Secure Android Apps- nVisium Security

1. Secure Android ApplicationsThe OWASP WayJack ManninoCEO/Chief “Breaker”ISSA DC- June 21, 2011https://www.nvisiumsecurity.comhttp://twitter.com/jack_manninohttp://www.linkedin.com/pub/jack-mannino/7/2b7/562©2011 nVisium Security Inc.

2. OverviewWho I am/ What we do

3. OWASP Mobile Security Project

4. Mobile World Meets Security World

5. Android Crash Course

6. Threat Modeling Android Apps

7. Risks and Controls

8. Where Do We Go From here?

9. Q&A, ResourcesWho I Am/ What We Do/ Where We AreWho I am

10. Jack Mannino

11. Company co-founder

12. Co-leader of the OWASP Mobile Security Project

13. Has a lot of phones…..

14. What we do:

15. Mobile Application Security

16. Web Application Security

17. Penetration Testing

18. Secure Development Training

19. Where we are:

20. Northern VirginiaOWASP Mobile Security Project

21. OWASP Mobile Security ProjectBegan in 2010

22. Current state of mobile application security: bad

23. We are aiming to make it: good

24. How do we plan to achieve this?OWASP Mobile Security Project

25. DisclaimerWe support OWASP by contributing expertise to the security community

26. OWASP does not support or endorse our business and services

27. Why am I mentioning this?

28. https://www.owasp.org/index.php/OWASP_brand_usage_rulesMobile World Meets Security World

29. Mobile World Meets Security WorldOnce upon a time, all phones could do was make phone calls….

30. And then, the world changed

31. Today’s mobile devices do things like

32. Make phone calls

33. Send SMS messages

34. Browse the web

35. VPN into corporate assets

36. Video conferencing

37. Track our location

38. Tap our phones to pay for things (soon)

39. Is anyone making money?

40. Do people use these things and their “apps”?Mobile World Meets Security World- Show Me The Money!!“Gartner Forecasts Mobile App Store Revenues Will Hit $15 Billion in 2011” (http://techcrunch.com/2011/01/26/mobile-app-store-15-billion-2011/)“Industry first: Smartphones pass PCs in sales” (http://tech.fortune.cnn.com/2011/02/07/idc-smartphone-shipment-numbers-passed-pc-in-q4-2010/)

41. Android Crash Course

42. And Now…Android!Debuted in 2008

43. Most popular mobile platform aroundPeople Use Android….Now What?Huge market share + attack monetization = target

44. Android Market is OPEN (in a bad way)

45. In the past 2 months, 4 times as much Android malware as all of 2010 (Source: Friend @ Lookout Mobile Security)

46. GGTracker- Toll fraud

47. DroidDream- Trojan in over 50 Android apps

48. Plankton- Steals browsing history, credentials, device logs, and more

49. 12 apps undetected in the Android Market for over 2 months!

50. Masqueraded with titles like “Angry Birds Rio Unlock”It Gets WorseMobile developers are partying like it’s 1999

51. Android platform is highly fragmented

52. Apps are self-signed

53. Old vulnerabilities are new vulnerabilities

54. New developers, new companies

55. Have we learned anything?!Android Crash Course- OverviewLinux-based operating system

56. Optimized for ARM architecture

57. Android runtime and libraries run on top of the OS

58. Applications run within the Dalvik Virtual Machine

59. Dalvik = optimization, not security

60. Each application runs in its own process (with exceptions)

61. Permissions model dictates what apps can/can’t do (sometimes)Android Crash Course- Architecture

62. Android Crash Course- EssentialsAndroidManifest.xml

63. Main configuration file

64. Where most components are declared

65. Permissions

66. Activities

67. Intents

68. Content ProvidersAndroid Crash Course- EssentialsPermissions

69. Applications are granted permissions for various actions

70. Declared within AndroidManifest.xml

71. “All or nothing” basis

72. ACCESS_FINE_LOCATION

73. CALL_PHONE

74. WRITE_SETTINGS

75. WRITE_SMS

76. READ_LOGS

77. And many, many more

78. Custom permissions tooAndroid Crash Course- EssentialsPermissions

79. Some developers go overboard

80. Questionable apps often request ridiculous permissions too

81. Example: Justin Bieber Wallpaper

82. android.permission.PROCESS_OUTGOING_CALLS

83. android.permission.WAKE_LOCK,

84. android.permission.READ_PHONE_STATE

85. android.permission.INTERNET

86. android.permission.RECEIVE_BOOT_COMPLETED

87. android.permission.ACCESS_NETWORK_STATE

88. android.permission.ACCESS_COARSE_LOCATION

89. android.permission.ACCESS_FINE_LOCATION

90. com.google.android.googleapps.permission.GOOGLE_AUTH

91. com.google.android.googleapps.permission.GOOGLE_AUTH.OTHER_SERVICES

92. android.permission.GET_ACCOUNTSAndroid Crash Course- EssentialsActivity

93. Single, focused thing a user can do (simple definition)Source: http://developer.android.com/reference/android/app/Activity.html

94. Android Crash Course- EssentialsIntent

95. Used to launch Activities and communicate with other components

96. Primary way of passing around data within AndroidAndroid Crash Course- EssentialsContent Provider

97. Used to expose and access data across applications

98. Permissions are declared by provider attribute in AndroidManifest.xml

99. Exposes data using a URI format

100. content://com.somepackage.topsecret/piidata/3Record IDAuthority(class name)PrefixPath

101. Threat Modeling Android Apps

102. Threat Modeling Android AppsThreat modeling is used to better understand an application’s surface for attackDon’t assume the sky is falling…..

103. Assume that it already fell

104. Users:

105. Root their phones

106. Lose their phones

107. Install things they shouldn’t

108. Use public wifi

109. Never listen to security people (ever)…

110. Now we can see the bigger pictureThreat Modeling Android Apps

111. Threat Modeling Android Apps- Loss Or Theft

112. Threat Modeling Android Apps- Remote Market Attack

113. Threat Modeling Android Apps- Legacy Architectures

114. Risks And Controls

115. OWASP Mobile Top 10 Risks and ControlsTop 10 RisksInsecure or unnecessary client-side data storageLack of data protection in transitPersonal data leakageFailure to protect resources with strong authenticationFailure to implement least privilege authorization policyClient-side injectionClient-side Denial Of Service (DoS)Malicious third-party codeClient-side buffer overflowFailure to apply server-side controls

116. #1 Insecure or Unecessary Client-Side Data StorageDo I really have to store it?#2 Lack of Data Protection in TransitNo SSL/TLS

117. Broken SSL/TLS

118. Ignoring certificate errors to “make apps work”

119. Facilitates Man In The Middle (MITM) attacks

120. Near Field Communications (NFC) leaves transport encryption up to the developers to implement correctly

121. Controls:

122. Use strong transport encryption when transmitting sensitive information

123. Even over 3G/4G…assume the carrier is compromised too

124. Detect errors and properly handle them

125. Unrecognized CA

126. Certificate name mismatches#3 Personal Data LeakageLogging sensitive information

127. Caching sensitive information

128. Browser

129. Search history

130. Location information

131. Controls:

132. Use only protected storage areas

133. Never external media!

134. Don’t use the global log file

135. Understand the implications of what you are storing and caching

136. Do you really need 3 years of GPS info on the device?#4 Failure To Protect Resources With Strong AuthenticationThis risk presents itself in multiple ways:

137. App-to-app

138. Single Sign On (Google Auth, Facebook)

139. Exposing Content Providers, Broadcasts

140. Client/Server

141. Has overlap with #10- Failure To Apply Server Side Controls

142. Controls:

143. Keep small session timeout windows when possible

144. Require re-authentication for sensitive actions

145. Never authenticate based on:

146. Device ID

147. Location#5 Failure To Implement Least Privilege Authorization PolicyOverly permissive permissions granted to apps

148. Does an application really need to modify system settings?

149. Does the permission even get used?

150. File access

151. MODE_WORLD_READABLE, MODE_WORLD_WRITEABLE

152. Overexposing Android components

153. Activities

154. Intents

155. Content Providers

156. Controls:

157. Only grant what is needed

158. K.I.S.S.

159. Common sense usually prevails #6 Client-Side InjectionLots of familiar faces

160. Cross Site Scripting (XSS)

161. Client-side SQL Injection

162. Multiple entry points

163. Browser

164. App-to-app

165. Server-side initiated attacks

166. Controls:

167. Encode data as close to parser boundary as possible

168. Validate input, validate output

169. Database calls should use prepared statements

170. String concatenation = still bad#7 Client-Side DoSScenarios that cause an application to stop working

171. Application crashes

172. Denies system resources to other apps

173. Dialing 911

174. May be triggered

175. Server side

176. Client-side

177. Controls:

178. Handle exceptions gracefully

179. Perform load testing to ensure resources are released as intended#8 Malicious Third-Party CodeLots of free to use code

180. Do your due diligence before using it

181. Trustworthy sources only

182. Perform code review before using third party libraries#9 Client-Side Buffer OverflowOn Android, applies to native apps

183. If your application uses native libraries, this applies

184. If you are using the standard SDK, less to worry about

185. Controls:

186. As insurance, always validate input and output

187. Perform bounds checking on native code you develop#10 Failure To Apply Server-Side ControlsThis should be familiar territory

188. Anything originating from the client = untrusted

189. Parameter manipulation

190. Prices

191. User ID (potential privilege escalation)

192. Injection Attacks

193. SQL Injection (against server)

194. Attacking web services

195. Controls:

196. Many…

197. OWASP Top 10 for web covers these issuesWhere Do We Go From Here?

198. What Happens Next?We haven’t seen ANYTHING yet

199. Ton of education and awareness needed

200. Things will get worse before they get better

201. Technology is outpacing security

202. Can’t fix the hard stuff without fixing easy stuffQuestions?Got them? Ask them

203. I hope this was useful

204. Thank you for attending!

205. Contact Information:

206. [email protected]

207. http://twitter.com/jack_mannino

208. http://www.linkedin.com/pub/jack-mannino/7/2b7/562ResourcesOWASP Mobile Security Project

209. https://www.owasp.org/index.php/OWASP_Mobile_Security_Project

210. Android Developer Resources

211. http://developer.android.com/index.html

212. DroidDream

213. http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/

214. Plankton

215. http://www.csc.ncsu.edu/faculty/jiang/Plankton/

216. OWASP iGoat Project

217. https://www.owasp.org/index.php/OWASP_iGoat_Project

Secure Android Apps- nVisium Security

More Related Content

What's hot (20)

Similar to Secure Android Apps- nVisium Security (20)

Secure Android Apps- nVisium Security