Category Archives: Conferences
Java Reflection in Android…FTW
I’ll be hitting a few smaller security conferences this spring (whatup BeaCon and BSidesROC) with a turbo talk on how Java reflection can be useful for accessing hidden APIs in Android. The team at Gibraltar had some great posts on this last year, but getting reflection to work for accessing the NfcAdapterExtras and NfcExecutionEnvironment classes was not as straight forward as things seemed. Here’s some tips on how to get it working (at least on an Gingerbread Nexus S).
First, you want to get familiar with the nfc_extras framework. This is not included in the standard Android SDK, but you can either pull the /system/framework/com.android.nfc_extras.jar file from a device or look at the Android source. You’ll see there are two classes: NfcAdapterExtras and NfcExecutionEnvironment. What I really wanted was in the embedded NfcExecutionEnvironment, but the proper way to get that object is from NfcAdapterExtras.getEmbeddedExecutionEnvironment(). So we’ll need to create that object and method first.
I decided to use reflection to access these classes in my own Android application. Since they’re not in the SDK, I couldn’t just “include android.nfc_extras.NFCAdapterExtras” in my code. Instead, we’ll just ask for that class by name at runtime.
String sReflectedClassName = "com.android.nfc_extras.NfcAdapterExtras";
Class cReflectedNFCExtras = Class.forName(sReflectedClassName);
Wow, that’s pretty easy. Except that we’re going to need to tell the Dalvik VM to load that additional nfc_extras framework so that it knows about that class. To do that, add the following after your application tag in the AndroidManifest.XML file of your application.
<uses-library android:name=”com.google.android.nfc_extras” android:required=”true” />
Now back to our “cReflectedNFCExtras” class. The first thing we’ll need to do is get the singleton NfcAdapterExtras. This is returned by the get(NfcAdapter paramNfcAdapter) method. Note that it takes an NfcAdpater as a parameter, so we have to specify the class for that when looking for this method. The following line should work for that.
Method mReflectedGet = cReflectedNFCExtras.getMethod("get", Class.forName("android.nfc.NfcAdapter"));
However, at first I had mistake in my code that cause this method not to be found (thank Jeremy for fixing this). So instead, I had looped through all the methods using getDeclaredMethods() and stopped when the “get” method we want was found. Here’s the code for doing that followed by invoking the method and passing it the default NFCAdapter which would be the next thing we’d want to do.
Object oReturnedNFCExtras = null;
Method mReflectedMethods[] = cReflectedNFCExtras.getDeclaredMethods();
for (int i = 0; i < mReflectedMethods.length; i++){
Log.d("NfcAdapterExtras METHOD:", mReflectedMethods[i].getName());
if(mReflectedMethods[i].getName().contentEquals("get")){
//Standard default NFCAdapter... need to pass this in to get back the singleton
NfcAdapter defaultAdapter = NfcAdapter.getDefaultAdapter(this);
oReturnedNFCExtras = mReflectedMethods[i].invoke(cReflectedNFCExtras, defaultAdapter);
}
}From here out, it’s smooth sailing as long as you take care of one more thing. Your application needs a special premission in order to use this framework, the one for “NFCEE_ADMIN“. The problem is this premission is declared with the protectionLevel of “signature” in the com.android.nfc3 package. There’s a few ways to get around this, but as far as I know, they’ll all require that you have root on the device. Thus, even though we’re using reflection to access these classes, Android’s permissions are still enforced. My way of dealing with this was to resign the com.android.nfc3 package with the same certificate I used to sign my newly created Android application, then adding the following line to my application’s AndroidManifest.xml
<uses-permission android:name=”com.android.nfc.permission.NFCEE_ADMIN” />
So there you go. We can now be NFCEE_ADMIN’s as well (on our own rooted devices) using reflection. I’m curious to try this out with other /system/framework packages as well. In most cases, the process should be more straight forward:
- Create a class using Class.forName(“package.class”)
- Find the method using getClass().getMethod(“method”, paramTypes)
- Then invoke the method with the proper parameters
Changes to Apple MDM for iOS 5.x
Last Saturday (January 28), I presented an updated talk on Apple’s iOS MDM system at ShmooCon 8. I had a great time, and really enjoyed all the questions and nice comments I received afterwards. I thought I’d mention a couple of the changes that iOS 5 provide.
First, the devices support some additional restrictions and controls. These controls should be available in most commercial MDM solutions, and can also be found in the iPhone Configuration Utility (IPCU). Among these new controls are the ability to:
- Disable Siri
- Selectively disable iCloud features: Backup, Document Sync, Photo Stream
- Reject SSL sites with untrusted certificates
- Prevent moving messages out of an email account into another
- Prevent use of an email account from 3rd party applications
Additions to the MDM service as a whole include:
- Ability to ask a device to “Check Out” when removed from MDM
- Installing and removing applications (custom and App Store apps)
- Listing managed applications
- Configuration of some settings (Voice and Data Roaming)
- Applying iTunes redemption codes to installation of apps (for Volume Purchase Plan)
I’ve updated my experimental MDM server to support most of these features. I’ve also added some better documentation for the server code, and scripts to help create the necessary server and CA certificates.
Slides from the presentation, as well as the code and the Black Hat white paper and slides, are all available at Github. Enjoy!
Shmootime: Shmoocon 2012
It’s time for one of our favorite security conference, Shmoocon. The Intrepidus Group will be there both on stage and in the booth (…and maybe in the hotel bar from time to time). If you’ve got a barcode, please drop by and say hello. The team has busy putting together a fairly crazy, yet shmooball free, booth for this year (apologies in advance to our neighbors). Just looking for the punching bag. We also plan to setup a tent and camp out in the Break It track where you can catch some of us (past and present) speaking.
Say hello to our booth babe
“Voight-Kampff’ing The BlackBerry PlayBook” at INFILTRATE 2012
Last week, we gave a talk at Immunity’s awesome INFILTRATE conference in Miami Beach, FL. Our presentation, “Voight-Kampff’ing The BlackBerry PlayBook”, discussed some of the black-box style, independent research we performed on the BlackBerry PlayBook. Although some content was similar to our PlayBook talk at SecTor 2011, there were some very notable additions. In particular, we discussed reverse engineering of PlayBook firmware images; flaws in authorization of AppWorld downloads; and exposure of an authorization token used for BlackBerry Bridge (the PlayBook’s PIM and email sync component).
The lattermost point has stirred up a bit of press post-INFILTRATE, so we’d like to clarify a few things:
1. The exposure of the authorization token is facilitated by a bug in the Persistent Publish/Subscribe (PPS) facility of the QNX operating system. This bug causes the contents of otherwise-inaccessible files to be readable from a special file in the same directory. RIM was made aware of this PPS bug as a result of our SecTor talk, as well as notification from others, and again by us prior to INFILTRATE (with special emphasis on disclosure of the Bridge token) — they have fixed this PPS bug in Tablet OS 2.0 (beta).
2. This token exposure effectively renders the BlackBerry handset password moot. The exposed authorization token is accessible after the user has “unlocked” BlackBerry Bridge (where “unlocking” would entail entering the paired BlackBerry device’s password if one is set). Unlocking Bridge is an expected behavior/process for Bridge users. After all, if you’re using Bridge on your device, you’re going to do this. In the case where a BB handset password has not been set, a malicious actor could just request this token from the Bridge service directly.
3. This isn’t “sniffing”. Some highly misinformed comments on news articles have suggested things like “a bad guy would have to be within 10 meters to exploit this.” This issue is not, I repeat not related to Bluetooth (which is used by BlackBerry Bridge). As an aside, despite the title of the article, threatpost has one of the best (press) write-ups so far.
4. The pervasiveness of malicious mobile applications exacerbates this flaw. Unless you’ve been living under a rock, you know that even “savvy” users are frequently duped by seemingly legitimate applications which later turn out to be doing Bad Things. The downplaying of this as an attack vector is nonsense, and the “if dumb users install malicious apps, they deserve whatever’s coming to them” argument is silly. Note that client-side browser or document reader vulnerability could even render this vector moot in the end.
In upcoming posts, we’ll dive a bit deeper into the meat of our research, so stay tuned. For those interested, we have posted the slides at SlideShare, and uploaded some initial code to the Intrepidus Group GitHub page.
OWASP Mobile – Top 10 Risks at AppSec USA
As one of the project leaders for the OWASP Mobile Security Project, it behooved me to help present, nay unveil the Release Candidate of the OWASP Top 10 Mobile Risks at OWASP AppSec USA 2011. Along with two of the other project leaders — Jack Mannino, of nVisium Security, and Mike Zusman, of Carve Systems — we discussed the general goals of the OWASP Mobile Security Project, its history, and finally the Top 10 Risks themselves. For each entry, we tried to provide an example of bad design or insecure coding practice that would give rise to such a risk, and/or a real world news story resultant of the associated risk item. We received great feedback from attendees, and it seemed some were very charged and passionate about the “top 10″ presented there. As mentioned in the slide deck, there is a 60-day window (from the unveiling) in which the RC Top 10 can be refuted or changed before we push it up to “Final” (that window ends on November 22).
The slide deck is available over at SlideShare.
We encourage anyone who’s interested to get involved in the OWASP Mobile Security Project (visit the OWASP wiki for information on mailing lists and other ways to help). With the Top 10 Risks and Top 10 Controls finally seeing the light of day, we’ve made some headway, but we’ve still got a long way to go.
BlackHat 2011 and Defcon 19 Summary: MXS9000 Style
We’re all getting back from BlackHat and Defcon now, despite some weather delays and red-eyes, I think everyone had a blast again this year. First off, a big thanks to the Rio for hosting DC and putting up with some shenanigans: there were rumors of rogue cell towers, some definitely unsafe wifi, and elevators mysteriously ended up in “inspection” mode (I had to walk 30 flights down one night! /me shakes his fist). The venue was great (I think everyone appreciated the change in scenery) and the tracks were pretty well organized. My only complaint: CRT TVs? Still?
I really want to thank the FNGs for their valiant effort to misinterpret my list: “re-usable bowl“, “re-usable spoon”, “tube of sunscreen”:
There were some really interesting talks at both BH and DC. In particular, “Reviving SmartCard Analysis”, by Karsten Nohl and Chris Tarnovsky was awesome — Nohl was one of the guys who broke the Mifare Classic by grinding down the chip and looking at the gates to figure out Mifare’s Crypto-1 algorithm. For those of you who aren’t familiar with smartcards, they are essentially a full computing system, complete with a processor, ROM, RAM, and supplementary processors, scaled down onto one chip. In this presentation, the researchers went through some of the previous attacks on smartcards. In early revisions, it was possible to use a microscope to read out memory on the chip. Once that memory was encrypted, attackers began capturing data by putting tiny pins into the wires between the decryption centers and the processor. In newer smartcards, those wires are protected by a mesh, making it far more difficult to read data from that area. Still newer smartcards will hide decryption within the CPU. Nohl and Tarnovsky revealed several design weaknesses in some modern chips — in an unnamed chip, the key was stored right next to the encrypted data in ROM; the baseband processor has unencrypted memory; substantial portions of the bootloader are unencrypted; also, everything sent to on-chip peripherals is in the clear (the wires themselves can be scrambled, but on an 8 bit chip there are only so many possible orders). My favorite part of this talk was degate, a software tool for reverse engineering gate logic from images (the researchers plugged siliconzoo.org if you’re like me and can’t tell the difference between an AND gate and an XOR etched in silicon, or any other logic circuit for that matter).
Also — thank you to Immunity and BlackHat for hosting and sponsoring another great HackCup. It was a little more popular this year with 12 teams competing. Unfortunately, the initial round was only two 15 minute games and Goal++ suffered defeat in both (5-4 and, well, we won’t mention the second game). We’ll be back next year with a leaner, meaner, and more coordinated team. Watch out, Brazil. Pics to follow, as soon as Zach gets his camera back.
That’s it from me. Hope to see you all again next year at BH/DC.
-mxs9000
Inside Apple’s MDM Black Box — Black Hat USA 2011
Since joining Intrepidus Group, I’ve spent a good deal of time helping to assess risk and craft security guidelines for iOS devices in large enterprises. A major factor in securing iStuff in the enterprise relies upon the use of Mobile Device Management technology (MDM). MDM has been around for a while, especially for some of the older, more corporately-established mobile devices (like BlackBerry or Windows Mobile). Last summer, though, Apple jumped into the arena, adding support for their devices as part of iOS 4.0.
Unfortunately, the way that MDM works for iOS hasn’t been very well described, publicly. Which makes it difficult when you’re trying to demonstrate to a customer that it will make their enviroment more secure.
So I set about doing everything I could to understand, at a deep, technical level, exactly how the technology worked. We were already pretty satisifed, abstractly, with the features and capabilities of Apple’s MDM, but we felt it necessary to go that extra step to truly know what it’s doing. The end result of this is that we now have a mostly-complete understanding of how the protocol works.
If you’re coming to Black Hat next week, you’ll have a chance to see me talk about all of this in person. I start with how iOS settings work, move into additional features available through the iPhone Configuration Utility, and then start talking about MDM. The talk shows in detail how MDM uses the Apple Push Notification Service, and describes the message format used to make that notification. It’ll also document the interaction between device and server, from authentication and enrollment to receiving commands and providing responses. Enough detail is provided to enable you to write your own experimental MDM server (or, you could simply use the one I’ll be releasing at the talk).
Finally, I’ll talk about some limitations and weaknesses I’ve uncovered, and their potential security ramifications. There might even be a surprise for those hardy enough to sit through the whole talk.
There will even be live demos. 
This is going to be quite the experience for me. If your work involves securing iOS devices, especially at the enterprise level, please drop by and give a listen. If you can’t make it, check back here after the conference — I hope to write up some of the more interesting bits of the talk for a standalone post, and we should also have the slides, white paper, and source code available for download at some point.
See you in Vegas!
-david.
Android NFC data forensics – More fun with SQLite
The other week I made it out to the NYC4SEC meetup to speak about NFC. It was my first time going, and I found the group to be a very creative bunch. We had a good time speculating on the Google Wallet announcement coming the following day, and I had been reading that a number of the attendees would come from a forensics background. This got me wondering about what NFC data could be recovered from a Nexus S.
To start, both reading an NFC tag or initiating an NFC LLCP connection will cause intent messages (and often some debug messages) to show up in the Android log buffers. However, this information isn’t written to disk and thus will not be persistent if the device is rebooted. It does not appear that there’s a global, system-wide way that NFC information is logged; but that’s not to say some common NFC applications won’t log this data.
Lets look at the default Google “Tags” application, which will handle NFC tags by default (if no other applications have registered intent-filters for them). Stored application data will be in the application’s /data/data/com.google.android.tag directory. In there, the databases directory contains a “tags.db” sqlite3 database. This database has a table named “ndef_msgs” which appears to store a copy of every NDEF message which made it to this application. This appears to go back to the first tag that we ever scanned with the phone (curse you Touch-A-Tag and your write locked ultralights). This table includes a timestamp in the “date” field, a human readable string in the “title” field, and then the full NDEF message in the bytes field. If you view the bytes data in a hex-editor, you’ll see the NDEF headers data structures as defined by the NFC-Forum.
Data in the Tags.db sqlite3 database
One important thing that is not recorded is the UID of the tag which is scanned. The UID is relatively unique and would go a long way to saying a particular physical tag was scanned at the time recorded in the database. Especially when you consider how these tags are envisioned to be used, posted in a static location where you need to be within 2 centimeters away from. If the UID was recorded with the timestamp and data, this might have become yet another database tracking privacy issue. I’ll leave it to the comments section of this post to discuss the current implementation’s privacy concerns but, outside of a factory reset, there doesn’t appear to be GUI option to clear this data.
I also took a quick look at both the NXP TagWriter and Farebot application. Both have similar databases in their application directories with some exceptions. The NXP database (/data/data/com.nxp.nfc.tagwriter/databases/taghistory.db) appears to only recorder the last 10 tags written. This matches up with the “History size” option in the application’s settings menu. The Farebot database file (/data/data/com.codebutler.farebot/databases/cards.db) does appear to record the UID of the tag scanned and an XML encoded version of the full information which was able to be read from the tag (sector data, access rights, etc). There is a “created_at” field, which one would assume is for the time-stamp; however, this does not appeared to be populated in any of the records on my device.
If you’re interested in getting to know more about NFC and security issues, join us for a webcast on June 16th. We’re calling it “NFC for n00bs”, so in that vain, leave the suits and ties at home for this one and expect a few bad football puns and screen shots of hex-editors.
IG in the WWDC
Made it out to California this week for Apple’s WWDC event. Apple has an interesting view on conferences and how that word relates to non-disclosure, so I’m going to stick with things from the keynote and pictures from others sites in this post.
If you’re looking for security features in the keynote, the summary slides at the end of the OSX and iOS sections are the ones I think will give the most insights (Apple’s keynote video is now online, or you can see stills on the TUAW or Gizmodo site among others).
On the Lion side of things, FileVaut 2 is obviously going to be of interest (and AirDrop got a lot of people chatting about what’s going on behind the scenes). In terms of iOS security, these ones jumped out at me: “Mass Configuration”, “Automatic Reference Counting”, and of course “Data protection for Core Data”. We’ll see what the week brings on those. So far, no signs of NFC getting any love out here.
Hijacking NFC Intents on Android
Google IO had a “How to NFC” session today where they demoed and described using NFC on Android. One of the items they pointed out was the desire to use NFC for instant gratification and zero-click interactions. The only default application on the Nexus S that I’ve seen this in before today was Google Maps, but the desire is that other applications will incorporate this feature as well. In the future, we may see a banking app that launches when the phone is touched to a particular NFC/NDEF message tag and not require the user to click anything.
To see how this could work right now on a Nexus S, take a Mifare tag and write to it an NDEF message with a URL to ”http://maps.google.com/“. When the device reads the tag, the standard NFC Tags application requiring user interaction will NOT be triggered. Instead it will automatically trigger Google Maps on the phone. This is done with specialized intent-filters. O’Reilly has been on the NFC ball and has a great write-upand flow chart about how Android figures out what actions to take when a new NFC tag/NDEF message is detected. It is well worth the read if you are planning on using NFC tags with your application.
To see how this works, pull out the AndroidManifest.xml file from the Google Maps application on the Nexus S, you’ll see a number of URLs registered for the “android.nfc.action.NDEF_DISCOVERED” action. These are intent-filters, which don’t require any special permission, nor present any type of prompt to the user when installed. So what if we wanted to create a competitor to Google’s Map application and register for these same intents? What if this was a banking app and the tags triggered the start of a transaction? Nothing currently stops our app from also creating these intent-filters, so lets see what that could look like.
We created a quick “Angry Birds New Jersey” application with some special intent filters in the manifest for our presentation at B-Sides Rochester last weekend. When the user installs what appears to be a game application, it will also silently register to receive the same intents which would launch Google Maps. Here’s a sample of the intent-filters for that:
Intent-Filters for NDEF_DISCOVERED
Now when a user scans a NFC tag with a maps URL, a menu choice will pop up asking the user to choose which application should handle the intent. The challenge becomes getting the user to send the information to our application instead of the office application. The intent-filters include two handy settings for this. First you can customize the “label” that will appear on the popup list. So instead of our normal installed application name “Angry Birds New Jersey” showing up, we can call it “Google Maps”. We can also set the icon that will be displayed. So again, instead of showing the game icon, we can use an image that people already associate with Google. If you had to choose between these two apps, which one would you click on?
Google Maps or Maps... which is the real application?
I’m not sure most users would know the first one on that list was the from the bird game we installed and not the offical Google Maps application. There might not be too much risk here hijacking a map URL, but its something I would encourage developers to think about with their data and tags.
UPDATE 11/18/2011
There is now a way to protect against this when writing your data to NFC tags, if your application is running on Android 4.0 (or probably later as well). The protection is being called Android Application Record (AAR). Click here for our full POST on the feature.
~benn
