Difference between revisions of "Mobile Top 10 2014-M6"

From OWASP
Jump to: navigation, search
(Created page with "{{Top_10_2010:SummaryTableHeaderBeginTemplate}} {{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}} {{Top_10_2010:SummaryTableValue-2-Template|Prevalence|COMMON}}...")
 
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
<center>[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks Back To The Mobile Top Ten Main Page]</center>
 +
{{Top_10_2010:SubsectionColoredTemplate|<center>Broken Cryptography</center>||year=2014}}
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
 
{{Top_10_2010:SummaryTableHeaderBeginTemplate}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Exploitability|EASY}}
Line 5: Line 7:
 
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 
{{Top_10_2010:SummaryTableValue-1-Template|Impact|SEVERE}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
 
{{Top_10_2010:SummaryTableHeaderEndTemplate}}
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat Description </td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Threat agents include the following: anyone with physical access to data that has been encrypted improperly, or mobile malware acting on an adversary's behalf.</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> Attack Vector Description </td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Attack vectors include the following: decryption of data via physical access to the device or network traffic capture, or malicious apps on the device with access to the encrypted data.</td>
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Security Weakness Description </td>
+
     <td colspan=2  {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>In order to exploit this weakness, an adversary must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process.</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Technical Impacts</td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability will result in the unauthorized retrieval of sensitive information from the mobile device.</td>
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Business Impacts </td>
+
     <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>This vulnerability can have a number of different business impacts. Typically, broken cryptography will result in the following:
 +
 
 +
* Privacy Violations;
 +
* Information Theft;
 +
* Code Theft;
 +
* Intellectual Property Theft; or
 +
* Reputational Damage.
 +
</td>
 
{{Top_10_2010:SummaryTableEndTemplate}}
 
{{Top_10_2010:SummaryTableEndTemplate}}
  
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=1|risk=2}}
 
The M1 category is one that is always in heavy debate. It encompasses almost everything that a mobile application can do badly that does not take place on the phone. Which is exactly the argument… should it be listed at all? Don’t we have Top Ten lists for Web Applications? Don’t we have one for cloud too?
 
 
In fact, we do. If we could be altogether sure that everyone who wanted information on mobile security also stopped by those projects… it would be a perfect world. Unfortunately, after two rounds of data collection from some of the world’s top assessment teams, we find that server side issues are so prevalent in mobile applications that we cannot ignore them in the Risk listing. While not statistically validated we feel that several factors lead to bad mobile application server code (and on a larger scale mobile insecurity in general):
 
 
* Rush to market
 
* Lack of security knowledge because of the new-ness of the languages
 
* Easy access to frameworks that don’t prioritize security
 
* Higher than average outsourced development
 
* Lower security budgets for mobile applications
 
* Assumption that the mobile OS takes full responsibility for security
 
* Weakness due to cross-platform development and compilation
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=2|risk=2}}
 
Secure coding and configuration practices must be used on server-side of the mobile application. For specific vulnerability information refer to the OWASP Web Top Ten or Cloud Top Ten projects. We will try and link references to those projects and other OWASP projects that provide more robust descriptions.
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=3|risk=2}}
 
  
 +
{{Top_10_2010:SubsectionColoredTemplate|Am I Vulnerable to Broken Cryptography?||year=2014}}
 +
Insecure use of cryptography is common in most mobile apps that leverage encryption. There are two fundamental ways that broken cryptography is manifested within mobile apps. First, the mobile app may use a process behind the encryption / decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data. Second, the mobile app may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary. The following subsections explore both of these scenarios in more depth:
 +
 +
== Reliance Upon Built-In Code Encryption Processes ==
  
If you look below, you can see that there is a ton of surface area to cover when thinking about M1:
+
By default, iOS applications are protected (in theory) from reverse engineering via code encryption. The iOS security model requires that apps be encrypted and signed by trustworthy sources in order to execute in non-jailbroken environments. Upon start-up, the iOS app loader will decrypt the app in memory and proceed to execute the code after its signature has been verified by iOS. This feature, in theory, prevents an attacker from conducting binary attacks against an iOS mobile app.
 
  
[[File:CloudTT_thum.png|border|350px]][[File:WebTT_thumb.png|border|350px]]
+
Using freely available tools like ClutchMod or GBD, an adversary will download the encrypted app onto their jailbroken device and take a snapshot of the decrypted app once the iOS loader loads it into memory and decrypts it (just before the loader kicks off execution). Once the adversary takes the snapshot and stores it on disk, the adversary can use tools like IDA Pro or Hopper to easily perform static / dynamic analysis of the app and conduct further binary attacks.
 
=== The Worst Offenders ===
 
  
While we cannot go over all of these, what we can do is list vulnerability types that we see most often within mobile applications:
+
Bypassing built-in code encryption algorithms is trivial at best. Always assume that an adversary will be able to bypass any built-in code encryption offered by the underlying mobile OS.
+
For more information about additional steps you can take to provide additional layers of reverse engineering prevention, see M10.
  
;Poor Web Services Hardening
+
== Poor Key Management Processes ==
: Logic flaws
 
:: [https://www.owasp.org/index.php/Testing_for_business_logic_(OWASP-BL-001) Testing for business logic flaws]
 
:: [https://www.owasp.org/index.php/Business_Logic_Security_Cheat_Sheet Business Logic Security Cheat Sheet]
 
: Weak Authentication
 
:: [https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management OWASP Top Ten Broken Authentication Section]
 
:: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet Authentication Cheat Sheet]
 
:: [https://www.owasp.org/index.php/Guide_to_Authentication Developers Guide for Authentication]
 
:: [https://www.owasp.org/index.php/Testing_for_authentication Testing for Authentication]
 
: Weak or no session management
 
: Session fixation
 
: Sensitive data transmitted using GET method
 
  
 +
The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:
  
; Insecure web server configurations
+
* Including the keys in the same attacker-readable directory as the encrypted content;
: Default content
+
* Making the keys otherwise available to the attacker;
: Administrative interfaces
+
* Avoid the use of hardcoded keys within your binary; and
 +
* Keys may be intercepted via binary attacks. See M10 for more information on preventing binary attacks.
  
 +
==Creation and Use of Custom Encryption Protocols==
  
; Injection (SQL, XSS, Command) on both web services and mobile-enabled websites
+
There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.
  
; Authentication flaws
+
Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform. Binary attacks may result in adversary identifying the common libraries you have used along with any hardcoded keys in the binary. In cases of very high security requirements around encryption, you should strongly consider the use of whitebox cryptography. See M10 for more information on preventing binary attacks that could lead to the exploitation of common libraries.
  
; Session Management flaws
+
==Use of Insecure and/or Deprecated Algorithms==
  
; Access control vulnerabilities
+
Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:
  
; Local and Remote File Includes
+
* RC2
 +
* MD4
 +
* MD5
 +
* SHA1
  
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
 
{{Mobile_Top_10_2012:SubsectionAdvancedTemplate|type={{Mobile_Top_10_2012:StyleTemplate}}|number=4|risk=2}}
References
 

Latest revision as of 01:06, 8 October 2014

Back To The Mobile Top Ten Main Page
Broken Cryptography
Threat Agents Attack Vectors Security Weakness Technical Impacts Business Impacts
Application Specific Exploitability
EASY
Prevalence
COMMON
Detectability
EASY
Impact
SEVERE
Application / Business Specific
Threat agents include the following: anyone with physical access to data that has been encrypted improperly, or mobile malware acting on an adversary's behalf. Attack vectors include the following: decryption of data via physical access to the device or network traffic capture, or malicious apps on the device with access to the encrypted data. In order to exploit this weakness, an adversary must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process. This vulnerability will result in the unauthorized retrieval of sensitive information from the mobile device. This vulnerability can have a number of different business impacts. Typically, broken cryptography will result in the following:
  • Privacy Violations;
  • Information Theft;
  • Code Theft;
  • Intellectual Property Theft; or
  • Reputational Damage.


Am I Vulnerable to Broken Cryptography?

Insecure use of cryptography is common in most mobile apps that leverage encryption. There are two fundamental ways that broken cryptography is manifested within mobile apps. First, the mobile app may use a process behind the encryption / decryption that is fundamentally flawed and can be exploited by the adversary to decrypt sensitive data. Second, the mobile app may implement or leverage an encryption / decryption algorithm that is weak in nature and can be directly decrypted by the adversary. The following subsections explore both of these scenarios in more depth:

Reliance Upon Built-In Code Encryption Processes

By default, iOS applications are protected (in theory) from reverse engineering via code encryption. The iOS security model requires that apps be encrypted and signed by trustworthy sources in order to execute in non-jailbroken environments. Upon start-up, the iOS app loader will decrypt the app in memory and proceed to execute the code after its signature has been verified by iOS. This feature, in theory, prevents an attacker from conducting binary attacks against an iOS mobile app.

Using freely available tools like ClutchMod or GBD, an adversary will download the encrypted app onto their jailbroken device and take a snapshot of the decrypted app once the iOS loader loads it into memory and decrypts it (just before the loader kicks off execution). Once the adversary takes the snapshot and stores it on disk, the adversary can use tools like IDA Pro or Hopper to easily perform static / dynamic analysis of the app and conduct further binary attacks.

Bypassing built-in code encryption algorithms is trivial at best. Always assume that an adversary will be able to bypass any built-in code encryption offered by the underlying mobile OS. For more information about additional steps you can take to provide additional layers of reverse engineering prevention, see M10.

Poor Key Management Processes

The best algorithms don't matter if you mishandle your keys. Many make the mistake of using the correct encryption algorithm, but implementing their own protocol for employing it. Some examples of problems here include:

  • Including the keys in the same attacker-readable directory as the encrypted content;
  • Making the keys otherwise available to the attacker;
  • Avoid the use of hardcoded keys within your binary; and
  • Keys may be intercepted via binary attacks. See M10 for more information on preventing binary attacks.

Creation and Use of Custom Encryption Protocols

There is no easier way to mishandle encryption--mobile or otherwise--than to try to create and use your own encryption algorithms or protocols.

Always use modern algorithms that are accepted as strong by the security community, and whenever possible leverage the state of the art encryption APIs within your mobile platform. Binary attacks may result in adversary identifying the common libraries you have used along with any hardcoded keys in the binary. In cases of very high security requirements around encryption, you should strongly consider the use of whitebox cryptography. See M10 for more information on preventing binary attacks that could lead to the exploitation of common libraries.

Use of Insecure and/or Deprecated Algorithms

Many cryptographic algorithms and protocols should not be used because they have been shown to have significant weaknesses or are otherwise insufficient for modern security requirements. These include:

  • RC2
  • MD4
  • MD5
  • SHA1

References