T

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

4. CEO

6. Principal Consultant

8. Principal Consultant

10. WhyUnique and different security risks

11. Goal To build security into mobile dev. life cycle

12. Interested? ContributeThreat Model Risks Controls Training Dev. Guide Secure Libraries Tools Methodologies Cheat Sheets

13. Mobile Threat Model

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)

20. 8 Mobile Threat Model

21. Top 10 Risks

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

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

34. Credentials disclosed

35. Privacy violations

38. Never use public storage areas (ie- SD card)

39. Leverage secure containers and platform provided file encryption APIs

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

46. Leverage the wealth of knowledge that is already out there

47. OWASP Web Top 10, Cloud Top 10, Web Services Top 10

49. Yes, this unfortunately happens often

50. Weakly encrypted data in transit

51. Strong encryption, but ignoring security warnings

52. Ignoring certificate validation errors

54. Tampering w/ data in transit

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

59. This includes data over carrier networks, WiFi, and even NFC

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

69. Toll fraud

72. Use prepared statements for database calls…concatenation is still bad, and always will be bad

74. Some apps rely solely on immutable, potentially compromised values (IMEI, IMSI, UUID)

75. Hardware identifiers persist across data wipes and factory resets

79. Out-of-band doesn’t work when it’s all the same device

81. Why? Convenience and usability

82. Apps maintain sessions via

83. HTTP cookies

84. OAuth tokens

85. SSO authentication services

87. Unauthorized access

89. Ensure that tokens can be revoked quickly in the event of a lost/stolen device

91. Similar but different depending on platform

92. iOS- Abusing URL Schemes

93. Android- Abusing Intents

94. Several attack vectors

95. Malicious apps

97. Data exfiltration

99. Prompt the user for additional authorization before allowing

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

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

114. Broken implementations using strong crypto libraries

115. Custom, easily defeated crypto implementations

116. Encoding != encryption

117. Obfuscation != encryption

119. Privilege escalation

122. Leverage battle-tested crypto libraries vice writing your own

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

132. Keep proprietary and sensitive business logic on the server

135. RC1 then becomes ‘Final v1.0’

136. 12 month revision cycle

137. Rapidly evolving platforms

138. Stale data = not as useful

140. We’ve identified the issues…now we have to fix them

141. Platforms must mature, frameworks must mature, apps must mature

143. Zach Lanier zach.lanier@intrepidusgroup.comhttp://twitter.com/quine

144. Mike Zusmanmike.zusman@carvesystems.comhttp://twitter.com/schmoilito