Explaining common mobile application security weaknesses and how to mitigate them. Presentation by Adrian Hayter and Andy Swift at the CNS Security Chapter event series.

1. .
Mobile Application (In)security
Explaining common mobile application security weaknesses and
how to mitigate them.
Adrian Hayter & Andy Swift
CNS Hut 3 Team
adrian.hayter@hut3.net / andy.swift@hut3.net

2. .
Attack Vectors
When penetration testing a mobile application, CNS Hut3 focuses
on four distinct areas:
• The Mobile Application
• The Mobile Device – iPhone, Android, Windows Mobile, etc.
• The Network – everything between the device and the server!
• The Server – most mobile applications interface with one.
Adrian Hayter & Andy Swift
Page: 2/25

3. .
Apps World
CNS Hut3 went to Apps World...
...and met some random American guy (Steve Wozniak).
Adrian Hayter & Andy Swift
Page: 3/25

4. .
How much do developers know about security?
Which of these counts as confidential data?
(a) Usernames & Passwords.
(b) Documents obtained after successful authentication.
(c) Session tokens.
(d) All of the above.
Adrian Hayter & Andy Swift
Page: 4/25

5. .
How much do developers know about security?
Which of these counts as confidential data?
(a) Usernames & Passwords. (8%)
(b) Documents obtained after successful authentication. (4%)
(c) Session tokens. (0%)
(d) All of the above. (88%)
Adrian Hayter & Andy Swift
Page: 5/25

6. .
How much do developers know about security?
Which of the following is best practice for data sent to web servers?
(a) Send login credentials over HTTPS. Use regular HTTP for
everything else.
(b) Force everything to be sent over HTTPS.
(c) Provide both HTTP and HTTPS and let the user choose.
(d) Allow HTTP but redirect immediately to HTTPS.
Adrian Hayter & Andy Swift
Page: 6/25

7. .
How much do developers know about security?
Which of the following is best practice for data sent to web servers?
(a) Send login credentials over HTTPS. Use regular HTTP for
everything else. (8%)
(b) Force everything to be sent over HTTPS. (76%)
(c) Provide both HTTP and HTTPS and let the user choose.
(4%)
(d) Allow HTTP but redirect immediately to HTTPS. (12%)
Adrian Hayter & Andy Swift
Page: 7/25

8. .
How much do developers know about security?
How should passwords be stored?
(a) In plaintext.
(b) Encoded using Base64.
(c) Salted and then hashed.
(d) Hashed and then salted.
Adrian Hayter & Andy Swift
Page: 8/25

9. .
How much do developers know about security?
How should passwords be stored?
(a) In plaintext. (0%)
(b) Encoded using Base64. (20%)
(c) Salted and then hashed. (56%)
(d) Hashed and then salted. (24%)
Adrian Hayter & Andy Swift
Page: 9/25

10. .
How much do developers know about security?
Which of these is the best choice for encrypting sensitive files?
(a) SHA-3
(b) Develop our own (secret) in-house encryption mechanism.
(c) AES-256
(d) 3DES
Adrian Hayter & Andy Swift
Page: 10/25

11. .
How much do developers know about security?
Which of these is the best choice for encrypting sensitive files?
(a) SHA-3 (16%)
(b) Develop our own (secret) in-house encryption mechanism.
(4%)
(c) AES-256 (76%)
(d) 3DES (4%)
Adrian Hayter & Andy Swift
Page: 11/25

12. .
How much do developers know about security?
Which is the correct attitude to have towards server-side security?
(a) We should put more focus on server-side security.
(b) We should put equal focus on both server-side and app-side
security.
(c) We don’t need to focus on server-side security because the app
is secure.
(d) We should put more focus on app-side security but be aware of
server-side security issues.
Adrian Hayter & Andy Swift
Page: 12/25

13. .
How much do developers know about security?
Which is the correct attitude to have towards server-side security?
(a) We should put more focus on server-side security. (20%)
(b) We should put equal focus on both server-side and
app-side security. (68%)
(c) We don’t need to focus on server-side security because the app
is secure. (0%)
(d) We should put more focus on app-side security but be aware of
server-side security issues. (12%)
Adrian Hayter & Andy Swift
Page: 13/25

14. .
Sensitive Data Storage
As an application developer, you have (almost) no control over the
user’s device. Presume the device is already compromised.
If at all possible, don’t store sensitive data on the device.
Sensitive Data includes:
• Credentials (e.g. passwords, keys, etc.)
• Session tokens (e.g. cookies)
• Files containing user information.
Mitigation: If you handle sensitive data, encrypt it before saving it
to the device. Use a strong encryption algorithm like AES-256.
Adrian Hayter & Andy Swift
Page: 14/25

15. .
Device Caches
Many devices keep caches of user input and other data relating to
the application.
• Temporary Files – Downloads, Documents, etc.
• User Dictionary – Depending on input type.
• Application Snapshots (iOS)
Mitigation: Remove files once they are no longer needed. Specify
correct input types. Disable caches if possible.
Adrian Hayter & Andy Swift
Page: 15/25

16. .
Device Caches: iOS Dictionary
Accessible via jailbreaking:
• /private/var/mobile/Library/Keyboard/dynamic-text.dat
• /private/var/mobile/Library/Keyboard/en_GB-dynamic-
text.dat
The iOS “DynamicDictionary” keeps a record of everything typed
into text boxes (Google searches, Facebook messages, SMS, email,
etc.)
Adrian Hayter & Andy Swift
Page: 16/25

17. .
Insecure Data Transmission
If data is sent over an unencrypted channel, it can be intercepted
and modified.
You can’t control which networks a user connects to. How many
people can resist free WiFi networks at coffee shops?
Even trusted networks can’t be relied on due to Evil-twin attacks.
Mitigation: Transmit data over an SSL / TLS connection at all
times.
Adrian Hayter & Andy Swift
Page: 17/25

18. .
SSL / TLS
SSL / TLS misconfigurations are some of the most common
security weaknesses.
Application side:
• Weak cipher selection.
• Accepting invalid certificates.
Server side:
• Supporting old protocols, weak ciphers.
• Renegotiation Denial of Service, BEAST, CRIME, BREACH
Mitigation: Mostly configuration file changes!
Adrian Hayter & Andy Swift
Page: 18/25

19. .
Jailbreaking / Rooting
People are always going to jailbreak / root their phones. They will
be able to access your application files, and possibly decompile the
application.
There is no point trying to perform “jailbreak detection”
techniques. Your application runs with low privileges. A jailbroken
/ rooted device will always be able to evade this detection.
Mitigation: Focus more on security of your application that trying
to prevent people reading your code. If you have code in your
application that you don’t want people to see, you shouldn’t be
letting people put it on their devices in the first place!
Adrian Hayter & Andy Swift
Page: 19/25

20. .
Android “Master Key” Exploits
A vulnerability found in early 2013 effectively allowed an attacker
to embed malicious code within a trusted and signed application
without invalidating the signature.
Despite its name, the “Master Key” exploits don’t actually expose
any Android keys. Instead, a vulnerability in the handling of the
ZIP-based APK files allows code modification.
Mitigation: Upgrade to Android 4.4. All previous versions are
vulnerable (approximately 99% of all Android devices).
Adrian Hayter & Andy Swift
Page: 20/25

21. .
User Stupidity
Adrian Hayter & Andy Swift
Page: 21/25

22. .
User Stupidity
Mitigation: None Known.
Adrian Hayter & Andy Swift
Page: 21/25

23. .
Vulnerabilities vs. Malware
Number of vulnerabilities per mobile OS
iOS vulnerabilities
are by far the most common.
Jailbreak exploits,
lock screen bypasses, numerous
native application related bugs.
Android on the other
hand has less vulnerabilities
overall (open source code).
Adrian Hayter & Andy Swift
Page: 22/25

24. .
Vulnerabilities vs. Malware
Number of malware families per mobile OS
Number of
vulnerabilities is not necessarily
an indication of the amount of
malware a system suffers from.
iOS vulnerabilities are
often more complex, require
a lot of user interaction.
Apple have a rigorous vetting
process for apps. Android’s
app store has almost no protection whatsoever.
Adrian Hayter & Andy Swift
Page: 23/25

25. .
Demos
Adrian Hayter & Andy Swift
Page: 24/25

26. .
Questions?
Ask away, or email:
adrian.hayter@hut.net / andy.swift@hut3.net
Adrian Hayter & Andy Swift
Page: 25/25