Securing Your Mobile Applications
0 likes272 views
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.
Securing Your Mobile Applications
- 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
- 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
- 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!