This document provides an overview of mobile application security. It begins with an introduction to the topic and why mobile security matters given the increasing ubiquity of mobile devices. It then covers common mobile vulnerabilities like those in the OWASP Mobile Top 10 list and examples like logic flaws, poor network security, insecure data storage, and privacy violations. The document concludes with recommendations on adopting an attacker mindset, leveraging resources, and thanks to sponsors.

1. 0
Securing Your Mobile
Applications
Greg Patton
HP Fortify on Demand

2. 1
Welcome to Houston TechFest
• Pleaseturn off allelectronicdevicesor set them to vibrate.
• If you must take a phone call,please do so in the lobbyso as
not to disturbothers.
• Thanks to our Diamond Sponsors:
Thank
you
for
being
a
part
of
the
9th Annual
Houston
TechFest!

3. 2
Agenda
• Introduction
• Why mobile security matters
• Common mobile vulnerabilities
• Takeaways

4. 3
Introduction
Greg Patton
StaticApplicationSecurity TestingManager
HP Fortify onDemand
- Managestaticapplication security testingteam
- Previously managedgroup ofmobiletesters
- 10yearsof applicationsecurity testingexperience
- Based in Houston, TX
hacker@hpe.com

5. 4
Why Mobile Security Matters

6. 5
Considerations: Mobile traffic increases
• Global mobiledata traffic will increase 26-fold
between 2010 and 2015
• There willbe nearly onemobiledeviceper capita
by2015 (~7 billion)
• Mobilepayments willexceed 984 Billionin2014
Data from Smart Insights, Yankee Group

7. 6
Considerations: Mobile ubiquity
• Mobileperformanceis becomingextraordinary
• Usinga non-mobilecomputerwillbecome
increasinglyrare
• “Homecomputer”willcome tomean better input
and displayoptionsfor yourmobilesystem
• Applereplacingdesktop withmobile?

8. 7
Considerations: Mobile ubiquity
• 2014 is consideredthe year that mobileweb
traffic will surpass non-mobilewebtraffic
• Mobilecomputingwillsoonbe knownas
“computing”
• Computingsomewhereotherthanyour mobile
devicewillbe the activitythat requires a name
• Attackersfollowthe users

9. 8
Considerations: Mobile insecurity
• Mobiledevelopmentisthe hottest type of
developmentrightnow. New surface area
equals dangeroussurface area
• If anyone’sgoingto putfeatures over security to
get the productout the door, it’slikely to be a
mobileteam
• Many enterprise mobiledevelopershaven’t had
the security trainingthat other types of
developershave had
• Many assume that because mobileback ends
aren’t visiteddirectlythey are more secure
(obscurityassumption)

10. 9
Mobile security differences
Q: What’s the difference
between “regular” security
and mobile security?

11. 10
Mobile security differences
Client ServerNetwork
Approachtothick-clienttesting

12. 11
Mobile security differences
Client ServerNetwork
Approachtothick-clienttesting
• Credentialsinmemory
• Credentialsonfilesystem
• Datastoredonfilesystem
• Poorcert management

13. 12
Mobile security differences
Client ServerNetwork
Approachtothick-clienttesting
• Credentialsinmemory
• Credentialsonfilesystem
• Datastoredonfilesystem
• Poorcert management
• Cleartextcredentials
• Cleartextdata
• Backdoor data
• Dataleakage

14. 13
Mobile security differences
Client ServerNetwork
Approachtothick-clienttesting
• Credentialsinmemory
• Credentialsonfilesystem
• Datastoredonfilesystem
• Poorcert management
• Cleartextcredentials
• Cleartextdata
• Backdoor data
• Dataleakage
• Injectionflaws
• Authentication
• Sessionmanagement
• Accesscontrol
• Logicflaws

15. 14
Mobile security differences
Q: What’s the difference
between this and mobile?

16. 15
Mobile security differences
Client ServerNetwork
Approachtomobiletesting
• Credentialsinmemory
• Credentialsonfilesystem
• Datastoredonfilesystem
• Poorcert management
• Cleartextcredentials
• Cleartextdata
• Backdoor data
• Dataleakage
• Injectionflaws
• Authentication
• Sessionmanagement
• Accesscontrol
• Logicflaws

17. 16
TwoKeydifferences
Magnifiednetworkvulnerability
Magnifiedphysical vulnerability
Yournetwork traffic is more likely to
be visibleto others witha mobile
devicethan at work or home
As withmostother types of
computing,oncetheattacker has
physical access,it’s game over
Mobile security differences

18. 17
Common Mobile Vulnerabilities

19. 18
OWASP Mobile Top 10 Risks
M1: Weak Server Side Controls M6: Broken Cryptography
M2: InsecureData Storage M7: ClientSide Injection
M3: InsufficientTransport Layer
Protection
M8: SecurityDecisions Via
UntrustedInputs
M4: UnintendedData Leakage M9: ImproperSessionHandling
M5: PoorAuthorizationand
Authentication
M10: Lack of Binary Protections

20. 19
Common vulnerabilities: OWASP
Open Web Application Security Project
• Thoughtleader in websecurity
• Runmany projectsdesignedto help industry
secure their applications
• OWASPTop10
• Risk RatingMethodology
• VulnerabilityPreventionCheatsheets http://www.owasp.org/

21. 20
Logicflawsare due to faulty
developerassumptions,i.e.
not thinking like an attacker
• Changinganarbitrary user’s
password
• Bypassingmulti-step
authentication
• Free productbyskipping
payment step
• Product+refund bysubmitting
negativenumber
• Defeatinga businesslimit by
enteringa highnegativenumber
• Getting a bulk discountononly
one itemby modifyingthecart
manually afterwards
Logic flaws

22. 21
Logicflawsare avoided by
performingexhaustive
vulnerabilityassessments
beforegoing to production
• Fullyunderstand the anticipated
flow of the application
• Assumethe mindof the attacker
• Identify places that developers
likely madeassumptions
• Attempttotake advantageof
those assumptions
• As a developer,think interms of
abuse vs. just regular use
Logic flaw defenses

23. 22
Many mobileapps do not
properly securenetwork
traffic
Many mobileapps allow SSL
communicationwithany host
• Trustingany certificate it sees
• Allowsexpiredcertificates
• Allowstrivial MiTMattacks
• Canconnectto HTTPS once,and
then fall back
• Oncein the middle,attackers can
model yourapp’s functionality
enrouteto breakingit
Poor network implementations

24. 23
TLS protectionhas multiple
levelsof security
• Ensure HTTPSisalwaysenabled
• Attempttomatch the name of
the remote certificate
• Certificatepinning*
• Recognizethatnothingisfool-
proof, andadjust accordingto
yourapp’s specificneeds
• Rememberthat pinningwasa
defense against compromised
CAs,not againstMiTM
Network recommendations

25. 24
Perhaps the most abused
functionalityisclient-side
storage
• Storageof credentials inplist
files, SQLitedatabases
• Failure to use KeyChaintostore
credentials
• Storageof sensitiveapplication
data on filesystem
• Apps(e.g.: banks) storingtheir
imagesin the publicfolder rather
than in their sandbox
• Applicationsloggingtothe
system log,but sendingsensitive
app data along withit
Promiscuous client-side storage

26. 25
Abusecase • Applicationprotectedbyvoice
password
• Passwordcheckedserver side
• File wasstored locally
• Retrievedthe file from the file
system
• Playedthe file back to itself
• Gainedaccess
Promiscuous client-side storage

27. 26
Be cautious of anything you
save—anywhere—including
on the client-side
• Ensureyou’reusingthe
platform-recommendedsolution
to store credentials
• Ensureyou use the Data
ProtectionAPItostoreany
sensitivedata
• Ensureyou are storing
everythingfrom yourapp into
the app sandboxso it cannot be
read byother applications
• Checkall loggingfunctionality
and notewhat you’resending
• Observe yourlog files withinthe
XCodelogviewerandensure you
are not storinganything
sensitive
Client-side storage recommendations

28. 27
There area number of binary
defenses that developers are
not implementing
• ASLRPIE (memory
randomization)
• Stack SmashingProtection
Enabled(Canary-based)
• AutomaticReferenceCounting
(memory resources)
• Binary debugnotdisabled– User
path informationdisclosure
• Developersare often
contractors, andhave customer
names inpaths
Failure to harden binaries

29. 28
AbuseCase • Founddevelopername inpath
• Wasno longer withcompany
• CheckedGithub
• Had all source available for apps
• Mobileand backend
• Lead tocompletecompromiseof
server
Failure to harden binaries

30. 29
Use alldefenses possibleto
harden your binaries before
release
• Ensurebinary protectionsare in
place
• Someare notsecurity-specific,
but improvetheoverall quality of
yourapplications
• Ensureno informationdisclosure
is present
Binary protections

31. 30
Many applicationsviolate
privacy withoutdevelopers
being aware
• Doesthe applicationaccess
GeoLocationdata?
• Doesthe applicationaccessthe
AddressBook?
• Doesthe applicationaccessyour
Photos?
• If so, what isyour app doingwith
this data?
• Doesyour applicationuse
analytics engines?
• If so, what doesit send there?
(UUID, appdata?)
Privacy violations

32. 31
Go with an absoluteleast-
privilegeapproach
• Don’taccessany data that could
be consideredprivateif youdon’t
need it
• There are applications outthere
that can evaluate what a given
binary accesses(HP Fortify
MobileReputation)
Privacy violations

33. 32
A massivenumber of
applicationswesee and
compromiseare compromised
due to backend vulnerabilities
• Promiscuouswebservices
• Full SQLstatements right inweb
service calls (saved money on
MSSQLServerManager)
• Blatant SQLi,XSS,CSRF,File
Includes, etc.
• Many developersassume “who’s
cominghere?”
• The data stores are oftenshared!
• Sharedhostingmeans
compromiseofmultiple
customers
Assumption of web obscurity

34. 33
Harden your web backend as if
the mobileapp didn’t even
exist
• Rememberhow easy it is to MiTM
a mobileapp
• Assumeeveryone cansee your
traffic
• Thismeans they can see all the
paths and parameters for your
backend
• Assumeattackers willcome
knocking
• Considerthe risks of shared
hosting,as others mightnotbe
taking these steps—evenif you
did
Assumption of web obscurity

35. 34
Takeaways

36. 35
It is an interestingtimefor
mobilesecurity
• Everyone’sheadingtomobile,
and the attackers are following
• Mobileis on the leadingedgeof
development,so mobileprojects
are especially susceptibleto
security shortcuts
• Most applicationshave major
vulnerabilities that are easily
found
Takeaways

37. 36
Adoptthe attacker mindset • Don’tbe afraid tolook at your
ownapps
• Thinklike an attackerand follow
some basicsteps to help you
evaluate yourownapplications
• Assumethe attacker has access
to the deviceand visibilityofall
traffic goingtoand from the
server, andcode accordingly
• Track your sensitivedata through
yourapp, fromuser to deviceto
network to server; where is it
vulnerable?
• Don’tstoresensitive data if you
don’thave to
Takeaways

38. 37
Leverageavailableresources
• Industry best-practicesare
available
o https://www.owasp.org
• Use the tools youalready have
o HTTP proxies, debuggers, source
code analyzers,etc.
o HP Enterprise Security Products
• Connectlocally
o Local OWASP Chapter
o HoustonSecurity Conference
(HouSecCon)
Takeaways

39. Houston Security Conference
http://www.houstonseccon.com/v6/

40. 39
HP Fortify on Demand
• Cloud-basedapplicationsecurity
testing
• Bothstatic and dynamictesting,
usingautomatedand manual
techniques
• Integrates withyourSDLC and
buildenvironmenttoprovide
critical security checkpoints
• Singleportal for codeuploads
and reviewingresults
• http://www.hp.com/go/fod
HP Fortify on Demand

41. 40
Please Leave Feedback During Q&A
If you leave session
feedback and provide
contact information in
the survey,you will be
qualified for a prize
Scan the QR Code to
the right or go to
http://bit.ly/1K1Hvi5

42. 41
Thanks to all our Sponsors!