Secure Android Apps- nVisium Security

  • 4,074 views
Uploaded 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 …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,074
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
368
Comments
0
Likes
10

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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.
  • 2. Overview
    • Who 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, Resources
  • Who I Am/ What We Do/ Where We Are
    • Who 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 Virginia
  • OWASP Mobile Security Project
  • 21. OWASP Mobile Security Project
    • Began 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. Disclaimer
    • We 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_rules
  • Mobile World Meets Security World
  • 29. Mobile World Meets Security World
    • Once 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 around
  • People 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 Worse
    • Mobile 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- Overview
    • Linux-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- Essentials
    • AndroidManifest.xml
    • 63. Main configuration file
    • 64. Where most components are declared
    • 65. Permissions
    • 66. Activities
    • 67. Intents
    • 68. Content Providers
  • Android Crash Course- Essentials
    • Permissions
    • 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 too
  • Android Crash Course- Essentials
    • Permissions
    • 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_ACCOUNTS
  • Android Crash Course- Essentials
    • Activity
    • 93. Single, focused thing a user can do (simple definition)
    Source: http://developer.android.com/reference/android/app/Activity.html
  • 94. Android Crash Course- Essentials
    • Intent
    • 95. Used to launch Activities and communicate with other components
    • 96. Primary way of passing around data within Android
  • Android Crash Course- Essentials
    • Content 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/3
    Record ID
    Authority
    (class name)
    Prefix
    Path
  • 101. Threat Modeling Android Apps
  • 102. Threat Modeling Android Apps
    • Threat modeling is used to better understand
    an application’s surface for attack
    • Don’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 picture
  • Threat 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 Controls
    • Top 10 Risks
    Insecure or unnecessary client-side data storage
    Lack of data protection in transit
    Personal data leakage
    Failure to protect resources with strong authentication
    Failure to implement least privilege authorization policy
    Client-side injection
    Client-side Denial Of Service (DoS)
    Malicious third-party code
    Client-side buffer overflow
    Failure to apply server-side controls
  • 116. #1 Insecure or Unecessary Client-Side Data Storage
    • Do I really have to store it?
  • #2 Lack of Data Protection in Transit
    • No 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 Leakage
    • Logging 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 Authentication
    • This 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 Policy
    • Overly 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 Injection
    • Lots 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 DoS
    • Scenarios 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 Code
    • Lots 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 Overflow
    • On 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 Controls
    • This 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 issues
  • Where 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 stuff
  • Questions?
    • Got them? Ask them
    • 203. I hope this was useful
    • 204. Thank you for attending!
    • 205. Contact Information:
    • 206. Jack@nvisiumsecurity.com
    • 207. http://twitter.com/jack_mannino
    • 208. http://www.linkedin.com/pub/jack-mannino/7/2b7/562
  • Resources
    • OWASP 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