7. Attacking Android Applications (Part 2)
0 likes65 views
This document summarizes part 2 of a course on attacking Android applications. It discusses how application components like activities and services can be exploited if not properly protected. Specific vulnerabilities in the Sieve password manager application are demonstrated, including insecure content providers, SQL injection, and an insecure file-backed content provider. The document also covers how services and broadcast receivers can be abused if not protected correctly.
7. Attacking Android Applications (Part 2)
- 1. CNIT 128 Hacking Mobile Devices 7. Attacking Android Applications Part 2 Updated 10-3-22
- 2. Topics • Part 1 • Exposing Security Model Quirks • Attacking Application Components (to p. 271: "Trust Boundaries") • Part 2 • Attacking Application Components (finishes)
- 3. Topics • Part 3 • Accessing Storage and Logging • Misusing Insecure Communications • Exploiting Other Vectors • Additional Testing Techniques
- 4. Trust Boundaries • Any Android app component can be controlled from any part of the app using intents • No default boundaries exist • If an app has a login screen • The developer must implement authentication mechanisms
- 5. Installing Sieve • Download from • https://github.com/mwrlabs/drozer/releases/ download/2.3.4/sieve.apk • Drag onto emulator • Enter password12345678 and 1234 • Close Sieve
- 6. Failed Trust Boundary • Open Sieve • Settings option available before login
- 8. Finding Exported Components • Drag APK into center pane of Android Studio • Examine Manifest • FileSelect Activity
- 9. Two Other Exported Activities • MainLogin Activity • PWList
- 10. Sieve • Exported activities • FileSelectActivity • MainLoginActivity • PWList • Can be started from any app
- 11. Unexported Activities • Can be launched from root account • SettingsActivity • AddEntryActivity • ShortLoginActivity • WelcomeActivity • PINActivity
- 12. Sieve • Exported Activity Launches • Unexported activity won't launch unless you are root
- 14. Creating Content • Launch Sieve in emulator • Log in with password12345678 • Add a saved password
- 15. Unprotected Content Providers • Not explicitly marked exported="false" in Manifest • Exported by default for target SDK < API 17
- 16. Content Providers • Two providers: DBContentProvider and FileBackupProvider, both exported • No permissions required, except path-permission for /Keys
- 17. Finding URI Paths • Install JADX from • https://sourceforge.net/projects/jadx.mirror/ • Launch from bin folder • Search for content:// • There may be other URIs
- 18. Content Query • Exposes username and email, password is an encrypted blob
- 19. SQL Injection
- 20. SQLite • App contains code like • select projection from table_name(uri) where selection=selectionArgs order by sortOrder • Bold items are parameters • uri is the full path of the content URI being queries
- 21. SQLite • Send these parameters: • URI: content://settings/system • projection: * • Query becomes • select * from system
- 22. SQLite Injection • Sending an apostrophe breaks syntax • projection parameter is vulnerable
- 23. Finding Table Names • Inject highlighted projection • Tables: Passwords and Key
- 24. Dumping Key Table • Reveals login password for Sieve app
- 25. Dumping Passwords Table • This is the default table, so we saw it before
- 26. Samsung Vulnerabilities • In 2011, installed apps on Samsung devices had content provider vulnerabilities exposing: • Emails & passwords • Instant messages and SMS • Call logs • GPS location • and more
- 27. • Because the content providers did not require read permissions • Also a SQL injection in the telephone app Samsung Vulnerabilities
- 28. File-Backed Content Providers • A content provider may allow other apps to retrieve files • By creating a content provider with a • public ParcelFileDescriptor openFile(Uri, String) method • URI should be validated against a whitelist of allowed files or folders • Or it allows an attacker to reference other files, such as /system/etc/hosts • Local File Inclusion
- 29. Local File Inclusion in Sieve • The FileBackupProvider allows Sieve to retrieve files, but allows arbitrary file read • Read /system/etc/hosts • Demonstrates vulnerability
- 30. Notice the /Keys Path • android:path="/Keys"
- 32. Android Documentation • Permission only applies for path exactly matching /Keys
- 33. /Keys v /Keys/ • Adding / evades permissions requirement
- 35. Services • Run code that must keep running • Even when the app is not in the foreground • Services can be started with an intent, like activities • An app can also bind to a service • Sending messages to and from it
- 36. Unprotected Started Services • The onStartCommand() method receives intents for this service from apps • May cause vulnerabilities • Auditor must read the code to assess the risk
- 37. Clipboardsaveservice • In 2012, privilege escalation was possible on Samsung devices • Because the com.android.clickboardsaveservice service could copy files from one location to another • This could be used by a package with no permissions to install another package
- 38. Unexported Services • They can be started and stopped from a privileged account anyway • The same as other app components • Using # am startservice # am stopservice
- 39. Unprotected Bound Services • Bound services are used for Remote Procedure Calls (RPCs) • There are several different types of services, as explained in link Ch 7b • Bound services implement the onBind() method inside their service class • This method must return an IBinder • Part of the RPC mechanism
- 40. Three Ways an App Can Implement a Bound Service • Extending the Binder class • Returning an instance of the service class in the onBind method • Not possible across the sandbox • Can only be bound to by other parts of the same app • Using a messenger • Apps send Message objects to each other
- 41. Three Ways an App Can Implement a Bound Service • Using AIDL (Android Interface Description Language) • Uses Inter-Process Communication (IPC) • Makes methods in an app available to other apps over the sandbox • To use, populate the .aidl files in the source code folder with interface definitions • Rarely used; more complex than messengers
- 42. Attacking a Messenger Implementation • Start by examining the handleMessage() method in the bound code • Shows what messages are expected and how functions are executed
- 43. Sieve Has Two Services • In AndroidManifest.xml
- 44. • First parameter should be 2354 to do a MSG_CHECK • 7452 for KEY, 9234 for PIN AuthService Source Code
- 45. Requesting Password from Another App • This works if you know the PIN • (It could be brute-forced)
- 46. Abusing Broadcast Receivers • Can be unprotected, so any other app can listen to it • Example workflow: • App takes login creds, verifies them with a server on the Internet • If they are correct, it sends a broadcast com.myapp.CORRECT_CREDSAb • The app receives the broadcast with an intent filter (see next slide)
- 47. Unprotected Receiver • Any app could send the intent with • run app.broadcast.send
- 48. CVE-2013-6272 • Vulnerable broadcast receivers in the Android codebase • Allows any app to initiate and terminate phone calls • On Android 4.4.2 and earlier
- 49. Intent Snif fi ng • A receiver can register to receive broadcasts intended for other apps • Possible if the app doesn't require a permission to receive the intent
- 50. Example • If an app sends an intent with secrets like this
- 51. Example • Any app can sniff it like this
- 52. Without Drozer
- 53. Secret Codes • Numbers to type on the keypad to do special things
- 54. • Dial *#*#4636#*#* • Doesn't work in Android Studio Emulator Secret Codes
- 55. Opens Testing
- 56. Remote Wipe • Samsung Galaxy devices could be remote wiped • *2767*3855# did factory reset without prompting the user • Could be invoked from a Web page with the tel: handler • <iframe src="tel: *2767*3855#"></iframe>
- 58. 7b