Category Archives: Mobile Security
Securing Mobile Hotspots, Part 1
Mobile hotspots are awesome. They allow the user to connect any WiFi-enabled device to a high-speed 4G network. Anywhere. Maybe that’s one reason we see so many hitting the shelves. A significant number of these devices are equipped with advanced capabilities, such as media sharing or location-based services. But even without these capabilities, mobile hotspots are a tinkerer’s dream. It’s a WiFi radio, cellular (3G and 4G) radio, embedded OS, and web server, all rolled into one sweet package. So much to look at! Without pointing out particular vulnerabilities that we’ve found, we’re going to cover several weak points that we see across the board in these devices and provide some advice for testers and developers.
Weak admin controls
While a router’s webapp isn’t a fully internet-exposed attack surface, it isn’t ideal if sharing your hotspot with someone you think you can trust leads to a total compromise of your data. Most hotspots have an admin password — we like to see a different password for the admin interface and for WPA. Otherwise, what’s the point of an admin interface? <oprah>You get admin, and you get admin, and….</oprah> Once the passwords are different, it shouldn’t be easy to bypass the password prompt altogether. Here is a great example. Researcher Dustin Schultz found that an unprivileged user can access the WiFi password and administrative settings by adding a ‘/’ to the end of any URL. We’ve seen this take many forms, and allow anything from faking the admin cookie to disclosure of the actual admin password.
Common web-app vulns
The router’s web interface is private, right? Right? Unfortunately, Cross-Site Request Forgery (CSRF) attacks can originate from outside the network, and ultimately send data on your behalf. If you are logged in as the administrative user, CSRF can be used to change access point security, administrative passwords, or execute denial-of-service (DoS) attacks. CSRF attacks have been well-documented, and the OWASP site has plenty of examples and remediations, the most basic of which is to include anti-CSRF tokens with every request. This allows the webserver to verify that the request is coming from the actual page, not from a pre-crafted static request which is embedded in a website.
WiFi Protected Setup
Many modern routers STILL have Wifi-Protected Setup (WPS) enabled by default. The purpose of WPS is to allow users to connect to the Access Point using an 8-digit WPS PIN instead of a WPA(2) network key. Unfortunately, a very public design flaw in the protocol allows the PIN to be brute forced because it is sent and verified 4 digits at a time. This results in the router giving out the WPA key for the network. Lucky for us, some routers do have an option to disable WPS. Unlucky for us, some of those routers respond to WPS protocol requests even after WPS has been disabled. To mitigate the problem, OEMs should make sure that users have an option to disable WPS and that the device does not respond to requests after it’s disabled.
We’ll be publishing some more issues next week, including command injection, UPnP, and DNS rebinding!
Cheers,
Max and Rohan
iOS Configuration Profile Ransomware
A couple of months ago, at ShmooCon 2013, Tim Medin gave a great short talk titled “Apple iOS Certificate Tomfoolery.” One of the most interesting ideas I took away from this talk was the idea of ransomware delivered through a configuration profile. Briefly, configuration profiles can be used to control many aspects of an iOS device’s configuration. They can enable features, disable features, and even hide applications from the user.
This is the tricky bit: Create a configuration profile that disables Safari, disables installation of applications, even disables iCloud backups, and adds a “READ ME” web page to the user’s home screen. Put a password on the profile, so the user has to enter the password in order to remove it. Now, you just need to convince the user to install the profile, and you can do that simply through email or SMS phishing. Once they install it, half their expected functionality suddenly goes away, and if they tap on the “READ ME” page, they’ll see the instructions as to how to pay ransom to receive the password to remove the profile. Win! (well, not for the user).
Now, fortunately, there are a couple of flags that (might) alert the user that something odd is happening. First, in the initial profile installation screen, is the list of contents, which includes “Profile Removal Password.” Similarly, tapping on “More Details” clarifies that this is a locked profile. Of course, if the email introducing the profile was written well enough, then the user might already expect and accept this. Hopefully we can train them not to. Also, if the user has a passcode on their device, then they have to enter their passcode as well, so it won’t simply install without the user noticing.
But what if they ignore all the warnings, and install the profile anyway? Well, all might not yet be lost. Turns out, the removal password is included in the profile, in plaintext. The attacker could choose to encrypt the profile, but to do that they need a public key from the target device, which might not be so easily acquired. So, assuming the profile is not encrypted, just pull down the .mobileconfig file from the original phishing email, open it up, and find the password.
Of course, the attacker could get really tricky, and serve up a file with a different password each time, placing some kind of key into the ransom notice (“Pay me $35 to remove this profile. Use the word ‘ostrich’ when you send me your bitcoins”) and then that key would be used to derive the actual removal password. If this is the case, then each time you hit the page you’d get something different, and so you wouldn’t be able to recover the correct password. In that case, the only real way to remove it is either to pay the ransom, or, if the device is jailbroken, get in and remove the profile directly from the filesystem.
In iOS 6.x, a new feature was introduced that can prevent the user from installing profiles. This feature is only available in Supervised Mode (via the Configurator application), however, and so isn’t of much use to the general population.
Want to hear more about configuration profiles and keeping your iOS devices secure? Come to my talk at SOURCE Boston next Thursday!
APKTool, make me a logcat sandwich
I recently turned a few friends on to Zed Shaw’s “learn python the hard way” course and it reminded me how bad of a programmer I can be. In fact, I’m that guy how litters his code with print statements. So it’s probably no shock then that a lot of times when I’m trying to figure out what’s going on in an Android app we’re reversing, that I’ll want to drop in some print statements. I use to do this by adding a few lines of smali directly into a class file, but there were a few things I needed to deal with for that to work how I wanted it. For example, here is what the default “debug” log call looks like in smali.
invoke-static {v0, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I
If you were going to drop this line into the code somewhere, you would need to make sure both v0 and v1 are Strings. I would typically want “v1″ to be the string I wanted logged out, and “v0″ (in this example) to be the log “Tag” value so I knew where I was in the code when it was dumped to the log (I may have a dozen or so values getting logged out, so this helps to keep things straight when you see them in the logs). Setting up this Tag string and not stomping on things sometimes meant I needed to increase the local variable count and add some more lines for setting the string and then making sure I got the register/variables correct in that previous logging line. This worked alright if it wasn’t too late in the night or I had enough caffeine in me, but I typically would screw something up and would end up recompiling a bunch of times. I wanted an easier way and something that could deal with logging out things that weren’t already strings.
Thus I created this simple class file I can drop into the root of any application (yes, this is not as good as a real debugger using JDWP, but sometimes doing things quick and dirty gets the job done quicker for me). I wanted to stay with Android log utility syntax, but simplified a few things. I overloaded the logging object’s “d” method so that it could take just about any variable type I was dealing with. One handy example of this is a byte arrays (which is often what we find decryption keys stored in). The wrapper in IGLogger will convert the byte array into a hex string and dump that to the logs. All you need to add is one statement to the code. If “v0″ contained a byte array we wanted printed out, just drop this line of code.
invoke-static {v0}, Liglogger;->d([B)I
Since “iglogger.smali” is in the root of the recompiled APK, we can statically invoke it from any other class in the project. In this case, we need to tell the “d” method v0 is a byte array “[B" and sticking with the standard Android logging utility class, we're returning an Integer (although I've thought about just making that a Void... I never check it). You may notice we're not passing a log Tag variable with this statement. IGLogger supports that if you want, but we've added a trick to IGLogger that I find works pretty well. In IGLogger, we'll create a new Throwable object, get the getStackTrace method to find out the last class and method we were in, and put that in our log Tag. If the APK is not obfuscated, this will even include a line number. This same trick allows for a very simple "hey, I got here and this is how" stack trace method to be dumped by placing this one line of code anywhere.
invoke-static {}, Liglogger;->d()I
You might have heard a lot of us here are fans of Virtuous Ten Studio for working with smali. I have a bunch of these IGLogger print statements in Extras->Smali->CodeSnippets. Makes it really simple to just click and drop in a log statement.
But that wasn’t good enough for Niko here when we had a massively huge app that was obfuscated. He talked me into automating the process of logging out each class and method that was entered so we could watch the logs and know what code paths were being taken. I ended up rolling this into a Python script I had written to “fix strings” in decompiled Android apps. You are probably aware that proper Android apps will have their strings placed into XML files so that it’s easier to internationalize the application. While this might be nice for developers, it means when we’re reversing an application, we may end up with some strange hex value instead of a readable string. “FixStrings.py” would loop through the decompiled code and add these strings back in as a comment tag when ever they showed up in the smali code. Your mileage may vary with how well this works, but in some apps, it helped us find things easier.
Adding on to that code base, I started to include some code to automatically add IGLogger statements around things I thought could be interesting. This includes a log statement after the “prologue” of any method. Also, any time we see two strings being compared, we’ll log both strings (this is always fun for watching a password being checked or when the app pulls up device info to see if it’s running on the right hardware). We plan to add a few more things for dumping Intent messages and URLs, but this is a start for now.
This of course will make the app run hella slow, fill up logcat, and in some cases break the application. I’ve tried to avoid that last one as best I can for now, but it is possible this script will massacre an APK so badly it will be unrunnable. If you run into that issue, you can turn off the lines that will add these automatic logging statements to the code (ie, JonestownThisAPK = False).
The last thing we added to the Python script was some searches to pull out info we may find interesting when assessing an APK file. We dump this into a file called “apk-ig-info.txt” and review it after decompiling the APK. Again, this is something we’re continuing to refine. You can find the code on the Intrepidus Group github repo:
https://github.com/intrepidusgroup/IGLogger
https://github.com/intrepidusgroup/APKSmash
Comments disabled
Armor for Your Android Apps – ShmooCon follow-up
Hopefully, everyone’s already decompressed from all the Shmoocon partying by now. I wanted to follow up on the IG Learner app that I presented during my “Armor for your Android Apps” talk and give out a couple of tips on how to approach cracking the challenges (which aren’t all that hard, really).
Before I dive into the meat of the lessons, I just wanted to point out that if you didn’t attend the conference but still want the app, you can get it from the Play Store:
https://play.google.com/store/apps/details?id=com.intrepidusgroup.learner
So, you’ve got everything installed and running. At this point you have two options – take the easiest way and hit the walkthrough or try to dig through the lessons yourself. I intended for the walkthrough to serve as a helper thing, but if you’d like to just use it to run through the whole thing, sure, that’s an option, too. The link to the walkthrough is provided at the end of this post.
In if you want to do it yourself but are not sure where to start, here’s a few general tips:
1. You will end up using Android SDK / Android monitor (monitor.bat) very heavily. I am guessing that by now you have that installed on your system anyway.
2. Use dex2jar (http://code.google.com/p/dex2jar/) to convert APK’s Dalvik executables (*.dex) into their Java representation – since the code is not obfuscated, this will really help you understand the logic of the lessons.
3. Apktool (http://code.google.com/p/dex2jar/) – this command-line utility lets you decompile APKs and recompile them back. You’ll definitely need this on a few occasions.
4. Jarsigner – comes with Java SDK, is necessary to install an app on an Android device. Read here about signing of APKs: http://developer.android.com/tools/publishing/app-signing.html
5. Virtuous Ten Studio (http://www.virtuous-ten-studio.com/) – Smali IDE, complete with syntax highlighting / automatic signing / APK upload. Awesomeness redefined. If you want to bypass 3) and 4) and not have to deal with it, go the VTS way. That said, I’d still recommend familiarizing yourself with the command line versions of the tools – just so that you understand better what’s happening behing the scenes.
6. Some knowledge of Java is definitely helpful for quick completion of challenges.
7. “adb shell pm list packages” gets you the list of packages installed on the phone. IG Learner is one of them.
Now, let’s go to some specific tips per lesson:
1. Lesson 1. This one is pretty self-explanatory. If you start the Android monitor and look at the log output, you’ll see the answer to the challenge. Easy as that.
2. Lesson 2. Convert the APK into Java and try to figure out the filename that’s being created. Another hint: default directory for Android app file storage is /data/data/<packagename>/files.
3. You can figure out what the URI scheme is just by looking at the lesson screen and requesting a URI. Now try to look through decompiled code (Either Smali or the Java representation) to figure out what the lesson is expecting. Also, pay attention to extra activities in the app.
4. You should use a local proxy to intercept application traffic (Burp Suite maybe?) Keep in mind that you can’t man in the middle SSL traffic unless the SSL certificate presented by the remote server is verified. And for that (at least, for Lesson 4) you need to update your trusted CA store with the signing certificate of your local proxy. Once you export that certificate (there are multiple ways to do it, using Internet Exporer’s certificate export wizard is one of them), you should be able to import into into the trusted CA store by placing it in the root of /sdcard and importing it through the Android’s Trusted Credentials menu.
5. This lesson is a bit trickier. For one of the ways to solve this, I suggest looking through the Smali code and finding the pin for https://www.intrepidusgroup.com SSL certificate that you can get by running Moxie Marlinspike’s pin.py script on our certificate. Then you can replace this with your own intercepting proxy certificate’s pin, recompile the app, and push it back to the phone. You’re good to go.
6. Hard-coded keys are awful. Seriously. When you’re playing around with symmetric encryption as you’re trying to find the correct value of the encrypted string, make sure that you convert that to Base64 for readable output. The logging facilities are there to help you.
The encryption can be done in less than 10 lines of Java code. If you’re struggling with that, check out our GitHub repository for a helper Java class.
7. Content providers are advertised in the Manifest. Mercury (http://labs.mwrinfosecurity.com/tools/2012/03/16/mercury/) is a great framework that lets you easily query those providers. This should be enough to successfully complete the challenge.
8. I’d recommend starting with decompilation of the app and looking at the Lesson8Activity. This may give you an idea of what the Intent handler is expecting. From there you can either download the Lesson8Aux app from the Play Store (https://play.google.com/store/apps/details?id=com.intrepidusgroup.lesson8auxapp), decompile it, modify it to throw the correct Intent to the application, or just use the “am” command to do just the same. Whichever is easier for you is fine, but I recommend going the auxiliary app way just to gain some more practice exercises decompiling and recompiling Smali code.
Oh, and yeah, the walkthrough (Huge thanks to our intern Nitin for putting it together!). Here it is:
Comments disabled
Evading evasi0n: iOS 6 Jailbreak Prevention
The latest iOS jailbreak was released yesterday. Called “evasi0n,” it can be used to bypass most all protections in iOS 6.1 on any device that supports it. It’s quite cool, and was certainly something I was looking forward to (since much of my work is greatly aided by working on a jailbroken device).
However, another part of my work is ensuring that our customers’ devices are as secure as they can be. And having an available jailbreak kind of weakens those assurances. So it might be useful to find a way to prevent the jailbreak from working.
And, it turns out, there might be such a way. At least, until the jailbreak team finds a workaround for the workaround.
Last March, Apple released the Configurator Application. Using this application, iOS devices can be put into a “Supervised” mode, strongly locks down many features. One of these features is the ability to connect to iTunes and do backups/restores. On a supervised device, this functionality is possible only from the machine designated as the device’s supervisor.
The evasi0n jailbreak just happens to depend on the iOS backup / restore channel. So much so, in fact, that this is what I got when I tried to jailbreak a supervised device:
Could the evasi0n authors work around this? Possibly. It depends on how deep the supervised mode controls are embedded within iOS. If the device requires a unique host key (from the supervising machine) in order to restore data to the iPad, then it could well be impossible to make evasi0n work on anything other than the actual supervising host.
Of course, putting a device in supervised mode isn’t for the faint of heart — it’s a major shift in how one configures and manages iOS devices. So this probably won’t be a “Jailbreak Stopper” for every major organization out there with large pools of iPads. But it might provide some additional comfort in small groups, like iPads checked out to executives, etc.
But couldn’t a user just remove the device from supervision? Yes, but that’s harder than it sounds. “Erase all Settings” won’t do it, and even “Erase all content and settings” (essentially, “wipe the device with extreme prejudice”) won’t kill the supervisory link. To make a device unsupervised, you need to connect it back to the supervising machine, and sever the link within Configurator. You should also be able to do it in iTunes by doing a full OS restore. In either case, however, all data on the device is wiped, so anything installed while in supervised mode would be lost prior to the jailbreak.
Bottom line: if your organization has iOS devices with sensitive information, and you’re concerned that this jailbreak might put data at risk, it might be worth checking out Configurator and putting some of your devices under supervised control.
[shameless plug: I'll be talking a little about this, and other ways to protect your data on iOS, at ShmooCon.]
UPDATE: Further thought should’ve made it obvious to me that forcing encrypted backups would have the same effect, and this is borne out in some simple testing. Of course, the user can’t be permitted to remove the encryption: so it needs to be forced through a configuration profile, preferably one that can’t be removed. If this setting is implemented through Mobile Device Mangaement, then the user could remove the device from MDM, disable encryption, jailbreak the device, and then re-enroll in MDM. So not entirely foolproof, but perhaps a more practical approach than shifting everyone to supervised mode.
Comments disabled
Unlocking NFC deadbolts with Androids
Program the EZon NFC lock to work with your Nexus
At Shmoocon this last year, there was a vendor who caught my eye with the Samsung SHS-3121 Digital Keypad Keyless Deadbolt “EZon” Lock. They endorsed the lock for the unique digital keypad, which randomly displays two extra digits that must entered before pressing the actual unlock code. A fairly nice way to ensure extra smudge prints on the keypad and even wearing. What got my attention though was the NFC cards which could also be used to unlock the deadbolt. At Shmoocon, I scanned the sample card with my Galaxy Nexus and realized it was a Mifare Classic card… with no protected sectors or data on it (not that it would have mattered too much since the Mifare Classic encryption can be fairly easily broken at this point). We ordered one for the office to play with even though there were some warnings that the RFID side of things might not have the best security.
I don’t want to turn this into a full product review (or video overview), but I’ll just focus on the NFC side of things. The lock ships with 5 branded “Access Cards” which are Mifare Classics. The lock only appears to be checking the 4 byte UID of the card and if the UID has been previously registered with the lock, it allows access. The UID is like a unique serial number for each card and should be impossible to change after the card is manufactured. None of the cards that are shipped with the lock are pre-registered, thus they must be manually added for access.
One thought of attack would be to similar to the HID card enumeration attacks (where if you know the ID from one card, it makes it pretty easy to find other values). Scanning the cards that were sent with the lock, the UIDs are not within close numerical range although some parts a similar (the UIDs were: 3e8700b1, be37feb0, eed2ffb0, fe2701b1, and… oops, I lost the last card). Additionally, the lock ships with brute-force detection enabled, which is refereed to as “prank” detection in the manual. Scan five invalid NFC cards in a row, the lock sounds an alarm and requires an administrator to unlock the device (or the door to be unlocked form the inside). Thumbs up for shipping with brute-force protection turned on by default. Unfortunately, we also noticed there’s a reset button hidden on the outside of the lock, so bring a paper clip and reset it after four attempts to avoid triggering the brute-force alarm and time-out.
That said, brute-forcing UIDs right now is a bit complicated. We haven’t seen a way to do this directly on a mobile device yet. A great whitepaper (PDF) on the current state of things was done by Michael Roland a few months ago. So while we can’t do this directly on our devices yet, we were able to purchase a knock-off “Mifare Classic” card from a contact in China which allows us to set the UID on a physical card using a non-standard command. At EUSecWest 2012, Max and I demonstrated using a Nexus S to read the UID off someone’s access card, then program onto this KIRF card in order to unlock the EZon.
So if you use one of these locks, you might want to keep your card in a shield when it’s not needed. However, you could also enroll your mobile phone to be your access key. This would then allow you to control when your card is active and when it is not. If you have an Android device that supports Google Wallet, you’re all set. The trick is to have Google Wallet installed with at least one “Loyalty Card” setup in the wallet, then make sure the card is enabled. Doing this enables NFC card emulation on your device which will present a UID to the EZon when it is within range. This type of card emulation is different from your payment information (so you don’t have to worry about the lock charging your bank account each time you unlock it). You can then enroll your phone just like a physical access card to the EZon and use your phone to unlock the device. The added benefit is that when your phone’s screen is turned off, card emulation is off as well which makes things a lot harder to tap and then clone.
~benn
Comments disabled
UltraReset – Bypassing NFC access control with your smartphone
We were just in Amsterdam to present our research on uses of NFC for physical access control. The two main industries we focused on were transit and hotel systems. Ever since Intrepidus got us Nexus S phones with NFC early last year, we’ve been looking for real world uses of NFC on our trips. We discovered the flaw with the SF Muni Ultralight cards last year on a trip there and followed up with informing them of the issue in December. At the time, we had to take the cards home and use an NFC reader connected to a laptop to do testing. Since then, things have changed; the Android API supports reading from and writing to most Mifare NFC cards, Ultralights included.
Some of the coverage of this has confused all NFC transit systems with those using the Mifare Ultralight cards incorrectly. In our presentation, we listed several cities that we know have NFC transit systems as an example of how widespread the technology is becoming. We listed two cities using Mifare Ultralight cards incorrectly that we have 1) tested and 2) contacted with remediation details.
For those of you that missed the video, we have it posted here: https://vimeo.com/49664045
UltraReset resetting an Ultralight transit card
This was a NJ Path 10 trip Ultralight card in the video. When we tap the card to the phone, our application reads all the data in pages 4 to 15 from the card and stores the data to the phone (we also store the card’s UID which we’ll write about more next week on hotel card issues). We then tap the card between two turn styles (which is why the count jumps by two). Once the 10 trips on card have been used up, touching it back to the phone causes the application to write the data back to the card. And with that, the card looks to be back in its original state when it was purchased with 10 rides remaining.
While these Ultralight cards don’t have access control features which are found in more expensive NFC cards, they do support a feature called a “One Way Counter” (which was named One Time Programmable or “OTP” in previous documents). These bits are in page 3 of the card’s data and once a bit is turned on, it can never be turned back off. This way, a card could be limited to being used only a limited number of times. These bits are left unchanged by the two transit systems we looked at which used Ultralight cards.
The one way counter (OTP) values of of the NJ Path card (top) and SF Muni (bottom). Neither system changes these bits when the card is used.
We know a number of cities are looking to roll out contactless technology and hope we can bring light to this issue so that it is implemented correctly in the future. One of the items we also raised in our talk is that full card emulation on smartphones is likely to happen soon. When this does, it could cause a number of NFC based access control systems to be re-evaluated.
If you think your system might be vulnerable to this issue, we have put an Android application in the Play store which will read and compare the one way counter (“OTP”) on Ultralight cards. Note, the standard cards that you might get from transit systems typically are not Ultralights. Ultralights are typically only used for “disposable” or “limited use” type tickets.
We have been reading lots of insightful comments on the articles we’ve seen. Please feel free to post questions or comments here and we will do our best to answer them (and no, we’re not planning to release the full UltraReset application). Last but not least, we would like to thank dragos and crew for having us at another one of the SecWest events — it’s always a great to catch up with folks in the industry and hear talks in the single track format. Thanks!
~Corey and Max
Comments disabled
Tracking Down the UDID Breach Source
I’d heard about the alleged FBI/Apple UDID leak shortly after arriving at work last Tuesday morning, and immediately downloaded and began reviewing the data. Less than an hour later, I’d surmised that comparing apps across multiple devices might help narrow down the source.
Several hours later, at 3:00, I saw a tweet from @Jack_Daniel suggesting that people checking their UDIDs in online forms only enter partial numbers . And that made me wonder: “How many digits is the minimum people need to enter in order to be guaranteed a unique result?” Sort to the rescue:
cat data | cut -c 2-7 | sort | uniq -c | more
This gave me a bunch of repeats. That’s not too surprising, as I’m only looking at 6 digits. Next up was 8 digits, and still I saw hundreds of repeats. Then I changed tactics and simply counted the number of unique UDIDs…and I came up with a number significantly different from the 1,000,001 that were released: 985,117. So there are almost 15,000 duplicates. Looking further, I saw that many of these duplicates have different device tokens, prompting a tweet, about 3:15:
Interesting. Just noticed there are UDID duplicates in that
data dump, with multiple APNS tokens. Different app providers,
or multiple regs?
About 45 minutes later, on my way home, @danimal suggested: “@DarthNull multiple apps? Seems like maybe a game or ad company.” I immediately thought, damn, that must be it. At 4:23 pm, I replied “Yes! makes sense.”
And two minutes after that, I found what seemed to be the source of the breach.
I had decided to look more closely at the most frequently repeated device IDs, on the theory that perhaps that would belong to a developer. They’d naturally test multiple apps for their company, each of which should have a different device token. So first, more shell magic:
cat data | cut -c 2-7 | sort | uniq -c | sort -n -r | head
Wow, some are repeated 10 or even 11 times!
11 4daa64abd
10 d1f575954
10 aa5c7aedb
8 12e6ec97e
7 f661c1396
7 4225e2a59
6 91a83b0e3
6 480074431
I searched for the first one, and found 11 different entries for a “Gary Miller.” Nothing much there. The next one, though, had some interesting device names:
'Bluetoad Support'
'Bluetoad Support'
'BT iPad WiFi'
'BT iPad WiFi'
'CSR iPad'
'Customer Service iPad'
'Developer iPad'
'Developer iPad'
'Hutch Hicken’s iPad'
'Hutch Hicken’s iPad'
Six different names, four repeated twice (implying at least a pair of apps and several users). Then I looked at the next entry, with 10 repeats: it’s variously named Robert, Red, and HP Pavilion. Meh. The entry, with 8 repeats: GoldPad. But the entry with 7 repeats really grabbed my attention:
'Bluetoad iPad'
'Bluetoad iPad'
'Client iPad BT'
'Client iPad BT'
'CSR/Marketing iPad'
'CSR/Marketing iPad'
'Jessica Aslanian’s iPad'
Support? Customer service? Developer? Marketing? A quick Google search revealed that, yes, BlueToad does develop iOS apps. In fact, they build magazine apps for many different publishers, and a quick trip through the iTunes store showed me that these applications use Push Notifications.
As this was the kids’ first day of school, we went out for a nice dinner to celebrate. While there, I thought more about what I’d found, and decided to roll the dice: I sent an email to BlueToad, using the email address on their website. I didn’t say much, just that there’d been a breach involving UDID and push tokens, and I’ve found some interesting data that suggest they may be involved. After returning home, I spent another four hours digging for more.
By the time I went to bed, I had identified nineteen different devices, each tied to BlueToad in some way. One, appearing four times, is twice named “Hutch” (their CIO), and twice named “Paul’s gift to Brad” (Paul being the first name of the CEO, and Brad being their Chief Creative Officer). I found iPhones and iPads belonging to their CEO, CIO, CCO, a customer service rep, the Director of Digital Services, the lead System Admin, and a Senior Developer.
This felt really significant. But as I started writing up my notes, doubt crept in. What are some other explanations? Perhaps everyone at the company uses a common suite of applications. Like the same timesheet app, for example. Then of course they’d all appear in the data. But even still, I couldn’t shake the feeling that I’m onto something.
I spent much of the next day writing a detailed analysis of the situation for our blog. Then, about 4:30, I drafted a follow-up message to BlueToad about what I’ve found, how I found it, and what I think it means. Also, I mentioned that though I’m reluctant to publicly name them without more solid data, it seems likely that others will also find their name in the dump.
Since I now have several more employee’s names, I spent some time looking for email addresses, to (hopefully) increase the chance of a response. While searching, I stumbled on a partial password dump for the company! And it was dated March 14, the same week that the hackers claimed they’d hacked into the FBI computer. Suddenly, I felt a lot more confident again, and I mentioned this connection in the email.
Shortly after 8:00 that evening, I heard from Hutch Hicken, their CIO. He thanked me for what I’ve done, and for my discretion in contacting them first rather than simply going public. He told me that they’re assessing the situation, but don’t yet know anything for certain. He didn’t think the March leak (which they’d already been aware of) was related, but that the rest of my findings were concerning. He told me they plan to “do this right,” he promised to keep me in the loop (as much as is feasible for a non-employee).
Most of the next day (Thursday), I didn’t really hear much. Then about 2:30 on Friday, Hutch called me again. Almost immediately, he told me that we can talk, but only if I agree to embargo the story until noon on Monday. My response was “Well, the fact that you’re asking me this tells me that I’ll want to say yes,” so naturally I agree.
I’m told that they’re confident the leak came from them, and he filled me in on some of the technical details (I’ll leave those details to others, to make sure I don’t make any mistakes). But they’re almost certain of their involvement, and are continuing to handle the situation.
Then he hit me with a big surprise: Kerry Sanders, a correspondent for NBC Nightly news in Miami, wants to interview me. On camera. He’s in the next room, and the phone gets passed to the reporter, and next thing I know we’re arranging an interview that night. He didn’t arrive at my house until 11:00 (his plane was delayed), and we spent 45 minutes talking about what I found, how I found it, the privacy implications of the breach, and other related topics.
By the time he left at midnight, I was exhausted. As I write this, I still don’t know how much of the interview he’s going to use, or even if it’s going to make it onto the air Monday night. Either way, it was certainly a surreal way to conclude what started out largely as another puzzle hunt.
I’m still not completely clear on all the technical details. Was BlueToad really the source of the breach? How did the data get to the FBI (if it really did at all)? Or is it possible this is just a secondary breach, not even related to the UDID leak, and it was just a coincidence that I noticed? Finally, why haven’t I noticed any of their applications in the (very few) lists of apps I’ve received?
Hopefully, I’ll learn the answers to many of these questions in the coming days. Either way, I’m glad to have been able to help, and offer my thanks to BlueToad for their cooperation, and their quick response.
UPDATE: Here’s the link for the NBC Nightly News post.
UPDATE: Timo Hetzel kindly corrected a misunderstanding that I had regarding how device tokens are created. I had believed that each application on a device had a different token, but that was in error — it’s a single device token for all apps on a device. So whenever I saw many tokens for a given device, that represented (in most cases) multiple refreshes of the same device. However, apps using the development “sandbox” Push Server receive a different token than what apps using the main production server receive, so seeing multiple devices from BlueToad, each with exactly two tokens for a given device name, further implicates the use of those devices by developers.
Android’s BuildConfig.DEBUG
Verbose logging in Android applications is both a problem we frequently see in production builds, as well as something we’ll try to enable if we’re pentesting an app. In revision 17 of Android’s SDK Tools and ADT, the release notes mentioned a feature which could help developers with this issue:
Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfig containing a DEBUG constant that is automatically set according to your build type. You can check the (BuildConfig.DEBUG) constant in your code to run debug-only functions such as outputting debug logs.
There appeared to be a few bugs in this working as expected in the original releases (Issue 297940), but that appears to have been worked out now. Running a few tests with revision 20, here’s an example of how it could be used and what it looks like in a built APK.
In our java code for our sample application, we included the following line:
if(BuildConfig.DEBUG){
Log.e("HelloJB", "I am in the Debug");
}
if(!BuildConfig.DEBUG){
Log.e("HelloJB", "I am NOT Debug");
}
Log.d("HelloJB", "Debug value is: " + BuildConfig.DEBUG);
We then cleaned, built, then exported our application as a signed package from Eclipse. As expected, logcat showed “I am NOT Debug” and “Debug value is: false”. However, decompiling the application using Dex2Jar showed that these values had been set at build time and not simply at execution. With the new update, the Dex2Jar output for those several lines was now just two:
Log.e("HelloJB", "I am NOT Debug");
Log.d("HelloJB", "Debug value is: false");
This looks like a pretty clean way to strip out any code you don’t want making it into your release builds (an issue we’ve seen many times in assessments).
Now for pentesters of Android applications, we often look to enable verbose application logging. I will typically look for a debug flag in the application and try setting it to TRUE at run-time or by recompiling the application. If a developer uses this method to remove debug logging though, this means switching setting the DEBUG boolean to true in the BuildConfig class on a released application will probably not make a difference. Instead, look for an empty logging class and add back in calls to Android’s log methods. There’s a few ways to skin that cat, but often some well placed smali code will do the trick. For example, if you see an empty d method taking two strings, try dropping in the following line to see the debug messages again.
invoke-static {p0, p1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I
Comments disabled
Apple’s iOS Security Overview
In late May, Apple quietly published a document entitled, simply, iOS Security. This short whitepaper describes several aspects of security within their iPad, iPhone, and iPod touch ecosystem, providing a high-level introduction to certain features and some fairly deep technical information for others. The stated goal is to help security-minded customers to better understand the core security features present in iOS. It’s definitely worth a read, but for now, let’s talk about some of the more interesting highlights.
It starts off describing the overall system architecture, from the boot ROM (including a public key used to validate system software) though the Low Level Bootloader and into the kernel and application layers. Executable code at all layers, including OS, Apple, and third-party applications, is signed, and the signatures are validated before the code is run. These checks help to keep malicious code from affecting the system.
Also described are some of the runtime security features. The core feature here is application sandboxing, where each application is limited in where it can write data, and prevented from accessing other application’s data or code. To share information with other applications, developers need to communicate through iOS APIs or services. Another noteworthy mention is that the core operating system partition is mounted read-only, further limiting the ability of a malicious program to attack the device.
Probably the most interesting section of this document details the Encryption and Data Protection features of iOS. Much of this is not new, having been detailed at WWDC conferences and in other devleoper documentation (not to mention several talks by prominent security researchers), but having it in a single, easily-accessible format is a welcome improvement.
The use of hardware-level AES-256 cryptography to provide full-disk encryption and a fast remote wipe capability is already well known, as is the use of a unique UID key embedded in each device’s hardware. What came as a surprise was the statement that this UID is not recorded by Apple or its suppliers, which means that keys (and data) protected using that UID cannot be decrypted by anyone not in possession of the target device (or, presumably, NSA-level supercomputers). Potential issues related to securely erasing stored keys from flash memory are also addressed with the Effecable Storage, where memory blocks are directly erased at a very low level.
Next up is a high-level description of file-based data protection attributes, which, when combined with a device passcode, provide application-level controls over data accessibility. The various protection classes are described, both for files and keychain entries, and it even provides a handy reference chart for system-level keychain entries like Wi-Fi passwords, email accounts, and private keys.
The data protection section finishes with a clear description of the four types of keybags in use on iOS: System, Backup, Escrow, and iCloud Backup keybags. In addition to the plain-English explantion of each keybag’s purpose (and location), the high-level structure of the keybag itself, along with protections for each key, is also given.
Two short sections, one describing Network Security features, and the other providing information on Configuration Profiles, device Restrictions, and MDM control, finish up the document, along with a short glossary.
Unfortunately, the whitepaper doesn’t have enough detail to serve as a reference for programmers or reverse engineers testing specific features. However, it is a great introduction to the complex collection of security features core to iOS. This should be required reading for enterprise-level security engineers and managers, whether contemplating future iOS support or hoping to better understand what they already have.
Comments disabled
