This presentation will dive into research, outcomes, and recommendations regarding information security for the "Internet of Things". Mark and Zach will discuss IoT security failures both from their own research as well as the work of people they admire. Attendees are invited to laugh/cringe at concerning examples of improper access control, a complete lack of transport security, hardcoded-everything, and ways to bypass paying for stuff. Mark and Zach will also discuss the progress that their initiative, BuildItSecure.ly, has made since it was announced this past February at B-Sides San Francisco. Based on their own struggles with approaching smaller technology vendors with bugs and trying to handle coordinated disclosure, Mark and Zach decided to change the process and dialog that was occurring into one that is inclusive, friendly, researcher-centric. They will provide results and key learnings about the establishment of this loose organization of security-minded vendors, partners, and researchers who have decided to focus on improving information security for bootstrapped/crowd-funded IoT products and platforms. If you're a researcher who wants to know more about attacking this space, an IoT vendor trying to refine your security processes, or just a consumer who cares about their own safety and privacy, this talk will provide some great insights to all of those ends. MARK STANISLAV DUO SECURITY Mark Stanislav is the Security Evangelist for Duo Security. With a career spanning over a decade, Mark has worked within small business, academia, startup and corporate environments, primarily focused on Linux architecture, information security, and web application development. He has presented at over 70 events internationally including RSA, ShmooCon, SOURCE Boston, and THOTCON. His security research has been featured on web sites including CSO Online, Security Ledger, and Slashdot. Mark holds a B.S. in Networking & IT Administration and an M.S. in Information Assurance, both from Eastern Michigan University. Mark is currently writing a book titled, "Two-Factor Authentication" (published by IT Governance). ZACH LANIER DUO SECURITY Zach Lanier is a Security Researcher with Duo Security, specializing in various bits of network, mobile, and application security. Prior to joining Duo, Zach most recently served as a Senior Research Scientist with Accuvant LABS. He has spoken at a variety of security conferences, such as Black Hat, CanSecWest, INFILTRATE, ShmooCon, and SecTor, and is a co-author of the recently published "Android Hackers' Handbook."

1. The Internet of Fails
Where IoT Has Gone Wrong and How We're Making It Right
Mark Stanislav Zach Lanier
<mstanislav@duosecurity.com> <zach@duosecurity.com>

2. The Internet of Things

3. 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 Glossary1
“Machine to machine (M2M) refers to technologies that allow
both wireless and wired systems to communicate with other
devices of the same type.”, Wikipedia2
IoT Growth Estimates
•Gartner: 26 billion units by 20203
•ABI Research: 30 billion units by 20204
4. https://www.abiresearch.com/press/more-than-30-billion-devices-will-wirelessly-conne
3. http://www.gartner.com/newsroom/id/26360731. http://www.gartner.com/it-glossary/internet-of-things/
2. http://en.wikipedia.org/wiki/Internet_of_Things

4. Cool! So What’s Wrong?
•Pervasiveness: You won’t have one IoT device, you’ll have ten.
•That’s a lot of new attack surface to your life and/or business
•Uniqueness: IoT devices are a wild-west of mixed technologies.
•How do I patch firmware on these dozen devices?
•Which random vendor made the hardware inside this device?
•Ecosystem: Your vendor may be leveraging six other vendors.
•Where’s your data going once it enters that IoT device?
•Who has access to your network via proxy connections?

5. The Internet of Things “Line of Insanity”TM
Sane Reasonable InsaneQuestionable
Egg TrayIP Camera Door LockDoor Bell

6. Cheap Hardware, Unlimited Possibilities
Electric Imp ($25) Gumstix ($169) Arduino ($75)
Raspberry Pi ($35)Pinoccio ($59)

7. Plenty Of Choices, How Do You Determine Security?
Philips ($60) LimitlessLED ($23)INSTEON ($30)
Vendors could each use different hardware, software,
APIs, third-party service providers, and patching
mechanisms

8. IoT Ecosystem

9. What’s Better Than One Vulnerable Device?
Interconnected Vulnerable Devices!
•If-This-Then-That (IFTTT)
supports over 110 platforms,
services, and devices
•Allows for event-based actions
across disparate technologies
•If the CO2
in this room is
unsafe, change my lightbulb
to be red to warn me
•This behavior will become a
consumer expectation rather
than merely a “nice to have”

10. The Government Is Watching — And That’s Good!
January 8th, 2014
FTC Commissioner Maureen Ohlhausen sits on panel at CES about IoT3
November 21st, 2013
Internet of Things - Privacy and Security in a Connected World Workshop2
February 7th, 2014
FTC approves final order settling charges against TRENDnet, Inc.4
June 3rd, 2013
Software & Information Industry Association asks FTC to be careful with IoT1
1. https://www.siia.net/blog/index.php/2013/06/siia-to-ftc-internet-of-things-requires-technology-neutral-policies-and-flexible-privacy-framework/
3. http://www.adweek.com/news/technology/will-washington-move-quickly-regulate-internet-things-154863
2. http://www.ftc.gov/news-events/events-calendar/2013/11/internet-things-privacy-and-security-connected-world
4. http://www.ftc.gov/news-events/press-releases/2014/02/ftc-approves-final-order-settling-charges-against-trendnet-inc
February 18th, 2014
US CERT works with IOActive to resolve Belkin WeMo vulnerabilities5
5. http://www.kb.cert.org/vuls/id/656302

11. Challenges Faced

12. Hardware Security
•Many devices use generic SoCs/boards
•Quick development, few security features (“HW hacking made easy”)
•Prevalence of same components, firmware, etc. means one bug affects
many products
•Little expertise required to design, build, and ship an “IoT Product”
+ =+
Least common denominator:
Logic analyzer Bus Pirate UART headers
Console!

13. Software Security
•Development environments don’t
necessarily make security
controls/options “clear”
•Selected platform may drive/
restrict language choices
% grep -Er "s(mem|str)cpy(" .
…
./apps/http-post-auth/http-post-auth.c: strcpy(s->message, "status=");
./apps/http-post-auth/http-post-auth.c: strcpy(&s->message[7], msg);
./apps/irc/irc.c: memcpy(log, &log[LOG_WIDTH], LOG_WIDTH * (LOG_HEIGHT - 1));
./apps/irc/irc.c: memcpy(log, &log[LOG_WIDTH], LOG_WIDTH * (LOG_HEIGHT - 1));
./apps/ping6/ping6.c: memcpy(command, (void *)"ping6", 5);
./apps/rest-coap/coap-common.c: memcpy(
./apps/rest-coap/coap-common.c: memcpy((char*)&buffer[index], option->value, option->len);
./apps/rest-coap/coap-common.c: memcpy(&buffer[index], packet->payload, packet->payload_len);
./apps/rest-coap/coap-server.c: memcpy(option->value, value, len);
./apps/rest-common/buffer.c: memcpy(buffer, data, len);
./apps/rest-common/buffer.c: strcpy(buffer, text);
./apps/rest-common/rest-util.c: memcpy(p + 4 - size, buf, size);
./apps/rest-common/rest-util.c: memcpy(buf, ((char*)(&data)) + 4 - size, size);
./apps/rest-common/rest.c: memcpy(temp_etag, etag, size);
./apps/rest-http/http-server.c: strcpy(current_header->value, value);
./apps/rest-http/http-server.c: strcpy(current_header->value, buffer);
./apps/rest-http/http-server.c: memcpy(buffer + index, response->payload, response->payload_len);
•“Me write Python/Ruby/
Node/… pretty one
day” (or worse, C)
•History repeating…?
Quick grep for potentially dangerous behavior in someone’s Contiki project

14. Challenges: Software Security (Cont’d…)
•Selected platform often locks dev/
vendor into given OS choice
•Proprietary OSes (such as
ElectricImp) - don’t peek inside
the black box!
•Linux, Contiki, QNX, et. al (all with
their own issues)
•Little consideration given to least-
priv, mitigations, hardening, etc.
•Third-party dependencies
•Inherited bugs/attack surface
•Also applies to mobile
Proprietary and Confidential. Do Not Distribute. © 2013 Accuvant, Inc. All Rights Reserved.
Bro, do you even PIE?
Proprietary and Confidential. Do Not Distribute. © 2013 Accuvant, Inc. All Rights Reserved.
Bro, do you even PIE?
Bro, do you even randomize?

15. Comms/Network Security
•WiFi goofiness (“device as AP”, no WPA, exploitable
behavior, etc.)
•Plaintext protocols or poor crypto at transport layer
•…or lack of cert pinning where SSL/TLS actually used
•Unprotected FW updates/downloads
•Otherwise seemingly unnecessary services listening
•Telnet, SSH, FTP, you name it…
•Shared accounts/auth material for “support” or
updates
•Use of technologies such as ZigBee and cellular
introduce additional security considerations
"Cellular made easy"

16. Platform* Security
•Everything that uses an HTTP GET/POST has
become an “API” to the average developer
•Authentication? Signed requests? Unlikely.
•Input manipulation is a less obvious concern
when developers do mobile and embedded
•Yup… OWASP {Mobile,Web} Top 10
•Leveraging third-party service providers
introduce exponential complexities and further
increases potential attack surface
•Quick & Dirty cloud infrastructure yields poor
accessibility and potentially confidentiality
* for our purposes “Platform” also includes supporting infrastructure, services, frameworks,

17. User Awareness & Behavior
•Users may not know (let alone care)
how to update device firmware or
apps
•Disparity in management: web
console v. mobile app v. physical
“update” button
•Also they just want to use the !@#
$ thing now!
•Lack of feedback or notification for
updates or errors
•How does a user know their IoT
device was updated or, worse,
compromised?

18. [Failures]

19. Oh, You Wanted Authentication on Your Camera?
•Issue: Some TRENDnet IP camera models
didn’t authenticate users connecting to
http://camera-ip/anony/mjpg.cgi which
exposed actual video feeds of people’s
cameras.
•Hypothetical Exploit:
•Google for “inurl:/anony/mjpg.cgi”
•Be a big creep that nobody likes
•Fix: Always verify all expected “private”
URLs actually require authentication. This is
easily accomplished with a curl script or
Selenium.
http://console-cowboys.blogspot.com/2012/01/trendnet-cameras-i-always-feel-like.html

20. You Get Keys, and You Get Keys… EVERYBODY GETS KEYS!
•Issue: IOActive determined that Belkin’s WeMo
devices were including their GPG signing key
and password inside of the firmware its self.
•Hypothetical Exploit:
•Retrieve firmware signing key + password
•MITM firmware feed announcing updates
•Own WeMo devices
•Flip lights and stuff
•Fix: Don’t try to “hide” secret data in firmware,
a lot of people are looking there. Signing
firmware is great… just don’t let attackers sign
it, too :)http://www.ioactive.com/news-events/

21. LIFX
•Issue: Context found that LIFX utilized a
hardcoded symmetric key for encrypting data
across 6LoWPAN, including WiFi credentials
•Hypothetical Exploit:
•Give a LIFX user a new bulb as a “gift”
•Get creepily close to their house
•Wait for them to add the new bulb, sniff traffic
•Decrypt packet capture with symmetric key
•Jump on their WiFi network and do bad things
•Fix: No, seriously, for the last time, don’t
hardcode passwords/keys/etc. in your firmware.
http://contextis.co.uk/blog/hacking-internet-connected-light-bulbs/

22. “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
toyXSS, CSRF,
auth bugs, etc.
Key extraction, replay,
injection, etc.
Unfettered console access,
no priv sep for services,
same "support" creds on
multiple devices
Linux-based gateway talks RESTful HTTP to “cloud”-based service, receives commands
(schedules, metering data, etc.), relays commands to smart plugs/meters via ZigBee

23. IZON IP Camera

24. Telnet And A Hardcoded Root Password? Let’s Do This!
•Issue: The camera’s mobile app contained hardcoded root
credentials so that it could initiate firmware upgrades by
connecting over Telnet and echoing out a shell script to start the
process.
•Hypothetical Exploit:
•Run strings on the decrypted mobile application
•Connect to any camera you can reach via Telnet as root
•View the admin password for the camera’s web interface and login
•Fix: Don’t use Telnet for anything… ever. Don’t hardcode

25. If You Want To Protect Data… Protect It.
•Issue: Unencrypted camera “alert” video clips
were uploaded to Amazon S3 into one bucket
and protected only by an MD5-string filename.
Oh, and no SSL.
•Hypothetical Exploit:
•Generate MD5 strings with the filename
format
•Be really, really, really patient
•View random videos of cats knocking stuff
over
•Fix: Leverage the AWS Identity and Access
Management (IAM) functionality to provide

26. API = Always Poorly Implemented
•Issue: API calls for third-party services were
done without SSL and used an MD5-sum of the
user’s password as a secret.
•Hypothetical Exploit:
•Go to Starbucks and hopefully get a PSL
•MITM network traffic
•Wait for someone to check their video camera
•Retrieve their MD5’ed password, crack, repeat
•Fix: If you setup third-party credentials for your
customers, do NOT transmit their real account
password. Also, make sure your vendors
understand the basics of API security.

27. The Bigger Picture of This Research, FWIW…

28. [Redacted]*
*The issues presented shown are real but the context has been
changed
Coordinated disclosure is rarely perfect :)

29. Session Handling: Time is Not On Your Side
•Issue: Session IDs are “generated” by using
only the exact UNIX epoch timestamp of when
you logged into the service for this IoT device.
•Hypothetical Exploit:
•Enumerate 172,800 recent epoch
timestamps
•Set your session ID to each timestamp
•Send a GET request to determine validity
•“Become” a user with a browser header
•Fix: Use your web framework’s default session
handler that hopefully isn’t non-random.

30. Don’t Trust What You Haven’t Verified
•Issue: Purchasing in-app credits for use with
the device via the app store lets the mobile
application dictate that a purchase occurred.
•Hypothetical Exploit:
•Pick a number… any number
•Make an API call with that number
•Gain that many “things” for your account
•Fix: Don’t let a mobile app be the authority on
any account balances. Always use a transaction
log on the backend to reconcile what purchases
have occurred and what balances should be.

31. Hiding in Plain(text) Sight
•Issue: A chicken-and-egg problem existed
where sensitive details about a user were
provided prior to authorization from said user.
•Hypothetical Exploit:
•Ask a user to be your friend
•Data is transmitted over the wire about that
user
•User gets to decide if they want to share data
•…wait a second…
•Fix: Don’t transmit data ahead of authorization,
even if the user interface won’t expose it. If it

32. Heart Bleed And The Internet Of Things
•PKI is (sadly?) a critical component of IoT security
•Mobile apps speaking to embedded devices
•Embedded devices speaking to services
•Services speaking to other services
•Developers leveraging service APIs
•How many IoT vendors are concerning themselves
over Heart Bleed implications?
•Do you think most random Chinese ODMs are going
to rush to get your devices patched and re-keyed? Or
even release a notice?

33. Vendors You’ve Never Heard Of

34. There’s A Shift Underway You Should Know About
•The IoT growth that we’re all expecting won’t just
be from large vendors like Belkin, TRENDnet,
Cisco, and Ericsson
•Postscapes1 and Wolfram Alpha2 list a few
hundred IoT-related companies, most of which
you’ve likely never heard of
•Crowd-funding web sites are going to produce
many of the newest IoT devices we all want to use
•Entrepreneurs likely have no experience with
information security, nor the budget to afford
help
•They also won’t know what a “security
1. http://postscapes.com/companies/ 2. http://devices.wolfram.com

35. CrowdFunding & IoT
Pinoccio
Wunderbar
KoolThings
Twine
Knut
Tessel
Canary
Piper

36. Vulnerability Handling & Disclosure Awareness
•Small vendors (and some big ones) fail to
get it, or just simply don’t know
•“But, why would anyone want to hack
this device? And why would they want
to tell us or talk about it publicly?”
•Few-to-no resources for small vendors to
handle this
•Nascency of “IoT” means some
researchers may not know either
•And we’d like for them to stay out of jail

37. A New Initiative

38. A New Initiative — BuildItSecure.ly

39. Our Current Partners, Vendors, and Researchers!

40. Our Timeline
February, 2014:
+ Initial announcement of this initiative at BSides San Francisco
March - April, 2014:
+ Established relationships with an initial set of partners/researchers
+ Link curation for presentations, papers, standards related to IoT
security
April, 2014:
+ Provide an update on progress and initial partners at SOURCE Boston
June, 2014:
+ Spun-up Bugcrowd for our launch vendors to leverage for bug triage
July, 2014:
+ Added additional IoT vendors to provide a better research pipeline
+ Pinoccio ships researchers their first hardware for testing!

41. What’s Next?
•Complete our first round of vendor hardware testing
•Pinoccio has provided hardware for two researchers to test
•Bugcrowd has been setup for our vendors + researchers to utilize
•We need to figure out testing/reporting/triage/fix timelines still
•Get some bugs reported, get them fixed, reward researchers(?)
•Figure out what works, what doesn’t — and then expand!
•We want to better understand our processes before growing
•As we add vendors to test for, we’ll add more researchers
•We’re a big fan of results and not just pretending help people ;)
•We’re growing slowly, on purpose, and happy about it

42. Conclusion

43. Lessons Learned
•People are way less cynical in information security than you may
think — don’t be afraid to ask people for their input and help.
!
•Take your timeline and double it. The same people who are
going to provide the best help/effort are already pretty damn
busy.
!
•Focus on quality, not quantity when it comes to people/
partners.

44. Conclusion
•IoT is still malleable enough to help make a positive impact
•BuildItSecure.ly could help consumers make better decisions
•Plenty of vendors — let’s find a few that care about security
•Worst case? We do some research and help a few companies!

45. Thanks! Questions?
Mark Stanislav
mstanislav@duosecurity.com
@markstanislav
Zach Lanier
zach@duosecurity.com
@quine
http://BuildItSecure.ly/
builditsecurely@duosecurity.com
@BuildItSecurely