Author Archives: benn
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
Android Backdoor Fail – The Kindle Fire Easter Egg
Happy New Year! And for all you Kindle Fire owners, happy early Easter as well. TeamAndIRC released their code and write-up for BurritoRoot which restores root level ADB access on the Kindle Fire. There were other ways to root the Fire before the latest update from Amazon, but this one is attention deserving because of how blatantly the developers left this back door wide open.
You can follow along even without a Fire by grabbing the 6.2.1 software update from Amazon’s site. Download the “bin” file, extract it, then find the “service.jar” framework file. This jar will be in the Android format, so to view this in jd-gui, you’ll want to convert it first (dex2jar works well).
Besides the standard com.android.server package you would expect to see in the service framework file, you’ll also notice there’s a “com.lab126.services” package (Lab126 appears to have done work for a number of Kindle releases). At that point, it’s pretty hard to ignore a class called “EasterEggReceiver”. There’s not much to this class and nothing has been obfuscated to make it hard to follow. Any application which broadcasts an intent message to the “com.amazon.internal.E_COMMAND” service with the correct extra data can enable the ADB daemon to restart as root. No permissions are needed to send that intent and there are no checks in the framework to see who sent the intent message (like maybe try to limit this to only apps with a certain signature) — simply any Android app on the device can call this backdoor feature.
Dex2Jar view of Kindle Fire's Services framework file
The means of data passing and the severity of this “feature” are different from the HTCLoggers.apk issue from October of last year, but I think they are both signs of the same trend. Mobile developers writing any sort of inter-process communication call or service need to ensure they are communicating only with other trusted apps. Android already gives you a way to do this, if your apps are signed with the same certificate. I’m a fan of Easter Eggs, but sometimes you want to make sure to limit who can walk away with your tasty burrito.
Man-in-the-Middle (MiTM) and certificate setup on Android 4.0
The Nexus Galaxy and Android’s Ice Cream Sandwich (ICS) are finally here. If you’ve done Android application testing in the past, you’ve probably have tried to install your own Certificate Authority (CA) cert on to an Android device or emulator. This process was somewhat painful and required root level access on physical devices. We have an old blog post here on that process, but that all changes now with ICS.
Installing a certificate can now be done in the Settings->Security menu of an Android 4.0 device and handled in the “Credential Storage” section. This does not require the device to be rooted (at least on the builds we’ve seen so far). The “Trusted Credentials” setting will list both the system wide installed certificates as well as any user added ones. An additional feature is now with a few simple clicks, the end user can disable any CA certificate on their device. Is your vendor still hanging with DigiNotar? Now you can disable that yourself without having to pull files from the device. Just click on the certificate, scroll down to the bottom of the pop-up message, then click the “Disable” button on the right.
Android 4.0 Credential Storage menu
Installing your own certificate is almost as easy. Here was my process. I needed the CA cert I generated in Mallory loaded onto to my Nexus. Mallory creates a unique CA certificate per-installation and stores it in Mallory’s “ca” directory. To move this onto the phone, I started up Python’s SimpleHTTPServer in that directory.
~/mallory/current/src/ca$ python -m SimpleHTTPServer
Now on the phone, I pointed the browser to that server on port 8000 in order to download the “ca.cer” file (adjust your IP address/port/filename as necessary).
http://192.168.90.1:8000/ca.cer
On my device, this dropped the CA certificate to the SD card. Back in Settings->Security screen, find the “Install from storage” option. Click that and your “ca.cer” file gets loaded into the “Trusted Credentials” store under the “User” tab. No bouncing castles or root needed. This will require you to set a passcode on your device (if there is not one already). Face unlock doesn’t appear to cut it just yet.
Mallory's CA Cert loaded on the device
~benn
NFC Intent Filters in Android 4.0 – Don’t forget the AAR
If you were developing a NFC application on Gingerbread for Android and were using intent filters, you had to be concerned about other applications on the device trying to intercept those intent messages. We did a blog post about this in May titled “Hijacking NFC Intents on Android“. Well with Ice Cream Sandwich, you now have a new NDEF record which you can add to specify that your app should handle the NFC intent (and if your app isn’t installed, the user should then get prompted to download it from the market). This new tag is being called an Android Application Record (AAR).
In our past blog example, if you were writing your NDEF message using an application on Android, you would want to include a second NDEF record into your NDEF message. Here’s how that code would look:
NdefMessage msg = new NdefMessage(
new NdefRecord[] { rtdUriRecord, NdefRecord.createApplicationRecord(“com.google.android.apps.maps”) });
Google has a good example of a full “Beam” application which supports AAR in the latest SDK (or you can view it online here). You’ll see the AAR is commented out in the code example, but you get the picture. This ends up being a great compromise for developers creating NFC applications. If you want to leave around generic NFC tags where it doesn’t matter what application handles the data, you don’t need to change a thing. However, if you need to launch a particular app, include one extra record. We’re not sure how well this will carry over to other platforms besides Android, but at least for now, our Blackberry Bold 9930 with NFC just ignores the extra NDEF record and handles the URL in the tag as expected.
Now the rest of this post is just so we can geek out about what an AAR actually is when written to a tag. We used an Ultralight-C and then read the tag data with libnfc. Here’s a screenshot of the values.
We’ve highlighted the AAR information. This appears to be using a Text Record Type Definition which follows the RTD external name format. If I’m reading the specs right, here’s what some of those values mean:
54 – RTD_TEXT
0F – Length of EXT tag (“android.com:pkg”)
1C – Length of Text data (“com.google.android.apps.maps”)
After that is our ASCII values for that record until our end of NDEF message marker “FE” (you can also see the Well Known URI record in the tag before the AAR data).
~benn
A Brave New Wallet – First look at decompiling Google Wallet
For the record, I welcome our new contactless payment overlords. I truly see the value in having the ability to make a payment transaction with our mobile devices. This opens up an opportunity to make these transactions more secure, give customers a better user experience, and also give them more control over payment options. Sure there are risks involved with this new technology and everyone should do their own weighing of the risk versus benefits, but I imagine a good number of you already have done this with deciding to use a current payment system over cash (or gold). However, a first (and rather quick as I’m supposed to be on vacation) look at the new Google Wallet code makes me wonder if this first release might need a bit of polish.
If you would like to follow along even without a Nexus S 4G, you can grab the new over-the-air (OTA) update from Google here. You can find the main parts of the new Wallet application in the “\system\app” directory of the update, but it will need some deodexing.
I typically start going through an app with the AndroidManifest.xml file. One thing that jumped out at me with the six “debug” and five “fakes” activities listed in the manifest. As a general best practice, debugging code should be removed from production releases. However, you do have to appreciate the humor of the “BsBankManagerActivity”. Yup, sign up with “BS” bank by calling “6501111111″ or visiting “http://bsbank.com” (BS Bank heard there was a BEAST breaking TLS this week, so they dropped it). Going through the BS code leads to some more fun “bsness” later on as well, such the revelation that “something is seriously wrong with this image URL” (which they were working on back in January?)
Additionally, there’s a handful of test related phone numbers left in “DebugMenuHelper” and “DemoDataPopulator”. Here they are in the format found:
4155589991
(415) 626-9682
(510) 351-0108
You will notice there are a few obfuscated classes in the wallet application. These appear to be related to the OTA proxy parts of the application. While not extremely complex in its functionality, I do think it’s appropriate to obfuscate this. Unfortunately, it appears that a great deal of logging can take place here and the default level is set to “FULL_LOGGING” (although it appears this level can be dynamically changed).
We haven’t yet seen what data gets logged by this, but the obvious concern would be a malicious log reading application as described over a year ago by the Lookout team. There also appears code that will send some log messages to “gtec.skcc@gmail.com“.
Continuing with the testing related code in the production application, lets pull out the number of test/demo/uat URLs (which don’t seem totally bogus but still could be). “CodeConfiguration” has a number of these:
private static final DEFAULT_CITI_SOAP_URL_CAT:Ljava/lang/String; = https://systemtest.citibankonline.citibank.com/MSMOTA Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalization ServicePortTypeEndpoint1
private static final DEFAULT_CITI_SOAP_URL_DEMO:Ljava/lang/String; = https://systemtest.citibankonline.citibank.com/MSMOTA Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTA PersonalizationServicePortTypeEndpoint1
private static final DEFAULT_CITI_SOAP_URL_PROD:Ljava/lang/String; = https://test.mobileservices.accountonline.com/MSMOTAPersonalization_ FUT/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalizationServicePortTypeEndpoint1
private static final DEFAULT_FDCML_PROD_URL:Ljava/lang/String; = "https://www.fdmobileservices.com/mAccountsWeb/MbankingService"
private static final DEFAULT_FDCML_TEST_URL:Ljava/lang/String; = "https://cat.fdmobileservices.com/mAccountsWeb/MbankingService"
private static final DEFAULT_TSM_URL_CAT:Ljava/lang/String; = "https://uat.skcctsm.com:8443"
private static final DEFAULT_TSM_URL_PROD:Ljava/lang/String; = "https://pip.skcctsm.com:8443"
const-string v1, "DEVELOPMENT"
const-string v2, "https://jmt0.google.com/cm"
const-string v1, "SANDBOX"
const-string v2, "https://cream.sandbox.google.com"
const-string v1, "PROD"
const-string v2, "https://clients5.google.com/cm"
Finally, with each point release of Gingerbread (2.3) we’ve see code around the NFC components changing greatly. Generally adding new functionality, but at times deprecating older ones. In the wallet code, there appears to be over 50 classes with at least one deprecated method.
I’m sure many others are looking at this code as well and have some intersting finds. We are looking forward to making a payment soon with our Nexus S. Maybe we’ll use it to buy a pair of shoes.
Update 11/18/2011
Its been a while now and there’s been quite a bit of good work on Google Wallet done on XDA Developers. To clear a few things up, the email address appears to be for Android Cloud to Device Messaging (C2DM) and a lot of the debug code was removed from the wallet updates which have been pushed. That said, you can flip on the “Debug” menu in the orginal code. If you want to get this to run on a device though, you’ll need to resign a few other packages or fix permissions.
-b3nn
USRP 101: Unlocking Wireless PC Locks (and freeing dolphins)
Wireless PC Proximity Lock
Have you ever seen one of these “USB Proximity PC Locks” before and thought “There’s NO way that piece of junk is secure”… turns out, you were right.
We had a little office challange recently to break this system, just for fun, and along the way document our Universal Software Radio Peripheral (USRP) which I’m still just starting to get to know. By now, I figure most of our readers would be familiar with the OpenBTS Project which uses an USRP to impersonate a GSM base-station. While this is an impressive use of the hardware at a fraction of the cost of a comercial base-station, the USRP can also be used to impersonate less functional and almost worthless priceless equipment… like that USB proximity lock.
First things first, we need to get one of these locks ourselves. Surprisingly, I got one of these as a gift from ThinkGeek years ago and you can still find them on eBay and a few other sites. I was missing the drivers for mine, but you can still find a copy online. I installed it in an XP virtual machine and paired the remote with the USB dongle. Now anytime the remote was powered down or more than 30 feet away, the lock screen with these pretty dolphins was displayed.
Wireless Lock "lock" screen on XP
What I needed to know next was the approximate frequency. which the remote used to send data to the dongle and unlock the computer. My goal was to capture this transmission with the USRP, then replay the signal when the remote was turned off or out of range. Unfortunately the documentation that came with the wireless lock was pretty silent on what it used to do this. Given the device is so old, I doubted it would use BlueTooth, so I started to look through the installed application files for clues. The application is sold to be re-branded by many companies, but the string “Copyright (C) 2003 Dritek System Inc” in the HIDRead.dll seems to point to the actual manufacture. The USB dongle installed as a HID device under Windows, but the driver does not appear to say anything about the frequency which the dongle and the remote communicate. Neither does the documentation with the driver nor the PDFs I found online. However, one EBay post did contain an image of the back packaging which seems to have “FCC 434Mhz”. This matches the unlicensed spectrum that is commonly used for remote keyless car unlocking and garage doors.
This was also backed up when the remote device was taken apart. There are 2 main chips on the remote I was interested in, one labeled “NDR 550″ and the other “MDT10P55B1S”. Some surfing around leads to the NDR550 being from “Najing Electronic Devices Institute” which list this as a One Port Resonator which operates at 433.92 Mhz. Also looking at the remote’s PCB near the battery there are markings “315″ and “434″. Mine had a blue pen marks next to the “434″ text which falls within the range of the WBX board in our USRP.
Wireless PC Lock Remote
Using the GNU Radio spectrum analyzer around the 433.92Mhz frequency with our USRP N210, we do in fact receive a signal when the unlock remote is powered up and transmitting. The “uhd_fft.py” script comes with GNURadio UHD package. While the GUI was a bit unstable on my system, command line parameters worked well.
uhd_fft.py -f 433.9M -A TX/RX
USRP FFT
The next step was to capture the signal coming from the remote to the dongle. While far from stealthy, the Log Periodic antenna we had from WA5VJB works for 400-1000MHz ranges. So with a bit of gain tweaking and proper timing, we were able to snag a good complex capture of the signal out of the air. Again, GNU Radio makes this easy with the “uhd_rx_cfile.py” script.
uhd_rx_cfile.py -f 433.9M -A TX/RX -g 35 outfile.dump
Then it was time to replay the signal. To do this, we wrote a GNU Radio Companion (GRC) file. I’d recommend looking at the OZ9AEC GRC examples if you’re new to GRC and have a UHD device like our N210. However, this replay script was so easy you could basically point and click to get it working. You’ll need just one source (something that will generate a signal in this case) and one sink (something to transmit the signal). The source was the file we had just captured which we sent to the UHD: USRP Sink. Set the sample rate to match that of the capture (default 1M), the center frequency (433.9 MHz in this case), and adjust the gain depending on your antenna and range. We set the file sink to repeat so running the script would continuously replay the unlock command to the dongle. From there, simply execute the script and watch the PC unlock (Go free my dolphin friends!)
GRC Transmit from File
We also looked at unlocking the system using a Teensy USB development board as a fake dongle (Sid, I want my Teensy back!). We plan to have a follow up post on that, but if you start looking though the registry and configuration settings for this wireless lock, you’ll notice some data looks strange. The “SqrtyKey.Cfg” file and HKLM\SOFTWARE\KeyMark\Wireless PC Lock\Password Answer registry setting are encoded with a transposition cipher. It shouldn’t take you long to figure out the pattern, so once you have, you can use the python script below to save you some decoding time. [download id="271" format="2"] (update: link should now work) (update 2: the maddman posted an awesome clean up of the script for Python 3 here)
So there you have it. Want to defeat a $20 wireless PC lock? All you have to do is spend $2500 on USRP hardware 
~Corey and Max
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
Pulling and finding APKs without root on Android
A number of us attended the NY/NJ OWASP meeting last night in New York. It featured great talks from Brad Antoniewicz on proximity card cloning and Jason Rouse on mobile pen-testing. Hats off to Jason who got crazy and donned one of our luchadora masks for his section on Android app testing. Nacho was proud.
The talked reminded me of a simple Android trick that I find people often aren’t aware of. From time to time (although increasingly more rare) we have an non-rooted Android device that we need to pull an APK file from. Since we’re not root, we can’t list the /data/app directory to locate the name of the APK file we want to pull. There’s a few ways you can tackle finding the name of the APK file, but what I find is the quickest way for me is to pull the packages.xml file.
adb pull /data/system/packages.xml
As the name indicates, this is an XML file of all the packages installed on the device (both system apps and user installed apps). A quick grep of a key word you think is in the package name should pull back the information you’re looking for with a “codePath” attribute that will point to the APK.
package name="com.nxp.nfc.tagwriter"
codePath="/data/app/com.nxp.nfc.tagwriter-1.apk"
nativeLibraryPath="/data/data/com.nxp.nfc.tagwriter/lib" flags="0"
ft="12f0c2af6e8" it="12f0c2afba2" ut="12f0c2afba2" version="8"
userId="10062" installer="com.google.android.feedback"
Another trick if you ARE rooted, notice the items in the “perms” tags in the packages.xml file. Is there an app that has a permission you don’t want it to have? Go blackberry permission style on it and drop permissions you don’t want it to have from the packages.xml file. Push back the packages.xml file (and check the file permissions and owner) then restart the device. Your mileage will vary here with how well this will work with an application, since in many cases developers haven’t written exception handling to fail gracefully if the application loses a permission, but I think it’s an interesting thing to try out.
I’d also recommend checking out Tim Strazzere’s blog, which as a nice breakdown on the “installer” attribute in the packages.xml file and ways to set this, even on those days you don’t feel like being root.
Update: Quine reminded me of his way to return package names. He uses the “pm list packages -f” command in adb shell. Take a look at our next blog post.
