Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CNIT 128 7. Attacking Android Applications (Part 2)

121 views

Published on

For a college class: Hacking Mobile Devices at CCSF

Instructor: Sam Bowne
More info: https://samsclass.info/128/128_S19.shtml

Published in: Education
  • Be the first to comment

  • Be the first to like this

CNIT 128 7. Attacking Android Applications (Part 2)

  1. 1. CNIT 128 Hacking Mobile Devices 7. Attacking Android Applications Part 2
  2. 2. Topics • Part 1 • Exposing Security Model Quirks • Attacking Application Components 
 (to p. 271: "Trust Boundaries") • Part 2 • Attacking Application Components (finishes)
  3. 3. Topics • Part 3 • Accessing Storage and Logging • Misusing Insecure Communications • Exploiting Other Vectors • Additional Testing Techniques
  4. 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 devloper must implement authentication mechanisms
  5. 5. Failed Trust Boundary • Open Sieve • Settings option available before login
  6. 6. Sieve • Exported activities • Can be started from any app
  7. 7. Sieve • Unexported activities • Can be launched from root account
  8. 8. Sieve • Cannot run through Drozer • Run as root from shell
  9. 9. Sieve • Settings opens
  10. 10. Exploiting Insecure Content Providers
  11. 11. Unprotected Content Providers • Not explicitly marked exported="false" in Manifest • Exported by default for target SDK < API 17 • Drozer provides • run app.provider.info
  12. 12. Content Providers • No permissions required, except for /Keys path
  13. 13. Finding URI Paths • Finds strings in the DEX file beginning with content:// • There may be other URIs • Here it finds /Passwords
  14. 14. Query • Exposes passwords, but in an encoded form
  15. 15. Insert Data • Duplicate the unknown password
  16. 16. content • You can do this from a shell without Drozer with • content query
  17. 17. Unexported Content Providers • Find them with • run app.provider.info -a <app> -u • Must query them with content from a root shell
  18. 18. SQL Injection
  19. 19. 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
  20. 20. SQLite • Send these parameters: • URI: content://settings/system • projection: * • Query becomes • select * from system
  21. 21. SQLite Injection • Sending an apostrophe breaks syntax • projection parameters is vulnerable
  22. 22. Finding Table Names
  23. 23. Dumping Keys Table
  24. 24. Drozer Finding Tables • run scanner.provider.sqltables
  25. 25. Mapping to a Web Interface • Map content providers to a Web interface • With the Drozer module auxiliary.webcontentresolver • Binds the provider to a port
  26. 26. Mapping to a Web Interface • Ony works on older Android versions • Allows use of sqlmap
  27. 27. 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
  28. 28. • Because the content providers did not require read permissions • Also a SQL injection in the telephone app Samsung Vulnerabilities
  29. 29. File-Backed Content Providers • A content provider may allow other apps to retrieve files • By creating a content prodicer 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
  30. 30. Local File Inclusion in Sieve • Read /system/etc/hosts • Demonstrates vulnerability •
  31. 31. • Reveal master password • Command somewhat different from textbook • I did it on Android 9 Local File Inclusion in Sieve
  32. 32. Detect Directory Traversal Vulnerability • run scanner.provider.traversal -a content:// com.mwr.example.sieve.FileBackupProvider
  33. 33. Notice the /Keys Path
  34. 34. Look in Manifest • Permission only applies for path exactly matching /Keys
  35. 35. /Keys v /Keys/ • Adding / causes permissions to stop applying
  36. 36. Attacking Insecure Services
  37. 37. 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
  38. 38. 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 • run app.service.start in Drozer to interact with these "started services"
  39. 39. 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
  40. 40. Unexported Services • They can be started and stopped from a privileged account anyway • The same as other app components • Using # am startservice # am stopservice
  41. 41. Unprotected Bound Services • Bound services are used for Remote Procedure Calls (RPCs) • Bound services implement the onBind() method inside their service class • This method must return an IBinder • Part of the RPC mechanism
  42. 42. 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
  43. 43. 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
  44. 44. Attacking a Messenger Implementation • Start by examining the handleMessage() method in the bound code • Shows what messages are expected and how functions are executed
  45. 45. Sieve Has Two Services
  46. 46. • First parameter should be 2354 to do a MSG_CHECK • 7452 for KEY, 9234 for PIN AuthService Source Code
  47. 47. Requesting Password from Another App • This works if you know the PIN • (It could be brute-forced)
  48. 48. 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 • Sends a broadcast com.myapp.CORRECT_CREDS
  49. 49. Unprotected Receiver • Any app could send the intent with • run app.broadcast.send
  50. 50. 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
  51. 51. Intent Sniffing • A receiver can register to receive broadcasts intended for other apps • Possible if the app doesn't require a permission to receive the intent
  52. 52. Example • If an app sends an intent with secrets like this
  53. 53. Example • Any app can sniff it like this
  54. 54. Secret Codes • Numbers to type on the keypad to do special things
  55. 55. • Dial *#*#4636#*#* Secret Codes
  56. 56. Opens Testing
  57. 57. 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 • <frame src="tel: *2767*3855#"></iframe>
  58. 58. Demo • http://ad.samsclass.info/128/settings.htm

×