the mobile threat landscape n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The Mobile Threat Landscape PowerPoint Presentation
Download Presentation
The Mobile Threat Landscape

Loading in 2 Seconds...

play fullscreen
1 / 53

The Mobile Threat Landscape - PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on

The Mobile Threat Landscape. Daniel Miessler Principal Security Architect, HP Fortify June 2013. 6 Ways to Build an Insecure Mobile Application. Daniel Miessler Principal Security Architect, HP Fortify June 2013. Agenda. Introduction Why Mobile Security Matters Mobile Security Differences

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Mobile Threat Landscape' - blaine


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the mobile threat landscape

The Mobile Threat Landscape

Daniel MiesslerPrincipal Security Architect, HP FortifyJune 2013

6 ways to build an insecure mobile application

6 Ways to Build an Insecure Mobile Application

Daniel MiesslerPrincipal Security Architect, HP FortifyJune 2013

slide3

Agenda

  • Introduction
  • Why Mobile Security Matters
  • Mobile Security Differences
  • Attacker Perspective
    • Common Mobile Vulnerabilities
    • Takeaways
  • Questions
slide4

Introduction

  • Daniel Miessler, CISSP, CISA, GCIAPrincipal Security Architect, HP Fortify
  • 10 years experience doing security testing
  • 5 years experience doing appsec testing
  • Web Application Vulnerability Assessments
  • Mobile Application Vulnerability Assessments
  • Application Security Process Development
  • Enterprise Security Consulting
      • daniel.miessler@hp.com
slide6

Considerations | Mobile Traffic Increases

  • Global mobile data traffic will increase 26-fold between 2010 and 2015
  • There will be nearly one mobile device per capita by 2015 (~7 billion)
  • Mobile payments will exceed 984 Billion by 2014

Data from Smart Insights, Yankee Group 2012

slide7

Considerations | Mobile Ubiquity

  • Mobile performance is becoming extraordinary
  • Using a desktop (static) computer will become increasingly rare
  • “Home computer” will come to mean better input and display options
slide8

Considerations | Mobile Ubiquity II

  • Mobile computing will soon be known as “computing”
  • Computing somewhere other than your mobile device will be the activity that requires a name
  • Attackers follow the users
slide9

Considerations | Mobile Insecurity

  • Mobile development is the hottest type of development right now. New surface area equals dangerous surface area
  • If anyone’s going to put features over security to get the product out the door, it’s likely to be a mobile team
  • Many enterprise mobile developers haven’t had the security training that other types of developers have had
  • Many assume that because mobile back ends aren’t visited directly they are more secure (obscurity assumption)
slide11

Mobile Security Differences

Q: What’s the difference between “regular” security and mobile security?

slide12

Mobile Security Differences |Thick-client Testing

Client

Network

Server

  • ABAP
  • C/C++
  • Java
  • Objective C
  • Python
  • VB6
  • COBOL
  • Cold Fusion
  • XML
  • SQL
  • ASP.NET
  • VB.NET
  • C#
  • Classic ASP
  • HTML
  • Flex
  • JavaScript/AJAX
  • JSP
  • PHP
  • VBScript
slide13

Mobile Security Differences |Thick-client Testing: Client

Client

Network

Server

  • ABAP
  • C/C++
  • Java
  • Objective C
  • Python
  • VB6
  • COBOL
  • Cold Fusion
  • XML
  • SQL
  • ASP.NET
  • VB.NET
  • C#
  • Classic ASP
  • HTML
  • Flex
  • JavaScript/AJAX
  • JSP
  • PHP
  • VBScript
  • Credentials in memory
  • Credentials on filesystem
  • Data stored on filesystem
  • Poor cert management
slide14

Mobile Security Differences |Thick-client Testing: Network

Client

Network

Server

  • ABAP
  • C/C++
  • Java
  • Objective C
  • Python
  • VB6
  • COBOL
  • Cold Fusion
  • XML
  • SQL
  • ASP.NET
  • VB.NET
  • C#
  • Classic ASP
  • HTML
  • Flex
  • JavaScript/AJAX
  • JSP
  • PHP
  • VBScript
  • Cleartext credentials
  • Cleartext data
  • Backdoor data
  • Data leakage
  • Credentials in memory
  • Credentials on filesystem
  • Data stored on filesystem
  • Poor cert management
slide15

Mobile Security Differences |Thick-client Testing: Server

Client

Network

Server

  • ABAP
  • C/C++
  • Java
  • Objective C
  • Python
  • VB6
  • COBOL
  • Cold Fusion
  • XML
  • SQL
  • ASP.NET
  • VB.NET
  • C#
  • Classic ASP
  • HTML
  • Flex
  • JavaScript/AJAX
  • JSP
  • PHP
  • VBScript
  • Injection Flaws
  • Authentication
  • Session Management
  • Access Control
  • Logic Flaws
  • Cleartext credentials
  • Cleartext data
  • Backdoor data
  • Data leakage
  • Credentials in memory
  • Credentials on filesystem
  • Data stored on filesystem
  • Poor cert management
slide16

Mobile Security Differences

Q: What’s the difference between this and mobile?

slide17

Mobile Security Differences |Mobile Security

Client

Network

Server

  • ABAP
  • C/C++
  • Java
  • Objective C
  • Python
  • VB6
  • COBOL
  • Cold Fusion
  • XML
  • SQL
  • ASP.NET
  • VB.NET
  • C#
  • Classic ASP
  • HTML
  • Flex
  • JavaScript/AJAX
  • JSP
  • PHP
  • VBScript
  • Injection Flaws
  • Authentication
  • Session Management
  • Access Control
  • Logic Flaws
  • Cleartext credentials
  • Cleartext data
  • Backdoor data
  • Data leakage
  • Credentials in memory
  • Credentials on filesystem
  • Data stored on filesystem
  • Poor cert management
slide19

Mobile Security Differences |Expanded Mobile Risk

  • Two key differences
    • Magnified network vulnerability
    • Your network traffic is more likely to be visible to others with a mobile device than at work or home
    • Magnified physical vulnerability
    • As with most other types of computer, once the attacker has physical access, it’s over
slide21

Attacker Perspective

  • Much of security comes down to seeing things from a different perspective, and mobile is no different
slide22

Attacker Perspective |What Users See

Get Sales Data

Get the username

Get the password

Edit my account

Remember the User

Generate Reports

slide23

Attacker Perspective |What Attackers See

Insufficient Data Storage

SQL Injection

Data Leakage

Cross Site Scripting

Sensitive Information Disclosure

Improper Session Handling

Weak Server Side Controls

Client Side Injection

slide27

Common Vulnerabilities |Most Apps Are Vulnerable

  • Most high-scrutiny (see: previously hacked) mobile apps are decently secure now, but the next tier down still have many issues
    • Evaluating any given application is likely to yield significant vulnerabilities
    • The younger, more eager the shop– the higher the chance of issues
slide28

Common Vulnerabilities |OWASP

Open Web Application Security Project

  • Thought leader in web security
  • Runs many projects designed to help industry security their applications
  • OWASP Top 10
  • Risk Rating Methodology
  • Vulnerability Prevention Cheat sheets
  • Our team is heading up the Mobile Top 10 2013
  • http://www.owasp.org/
slide30

Common Vulnerabilities |Real-world Perspective

  • Definitely check out the OWASP Top 10, but this is more about what we’re seeing in the wild
  • We constantly test mobile applications from the top companies in the world, and these are the top categories of issue we find in those applications
slide31

Common Vulnerabilities |Real-world Results

  • Case study of 120 Mobile applications for a single enterprise customer (results are typical)
  • 66% of applications contained a critical or high vulnerability that either:
    • Disclosed 1 or more users’ personal data
    • Compromised the backend system

66%

slide32

Common Vulnerabilities |Logic Flaws

  • Logic flaws are due to faulty developer assumptions, i.e. not thinking like an attacker
    • Changing an arbitrary user’s password
    • Bypassing multi-step authentication
    • Free product by skipping payment step
    • Product + refund by submitting negative number
    • Defeating a business limit by entering a high negative number
    • Getting a bulk discount on only one item by modifying the cart manually afterwards
slide33

Common Vulnerabilities |Logic Flaw Defense

  • Logic flaws are avoided by performing exhaustive vulnerability assessments before going to production
    • Fully understand the anticipated flow of the application
    • Assume the mind of the attacker
    • Identify places that developers likely made assumptions
    • Attempt to take advantage of those assumptions
    • As a developer, think in terms of abuse vs. just regular use
slide34

Common Vulnerabilities |Poor TLS Implementations

  • Many mobile developers are allowing SSL communication with any host
    • Trusting any certificate it sees
    • Allows expired certificates
    • Allows trivial MiTM attacks
    • Can connect to HTTPS once, and then fall back
    • Once in the middle, attackers can model your app’s functionality enroute to breaking it
slide35

Common Vulnerabilities |Poor TLS Implementation

  • TLS protection has multiple levels of security
    • Ensure HTTPS is always enabled
    • Attempt to match the name of the remote certificate
    • Certificate pinning*
    • Recognize that nothing is fool-proof, and adjust according to your app’s specific needs
    • Remember that pinning was a defense against compromised CAs, not against MiTM
slide36

Common Vulnerabilities |PromiscuousClient-side Storage

  • Perhaps the most abused functionality is client-side storage
    • Storage of credentials in plist files, SQLite databases
    • Failure to use KeyChain to store credentials
    • Storage of sensitive application data on filesystem
    • Apps (e.g.: banks) storing their images in the public folder rather than in their sandbox
    • Applications logging to the system log, but sending sensitive app data along with it
slide37

Common Vulnerabilities |PromiscuousClient-side Storage

  • Be cautious of anything you save—anywhere—including on the client-side
    • Ensure you’re using the platform-recommended solution to store credentials
    • Ensure you are storing everything from your app into the app sandbox so it cannot be read by other applications
    • Check all logging functionality and note what you’re sending
    • Observe your log files within the XCode log viewer and ensure you are not storing anything sensitive
slide38

Common Vulnerabilities |PromiscuousClient-side Storage

Q: What data on your iOS device is protected by the built-in encryption, i.e. the passcode?

slide39

Common Vulnerabilities |PromiscuousClient-side Storage

A: By default, onlyemail and texts.

In other words, most application data being stored on an iOS device is available to anyone who steals your phone—evenif it is locked and has a passcode.

slide40

Common Vulnerabilities |PromiscuousClient-side Storage

  • Corporate issued iPhone
  • Latest software (6.1.4)
  • Not jailbroken
  • Locked
  • With passcode
  • DEMO
slide41

Common Vulnerabilities |PromiscuousClient-side Storage

  • Be cautious of anything you save—anywhere—including on the client-side
    • Ensure you’re using the platform-recommended solution to store credentials
    • Ensure you use the Data Protection API to store any sensitive data; it will not be protected by default: (See: NSFileProtectionComplete in developer documenetation)
    • Ensure you are storing everything from your app into the app sandbox so it cannot be read by other applications
    • Check all logging functionality and note what you’re sending
    • Observe your log files within the XCode log viewer and ensure you are not storing anything sensitive
slide42

Common Vulnerabilities |Failure to Harden Binaries

  • There are a number of binary defenses that developers are not implementing
    • ASLR PIE (memory randomization)
    • Stack Smashing Protection Enabled (Canary-based)
    • Automatic Reference Counting (memory resources)
    • Binary debug not disabled  User path information disclosure
slide43

Common Vulnerabilities |Failure to Harden Binaries

  • Use all defenses possible to harden your binaries before release
    • While some are not critical security issues, they still can have an impact on the overall quality of your application
slide44

Common Vulnerabilities |Privacy Violations

  • Many applications violate privacy without developers being aware
    • Does the application access GeoLocation data?
    • Does the application access your Address Book?
    • Does the application access your Photos?
    • If so, what is your app doing with this data?
    • Does your application use analytics engines?
    • If so, what does it send there? (UUID, app data?)
slide45

Common Vulnerabilities |Privacy Violations

  • Go with an absolute least-privilege approach
    • Don’t access any data that could be considered private if you don’t need it
    • There are applications out there that can evaluate what a given binary accesses (AppAuthority, HP Risker)
slide46

Common Vulnerabilities |Assumption of Web Obscurity

  • A massive number of applications we see and compromise are compromised due to backend vulnerabilities
    • Promiscuous web services
    • Full SQL statements right in web service calls (saved money on MSSQL Server Manager)
    • Blatant SQLi, XSS, CSRF, File Includes, etc.
    • Many developers assume “who’s coming here?”
    • The datastores are often shared!
    • Shared hosting means compromise of multiple customers
slide47

Common Vulnerabilities |Assumption of Web Obscurity

  • Harden your web backend as if the mobile app didn’t even exist
    • Remember how easy it is to MiTM a mobile app
    • Assume everyone can see your traffic
    • This means they can see all the paths and parameters for your backend
    • Assume attackers will come knocking
    • Consider the risks of shared hosting, as others might not be taking these steps—even if you did
slide49

Takeaways

  • It’s an interesting time for mobile security
    • Everyone’s heading to mobile, and the attackers are following
    • Mobile is on the leading edge of development, so mobile projects are especially susceptible to security shortcuts
    • Most non-scrutinized applications have major vulnerabilities that are easily found
slide50

Takeaways

  • Think like an attacker and follow some basic steps to help you evaluate your own applications without much cost
  • Assume the attacker has access to the device and visibility of all traffic going to and from the server, and code accordingly (learn from cryptography)
  • As part of a threat modeling step, track your sensitive data through your app, from user to device to network to server; see where it’s vulnerable
  • Don’t store PII if you don’t have to
slide51

Takeaways

  • Remember that you must explicitly use the Data Protection APIs otherwise your data will still be available to a thief
  • Don’t be intimidated by “mobile” security; the fundamentals are the same
  • Use industry-tested methods for implementing security; be extremely weary of DIY solutions for input validation, encryption, authentication, etc.
  • Take advantage of the resources available to help you, e.g.: platform secure coding guides, OWASP, etc.
slide52

Takeaways |Resources

  • iOS Security Guidehttp://images.apple.com/iphone/business/docs/iOS_Security_Oct12.pdf
  • Android Security Guidehttp://source.android.com/tech/security/
  • OWASP Mobile Top 10https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
  • OWASP iOS Developer Cheat sheethttps://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet