Your SlideShare is downloading. ×
0
Secure Android ApplicationsThe OWASP WayJack ManninoCEO/Chief “Breaker”ISSA DC- June 21, 2011<br />https://www.nvisiumsecu...
Overview<br /><ul><li>Who I am/ What we do
OWASP Mobile Security Project
Mobile World Meets Security World
Android Crash Course
Threat Modeling Android Apps
Risks and Controls
Where Do We Go From here?
Q&A, Resources</li></li></ul><li>Who I Am/ What We Do/ Where We Are<br /><ul><li>Who I am
Jack Mannino
Company co-founder
Co-leader of the OWASP Mobile Security Project
Has a lot of phones…..
What we do:
Mobile Application Security
Web Application Security
Penetration Testing
Secure Development Training
Where we are:
Northern Virginia</li></li></ul><li>OWASP Mobile Security Project<br />
OWASP Mobile Security Project<br /><ul><li>Began in 2010
Current state of mobile application security: bad
We are aiming to make it: good
How do we plan to achieve this?</li></li></ul><li>OWASP Mobile Security Project<br />
Disclaimer<br /><ul><li>We support OWASP by contributing expertise to the security community
OWASP does not support or endorse our business and services
Why am I mentioning this?
https://www.owasp.org/index.php/OWASP_brand_usage_rules</li></li></ul><li>Mobile World Meets Security World<br />
Mobile World Meets Security World<br /><ul><li>Once upon a time, all phones could do was make phone calls….
And then, the world changed
Today’s mobile devices do things like
Make phone calls
Send SMS messages
Browse the web
VPN into corporate assets
Video conferencing
Track our location
Tap our phones to pay for things (soon)
Is anyone making money?
Do people use these things and their “apps”?</li></li></ul><li>Mobile World Meets Security World- Show Me The Money!!<br /...
Android Crash Course<br />
And Now…Android!<br /><ul><li>Debuted in 2008
Most popular mobile platform around</li></li></ul><li>People Use Android….Now What?<br /><ul><li>Huge market share + attac...
Android Market is OPEN (in a bad way)
Upcoming SlideShare
Loading in...5
×

Secure Android Apps- nVisium Security

4,289

Published on

Presentation I gave at ISSA DC on June 21, 2011. It introduces the OWASP Mobile Security Project, and covers at a high level: Overview of the Android platform, Mobile Top 10 Risks, Threat Modeling for Android.

0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,289
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
376
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

Transcript of "Secure Android Apps- nVisium Security"

  1. 1. Secure Android ApplicationsThe OWASP WayJack ManninoCEO/Chief “Breaker”ISSA DC- June 21, 2011<br />https://www.nvisiumsecurity.com<br />http://twitter.com/jack_mannino<br />http://www.linkedin.com/pub/jack-mannino/7/2b7/562<br />©2011 nVisium Security Inc.<br />
  2. 2. Overview<br /><ul><li>Who I am/ What we do
  3. 3. OWASP Mobile Security Project
  4. 4. Mobile World Meets Security World
  5. 5. Android Crash Course
  6. 6. Threat Modeling Android Apps
  7. 7. Risks and Controls
  8. 8. Where Do We Go From here?
  9. 9. Q&A, Resources</li></li></ul><li>Who I Am/ What We Do/ Where We Are<br /><ul><li>Who I am
  10. 10. Jack Mannino
  11. 11. Company co-founder
  12. 12. Co-leader of the OWASP Mobile Security Project
  13. 13. Has a lot of phones…..
  14. 14. What we do:
  15. 15. Mobile Application Security
  16. 16. Web Application Security
  17. 17. Penetration Testing
  18. 18. Secure Development Training
  19. 19. Where we are:
  20. 20. Northern Virginia</li></li></ul><li>OWASP Mobile Security Project<br />
  21. 21. OWASP Mobile Security Project<br /><ul><li>Began in 2010
  22. 22. Current state of mobile application security: bad
  23. 23. We are aiming to make it: good
  24. 24. How do we plan to achieve this?</li></li></ul><li>OWASP Mobile Security Project<br />
  25. 25. Disclaimer<br /><ul><li>We support OWASP by contributing expertise to the security community
  26. 26. OWASP does not support or endorse our business and services
  27. 27. Why am I mentioning this?
  28. 28. https://www.owasp.org/index.php/OWASP_brand_usage_rules</li></li></ul><li>Mobile World Meets Security World<br />
  29. 29. Mobile World Meets Security World<br /><ul><li>Once upon a time, all phones could do was make phone calls….
  30. 30. And then, the world changed
  31. 31. Today’s mobile devices do things like
  32. 32. Make phone calls
  33. 33. Send SMS messages
  34. 34. Browse the web
  35. 35. VPN into corporate assets
  36. 36. Video conferencing
  37. 37. Track our location
  38. 38. Tap our phones to pay for things (soon)
  39. 39. Is anyone making money?
  40. 40. Do people use these things and their “apps”?</li></li></ul><li>Mobile World Meets Security World- Show Me The Money!!<br />“Gartner Forecasts Mobile App Store Revenues Will Hit $15 Billion in 2011” (http://techcrunch.com/2011/01/26/mobile-app-store-15-billion-2011/)<br />“Industry first: Smartphones pass PCs in sales” (http://tech.fortune.cnn.com/2011/02/07/idc-smartphone-shipment-numbers-passed-pc-in-q4-2010/)<br />
  41. 41. Android Crash Course<br />
  42. 42. And Now…Android!<br /><ul><li>Debuted in 2008
  43. 43. Most popular mobile platform around</li></li></ul><li>People Use Android….Now What?<br /><ul><li>Huge market share + attack monetization = target
  44. 44. Android Market is OPEN (in a bad way)
  45. 45. In the past 2 months, 4 times as much Android malware as all of 2010 (Source: Friend @ Lookout Mobile Security)
  46. 46. GGTracker- Toll fraud
  47. 47. DroidDream- Trojan in over 50 Android apps
  48. 48. Plankton- Steals browsing history, credentials, device logs, and more
  49. 49. 12 apps undetected in the Android Market for over 2 months!
  50. 50. Masqueraded with titles like “Angry Birds Rio Unlock”</li></li></ul><li>It Gets Worse<br /><ul><li>Mobile developers are partying like it’s 1999
  51. 51. Android platform is highly fragmented
  52. 52. Apps are self-signed
  53. 53. Old vulnerabilities are new vulnerabilities
  54. 54. New developers, new companies
  55. 55. Have we learned anything?!</li></li></ul><li>Android Crash Course- Overview<br /><ul><li>Linux-based operating system
  56. 56. Optimized for ARM architecture
  57. 57. Android runtime and libraries run on top of the OS
  58. 58. Applications run within the Dalvik Virtual Machine
  59. 59. Dalvik = optimization, not security
  60. 60. Each application runs in its own process (with exceptions)
  61. 61. Permissions model dictates what apps can/can’t do (sometimes)</li></li></ul><li>Android Crash Course- Architecture<br />
  62. 62. Android Crash Course- Essentials<br /><ul><li>AndroidManifest.xml
  63. 63. Main configuration file
  64. 64. Where most components are declared
  65. 65. Permissions
  66. 66. Activities
  67. 67. Intents
  68. 68. Content Providers</li></li></ul><li>Android Crash Course- Essentials<br /><ul><li>Permissions
  69. 69. Applications are granted permissions for various actions
  70. 70. Declared within AndroidManifest.xml
  71. 71. “All or nothing” basis
  72. 72. ACCESS_FINE_LOCATION
  73. 73. CALL_PHONE
  74. 74. WRITE_SETTINGS
  75. 75. WRITE_SMS
  76. 76. READ_LOGS
  77. 77. And many, many more
  78. 78. Custom permissions too</li></li></ul><li>Android Crash Course- Essentials<br /><ul><li>Permissions
  79. 79. Some developers go overboard
  80. 80. Questionable apps often request ridiculous permissions too
  81. 81. Example: Justin Bieber Wallpaper
  82. 82. android.permission.PROCESS_OUTGOING_CALLS
  83. 83. android.permission.WAKE_LOCK,
  84. 84. android.permission.READ_PHONE_STATE
  85. 85. android.permission.INTERNET
  86. 86. android.permission.RECEIVE_BOOT_COMPLETED
  87. 87. android.permission.ACCESS_NETWORK_STATE
  88. 88. android.permission.ACCESS_COARSE_LOCATION
  89. 89. android.permission.ACCESS_FINE_LOCATION
  90. 90. com.google.android.googleapps.permission.GOOGLE_AUTH
  91. 91. com.google.android.googleapps.permission.GOOGLE_AUTH.OTHER_SERVICES
  92. 92. android.permission.GET_ACCOUNTS</li></li></ul><li>Android Crash Course- Essentials<br /><ul><li>Activity
  93. 93. Single, focused thing a user can do (simple definition)</li></ul>Source: http://developer.android.com/reference/android/app/Activity.html<br />
  94. 94. Android Crash Course- Essentials<br /><ul><li>Intent
  95. 95. Used to launch Activities and communicate with other components
  96. 96. Primary way of passing around data within Android</li></li></ul><li>Android Crash Course- Essentials<br /><ul><li>Content Provider
  97. 97. Used to expose and access data across applications
  98. 98. Permissions are declared by provider attribute in AndroidManifest.xml
  99. 99. Exposes data using a URI format
  100. 100. content://com.somepackage.topsecret/piidata/3</li></ul>Record ID<br />Authority<br />(class name)<br />Prefix<br />Path<br />
  101. 101. Threat Modeling Android Apps<br />
  102. 102. Threat Modeling Android Apps<br /><ul><li>Threat modeling is used to better understand</li></ul> an application’s surface for attack<br /><ul><li>Don’t assume the sky is falling…..
  103. 103. Assume that it already fell
  104. 104. Users:
  105. 105. Root their phones
  106. 106. Lose their phones
  107. 107. Install things they shouldn’t
  108. 108. Use public wifi
  109. 109. Never listen to security people (ever)…
  110. 110. Now we can see the bigger picture</li></li></ul><li>Threat Modeling Android Apps<br />
  111. 111. Threat Modeling Android Apps- Loss Or Theft<br />
  112. 112. Threat Modeling Android Apps- Remote Market Attack<br />
  113. 113. Threat Modeling Android Apps- Legacy Architectures<br />
  114. 114. Risks And Controls<br />
  115. 115. OWASP Mobile Top 10 Risks and Controls<br /><ul><li>Top 10 Risks</li></ul>Insecure or unnecessary client-side data storage<br />Lack of data protection in transit<br />Personal data leakage<br />Failure to protect resources with strong authentication<br />Failure to implement least privilege authorization policy<br />Client-side injection<br />Client-side Denial Of Service (DoS)<br />Malicious third-party code<br />Client-side buffer overflow<br />Failure to apply server-side controls<br />
  116. 116. #1 Insecure or Unecessary Client-Side Data Storage<br /><ul><li>Do I really have to store it?</li></li></ul><li>#2 Lack of Data Protection in Transit<br /><ul><li>No SSL/TLS
  117. 117. Broken SSL/TLS
  118. 118. Ignoring certificate errors to “make apps work”
  119. 119. Facilitates Man In The Middle (MITM) attacks
  120. 120. Near Field Communications (NFC) leaves transport encryption up to the developers to implement correctly
  121. 121. Controls:
  122. 122. Use strong transport encryption when transmitting sensitive information
  123. 123. Even over 3G/4G…assume the carrier is compromised too
  124. 124. Detect errors and properly handle them
  125. 125. Unrecognized CA
  126. 126. Certificate name mismatches</li></li></ul><li>#3 Personal Data Leakage<br /><ul><li>Logging sensitive information
  127. 127. Caching sensitive information
  128. 128. Browser
  129. 129. Search history
  130. 130. Location information
  131. 131. Controls:
  132. 132. Use only protected storage areas
  133. 133. Never external media!
  134. 134. Don’t use the global log file
  135. 135. Understand the implications of what you are storing and caching
  136. 136. Do you really need 3 years of GPS info on the device?</li></li></ul><li>#4 Failure To Protect Resources With Strong Authentication<br /><ul><li>This risk presents itself in multiple ways:
  137. 137. App-to-app
  138. 138. Single Sign On (Google Auth, Facebook)
  139. 139. Exposing Content Providers, Broadcasts
  140. 140. Client/Server
  141. 141. Has overlap with #10- Failure To Apply Server Side Controls
  142. 142. Controls:
  143. 143. Keep small session timeout windows when possible
  144. 144. Require re-authentication for sensitive actions
  145. 145. Never authenticate based on:
  146. 146. Device ID
  147. 147. Location</li></li></ul><li>#5 Failure To Implement Least Privilege Authorization Policy<br /><ul><li>Overly permissive permissions granted to apps
  148. 148. Does an application really need to modify system settings?
  149. 149. Does the permission even get used?
  150. 150. File access
  151. 151. MODE_WORLD_READABLE, MODE_WORLD_WRITEABLE
  152. 152. Overexposing Android components
  153. 153. Activities
  154. 154. Intents
  155. 155. Content Providers
  156. 156. Controls:
  157. 157. Only grant what is needed
  158. 158. K.I.S.S.
  159. 159. Common sense usually prevails </li></li></ul><li>#6 Client-Side Injection<br /><ul><li>Lots of familiar faces
  160. 160. Cross Site Scripting (XSS)
  161. 161. Client-side SQL Injection
  162. 162. Multiple entry points
  163. 163. Browser
  164. 164. App-to-app
  165. 165. Server-side initiated attacks
  166. 166. Controls:
  167. 167. Encode data as close to parser boundary as possible
  168. 168. Validate input, validate output
  169. 169. Database calls should use prepared statements
  170. 170. String concatenation = still bad</li></li></ul><li>#7 Client-Side DoS<br /><ul><li>Scenarios that cause an application to stop working
  171. 171. Application crashes
  172. 172. Denies system resources to other apps
  173. 173. Dialing 911
  174. 174. May be triggered
  175. 175. Server side
  176. 176. Client-side
  177. 177. Controls:
  178. 178. Handle exceptions gracefully
  179. 179. Perform load testing to ensure resources are released as intended</li></li></ul><li>#8 Malicious Third-Party Code<br /><ul><li>Lots of free to use code
  180. 180. Do your due diligence before using it
  181. 181. Trustworthy sources only
  182. 182. Perform code review before using third party libraries</li></li></ul><li>#9 Client-Side Buffer Overflow<br /><ul><li>On Android, applies to native apps
  183. 183. If your application uses native libraries, this applies
  184. 184. If you are using the standard SDK, less to worry about
  185. 185. Controls:
  186. 186. As insurance, always validate input and output
  187. 187. Perform bounds checking on native code you develop</li></li></ul><li>#10 Failure To Apply Server-Side Controls<br /><ul><li>This should be familiar territory
  188. 188. Anything originating from the client = untrusted
  189. 189. Parameter manipulation
  190. 190. Prices
  191. 191. User ID (potential privilege escalation)
  192. 192. Injection Attacks
  193. 193. SQL Injection (against server)
  194. 194. Attacking web services
  195. 195. Controls:
  196. 196. Many…
  197. 197. OWASP Top 10 for web covers these issues</li></li></ul><li>Where Do We Go From Here?<br />
  198. 198. What Happens Next?<br /><ul><li>We haven’t seen ANYTHING yet
  199. 199. Ton of education and awareness needed
  200. 200. Things will get worse before they get better
  201. 201. Technology is outpacing security
  202. 202. Can’t fix the hard stuff without fixing easy stuff</li></li></ul><li>Questions?<br /><ul><li>Got them? Ask them
  203. 203. I hope this was useful
  204. 204. Thank you for attending!
  205. 205. Contact Information:
  206. 206. Jack@nvisiumsecurity.com
  207. 207. http://twitter.com/jack_mannino
  208. 208. http://www.linkedin.com/pub/jack-mannino/7/2b7/562</li></li></ul><li>Resources<br /><ul><li>OWASP Mobile Security Project
  209. 209. https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
  210. 210. Android Developer Resources
  211. 211. http://developer.android.com/index.html
  212. 212. DroidDream
  213. 213. http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/
  214. 214. Plankton
  215. 215. http://www.csc.ncsu.edu/faculty/jiang/Plankton/
  216. 216. OWASP iGoat Project
  217. 217. https://www.owasp.org/index.php/OWASP_iGoat_Project</li>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×