Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

CNIT 128 7. Attacking Android Applications (Part 2)

132 vues

Publié le

For a college class: Hacking Mobile Devices at CCSF

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

Publié dans : Formation
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

×