Download as PDF, PPTX
Uploaded bySam Bowne
CNIT 128 7. Attacking Android Applications (Part 3)
This document discusses various techniques for attacking Android applications, focusing on exploiting storage access, insecure communications, and application vulnerabilities. Key topics include permission management, file encryption, SQL database vulnerabilities, and misconfigured app attributes. It also highlights testing techniques and tools for analyzing and enhancing app security.
More Related Content
Similar to CNIT 128 7. Attacking Android Applications (Part 3)
![[Wroclaw #1] Android Security Workshop](https://cdn.slidesharecdn.com/ss_thumbnails/owaspplwroclaw1-160225150939-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
CNIT 128 7. Attacking Android Applications (Part 3)
- 1. CNIT 128 Hacking MobileDevices 7. Attacking Android Applications Part 3
- 2. Topics • Part 1 •Exposing Security Model Quirks • Attacking Application Components (to p. 271) • Part 2 • Attacking Application Components (finishes)
- 3. Topics • Part 3 •Accessing Storage and Logging • Misusing Insecure Communications • Exploiting Other Vectors • Additional Testing Techniques
- 4.
- 5. File and FolderPermissions • 10 characters in permissions section • -rw-r----- • First char: - for file, d for directories • Next 3 chars: rwx for owner (user) • Next 3 chars: rwx for group • Next 3 chars: rwx for others • World readable, writable, executable
- 6. Numerical Permissions • In octal(base 8) • chmod 777 assigns rwxrwxrwx • chmod 644 assigns rw-r--r-- • chmod 755 assigns rwxr-xr-x
- 7. Umask • Determines defaultpermissions for newly created files and folders • For Android 4.0 and up umask is 0077 • So applications have rwx------ • Owner-only
- 8. Traversal Checking • Afile is only accessible to other apps • If all the parent folders also allow access
- 9. Droidwall Privilege Escalation • TheDroidwall app used the iptables firewall • And made a droidwall.sh script with 777 permissions, running as root
- 10. File Encryption • Encryptingfiles protects them from attackers • But where do you put the key? • Often in the source code, where attackers can easily find it • SQLCipher is often used this way
- 11. SQLite Cracker • Triesall words in the app
- 12. SD Card Storage •Android can use built-in SD cards and external ones • SD cards are typically formatted with FAT32 • No permissions possible • Android required android.permission.WRITE_EXTERNAL_STORAGE permission to write to SD card • But no permissions to read from it
- 13. • Common locations for external SD card • Android 4.4 and later enforce android.permission.READ_EXTERNAL_STORAGE permission SD Card Storage
- 14. WhatsApp Database Storage • WhatsAppstored its database on the SD card • Any app granted android.permission.READ_EXTERNAL_STORAGE permission could read it • It was AES encrypted, but with a static key • The "WhatsApp Xtract" tool could open it
- 15. Logging • Useful fordevelopers • Applications with READ_LOGS permission can read the logs • Android 4.1 and later changed READ_LOGS to signature | system | development • No third-party app can obtain this permission
- 16.
- 17.
- 18. • HTTP (unencrypted) •HTTPS without validating TLS certificate • We've done it in the projects with Burp Insecure Communications
- 19.
- 20. Certificate Pinning • Appchecks the TLS certificate with custom code • It won't accept the 'Trusted Credentials" in Android • There are several ways to overcome this
- 21.
- 22. SSL Validation Flaws •Developers often disable validation in the app • For testing and to prevent annoying error messages • By adding a HostNameVerifier method that always returns true • Or a TrustManager method that does nothing
- 23. WebViews • WebView allowsweb pages to be rendered within an app • Prior to Android 4.4 it used WebKit • Later versions use Chromium • WebView runs in the app's context • Allows the developer's hooks, often disabling TLS
- 24. WebSettings Class • Controlsconfiguration of WebView
- 27. Exploiting WebView • Senda malicious intent with an extra containing a URI like • file:///data/data/com.malicious/app/ exploit.html
- 28. JavaScript Interfaces • Canrun Java pages inside WebView
- 29. • Execute anyOS command • On Android before 4.1 • And any app with targetSdkVersion < 17 • On any devioce
- 30.
- 31. Other Communication Mechanisms • Clipboard •Local Sockets
- 32. Clipboard • Data canbe read and written by any app • Password managers often use the clipboard to move password into an app • Any app can easily steal it • Drozer can read the clipboard
- 33. Local Sockets • TCP,UDP, or Unix • Any app can connect to it
- 34. Wireshark • Inspect networktraffic
- 35.
- 36. Abusing Native Code •Compilied C/C++ Code • Analyze with IDA (Covered in CNIT 127) • Vulnerabilties like bufferr overflows • Develop exploits with GDB debugger • Available for Android
- 37. Exploiting Misconfigured Package Attributes •AndroidManifest.xml may allow • Application Backups • true by default • Make backup with adb backup • Debuggable Flag • false by default
- 38. Debuggable Flag • Exposesapplication data • Allows code execution in context of application • Can be exploited with physical access to the USB port (if USB debugging is enabled) • Uses a Unix socket @jdwp-control
- 39.
- 40.
- 41. Layered Security • Certificatepinning • App checks TLS cetificate • Won't accept a proxy like Burp • Root detection • App refuses to run on a rooted device
- 42. Patching Apps • Modifycode with apktool to remove security tests •
- 43. Manipulating the Runtime •Insert low-level hooks into the Android system • So the API calls the apps make are changed • Analogous to placing the app into a virtual machine • Allows you to change the operation of an app without modifying the app itself
- 44. Tools • Cydia Substrate •Xposed Framework • Frida