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.

Hacking Mobile Apps

1,264 views

Published on

Mobile apps are the entry point to your web applications, APIs and web services. But sometimes the developer implements security in the mobile app that can easily be bypassed by a malicious attacker, allowing the attacker to exploit your web applications and steal confidential information. In this presentation I will show you how easy it is to attack a mobile application, intercept the communication and exploit the trust model of mobile apps. I will also give an overview of the OWASP Top 10 Mobile Risks.

Published in: Education
  • Be the first to comment

  • Be the first to like this

Hacking Mobile Apps

  1. 1. Erwin Geirnaert – Chief Hacking Officer ”Hacking Mobile Apps” – Infosecurity 2016 www.zionsecurity.com
  2. 2. About ZIONSECURITY > 10 years of experience in Application Security Founded in 2005 by Erwin Geirnaert, recognized expert in (web) application security, and Jessica Nieuwdorp Main office in Leuven (Rotselaar) Experience in securing business and e-business (mobile) applications, e-commerce shops and network infrastructure Hacking IoT, mobile apps, SCADA, CCTV/Badges, … + 10 people Since October 2015 member of the SecureLink Group ZIONSECURITY
  3. 3. Hacking Mobile Apps
  4. 4. What can you do with a mobile app? • Mobile banking • Make payments • Unlock your house • Drive your car • Store passwords
  5. 5. On Vulnerabilities and Malware 5
  6. 6. 6 Android vs iOS vs Windows 8.1 Windows 8.1 (Feb. 2016)
  7. 7. 7 Android vs iOS vs Windows 8.1 Android (Feb. 2016)
  8. 8. 8 Android vs iOS vs Windows 8.1 iOS (Feb. 2016)
  9. 9. 9 Android vs iOS vs Windows 8.1 203 in 4 years 808 in 10 years 187 in 8 years
  10. 10. Many vulnerabilities != a lot of malware 10
  11. 11. Malware families 11 • Far more “malware” for Android than for iOS • Virtually no malware uses any vulnerability • they just ask for the permissions they need • or they only work on rooted or jailbroken device • Due to the lack of distribution channel for malware for iOS • Apple Store vetting more strict than Google Play • Android open to other stores Vs only 1-3 for IOS!
  12. 12. OWASP Top 10 Mobile Risks 12
  13. 13. Mobile Application Threat Model 13 Victim App Malicious App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  14. 14. Mobile Threat Model
  15. 15. OWASP Mobile Top 10 Risks 2014
  16. 16. OWASP TOP10 2014 16 Top of the list: M1: Weak Server Side Controls Victim App Malicio us App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  17. 17. M1- Weak Server Side Controls
  18. 18. Discovery 18 Public APIs are designed to be used by ‘external’ parties • Documentation • API descriptors in standard formats • URI-style: Swagger, RAML, API-Blueprint, I/O Docs, etc. • SOAP: WSDL/XML-Schema • Hypermedia: JSON-LD, Siren, Hydra, etc. • This obviously helps in the discovery phase 
  19. 19. Swagger example 19 "paths": { "/pet/{petId}": { "delete": { "tags": ["pet"], "summary": "Deletes a pet", "description": "", "operationId": "deletePet", "produces": ["application/json", "application/xml"], "security": [{ "petstore_auth": ["write:pets", "read:pets"] }] "parameters": [{ "name": "petId", "in": "path", "description": "Pet id to delete", "required": true, "type": "integer", "format": "int64" }], . . . Attack point HTTP method, how does it handle unspecified methods? OAUTH 2: which implementation?, known vulnerabilities? How does it validate tokens? Scopes? Is access validated? Link between user and petId? Are IDs random? Injection? XSS? What if we do not set the “petId”? What if we do not give an int? Or > int64 max size?
  20. 20. “Classic Discovery” in case the API is secret 20 What about just keeping your API secret? • Local Proxy or network sniffer • Guess / brute-force APIs • http://api.*.com/api/v?/*.json
  21. 21. Public API with a secret API key… 21 March 2014 Issue was already reported to them in 2010...
  22. 22. Story 22 • Install the official Android App • Use local proxy to intercept traffic • Start App, enter garbage at login page (over HTTP!) • GET /handler.php?CritickerKey=xxxxx&Function=UserSignin&UserName=asdfasdf& Password=6d2dedb5b9e02d466a8d98b4c4398b1d • The Criticker API has a call to get the list of users! • GET handler.php?CritickerKey=xxxxx&Function=AccountUsers • And a call to request the current password! In plaintext! Of any user! Without authentication - zucht • GET handler.php?CritickerKey=xxxxx&Function=LookupPassword&UserId=xxxxx
  23. 23. What did they do wrong? 23 • They created an API with “useless”, dangerous and documented features • Call to get list of all users? • Call to get password of a any user? • Passwords are stored in plain text on the server • They use plain HTTP (no SSL) • Their one and only “API key” is sent over the network with every call
  24. 24. Tesla API 
  25. 25. OWASP TOP10 2014 25 M2: Insecure Data Storage Victim App Malicio us App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  26. 26. People are Curious Creatures 26 • From a 2011 study [McAfee, Ponemom Inst., 4] • 140,000 out of 3.3M (4.1%) of smart phones were lost or stolen in 1 year • 10,000 were recovered • 47% lost at home or hotel room, 29% while in transit • Smartphone Honey Stick Project [Symantec, 2012, 5] • 50 `prepped’ smartphone intentionally ‘lost’ in various cities in US • 96% were accessed by the finders, about 85% checked data on phone • 43% opened the ‘online banking’ app • 53% opened the ‘salaries’ file • 60% checked personal mail • 72% opened photos
  27. 27. iOS System Software Authorization 27 • In general you an install ‘whatever OS you want’ on an Android device by unlocking the bootloader • Apple is trying very hard to force users to always run the latest iOS version available • System Software Authorization makes downgrading very hard • Apple’s update servers generate personalized and digitally signed firmware images; • The mobile device bootloader will only accept signed update images with his unique device ID
  28. 28. What about disk encryption? 28 • Only protects the data at rest. • Operates at the lowest layers of OS • Does not protect data from one App to another • Does not replace applications specific protection of config files, etc.! Apple adds a File Data Protection layer that encrypts on a per-file basis. The keys itself are kept in a Secure Element and releasing the keys depends on the Protection Class of the file. The per-file keys are encrypted with one System Key.
  29. 29. Apple vs FBI (Feb 2016) 29 • In December 2015, 14 people were shot in San Bernardino, California • The FBI recovered an iPhone, and it’s screen is locked • It is not rooted, no SSH • So now they have a court order against Apple to help them, why? • Possibly 10 wrong attempts will erase the System Key • The delay after 9 attempts is 1 hour • So 4 pin is on average 5000 attempts = 200 days • So they ask Apple to build an “update” that will remove the erasure of the System key, remove the delay and allow input through the lightning interface
  30. 30. OWASP TOP10 2014 31 M3: Insufficient Transport Layer Protection Victim App Malicio us App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  31. 31. SSL’s Role 32 SSL – The Good • Secures the actual client authentication; as majority of web authentication is based on passwords/tokens • Compatible with vast amount of clients and servers • ‘Easy’ to set up (hard to do right) • Removes crypto burden from application developers
  32. 32. SSL’s Role 33 SSL – The Bad • Compatibility -> Complexity -> Vulnerabilities • For APIs it is also mostly the only crypto layer • If broken -> huge impact • “But we are using SSL…”: it does not magically make your site secure… • If used with server side certs only, client side authentication is not in scope • Transport layer security -> does not prevent many application layer problems (injection, XSS, etc.)
  33. 33. M3- Insufficient Transport Layer Protection 34 Certificate pinning • Browsers are used to connect to large amount of different sites and hosts • PKI needed to verify all SSL certificates in the world using just a limited set of root certificates • Mobile Apps typically only connect to a couple of web services that are known on before hand • -> makes it possible to embed the certificate in the App itself
  34. 34. OWASP TOP10 2014 36 M4: Unintended Data Leakage Victim App Malicio us App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  35. 35. M4- Side Channel Data Leakage •Logging 3 Screenshots
  36. 36. Logs
  37. 37. OWASP TOP10 2014 39 M5: Poor Authorization and Authentication M9: Improper Session Handling Victim App Malicio us App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  38. 38. M5- Poor Authorization and Authentication • Apparently it is ’not done’ to ask users to enter their credentials more than once in a mobile app • Worst case: username/pwd stored on phone’s local storage • Slighly better: hash stored and keychain used for IOS • Even better: temporary (OAUTH) token stored • Using local authentication to unlock an app and then have the app login to the back-end is not secure…but it happens a lot
  39. 39. Secret API with docs in error message 41 • Basic authentication (over SSL, no cert pinning) • With static fixed username/password for all users (embedded in App) • Only ‘authentication’ is the userID • This userID is sequential (not random) • Returns a help file if you send a wrong API request
  40. 40. OWASP TOP10 2014 42 M10: Lack of Binary Protections Victim App Malicio us App External storage Internal storage Shared Preferences Content Provider Native Libraries / OS User 3rd party services Our web services
  41. 41. M10 Lack of Binary Protection 43 • IOS Applications are hard to reverse and make life difficult for pentesters  • Android Applications are trivial to reverse and return very readable code • HTML, CSS, and JavaScript (i.e. cordova) based frameworks offer very good reversibility…
  42. 42. Code Obfuscation 44 • Android build system includes support for ProGuard • removes unused code • renaming classes, fields, and methods • Makes reverse engineering more difficult • Smaller .apk files • Why use it? Because .apk -> source is trivial.... package a; public class a { static String a = "Hello"; static void a() { System.out.println(a); } public static void main(String[] args) { a(); } }
  43. 43. Android App Reverse Engineering 45 • Tool chain to obtain code from any app in Android apk dex source Get apk from phone (“root”) unzip jar dex2jar JD-GUI Extract dex from apk package Translate dex to jar Decompile bytecode to source
  44. 44. M10 Lack of Binary Protection Prevention Tips 46 • Obfuscate your code for production builds • Know the limitations of obfuscators • String constants may not be obfuscated, if they are this is reversible… • Try to keep “important” business logic on the server
  45. 45. Q&A @ZIONSECURITY www.linkedin.com/in/erwingeirnaert www.zionsecurity.com

×