Appsec USA<br />Minneapolis, MN<br />September 23, 2011<br />OWASP Top 10 Mobile Risks<br />Jack Mannino, nVisium Security...
2<br />Agenda<br />Introductions<br />Mobile Security Project<br />Mobile Threat Model<br />Top 10 Risks<br />Wrap Up/Q&A<...
3<br />Introductions<br />Jack Mannino<br /><ul><li>nVisium Security
CEO
https://www.nvisiumsecurity.com</li></ul>Mike Zusman<br /><ul><li>Carve Systems
Principal Consultant
http://www.carvesystems.com</li></ul>Zach Lanier<br /><ul><li>Intrepidus Group
Principal Consultant
https://intrepidusgroup.com</li></li></ul><li>4<br />Mobile Security Project<br /><ul><li>Began Q3 2010
WhyUnique and different security risks
Goal To build security into mobile dev. life cycle
Interested? Contribute</li></ul>Threat Model<br />Risks<br />Controls<br />Training<br />Dev. Guide<br />Secure Libraries<...
Mobile Threat Model<br />
6<br />Mobile Threat Model<br /><ul><li>Platforms vary with mileage
Very different from traditional web app model due to wildly varying use cases and usage patterns
Must consider more than the ‘apps’
Remote web services
Platform integration (iCloud, C2DM)
Device (in)security considerations</li></li></ul><li>7<br />Mobile Threat Model<br />
8<br />Mobile Threat Model<br />
Top 10 Risks<br />
10<br />Top 10 Risks<br /><ul><li>Intended to be platform-agnostic
Focused on areas of risk rather than individual vulnerabilities
Weighted utilizing the OWASP Risk Rating Methodology
https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
Thanks to everyone who participated</li></li></ul><li>11<br />Top 10 Risks<br />
12<br />M1- Insecure Data Storage<br /><ul><li>Sensitive data left unprotected
Applies to locally stored data + cloud synced
Generally a result of:
Not encrypting data
Caching data not intended for long-term storage
Weak or global permissions
Not leveraging platform best-practices</li></ul>Impact<br /><ul><li>Confidentiality of data lost
Credentials disclosed
Privacy violations
Non-compliance</li></li></ul><li>13<br />M1- Insecure Data Storage<br />
14<br />M1- Insecure Data StoragePrevention Tips<br /><ul><li>Store ONLY what is absolutely required
Never use public storage areas (ie- SD card)
Leverage secure containers and platform provided file encryption APIs
Do not grant files world readable or world writeable permissions</li></li></ul><li>15<br />M2- Weak Server Side Controls<b...
Not mobile specific per se, but essential to get right
We still can’t trust the client
Luckily, we understand these issues well
Existing controls may need to be re-evaluated (ie- out of band comms)</li></ul>Impact<br /><ul><li>Confidentially of data ...
Upcoming SlideShare
Loading in...5
×

OWASP Top 10 Mobile Risks

53,804

Published on

T

Published in: Technology
5 Comments
65 Likes
Statistics
Notes
No Downloads
Views
Total Views
53,804
On Slideshare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
3,427
Comments
5
Likes
65
Embeds 0
No embeds

No notes for slide

OWASP Top 10 Mobile Risks

  1. 1. Appsec USA<br />Minneapolis, MN<br />September 23, 2011<br />OWASP Top 10 Mobile Risks<br />Jack Mannino, nVisium Security<br />Mike Zusman, Carve Systems<br />Zach Lanier, Intrepidus Group<br />OWASP Mobile Security Project<br />
  2. 2. 2<br />Agenda<br />Introductions<br />Mobile Security Project<br />Mobile Threat Model<br />Top 10 Risks<br />Wrap Up/Q&A<br />
  3. 3. 3<br />Introductions<br />Jack Mannino<br /><ul><li>nVisium Security
  4. 4. CEO
  5. 5. https://www.nvisiumsecurity.com</li></ul>Mike Zusman<br /><ul><li>Carve Systems
  6. 6. Principal Consultant
  7. 7. http://www.carvesystems.com</li></ul>Zach Lanier<br /><ul><li>Intrepidus Group
  8. 8. Principal Consultant
  9. 9. https://intrepidusgroup.com</li></li></ul><li>4<br />Mobile Security Project<br /><ul><li>Began Q3 2010
  10. 10. WhyUnique and different security risks
  11. 11. Goal To build security into mobile dev. life cycle
  12. 12. Interested? Contribute</li></ul>Threat Model<br />Risks<br />Controls<br />Training<br />Dev. Guide<br />Secure Libraries<br />Tools<br />Methodologies<br />Cheat Sheets<br />
  13. 13. Mobile Threat Model<br />
  14. 14. 6<br />Mobile Threat Model<br /><ul><li>Platforms vary with mileage
  15. 15. Very different from traditional web app model due to wildly varying use cases and usage patterns
  16. 16. Must consider more than the ‘apps’
  17. 17. Remote web services
  18. 18. Platform integration (iCloud, C2DM)
  19. 19. Device (in)security considerations</li></li></ul><li>7<br />Mobile Threat Model<br />
  20. 20. 8<br />Mobile Threat Model<br />
  21. 21. Top 10 Risks<br />
  22. 22. 10<br />Top 10 Risks<br /><ul><li>Intended to be platform-agnostic
  23. 23. Focused on areas of risk rather than individual vulnerabilities
  24. 24. Weighted utilizing the OWASP Risk Rating Methodology
  25. 25. https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
  26. 26. Thanks to everyone who participated</li></li></ul><li>11<br />Top 10 Risks<br />
  27. 27. 12<br />M1- Insecure Data Storage<br /><ul><li>Sensitive data left unprotected
  28. 28. Applies to locally stored data + cloud synced
  29. 29. Generally a result of:
  30. 30. Not encrypting data
  31. 31. Caching data not intended for long-term storage
  32. 32. Weak or global permissions
  33. 33. Not leveraging platform best-practices</li></ul>Impact<br /><ul><li>Confidentiality of data lost
  34. 34. Credentials disclosed
  35. 35. Privacy violations
  36. 36. Non-compliance</li></li></ul><li>13<br />M1- Insecure Data Storage<br />
  37. 37. 14<br />M1- Insecure Data StoragePrevention Tips<br /><ul><li>Store ONLY what is absolutely required
  38. 38. Never use public storage areas (ie- SD card)
  39. 39. Leverage secure containers and platform provided file encryption APIs
  40. 40. Do not grant files world readable or world writeable permissions</li></li></ul><li>15<br />M2- Weak Server Side Controls<br /><ul><li>Applies to the backend services
  41. 41. Not mobile specific per se, but essential to get right
  42. 42. We still can’t trust the client
  43. 43. Luckily, we understand these issues well
  44. 44. Existing controls may need to be re-evaluated (ie- out of band comms)</li></ul>Impact<br /><ul><li>Confidentially of data lost
  45. 45. Integrity of data not trusted</li></li></ul><li>16<br />M2- Weak Server Side Controls<br />OWASP Top 10<br /><ul><li>https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project</li></ul>OWASP Cloud Top 10<br /><ul><li>https://www.owasp.org/images/4/47/Cloud-Top10-Security-Risks.pdf</li></li></ul><li>17<br />M2- Weak Server Side ControlsPrevention Tips<br /><ul><li>Understand the additional risks mobile apps introduce into existing architectures
  46. 46. Leverage the wealth of knowledge that is already out there
  47. 47. OWASP Web Top 10, Cloud Top 10, Web Services Top 10
  48. 48. Cheat sheets, development guides, ESAPI</li></li></ul><li>18<br />M3- Insufficient Transport Layer Protection<br /><ul><li>Complete lack of encryption for transmitted data
  49. 49. Yes, this unfortunately happens often
  50. 50. Weakly encrypted data in transit
  51. 51. Strong encryption, but ignoring security warnings
  52. 52. Ignoring certificate validation errors
  53. 53. Falling back to plain text after failures</li></ul>Impact<br /><ul><li>Man-in-the-middle attacks
  54. 54. Tampering w/ data in transit
  55. 55. Confidentiality of data lost</li></li></ul><li>19<br />M3- Insufficient Transport Layer Protection<br />Real World Example: Google ClientLogin Authentication Protocol<br /><ul><li>Authorization header sent over HTTP
  56. 56. When users connected via wifi, apps automatically sent the token in an attempt to automatically synchronize data from server
  57. 57. Sniff this value, impersonate the user
  58. 58. http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html</li></li></ul><li>20<br />M3- Insufficient Transport Layer ProtectionPrevention Tips<br /><ul><li>Ensure that all sensitive data leaving the device is encrypted
  59. 59. This includes data over carrier networks, WiFi, and even NFC
  60. 60. When security exceptions are thrown, it’s generally for a reason…DO NOT ignore them!</li></li></ul><li>21<br />M4- Client Side Injection<br /><ul><li>Apps using browser libraries
  61. 61. Pure web apps
  62. 62. Hybrid web/native apps
  63. 63. Some familiar faces
  64. 64. XSS and HTML Injection
  65. 65. SQL Injection
  66. 66. New and exciting twists
  67. 67. Abusing phone dialer + SMS
  68. 68. Abusing in-app payments</li></ul>Impact<br /><ul><li>Device compromise
  69. 69. Toll fraud
  70. 70. Privilege escalation</li></li></ul><li>22<br />M4- Client Side Injection<br />Garden Variety XSS….<br />With access to:<br />
  71. 71. 23<br />M4- Client Side InjectionPrevention Tips<br /><ul><li>Sanitize or escape untrusted data before rendering or executing it
  72. 72. Use prepared statements for database calls…concatenation is still bad, and always will be bad
  73. 73. Minimize the sensitive native capabilities tied to hybrid web functionality</li></li></ul><li>24<br />M5- Poor Authorization and Authentication<br /><ul><li>Part mobile, part architecture
  74. 74. Some apps rely solely on immutable, potentially compromised values (IMEI, IMSI, UUID)
  75. 75. Hardware identifiers persist across data wipes and factory resets
  76. 76. Adding contextual information is useful, but not foolproof</li></ul>Impact<br /><ul><li>Privilege escalation
  77. 77. Unauthorized access</li></li></ul><li>25<br />M5- Poor Authorization and Authentication<br />
  78. 78. 26<br />M5- Poor Authorization and AuthenticationPrevention Tips<br /><ul><li>Contextual info can enhance things, but only as part of a multi-factor implementation
  79. 79. Out-of-band doesn’t work when it’s all the same device
  80. 80. Never use device ID or subscriber ID as sole authenticator</li></li></ul><li>27<br />M6- Improper Session Handling<br /><ul><li>Mobile app sessions are generally MUCH longer
  81. 81. Why? Convenience and usability
  82. 82. Apps maintain sessions via
  83. 83. HTTP cookies
  84. 84. OAuth tokens
  85. 85. SSO authentication services
  86. 86. Bad idea= using a device identifier as a session token</li></ul>Impact<br /><ul><li>Privilege escalation
  87. 87. Unauthorized access
  88. 88. Circumvent licensing and payments</li></li></ul><li>28<br />M6- Improper Session HandlingPrevention Tips<br /><ul><li>Don’t be afraid to make users re-authenticate every so often
  89. 89. Ensure that tokens can be revoked quickly in the event of a lost/stolen device
  90. 90. Utilize high entropy, tested token generation resources</li></li></ul><li>29<br />M7- Security Decisions Via Untrusted Inputs<br /><ul><li>Can be leveraged to bypass permissions and security models
  91. 91. Similar but different depending on platform
  92. 92. iOS- Abusing URL Schemes
  93. 93. Android- Abusing Intents
  94. 94. Several attack vectors
  95. 95. Malicious apps
  96. 96. Client side injection</li></ul>Impact<br /><ul><li>Consuming paid resources
  97. 97. Data exfiltration
  98. 98. Privilege escalation</li></li></ul><li>30<br />M7- Security Decisions Via Untrusted Inputs<br />Skype iOS URL Scheme Handling Issue<br /><ul><li>http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/</li></li></ul><li>31<br />M7- Security Decisions Via Untrusted InputsPrevention Tips<br /><ul><li>Check caller’s permissions at input boundaries
  99. 99. Prompt the user for additional authorization before allowing
  100. 100. Where permission checks cannot be performed, ensure additional steps required to launch sensitive actions</li></li></ul><li>32<br />M8- Side Channel Data Leakage<br /><ul><li>Mix of not disabling platform features and programmatic flaws
  101. 101. Sensitive data ends up in unintended places
  102. 102. Web caches
  103. 103. Keystroke logging
  104. 104. Screenshots (ie- iOSbackgrounding)
  105. 105. Logs (system, crash)
  106. 106. Temp directories
  107. 107. Understand what 3rd party libraries in your apps are doing with user data (ie- ad networks, analytics)</li></ul>Impact<br /><ul><li>Data retained indefinitely
  108. 108. Privacy violations</li></li></ul><li>33<br />M8- Side Channel Data Leakage<br />Screenshots<br />Logging<br />
  109. 109. 34<br />M8- Side Channel Data LeakagePrevention Tips<br /><ul><li>Never log credentials, PII, or other sensitive data to system logs
  110. 110. Remove sensitive data before screenshots are taken, disable keystroke logging per field, and utilize anti-caching directives for web content
  111. 111. Debug your apps before releasing them to observe files created, written to, or modified in any way
  112. 112. Carefully review any third party libraries you introduce and the data they consume
  113. 113. Test your applications across as many platform versions as possible</li></li></ul><li>35<br />M9- Broken Cryptography<br /><ul><li>Two primary categories
  114. 114. Broken implementations using strong crypto libraries
  115. 115. Custom, easily defeated crypto implementations
  116. 116. Encoding != encryption
  117. 117. Obfuscation != encryption
  118. 118. Serialization != encryption</li></ul>Impact<br /><ul><li>Confidentiality of data lost
  119. 119. Privilege escalation
  120. 120. Circumvent business logic</li></li></ul><li>36<br />M9- Broken Cryptography<br />ldc literal_876:"QlVtT0JoVmY2N2E=”<br />invokestaticbyte[] decode( java.lang.String ) // Base 64<br />invokespecial_libjava.lang.String.<init> // pc=2<br />astore8<br />private final byte[] com.picuploader.BizProcess.SendRequest.routine_12998 <br /> (com.picuploader.BizProcess.SendRequest, byte[], byte[] );<br /> {<br /> enter<br />new_libnet.rim.device.api.crypto.TripleDESKey<br />
  121. 121. 37<br />M9- Broken CryptographyPrevention Tips<br /><ul><li>Storing the key with the encrypted data negates everything
  122. 122. Leverage battle-tested crypto libraries vice writing your own
  123. 123. Take advantage of what your platform already provides!</li></li></ul><li>38<br />M10- Sensitive Information Disclosure<br /><ul><li>We differentiate by stored (M1) vs. embedded/hardcoded (M10)
  124. 124. Apps can be reverse engineered with relative ease
  125. 125. Code obfuscation raises the bar, but doesn’t eliminate the risk
  126. 126. Commonly found “treasures”:
  127. 127. API keys
  128. 128. Passwords
  129. 129. Sensitive business logic</li></ul>Impact<br /><ul><li>Credentials disclosed
  130. 130. Intellectual property exposed</li></li></ul><li>39<br />M10- Sensitive Information Disclosure<br />
  131. 131. 40<br />M10- Sensitive Information DisclosurePrevention Tips<br /><ul><li>Private API keys are called that for a reason…keep them off of the client
  132. 132. Keep proprietary and sensitive business logic on the server
  133. 133. Almost never a legitimate reason to hardcode a password (if there is, you have other problems)</li></li></ul><li>Wrap Up<br />
  134. 134. 42<br />Going Forward<br /><ul><li>60 day review period open to the public
  135. 135. RC1 then becomes ‘Final v1.0’
  136. 136. 12 month revision cycle
  137. 137. Rapidly evolving platforms
  138. 138. Stale data = not as useful
  139. 139. If you have suggestions or ideas, we want them!</li></li></ul><li>43<br />Conclusion<br /><ul><li>This is a good start, but we have a long way to go
  140. 140. We’ve identified the issues…now we have to fix them
  141. 141. Platforms must mature, frameworks must mature, apps must mature
  142. 142. The OWASP Mobile body of knowledge must grow</li></li></ul><li>44<br />Q&A<br />Thanks for listening!<br /><ul><li>Jack Mannino jack@nvisiumsecurity.comhttp://twitter.com/jack_mannino
  143. 143. Zach Lanier zach.lanier@intrepidusgroup.comhttp://twitter.com/quine
  144. 144. Mike Zusmanmike.zusman@carvesystems.comhttp://twitter.com/schmoilito</li>
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×