RaDaJo (RAul, DAvid and JOrge) Security Blog

Mobile Malware Attacks and Defense
Author: Ken Dunham et. al.
Editorial: Syngress
Publication date: November 14, 2008
ISBN-10: 1597492981
ISBN-13: 978-1597492980


Summary: An historical reference of mobile malware and threats, plus a technical introduction to its analysis and in-depth inspection.

Score: 4/5

Review:
Security threats on mobile platforms are one of the key topics and main targets for the next couple of years, given the ubiquity and popularity of these devices, plus their advanced capabilities and use of sensitive application: micro payments, online banking and e-commerce, access to "the cloud", etc.

This book is one of the few references, if not the only one (till very recently), focused on the multiple security aspects of the mobile ecosystem. As such, it constitutes a great historical reference about what mobile malware (referred as MM) and threats were until its publication, in late 2008.

The book starts by introducing mobile malware, although it can be a bit confusing for the novice reader, as it mixes up attacks, tools and threats (most them Bluetooth based), and for example, WiFi is not even mentioned (yet). The next chapter (ch 2) provides an interesting overview on how mobile malware shows up in a terminal from a user perspective, including the most common behaviors and the kind of interaction expected from the user. It would be great to have a detailed explanation of the propagation method, as with CommWarrior, for all the samples analyzed in this chapter.

The next three chapters (ch 3-5) are a really valuable historical reference about mobile malware, including its timeline, how it has evolved since 2000 till 2008, the types of threats, categorized by malware families, the most significant or famous specimens, such as Cabir in the Bluetooth side, plus an extensive taxonomy of mobile malware and threats based on the infection strategy, distribution and payload. Although some tables, with more than 400 references, could have been moved to an appendix to facilitate the reading, this set of chapters summarizes how mobile malware seriously started, back in 2004, and evolved over time. The comparison of different pieces of malware, and the extra analysis of the most relevant specimens, together with the technical details they used to survive, makes this section of the book a very good "encyclopedia".

Then, the book reflects the influence of multiple authors, presenting different unconnected and independent chapters. The phishing, SMSishing and Vishing chapter moves out of the mobile space, covering lots of details about these threats on traditional environments, such as common web browser based solutions, and the usage and purpose of the network captures attached is still not clear to me. I still remember my surprise from a technical perspective when I read that the transmitted data between the client and the verification server could not be identified, as they were using an SSL connection: "What about using a HTTP(S) interception proxy?" Finally, it includes an extensive phishing academic research mainly based on Bayesian networks and a distributed framework, which on my opinion, is clearly out of the scope of the book.

The more technical chapters come next; chapter 7 focuses on the core elements for the most widely used mobile platforms, their protection mechanisms and how they have been bypassed in the past, covering mainly Windows Mobile (WM), iPhone, Symbian, BlackBerry and J2ME (Java). It includes a extremely short summary on prevention and exploitation. This is complemented by the techniques, methods and tools available for the analysis of mobile malware (ch 8), the in-depth details for the disassembly and debugging of associated binaries (ch 10), plus the strategy and main constraints to perform a forensic analysis on this type of devices (chapters 8 and 9). This is by far the most relevant technical portion of the book.

The book follows the old and useful Syngress layout tradition of adding a few common sections at the end of each chapter to reinforce the material covered: Summary, Solutions Fast Track, and FAQ.

The first portion of the book (ch 1-5) will be an eye opener for a non-technical audience; highly recommended, together with the last chapter (ch 11) focused on the defensive side and how to mitigate all the threats covered along the book. The second portion for the book (ch 7-10) is focused on security professionals, mainly incident handlers and forensic analyst that need to deal with the technical aspects of mobile attacks and infections.

Due to the new mobile threats and issues that turned up in 2009 for the advanced smartphone platforms (like iPhone or Android), and the trend for new and more dangerous specimens expected in 2010, a second volume or edition would be a must.

UPDATE: Amazon review (first one).

Labels: book, Mobile, Wireless

I spent part of last and this year researching about Bluetooth security, and recently I have been promoting the need to focus on securing Bluetooth technologies at a personal and enterprise level. I've presented about it in several private and public events all over the world, such as Meitsec 2008, II Jornadas CCN-CERT, or SANS London 2008.

An event-independent English version of the presentation (requested by multiple attendees) is available here!


The most critical aspect is that Bluetooth devices are being extensively used to exchange private and sensitive information in the form of data and voice, and the control is mainly on the hands of end users. If you do not enable an enterprise (or even personal) security program for these devices and communication channels at the same level you do with the rest of your infrastructure, you will be dealing against Bluetooth-related security incidents soon, especially on targeted attacks. Start by adding Bluetooth detection capabilities, and integrate this technology in your penetration tests and incident handling procedures.

Although it has been tough traveling around with two laptops, plus the USRP, multiple omni and directional antennas, cables, several Bluetooth dongles, plus the victim cellphones and headsets... just to run the demo, it has been a well worth experience! The demonstration focuses on showing the audience the Bluetooth activity around, discovering the undiscoverable (Bluetooth hidden devices), and injecting and eavesdropping audio from a headset The initial threat was published by Spill and Bittau, then popularized by Josh Wright, and in my opinion it is not getting enough attention. A demo is well worth a thousand words! ;)

Something that took my attention in one of the events was the little impact the presentation and demo had on part of the audience, as it seems it didn't increase the awareness and paranoid level about the current threats. It is in our hands (as end users and organizations) to improve the security capabilities we demand from the Bluetooth vendors. Most of the time, I see the audience changing the Bluetooth settings on their phones and PDA's as I move through the material ;)

This time, the security recommendations are not based on expensive or complex solutions, such as the latest and greatest Bluetooth IDS/IPS that costs more than 100K €. You simply need to follow common sense practices and precautions to get a reasonable level of protection (check the last part of the presentation), and understand the major threats and weaknesses, especially on Bluetooth devices with limited capabilities, such as car kits, headsets, keyboard and mouse, etc.

Enjoy it and... Happy Blue Christmas!
--
Raul Siles
www.raulsiles.com

Labels: Wireless

Probably at this point you have heard that "WPA has been cracked" all over the Internet and the Blogosphere. As the specific details will be fully disclosed on PacSec 2008 next week, and in an upcoming whitepaper on the aircrack-ng website (check it during the weekend or early next week), I considered relevant to provide technical details (summarizing facts) about what's going on and clarify some of the FUD out there.

UPDATE: The "Practical attacks against WEP and WPA" whitepaper has been released (08/11/2008 - 21:00 CET). The paper mentions the attack could be run on non-QoS wireless networks, although no extra details are provided.

First of all, you have a technical overview on this post (thanks Erik for the reference), and thanks to Della Lowe and Rick Farina (from AirTight Networks) for the early warning notification, spreading the word to create awareness on the community, and the detailed technical conversation we had about the topic, respectively.

Why is this relevant? Because it is the first cryptographic attack against WPA(2), and TKIP specifically. Previously we only knew about dictionary attacks on WPA or WPA2 pre-shared keys (Personal mode), or RADIUS impersonation attacks in Enterprise mode.

The attack:

• This security research has been discovered by Erik Tews (the T on the PTW WEP attack) and Martin Beck, members of the aircrack-ng team.
  
• The new attack only affects the TKIP encryption algorithm used by WPA (and WPA2, optionally).
  
• The attack allows an attacker to decrypt individual 802.11 wireless frames, similarly to the old WEP chopchop attack, as it discloses the keystream (or PRGA), that is, the cryptographic material used to encrypt a single wireless frame.
  
• The attack also allows to inject new frames using the info of the disclosed keystream and other tricks (see below).
  
• The keystream is disclosed by attacking the integrity algorithm (MIC) used in TKIP, called Michael.
  
• TKIP implements specific built-in countermeasures around Michael to avoid frame manipulation, and blocks replay attacks using sequence number enforcement.
  
• The attack takes advantage of the message notification about MIC failures in order to identify valid injected frames, in the same way the WEP chopchop attack used the ACK frames to confirm valid frames.
• Frames can only be injected when the wireless multimedia extensions (802.11e or WMM) are used, as these allow to break the sequence enforcement mechanism. The injected (and forged) frame is sent over a different QoS queue. This effectively limits the amount of injected frames that can be sent (around 7).
  
• Some access points, or standards like 802.11n, require WMM. It cannot be disabled. The 802.11n standard does not accept TKIP, but some 11n vendors allow you to enable it.
• The attack combines the new chopchop techniques, plus the QoS queue change, to decrypt and inject new frames. This is were the meat of the research and whitepaper is!
  
• The attack only allows to decrypt and inject frames that go from the AP to the client, as the client generates the MIC failures (required to confirm the validity of an injected frame).
• The current research allows to decrypt the frame at a rate of about one bit per minute on average, that is the reason why the current attack is effective against small packets, such as ARP, DNS, or TCP SYN packets. However, spending a bigger amount of time it would be possible to decrypt larger packets.
  
• Every time a new valid frame is injected (confirmed by the generation of a MIC failure message), a new bit value is discovered (like in chopchop), but with TKIP, the attack must stand-by for 60 seconds in order not to trigger the Michael countermeasures, what will renew the keys (and invalidate the attack).
  
• The reason why it is being said that it takes 12-15 minutes (or 900 seconds) is because the goal of the sample test is to decrypt two bytes (16 bits) of an IP address (considering the other two bytes are known, subnet portion on a class B) inside an ARP packet.
• By looking at the source code of the PoC tool, it checks the IP private address ranges: 192.168, 10.x (10.0), 172.16-31 (172.16).
  
• For those interested on the in-depth technical details (see the source code), there is a new tool that implements the attack, called tkiptun-ng, and it is available on the aircrack-ng SVN repository (current copy, rev.1208).
  

This new research opens the door to new WPA(2)/TKIP attacks and future enhancements, so it is time to start applying and planning the appropriate security countermeasures to remove or mitigate this and similar future threats.

The countermeasures (for wireless vendors, businesses, and end users):

• [users and businesses] Switch to AES and WPA2, as more TKIP attacks are going to come! AES is the best solution (if your equipment supports it, mandatory since 2006 from a WiFi Alliance perspective) as it is more efficient and secure than TKIP.
  
• [vendors] There are a few ideas around to fix the vulnerability from a TKIP perspective:
• Rotate keys every two minutes, but this will have a significant performance impact, specially on the devices that do not support AES (with limited hardware capabilities). [1]
  
• Don't send the early warning message notifying about the first MIC failure, what will break the current 802.11i standard.
• Activate the MIC countermeasures with a single MIC failure, what will break the standard again, and activate the built-in DoS capabilities within TKIP in non-evil scenarios where a single packet has an invalid MIC. Very risky!
  
• [businesses] If your hardware do not support AES and cannot be easily replaced, complement the security mechanism provided by TKIP encryption with other capabilities, such as detection. This attack generates a significant amount of MIC failure messages that must be detected by your wireless IDS (WIDS).
  

[1] This reminds me about the old (and almost useless) Dynamic WEP (DWEP) implementations.

Remember, TKIP was a temporary solution to mitigate WEP security issues. It is time to switch to AES, so start planning the migration now!


NOTE: If there is an incorrect statement above, as all the details are not known yet, please let me know in order to clarify or fix it.

Labels: Wireless

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:

• 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.

Although these are old Bluetooth attacks, I'm sure we still are going to see similar vulnerabilities in new phone models, as it is an implementation bug. If you want to test your device, I suggest you to port and service scan it from a Bluetooth point of view using the psm_scan (1-65535) and rfcomm_scan (1-30) tools.

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

It is August 2008, that is, famous US hacking conference time once again! This time BlackHat and Defcon are surrounded by the recent Dan Kaminsky's DNS vulnerability. You can get most of the details from the July's posts on his blog, and on the Metasploit blog. Test your DNS, retest, and patch! I couldn't miss not to blog about it! ;)

But not only of DNS we live, so Airtight Networks, as they did last year too with WEP cloaking, is presenting on Defcon 16 about something they called "Autoimmunity disorder in Wireless LANs". The name comes from biology: autoimmune disorder is a malfunction of the body's immune system that causes the body to attack its own tissues. The vulnerability found in WiFi access points allows an attacker to inject specially crafted packets that influence the AP behavior, creating a kind of self-DoS scenario.

It basically exploits one of the major threats against wireless technologies, Denial of Service (DoS), and becomes a new way of launching a DoS attack. It's not a new cutting-edge flaw, and although it is not a 802.11 design vulnerability, it's an AP implementation vulnerability we need to pay attention. The main reason behind it is the complexity of the 802.11 specification. The original 802.11-1999 is a 528 pages document, the 802.11i-2004 spec adds 190 pages, the new 802.11-2007 spec is 1232 pages in length, and now you need to add 802.11n (MIMO), 802.11e (WMM), 802.11w, 802.11f, 802.11k, 802.11r, as well as all the other upcoming IEEE extensions. Do you see how complex the development of an 802.11 AP or client driver can be?

The vulnerability has been found in all kinds of 802.11 APs, SOHO/home, open source and commercial. Each of them is vulnerable to different stimulus, based on their own 802.11 implementation, but with a similar end result. You need to wait till Defcon to get the details, where different malformed crafted frame samples will be demonstrated. Basically, referring back to biology, they have found different antigens (the crafted packets) for different AP implementations, that is, different substances that can stimulate an immune response.

The following scenario demonstrates the issue: Every time a WiFi client connects to an AP, it follows the authentication and association process, it gets an Association ID (AID), and a new entry is created for that client in the AP's association table. When an AP gets a new 802.11 wireless frame, before forwarding it, it checks that the source address is on the association table and therefore belongs to an existent client. If it is not, the AP takes actions using management frames to notify the client about it, and potentially ensures the client is not allowed any access. What if the source address of the 802.11 frame is the broadcast address (ff:ff:...:ff)? The source address can never be the broadcast address, but if the AP has not been implemented with the proper sanity checks, it may try to ensure that "this client" is not allowed to connect to the network. As a result, it disassociates "this client", that is, all clients (broadcast address). A single frame can trigger autoimmunity disorder and cause the AP to turn hostile against its own clients.

Since these are new malicious frames, not available in the current WIDS signature databases (time to update them!), plus it is the AP the final device originating the DoS over the legitimate clients, and because the attacker needs a lower injection rate to keep the DoS going on (vs. the standard deauthentication or disassociation DoS floods), it might be slightly more difficult to detect these attacks.

The second part of the presentation demonstrates a similar scenario against 802.11w-aware AP's. 802.11w (or MFP, Management Frame Protection) is an upcoming specification that promises to protect (through authentication, encryption and integrity) non-data 802.11 frames. Unfortunately, some time ago we discovered that only a few management frames will be protected by it, leaving other management frames and control frames unprotected, still exposing WiFi networks to DoS attacks. Additionally, autoimmunity disorder opens a new door through which DoS attacks can still be launched due to 802.11w-aware AP's with implementation flaws.

A very brief preview of the presentation can be found here.

Although some people still think deploying a wireless network using WPA or WPA2 is enough to protect the network, you can easily learn this is not the case. Check the latest papers on my wireless security Web page, or the recently updated SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course I teach in Europe (a whole new set of contents has been added, including lots of new labs, the new FreeRadius-WPE attacks, wireless fuzzing, attacks against other wireless technologies, new sections covering Bluetooth, and a full update to the complementary SWAT kit). We need to deal with lots of recent wireless threats, complex and advanced rogue devices, 802.11n intrusion detection constraints and new attacks, extended wireless client attacks, new EAP implementation flaws, as well as multiple DoS scenarios, and protect other common wireless technologies, like Bluetooth. In the case of autoimmunity disorder, we definitely need a better secure software development cycle for all 802.11 products, including AP's and client software, such as wireless card drivers.

As complementary information (for those reading till the end of my long posts ;), there is a new free online wireless tool to simulate 802.11n coverage, called 802.11n WLAN Coverage Estimator.

P.S: Thanks to Della Lowe and Pravin Bhagwat, CTO, for bringing up this issue to my attention and for the first hand Defcon preview.

Labels: Wireless