Secure Android Apps- nVisium Security
•Download as PPTX, PDF•
12 likes•3,014 views
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.
Report
Share
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
- 6. Threat Modeling Android Apps
- 8. Where Do We Go From here?
- 9. Q&A, ResourcesWho I Am/ What We Do/ Where We AreWho I am
- 10. Jack Mannino
- 12. Co-leader of the OWASP Mobile Security Project
- 13. Has a lot of phones…..
- 14. What we do:
- 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
- 34. Browse the web
- 35. VPN into corporate assets
- 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/)
- 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)
- 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
- 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
- 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
- 71. “All or nothing” basis
- 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
- 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
- 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
- 128. Browser
- 129. Search history
- 130. Location information
- 131. Controls:
- 132. Use only protected storage areas
- 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
- 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)
- 163. Browser
- 164. App-to-app
- 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:
- 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
- 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
- 190. Prices
- 191. User ID (potential privilege escalation)
- 192. Injection Attacks
- 193. SQL Injection (against server)
- 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:
- 212. DroidDream
- 214. Plankton
- 216. OWASP iGoat Project