Defending Behind the Mobile Device


Published on

RSA Europe 2012 presentation on a holistic view to securing the mobile application ecosystem.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Everyone has a different definition of riskDevelopers look at threats different than IT peopleIT looks at threats differently than the CSO and CTO of an enterpriseMedia has a totally different view than the rest of the world pushing sensationalist headlines that really shapes how everyone is addressing the problem.Segmentation of population falls generally into two bucketsThe developersOperations people-different view points on what the problems are in mobile and what can be done to fix them
  • Securing the SDLC is the primary desire of the development side of the house. What can they do to increase the creation rate of secure code. For the longest time the only metric that mattered was, what can be done to increase the rate of creation of code. Bugs and security flaws didn’t matter. Only recently has the developer world really begun to embrace the creation of secure and low bug density code. Vulnerabilities is their primary priority when it comes to securing the development lifecycle. Identifying vulnerabilitieseducating the development team on what the vulnerabilities look like and how to fix themFixing the flawsAnd testing that their flaws were properly fixed.And the cycle continues. Developers traditionally haven’t cared as much about the capabilities of their code or the fact that malware may be embedded in their code.Reasoning: We wrote it. We know what it does and we know that it doesn’t have malware (not always true)Transition to BYOD…
  • In the Enterprise operations and IT world the priorities are reversed. They want to know first and formost that they don’t have any malware in the applications they are deploying to their user base.They then want to know what the applications are actually capable of doing on the device.And finally, does the application have any vulnerabilities that can be exploited on the device itself.These two types of views require two different types of execution if we are to help the Enterprise solve their mobile related problems
  • What makes up a risk rating? Risk is grey. It’s not binary, it’s not 0/1. It’s 1-1000000. It’s infinite shades of grey.Risk is made up of the security and privacy levels of application, and does that risk level fit within the acceptable threshhold that has been set by your enterprise risk policy.
  • We are at a mobile crossroads, an inflection pointJuniper Trust in Mobility Survey Results18% of people do not trust19% of surveyed people DO trust63% have no idea
  • Three distinct areas, mobile malware, application behaviors, and code vulnerabilitiesEach of these areas is a risk to the enterprise specific to the mobile spaceEach manifests itself in a slightly different attack model (yes we’ve seen each of these in the wild)Each results in a different method by which we must apply security controls
  • Mobile malware is shaping up to be the perfect storm.Describe perfect malware…DecentralizedInterconnectedMobileAbility to access targeted data quicklyDescribe mobile networks todayDecentralizedInterconnectedMobile – In every wayQuick content access and retrieval
  • Statistics, everyone has got them.What you see here are a bunch of statistics samples from different vendor researchNumbers are largely irrelevantWhat matters is the trending linesYou can dispute any individual group of statistics, but when every player in the ecosystem is claiming the same trends the data increases in value
  • Look into one specific set of trends.These results are from the McAffee annual report on threat predictions for 2012The trend is the same as every other report. Exponential growth.From July to November of 2011 there was significant uptick month over month demonstrating the typical exponential curveI’ve been predicting this type of uptick since end of 09 beginning of 10I was wrong. I was early. There was growth but nothing like we saw in 2011 and 2012I was also wrong in predicting where the out break would occur first. I saw the target as Blackberry (but we all know how that story went)It was Android…What I was RIGHT about was the distribution method for malware.. The public marketplace
  • So why was it Android and not Blackberry or some other player?Close technologyHarder to REStronger OS securityRealistically…Better app store securityNo fragmentation issue
  • North Carolina state did some significant research they called the mobile genome project.4 common types of infection vectorsRepackaging – 86% HugeDrive by – who caresStandalone – not really an issueUpdate – Coupled with exploitation based attacks and other repackaging for distributionDoesn’t total 100% because some samples contained multiple distribution and infection mechanismsSamples collected between August and October of 2011
  • What type of payloads were most common..Somewhat well distributed with the exception of remote controlEven spread between:Financial chargesInformation CollectionPriv EscalationRemote control was a larger number most likely because the attackers want to be an ongoing concernDon’t total 100% because some samples contained multiple distribution and infection mechanismsSamples collected between August and October of 2011
  • I ask developers all the time “Do you know what your code does”. Invariably the answer is “of course I do.. I wrote the code”. I then tell them they are wrong and listen to them fight with me for a few minutes.. And then I explain what I mean.Do you reuse or repurpose code – YESDo you use libraries that other people have written – YESDo you audit the source code of every library you use in your app? – NODo you use any third party binary only libraries – YESDo you reverse engineer and analyze the security of these libraries – NOThen you have no idea what your code really does.You are inheriting and accepting risk into your application every time that you use third party code or libraries
  • LinkedIn-Transmitted entire calendar entries-Included participant information-Times-Dialin numbers-NotesPath-Transmitted entire address book to the company-Did not disclosure this information to the userPandora-Transmitted GPS location-Phone identifying values (Android ID / iPhone identifiers)-Other sensitive data-Ad libraries-Likely third party library problem
  • -Sensitive Data Leakage-Unsafe Sensitive Data Storage-Unsafe Sensitive Data Transmission-Hardcoded passwords / keys
  • Layered APIs on common languagesBlackberry and Android use JavaNon-issue for Objective-C (it’s own language)
  • MDMGood -Strong policy and configuration mgmt-MAM support growingBAD-Security is secondary-MDM Differentiation is tough-Limited by API set provided by handset vendor-Expensive (40-60 per user per year)-MDM server security
  • Mobile AVGood-Catching the KNOWN malware-Awesome at killing battery lifeBAD-Inability to catch anything unknown (0day)-Same problem as traditional malware-Persistent resource issue (humans required)-Often highly priviledged apps running on the device(one bug to rule them all)
  • Good-Primary distributor of applications-Easy to locate desired applications-Trivial installation-Basic curating of applications occurs-Kill switchesBAD-Inadequate curating (incented by the app race)-Inconsistent application of checks-Speed of dissemination of applications
  • Good-Single source of applications (at the end of the day this is where all apps come from)-Generally not ill intentioned (but not always)BAD-Inadequate security education-Inadvertent code flaws-Intentional code flaws (backdoors)-Not incented to create secure code-Code reuse security paradigm
  • Capabilities mapping-Knowing what your application does.. EXACTLY what it doesMalware detection-Knowing if there is something hidden in your code (truly a subset of capabilities mapping)Vulnerability Analysis-Knowing if there are code flaws that can be exploited in your applications
  • Look at what the application DOES via static analysisLook for appropriate permissionsTrace sensitive data from sources to sinksCode flowData flowExecute dynamic runtime analysis as wellInform between the static and dynamic to create the most accurate capabilities picture
  • The traditional way is broken. Signatures don’t work. Easily evaded.When we put a new piece of malware into the hands of a malware analyst. What do they do with it?They do static analysisThey do runtime analysisThey add human intelligence to the system to determine what the application does and what the risk is of the programBest solution includes a machine learning system that determines what the application does and tries to understand how that maps to malicious intent
  • Application FlawsBad file permissionsUnprotected programmatic interfaces/APIsThe other usual suspectsSQLi, XSS, exfiltration, poor crypto, etc.Inherited risks via 3rd party libsEnvironmental FlawsRuntime and libraryidiosyncrasies or bugsPrivilege escalation vulns(OS or kernel)Other outdated, vulnerable components
  • Use all of the strategic control pointsNOT just oneImplement what each one is good atStrengthen each individually with good application security capabilities
  • PolicyOverarching security strategy drives…BYOD policy, access control, etc.I.R. plans should account for “computer-in-my-pocket”ProcessIdentifying/inventorying mobile devices, usage patterns, security modelsTechnical ControlsMDM and/or “enterprise-friendly” mobile AVDetection, lockdown, alerting, response optionsInternal analysis/testing lab? ($$$)Or just pay external firm to do it
  • “Mobile malware will continue to grow...”Especially on AndroidThe trajectory for mobile payment apps will eventually make them an enticing target, but not quite there yetThere’s yet an(other) opportunity to learn from previous failures, successes, and innovations in security, and apply them to the mobile spaceTake a holistic view of your ecosystemControl for problems at the choke pointsThis is going to be a journey… It won’t happen over nightIn the short term we have to add these new concepts and capabilities to our mobile environmentDesign your mobile security program keeping these concepts in mindIndividual point solutions will not work…Take a holistic approach
  • Defending Behind the Mobile Device

    1. 1. Defending Behind The Device Mobile Application Risks Tyler Shields Product Manager and Strategist Veracode, IncSession ID: MBS-301Session Classification: Something for everyone
    2. 2. Agenda The “What” The MobileProblem Ecosystem 1 2 3 4 Threat The Fix Landscape
    3. 3. The Problem 1 3
    4. 4. What Are The Risks Define the Threats 4
    5. 5. Securing the SDLC The Developer View Identify Priorities1. Vulnerabilities Retest Educate2. Capabilities3. Malware Remediate 5
    6. 6. Moving Into The Enterprise Bring Your Own Device Priorities 1. Malware 2. Capabilities 3. Vulnerabilities 6
    7. 7. Risk is not binary Risk is analog Policy Confidentiality Accessibility Integrity Rating Rating Rating Exfiltration of Disclosure of Can Data be Is Data Always Sensitive Data Secrets Modified Accessible 7
    8. 8. Mobile Crossroads The Inflection PointDo you trust the security of your mobile device… 63% Have yet to make up their minds 8
    9. 9. Threat Landscape 2 9
    10. 10. The Mobile Threat Landscape 10
    11. 11. Mobile MalwareMobile Networks Decentralized Interconnected Mobile Quick Content RetrievalPerfect Malware Decentralized Interconnected Mobile Quick Content Retrieval 11
    12. 12. Statistics12
    13. 13. Malware Timeline2011Jul August Septembe O ct ob er November y r Malware Early to Exponential Wave the Game Growth Begins 13
    14. 14. Primary TargetAndroid Most Targeted(65%)iOS Absent (<1%) WHY • Closed Technology • Harder to Reverse Enginee 7% 1% • Stronger OS Security 27% 65% • Better App Store Security • No Fragmentation Issue Android J2ME Symbian Windows Mobile Distribution of Mobile Threats by Platform 2011 14
    15. 15. Mobile Malware Repackaging Update86% • Choose popular app • Disassemble • Add malicious payloads • Re-assemble • Similar to repackaging • Does not add full payload • Adds small downloader 7% • Submit new app to • Payload downloaded at public market runtime Drive-By Standalone • Entice users to • Commercial spyware download malware • Non functional fake<1% • Distributed via malicious websites • May or may not contain a browser exploit apps (Fake Netflix) • Functional Trojan code • Apps with root exploits 14% 15
    16. 16. Mobile Malware Privilege Escalation Remote Control37% •Attempts root exploits •Small number of platform vulnerabilities •May use more than one •Similar to PC bots •Most use HTTP based web traffic as C&C •Advanced C&C models 93% exploit for attack translating from PC world •Advanced obfuscation seen in the wild Financial Charges Information Collection •Premium rate SMS •Harvests personal45% •Both hard-coded and runtime updated numbers •Employ SMS filtering information and data •User accounts •GPS location 45% •SMS and emails PhoneSMS •Phone call tapping •Ad Libraries Number 16
    17. 17. Application Behaviors Previous Code Web Sources Your CodeBinary 3rd Party Source 3rd Party Libraries Libraries 17
    18. 18. Case studies WoW… Lots! 18
    19. 19. Vulnerabilities• Sensitive data leakage (inadvertent or side channel)• Unsafe sensitive data storage• Unsafe sensitive data transmission• Hardcoded password/keys 19
    20. 20. Vulnerabilities• Layered APIs on common languages• Blackberry and Android use Java as a base• Non-issue for Objective-C (it’s own language) 20
    21. 21. Mobile Ecosystem 3 21
    22. 22. The Mobile Ecosystem The Players of the Game Consumer 22
    23. 23. MDM Vendors The Enterprise Choke Point Enterprise Control Point What They Provide Device Enrollment and Management Security Management Device Configuration Device Monitoring Software Management Security Components Passcode Enforcement Encryption Feature Restriction Compliance Locate and Wipe Certificate Management 23
    24. 24. Mobile Anti-Virus Old Methods Rehashed Old Methods Rehashed What They Provide Quarantine and Eradicate Malware Signature Based Analysis Security Components Cloud Analysis Spam Filtering Email Attachment Scanning Data Backup 24
    25. 25. Application Markets The Distributor The Distributor What They Provide Marketplace for Applications User Ratings Application Updates Security Components Application Approval Process Android Bouncer iOS Scanning 25
    26. 26. Developers The Source The Source What They Provide Enterprise Application Development Consumer Application Development Cross-platform Expertise Security Components Variable on Developer Capabilities 26
    27. 27. The Fix 4 27
    28. 28. The Fix Securing Against Multiple ThreatsBehavioral Analysis Malware DetectionVulnerability Analysis 28
    29. 29. Static Behavioral Analysis Features and Permissions Data Sources Data Sinks Mapping User Facing • Location Data • HTTP Requests • Contacts • Outbound SMS • Trace Sources to • Email • Outbound Email Sinks • SMS Data • DNS Requests • Application “Intent” • SQL Access • TCP • Permission • File System • UDP Mapping • Photos • Vulnerable Code • Human Intelligence • Phone ID Values Code Flow Data Flow 29
    30. 30. Dynamic Behavioral Analysis Playing in the Sandbox Instrumented Analysis Example Data Gathered• Sandboxed Emulator • Network Traffic• Instrumented Fuzzy Logic Inputs • CPU Utilization• Tracked Outputs • Memory Footprint• Tracked System State • Mapping Screen to Functionality 30
    31. 31. Malware Detection Learn From Previous Mistakes StaticSignatures AnalysisSignaturesSignatures Human Intelligence DynamicBasic Heuristics Analysis 31
    32. 32. Vulnerability Analysis Find the Flaws Environmental Flaws Application Flaws 32
    33. 33. Strategic Control Points Security and Power Application Markets Enterprise Developers MDM Consumer Developers Outsourced Developers Anti-Virus COTS Developers … Developers Enterprise 33
    34. 34. Enterprise Fixes De-Risk B.Y.O.DPolicy ProcessTechnical Controls 34
    35. 35. The Road Ahead Where do we go from here? Capabilities Malware Vulnerability A Safer + + = Mapping Detection Analysis Mobile Path 35
    36. 36. Sources @txs Show me the data• Juniper Network Trusted Mobility Index• A History of Malware – Trend Micro• A Survey of Mobile Malware In The Wild – UC Berkeley• Mobile Malware Evolution Part 5 – Kaspersky Labs• Dissecting Android Malware: Characterization and Evolution – Yajin Zhou and Xuxian Jiang• google-maps/2012-06-11 Apples new iOS 6 adds deep Facebook integration, dumps Google Maps• LinkedIn Privacy Fail• Mobile Exploit Intelligence Project – Trail of Bits• Social Mobile Apps Found Storing User’s Content Without Permission• And More…. Contact me if you need something specific I may have left out… 36