1. Leo McCavana, OWASP Belfast, October 1st, 2015
Mobile App Pen testing
Leo McCavana, OWASP Belfast, October 1st, 2015

2. Agenda Who? What mobile pen testing ‘is’ and ‘is not’
What does mobile app security mean?
Mobile app architecture complexity
Basic threat model of a mobile app and service
The interesting stuff you find
A word or 3 on tools and hardware
Summary, Q & A

3. Who? 11 years experience in Application Security
Employed by Allstate Northern Ireland
Former developer in a previous life
Primary focus: Mobile, web services, web apps
Always learning something (right now, OSCP)

4. What (mobile) pen testing is …
… an assurance measure at a given point in time
… more than just a mobile app
… gets completed at the end of the software development process on a production quality build
… involves looking at everything from the perspective of an attacker
… and a lot of fun, getting paid to break things 

5. What (mobile) pen testing is not …
… a magic bullet or sprinkling of fairy dust that somehow makes an app ‘secure;.
… a replacement for doing other stuff at the different stages of software production
… something that gets done once as a box ticking affair.

6. Consider Pen Testing as just one aspect of Mobile Application Security
Consider Pen Testing as just one aspect of Mobile Application Security. So ….. What does Mobile Application Security mean?

7. We’ve all heard these before …
Just encrypt the phone and use a pin.
Use an iPhone …. It’s more secure than Android
Use Android, it’s more secure than an iPhone!
It’s just an app stored on a phone, nothing else.
Our apps require a user name/password …. that’s secure enough.
We use crypto/security technology ‘X’.

8. Security ‘features’ don’t make an app and its data secure by default
Security ‘features’ don’t make an app and its data secure by default. Enterprise quality mobile apps are not simple. Let’s qualify …

9. 3 views of Mobile App Architecture

10. What customers expect

11. What the Architects see

12. Then the pen testers see this …

14. The more complex the architecture is, the greater the attack surface in terms of the potential threats. Let’s look at some of the interesting stuff that can be found in a mobile app pen test.

15. OWASP Top 10 for Mobile

16. To keep things simple for now , we’ll focus on a few of the items
To keep things simple for now , we’ll focus on a few of the items. Insecure storage/unintended data leakage, broken cryptography, weak server side controls, insecure transmission of data.

17. Threat 1 – Insecure Data Storage & Data Leakage
What type of data is stored on a mobile device?
Local databases (SQLite), Preference files, Cached content files
A lot of information potentially useful to an attacker that needs to be protected.

18. Threat 1 – Insecure Data Storage & Data Leakage
Where do mobile apps store all of this stuff?
Application specific ‘sandboxes’
Android: /data/data/**APPNAME**/
iOS: /private/var/mobile/Applications/***APPGUID***/

19. Threat 1 – Insecure Data Storage & Data Leakage
Why the need for ‘sandboxing’?
Data is specific to a single application
Access to data requires a device to be ‘jail broken’ or ‘rooted’.
However …

20. Always assume that if an attacker has access to a device, they can access anything on it. Time to look at a sample a sample app. 

21. Threat 1 – Insecure Data Storage & Data Leakage
Note the emphasis on ‘credentials’
What does that mean?
Where could it be stored and how?

22. Threat 1 – Insecure Data Storage & Data Leakage
An example application that allows customers to make credit card payments.
Let’s check to see if anything is stored locally …

23. Threat 1 – Insecure Data Storage & Data Leakage
SSH into the device
A card database has been found ... Wonder what it contains?

24. Threat 1 – Insecure Data Storage & Data Leakage
Spot anything?

25. Threat 1 – Insecure Data Storage & Data Leakage
It’s an exaggerated example, but the app is storing credit cards ‘in the clear’ – by design.

26. Threat 1 – Insecure Data Storage & Data Leakage
Unintended data leakage occurs when data is inadvertently stored on the mobile device that is accessible by other apps.
Typically originates from the operating system itself – hence ‘unintended’

27. Threat 1 – Insecure Data Storage & Data Leakage
Examples of unintended data leakage:
Caching: keyboard, copy/paste buffer, URL
‘Send to background’ application screenshots

28. Threat 1 – Insecure Data Storage & Data Leakage
PINs and passwords are not cached by default.
‘Normal’ string data cached – e.g. password reminders!

29. Threat 1 – Insecure Data Storage & Data Leakage
A ‘send to background’ app screenshot.
Useful to an attacker?
Any obvious ‘fixes’ here?
Use the proper UI controls to make passwords invisible - also stops it being included in a keyboard cache)
iOS stores the images: /private/var/mobile/Applications/***APPGUID***/Library/Caches/Snapshots/

30. Store the information properly
More data = bigger risk Consider the type of data you really need to store on the device
Store the information properly
Use an app specific location
Disable caching
…. where possible

31. Use encryption properly to protect the data you really need.
However …

32. Encryption is no magic bullet and the best cryptographic algorithm can be rendered ineffective if not implemented correctly …
Let’s take a closer look at the content of some SQLite files found on a device …

33. Threat 2 – Broken Cryptography
What do you see here?.
It’s encrypted (and B64 encoded for good measure), so it’s ok. Right? Hmm …….

34. Threat 2 – Broken Cryptography
Can you spot any issues here?

35. Threat 2 – Broken Cryptography
Can you spot any issues here?

36. Threat 2 – Broken Cryptography
So …. a key value of ‘superse5retkeY!’ enables this…

37. Threat 2 – Broken Cryptography
… to become this:

38. Threat 2 – Broken Cryptography
Or this (an encrypted image in base64) ….

39. Threat 2 – Broken Cryptography
To become this …

40. Threat 2 – Broken Cryptography
Any other impacts of a hard coded key?
Encryption/Decryption of all data on all devices uses the same key!
In other words, every customer who uses the app! 

41. Threat 2 – Broken Cryptography
Anything else to tell us?
Yup … crypto keys can usually be found regardless of how unique they are or where they are stored.
Using instrumentation (e.g. IntroSpy etc), any time a crypto key is exposed to a native crypto API, it can be found.
However …. If the key is unique, then it lessens the impact.

42. NEVER ‘roll your own’ cryptographic algorithms NEVER hard code keys
Do you really need to store user data on the device? Encrypt it (properly)!
NEVER ‘roll your own’ cryptographic algorithms
Only use industry standards
NEVER hard code keys
Very easily discovered via reverse engineering

43. Never use shared keys Make them specific to the user/device!
Store keys securely
Use a keychain/keystore

44. Threat 3 – Weak Server Side Controls
Traffic interception between a mobile app & service.

45. Threat 3 – Weak Server Side Controls
All input is evil – usual rules apply: 
Validate on the server for size/type/range value based on ‘known good parameters’
‘In app’ controls are only an aid to usability.

46. Threat 3 – Weak Server Side Controls
Poor/missing authentication allows an adversary to anonymously execute functionality within the mobile app or service endpoints.

47. Threat 3 – Weak Server Side Controls
Poor or missing authorization enable an attacker to execute functionality they should not be entitled to. E.g. Customer X can see Customer Y details.
Let’s consider an example of a banking app that allows user to login and check their balances …

48. Threat 3 – Weak Server Side Controls
A sample request and response:
What could possibly go wrong here? 

49. Threat 3 – Weak Server Side Controls
A tampered request and response (account #):
The authenticated user shouldn’t be authorized to see this data. An attacker could run a brute force attack …. Think of the impact! 

50. ‘In app’ data validation controls are only aids to usability
Never assume an attacker will only attack via the app Attackers will always try to attack service endpoints
‘In app’ data validation controls are only aids to usability
Always validate on the server side for security
Accept only ‘known good’ parameters
Adopt a white listing approach based on size/type/length/range/value

51. Perform authorization checks
ALWAYS remember to Authenticate and Authorize … … before granting access to information
Just because somebody is authenticated
doesn’t mean they are authorized to see all data
Perform authorization checks
On every service call

52. Threat 4 – Insecure transmission of data

53. Threat 4 – Insecure transmission of data
Scenario: a consumer app that transmits/receives data that is sensitive (e.g. financial details)
Any issues with the intercepted request?

54. Threat 4 – Insecure transmission of data
As you can see, an account number is shown in the ‘get’ line

55. Threat 4 – Insecure transmission of data
Impact?
The GET method: account numbers will show up in log files …. use POST instead (e.g. JSON payload in the body)
Think of the privacy impact … (SSNs, CC numbers etc … 

56. Always consider the data sensitivity Encrypt sensitive data in transit
Using ‘https’ at the app code level is no silver bullet though
Traffic can always be intercepted – think carefully about the data you REALLY need
Service endpoints need to be configured properly
Switch off port 80, redirect to https variant

57. NEVER put sensitive data in URL parameters Use POST instead

58. A word or 3 on tools and hardware
Jailbroken/rooted mobile devices (simulators can be slow)
Instrumentation:
Introspy (getting a bit long in the tooth), Frida, IDB, also consider Xframework for Android (looking at this now!)
Proxy tools: Burp/Zap etc (no intro needed)
Reverse Engineering (Android): Dex2Jar, JD-GUI
Build your own utils in Python …. E.g. to handle decryption etc.
MAC or Windoze?: Both.
Don’t get hung up on using tool X or Y …. And don’t put all your trust in tools that promise so much either.
Invest in developing your own analog computer: set up your own test lab with vulnerable apps.
And obviously …. Get permission first to pen test something

59. Summary
Mobile apps are not simple in terms of the overall architecture.
REALLY consider what needs to be stored on the device.
Be careful with encryption – don’t let an attacker use it as a weapon.

60. Summary
Ensure that service endpoints authenticate and authorize, ALWAYS
Use SSL to protect data in transit
Perform white listing validation on all service endpoint calls.
Never assume ‘in-app’ controls are safe – the attacker can easily bypass them.

61. Questions?
linkedin.com/in/leomcc