Outsmarting smartphones
Download as PPT, PDF•1 like•913 views
The document discusses smartphone security, focusing on the vulnerabilities in iPhone and Android applications due to poor programming and the lack of standardization in mobile app development. It details the reverse engineering process for iPhone apps and the architecture of Android applications, including their permission models and security features. The speaker emphasizes the rapid growth of the smartphone industry and the need for improved security practices in mobile application development.
![[email_address] @s_harit O ut S marting SmartPhones](https://image.slidesharecdn.com/outsmartingsmartphones-111027044819-phpapp01/85/Outsmarting-smartphones-1-320.jpg)
Outsmarting smartphones
- 1. [email_address] @s_harit O ut S marting SmartPhones
- 2. 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)
- 3. 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
- 4. 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
- 5. I once had an iPhone...
- 6. 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
- 7. Reverse Engineering iPhone Apps
- 8. 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
- 9. 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
- 10. 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
- 11. I have an Android phone... ...and I love it :-)
- 13. 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.
- 14. 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
- 15. 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
- 16. 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
- 17. 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 ;-)
- 18. 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
- 20. 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
- 21. 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
- 28. All your data is Mine
- 29. Manifestor.py
- 30. Manifestor
- 31. 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
- 32. QUESTIONS
- 33. 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