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

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

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)

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 

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.

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?

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

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 …

3 views of Mobile App Architecture

What customers expect

What the Architects see

Then the pen testers see this …

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.

OWASP Top 10 for Mobile

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.

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.

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***/

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 …

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

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

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 …

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

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

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

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’

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

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

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/

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

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

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 …

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

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

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

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

Threat 2 – Broken Cryptography … to become this:

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

Threat 2 – Broken Cryptography To become this …

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! 

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.

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

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

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

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.

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

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 …

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

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! 

‘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

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

Threat 4 – Insecure transmission of data

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?

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

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 … 

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

NEVER put sensitive data in URL parameters Use POST instead

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

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.

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.

Questions? leomccavana@hotmail.com linkedin.com/in/leomcc