The document provides an overview of securing Android applications according to the OWASP (Open Web Application Security Project) approach. It discusses the OWASP Mobile Security Project, performs a crash course on Android architecture and essentials, demonstrates threat modeling for Android apps, reviews the top 10 mobile risks and associated controls from OWASP, and provides resources for further information.

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

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?

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:

22. Current state of mobile application security: bad

23. We are aiming to make it: good

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

27. Why am I mentioning this?

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?

41. Android Crash Course

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!

51. Android platform is highly fragmented

52. Apps are self-signed

53. Old vulnerabilities are new vulnerabilities

54. New developers, new companies

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)

63. Main configuration file

64. Where most components are declared

65. Permissions

66. Activities

67. Intents

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

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

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

95. Used to launch Activities and communicate with other components

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 ID Authority (class name) Prefix Path

101. Threat Modeling Android Apps

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)…

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

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

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

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

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.

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

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

180. Do your due diligence before using it

181. Trustworthy sources only

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

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…

199. Ton of education and awareness needed

200. Things will get worse before they get better

201. Technology is outpacing security

203. I hope this was useful

204. Thank you for attending!

205. Contact Information:

206. Jack@nvisiumsecurity.com

207. http://twitter.com/jack_mannino

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