The Evidence was in your Monthly Cell Phone Bill!... Bluetooth?
About 11 months ago I posted a kind of security challenge about my cell phone. Sorry about the delay, we have had some readers (Thanks Robin! et al) reminding me and asking "what happened". You deserve the information ;), so finally, here it is!
Answers to the questions raised in the previous blog post:
1) What are the incident response steps you would follow to discern what happened?
On purpose, I'm not going to be too formal following the recommended 6-step Incident Handling process we use and teach in the SANS Security 504 course. The first think to consider is this post itself... eh? You need to go through a final "Lessons Learned" phase, summarize, agree on, and report what happened and how to avoid similar incidents in the future. No matter how busy you are after the incident, and it is better late than never (this post is the best example), you need to do it.
First of all, you need a good detection mechanism, anomaly-based in this case, to detect deviations from the norm. After being aware of the extra charges, I started analyzing in-depth the logs, that is, the cell phone bill details. I focused on the specific date and time the messages were sent. Let's say September 9, between 21:50 and 22:05 (16 minutes). I focused on remembering where I was on that date, what I was doing at that time, and where my cell phone was on that specific moment :) I checked with the people around me at that date and time to double check my memories (team work).
I also tried to identify a pattern in the timing for the message generation during the 16 minutes period without success. There were minutes without messages, minutes with a single message, and minutes with up to five messages. The number of messages per minute in the 16 minutes period were: 1 3 1 3 2 0 1 0 1 5 1 0 1 0 3 2.
Additionally, I inspected the list of sent messages on the cell phone, trying to gather more evidence about the incident. Unfortunately, the list was empty. I checked the phone settings and discovered that the "Save all sent messages" option was off :( Time to change it for future incidents and reflect it into the "Lessons Learned" report. Check your phone at this point, exercising the "Preparation" phase, and be sure you enable as much logging as possible (if the phone memory can support it), so that you can have all the evidence available in future incidents.
I made a call to the telecommunication provider just to notify them about the incident and get them involved in reviewing the case. The person taking care of my call checked the description and classified it as "consecutive SMS messages sent" event. It seems it is something they already have categorized ;) The reason they initially argued was that my cell phone brand (of course, they know my cell phone brand) sometimes present this misbehavior. Amazing! ;) It is the first time I see this and I was tempted to ask: Does it apply to all models from the same manufacturer? (BTW, the brand was one of the major cell players world-wide)
Finally, I was following the incident with the provider, and three months later (one of the reasons that delayed this post), they agreed that it was a misbehavior on their billing system and decided to return my money back. From a technical perspective, unfortunately, it was not due to a new cutting-edge hacking technique ;)
2) What do you think is the most probable security threat/vulnerability/exploit that could explain this type of incident?
Being wireless one of my preferred security topics, the first thing that came to my mind was... Bluetooth!! Perhaps I left the Bluetooth radio enabled by mistake and someone was able to take advantage of it through a bluebugging attack (sometimes referred as bluesnarfing). Sometimes people mix these two types of Bluetooth attacks as they are very similar.
Both anonymous attacks allow an intruder to exploit a vulnerability in the phone firmware and get unauthorized access to the cell phone capabilities and run commands through Bluetooth without notifying or alerting the user, that is, evading any authentication and authorization mechanism:
Another option, as Robin pointed out, could have been someone around me, like the kids (it is always good to have kids around to blame them for it ;)), playing with my phone and impulsively voting through SMS in any of the popular TV programs. It was not the case :)
Finally, do not forget to add all your mobile, and especially Bluetooth devices, to your common detection, incident handling, and computer forensics best practices, as well as to your auditing and pen-testing capabilities. It is time to do so, as these devices are used for really sensitive information and tasks! For this same reason, new cutting-edge Bluetooth sections and labs have been recently added to the SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course.
Answers to the questions raised in the previous blog post:
1) What are the incident response steps you would follow to discern what happened?
On purpose, I'm not going to be too formal following the recommended 6-step Incident Handling process we use and teach in the SANS Security 504 course. The first think to consider is this post itself... eh? You need to go through a final "Lessons Learned" phase, summarize, agree on, and report what happened and how to avoid similar incidents in the future. No matter how busy you are after the incident, and it is better late than never (this post is the best example), you need to do it.
First of all, you need a good detection mechanism, anomaly-based in this case, to detect deviations from the norm. After being aware of the extra charges, I started analyzing in-depth the logs, that is, the cell phone bill details. I focused on the specific date and time the messages were sent. Let's say September 9, between 21:50 and 22:05 (16 minutes). I focused on remembering where I was on that date, what I was doing at that time, and where my cell phone was on that specific moment :) I checked with the people around me at that date and time to double check my memories (team work).
I also tried to identify a pattern in the timing for the message generation during the 16 minutes period without success. There were minutes without messages, minutes with a single message, and minutes with up to five messages. The number of messages per minute in the 16 minutes period were: 1 3 1 3 2 0 1 0 1 5 1 0 1 0 3 2.
Additionally, I inspected the list of sent messages on the cell phone, trying to gather more evidence about the incident. Unfortunately, the list was empty. I checked the phone settings and discovered that the "Save all sent messages" option was off :( Time to change it for future incidents and reflect it into the "Lessons Learned" report. Check your phone at this point, exercising the "Preparation" phase, and be sure you enable as much logging as possible (if the phone memory can support it), so that you can have all the evidence available in future incidents.
I made a call to the telecommunication provider just to notify them about the incident and get them involved in reviewing the case. The person taking care of my call checked the description and classified it as "consecutive SMS messages sent" event. It seems it is something they already have categorized ;) The reason they initially argued was that my cell phone brand (of course, they know my cell phone brand) sometimes present this misbehavior. Amazing! ;) It is the first time I see this and I was tempted to ask: Does it apply to all models from the same manufacturer? (BTW, the brand was one of the major cell players world-wide)
Finally, I was following the incident with the provider, and three months later (one of the reasons that delayed this post), they agreed that it was a misbehavior on their billing system and decided to return my money back. From a technical perspective, unfortunately, it was not due to a new cutting-edge hacking technique ;)
2) What do you think is the most probable security threat/vulnerability/exploit that could explain this type of incident?
Being wireless one of my preferred security topics, the first thing that came to my mind was... Bluetooth!! Perhaps I left the Bluetooth radio enabled by mistake and someone was able to take advantage of it through a bluebugging attack (sometimes referred as bluesnarfing). Sometimes people mix these two types of Bluetooth attacks as they are very similar.
Both anonymous attacks allow an intruder to exploit a vulnerability in the phone firmware and get unauthorized access to the cell phone capabilities and run commands through Bluetooth without notifying or alerting the user, that is, evading any authentication and authorization mechanism:
- Bluebugging uses the RFCOMM and Serial Port profile to get control of the phone telecom capabilities through AT commands, that is, the attacker can send make and forward calls, establish data connections, send and receive text messages (SMS) - this is what I thought - and even turn the device into a listening bug. View an example from The Real Hustle.
- Bluesnarfing uses the OBEX Object Push profile to get access to the storage capabilities of the device, including the list of contacts, calendar, SMS boxes, files (images, audio, video, etc), IMEI, etc.
Another option, as Robin pointed out, could have been someone around me, like the kids (it is always good to have kids around to blame them for it ;)), playing with my phone and impulsively voting through SMS in any of the popular TV programs. It was not the case :)
Finally, do not forget to add all your mobile, and especially Bluetooth devices, to your common detection, incident handling, and computer forensics best practices, as well as to your auditing and pen-testing capabilities. It is time to do so, as these devices are used for really sensitive information and tasks! For this same reason, new cutting-edge Bluetooth sections and labs have been recently added to the SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course.
Labels: Wireless
posted by Raul Siles at 3:57 PM
0 Comments:
Post a Comment
<< Home