After almost four years, Taddong’s expedition comes to an end…

Much like the four historic and meritable expeditions that went into the Challenger Deep reached their destination, today we announce that Taddong's adventures will hit bottom next December 2013.

Almost four years ago we embarked on a journey that has allowed us to accomplish the challenges that we defined at the beginning. We left the surface and delved deep into different security aspects of a range of current complex information technologies, by developing research activities and offering our professional services.

We hope that we have been able to shed some light on the different areas of information security that we have worked on, by means of our direct collaboration, by sharing our findings and knowledge when participating in security conferences, and through the posts in our blog and the tools and articles we published in our lab.

As of 2014, Taddong members will be starting two new adventures, motivated by the quest for new and more advanced technical challenges and committed to continue their journey to find, who knows, new abysses or deeper places that the ones found to date. David and Jose will continue their activities from Layakk, whereas Monica and Raul will do it from DinoSec. If you want to stay informed about our activities, don't hesitate to follow us in our (personal and professional) webpages, blogs and twitter accounts:

• LAYAKK: www.layakk.com (blog.layakk.com) @layakk


• DinoSec:  www.dinosec.com (blog.dinosec.com) @dinosec


• Raúl Siles: www.raulsiles.com @raulsiles

iStupid: Advanced Usage

This is a follow up of the original iStupid introduction and the iStupid setup & basic usage blog posts. The simplest way of launching iStupid is by specifying the local Wi-Fi interface in monitor mode (e.g. mon0). However, this is not a very useful alternative for the main purpose of the tool, as it will start announcing a random SSID (or network name) that will hardly match any entry on the target iOS mobile device PNL:

The "-v" (or verbose) option allows you to see how iStupid continuously generates 802.11 beacon frames (as it displays dots while sending 802.11 frames; see image above) and can be combined with any other option.

iStupid also allows you to set the channel ("-c" option) for the impersonated Wi-Fi network (not required, as Wi-Fi clients monitor networks and send probe requests through all the different channels), specify the BSSID of the Wi-Fi network via the "-b" option (random by default), set the beacon interval ("-i" option; 100 ms by default), and set the 802.11 rates (11b or 11g; "-t" option). The "-h" option provides help and all the details about these command line switches.

The most interesting command line switch is "-m". When the "-m" option is used, iStupid will monitor specific probe requests sent by Wi-Fi clients for the same SSID that it is announcing. This feature allows iStupid to automatically identify the security type of the Wi-Fi network stored on the target iOS mobile device for a given SSID, complementing the manual security type detection process described on the iStupid basic usage blog post.

In order to accurately and quickly use iStupid automatic detection capabilities through the "-m" option, due to the way iOS mobile devices scan for Wi-Fi networks and based on the research I performed, the best option is to ensure the iOS mobile device cannot currently connect to any nearby network (turn off the known Wi-Fi access points, if any). Then, execute these steps in the following order:

1. Disable the Wi-Fi interface in the target iOS device.
2. Launch iStupid with the desired options (e.g. "--loop" and "-m").
3. Enable the Wi-Fi interface in the target iOS device.

After turning on the Wi-Fi interface, the iOS mobile device will start scanning for the currently available Wi-Fi networks, it will find the iStupid impersonated network, and if it is available on its PNL (same name and security type), it will send particular 802.11 probe requests for that network. As a result, iStupid will print out the MAC address of the iOS device. iStupid allows monitoring a single Wi-Fi client MAC address (e.g. "-m 00:01:02:03:04:05") or multiple clients, in reality, all nearby clients through the "-m ff:ff:ff:ff:ff:ff" option.

As the network security type is initially unknown, by combining the "-m" and the "--loop" options iStupid will iterate through the different security types and, once the iOS device identifies the network available on its PNL, it will specifically probe for it and its MAC address will be displayed on the right hand side of the corresponding security type, automatically disclosing the security type of the legitimate network [0].

Additionally, the time iStupid spends on each security type can be adjusted through the "--loop_interval" option. The default value of 30 seconds works pretty well to allow iOS devices to rescan for new Wi-Fi networks.

Once the security type of the network has been identified, you can directly delete the network from the device PNL or easily relaunch iStupid with that specific security type (instead of "--loop") and proceed to delete the associated entry from the hidden PNL... slowly :-)

Something else I discovered when developing iStupid is that iOS might present weird GUI behaviors when the same network name is switching over different security types. As a result, the lock that indicates that a network is "secure" might dance, that is, appear on the top left hand side of the network name :-)

Nowadays, iStupid can also be used to manage and remove the entries from the Windows 8 hidden PNL, although you can use the "netsh" command line tool (e.g. "netsh wlan show profiles") too or the WiFi Profile Manager 8 graphical tool (Thanks Dennis Weber - Bechtle BISS - for the heads up!). Surprisingly, Windows 8 does not include the "Manage wireless networks" option available within the "Network and Sharing Center" in Windows 7. It does not include either the "advanced" button that allows managing the PNL in Windows Phone 8 (see slide 8 of my RootedCON 2013 presentation for a screenshot sample). As with iOS, only when the Wi-Fi network is in range you can right-click on it from the list of currently available networks in the default Windows 8 graphical interface and access the advanced options to manage the PNL.

Shameless plug: I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in Tokyo (October 21-26, 2013) and London (November 18-23, 2013).

[0] iStupid does not use advanced multi-thread locks and synchronization, so potentially the MAC address of the Wi-Fi client could be printed on a nearby security type. This can also occurs if the target iOS device decides to probe for the network at any given time, such as when it wakes up from an idle state.

iStupid: Setup & Basic Usage

iStupid, indescreet SSID tool (for the) unknown PNL (on) iOS devices, is a Python-based tool for Linux that allows deleting Wi-Fi network entries from the hidden PNL of iOS mobile devices. For more details see the original iStupid blog post, and it can be downloaded, as usual, from Tadddong's lab.

Setup & Requirements
iStupid directly runs in some of the most famous security Linux distributions, such as Kali Linux, BackTrack Linux (BT5R3), or MobiSec (v1.1) [0]. If you are interested on running iStupid on a different Linux system the main two requirements are Python 2.7.x and Scapy. The next two commands allow you to easily check the Python and Scapy versions (e.g. Kali):
# python -V
Python 2.7.3
# dpkg -l | grep -i scapy
ii  python-scapy    2.2.0-1    all    Packet generator/sniffer and network scanner/discovery

Before running iStupid you need to put your Wi-Fi network interface or card in monitor mode. You can use the well-known "airmon-ng start wlan0" command (from the aircrak-ng suite), or preferably use the following Linux commands, adjusting accordingly your network interface names (e.g. phy11, wlan0, and mon0):

Usage

To run iStupid (as root or using "sudo") you simply need to provide the SSID (or network name) of the Wi-Fi network to impersonate (through the "-s" option) and the local monitor mode Wi-Fi network interface (e.g. mon0):

In the example above, iStupid will emulate that a Wi-Fi network called "Taddong" is available, allowing you to delete it from iOS mobile devices. The default security type used for the network is OPEN, very common for public Wi-Fi networks and hotspots. However, the Wi-Fi network security type can be easily changed by specifying one of the different security options: OPEN (--open), WEP (--wep), WPA-Personal (--wpa), WPA2-Personal (--wpa2), WPA-Enterprise (--wpa-enterprise), or WPA2-Enterprise (--wpa2-enterprise). Example for a WPA2-Personal (or PSK) network:

Therefore, the first requirement to be able to remove a Wi-Fi network from iOS mobile devices is to know at least the name of the Wi-Fi network you connected to in the past, which was saved inside the hidden PNL. As a recommended practice, every time you connect to a new network you could take a screenshot of the Wi-Fi screen on iOS (by pressing both the Power and Home buttons simultaneously) in order to easily remember the network name:

The second requirement is to know the Wi-Fi network security type. A very common scenario for end users is to remember the SSID they connected to and (at most) if it was an open or a secure network. Unfortunately, if it was a secure network, iOS does not help the user to differentiate between the multiple security types, as all them are represented by a lock (see the image above).

For this reason, iStupid implements the "--loop" option. When used, iStupid will loop through the different security types, spending by default 30 seconds on each of them. This amount of time allows iOS to re-scan for new networks and identify the new security type, allowing you to manually remove the associated entry from the hidden PNL:

If you don't know the security type, this iStupid basic usage requires you to manually check if the network can be removed from the iOS mobile device, through the blue arrow button available at the right of the network name and the "Forget this network" option, every time the security type changes on the iStupid output. Once you see a new security type printed by iStupid (between curly braces), go to the iOS device, wait until it re-scans for networks (via the spinning wheel at the right of the "Choose a Network..." label), and try to remove the network from the hidden PNL:

The loop interval, that is, the amount of time iStupid spends on every security type, can be changed through the "-l" (or "--loop_interval") option. The next blog post in this series will demonstrate iStupid advanced usage through some additional command line switches (check the help with "iStupid -h"), like the one that tries to identify automatically the security type of the original Wi-Fi network.

Shameless plug: I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in Tokyo (October 21-26, 2013) and London (November 18-23, 2013).

[0] Mobisec v1.1 by default uses Python 2.6.5 and will complaint about not having the "argparse" module. You need to update it to Python 2.7.x in order for iStupid to work.

iStupid

One of the tools I demonstrated during the last RootedCON 2013 conference in Madrid as part of my "Wi-Fi: Why iOS (Android, and others) Fail inexplicably?" talk was iStupid: indescreet SSID tool (for the) unknown PNL (on) iOS devices. Apple mobile devices, based on iOS (such as iPhone, iPad or iPad mini, and iPod Touch), do not provide capabilities to manage their Wi-Fi Preferred Network List (PNL). This deficiency is something I talked about on my "Wi-Fi (In)Security - All Your Air Are Belong To..." presentation in 2010, almost three years ago (back to iOS 2.x, 3.x, 4.x...), and the situation has not changed :(

Unfortunately, the existence of other vulnerabilities where mobile devices disclose their PNL in the air (specifically TAD-2013-001 for iOS devices; see note below) makes mandatory to have capabilities to manage the PNL (view, add, delete, and edit PNL entries) in order to be able to check and increase the security of Wi-Fi clients. Besides that, the PNL management capabilities should also allow the user (or security administrators) to easily define the connection priority order when multiple known Wi-Fi networks are available, plus allow defining if the client should automatically connect to known Wi-Fi networks, being able to disable or configure that behavior per network individually. Additionally, it would be very interesting for mobile vendors not to force the user to have to enable the Wi-Fi interface in order to be able to manage the PNL (and change or configure other Wi-Fi settings), as the device might temporarily be exposed unnecessarily until a secure Wi-Fi setup is completed.

iOS mobile devices allow to easily add entries to the hidden PNL: every time you connect to a new network. However, the user cannot remove entries from the hidden PNL unless the Wi-Fi network is in range. Only if the user is in the area of coverage of the original Wi-Fi network, by selecting the blue arrow button available at the right of the network name, the "Forget this network" option will be available, which allows removing the network from the hidden PNL... WTF! (Without Traveling Faraway... where the original network is really available).

Trying to overcome this limitation in iOS devices, we thought about developing an iOS app (mobile application) to be able to manage the PNL. However, as you can see on slide 12 of my RootedCON 2013 presentation, for non-jailbroken devices there is no iOS SDK public API (or library) that allows accessing the PNL. Therefore, iStupid is NOT an iOS app :( Please, do not confuse the iStupid security tool (Python-based) with the iStupid app (entertainment) available on the Apple Store since 2010.

As a result, the other alternative I came up with was to develop iStupid, indescreet SSID tool (for the) unknown PNL (on) iOS devices, a Python-based tool (for Linux) available in Taddong's lab starting today (v1.0). It generates Wi-Fi (802.11) beacons frames for one or multiple SSID's, so that a previously known Wi-Fi network is available here and now and, thus, can be easily removed from the hidden PNL of iOS mobile devices. The tool provides multiple configuration options for the advanced user (check the help with "iStupid -h"), such as selecting the Wi-Fi network SSID, channel, BSSID, beacon interval, 802.11 rates, security settings (Open, WEP, WPA(2)-Personal & WPA(2)-Enterprise), and much more. Future versions of the tool might include an option to perform dictionary and brute force Wi-Fi network impersonation on the SSID, and potentially, support for other operating systems, such as Mac OS X (as there are lots of iOS mobile device owners that are Mac OS X users).

Mobile devices perform network identification, that is, they consider a currently available Wi-Fi network to be the same as a previously known Wi-Fi network, based on two factors: the SSID (or network name) and the Wi-Fi network security type.

During my initial testing I discovered that for iOS mobile devices it is not relevant if the network is based on WPA or WPA2, or if it uses TKIP or AES-CCMP. iOS allows the user to remove a WPA2 network from the PNL even if it appears as WPA, and viceversa.

The version I showed at RootedCON (v0.9) has been slightly improved by version 1.0 with additional capabilities that are detailed in the two upcoming Taddong's blog posts: "iStupid: Setup & Basic Usage", and "iStupid: Advanced Usage".

NOTE: I'm wondering if the recently published press release covering this PNL disclosure issue on modern mobile devices will finally help to motivate vendors to fix it? Am I holding my breath? No.

How To Add Wi-Fi Networks To Mobile Devices?

One of the first things I learned during my recently published Wi-Fi security research is that mobile vendors do not read Taddong's Security Blog ;-) During the RootedCON2013 conference celebrated in Madrid last month, March 7-9, I talked about the still prevalent Wi-Fi weaknesses, or vulnerabilities (depending on how relevant you think they are), in mobile devices. The full presentation, called "Wi-Fi: Why iOS (Android, and others) Fail inexplicably?", has been published in Taddong's lab, and by the RootedCON organization (check the other great presentations too). The minimalism applied to the user interface in mobile platforms clearly impacts, still nowadays, their Wi-Fi capabilities and security stance.

In 2010 I published a Windows Mobile 6.5 vulnerability in its indiscreet Wi-Fi interface (TAD-2010-003) in which the "This is a hidden network" configuration setting didn't have any effect. In the same way this setting existed since the Windows XP SP2 days and through all the subsequent Windows versions (Vista, 7, 8…), it was not working for Windows Mobile, so all Wi-Fi networks were managed as hidden and disclosed for free by the device.BTW, this behavior does not affect Windows Phone 7.x or 8.
 
This insecure Wi-Fi client behavior is well known since 2004, when the original Karma-like attack were published (so old that link does not exist anymore :-), and was fixed in 2007 in Windows XP through the KB917021 optional update. Why in 2013 most mobile platforms still expose client devices to Wi-Fi network impersonation attacks…?
 
In 2011 I published a similar Preferred Network List (PNL) disclosure vulnerability for Android 2.x-3.x (TAD-2011-003) depending on how you add a Wi-Fi network to the mobile device: automatically from the list of available Wi-Fi networks (expected behavior) by selecting it, or manually from the "Add Wi-Fi network" button (now the "+" button in Android 4.x) at the bottom of that list (vulnerable behavior, as the network is considered as hidden again).

During 2012 I explored new vulnerability research and disclosure approaches and strategies. Due to the fact vendors (IMHO) do not pay enough attention to and do not spend enough time on these issues, I decided to mimic them and not to spend too much time on thoroughly reporting and documenting these vulnerabilities though a detailed security advisory, as I did in the past. Instead, I notified the vendors, and the conference presentation (from page 5-24 of 68) plus this blog post become the technical report for these vulnerabilities that affect the main mobile platforms still today. I simply gave each of them a vulnerability ID to keep track of them (if required):  

• TAD-2013-001: PNL disclosure in iOS 1.x-6.x when adding Wi-Fi networks manually. 
• TAD-2013-002: PNL disclosure in BlackBerry 7.x when adding Wi-Fi networks manually (at least it can be changed afterwards from the advanced Wi-Fi settings, and in particular, through the "SSID broadcasted" option). 
• TAD-2011-003 still applies to the latest Android 4.x versions, and has not been fixed since Android 2.x-3.x (2011).

Apart from manually adding new Wi-Fi networks to the device, there are other weird situations where mobile devices might disclose their PNL… by mistake. Mobile vendors need to pay close attention to this issue and avoid their devices became easy victims of Karma-like attacks, where an attacker impersonates the legitimate Wi-Fi network and shares the network at layer 2 with the victim for further attacks (independently of the Wi-Fi network security settings, as there are ways to get the network key just interacting with the Wi-Fi clients). I also suggest mobile vendors to include an option to easily determine if a Wi-Fi network is considered as hidden or not by the device, as we have in the traditional operating systems.

This specific vulnerable behavior associated to Wi-Fi clients is reflected in the OWISAM Top 10 methodology, as "OWISAM-TR-009: Client trying to connect to insecure networks". OWISAM is a new Wi-Fi project by Tarlogic that was also presented during RootedCON 2013 (OWISAM). If you are working on Wi-Fi security I recommend you to get involved.

The tools I demoed during the presentation, such as iStupid (indescreet SSID Tool (for the) Unknown PNL (on) iOS Devices), will be released in the upcoming weeks. Other mobile device Wi-Fi vulnerabilities that affect Wi-Fi enterprise networks are covered on my RootedCON 2013 presentation (pages 40-60 of 68), and potentially, on a future blog post.

Wireshark SMB2 file extraction feature now available

Our SMB2 object exporting functionality has been included in the Wireshark development trunk from SVN rev. 48210 on.

Source code and binaries for the supported platforms are publicly available at the automated build section of Wireshark.

NOTE: As this is a development version, use it with caution.

Wireshark SMB2 file extraction feature

Some time ago we contributed to Wireshark the SMB file extraction feature, which enabled the tool to extract a file (or portions of it) from the SMB traffic contained in a network traffic capture. From the moment when the plugin was published, we have received several requests to extend this funtionality to support SMB2 traffic as well, and we have also seen the need for that functionality in every pentest that we have done since then, but we haven't had the time to write the code. During a recent engagement we finally decided the time had arrived to go and write it.

Although SMB2 support was our main objective, we took the time to implement some other functionalities that we have detected that were necessary.

SMB2 support for ExportObjects->SMB
The major part of work to write SMB2 support has been finding out where the needed information can be found in smb2 dissector and, for those pieces of information not already there, how to store them in the right place to integrate, as far as we can, into the wireshark code structures. The rest of the code (the part where the file is built from the chunks that are extracted from each packet) has been almost completely reused. We have implemented the minimum functionality to be able to make a proof of concept, but we have tested it against a lot of real captures and it seems to be stable. You can see what it looks like in the following screenshot.

Other major changes
The "File ID" vs. "File Name" dilemma
There was another important issue flying around our minds since we wrote the first plugin. SMB and SMB2 identify a file based on a File ID (which has different formats and meanings in SMB and SMB2). It is usual to find the same file (i.e. same tree_id AND same file_name) several times in the same capture file. That means that it is possible that some parts of a big file are associated with one file_id and other parts of the same file are associated with a different file_id. In that case the plugin, as it was, would report that it knew a percentage of two different files. We were wondering if taking the "tree_id+file_name" as the file identifier could make the plugin to capture the whole file or at least a bigger part of it.

This seemed to make sense, because the plugin builds the final file by inserting the chunks that it receives in the order that appear in the capture, and so it overwrites older parts of the file with newer ones. Yet, we were not completely sure that was the best solution, and finally decided to make it an option for the user, available at
Edit->Preferences->Protocols->SMB and Edit->Preferences->Protocols->SMB2
for that purpose:

Support for other SMB dialects
Some time ago Paul Santangelo pointed out that the plugin didn't work under some circumstances. After studying the capture file that he sent us, we concluded that he was right: we had implemented the extract capability for *_ANDX SMB commands, but not for the original SMB_COM_CREATE, SMB_COM_OPEN, SMB_COM_READ and SMB_COM_WRITE commands. Although according to Microsoft these commands are deprecated, we decided to include support for them because wireshark smb dissector supports it and also because that way the plugin can be used in rare but existing old environments. By the way, Paul, we loved the example pdf file extracted from your capture!

Other minor changes
We have also include some minor improvements to the plugin.
The first one is a bit of cleaning in the way that file names are shown. Wireshark uses UTF-8 enconding to show strings in the ExportObjects->SMB window, but SMB uses some flavour of UTF-16. We have ensured that the string passed to that window is encoded in UTF-8 schema, and all non printable characters coming from UTF-16/UNICODE have been transformed into a single '?'. It is not a perfect solution, but it is a bit cleaner.
The last change we added has to do with tree id names and filenames. Until now, when the plugin was not able to find the tree id it just showed TREEID_UNKNOWN or TREEEID_XXX (where XXX was the ID number of the tree). Now, the server IP address has been added to the tree pseudo-name, so that the user doesn't have to dive into the packet trace to find it.
Regarding filenames, we have decided to show the full pathname instead of the basename, because we think that this provides better information.

Coming next
In a few days we will send the patch to wireshark for inclusion in the deveolpment trunk, so we hope it will be publicly available soon. As usual, we will then publish a windows compiled version of wireshark including all this. So stay tuned if you want this feature in your Wireshark!

TLSSLed v1.3

After more than one year since the previous TLSSLed version, we are happy to announce TLSSLed v1.3!

This version is the result of testing lots of HTTPS (SSL/TLS) implementations during real-world pen-tests, so it is full of minor improvements and extra checks to identify different behaviors we have found in the wild (see the changelog inside the tool/script: "New in version 1.3" section). In several of my "Security of National eID (smartcard-based) Web Application" talks during the last year I mentioned that an upcoming TLSSLed version was going to be released... so here it is! :) Additionally, the tool output has been changed for easy reading and to provide quick information for each finding: negative [-], positive [+], or informational [.] (as well as grouping tests [*] and highlight warning and error messages [!]).

The tool usage has not changed. Simply run the tool by providing the target hostname or IP address plus the target port:
$ ./TLSSLed_v1.3.sh <hostname or IP_address> <port> 

This version has been tested on updated versions of Samurai WTF 2.0 (running openssl 1.0.1 and sslscan 1.8.2), Backtrack5 R3 (running openssl 0.9.8k and sslscan 1.8.2), and Mac OS X Mountain Lion 10.8.x (running openssl 0.9.8r and sslscan 1.8.2; it requires to add and compile sslscan manually, see below). Samurai WTF 2.0 is the only one of these three that includes openssl v1.0.x by default, providing support for the TLS v1.1 and v1.2 protocol tests.

Instructions to get and compile sslscan for Mac OS X are available on the original webpage, although for Mountain Lion, if you have Xcode installed (or even without it?), you simply need to run the following command and ignore the openssl deprecated warnings:
$ gcc -lssl -lcrypto -o sslscan sslscan.c

Additionally, TLSSLed v1.3 has also been recently tested with a newest sslscan fork project that was released to better support STARTTLS, currently at version 1.8.3rc3, and available at GitHub.

If you find any bug, misbehavior, openssl/sslscan version combination, or target HTTPS (SSL/TLS) implementation that cannot be properly tested, please let us know so that we can fix it and add new features. Enjoy it!

TLSSLed v1.3 can be downloaded, as usual, from Taddong's lab.

Apple's Skimpy Software Update Descriptions

UPDATE: January 28, 2013
Coincidentally, iOS 6.1 includes a security fix for a DoS Wi-Fi vulnerability (CVE-2012-2619) whose advisory was published on October 23, 2012, by Core Security (including a PoC), affecting the Broadcom Wi-Fi chipset of iPhone 3GS (BCM4325), iPhone 4, iPad and iPad 2 (BCM4329), as well as other Apple and non-Apple mobile devices.

NOTE: This article was cross-posted on the SANS Penetration Testing blog edited by Ed Skoudis.

This blog post is a follow up about the concerns regarding Apple's iOS updates and potential improvements from a previous SANS Penetration Testing blog post by Josh Wright, titled "Apple's Combined Patching", published in October 2012.

Since the release of iOS 6 last year, Apple has published iOS 6.0.1 and then iOS 6.0.2. The main concern with iOS 6 (Sep 19, 2012) was the huge amount of security flaws fixed on a single version (197), plus the combination of platform changes and security patches rolled into a single update. The iOS 6.0.1 update (Nov 1, 2012) included fixes for four specific security flaws, with their corresponding CVEs, plus other non-security rated bug fixes, like one that improves Wi-Fi reliability for WPA2 networks. And then... iOS 6.0.2 was released on Dec 18, 2012, one month ago today.

The iOS 6.0.2 update is neither listed on the Apple Security Updates webpage nor on the Apple Product Security Announce mailing list, so one could assume it is a non-security related update, but... are we sure? The truth is - We as a community don't really know, as Apple hasn't provided any information about security issues addressed in this update! The iOS 6.0.2 update page only says (it) "Fixes a bug that could impact Wi-Fi.":

Gosh! Thanks for almost nothing, guys. It is hard to think about a software update description that can be less useful, unless you remove the last four words leaving simply "Fixes a bug". Still today, one month after its release date, a significant number of IT people are not aware of the update, and hardly anybody has any related details. In the same way we learned a decade ago about the importance of separating functionality updates from security patches, we also learned about the importance of getting descriptive and actionable security update details.

With such limited information, if one turns to the community (sometimes a questionable source of trustworthy information) trying to find more details about the update, you can find all kind of reports and very long Apple forums threads: from people whose iOS 6 device couldn't connect to any Wi-Fi network and required 6.0.2 to use Wi-Fi, to just the opposite, people that cannot connect after updating to 6.0.2. Supposedly the 6.0.2 update fixes various Wi-Fi connectivity issues introduced by iOS 6, but it additionally may impact battery life, an issue that could be associated to a change in the Wi-Fi behavior related to the mysterious bug that shall not be named (at least by our friends in Cupertino in their patch description).

Back to the original question... are there any security implications to this software update considering it fixes an undocumented Wi-Fi related bug? Wi-Fi is one of the most, if not the most (together with 2/3/4G mobile communications), relevant communication mechanism for mobile devices today. As we cover in detail in the SANS SEC575: Mobile Device Security and Ethical Hacking training class, modern mobile devices are affected by various security weaknesses in their Wi-Fi capabilities, even when using enterprise Wi-Fi networks. Since we do not have official details about this update... when is a software update considered security related?

By default, when multiple known Wi-Fi networks are available, iOS devices connect to the last-used network. However, there are reports of iOS 6 devices prioritizing open networks over secure networks. From my perspective, this behavior has some rather serious security implications. It is not possible to know yet if this is the bug fixed by 6.0.2, or any other of the multiple Wi-Fi connection issues reported all over the Internet (not including here the fact that the Apple web testing page used by iOS devices to discover if they are under a Wi-Fi captive portal was not available for some time and was the cause of some of these connectivity problems). Troubleshooting Wi-Fi issues is not a trivial task, as multiple factors can influence the testing, such as nearby signals, radio frequency glitches, or even the frequency band used by the access points (2.4 or 5 GHz).

In the SANS SEC575 class, when we cover the security of the iOS mobile device platform, people frequently try to validate the following statement: "So, can we say that the latest (mobile device) hardware models are more secure?" If they can answer in the affirmative, they have a solid business argument to ask their boss for the latest and greatest mobile device model! In many cases, the statement is indeed true, as earlier models are left in the dust unable to run the latest patched versions of mobile device software. Leaving business and marketing strategies aside, today's mobile device security is a mix of hardware, firmware, and software updates, where the latest hardware models implement security protections not available in previous models. But, the update cycle is shockingly small, making the PC upgrade cycle of two-to-four years look like a snails pace.

Besides Apple, other mobile device platforms also present relevant weaknesses in their security update processes. Platform fragmentation and the lack of timely updates are a major concern, especially for Android devices. Unfortunately, the security maturity level of the mobile world today is still a decade behind in many aspects. We need to learn from history, and apply, to the mobile world, the best practices we have learned!

Should users and enterprises update to iOS 6.0.2 for security reasons? The truth is: we don't know! Should Apple provide more detailed descriptions about software updates? Yes, absolutely. For the love of all things Apple and the security community: please, please, please arm us with the information we need to make intelligent decisions about patching and security our devices. Am I holding my breath? No.