5. Securing the SDLC
The Developer View
Identify
Priorities
1. Vulnerabilities
Retest Educate
2. Capabilities
3. Malware
Remediate
5
6. Moving Into The Enterprise
Bring Your Own Device
Priorities
1. Malware
2. Capabilities
3. Vulnerabilities
6
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. Mobile Crossroads
The Inflection Point
Do you trust the security of your mobile device…
63% Have yet to make up their minds
8
11. Mobile Malware
Mobile Networks
Decentralized
Interconnected
Mobile
Quick Content
Retrieval
Perfect Malware
Decentralized
Interconnected
Mobile
Quick Content Retrieval
11
13. Malware Timeline
2011
Jul August Septembe O ct ob er November
y r
Malware
Early to Exponential
Wave
the Game Growth
Begins
13
14. Primary Target
Android 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. Mobile Malware
Repackaging Update
86% • 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. Mobile Malware
Privilege Escalation Remote Control
37% •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 personal
45% •Both hard-coded and
runtime updated numbers
•Employ SMS filtering
information and data
•User accounts
•GPS location
45%
•SMS and emails
Phone
SMS •Phone call tapping
•Ad Libraries
Number
16
17. Application Behaviors
Previous Code Web Sources
Your Code
Binary 3rd Party Source 3rd Party
Libraries Libraries
17
19. Vulnerabilities
• Sensitive data leakage
(inadvertent or side
channel)
• Unsafe sensitive data
storage
• Unsafe sensitive data
transmission
• Hardcoded password/keys
19
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
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. 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. 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. Developers
The Source
The Source
What They Provide
Enterprise Application
Development
Consumer Application
Development
Cross-platform Expertise
Security Components
Variable on Developer
Capabilities
26
28. The Fix
Securing Against Multiple Threats
Behavioral Analysis
Malware Detection
Vulnerability Analysis
28
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. 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. Malware Detection
Learn From Previous Mistakes
Static
Signatures Analysis
Signatures
Signatures Human
Intelligence
Dynamic
Basic Heuristics Analysis
31
33. Strategic Control Points
Security and Power
Application Markets
Enterprise Developers
MDM Consumer Developers
Outsourced Developers
Anti-Virus COTS Developers
… Developers
Enterprise
33
34. Enterprise Fixes
De-Risk B.Y.O.D
Policy
Process
Technical
Controls
34
35. The Road Ahead
Where do we go from here?
Capabilities Malware Vulnerability A Safer
+ + =
Mapping Detection Analysis Mobile Path
35
36. Sources @txs
tshields@veracode.com
Show me the data
• http://www.juniper.net/us/en/local/pdf/additional-resources/7100155-en.pdf
Juniper Network Trusted Mobility Index
• http://countermeasures.trendmicro.eu/wp-content/uploads/2012/02/History-of-Mobile-Malware.pdf
A History of Malware – Trend Micro
• http://www.cs.berkeley.edu/~afelt/felt-mobilemalware-spsm.pdf
A Survey of Mobile Malware In The Wild – UC Berkeley
• http://www.securelist.com/en/analysis/204792222/Mobile_Malware_Evolution_Part_5
Mobile Malware Evolution Part 5 – Kaspersky Labs
• http://www.csc.ncsu.edu/faculty/jiang/pubs/OAKLAND12.pdf
Dissecting Android Malware: Characterization and Evolution – Yajin Zhou and Xuxian Jiang
• http://www.fiercemobilecontent.com/story/apples-new-ios-6-adds-deep-facebook-integration-dumps-
google-maps/2012-06-11
Apple's new iOS 6 adds deep Facebook integration, dumps Google Maps
• http://www.net-security.org/secworld.php?id=13050
LinkedIn Privacy Fail
• http://www.trailofbits.com/resources/mobile_eip_2.pdf
Mobile Exploit Intelligence Project – Trail of Bits
• http://www.net-security.org/secworld.php?id=12418
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
Notas do Editor
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