Upload
sensepost
View
1.240
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Presentation by Saurabh Harit att he mobile security summit in johannesburg 2011. This presentation is about security on the iPhone and Android platforms. The presentation begins with a discussion on decrypting iPhone apps and its implications. The Android security model is discussed. The presentation ends with a series of discussions on practical Android attacks.
Citation preview
echo whoami
• Senior Security Analyst @SensePost (awesome company BTW)
• 7+ years in InfoSec
• Specialize in Web App & Network security
• Part time Reverse Engineer (is that even possible???)
• Certified Ethical Hacker (as if it matters)
• Can do 50 Push-ups in one go (and faint)
• Why does everyone rant about SmartPhone security
• Understanding iPhone Application layout
• Decrypting iPhone apps & what can we achieve
• Android Architecture
• Android Permission Model & Sandbox
• Analyzing Android Apps - Deep sea diving
• Practical Attacks on Android
• Demos
• And more Demos
• Introducing Manifestor.py
Why care???
• Smartphones are growing in popularity by minute
• Windows 7 (Dell, HTC, LG etc.), iPhone (Apple), Android (Google, HTC, Samsung, Motorola etc.)
• means growth in mobile applications (According to Juniper Research, mobile application market is expected to reach $32 billion by 2015)
• means loads of mobile application development (from barcode scanner to angry birds to mobile BANKING)
• means tons of lines of code (plus bad programming)
• equals to VULNERABILITIES - programmatic, environmental, configurational and so on
I once had an iPhone...
iPhone Binary Format
• IPA file - basically a zip archive
• Location of app binary on iPhone:
‣ Payload/MyApp.app/MyApp
• Based on Mach-O (Mach Object) file format
• Sandbox:
‣ Apps restricted to their own private directory and memory pages
• Apps are encrypted
‣ Decrypted by iPhone loader on run-time
Reverse Engineering iPhone Apps
Decrypting iPhone Binary
• What do I need:
‣ Jailbroken iPhone (Yes, it’s a necessity of life)
‣ iPhone SDK (Otool)
‣ Hex Editor (0xED, HexWorkshop, etc. etc.)
‣ Ida Pro (Optional) - Version 5.2 - 5.6
• Finding an app root dir on iPhone
‣ sudo find / | grep iApp.app
‣ myApp.app contains iApp, actual binary
• “crypt” load command responsible for decryption
‣ otool -l iApp | grep crypt
Decrypting iPhone Binary
• What do I need:
‣ Jailbroken iPhone (Yes, it’s a necessity of life)
‣ iPhone SDK (Otool)
‣ Hex Editor (0xED, HexWorkshop, etc. etc.)
‣ Ida Pro (Optional) - Version 5.2 - 5.6
• Finding an app root dir on iPhone
‣ sudo find / | grep iApp.app
‣ myApp.app contains iApp, actual binary
• “crypt” load command responsible for decryption
‣ otool -l iApp | grep crypt
Decrypting iPhone Binary
• Locate “cryptid” in actual binary, and flip it to “0”
‣ Do it, NOW
• “cryptid” is now “0”. What does this mean?
• Not decrypted yet
• Next, run the app on iPhone and take a memory dump
‣ Actaul code starts at 0x2000
‣ Size of encrypted data - 942080 (0xE6000)
‣ So, we need to dump from 0x2000 to 0xE8000. Guess why? :-)
• Run app on iPhone, ssh into iPhone, use gdb
‣ gdb -p PID
‣ dump memory iApp.bin 0x2000 0xE8000
• Pull iApp.bin on local machine
‣ Overwrite bin file on initial binary file (where we “cryptid” was set to “0”)
‣ Don’t forget - “cryptoff” was 4096 (0x1000)
• Sorted :-)
• For all technical details, please refer to SensePost blog:
‣ http://sensepost.com/blog/6254.html
I have an Android phone......and I love it :-)
Android Architecture
Android Security Model
• Linux kernel
• Linux-Like permission model
• Applications run with their own uid:gid (something like multi-user system)
• Applications may share a uid (must be signed with same key)
• App permissions are defined in AndroidManifest.xml
• Manually reviewed / accepted by user on install (Really??? What if I am a runway model?)
• Applications can be self-signed.
AndroidManifest.xml
•One for each app
•Declares Java package name for the application
•Describes components of the application - activities, services, broadcast receivers, content providers
•Declares permissions required to access protected parts of APIs
•Declares permissions required by other applications to interact
Activity
•User-focused task
•Almost always interacts with user
•Displays a button, text box etc.
•Runs within app’s process
•Stack based - new activity is placed at top
•Activity states: active, paused, stopped, resumed
Intents
• Basically messages between components such as activities, services etc.
• Like passing parameters to API calls, except it’s asynchronous
• Run-time binding
• Start an activity with startActivity()
• Similarly sendBroadcast(), startService(Intent) and so on
Start an
Activity
Broadcast Receiver
• Communication between Apps and System
• Messages sent as Intents
• Dynamic creation through context.registerReceiver()
• Static declaration through receiver tag in AndroidManifest.xml
• Can be exported with <intent-filter> tag in AndroidManifest.xml
• Access permissions can be enforced by either sender or receiver
• Apps can register to receive intents without special privileges ;-)
Service
• Long running background process
• Can run in its own process,
• Or in context of another application’s process
• Can be started with an intent
• Can be secured by adding a Permission check to their <service> tag
• Careful while sending sensitive data
Understanding Android App
• Apps run in Dalvik Virtual Machine - One DVM for each app
• DVM is register based, not stack based
• DVM ensures application isolation
• One application cannot access data of another application
‣ Hmmm, “cannot” or “SHOULD not”
• Unique UID for each application
• Apps written in Java, then compiled to Dalvik byte code
‣ No Solid code obfuscator for android platform
‣ Even if there is one, no-one uses it
• Permissions are declared in AndroidManifest.xml
• Permissions displayed to user on download - Accept or Reject. TRICKY!!!
‣ Everyone sitting in this room may care, what about others???
‣ What about installing via “adb” - Cracked apps (“adb install malicious.apk”)
• permission.INTERNET - Very common but that’s all they need :-)
• Easy to publish malicious app on Android Market
APK File Format
• Application package file for Android
• Variant of JAR file format
• Contains (unzip AndroidApp.apk):
• AndroidManifest.xml
• META-INF directory
• Classes.dex
• Res directory
• resources.arsc
Decompiling Android Apps
Analyzing HTTP Traffic
Bypassing Lock Pattern
Insecure Data Storage
All your data is Mine
Manifestor.py
Manifestor
Lets Sum It Up
• FACTS:
• SmartPhone industry is rapidly growing and will continue to grow
• Provide plethora of features & functionalities
• Apps for anything & everything
• Developed by unexperienced young developers
• Whats Required:
• Standardization of application development
• In-built secure APIs within SDK
• Need for strong threat model
• Domain based testing
•QUESTIONS
References
• http://www.juniperresearch.com/shop/products/whitepaper/pdf/MAS10_White%20Paper.pdf
• http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
• http://developer.android.com/guide/basics/what-is-android.html
• www.slideshare.net/JackMannino/owasp-top-10-mobile-risks
• https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks
• developer.android.com/sdk/
• code.google.com/p/android-apktool/
• https://www.facebook.com/HTC/posts/10150307320018084