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

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

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

2 responses to “Shmoocon 2011: TEAM JOCH vs. Android: The Ultimate Showdown

  1. Pingback: Week 4 In Review – 2011 | Infosec Events

  2. Pingback: Top 5 posts of 2011 « Cатсн²² (in)sесuяitу / ChrisJohnRiley

%d bloggers like this: