Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: android

A sneak peek into Android “Secure” Containers

It’s been a bit quiet here on the blog, so I thought I’d take a few minutes to write up an issue I raised with the fine folks over at LastPass .

Alongside the HTTP Response Code stuff, I’ve been playing around more and more with Android applications. One of the things I presented on in Vegas at the BSidesLV Underground track was breaking into Android Secure Containers. The name of the talk was cryptic for sure, mostly because said “secure” containers were anything but secure, and because I hadn’t had time to report the issues to the effected vendors. The issues I discussed weren’t tied to a single application, and effect numerous apps within the Play Store…
So, here we are a month later, and LastPass has rolled out a “fix” for the issue I reported to them. This means I can give you the down and dirty details now that you’ve all updated your Android devices to the latest LastPass version (currently 2.5.1). FYI: the CVE  numbers for these issues although not referenced in the LastPass changelogs as yet are CVE-2013-5113 and CVE-2013-5114.

This research needs a little back story to explain it, so bear with me for a minute while I set the stage.

Back Story / Testing Scenario

I started down this research track when I was looking at how Android applications provide additional security through PIN and/or password protection of specific applications. This additional layer of security offered by applications like LastPass is there to stop people who have physical access to your Android device from getting into the more secure areas of your data (e.g. Passwords). With this in mind I expected the implementation of these protections to be designed to stand up to an attacker with physical access to the device (aka. somebody who’s stolen/borrowed/found your Android device).

Some Facts

Without root access to the android device, it’s not directly possible to view or alter the data of specific applications. Even if USB Debugging is enabled (by the owner, or later by an attacker with device access) it’s only possible to view specific data on the Android device, not all the juicy stuff. Everything I’m about to discuss is possible based on a non-rooted device, however USB debugging needs to be enabled to allow us to interact with the device using adb. Remember, the scenario we’re talking about here is physical device access, so this shouldn’t be a big hurdle.

Note: It goes without saying that everything that can be achieved here with ADB /USB Debugging can also be achieved through exploitation of the device… although, there are much more fun things to do if you’re popping shell on a device 😉

The LastPass Case


LastPass allows a user to save their password within the Android application so that you don’t need to type it every time you open the app. This isn’t abnormal for applications, and like any good security minded application they give you options to secure the access using something other than your long long password (aka… the PIN).

Given my experience, users of such applications have too much faith in the security of their devices and have no desire to type in their 32 character random LastPass password whenever they open the application (have you tried that on a handheld device? Yhea, not fun…). Much better to store the password in the secure container settings and assign a PIN to protect the app (because that’s secure!).

So with the back story and the explanation out the way, here’s the meat of the issue

The Meat

When I first started testing LastPass on the Android (version 2.0.4 at the time) I noticed something interesting about the AndroidManifest. In particular the android:allBackup was set to True, meaning that even though I couldn’t read or edit the configuration/settings of LastPass directly on the device (remember, non-rooted device) or via ADB (remember, USB debugging enabled, but even then no direct access), I could perform backup and restore operations via ADB.

This led me down the trail of learning more about the “adb backup” command (introduced in Android ICS). What makes adb backup and restore so useful in this context, is the ability to not only backup a device entirely over USB, but also to specifically backup individual application data (with or without the APK file). This makes the backup and restore much more flexible for what we’re looking at doing. After all, backing up an entire 16GB device every time gets tiring (I’m looking at you iOS).

By performing an adb backup (command: adb backup com.lastpass.lpandroid -apk) and accepting the prompt on the device, you end up with a backup.ab file containing the LastPass application (APK) and the data/configuration/settings from the application. There have been numerous discussions on the format used by Android Backup files, but I wasn’t happy with any of the solutions offered to decrypt the AB files into something usable. So I decided to automate the lengthy process in Python (see https://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release/) and add in some features to ease things a little.

The final result is a directory output of the LastPass application (with or without the APK – your choice – screenshot is without APK). lastpass_tree

Taking a look at the files the sp/LPandroid.xml quickly stood out as worth further analysis. As expected the configuration file contained the username and password in encoded format (if saved within the LastPass app). Alongside this the XML also contains an encoded version of the PIN and various other application settings. Putting aside the possibility to decode the password and PIN, a few settings caught my eye for easy wins:

  • reprompt_tries

This is a simple integar that increases as incorrect PINs are entered

  • passwordrepromptonactive
  • pincodeforreprompt (holds encoded PIN)
  • requirepin

These control the password reprompt on startup and the PIN protection (yeah, you can see where this is going already)

The Story So Far

We have access to the LastPass configuration of a non-rooted device via adb backup… and we can fiddle with the resulting configuration file. However we’re still playing about with the XML inside a backup and not with the device itself. We need to get the changes back into the device

Next Step

Using more Python trickery goodness (see https://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release/) we can take the directory structure created and rebuild the Android Backup file (with the changes that we’ve made to the files of course). Then we can restore the backup to the device (if you still have access to it) or to your own device/emulator (make sure you have the APK in the backup file or the app already installed if you want to restore to another device).


lastpass_home_screenAs expected, playing with the reprompt_tries by setting it to a minus number (-9999 for example) allows you to bypass the 5 PIN attempts before wipe feature of LastPass. This essentially gives you 10,000 retries. If you can’t guess a 4 digit PIN in 10,000 retries, then nothing can help you 😛

However, the easier and more fun option is the pincodeforreprompt / passwordrepromptonactive and requirepin alteration which results in the LastPass application not requiring a PIN for entry anymore.

  1. Backup configuration and unpack
  2. Alter XML settings as required
  3. Pack configuration and restore
  4. <<< Profit >>>


Some of the more eagle eyed amongst you may have already noticed another interesting attack vector here. The ability to backup LastPass from a device (within 30 seconds if you’re handy ;) and return the device to the owner, coupled with the freedom to restore said backup to an attacker controlled device, makes the attack much more interesting. Not only can you do this, bypass the PIN in your own time, and then read and extract the stored passwords as desired. You can also maintain access to the users LastPass account until such time as they change their LastPass password itself.

If the original owner alters their any of the passwords their store in the LastPass service, the attacker can simply close and restart the cloned Android container to update the information from LastPass’ servers.

Note: Version 2.5.1 mentions an alteration in the way LastPass creates UUIDs. This may effect this cloning attack – as yet unconfirmed

Round 2 – It’s not over yet

You may have noticed the use of quotes around “fix” at the beginning of this post… After LastPass got back to me to say they’d fixed the issue (actually they responded to say they’d fixed it the day before I reported it as they’d disabled allowBackup and not pushed it to the Play Store yet), I started looking at the proposed fix and possible bypasses based on the same physical access scenario. After a few false starts I have a working bypass for their fix that once again allows the attack (with an additional step). Once they’ve fixed the fix, I’ll let you guys know how that one went down 😉

Until then, make sure you upgrade your Lastpass to the latest Play Store version (2.5.1 at this time) and keep an eye out for further fixes!


BSidesLV: Android Backup [un]packer release

bsideslvlogoAs part of my “Mobile Fail: Cracking open “secure” android containers” talk at BSidesLV I’ve released a couple of scripts I wrote to automate some of the legwork involved in backing up Android applications and automatically unpacking their data and settings. The accompanying script takes the data and settings structure and re-packs it into a working Android Backup file for restoration.

These scripts were used as part of my research to view settings used by applications and in some cases alter the configuration to deactivate secure features or allow access. In some cases it’s also possible to alter configuration files to gain elevated functionality (unpaid… but nobody would ever do that… right!).

The process isn’t new and can be done manually, however automated solutions are always easier…

packer unpacker


  • openssl with zlib support
  • star (apt-get install star)

Simple Python scripts to perform:

  • an adb backup of a specific application and uncompress it to a directory structure
  • recompress a directory structure back into a valid adb restore file

Example usage:

./ab_unpacker.py -p com.app.android -b app.ab

  • Creates an adb backup of com.app.android called app.ab and uncompresses it into ./com.app.android

./ab_packer.py -d ./com.app.android -b app_edit.ab -o app.ab -r

  • Repacks the contents of ./com.app.android into app_new.ab and attempts to restore it via adb



Shmoocon 2011: TEAM JOCH vs. Android: The Ultimate Showdown

TEAM JOCH vs. Android: The Ultimate Showdown

Jon Oberheide and Zach Lanier

Android Security Overview

Base platform :

  • ARM Core
  • Linux Kernel 2.6.3x
  • Native Libraries
  • Dalvik VM
  • ….

TrustZone Security Foundation by ARM

  • ARM11 TrustZone –> Unused!
  • ARM11 Jazelle JVM –> Unused!
  • ARMv6 eXecute-Never (XN)? –> Unused!

Mobile ASLR sucks!

Exploiting like it’s 1990

  • Executable stack/heap
  • Non-randomization of mmap/brk

Permissions based models

Applications explicitly request pre-defined permissions. All or nothing (ACCEPT or don’t install)

App Sandboxing

standard uid/gid – generating a unique account per app to prevent overwriting of files

Application signing


Kernel Security

Linux kernel = Swiss cheese

Jailbreaks, aka local privesc


Dalvik VM != sandbox

  • Not limited to execute dex bytecode
  • Can pop out of VM to execute native code
  • Any 3rd party app can root your phone by exploiting a kernel vuln

Native code packaged within APKs

  • No code signing

How to build a mobile botnet

  • Build some fun looking game/app
    • including RootStrap functionality
    • Periodically phone home to check for new payloads
  • As soon as a new kernel vuln is discovered, push out exploit payload
  • Rootkit a bunch of phones

PoC –> Eclipse Preview

200+ downloads in under 24 hours

Not very good reviews… 1*

Google pulled the software from the store

Google used the REMOVE_ASSET function to uninstall the app from the phones

Google can not only remove software, but use INSTALL_ASSET to install things!

Platform Security

There’s a lot of “platform goo” in the middle between applications and kernels

What to attack?

  • Not kernel, not apps!
  • How about the permissions framework

Permissions approval process is designed to warn users of what an application needs to access

  • Browse
  • Install
  • Approve?
  • Installed!

Google is a sneaky panda!

You don’t actually download/install the app through the market

When you click install in market, Google sends the INSTALL_ASSET command to your phone to begin the install using the GTalkService persistent data connection used to connect your phone to Google.

This is one of the few closed-source parts in Android.

Connections are SSL… but SSL isn’t everything.

If you can pop the GTalkService Servers at Google, you could push out apps to every Android phone!

Gap in responsibility

Market app performs the perceived install process and acceptance of permissions

The GTalkService then takes it from there

The communications use Google’s Protobuf format which has been at least partially documented by the Android Market API project on googlecode.

Elements of an install request

Needs to be populated with

  • Misc fields
  • App ID
    • Can be derived from dissecting market requests
  • Auth Token
    • Turns out this can be stolen from the Android AccountManager

Bypassing permissions approval

  • Steal the “android” service token used by the market from the AccountManager
  • Construct ProtoBuf request to market servers
  • Bypass the permissions approval process by directly requesting the software from the GTalkService using INSTALL_ASSET

When people viewed the install page in the market, the user wasn’t prompted and in the background other applications were installed

Platform Security Write-up

Vulnerability Status

  • Donut: Fixed
  • Foyo: Fixed
  • Eclair: no confirmation yet, may be vulnerable

Solution adds a process where the marketplace flags an app as accepted which the GTalkService checks before installing.

Platform complexity leads to vulns

  • Round-about marketplace and GTalkService procedure
  • “server-initiated” flag fix worth investigation

Application Security

Broad Observations

The web pushed a lot of content to the browser

Now instead of data, functionality is being pushed to the web.

Mobile brought about an app for everything. Most could be achieved through the browser

XKCD viewer??


Carriers: “We trust you because you’re on our network”

Client-side data trust issues… admin=1 is live again!



Whitebox source-code review

  • Sometimes it’s trivial to get app source code


  • Acquiring Application binaries
  • Reverse Engineering (Disass/Decomp)
  • Network Analysis (Fuzzing, Protocol Analysis)
  • MITM

Testing Tools and Techniques

  • DextoJar
  • JDgui / JAD
  • Undex
  • APKtool (wrapper around smaller tools)

Case Studies


Originally written in Java, like most Android apps

Source available under Apache 2.0 license

FourSquare API supports Basic Auth and OAuth

  • OAuth Includes signatures for transactions to prevent replay attacks etc…
  • So naturally FourSquare used Basic Auth over HTTP

FourSquared app does have OAuth support, but it’s not actually used

Fixed since, as FourSquare API now forces HTTPS (at least it’s one step in the right direction)

Storage Application

Simple crash in storage quota viewer

  • Divide by zero error leads to Dos
  • Attacker mus successfully intercept and modify the server response

More of an annoyance than a real problem… app crashes!

This app also supported some DRM protections however

  • App supports sharing video, audio, image content
  • This is set by an XML manifest that says what is and isn’t possible
  • DRM enforced on the handheld….
  • intercept, change read only to share and DRM bypassed

App Framework

Runs on multiple platforms

Custom permissions restricts us from sending messages (intents) to the runtime

This app implements a custom intent service which can be spoken to as long as you have the right key!

But other malicious apps can clobber widget content! (CWE-276: Incorrect Default Permissions)

The configuration and store on the filesystem is world writable, allowing for clobbering the app content (modify widget anybody)

Lookout mobile

Lookout mobile security app

> 4 million users

Performs scanning, backup, lost device recovery.

Installs with world writeable configuration file (/data/data/com.lookout)

Has a code execution flaw due to its call to liblookout.so from a shared location.

By overwriting the lib (or changing the read path in the world writeable config) you can get code exec

Security app != Secure phone


  • No real guidance, standards, best practices
  • Bone-headed unix mistakes from 1995 are appearing in mobile now


  • Shmoocon Schedule –> HERE
  • Talk Synopsis –> HERE
  • Market API –> HERE