Category Archives: Mobile Security
Google Wallet – Last Four Digits Revealed to Malware Vulnerability
If you’re using Google Wallet, please check your version number and ensure you’re up-to-date (1.1-R57v5 as of this post). This post describes an issue we discovered and reported to Google a few weeks ago. It has now been patched in the latest version of Google Wallet. We think it’s an interesting concern for both end users of Google Wallet and other application developers. While not the most earth shattering vulnerability, it’s probably not something you would want malware collecting about you or your credit cards.
To start, there has been a lot of great research into Google Wallet recently, including the ability to brute force the account PIN and viaForensics dive into application data storage. Both of those attacks required root level access to the device. However, in this attack, the heart of the issue involves the ability to send a specially formatted intent message to Google Wallet. This is something any Android application can do, once installed, without any additional permissions. The specially formatted intent message essentially tells Google Wallet to turn on verbose logging. Data which gets logged includes the last four digits of any credit cards that have been associated with your Google Checkout account (since Google Checkout is now rebranded/merged with Google Wallet). While the full card number is not shown, this data (along with other information that might get collected as well), could be used to target you for a fairly believable social engineering attack. Additionally, the inclusion of Google Checkout information means card numbers which I never thought of as part of my mobile phone’s digital wallet, were included as well (you’ll see these as “UNPROVISIONED” listings in the logs).
Last 4 digits of credit card numbers from Google Wallet/Checkout in the Android Logs
We’ve put together a short video which shows our “malware” application sending this intent message and collecting data on a non-rooted Galaxy Nexus (running version 1.1-R52v7 of Google Wallet) . You’ll notice the application does require the one permission, the ability to read the device logs. For the technical details, please see the our security advisory.
http://intrepidusgroup.com/advisories/intrepidus-advisory-20120418.txt
As for the fix, Google has stated they’ve reviewed all of Wallet’s logging features and have added the android:exported=”false” attribute to the LoggingPriorityChangeReceiver to prevent third party applications from enabling this feature.
Video: Google Wallet – Verbose Log Capture Malware Example
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
Google Wallet coming for iOS?
The list of two OS types in WalletShared: ANDROID and IOS (click to enlarge)
Let’s start by saying this is no smoking gun, but a pretty interesting case of information leakage through an application. For our regular blog readers, you’ll know we’ve been looking into NFC based applications over the past year. The jewel of all NFC apps is easily Google Wallet and thus we’ve spent a large amount of time trying to understand it. When you decompile an Android application, which isn’t obfuscated, you’re able to see the same class names, method names, variable names, and other identifiers as in the developer’s source code. In this case, Google Wallet includes a package called “wallet.proto” which contains parsers for any “Protocol Buffer” formatted data the application uses. While the name “Protocol Buffers” sounds generic, it’s actually Google’s well-documented mechanism for serializing data (think of it as their version of XML or PLists). If you followed the Google Wallet PIN hashing issue, you’ll remember that the PIN hash is stored in a protocol buffer.
The “WalletShared” protocol buffers package in the current version of Google Wallet contains hints of iOS within the parsers definitions. This includes defining the “DeviceContext -> HardwareType” field with only two values: “ANDROID” and “IOS”. iOS strings are also found in two additional protocol buffers called “IosDevice” and “IosWallet”. The classes only leak a little detail about the information being collected which include items named “appId”, “appVersion”, “walletUuid”, and a few “model” and “version” items.
Function names with
Now you might ask why anything about an iOS application, written in Objective C, would get compiled into an Android application, written in Java. This could happen because of how a Protocol Buffer structured data definition file is created. A developer typically creates a “.proto” file, which is a programming language independent file which defines the data structure. This “.proto” file is then compiled using the “protoc” application and creates the appropriate files for the language you are programming in. Thus, it’s simple to use the same “.proto” file to create a Java object or an Objective C object if they are both going to use the same data structure. While Objective C is not in the official protocol buffers package, there is an add-on for that language available. Thus it is quite likely if there was a “shared” data structure which both clients and the server would need to parse, the same “.proto” file would be used regardless of the application’s programming language.
Of course, if Google is developing Google Wallet for iOS, it raises numerous questions. Since iOS devices do not currently include an NFC radio or secure element, is Google planning to release a case, or “sleeve,” with these components? Or do they know something about the next iPhone we don’t? And if the next iPhone does have NFC and a Secure Element, would Apple allow Google access to those components? In any case, if Google is working on developing their wallet for iOS, this could be a sign of strong commitment by Google to contactless payment technology. And that’s a win for everyone regardless of which device is in your pocket right now.
Quick Look at Apple Configurator
Shortly after the iPad event on Wednesday, Apple released the free Apple Configurator application. It’s billed as a way to “set up new devices, and install enterprise apps,” but my main interest was in learning how it might interact with Mobile Device Management. So I upgraded my iTunes to 10.6, installed the application, and started poking around.
Essentially, Configurator allows you to maintain a fleet of identical iOS devices. With it, you can re-baseline up to 30 devices simultaneously, pre-installing applications and configuration profiles at the same time as wiping it clean and updating the OS version. The application allows you to create configuration profiles directly, or you may import profiles created in the iPhone Configuration Utility (IPCU). [Aside -- the IPCU was also updated on Wednesday, and both that and Configurator support some new features, including the ability to disable Siri when the device is locked. Interestingly, Configurator also includes the ability to enable a "Siri Profanity Filter" and to disable Location Services, neither of which I've been able to find in the new IPCU.] The Configurator doesn’t include the capability to create an MDM enrollment profile, but you can import one from IPCU and it works just fine.
When used in this mode, Configurator can easily streamline the setup of large numbers of devices for corporate deployment. I haven’t found a way to pre-set all the “Welcome to iOS” responses (selecting a language, assigning an Apple ID, etc.), but even with those last few manual steps, this can make rapid deployment of large numbers of devices in an enterprise much, much easier. The device is wiped, then the latest version of the iOS installed, along with applications and profiles. At this point, the device can be set aside into a pool, ready to be used. You can even load pre-purchased App Store applications (for very small deployments, you can pre-set the AppleID used to purchase the apps you’re installing, otherwise you’d need to use the Volume Purchase Program to load redemption codes for each device).
But that’s not all! When baselining (or “preparing”) a device, the user has a chance to configure it as a “Supervised” device. When issuing the device to end users, you can just hand it to them, or have the system formally “check out” the device. By doing the check out, the device can be customized with the user’s name, photo, and pre-installed user-specific documents. When the user is done with the device, they return it, and the check-in process then backs up the user’s data, and wipes and re-baselines the device for the next user.
All of that would be interesting enough, but my focus is more on security than ease of deployment — what does Configurator do to enhance or replace MDM? Firstly, the profile that marks the device as supervised can not be removed by the end user. In fact, as far as I can tell, it can’t even be removed by the machine which prepared the device. The only way to “un-supervise” a device is to wipe it clean and start from scratch. It also locks the device to the system used to prepare it — trying to connect to iTunes or IPCU on another system results in an error. In fact, even using IPCU on the Configurator machine won’t work — it won’t let you install or remove profiles at all. However, I was able to manually install an MDM profile, as a user, by tapping on a link in Safari, so the end user might still be able to make changes that way even if IPCU is locked out. Also, even when the MDM enrollment profile is installed as part of the device preparation and baseline process, the user may still remove the enrollment.
One final interesting point — the use of the “supervised” term caught my eye. When researching the changes that iOS 5.0 brought to the MDM system, I found several mentions of supervised devices near other MDM-related strings in the iOS binaries. I also found several references to a “Chaperone” system. These included things like “PermissionSlip,” “AllowSleepOver,” and even “ReadyForKeyMaster” (though no mention of Zuul). Ever since seeing that, I’ve wondered if some form of parental-oriented device management and monitoring might be in the works. Well, this system seems to make use of Chaperone-related profiles, so perhaps we’re seeing the first elements of this beginning to enter production.
In summary, the new Apple Configurator application looks like it will be very useful for anyone maintaining a small fleet of devices (such as loaner devices, or in support of a class), and will also greatly streamline the large-scale preparation and deployment of devices within the enterprise. For further reading, here’s a link to the Configurator Documentation from Apple.
Google Wallet PIN Brute Forcing
Google Wallet is a project of great interest right now as it is a big shift in how we pay for goods and services in the US (Japan is quite far ahead of everyone on mobile payments). Some researchers have discovered that Google Wallet is storing the PIN for your wallet on the device in a relatively insecure format. Since this information was already released into the wild, we felt we should share our perspective and how we would approach this problem. The PIN data is stored in the application’s SQLite database.
The SQLite database is stored in the Google Wallet data directory. Google wallet stores the pin in the proto column of the metadata table. The data is encoded using the protobuf format (also by Google). The following SQL query retrieves the data:
select hex(proto) from metadata where id = "deviceInfo";
This query retrieves the protobuf data encoding a number of device and user specific information. Protobuf is a data serialization format, similar to JSON in concept. Next the data must be deserialized. The standard way to work with protobuf data is to define a .proto file, which acts as a key for deserialization. These .proto files get compiled down to application specific code and are not in their native human readable format. Raj decided to start to write a generic protobuf decoder (Protobuf Easy Decode) . This Python module can decode protobuf data without a .proto file. Some data is inevitably lost when reading raw protobuf data without a .proto file.
Recovering the PIN with the decoded data required some understanding of the specific .proto structure. Once the salt and the hash of the salted pin retrieved, brute forcing the PIN is a trivial matter: brute_pin.py illustrates how to brute force the PIN.
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!
“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.
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
OWASP ATL: Mobile Application Assessment Presentation
I recently gave a presentation at OWASP ATL on the OWASP Mobile Top 10 and how to assess mobile applications. This was a light weight discussion of the OWASP Mobile Top 10 and some topical and technical concerns related to securing mobile applications.
Download the presentation here: [download id="276"]
These videos show various testing techniques on real applications. The applications targeted didn’t have any serious problems. In the case of the game, “WordFeud”, a Scrabble clone, the game maintained game state on the server and tampering with client side values did not yield any interesting results. The SoundCloud demonstration shows how it uses the iOS data protection API to avoid storing OAuth tokens in the applications file sandbox and instead uses KeyChain.
Video Demo Series Here:
iPad SSL MiTM
- http://www.youtube.com/watch?v=0453HDZYdGU
- http://www.youtube.com/watch?v=kZ1pKShrKyk
- http://www.youtube.com/watch?v=NvyM1wzwT2o
- http://www.youtube.com/watch?v=HRRqL7IAkJw
- http://www.youtube.com/watch?v=24FT-plmjAs
iOS Application MiTM
- http://www.youtube.com/watch?v=Hgk310uUdjI
- http://www.youtube.com/watch?v=x1T6kjtcpLw
- http://www.youtube.com/watch?v=0VwJ1bss5wA
- http://www.youtube.com/watch?v=50NAa324WC0
- http://www.youtube.com/watch?v=btl147-ioKQ
- http://www.youtube.com/watch?v=5YFC2L0vapM
- http://www.youtube.com/watch?v=UL6mjywzBwU
Sound Cloud and Data Protection
