1 / 75

Hacking (and Defending) iPhone Applications

Hacking (and Defending) iPhone Applications. Garrett Held and Kevin Stadmeyer. Managing Consultants with Trustwave SpiderLabs Have performed hundreds of application tests from mainframe to web to mobile. Who Are We?.

ghada
Download Presentation

Hacking (and Defending) iPhone Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hacking (and Defending) iPhone Applications

  2. Garrett Held and Kevin Stadmeyer • Managing Consultants with Trustwave SpiderLabs • Have performed hundreds of application tests from mainframe to web to mobile • Who Are We?

  3. What we’ll cover – secure coding and beyond, what to look for when assessing an iPhone application • Agenda • The Basics • Setup For Testing • Secure Storage of Data And Credentials • Inadvertent Local Storage and Caching • Client Side Sanitization • Secure Coding • Push Notifications • Secure Communications

  4. The Basics

  5. Why are people attacking mobile apps? • Stealing Money • Embarrassing People (“Hactivists”) • Get Famous • Just the Facts, Ma’am

  6. iPhone Apps in the Press • Just the Facts, Ma’am

  7. How are people attacking mobile apps? • New and unsafe operating systems? • Terrible developers who don’t care? • Clueless users who don’t know they should care? • Just the Facts, Ma’am

  8. What Security Model We’re Not Talking About? • Layer 1: Apple Store • Layer 2: Sandboxing via “Seatbelt” • Just the Facts, Ma’am

  9. Just the Facts, Ma’am

  10. Setting Up The Testing Environment

  11. Don’t you mean setting up the decompiler? • No • Setting Up The Testing Environment

  12. On das metal – Step 1: get your proxy right • We Built This City

  13. On das metal – Step 2: Get ya certs heard! • We Built This City

  14. On das metal – Step 3: Roll It Up • We Built This City

  15. On das metal – Step 4: Mail it! • We Built This City

  16. On das metal – Step 5: Install It • We Built This City

  17. On das metal – Step 6: Install It (Errrr….) • We Built This City

  18. On das metal – Step 7: Proxy It! • We Built This City

  19. On das metal – Step 8: Victory! • We Built This City

  20. On The Computer Machine – Step 6: Install It! • We Built This City

  21. On The Computer Machine – Step 7: Install It! • We Built This City

  22. On The Computer Machine • We Built This City • The format is X’<SHA1 Fingerprint>’

  23. Now What? • We Built This City

  24. Now What? • We Built This City

  25. Now What? • We Built This City

  26. Secure Storage Of Data

  27. The Keychain • Indefinite Storage • Can you store credentials securely without the keychain? • Don’t let the feature make you lazy • Don’t store credentials in the keychain unless you don’t care about certain things • Storing Credentials

  28. Keychain Compromise via Jailbreaking • Through a series of steps, retrieves passwords stored in the keychain [1] • Researchers compromised keychain passwords only, not other protected classes such as passwords for websites • Jailbreak stolen iPhone (requires physical access), gain SSH access • Copy scripts that will compromise the keychain • Scripts output the victims passwords • Storing Credentials [1] http://www.sit.fraunhofer.de/en/Images/sc_iPhone%20Passwords_tcm502-80443.pdf

  29. Where Should You Store Them? • Not on the device? • At least not in plaintext! • Storing Credentials

  30. Securely Storing Data At Rest – things to look for • Database calls? • Injection Possible? • Using Core Data? • Does the application trust the integrity of the data? • Remember trust boundaries! • Storing Credentials

  31. Recommendations for non-credential data • Do not store data on the phone if at all possible • Never has it been so easy to lose so much data so fast! • Require user to enter a passcode • Can still be brute-forced with time once the encrypted text is found • Poor user-experience on mobile devices • Storing Credentials

  32. Recommendations for non-credential data • Store decryption key on a server and require credentials (non-stored) to access key • Only works for applications that do not require offline access • Increases data usage • Revocable though • Data not “stored” in the cloud • Storing Credentials

  33. B-b-b-but kSecAttrAccessibleWhenUnlocked! • By default iOS writes information to the keychain with this attribute • By default most user’s passwords suck • Storing Credentials

  34. Look Familiar? • Storing Credentials

  35. Most Users Pick Simple PINS 10,000 possibilities ~.1 second to crack (100k a second is pretty standard) • Storing Credentials

  36. Protect Stupid Users • Require Strong Passwords (8+ alpha-numeric chars) • Use REAL and GOOD encryption • Don’t rely on an inherently insecure PIN to protect users. • If they knew what they were doing we wouldn’t be here today. • Storing Credentials

  37. Inadvertent Local Storage and Caching

  38. Screenshots • Where are they stored? • When are they taken? • Who can access them! • I Accidently Your Data…

  39. Screenshots • I Accidently Your Data…

  40. Screenshot Protection • I Accidently Your Data…

  41. Other Storage Of Information • Autocomplete, etc. • I Accidently Your Data…

  42. Autocomplete • Override autocomplete • textfield.autocorrectionType = UITextAutocorrectionNone • I Accidently Your Data…

  43. Client Side Sanitization

  44. It’s bad… • Less burden on server • Critical bypasses (yay!) • Client Side? More like Bad side, amirite?

  45. It’s bad… • Some classic Web Application faults translate well into the iPhone. • Web developers relied on: • JavaScript controls • Hidden fields • JSON responses • Information stored in Flash objects • Client Side? More like Bad side, amirite?

  46. Rogue Clients • Attackers can write apps (Some testers, too) • Client side secrets can be decompiled • We don’t care if it’s obfuscated for now, that’s a point in time. • Distributed through trusted App store? • Already happened to Android • Client Side? More like Bad side, amirite?

  47. How To Do It Right • Server Side Controls • Assume everything coming in came from a rouge or compromised client • Enforce secure communications • Client Side? More like Bad side, amirite?

  48. What Applies in the iOS world? • Client Side? More like Bad side, amirite?

  49. CSRF and XSS In Apps? • Calls to browser • Recent Android Issue [1] • Loads javascript:alert(document.cookie) • Embedded browser shares web app issues • Rogue applications and rogue users • Client Side? More like Bad side, amirite? ]1] http://www.crn.com.au/News/265931,video-details-android-browser-intercept-flaw.aspx

  50. Break That Down Into Attackers View • Client Side? More like Bad side, amirite?

More Related