Appsec usa 2011 owasp top 10 mobile risks-1

  • 2,120 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
2,120
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
128
Comments
1
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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