security-zone 2012

OWASP Foundation
September 19th, 2012 https://www.owasp.org

OWASP"
Top 10 Mobile Risks

Sven Vetsch
Leader OWASP Switzerland



Copyright The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
 Introduction
Sven Vetsch
Leader OWASP Switzerland
http://www.owasp.ch
Partner & CTO Redguard AG
http://www.redguard.ch
Focused on Application Security (Web,
Mobile, )

2
 Agenda
Mobile Security Project
Mobile Threat Model
Top 10 Mobile Risks
Wrap Up
Q&A

3
Mobile Security Project
Started in Q3 2010 Threat Model
Risks
Why? Controls
Training
Unique and different Dev. Guide
security risks Secure Libraries
Tools
Goal Methodologies
Cheat Sheets
To build security into
mobile dev. life cycle

4
Mobile Threat Model
 Mobile Threat Model
Platforms vary heavily
Very different from traditional web app
model due to wildly varying use cases and
usage patterns
Must consider more than the Apps
Remote web services
Platform integration (iCloud, GCM)
Device (in)security considerations
6
Mobile Threat Model

7
Mobile Threat Model

8
Top 10 Mobile Risks
 Top 10 Mobile Risks
Intended to be platform-agnostic
Focused on areas of risk rather than individual
vulnerabilities
Weighted utilizing the OWASP Risk Rating
Methodology
https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

10
 Top 10 Mobile Risks
Everything in this presentation is in a draft
state.
First final version is planned for around
February 2013

11
 Top 10 Mobile Risks
OWASP Top 10 Mobile Risks

M1 Insecure Data Storage M6 Improper Session Handling

Security Decisions"
M2 Weak Server Side Controls M7
Via Untrusted Inputs

Insufficient Transport"
M3 M8 Side Channel Data Leakage
Layer Protection

M4 Client Side Injection M9 Broken Cryptography

Poor Authorization and Sensitive Information

M5 M10
Authentication Disclosure

12
 M1- Insecure Data Storage

Sensitive data left unprotected Impact

Applies to locally stored data + Confidentiality of
cloud synced data lost
Generally a result of: Credentials
Not encrypting data disclosed
Caching data not intended for long-term Privacy violations
storage

Weak or global permissions

Non-compliance
Not leveraging platform best-practices

13
M1- Insecure Data Storage

14
 M1- Insecure Data Storage"
Prevention Tips

Store ONLY what is absolutely Control Description

required
1.1-1.14 Identify and protect sensitive
Never use public storage areas (ie- data on the mobile device

SD card) 2.1, 2.2,

2.5
Handle password credentials
securely on the device

Use secure containers and platform

provided file encryption APIs
Do not grant files world readable or
world writeable permissions

15
 M1- Insecure Data Storage"
Prevention Tips
European Network and Information Security Agency (ENISA)
Smartphones secure development guidelines for app
developers
Store ONLY what is absolutely Control Description
required
1.1-1.14 Identify and protect sensitive
Never use public storage areas (ie- data on the mobile device

SD card) 2.1, 2.2,

2.5
Handle password credentials
securely on the device

Leverage secure containers and

platform provided file encryption
APIs
Do not grant files world readable or
world writeable permissions
16
 M2- Weak Server Side Controls

Applies to the backend services Impact

Not mobile specific per se, but Confidentially of
essential to get it right data lost
We still cant trust the client Integrity of data
Luckily, we understand these not trusted
issues (quite) well
Existing controls may need to be
re-evaluated

17
 M2- Weak Server Side Controls
OWASP Top 10 OWASP Cloud Top 10







https://www.owasp.org/index.php/
Category:OWASP_Top_Ten_Project https://www.owasp.org/images/4/47/Cloud-
Top10-Security-Risks.pdf

18
 M2- Weak Server Side Controls"
Prevention Tips

Understand the additional risks

Control Description
mobile apps introduce into existing
architectures 5.1-5.8 Keep the backend APIs
(services) and the platform
(server) secure
Leverage the wealth of knowledge
that is already out there
OWASP Web Top 10, Cloud Top
10, Web Services Top 10
Cheat sheets, development guides,
ESAPI
19
M3- Insufficient Transport Layer Protection

Complete lack of encryption for Impact

transmitted data
Man-in-the-
Yes, this unfortunately happens often
middle attacks
Weakly encrypted data in transit Tampering w/
Strong encryption, but ignoring data in transit
security warnings
Confidentiality of
Ignoring certificate validation errors data lost
Falling back to plain text after failures

20
M3- Insufficient Transport Layer Protection

Real World Example: Google ClientLogin

Authentication Protocol (fixed)
Authorization header sent over HTTP
When users connected via wifi, apps
automatically sent the token in an attempt to
automatically synchronize data from server
Sniff this value, impersonate the user
http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html

21
M3- Insufficient Transport Layer Protection"
Prevention Tips

Ensure that all sensitive data Control Description

leaving the device is encrypted 3.1.3.6 Ensure sensitive data is

protected in transit

This includes data over carrier

networks, WiFi, and even NFC
When security exceptions are
thrown, its generally for a
reasonDO NOT ignore them!

22
 M4- Client Side Injection

Apps using browser libraries Impact

Pure web apps
Device
Hybrid web/native apps
compromise
Some familiar faces
Toll fraud
XSS and HTML Injection
SQL Injection Privilege
escalation
New and exciting twists
Abusing phone dialer + SMS
Abusing in-app payments
23
 M4- Client Side Injection

Garden Variety XSS. With access to:

24
 M4- Client Side Injection"
Prevention Tips

Sanitize or escape untrusted data Control Description

before rendering or executing it 6.3 Pay particular attention to

validating all data received
Use prepared statements for from and sent to non-
trusted third party apps
database callsconcatenation is before processing
10.1-10.5 Carefully check any runtime
still bad, and always will be bad interpretation of code for
errors

Minimize the sensitive native

capabilities tied to hybrid web
functionality

25
 M5- Poor Authorization and Authentication

Part mobile, part architecture Impact

Some apps rely solely on Privilege
immutable, potentially escalation
compromised values (IMEI, IMSI,
UUID) Unauthorized
access
Hardware identifiers persist across
data wipes and factory resets

Adding contextual information is

useful, but not foolproof

26
M5- Poor Authorization and Authentication

27
 M5- Poor Authorization and Authentication"
Prevention Tips

Contextual info can enhance

things, but only as part of a Control Description

multi-factor implementation 4.1-4.6 Implement user

authentication/authorization
and session management
Out-of-band doesnt work when 8.4
correctly
Authenticate all API calls to
its all the same device (i.e. paid resources

MTAN)
Never use device ID or
subscriber ID as sole
authenticator
28
 M6- Improper Session Handling

Mobile app sessions are generally Impact

MUCH longer
Privilege
Why? -> Convenience and usability escalation
Apps maintain sessions via Unauthorized
HTTP cookies access
OAuth tokens Circumvent
SSO authentication services licensing and
payments
Using a device identifier as a session
token is a bad idea

29
 M6- Improper Session Handling"
Prevention Tips

Dont be afraid to make users Control Description

re-authenticate from time to time 1.13 Use non-persistent identifiers

Ensure that tokens can be 4.1-4.6 Implement user

authentication/authorization
revoked quickly in the event of a and session management
correctly

lost/stolen device
Utilize high entropy, tested token
generation resources

30
M7- Security Decisions Via Untrusted Inputs

Can be leveraged to bypass Impact

permissions and security models
Consuming paid
Similar but different depending on resources
platform
Data exfiltration
iOS: Abusing URL Schemes
Android: Abusing Intents Privilege
escalation
Several attack vectors
Malicious apps
Client side injection
31
 M7- Security Decisions Via Untrusted Inputs

Skype iOS URL Scheme Handling Issue

http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/

32
M7- Security Decisions Via Untrusted Inputs"
Prevention Tips

Check callers permissions at Control Description

input boundaries 10.2 Run interpreters at minimal

privilege levels

Prompt the user for additional

authorization before allowing
Where permission checks
cannot be performed, ensure
additional steps required to
launch sensitive actions
33
 M8- Side Channel Data Leakage

Mix of not disabling platform features and Impact

programmatic flaws

Sensitive data ends up in unintended places Data retained

Web caches
indefinitely
Keystroke logging Privacy violations
Screenshots (i.e. iOS backgrounding)

Logs (system, crash)

Temp directories

Understand what 3rd party libraries in your

apps are doing with user data (i.e. ad
networks, analytics)
34
 M8- Side Channel Data Leakage
Screenshots


Logging

35
 M8- Side Channel Data Leakage"
Prevention Tips

Never log credentials, or any other sensitive data to Control Description

(system) logs
7.3 Check whether you are
Remove sensitive data before screenshots are taken, collecting PII, it may not
disable keystroke logging per field, and utilize anti- always be obvious
caching directives for web content 7.4 Audit communication
mechanisms to check for
Debug your apps before releasing them to observe unintended leaks (e.g. image
metadata)
files created, written to, or modified in any way

Carefully review any third party libraries you introduce

and the data they consume

Test your applications across as many platform

versions as possible

36
 M9- Broken Cryptography

Two primary categories Impact

Broken implementations using strong
crypto libraries Confidentiality of
data lost
Custom, easily defeated crypto
implementations Privilege
escalation
Encoding != encryption
Obfuscation != encryption Circumvent
business logic
Serialization != encryption

37
M9- Broken Cryptography"

38

 M9- Broken Cryptography"
Prevention Tips

Storing the key with the Control Description

encrypted data negates 1.3 Utilize file encryption APIs

everything 2.3 Leverage secure containers

Leverage battle-tested crypto

libraries vice writing your own
Take advantage of what your
platform already provides!

39
 M10- Sensitive Information Disclosure

We differentiate by stored (M1) vs. Impact

embedded/hardcoded (M10)
Credentials
Apps can be reverse engineered with disclosed
relative ease
Code obfuscation raises the bar, but
Intellectual
property exposed
doesnt eliminate the risk
Commonly found treasures:
API keys
Passwords
Sensitive business logic

40
M10- Sensitive Information Disclosure

41

 M10- Sensitive Information Disclosure"
Prevention Tips

Private API keys are called that for Control Description

a reasonkeep them off of the 2.10 Do not store any passwords

client or secrets in the application
binary

Keep proprietary and sensitive

business logic on the server
Almost never a legitimate reason
to hardcode a password (if there
is, you have other problems)

42
Wrap Up
 Going Forward
12 month revision cycle
Rapidly evolving platforms
Stale data == not as useful
If you have suggestions or ideas, we want
to hear them!

44
 Conclusion
This is a good start, but we have a long
way to go
Weve identified the issuesnow we have
to fix them
Platforms must mature, frameworks must
mature, apps must mature
The OWASP Mobile body of knowledge
must grow

45
 Q&A
Thanks for listening!

Thanks to Jack Mannino, Zach Lanier and Mike Zusman for

their original OWASP Top 10 Mobile Risks presentations.

Contact me:
[email protected]
Twitter: @disenchant_ch / @owasp_ch

46