CEO

Principal Consultant

Principal Consultant

WhyUnique and different security risks

Goal To build security into mobile dev. life cycle

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, C2DM)

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

Applies to locally stored data + cloud synced

Generally a result of:

Not encrypting data

Caching data not intended for long-term storage

Weak or global permissions

Credentials disclosed

Privacy violations

Never use public storage areas (ie- SD card)

Leverage secure containers and platform provided file encryption APIs

Not mobile specific per se, but essential to get right

We still can’t trust the client

Luckily, we understand these issues well

Leverage the wealth of knowledge that is already out there

OWASP Web Top 10, Cloud Top 10, Web Services Top 10

Yes, this unfortunately happens often

Weakly encrypted data in transit

Strong encryption, but ignoring security warnings

Ignoring certificate validation errors

Tampering w/ data in transit

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

This includes data over carrier networks, WiFi, and even NFC

Pure web apps

Hybrid web/native apps

Some familiar faces

XSS and HTML Injection

SQL Injection

New and exciting twists

Abusing phone dialer + SMS

Toll fraud

Use prepared statements for database calls…concatenation is still bad, and always will be bad

Some apps rely solely on immutable, potentially compromised values (IMEI, IMSI, UUID)

Hardware identifiers persist across data wipes and factory resets

Out-of-band doesn’t work when it’s all the same device

Why? Convenience and usability

Apps maintain sessions via

HTTP cookies

OAuth tokens

SSO authentication services

Unauthorized access

Ensure that tokens can be revoked quickly in the event of a lost/stolen device

Similar but different depending on platform

iOS- Abusing URL Schemes

Android- Abusing Intents

Several attack vectors

Malicious apps

Data exfiltration

Prompt the user for additional authorization before allowing

Sensitive data ends up in unintended places

Web caches

Keystroke logging

Screenshots (ie- iOSbackgrounding)

Logs (system, crash)

Temp directories

Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content

Debug your apps before releasing them to observe files created, written to, or modified in any way

Carefully review any third party libraries you introduce and the data they consume

Broken implementations using strong crypto libraries

Custom, easily defeated crypto implementations

Encoding != encryption

Obfuscation != encryption

Privilege escalation

Leverage battle-tested crypto libraries vice writing your own

Apps can be reverse engineered with relative ease

Code obfuscation raises the bar, but doesn’t eliminate the risk

Commonly found “treasures”:

API keys

Passwords

Keep proprietary and sensitive business logic on the server

RC1 then becomes ‘Final v1.0’

12 month revision cycle

Rapidly evolving platforms

Stale data = not as useful

We’ve identified the issues…now we have to fix them

Platforms must mature, frameworks must mature, apps must mature

Zach Lanier zach.lanier@intrepidusgroup.comhttp://twitter.com/quine

Mike Zusmanmike.zusman@carvesystems.comhttp://twitter.com/schmoilito