A basic guide how to look for OWASP mobile top 10 risks in Android applications using AppUse and opesource tools.

1. OWASP top 10 mobile risks
Paweł Rzepa

2. 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 ;).

3. What are we going to talk about…

4. Before we start… the threat model

5. M2 - Insecure data storage

6. 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.

7. 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

8. 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>

9. Insecure data storage - demo

10. Insecure data storage – real example
• Outlook stored all attachements as
unencrypted and world readable files on
external storage.

11. 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.

12. M3 - Insufficient transport layer
protection

13. Insufficient transport layer protection
– what it is?
• Simple words definition: application does NOT
implement TLS or it does incorrectly.

14. 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

15. 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?

16. Cert Pinning - theory
• Embedded in source code expected X509
certificate or public key.
if (presented_cert == pinned_cert)
Start_connection();
else
Drop_connection();

17. 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

18. 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

19. Insufficient transport layer protection-
example

20. 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

21. 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_Protectio
n_Cheat_Sheet

22. M4 - Unintended data leakage

23. 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.

24. 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)

25. 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.

26. Unintended data leakage - demo

27. 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").

28. M5 - Poor Authorization and
Authentication

29. 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.

30. 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

31. Poor Authorization and Authentication
- demo

32. 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

33. And always remember to…
• …stay reasonable when you’re going to follow
advices from the Internet…

34. 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.

35. M6 - Broken Cryptography

36. 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

37. 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.).

38. Broken Cryptography - example
• Encrypted db is definitely a good idea…

39. Broken Cryptography - example
• …but not when you’re hardcoding passwords
to decrypt it in code…

40. Broken Cryptography – real example
• NQ Vault

41. 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.

42. M7 - Client side injection

43. 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

44. Client side injection – what to inject?
• SQL injection to local db
• XSS/WebView injection
• Directory traversal
• Intent injection

45. 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);

46. Client side injection – how to find?
• SQL injections:
dz> run scanner.provider.injection –a <package_name>
• Data path traversal
dz> run scanner.provider.traversal –a <package_name>
• Intent injections
dz> 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

47. Client side injection - demo

48. 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

49. 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.

50. M9 - Improper session handling

51. 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.

52. 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)

53. 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/

54. 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.

55. Thank you!

56. 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=54jm3hh7l
aelc19qq6ernql5m2
• 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