Presentation on theme: "Leo McCavana, OWASP Belfast, October 1st, 2015"— Presentation transcript:
1 Leo McCavana, OWASP Belfast, October 1st, 2015 Mobile App Pen testingLeo 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 complexityBasic threat model of a mobile app and serviceThe interesting stuff you findA word or 3 on tools and hardwareSummary, Q & A
3 Who? 11 years experience in Application Security Employed by Allstate Northern IrelandFormer developer in a previous lifePrimary focus: Mobile, web services, web appsAlways 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 AndroidUse 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 …
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 filesA 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 applicationAccess 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 deviceA 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 deviceStore the information properlyUse an app specific locationDisable 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 algorithmsOnly use industry standardsNEVER hard code keysVery easily discovered via reverse engineering
43 Never use shared keys Make them specific to the user/device! Store keys securelyUse 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 usabilityAlways validate on the server side for securityAccept only ‘known good’ parametersAdopt 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 informationJust because somebody is authenticateddoesn’t mean they are authorized to see all dataPerform authorization checksOn every service call
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 thoughTraffic can always be intercepted – think carefully about the data you REALLY needService endpoints need to be configured properlySwitch 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-GUIBuild 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 SummaryMobile 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 SummaryEnsure that service endpoints authenticate and authorize, ALWAYSUse SSL to protect data in transitPerform white listing validation on all service endpoint calls.Never assume ‘in-app’ controls are safe – the attacker can easily bypass them.