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
- Certificate Validation
- Support for Emerging Technologies
Testing Techniques
- Whitebox
- Sometimes it’s trivial to get app source-code
- Blackbox
- Acquiring application binaries
- Reverse Engineering
- 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
- Smali / baksmali
- 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:
Like this:
Like Loading...
Related
