OWASP top 10 mobile risks

Paweł Rzepa

Important notes

• The goal of this presentation is to provide you a basic knowledge about mobile risks and easy methodology to find those risks in your applications.

• If you want to add anything important/interesting and related to the topic – feel free to interrupt me ;).

What are we going to talk about…

Before we start… the threat model

M2 - Insecure data storage

Insecure data storage – what it is?

• Simple words definition: valuable pieces of data (e.g. passwords, cookies, personal information) are stored in the data-stores on the device in insecure (plain text or reversable encoding) format.

Insecure data storage – what to look for?

• Look for any sensitive information in:– SQLite databases (local)– XML Data Stores– Plain text configuration files– Cookie stores– SD Card

Insecure data storage – how to find?

• Install and run application for some time• Monitor changes in /sdcard before and after

installing an application• Analyze package files on different stages:

adb pull /data/data/<apk_package_name>

Insecure data storage - demo

Insecure data storage – real example

• Outlook stored all attachements as unencrypted and world readable files on external storage.

Insecure data storage - mitigations

• Don’t store data unless it’s absolutely necessarry.

• Use encryption for local storage (use method setStorageEncryption).

• For databases consider using SQLcipher for Sqlite data encryption.

• Ensure any shared preferences properties are NOT MODE_WORLD_READABLE.

M3 - Insufficient transport layer protection

Insufficient transport layer protection – what it is?

• Simple words definition: application does NOT implement TLS or it does incorrectly.

What do you mean „incorrectly”?

• Insecure implementations are:– Using known weak ciphers / version (e.g.

SSLv2/SSLv3, RC4)– Securing only part of the communication (e.g. only

authentication)– Lack of certificate inspection

Certificate inspection in web applications – chain of trust.• In web applications the validation of certificate is on the

side of a browser.• It is done by a „chain of trust”.

• But how a mobile app can know if it is communicating with a proper server?

Cert Pinning - theory

• Embedded in source code expected X509 certificate or public key.

if (presented_cert == pinned_cert)Start_connection();elseDrop_connection();

Cert Pinning - reality

• Guys from Leibniz Universität Hannover tested 100 apps and…

• 21 apps trust all certificates• 20 apps accept all hostnames• And in the end they asked developers why it

happened…

More: https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf

Insufficient transport layer protection- how to find?

• Passive analysis with Wireshark/Burp (to check if all traffic is encrypted)

• Use Mallodroid:./mallodroid.py –f AppToCheck.apk –d ./javaout

• Look for end point implementation flaws using SSLyze (or https://www.ssllabs.com/ssltest/ for public domain):

sslyze --regular www.example.com:443

Insufficient transport layer protection- example

Insufficient transport layer protection-few facts from reality

• According to the FireEye research from July 17 2014, among 1000 most-downloaded free applications in the Google Play store:

Source: https://www.fireeye.com/blog/threat-research/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html

Insufficient transport layer protection- mitigations• Any sensitive data MUST be transfered over TLS• How to do it properly? Follow the rules: https

://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

M4 - Unintended data leakage

Unintended data leakage – what it is?

• Simple word definition: OS/frameworks puts sensitive information in an insecure location in the device.

• Important note: insecure data storage talks about developer conscious efforts to store data in insecure manner, while unintended data leakage refers to OS/framework specific quirks which can cause data leakages.

Unintended data leakage – common leakage points

• URL Caching • Copy/Paste buffer Caching• Logging• Analytics data sent to 3rd parties (e.g. ads

sending GPS location)

Unintended data leakage – how to find?

• Extract data from leaking content providers using Drozer:

dz> run app.provider.finduri <package_name>

• Use logcat to verify what is being logged using ADB:adb logcat [output filter] | grep cookie,username…

• Use listener (Burp/Wireshark) to monitor what is being sent to 3rd parties.

• Use Intent Sniffer to see if any confidential data is sent via Intents.

Unintended data leakage - demo

Unintended data leakage - mitigations

• NEVER log any sensitive information (observe what you’re storing in crashlogs).

• Disable copy/paste function for sensitive part of the application.

• Disable debugging (android:debuggable="false").

M5 - Poor Authorization and Authentication

Poor Authorization and Authentication – what is it?

• Simple words definition: if you’re able to bypass authentication and/or laverage your privileges then… your app has poor authorization and/or authentication.

Poor Authorization and Authentication – how to find?

• Try to bypass authentication by accessing exported activities using Drozer:

dz> run app.activity.start –component <component_name>

• Intercept traffic with Burp and modify parameter to login as other user/see unauthorized content (e.g. by manipulating device ID).

• Test account lockout policy• Test strong password policy

Poor Authorization and Authentication - demo

Poor Authorization and Authentication – real example

• A flaw in application can become an entry point to compromise an operating system.

• For example a Viber app:https://www.youtube.com/watch?time_continue=40&v=rScheIQDD0k

And always remember to…

• …stay reasonable when you’re going to follow advices from the Internet…

Poor Authorization and Authentication - mitigations• Assume that client-side authorization and

authentication controls can be bypassed - they must be re-enforced on the server-side whenever possible!

• Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device. It should be optional and not be enabled by default.

• Do not allow for offline brute force attacks.

M6 - Broken Cryptography

Broken Cryptography – what it is?

• Simple words definition: using insecure implementation or implementing it in a insecure way.

• Few reminders (yeah I know you know it…):– encoding != encryption– obfuscation != encryption

Broken Cryptography – how to find?

• Decompile the apk using dex2jar (or luyten for more verbose result) and review jar file in JD-GUI.

• Look for decryption keys (in attacker-readable folder or hardcoded within binary).

• Try to break encryption algorithm if an application uses custom encryption.

• Look for usage of insecure and/or deprecated algorithms (e.g. RC4, MD4/5, SHA1 etc.).

Broken Cryptography - example

• Encrypted db is definitely a good idea…

Broken Cryptography - example

• …but not when you’re hardcoding passwords to decrypt it in code…

Broken Cryptography – real example

• NQ Vault

Broken Cryptography - mitigations

• Use known, strong cryptography implementations.

• Do not hardcode keys/credentials/OAUTH tokens.

• Do not store keys on a device. Use password based encryption instead.

M7 - Client side injection

Client side injection – what it is?

• Simple words definition: malicious code can be provided as an input and executed by the application (on the client side).

• The malicious code can come from:– Other application via intent/content provider– Shared file– Server response– Third party website

Client side injection – what to inject?

• SQL injection to local db• XSS/WebView injection• Directory traversal

• Intent injection

A new Android’s toy – the Intents• Android application can talk

(Inter-Process-Communication) to any other component (e.g. other application, system service, running new activity etc.) via special objects called Intents.

Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse(„https://owasp.org”));Intent i = new Intent(android.provider.MediaStore.Action_IMAGE_CAPTURE);

Client side injection – how to find?

• SQL injections:dz> run scanner.provider.injection –a <package_name>

• Data path traversaldz> run scanner.provider.traversal –a <package_name>

• Intent injectionsdz> run app.package.manifest –a <package_name>dz> run app.activity.info –a <package_name>

dz> run app.service.info --permission null –a <package_name>dz> run intents.fuzzinozer --package_name <package_name> --

fuzzing_intent

Client side injection - demo

Client side injection – real example• The UniversalMDMClient (built-in application Samsung KNOX

– a security feature to seperate personal and professional activities).

• Crafted URI with „smdm://” prefix allows for remote installation of ANY application, while a user thinks he’s installing an update for UniversalMDMClient.

• How it works in practice? https://www.youtube.com/watch?time_continue=56&v=6O9OBmsv-CM

Client side injection - mitigations

• Always validate on a server side any user input!• For internal communication use only explicit

Intents.• Avoid using Intent-filter. Even if the Activity has

atribute „exported=false” another application can define the same filter and a system displays a dialog, so the user can pick which app to use.

M9 - Improper session handling

Improper session handling – what it is?

• Simple words definition: if your session token can be guessed, retrieved by third party or never expires then you have a problem.

Improper session handling – how to find?

• Intercept requests with proxy (e.g. Burp) and verify if:– Verify if a session expires (copy a cookie and try to use it

after 30 minutes)– Verify if a session is destroyed after authentication state

changes (e.g. switching from any logged in user to another logged in user)

– Verify if you are able to guess any other session (e.g. it’s easy to impersonate other user when application uses device ID as a session token)

Improper session handling – few facts from reality

• What we know is that „sessions have to expire”…

• …but how long should it REALLY last?• According to experiment* the average application

session (counted from opening an app to closing it) lasts… 71.56 seconds.

* - http://www.mendeley.com/research/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/

Improper session handling - mitigations

• Invalidate session on a server side.• Set session expiration time adjusted to your

application.• Destroy all unused session tokens.• Use only high entropy, tested token

generation resources.

Thank you!

References• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks• https://github.com/ikust/hello-pinnedcerts• http://www.exploresecurity.com/testing-for-cipher-suite-preference/• http://resources.infosecinstitute.com/android-hacking-security-part-4-exploiting-unintended-data-leakage-side-channel-data-leakage/• http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks• https://manifestsecurity.com/android-application-security/• https://mobilesecuritywiki.com/• http://androidcracking.blogspot.de/2014/02/zerdeis-luyten-worthwhile-jd-gui.html• https://www.acsac.org/2011/openconf/modules/request.php?module=oc_program&action=view.php&a=&

id=111&type=3&OPENCONF=54jm3hh7laelc19qq6ernql5m2• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Mobile_Threat_Model• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Security_Testing• https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf• https://www.ssllabs.com/ssltest/• http://www.slideshare.net/ibmsecurity/overtaking-firefox-profiles-vulnerabilities-in-firefox-for-android• http://resources.infosecinstitute.com/cracking-nq-vault-step-by-step/• http://www.slideshare.net/ibmsecurity/pinpointing-vulnerabilities-in-android-applications-like-finding-a-needle-in-a-haystack• https://github.com/linkedin/qark• https://www.mendeley.com/catalog/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/• http://blog.quarkslab.com/abusing-samsung-knox-to-remotely-install-a-malicious-application-story-of-a-half-patched-vulnerability.html• http://www.bkav.com/top-news/-/view_content/content/46264/critical-flaw-in-viber-allows-full-access-to-android-smartphones-bypassing-lock-screen• http://thehackernews.com/2014/05/microsoft-outlook-app-for-android.html• https://drive.google.com/file/d/0BxOPagp1jPHWVnlzWGNVbFBMTW8/view?pref=2&pli=1