mobile application security - amazon s3mobile application security june 25, 2015. about us ... 3rd...
TRANSCRIPT
www.nvisium.com
Jack ManninoAnand Vemuri
Mobile Application Security
June 25, 2015
www.nvisium.com
About Us• Jack Mannino
• CEO at nVisium
• UI and UX development impaired
• Enjoys: Scala, Elixir
• Tolerates: Java
• Allergic To: Cats, Pollen, .NET
• Anand Vemuri• AppSec Consultant at nVisium
• Tech Junkie, JavaScript Ninja Wannabe
• Software Dev-turned-Hacker
• Bamboo Flute Player
www.nvisium.com
Disclaimer: Mobile device management (MDM) is not mobile application security.
www.nvisium.com
What is Mobile Security?
• Access
• Privacy
• Safety
“Apps are built for users, so as developers we must ensure that users are not compromised…”
www.nvisium.com
What’s the big deal?
• Integration with many other services• IoT
• Wearables
• Payments
• Other API’s
www.nvisium.com
Mobile Architectures and Attack Surface
www.nvisium.com
Mobile Architectures and Attack Surface
www.nvisium.com
Mobile Architectures and Attack Surface
www.nvisium.com
Secure Communications
• Not Just HTTP• Other protocols
• NFC
• Bluetooth/Bluetooth LE
• Issues related to• Ignoring certificate
exceptions
• Trusting all certificates
• Fallback to plain text
• Improper key exchange
• Weak algorithms/ciphers
www.nvisium.com
• Registration Authorities validate user identity
• Certificate Authority verifies and issues certificate
• Validation Authority validates certificate
Public Key Infrastructure
www.nvisium.com
Self-Signed Certs• User can sign the cert
by themselves.• If apps accept self-
signed certs then attackers can execute SSL MITM attacks.
www.nvisium.com
Demo: MITM
www.nvisium.com
Certificate Pinning• “Pin” the client-certificate known to be used to the server• Removes CA from the equation• Prevents against Self-Signed Cert attacks• Significantly reduces threat of rogue certs
*Note: If you are pentesting apps with cert pinning you can use iOS Kill Switch or Android’s SSL bypass tool. Use at your own risk! https://github.com/iSECPartners/ios-ssl-kill-switchhttps://github.com/iSECPartners/android-ssl-bypass
www.nvisium.com
Securing Communications
• Disable HTTP endpoints and avoid falling back to plain-text• If a request over TLS fails,
kill the socket, don’t default back to HTTP.
• Don’t use self-signed certs just because “it’s easier”
• Use Certificate Pinning• Perfect Forward Secrecy• Use HSTS, use TLS, avoid SSL
www.nvisium.com
Data Storage and Privacy• Sensitive Info
○ Shared Preferences○ SQLite○ Storage Access Framework○ Logs, caches, temp files, etc.
• Privacy○ What to collect
○ Who to share it with
○ Ask for consent■ http://www.coppa.org/
■ https://www.ftc.gov/reports/mobile-privacy-disclosures-building-trust-through-transparency-federal-trade-commission
www.nvisium.com
Storing Sensitive Information• Avoid storing sensitive
information in SQLite or Shared Preferences
• Attackers can trivially dump these databases
• If sensitive data must be stored on a client device, then the data store should be properly encrypted
• External Storage has weaker permissions.
https://www.zetetic.net/sqlcipher/
www.nvisium.com
Privacy• Collect only whatever
data is needed for the app• Do you know what gets
sent to your ad and analytics services?
• Children’s online privacy protection act http://www.coppa.org/
www.nvisium.com
Privacy
www.nvisium.com
Privacy
www.nvisium.com
Demo: Insecure Data Storage
www.nvisium.com
Encryption• Encryption
○ Symmetric/Asymmetric Encryption
■ weak hashing
■ weak algorithms and ciphers (ECB etc)
○ Key Storage
■ Keystore
■ ephemeral
■ (bad) hardcode or store
○ Hardware-Backed Storage
•
•
www.nvisium.com
Encryption
www.nvisium.com
Authentication• To a device
○ pin/password
○ biometrics, Smart Unlock
• To the local application○ local passcode
• To a remote service○ username/password
○ certificates
○ 3rd party provider/API
www.nvisium.com
Remote Authentication• Correct: Users should
properly authenticate to the application and be granted a session token.
• Incorrect: Your imagination is the limit.
• Identity management is complicated
www.nvisium.com
Authorization : Insecure Direct Object Reference
• Common Web Vulnerability
• OWASP A4
• Backend service does not restrict references to restricted resources.
www.nvisium.com
App-To-App Authorization
• Permissions - required to use certain APIs or components
• Intent filter - Specifies the criteria for Intents it accepts based on the intent’s action, data, category etc.
• Exported By Default - Android Studio exports Services and Broadcast Receivers by default
• Malicious apps can leverage misconfigured permissions to abuse components within other apps
www.nvisium.com
Demo: Abusing Broadcast Receivers
www.nvisium.com
Conclusions
• Secure all communications!○ Certificate Pinning
• Store your data securely○ Encrypt any sensitive data on client.
• Respect User Privacy• AuthN & AuthZ
○ Permissions & Identity
• “Don’t trust users!”
www.nvisium.com
Thank You
Jack Mannino, CEO of nVisium○ Twitter: @jack_mannino○ Linkedin:https://www.linkedin.com/pub/jack-
mannino/7/2b7/562
○ Blog: https://blog.nvisium.com/
Anand Vemuri, AppSec Consultant at nVisium○ Linkedin:https://www.linkedin.com/pub/anand-
vemuri/58/15/348
○ Twitter: @brownhat57○ Blog: http://brownhat57.blogspot.com