Android in the healthcare workplace

1,039 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,039
On SlideShare
0
From Embeds
0
Number of Embeds
126
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Android in the healthcare workplace

  1. 1. Android in the Healthcare Workplace: A Case Study Thomas Richards g13net@gmail.comOWASP04/05/12 Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation http://www.owasp.org
  2. 2. About meMy name is TomTwitter: @g13netWebsite: www.g13net.comIndependent Vulnerability Researcher(at night!) 13 Published vulnerabilities with 5 CVE-IDs assignedIT Support Analyst (by day) OWASP 2
  3. 3. Why this talk?With the growth of mobile devices, companies are looking to capitalize on this for business purposesVery rapidly writing applications for these mobile platformsSecurity is a concern OWASP 3
  4. 4. What this talk isThis talk is about a security assessment performed on a product my company usesThis is not about the Android platform itself, or security issues with it OWASP 4
  5. 5. BackgroundHome Health Company (visiting nurses)Transitioned from Laptop with thick client software to Mobile platform Flexibility and Mobility are huge for a 75% mobile workforceNew product, rewritten for Android from Windows Mobile OWASP 5
  6. 6. HIPAA ConcernsHIPAA is the word in HealthcareNeed to Protect PHIEncryption! At Rest In Transit OWASP 6
  7. 7. Deploying DevicesDeployed 250 Android Tablets Running Froyo (2.2)MDM SolutionsNo Imaging OWASP 7
  8. 8. About the softwareRuns on Android Not available in the marketClinicians sync to get data Patient data(records) are kept on the deviceVendor stated data on the device was encrypted as well as data in transit OWASP 8
  9. 9. How did I perform this assessment?Android Emulator! Able to observe traffic in real timeUsed OWASP Mobile Top 10 and Web Top 10 as guidelines OWASP 9
  10. 10. Authentication and AuthorizationOnly two pieces of information were needed to configure a device: Server name and Agent IDAgent IDs are sequentialNo way to validate an approved device is being configuredFinding Server name and Agent ID would lead to complete compromise OWASP 10
  11. 11. Setup Screen OWASP 11
  12. 12. PasswordUser’s password was configured and stored locallyNo complexity requirements OWASP 12
  13. 13. Data at restI was able to determine that the data in the local database was encrypted (yay!)It was protected by the user’s password and using built in SQLite APIs for encrypting a database OWASP 13
  14. 14. Data in TransitNo SSL!Using HTTP, they used POST methods to retrieve data from the serverNow treat this as a web app also OWASP 14
  15. 15. Traffic capture screenshot OWASP 15
  16. 16. POST Request Screenshot OWASP 16
  17. 17. Interesting Side NoteGoing to sync1.vendor.com/falcon showed form based login prompt.Also not in HTTPs, tried to connect to it viaGoing to: sync1.vend.com/falcon/mobiledevicehandler.fal Displayed custom encoding OWASP 17
  18. 18. Session HandlingNo Cookies present.The server would not know if the request was proper which could lead to Replay attacks. OWASP 18
  19. 19. Insufficient Transport Layer ProtectionObvious IssuesCustom “encoding” After some RE, not encryption! (no key present) Some Plaintext available I was able to analyze their protocol. OWASP 19
  20. 20. Server name IdentificationPlaintext! OWASP 20
  21. 21. Agent ID IdentificationAfter observing traffic with different Agent IDs, I was able to determine where in the string it lived OWASP 21
  22. 22. Agent ID Identification Cont.Raw Hex: aa10ffffffff00010102633a1020000000000081 aa10ffffffff0001010264ee1020000000000081Converting the hex “633a” and “64ee” to decimal revealed the Agent IDs.This coupled with Server Name in plaintext could lead to complete compromise of data OWASP 22
  23. 23. Server IdentificationNo attempts were made to disguise the identity of web server and technology used OWASP 23
  24. 24. Notifying the VendorBrought this to the attention of my boss who asked me to write it upSubmitted write-up to the vendorCTO Came and stated they were aware of these issues (they lied to us in the beginning) OWASP 24
  25. 25. Vendor’s PlanSetup Codes Unique 8 character string generated on server end before setting up a deviceSSL (eventually) As of current version, still no SSL present. They stated it would have been in Dec 2011 release OWASP 25
  26. 26. Protecting OurselvesAsk vendor if the app has been independently assessed for security issues (companies specialize in this!)Assess the software yourself. OWASP 26
  27. 27. Thank you! OWASP 27

×