mobile application security - amazon s3mobile application security june 25, 2015. about us ... 3rd...

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