What Healthcare Can Learn From Interesting Directions in IoT Security

Short presentation given at Archimedes Workshop on Medical Device Security 2016

Transcript

1. What Healthcare Can Learn from Interesting Directions in IoT Security ZACH LANIER Director of Research
2. What Healthcare Can Learn from Interesting Directions in IoT Security ZACH LANIER Director of Research (a.k.a IDIoTS)
3. About This Talk
4. Who is this clown? • Zach Lanier • Director of Research, Cylance • Old net, web/app, mobile/ embedded security research/ pen test type • Previously at Accuvant Labs and Duo Security • Co-author, "Android Hacker's Handbook" (Wiley, April 2014)
5. Agenda • Challenges Faced • Some “Lessons” • Field Innovations (?) in IoT Security • Solutions “we” would like to see • Case Studies / Predictions • Q&A
6. About the Internet of Things • “The Internet of Things is the network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment.” (Gartner IT Glossary) • “Machine to machine (M2M) refers to technologies that allow both wireless and wired systems to communicate with other devices of the same type.”
 • IoT Growth Estimates • Gartner: 26 billion units by 2020 • ABI Research: 30 billion units by 2020
7. The Internet of Things “Line of Insanity”TM Sane Reasonable Insane Questionable Egg Tray IP Camera Door Lock Door Bell
8. Challenges
9. Challenges: “Process” • Verification of healthcare professionals' credentials • (i.e. "are you actually a doctor?") • Rights / privileges (technical) should be predicated on these credentials, such as "STOP HEART COMMAND”
10. Challenges: “Technology” • Hardware • Ensuring integrity / trustworthiness of code (limited execution environment / power consumption / clock speed) • Flashing devices • Can be convoluted process • Emergency situations => need immediate access • Backend/software challenges • Security of supporting infrastructure • Web services • Communications channels
11. Challenges: “User Awareness/Behavior” • Users may not know how to update device firmware or apps • If that’s even a capability • Disparity in management: web console v. mobile app v. physical “update” button • Lack of feedback or notification for updates or errors • How does a user know their IoT or medical device was updated or, worse, compromised?
12. Examples / Lessons
13. Example: Basic Hardware Security + = + Least common denominator: Logic analyzer Bus Pirate UART headers Console!
14. Example: Home Automation Gateway Magical cloud service/site M ZigBee ZigBee ZigBee HTTPS HTTPS HTTPS Mobile app Web browser "Gateway" Lights Pool pump Automated cat entertainment toy XSS, CSRF, auth bugs, etc. Key extraction, replay, injection, etc. Unfettered console access, no priv sep for services, same "support" creds on multiple devices
15. Example: Hardcoded Passwords
16. Example: Hardcoded Passwords Don’t.
17. Example: Hardcoded Passwords Don’t. Just…don’t.
18. Example: Hardcoded Passwords Don’t. Just…don’t. Example from an IP camera’s
 mobile app:
19. Example: IP Camera
20. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script on embedded webserver
21. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script on embedded webserver • Pre-auth command injection
22. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script on embedded webserver • Pre-auth command injection • as root
23. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script on embedded webserver • Pre-auth command injection • as root FOO_COMMAND=%2Fsbin%2Fiwpriv+ra0+set+FOO %3DFOOSTART%3B%2Fsbin%2Fiwpriv+ra0+set+FOOTXLEN %3D24%3B%2Fsbin%2Fiwpriv+ra0+set+FOO%3DTXCONT %3B&FOOCHANNEL=&FOOTXLEN=24&FOOTXCNT=&FOOTXM ODE=&FOOTXBW=&FOOTXGI=&FOOTXMCS=&FOOTXANT=&F OORXANT=&FOORXFER=&ResetCounter=&FOOAUTOALC=&FO OIPG=&FOOPAYLOAD=&FOO=TXCONT
24. Example: “Media” Controller IoT/embedded device • Undocumented network diagnostics script on embedded webserver • Pre-auth command injection • as root FOO_COMMAND=%2Fsbin%2Fiwpriv+ra0+set+FOO %3DFOOSTART%3B%2Fsbin%2Fiwpriv+ra0+set+FOOTXLEN %3D24%3B%2Fsbin%2Fiwpriv+ra0+set+FOO%3DTXCONT %3B&FOOCHANNEL=&FOOTXLEN=24&FOOTXCNT=&FOOTXM ODE=&FOOTXBW=&FOOTXGI=&FOOTXMCS=&FOOTXANT=&F OORXANT=&FOORXFER=&ResetCounter=&FOOAUTOALC=&FO OIPG=&FOOPAYLOAD=&FOO=TXCONT
25. Field Innovations (?) in IoT (Security?)
26. Electric Imp • Easy build and deployment environment • Provides cloud service for messaging, fleet management/tracking, etc. • Simple-but-robust libraries • Comms, security, I/O, etc. • Very tight (minimal, no superfluous functionality) firmware and execution environment • Production hardware is near-if-not- completely impossible to instrument/ debug (e.g. JTAG / ICE) • Tied to Imp Cloud for (most) services
27. Particle • Easy build and deployment environment • Provides cloud service for messaging, fleet management/ tracking, etc. • Simple-but-robust libraries • Comms, security, I/O, etc. • Tied to Particle Cloud for deployment and management • Easy hardware debugging • i.e. dump firmware
28. Atmel ATSHA204 • Dedicated crypto and key storage • Low power • Additional physical imposition/ footprint • Increased expense • Additional technical debt • Deprecation • Additional software programming considerations
29. Solutions We Would Like To See
30. Solutions We Would Like To See
31. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites
32. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms
33. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification
34. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity
35. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security
36. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications
37. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services
38. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services • Auditing / Accounting
39. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services • Auditing / Accounting • Access Control / AuthZ / AuthC
40. Solutions We Would Like To See • On-board crypto co-processors w/strong algorithms/ciphersuites • Power consumption characterized for standard algorithms • e.g. 5mA/hr for RSA verification • Innovations in communications to address lack of connectivity • Ready-made frameworks for medical/healthcare security • Communications • Backend services • Auditing / Accounting • Access Control / AuthZ / AuthC • etc.
41. Predictions
42. Predictions
43. Predictions • Malware targeting IoT
44. Predictions • Malware targeting IoT • Ransomware
45. Predictions • Malware targeting IoT • Ransomware • Lock user out of device
46. Predictions • Malware targeting IoT • Ransomware • Lock user out of device • Siphon data
47. Predictions • Malware targeting IoT • Ransomware • Lock user out of device • Siphon data • Physical damage
48. Predictions • Malware targeting IoT • Ransomware • Lock user out of device • Siphon data • Physical damage • e.g. overheat device
49. Predictions • Malware targeting IoT • Ransomware • Lock user out of device • Siphon data • Physical damage • e.g. overheat device • Attacks against IoT as vector into enterprise/org
50. Predictions • Malware targeting IoT • Ransomware • Lock user out of device • Siphon data • Physical damage • e.g. overheat device • Attacks against IoT as vector into enterprise/org • Mobile aside, how many connected/IoT devices are people bringing day-in-day-out?
51. QUESTIONS AND ANSWERS