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

It Melts In Your Hand: An Overview of Security (Failures) In Mobile Applications – Zach Lanier

Mobile Application Themes

Broad Observations

The web pushed content to the browser

• Centralization of apps and data
• Always a push for MORE (ActiveX, applets, …)

Now, everyone gets their own app!

• Code (not HTML) gets pushed to the endpoint
• App for things like XKCD

Authorization

Carriers only authenticate to the network. Once you’re on the carrier, it’s free access with almost no checks.

Third-party applications are sometimes better than carrier apps with support for better auth

Some stupid client-side auth issues (admin=1)

Many apps are syncing data between the device and cloud using simple HTTP

At that point it’s just like pentesting a webapp

Platform Security

Quick Overview of the common platforms

Many disparate platforms

• Android, iPhone Os, RIM, WinMo, Brew, ….

Different platforms handle security differently

Concerns

• Shared user accounts
• Native Code
  • Obj-C, JNI)
• Certificate Validation
  • SSL, Code Signing
• Support for Emerging Technologies
  • Flash, WebKit, HTML5

Testing Techniques

• Whitebox
  • Sometimes it’s trivial to get app source-code
• Blackbox
  • Acquiring application binaries
  • Reverse Engineering
    • Dissassembly
  • Network Analysis
    • Protocol Analysis
    • Fuzzing
    • MITM

Protocol analysis is often the easiest method. A lot of applications tunnel over HTTP and make it easier for testers.

Tools commonly used .:

• undx, coddec, JAD
  • decompilation
• Smali / baksmali
  • (dis)assembly, patching
• Native Code?
  • IDA with ARM support
  • Strings

adb –> Android Debugging Bridge

Not everybody can by a RE ninja.. sometimes the easiest way is to listen to it’s traffic

Become the MITM using tools like WAPT, WebScarab/Paros/Burp

Issues include things like requirement to be on the carrier connection and string SSL Certificate checks

Solutions including the use of mobile broadband cards and emulators to sit on the carrier network and still run the app

Wifi isn’t always an option as not all phones support it, applications may not connect over Wifi

Intrepidus have released a tool called mallory for MITM on TCP and UDP connections. This is useful for MITM mobile device testing

Case Studies

Foursquared

Application for 4square

Usage of Basic Auth instead of OAuth

• Cleartext transmission of username/password

4square are starting to enforce OAuth and SSL in the future

Why is this a problem –> Most applications prefer WIFI over carrier. Easy to sniff at your local Starbucks

A Storage Application

Multi-platform application

Developed by a third-party, branded for major carriers

Problem –> Simple crash in the storage quota viewer

Attacker needs to MITM and alter the server response –> Client crashes

Application has DRM, but allows you to share between friends.

Enforcement occurs on the client-side when viewing (XML response from the server detailing DRM info) –> FAIL

Embedded Device #1

Mix of HTTP and HTTPS content

MITM on HTTP traffic to enable hidden Admin content

Strict SSL Validation prevents SSL MITM

The big problem was command injection by injection of commands into the SSID –> SSID; <insert your command here>

Embedded Device #2

Typical XSS flaws in interface

Also command injection flaw allowing access

BREW Picture Upload

Designed to upload data from the phone to the cloud

BREW != Smart Phone

– No Wifi

Application Directed SMS

• SMS Client can parse messages and identify specific control messages for distinct applications
• Debug code: SMS instruction to change remote upload destination
• Traffic was plaintext HTTP/SOAP

Authentication uses a static token for the lifetime of the app on that device.

Authentication token was an MD5 hash created server-side –> Able to recreate the data used to create the MD5 hash

Able to hijack other users accounts based on this information and creation of valid MD5s

POST-Mortem

• No SSL
• No Real Auth Scheme
  • Wh would you lie about your phone number
  • If they’re on our network they’re trusted
• No authorization controls on the server

RIM Picture Upload

Similar to the BREW upload

Extract binary using JavaLoader.exe and run it in an emulator

Main app in a COD file.. simple ZIP format produces files to be decompiled

Decompilation didn’t give a clean output.

What was visible was a hard-coded 3-DEs key in the Java Bytecode. All devices use the same key!

Every encrypted image sent out on the wire was prefixed with an auth header

The WebApp at the server-side was vulnerable to a number of flaws including injection, and information disclosure

LAX permissions: Allowed to do whatever it wanted on the device itself –> What ever happened to least privilege?

POST-Mortem

• Broken, Hard-coded crypto
• Lack of input validation
• LAX permissions and no defense in-depth

Links:

• Quine Twitter –> @quine
• Mallory –> LINK
• Mallory BH Talk –> LINK