cya: mobile app security begins at the server

© Copyright 2016 NowSecure, Inc. All Rights Reserved. Proprietary information.

CYA: MOBILE APP SECURITYBegins at the Server


Connect with us

Connect with us on Twitter @NowSecureMobile

—

Visit our website at https://www.nowsecure.com

Ted EullVP, Risk and Privacy


● Built NowSecure’s mobile security and risk assessment practices

● 15+ years in development and information security

● Certified CRISC, GWAPT


Contents

● The mobile backend

● Backend security challenges

● Backend security fundamentals

● A five-step plan

● Questions


The mobile backend


A simplified diagram


Various implementations

● Proprietary / On-prem - you provision servers, configure OS, write APIs, etc. yourself and host the

technology in a datacenter you control or access. Example: Your server room

● Infrastructure-as-a-Service (IaaS) - a third party provides physical or virtual servers, and essential

resources such as network and block storage. You provision OS and software but don’t access or

control the hosting environment. Example: VM instances in EC2, Rackspace

● Platform-as-a-Service (PaaS) - rather than build systems on third-party servers, you access a

provided platform such as a database or app building platform and configure within that platform.

Examples: Google App Engine, Force.com, Azure SQL DB

● Software-as-a-Service (SaaS) - complete software application you may access via REST APIs

(typically) in addition to web based access. Examples: Zendesk, Stripe, Salesforce, etc.

Normally a combination of these

© Copyright 2016 NowSecure, Inc. All Rights Reserved. Proprietary information..

One app, many APIsA single app can have many backend services


Challenges in securing yourmobile app’s backend


Keeping up with the pace of mobile

● Demand for new features to compete

● Short cycles, frequent releases

● New technology with different/less security control - (NoSQL)

● Developers retooling skills to new technology quickly

● Numerous functions and libraries, incorporation of OSS

● Less time for infrastructure review

● Instituting security checkpoints with agile

● Proliferation of micro-services

Consumers want the app yesterday


Mobile API services are web services

● Common misconception that mobile services

are more secure by default (false)

● Manipulating web traffic in-browser is easier,

but mobile APIs can be attacked by injection,

fuzzing, and brute force

● HTTPS (TLS) does not protect from attacks or

ensure client is your app

● Proxies, web app firewalls and proper server

config can help repel attacks

hidden != secure

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project


Security responsibilities

Application

DB/Storage

OS

Networking

Virtual Host

Physical

Application

DB/Storage

OS

Virtual Host

Networking

Physical

Application

DB/Storage

OS

Networking

Virtual Host

Physical

Access Control Access Control Access Control

Application

PaaSOn-prem IaaS SaaS

DB/Storage

OS

Networking

Virtual Host

Physical

Access ControlYou

You and/or vendor

Vendor

Legend


MBaaS

● MBaaS is a form of PaaS providing API configuration/coding, data object

management, data connectors, versioning, access control and more

through custom hosted interfaces.

● Range from simpler API builder to fully-featured management system.

● e.g. Appcelerator Arrow, Parse, Firebase, AWS Mobile Hub, Azure Mobile Services

● Key issues○ Assurance of security in infrastructure

○ Provider stability

○ Auditability

○ Granularity of control

Faster, easier... but secure? It depends


Real world examples

● API communications without HTTPS - Many apps fail to use TLS on some or all API calls, exposing sensitive data

such as user location or personal info. (NFL Mobile app, CBS Sports app)

● Instagram bug (delete comments) - 10-year-old from Finland proved he could delete anyone’s comments

(including Justin Bieber) and received a $10k bug bounty.

● Trusting input from the mobile app - NowSecure’s @0xroot responsibly disclosed that Evernote trusted the app to

tell it whether the customer was “premium” or “free” enabling user to get elevated access without paying.

● Improper authentication / session management - Banking app (!!) function enabled user to change password

without being authenticated.

● User data enumeration (no authentication required) - By knowing some user info we could rapidly query the API

endpoint and ultimately access SSN for some accounts.

● Open API for credit card validation - We found an open API endpoint that would validate Credit Card numbers

with no rate limiting and easily stolen credential.

Involving insecure backend

http://www.darkreading.com/nfl-mobile-sports-app-contains-super-bowl-sized-vulns/d/d-id/1318802

https://threatpost.com/cbs-sports-app-transmitted-data-unencrypted-in-cleartext/117342/

http://arstechnica.com/security/2016/05/facebook-schoolboy-bug-bounty-justin-bieber-instragram-hack/

https://www.nowsecure.com/blog/2014/07/23/all-your-notes-in-evernote-belong-to-me/


Security fundamentals for your mobile backend


Proven security techniquesSecure backend systems with these famous infosec techniques

Limit access

Harden servers

Update software

Monitor and log

Develop securely*

Hack yourself

*Easier said than done, but you have to try.


Limit access

● Require secure connections - VPN + SSH

● Use firewall rules to control connections

● Use strong multi-factor authentication

● No apps running as root

● Do your developers have access to production?

● Physical access still matters

Least privilege for all!


Harden servers + update software

● Use a standard, minimal build OS

○ Only services necessary to support the app(s)

○ Commercially supported - e.g. Windows, RHEL

○ IaaS-provided - e.g. Amazon Linux AMI

○ Security-optimized - BSD

● Watch for CVEs or alerts for high-risk vulns

○ Heartbleed, Shellshock, OpenSSL

○ Patch quickly, then fix what breaks

○ Don’t confuse antivirus for vulnerability protection

Windows Server 2003 standard install? Not so much.

https://technet.microsoft.com/en-us/security/jj720323.aspx

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf


Monitor and log

● Log and monitor access requests to all APIs

○ Monitor all access attempts for brute-force and lateral attacks

○ Deploy risk-based access controls to adapt and modify the app’s

execution flow

● API Rate Limits (“throttling”)

○ Locks down services implemented and used by the app

○ Provides control over the assignment of server-side resources

○ Prevents brute force, account harvesting (user enumeration),

and replay attacks

● Log and monitor all connected systems for suspicious activity

Is anyone watching this API?


Hack Yourself

● Perform vulnerability scanning and pen testing

of backend infrastructure

● Automation for basic testing (e.g patch level,

configuration)

● Red Team testing to emulate malicious actors

● 3rd party to avoid internal conflicts

○ Vet credentials and references

○ Require detailed reporting, replication

steps and risk rating (CVSS)

Before they do.


Develop securely

● Hire, design, build, test, deploy and iterate with security in mind

● Evaluate threats, create “misuse cases”

● Build security-focused test cases for QA

● Test iteratively with builds/releases

● Pay special attention to authentication, session management,

input validation and sensitive transactions

● Train architects, developers, and QA on security

Agile and secure SDLC are not enemies


Secure authentication + session management

● Secure Authentication (OWASP)

○ Avoid outmoded or custom implementations.; Limit attempts, add 2nd factor

○ Prevent use of API services by unknown/untrusted devices (device registration step)

● Use session-based authentication

○ Avoid storing passwords by using token-based (OpenID, OAuth2, SAML, JWT)

○ Use TLS (https) and ensure access tokens are stored securely

○ Use a session token via POST (not GET) or Use an API key (POST body argument or secure cookie)

○ DO NOT include sensitive information in the URL (can be compromised)

● Prevent CSRF, XSS and replay attacks

○ Proper authentication on all API endpoints

○ Server-side session termination

● Make security decisions on the server side (!)

Welcome to our API, two forms of ID please.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

https://www.owasp.org/index.php/SAML_Security_Cheat_Sheet


Input validation

● Treat calls from mobile app as untrusted

○ Validate content-types and response-types

○ Need to ensure the security of all content sources for the app

○ Assume malicious party could replace content going to server,

including an authenticated session

○ Use message signatures for stronger validation

● Sanitize user input

○ Perform client-side for efficiency but still must check on server

○ Especially watch - files/images, URLs, XML, JSON, blobs

○ Implement secure parsing to avoid deserialization vulns

Don’t trust your own app

HTTP://XKCD.COM/327/

https://www.owasp.org/index.php/Deserialization_of_untrusted_data

http://xkcd.com/327/








About agile + devops

● Expect upfront challenges

introducing security controls in agile

● Devops process and tools can help

with security checkpoints and

standard environments

● Key change - breaking down walls

between security and development

Don’t hate the process, hate the flaw

“I have seen productivity gains of 15% and greater when preventative and detective security controls are embedded in the development process”

Jim Routh, CSO, AetnaSearchSecurity interview

http://searchsecurity.techtarget.com/opinion/Marcus-Ranum-QA-Aetna-CSO-Jim-Routh-on-Agile-security-challenges

http://searchsecurity.techtarget.com/opinion/Marcus-Ranum-QA-Aetna-CSO-Jim-Routh-on-Agile-security-challenges


Resources

CERT Top 10 Secure Coding Practices

SAFECode Practical Security Stories and Tasks for Agile Dev Environments

OWASP REST Security Cheat Sheet

OWASP Application Security Verification Standard

NowSecure Secure Mobile Development Best Practices

View now

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices



http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf

http://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#tab=Downloads

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project#tab=Downloads

https://www.nowsecure.com/resources/secure-mobile-development/






A five-step plan


There are far more complicated ones available, if you want...

Five-step plan to secure the mobile backend

1 Establish ownership + key roles

Document architecture

Analyze risk + requirements

Assess security

Remediate + repeat

2

3

4

5


Key steps and questions

1. Establish ownership + key roles

a. Who represents business, security,

network admin, dev

b. Authority to test and mandate changes

2. Document architecture

a. Include third-party systems

b. GSD beats perfection

3. Analyze risk + requirements

a. What data are we handling?

b. What policies or regulations do we

need to comply with? (PCI-DSS, FFIEC,

FERC, HIPAA)

The nitty gritty.

4. Assess security

a. Begin with vulnerability scan at minimum

b. Target higher-risk functions/features

c. Rate issues for severity, prioritize

5. Remediate + repeat

a. Add security into issue tracking

b. Escalate where necessary

c. Communicate results, metrics

d. Automation for scanning, config checks

e. Regular log/alert monitoring?

f. Security training for dev team


On PaaS, IaaS and SaaS

● Advantages of more outsourced backend:

○ Dedicated infrastructure personnel

○ Purpose-built systems

○ Isolation from other business systems

○ DoS resistance, resiliency

● Disadvantages: XaaS may not protect you from:○ Compromised admin credentials

○ Flawed API logic

○ Data flows to another system

○ Regulatory problem

○ All CVEs in server software

○ Reduced control and visibility

It’s a cloud world, we’re just living in it


Questions?

[email protected]+1 312.878.1100

@tedtalks2

Read more on securing your mobile apps’ backend, and secure mobile development in general, in our

Secure Mobile Development Best Practices https://www.

nowsecure.com/resources/secure-mobile-development/




cya: mobile app security begins at the server

Technology