T

1. Appsec USAMinneapolis, MNSeptember 23, 2011OWASP Top 10 Mobile RisksJack Mannino, nVisium SecurityMike Zusman, Carve SystemsZach Lanier, Intrepidus GroupOWASP Mobile Security Project

2. 2AgendaIntroductionsMobile Security ProjectMobile Threat ModelTop 10 RisksWrap Up/Q&A

3. 3IntroductionsJack ManninonVisium Security

4. CEO

5. https://www.nvisiumsecurity.comMike ZusmanCarve Systems

6. Principal Consultant

7. http://www.carvesystems.comZach LanierIntrepidus Group

8. Principal Consultant

9. https://intrepidusgroup.com4Mobile Security ProjectBegan Q3 2010

10. WhyUnique and different security risks

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

12. Interested? ContributeThreat ModelRisksControlsTrainingDev. GuideSecure LibrariesToolsMethodologiesCheat Sheets

13. Mobile Threat Model

14. 6Mobile Threat ModelPlatforms 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 considerations7Mobile Threat Model

20. 8Mobile Threat Model

21. Top 10 Risks

22. 10Top 10 RisksIntended 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 participated11Top 10 Risks

27. 12M1- Insecure Data StorageSensitive 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-practicesImpactConfidentiality of data lost

34. Credentials disclosed

35. Privacy violations

36. Non-compliance13M1- Insecure Data Storage

37. 14M1- Insecure Data StoragePrevention TipsStore 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 permissions15M2- Weak Server Side ControlsApplies 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)ImpactConfidentially of data lost

45. Integrity of data not trusted16M2- Weak Server Side ControlsOWASP Top 10https://www.owasp.org/index.php/Category:OWASP_Top_Ten_ProjectOWASP Cloud Top 10https://www.owasp.org/images/4/47/Cloud-Top10-Security-Risks.pdf17M2- Weak Server Side ControlsPrevention TipsUnderstand 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, ESAPI18M3- Insufficient Transport Layer ProtectionComplete 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 failuresImpactMan-in-the-middle attacks

54. Tampering w/ data in transit

55. Confidentiality of data lost19M3- Insufficient Transport Layer ProtectionReal World Example: Google ClientLogin Authentication ProtocolAuthorization 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.html20M3- Insufficient Transport Layer ProtectionPrevention TipsEnsure 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!21M4- Client Side InjectionApps 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 paymentsImpactDevice compromise

69. Toll fraud

70. Privilege escalation22M4- Client Side InjectionGarden Variety XSS….With access to:

71. 23M4- Client Side InjectionPrevention TipsSanitize 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 functionality24M5- Poor Authorization and AuthenticationPart 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 foolproofImpactPrivilege escalation

77. Unauthorized access25M5- Poor Authorization and Authentication

78. 26M5- Poor Authorization and AuthenticationPrevention TipsContextual 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 authenticator27M6- Improper Session HandlingMobile 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 tokenImpactPrivilege escalation

87. Unauthorized access

88. Circumvent licensing and payments28M6- Improper Session HandlingPrevention TipsDon’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 resources29M7- Security Decisions Via Untrusted InputsCan 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 injectionImpactConsuming paid resources

97. Data exfiltration

98. Privilege escalation30M7- Security Decisions Via Untrusted InputsSkype iOS URL Scheme Handling Issuehttp://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/31M7- Security Decisions Via Untrusted InputsPrevention TipsCheck 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 actions32M8- Side Channel Data LeakageMix 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)ImpactData retained indefinitely

108. Privacy violations33M8- Side Channel Data LeakageScreenshotsLogging

109. 34M8- Side Channel Data LeakagePrevention TipsNever 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 possible35M9- Broken CryptographyTwo primary categories

114. Broken implementations using strong crypto libraries

115. Custom, easily defeated crypto implementations

116. Encoding != encryption

117. Obfuscation != encryption

118. Serialization != encryptionImpactConfidentiality of data lost

119. Privilege escalation

120. Circumvent business logic36M9- Broken Cryptographyldc literal_876:"QlVtT0JoVmY2N2E=”invokestaticbyte[] decode( java.lang.String ) // Base 64invokespecial_libjava.lang.String.<init> // pc=2astore8private final byte[] com.picuploader.BizProcess.SendRequest.routine_12998 (com.picuploader.BizProcess.SendRequest, byte[], byte[] ); { enternew_libnet.rim.device.api.crypto.TripleDESKey

121. 37M9- Broken CryptographyPrevention TipsStoring 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!38M10- Sensitive Information DisclosureWe 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 logicImpactCredentials disclosed

130. Intellectual property exposed39M10- Sensitive Information Disclosure

131. 40M10- Sensitive Information DisclosurePrevention TipsPrivate 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. 42Going Forward60 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!43ConclusionThis 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 grow44Q&AThanks 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