CNIT 128 3. Attacking iOS Applications (Part 1)
0 likes351 views
For a college class: Hacking Mobile Devices at CCSF Based on "The Mobile Application Hacker's Handbook 1st Edition", by Dominic Chell Instructor: Sam Bowne More info: https://samsclass.info/128/128_S19.shtml
![Kali linux and some features [view in Full screen mode]](https://cdn.slidesharecdn.com/ss_thumbnails/kali-171205224458-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to CNIT 128 3. Attacking iOS Applications (Part 1) (20)
More from Sam Bowne (20)
Recently uploaded (20)
CNIT 128 3. Attacking iOS Applications (Part 1)
- 1. CNIT 128 Hacking Mobile Devices 3. Attacking iOS Apps Part 1
- 2. Topics: Part 1 • Introduction to Transport Security • Identifying Insecure Storage • Patching iOS Applications with Hopper
- 3. Topics: Part 2 • Attacking the iOS Runtime • Understanding Interprocess Communication • Attacking Using Injection
- 4. Attack Scenarios • From the network • Tainted data from server-side applications • Physical access to the phone • Interactive access to the phone • Control of another app on the phone
- 6. Cleartext Channels • Such as HTTP • Never safe • Even if not transmitting sensitive data like passwords • Because an attacker could inject JavaScript
- 7. Finding Cleartext • Examine traffic with Wireshark or Burp
- 8. Three SSL/TLS Implementations • The URL loading system • The Carbon Framework • The Secure Transport API
- 9. The URL Loading System • High-level classes and methods like • NSURLConnection • NSURLSession • Simplest method • Most widely adopted
- 10. Carbon Framework • More granular API than the URL loading system • Gives developers greater control over network requests • Implemented using the CFNetwork class
- 11. Secure Transport API • Low-level API • The foundation of CFNetwork and the URL loading system • Greatest control over the transport • Complex to implement • Rarely used directly
- 12. Certificate Validation • SSL and TLS use certificate-based authentication to • Ensure that you are communicating with the desired server • Prevent eavesdropping and tampering attacks • Unless the validation is weakened
- 13. Trusted CA • Certificates must be signed by a trusted Certificate Authority (CA) • Accepting self-signed or unvalidated certificates undermines TLS and SSL • Allowing MiTM attacks
- 14. NSURLConnection Class • Developer can allow self-signed certificates • By customizing the didReceiveAuthenticationChallenge method
- 15. Carbon Framework • Can allow self-signed certficates by setting up an SSL settings dictionary • That sets the kCFStreamSSLValidatesCertificateChain constant to false
- 16. Secure Transport API • Setting the kSSLSessionOptionBreakOnServerAuth option • Disables the API's certificate validation • But the app might have its own trust evaluation routines, like certificate pinning
- 17. Certificate Problems • Self-signed certificates • Expired certificates • Mismatched hostnames • Expired root CA certificates • Allowing any root certificate
- 18. Dynamic Testing • Route traffic through the Burp proxy • Browser detects the SSL error
- 19. GOTO Fail
- 22. SSL Session Security • There are other possible SSL errors if an app is using the Carbon framework or the Secure Transport API • But not if it uses the high-level URL loading API • Because there is no way to modify the SSL/TLS session properties
- 23. Protocol Versions • CFNetwork and Secure Transport APIs • Both allow a developer to modify the protocol version • SSLv2 and SSLv3 are vulnerable
- 24. CFNetwork API (Carbon Framework) Protocol Settings • These settings specify vulnerable versions • kCFStreamSocketSecurityLevelSSLv2 • kCFStreamSocketSecurityLevelSSLv3 • kCFStreamSocketSecurityLevelTLSv1 • These settings allow negotiation of insecure versions • kCFStreamSocketSecurityLevelNone • kCFStreamSocketSecurityLevelNegotiatedSSL
- 25. Secure Transport API Protocol Settings • These settings allow vulnerable versions • kSSLProtocolUnknown • kSSLProtocol3 • kTLSProtocol1 • kTLSProtocol11 • kDTLSProtocol1 • This is the preferred setting • kTLSProtocol12
- 27. Specific Cipher Suite • Developer may specify an insecure suite • Secure Transport and CFNetwork APIs allow this
- 28. Intercepting Encrypted Communications • Necessary to test apps • Must install the Burp certificate on the phone
- 29. Bypassing Certificate Pinning • An app has information about the correct certificate embedded in it • And refuses to connect with other certificates • This must be bypassed to view the network traffic
- 30. Substrate Tweaks
- 32. Local Storage • An attacker can steal local data when • The phone is stolen while unlocked • The Touch ID sensor is bypassed • Remote compromise through exploitation • Default credentials on jailbroken phones • There is no passcode • Pairing with a malicious computer • Exploiting the boot chain
- 33. Storage Errors • Stored by app in plaintext • Using custom encryption with insecure key • Stored with wrong data protection class • Inadvertently stored by iOS
- 35. Protection Classes • No Protection • Not encrypted • Unsuitable for sensitive data • Complete Until First User Authentication • Discouraged for sensitive data
- 36. Identifying Data Protection Classes • If data can be backed up • Back up, then use
- 37. Keychain Items • keychain_dump creates plist files • protection_class key inside them
- 38. Dynamic Analysis • Tests stored data that doesn't get backed up • Use Cydia Substrate • The old Snoop-It tool was helpful, but it's gone
- 39. Patching iOS Applications with Hopper
- 40. Get the Binary • Project M 702
- 43. Pseudo Code