>> It's time for our next talk, and it sure looks like we are picking on every little thing
that you can buy at Best Buy and plug into your network today, and that's awesome, that's
awesome. So we're going to hear from the guys from Duo right now. We've got Mark and Zach,
and let's give them a big party track welcome. In fact, one of these guys is a new speaker. So
that will be fun. [Applause] >> I think he was expecting his shot. Anyway, so welcome to the
Internet of fails. Where IoT has gone wrong and how we're making it right. I'm Zach Lanier,
Senior Security Researcher with Duo Security. >> And I'm Mark Stanislav with Duo Security as
well. >> Thank you. Thank you. So IoT, you know, if you have been in the space for a while,
you probably know similar things as M2M, so machine-to-machine. If you've been doing embedded
security research, you're probably much more friendly with that term. I think cloud
computing is a good example of how we all bitched about semantics for the first five
years, and now everyone is just, like, yeah, cloud computing, cool. But everyone was, like,
oh, that is not a thing, this is bullshit no one will do this. So I think IoT is the same way, you
know, probably get passed the definitions and the semantics of a lot of this stuff, and kind of
look at it for what it is, which is a huge sector for research. A lot of the talks I think will be
seen at DEF CON for many years to come we'll be around these kinds of devices. There is a lot
to talk about today. So let's get onto it. In terms of what we have going, you know,
pervasiveness really is kind of where it comes down to. You think about like home router,
right? You have the home router hacking lab, all that going on. The number of devices that we
have in IoT where you have firmware going, right? We can barely update one router. What
makes us think we're going to update like hundreds of devices in our households in five years?
There is a lot going on there, the service, whether it is a business or whether it's your
personal life, right? You're going to bring the stuff in IoT into your offices and if you do
penetration testing, I'm guessing you're hoping people are going to bring these random
things off the shelf of Best Buy that reverse proxy out into the office. In terms of the overall
environment, there is a lot going on in terms of how diverse the technologies are. So the
ecosystem are really messed up right now. You see companies big and small trying to standardize
and make sense of it all, but really we don't see that quite yet and I don't think we will
for a while. Part of the cool thing about IoT right now and where we're at with a lot of
technologies we'll talk about today is you can innovate really easily. You have a lot of
agility and IoT is really taking advantage of that right now. So how do you patch a bunch of
firmware on the devices? Do you auto update? Do you have people manually do it? What's that
going to look like, again, when you're on that scale? And the problem we've always had with
embedded hardware is you get random, you know, ODMs. You have firmware that no one has
actually done. Security audits of kernels that are like 15 years old. And, you know, this
is the kind of stuff that we're putting in our networks right now. So even though the device
is new, the actual technology underlined is probably not. Ecosystem overall, if you buy an
IoT device, guess what? That IoT device probably has like three or four services behind it from
three or four other vendors. So you're not just buying a piece of hardware and on you're
putting it on your network. You're buying a piece of hardware, putting it on your
network, and then it's calling out to three other services that then have data that you have for
your device to function or service accounts to make it tie into something else you're
doing. So where does your data go when it goes to the IoT? It's the same problem as CloudRight.
Where is my data at? Um, with IoT you definitely don't know where it's going. At least with
Cloud Services you at least know who, like, what provider might have it. With IoT you're kind of
just blindly trusting that the person that created the hardware has a good service provider on
the back end. And like I mentioned, the proxy connections, if you haven't done
this kind of research yet, you'll see a lot of devices traversing through all of your
security, going out to the Internet and then exposing web interfaces on a public port
through one of the search providers. So again for attackers this is kind of a big
deal. Internet things. A lot of insanity is trademarked by me, unofficially. So if you think
about IoT and you think about attack surface, right? IT cameras seem crazy because they
are cameras in your home recording you, audio and video whatever. But really, that's
kind of the purpose of this technology world. It is convenience, yes, there is some
risk, but at the same time, if I'm in Las Vegas I can see my home right now, and that's
pretty cool. But if you go down the line though, an egg tray that is connected, it tells you
how soon your eggs are going to expire. That really kind of solidifies the insanity part of
this for me because imagine what company wants to be the company that gets breached by an egg
trainer office. We get really, really scared when fridges start sending spam. How about you
actually have someone running code execution from your egg tray or running Wireshark from
an egg tray, that should scare you. >> So one of the things that we have noticed is, so
there is IoT, you're probably familiar with a lot of big commercial vendors who have kind
of occupy the IoT space. But, lately, there has been this, this explosion in terms of just
anyone can buy, any one of these things like an electric end, they don't really have to
understand hardware or software. They buy this thing and they Sauder some stuff maybe or they
get their friends to do it, and they go to this web based IDE and they plug in some code, and
then they get $800,000 on kick starter. So hardware is really, really cheap and very
accessible. And the possibilities are endless here, and it's great because anyone
can do this, but at the same time, any one of these pieces of hardware might have its own
security-related idiosyncrasies, the people developing the software, the people running the
services that back some of these pieces of hardware might not actually have any security
experience or actually apply any controls whatsoever. So, you know, the low barrier to entry
is $25 to become a new IoT vendor. I don't know if any of you are familiar with some of
the WiFi enabled lightbulbs but is one of the things that we started to thinking about. We
actually have some WiFi enabled lightbulbs back in one of our offices. And you see something
like Philips, which is a $60 WiFi enabled lightbulb which you would assume all things being
equal. Philips probably took into account some security measures, maybe, but then you
have, you know, the $23 kind of Alibaba special that comes from who knows where, made by who
knows who. And probably not as robust from a security standpoint. So if you're going
to be deploying these lightbulbs across your office so that you can maybe, you know, cut down on
your electricity bill and automate some of the lighting, what are you going to pay for?
Are you going to pay the $60 or go as low price point as you possibly can? So this is kind
of, I think, really represents Mark's point about the IoT ecosystem. It basically stacks
all of the way down, right? Just like with mobile, we've built on top of existing services and
added a whole new device of software with its own vulnerabilities and hardware
issues. So have we done with IoT as well because now we have mobile apps that control these
devices and they talk to web services. So it's just a spaghetti of security to
connect. >> So the to point out, you know, if this and that, we're not talking about phones
and their service and everything else. But we want to kind of talk about the principle that
when you have all of these embedded devices on your network, the next thing you want
to do is connect them all, clearly. You want them to do cool things, and some that are
practical, right? Like my example here, you have a CO2 monitor, if all of a sudden CO2
goes up, aside from of course, like alarms, maybe the lightbulb turns red, or some other way
that can actually, you know, permeate your household or your office space to add value to
what you already have deployed for technology. However, if you have 110 platforms and if this
and that, what happens when, you know, they have tens of thousands of users and they get
compromised? What does that mean for infrastructure, for businesses, for personal homes?
What could you do if you had access to APIs, maybe you found a venerability in one of the
APIs that they are using for customers. What could that mean to people actually leveraging
these platforms? So government, of course, at DEF CON is always a tricky topic. I think, though,
if you paid attention, FTC is ideally there at all times to help consumers protect their
interests. Whether that is companies lying to you, that company is saying that, Oh yeah,
we secure your stuff, don't worry about this. It turns out they don't use encryption or
whatever else. So FTC is actually been pretty forward on this, you know, they've had
panels and they have meetings and talking to different people in this space, but TRENDnet,
which we'll talk about an example here in a second. That was actually a case where they
came down pretty hard on TRENDnet because they had a vulnerable IP camera with a
pathetic vulnerability that should never get out the door from any respectable business,
and that put a lot of people in danger. So for better or for worse, there is government
oversight in this space and so the people in this room, you don't want to be left behind. If
the government is ahead of you in technology we've got a problem. So think about what
you're working on that, that would definitely set a precedent. >> So just to kind of
give an overview of some of the challenges that small vendors in particular face and large
vendors as well, when it comes to IoT. We'll just kind of run though some of these. The talk
that preceded ours and many of the talks that will probably happen throughout this entire
conference, and I'm sure that none of you are strangers to this, but hardware security can
be a death nail for a lot of these devices. And as we showed with the $25 to the $130 devices
that are out there, a lot of these devices that are out in production use just sort of
generic development, you know, system on chips, or development boards and they're designed
basically facilitate rapid prototype and quick development. They don't really have a lot of
security features for a variety of reasons. They want to make it as agile as possible, they want
to make it as quick as possible, they want to have a lower power consumption. Any number of
things and another thing that can be overlooked is the prevalence of the same
components if they're using the same SoC or if they're using the same micro code or any number of
things. Finding one issue in one of those things could affect a whole swath of devices that
might have been not even by the same vendor. Like we said, there's almost no expertise
required to really a common IoT vendor at this point. So the least common denominator any of
this is, I'm not really a great hardware hacker, but this has cropped up time and time again,
it is literally, like, these devices getting shipped out in production with things as simple
as UR headers, so exposed and, you know, you just drop right to a root shell on one of these
devices and you start stealing the whole thing. And then you go and repeat that on every one of
those devices. Software security is still a big issue here as well. Because of a lot of the
environments, in particular, an example, you are kind of restricted as to what language
you can actually develop in. So people might not necessarily, if it is something like a really
low end, or really like, great embedded device, you might have to learn C and people continue
to fuck up and not learn C correctly. So they use functions that they are not supposed to,
right? There are is dangerous behavior repeating itself because we write C pretty one
day. So it's just sort of history repeating. And then because you might be picking a
platform that restricts your language, you might be also restricted to what operating
system you can run as well. And if it's, you know, if the OS is already loaded there or you're
using a vendor-provided OS, they might not have taken into account simple things like
exploit mitigation. They might not have even done things like DPA Solar or XN. They might not
be doing any sort of mitigation, nothing. So just an example over here from an embedded device
which actually runs a web server that talks to a bunch of other things that are really
important. There is zero, pretty much zero memory address randomization. So the dependency
on other libraries, if you think about things like heart bleed, for instance, relying on these
other opaque, or open source libraries you basically get this bug inheritance as well. And
this applies to mobile applications that run these things as well. So
communications and network security for a lot of the devices. There might be some
really weird goofiness. I know someone in the audience is going to recognize this example, but
when the device actually acts as an access point or it connects to a remote control that they
are acting on either mode, when they don't necessarily enable things like WEP, or WAP or WAP2
or they just have some other exploitable behavior. There are cases where they will transmit
things like software updates over plaintext or if they do transmit them securely or over
SSL/TLS they don't sign the firmware update blogs or anything like that. Numerous
services that are exposed on a lot of these devices that don't necessarily enhance
functionality in any way, so just remote administration services. Shared accounts are a
problem as well when the vendor might provide a support account for updates or remote support.
And maybe there's a static SSH key shared across all of these devices or the same hardcoded
password, things of that nature. And these are complicated even furthermore by use of other
technologies like 6LoPAN, ZigBee, et cetera. And then the simple example where you can
spend I think $50 and plug a GSM modem on to your device. There are talks here to we'll discuss
yet again how ridiculous GSM is. So COM security is still a really hard thing to solve if
you're a small IT guy. >> Kind of getting back to the fact that the IoT device you have really
is not just an IoT device, it's really just kind of a hub for a bunch of services that are then
going to connect to from like four or five or third-party vendors. So if you think of
things like APIs, APIs rarely are actually APIs. They're just like, oh, I did a get against a
web server, therefore API. What we're not seeing, A, authentication against these
devices is really there. It will just say, oh, well, this embedded hardware, clearly you
can't see what these calls are over the network and have no protection on them because they
think that no one is going to look at this kind of stuff, or signing request to ensure
integrity to what API calls are made in the first place. So OWASP mobile, you know, web top
ten. This is all alive and well in the world of IoT. The same problems that we all, you know,
attack online and the Internet, guess what, they're all on these IoT devices as well. So if
you're looking to get a shell on one of these devices, maybe it has a sequel server, because why
not add a sequel server to everything, and maybe it has a web app with poor code handling.
Well, guess what, now you write your PHP shell or suburb, CGIF and you drop it on the IoT
device, and you have, you know, CNC over this entire network of IoT devices in that home. So
just kind of conflating all of these different technologies that we already screwed up
really badly all the time. Now it's just like this magical box of terribleness, and that's what
you're buying for $150. So the third party provider thing, you know, I have seen those go
really badly. We will talk about that today, but not too much. If you think about cloud
infrastructure and the services that people stand up, whether it is a pass or they are doing
infrastructure, like, EC2 or something. A lot of these cases they might understand how to get
the software out, which is probably isn't true, but they at least know how to get a nice
piece of hardware out. And then they're saying oh, we need all this infrastructure now to
support this, well, they're going to have infrastructure vulnerabilities, they're going
to have, you know, OS updated packs, and default credentials to web app services and
everything else that people do wrong already. Now you're going to have that across four or five
vendors. Kind of getting back to what I started on which is this idea where, you know, it is hard
enough to get people to update their routers, but at the level of coverage in IoT that I think
we will see in the next few years. That's going to be a really big problem for most
consumers out there. This audience is exempt, you guys will upgrade your firmware
hopefully, but if you have all these different examples across your life in technology, you
know, some things you bootstrap by and opening a mobile app and saying, like, oh, new firmware
version, hit, you know, update. And then some of them you hold the button on the back of the
thing to call home, and you know, bootstrap to that process. And some of them you go to the
web interface on the device. You know, the web interface that was mentioned once in the
instruction booklet that you threw promptly away. So there's all these different ways to do
firmware, and one thing we're not seeing very commonly is auto-updating firmware. Now you
can make pros and cons to whether you should update firmware. Certainly for the
vendor, it is a harder process to get right and have a recovery mode and all that, but again,
how many of these you're going to have, and what's that gonna look like if one bug comes out,
if another heart bleed happens in five years, what would that mean to all these devices that
have SSL snaps that are compromised now. So let's jump into some failures. So a lot of
this section at the top is really an anti-pattern talk. You know, what happened, why it's
wrong, how you should be doing it right, because I think that's a pretty good methodology to
help people understand what is going on. So the TRENDnet that I mentioned earlier, basically
they had a CGI app on this thing where it was viewing video -- and don't let this /anony part
fool you. That's not supposed to be typed anonymous endpoint for this thing. They actually just
failed -- I think it was a code regression, some of the firmware that was across dozens of their
cameras and in this case, the first time the bug came out, someone actually indexed 700
cameras almost immediately, put them online, they actually created a Twitter account to
say, like, oh, look, a new camera that is vulnerable to this. And you could just watch
the video stream by going to this URL on any IP you could find off Shodan or Google. So
it's kind of a big risk for people that bought this camera thinking, like, yeah, TRENDnet
company, they have been around for a while. In this case, this is all that you do. You go to
Google into your URL and find some cameras, and that's of course if you don't just go to
one of the many aggregation sites for big creepers, but don't be a big creeper. And
really what frustrates me, this isn't a security thing, right? This is like basic QA101, does
your admin have access to admin pages, do your guests have access to guest pages, and can
your guests get to admin pages? The answer should be no. And they didn't take the time to run
a curl script on a loop or Selenium tasks or anything else. That would have very quickly
caught that this was a problem. So second one, you know, IOActive has done amazing
research. One section they did a little while back was on some of the Belkin WeMo stuff. And, you
know, in this case, you have Belkin which is actually doing some of the best practices out
there. They're actually signing firmware. Unfortunately, and you know, anyone who has ever got a
key burn knows how this feels. They had the key, and then the pass phrase is actually
hardcoded in the firmware. So the firmware got dumped, they extracted the signing key and
pass phrase and now they're at a point as an attacker where you can actually sign valid
firmware. So if you can amend the middle of the update request or you can somehow otherwise
interface into the update mechanism, at that point you would actually be able to push
valid firmware on to that device. So you know, QLDR on this one, and we're going to
touch this one or two more times while we're standing up here. Don't hide stuff in firmware.
It's not hidden, like, whether someone gets the firmware today or tomorrow, whether you think
that you obfuscated a key in there, you didn't, it's not hidden. The same thing applies
to mobile apps. Just because it's encrypted when it goes up to the app store, it doesn't
mean that someone can't just dump the memory and get all of the ASCII out of that binder and
go through. >> So contact security was looking at these LIFX devices and what they
discovered was that -- so 6LoWPAN and other low-powered, you know, IPV6 over this low
power -- inside of the device, once again, hardcoded symmetric key for encrypting all sorts of
data, including credentials, and WiFi pass phrases and such for the other side of this device.
So the hypothetical exploit, you give this to someone as a gift, you creep up on their house
pretty usual, and one they add the bulb to their network, you just capture traffic decrypted
with symmetric key and then you get all their WiFi credentials. And then you just jump on to
their WiFi network and you creep on them there as well. So, again, repeating the same exact
thing from before. Don't hardcode things if you don't want them to be found. They will
be found. So that's why -- Dubbie and Dolan are over there. So another example here. This is
a whole automation gateway that was built by a large utility group. Well, provided by a large
utility provider. What they did was they actually outsourced all of this to another service
provider who gets these basically like white label devices that connect to their
infrastructure so that you can on there and, you know, have your lights flip on and off, and
have your pool pump flip on and off, and it has this beautiful web interface. It's really ugly,
it wasn't that beautiful. It can be controlled though a mobile app as well, so, you know, you
talk to this magical cloud site and then over this verse connection to this gateway will
push down directives from the users of scheduling and things of that nature. So this kind of
represents sort of the whole swathe of things that, you know, the web interface itself was
vulnerable to all sorts of OWASP top 10 101 things. And then the gateway itself had unfettered
console access, there were the UR headers exposed that dumped you right into the root shell.
There was no privileges separation for any services on the device. The same support
credentials are used to manage all of the devices. And then on the other side, on the ZigBee
side of it, where it talked to the controllers there was vulnerable, like, things
extraction, replay, injection, et cetera. So this is sort of an example of we start to kind of
encroach upon utility and more ICS-type stuff. >> Cool, so that is pretty cool stuff that other
people have squared away in this space. So this next topic someone actually did last year,
does anyone have an IZON IP camera? There's plenty of people. There's got to be one or
two in here. Yeah! Did you get rid of it? It's not surprising. So a couple examples. So IP
camera, I bought it, I had the best of intentions. I happened to scan my network one day as
you do, and there was Telnet listening, and whenever Telnet is listening in 2013 of this
time, you should just stop what you are doing, and figure out why Telnet is on your network
and stop it immediately. So in trying to break into this device and do bad things to it, one
thing I did getting back to my don't hardcode stuff anywhere is, okay. All right. No, setup.
So the mobile app in this case, again, people assume mobile apps are safe and they're encrypted.
Well, when you have them in your phone and you start them, guess what? They decrypt. So you dump
the memory and you get the decrypted version of this. In this case, you know, in this IDA
screen shot, this was actually shell scripting that connected over Telnet to do the firmware
upgrade kickoff. So you have hardcoded root credentials over Telnet firmware upgrade. This is
what we're talking about in IoT and the Internet of fails. This is like a collapsing of
terribleness. So in this case, run strings, get some details. Drop your admin credentials and
log-in. And now, you've guess what? You have access to root on every single camera because this
isn't a mobile app. This isn't one off thing, this is every single one. >> All right. Let's
congratulate our first time speaker to DEF CON. [Applause] >> Thank you. >> There you go.
>> Oh, I feel so much better now. >> All right. I just want to point out, I love that
Internet of fail comment about the Internet of things. >> Is there anything different? It's
not just a synonym? >> Well, that is true. That's where we've been for ages. >> So if you are
ever in charge of this scenario, do not use Telnet, if you do, you're not a DEF CON, so let's
face it, you guys are fine. And don't hardcode passwords. Another example, this gets to
the service layer. So Amazon web services was being used to actually store the video
recording. So if you had a motion alert, or sound alert, it recorded, drop it to S3, your
mobile up would then go, hey, I need to see that alert, and then it would pull it up. So in this
case, there was no authentication required to hit the endpoints for S3. So they
weren't using the IAM or any of the other very smart ways you should do things. The times were
protected with MD5 strings for the actual file digest, and there's no SSL. So A, if you're
in a coffee shop and someone is on the network, guess what? They're going to see the same
video you are watching on your own. B, if you have a shit load of time, and a cluster and want
to piss off AWS, you could probably get through a little bit of key space and maybe find
a video or two. But it's one of those things, you take something as simple as upload a video and
store it, they don't encrypt it in transit, they don't encrypt it as rest, and they don't
actually protect it with anything more than just a file name stream. So if you thought
your video of you getting out of shower and walking by was going to be deleted off of the
Internet securely, I wouldn't hold hope out. So yes, simple things like AWS has identity
access management. It's very easy. You can give credentials per users. Block things off, put
it in a mobile app, and make it connect out and actually do API calls the right way, and segment
data. Also, hey, Amazon, you can just encrypt before you upload, simple as that. Yes, good cat
video is cat videoing. So you guys enjoy that for a second. Getting back to my tirade
against APIs. Is it the poorly implement or is it the low sack? Okay. So API calls in this case,
the API calls that were actually going out, again, without SSL, because why would you encrypt
anything? And the secret token in the API call, this is how you can tell that this is always
true. The secret token was just the user's password that was MD5. So if you didn't already
have their password, and you were on the network with them, you sniff the terrible password,
anyway, and now you can just login as that person and look at their video realtime and see
them when they're getting out of the shower. One thing that happened here which really
pissed me off, and I made that very clear to the vendor is they actually took my password that I
signed up with for their service, and transmitted the MD5 sum to their vendor, and they
thought that was like okay to do. So when we do things like use, you know, one password or
last password or whatever, and we're like, yeah, we have one password per site. Guess what? I
didn't know that this was a vendor. So if they get breached I'm not changing my password
because I don't think I'm impacted, but I am because they've passed my password on to
someone else without telling me about it. So I think one thing that helps is looking at kind of
the big picture of what is happening in IoT. Remember, this is one device. All of those
things that you're seeing on the screen are a direct vulnerability I found, just a
terrible failure of best practices or just a total compromises of security for all
customers to the point where they actually had hardcoded Amazon S3 credentials in the
mobile app. Remember how I was just saying that Amazon S3 was the place they stored everyone's
videos without any kind of segmentation? So we're supposed to say this vendor is redacted,
but -- yeah, whatever. So these are real, real issues that we identified maybe six, or seven
months ago. Well, even longer. So basically just to give you an idea, this device is basically a
little embedded device, there's a mobile app that goes with it. You can pretty much control
everything through this mobile app and it talks to AWS and pushes messages back and forth
and down. And it uses the electric input. So the session IDs to talk to their service to
actually manage and push messages down to this device were just based on UNIX epoch,
period. Just the UNIX epoch as timestamp for when you logged into that service. So that's a
very small space in which to actually root write. So with all of the recent timestamps, just,
you know, brute force through them. So then you become a user simply with this little browser
header. So clearly the fix is, use real session management, right? This is all back to ten
10 OWASP 101 basic web security stuff. The impact here is pretty bad because it has to do with
kids. So they also have a system where you can buy credits to then send messages to these
various devices. So you purchase these, these credits via an app purchasing inside of the mobile
application. Now, it turns out that -- the, it was the client's side enforcement. The client
would tell the server how many credits it wanted. The server is like cool, whatever you say. You
can pick a number, any number, a signed integer, add and remove credits as you felt fit. So you
get that many of whatever things, whatever credit things this gives you. So obviously do
not let the client be the authority for this because you must assume that it is in the
bad creeper's control. Excuse me. So there was also this sort of -- I don't really want to
confuse deputy problem, but just basically a major fuck up where -- if you, the analogy here, is
if you are using something like Facebook, I send you a friend request, you have to then accept
or reject that friend request before we see each other's stuff, right? Technically, like,
that's generally how it works. Here, however, you could ask the user or whoever, you know,
whoever your target is to be your friend and immediately access their stuff. So you could
start sending messages to this device. So, you know, ask a user to be your friend, you get some
stuff back about the user and then you can just start sending messages to their device. So,
obviously, have, you know, authorization process for all of these things. I don't actually
transmit anything about target back that the attacker can then use. You know, actually have
control be on the target's side. And then, of course, there is the heart bleed discussion that
doesn't seem to want to die. So you've got MoLEP speaking to embedded devices, you've got
embedded devices speaking to remote services and back and forth. You know, there's been
these stats, I think it's been something like 300,000 services that have been identified out,
live out on the Internet that are vulnerable to heart bleed and probably other things as
well. But you have to ask yourself, what about these devices that are employed
internally or the services that they are talking to or even the clients, are the clients
actually vulnerable to heart bleed, obviously, that's been demonstrated as well. So you
really think that the $25 Ali Baba special lightbulb that you bought. If that happens to be
vulnerable to something like this, do you really think that you're going actually get that
addressed that the vendor actually cares? They might even be a fly by night operation or
may not have the expertise to actually deal with this. >> So one problem that we're seeing
and why we're so interested in this space in trying to make it suck less is the vendors that
you're going to see in this space are not, you know, the Belkins. You know, obviously
they have some stuff, Cisco has some stuff, but they're not the people that you're going to get
most of your devices from. A lot of the stuff -- if you look at the kick starter, and you go-go
dragging innovation, you know, there's a lot of IoT right now, and if you think of like
$80,000, you have to do R&D, prototyping, software development, hardware
management, Cloud Services, hiring marketing and salespeople. To build devices,
ship them and then have like legal, right? $80,000 is going to go very, very, very quickly.
They're not going to have money to spend on protecting your device. Again, everyone has the
best of intentions, right? And that's why this road is paved, you know, to hell with IoT
devices all along the way. We're going to be in a really bad place, much worse than we are
now, which is pretty bad. And if you look at postscapes.com or devices that are from alpha.com,
go see how many companies you've ever heard of because they're probably brand new
entrepreneurs, brand new bootstrap startups, or someone that crowdfunded a device. And
this is the kind of stuff all of us are going to want to buy, but at what cost, right? One other
main point to this is a security researcher to Belkin, or Cisco or Samsung at least mean
something, right? Security researcher, these vendors with two people on staff that are
both like maybe one product designer and one guy that is okay at mobile apps they don't
know what security research is, they probably don't come to DEF CON, and they are going to be
the people that are trying to triage bugs in thinking that you're breaking in to their
company and trying to extort them. And we've been told on a call by a lawyer that we hacked
their systems, and that we were doing like terrible things to their company when all we were
doing was testing the device locally in our home. So crowdfunding, again, a lot of
this is coming out of crowdfunding. It's not just, like, speaking of platitudes,
like, literally some of these devices are that you might be using right now actually or
probably crowdfunded. And it's a great way to innovate, for sure, but again, the margins on these
things are nil and the amount of extra capital they have to invest is also nil. So it
doesn't really turn out too well. >> So kind of back to what Mark was just saying a minute
ago. A lot of these small vendors, and we've had this experience time and time again,
as I'm sure many of you probably have as well, the small vendors, even some large ones to this
day, right? That's why we still have CFA reform and shit like that. They just don't quite get
why you're coming to them and telling them that their baby is ugly. Why would anyone want to
hack my device? What are you selling? Why would you want to talk about this publicly? They
don't have the resources or the experience to necessarily deal with this. Like Mark said, Mark
said they might be strapped for cash or they're just trying to get the product out the door. So
the need for this space as well means that certain researchers even if you're like bad ass, you
know, super mega cool exploit, but haven't really ever interacted with an IoT vendor
before, especially one of the smaller ones, you might not know how to approach them. So we kind
of like to bridge that gap between, like other initiatives have done before for the
traditional space. We kind of like to make sure that stuff is fixed and that you-all stay out
of jail when it comes to IoT. So born out of some of that redacted slides you saw, and
just general frustration talking to vendors in this space and realizing that they're not going
to get it. We started an initiative called build it securely. So primarily we're
focused on the small company. The vendor that is kick starter or it's bootstrapped because
more often than not, they're going to have no money. Even some of the big vendors don't
actually have as many security resources on staff as you would like to know or like to think.
Ad so primarily we're trying to bridge that gap for them and help them get better devices in
your hands so we're going to still do research. You're going to get devices you don't have to
throw away after two days. We're also trying to create resources on the site. So if you want to
know, hey, I'm an engineer, what is the one document I should look at for IOS security, what's
the one API presentation I should look at, and we'll try to create some of those on the site
and just give resources that we think are pretty legit, and hopefully they actually read
them and go through them. And then of course, presenting conferences like this to talk
about this and, you know, getting people involved. Okay. It has been a long road. We will
look at a timeline in a second. But where we're at now is the drop cam was just acquired by
NASA for $550 million, unrelated to our impact on them, I assure you. And Belkin just came on. So
obviously we talked earlier about IOActive and Belkin's research. Brian over at Belkin
actually has a good security pedigree, and he really does want to make things better. So
we're going to be working with his team as well to give them extra resources and make things
more secure for all of the cool stuff they have coming out. Dip Jar is actually an incubator
startup out of Boston, and they are doing some cool stuff with basically a tip jar, GSM
enabled, that you can just dip your card in and that's how you tip people if you don't have
cash and you kind of want to go and like say, here's two bucks. And who else do we have?
Pinoccio which is actually a system on ship vendor, you might have saw them in earlier slides.
Zendo is a stealth startup right now in the IoT space. They're going to have a pretty large
product line coming out here. Fun fact, the CEO of Zendo is actually the former CEO of
Steminnovation who made the eyes on camera. He saw my research previously, and that this new
company he doesn't want to do it the wrong way. So, you know, we get really cynical about
companies not giving a shit, but I had a cold call from a CEO of someone I burned in the news.
And he reached out to me to have me come in and give security lectures to his engineering
staff. So it's not all doom and gloom as much as we might pretend. There are companies
that are trying to work hard on security, and we should try to support them. Amazing
researchers, IOActive, Steven Routley, Stephan Chenette, Don Bailey, did we forget anyone?
Zack, and then Bugcrowd is providing their entire platform pro bono to us. So that
researchers can triage bugs to vendors through a private communication between them. And
the best part about all of this is, all of the researchers are basically doing this, one,
because they want to help some people, two, because they're going to get research done and
not be sued for it. They already have opt in from these vendors. So, these are some pretty
awesome companies. Some companies you might not have heard of up here, but these are
really interesting companies doing some pretty impressive product lines coming out in the
space. And we're going to have researchers looking at preproduction hardware, doing
assessments against them, getting them bugs and actually making this device better before
they go in people's hands rather than after. But, again, they'll be at DEF CON hopefully next
year talking about some of the stuff they brought because that's part of the deal. In
terms of timeline, we just started this up in February, besides San Francisco, you know,
we've really been kind of spinning things up pretty slowly. We don't want to have a
situation where we say every researcher on Earth get involved in this. We're not trying to
have the largest list of people. We're trying to have the most output and the most production.
And sometimes you have to kind of do the walk before you run. So far so good. We actually just
in July shipped hardware from Pinoccio to two of our researchers. So that's kind of
our first line in the sand that hey we accomplished something that we were trying to
accomplish. And we have a lot more coming out for the next few months, and we'll be bringing
for researchers on. We have contact details at the end if you want to look at some of
that. Pinoccio has got the hardware. Bugcrowd is setup for our vendors at this point. We're
still kind of doing some of the stuff that we all deal with already which is like timelines,
triage, when the bugs have to get fixed, when we going to drop bugs and is the kind of stuff
that any kind of coordinator goes through when you do this sort of process. And we're
growing. It's not about having the most people on our website, but it's about having the most
people getting shit done and associated with us, which is something that our vendors have
taken kindly to. They don't want to have you throwing 300 people at them because it's hard for
vendors that don't have security in-house to understand how to work with vendors. So we're
actually doing a lot of knowledge transfer and teaching vendors in this space, what kind
of research it is, how it works, why people do it, and why we're at DEF CON in the first place.
>> So what does it all mean? What's the conclusion? So basically what we've learned is
that people can actually be altruistic occasionally. There is a lot of cynicism, but
sometimes people can suspend that or actually erase it entirely and, and don't be
afraid to actually reach out to people, and vice-versa. Don't be afraid -- we would encourage
like collaboration. We want people to want to do this. We want this to be a community
effort so we can have an impact. That's why we've partnered with like I Am The Cavalry, for
instance, because this kind of falls in line with some of the stuff that they're doing. It
gives us visibility and gets them resources. Of course, we did have some aggressive goals
initially, but we've stepped back and kind of made it a little more comfortable. Doubled
the timeline, basically. Since a lot of the researchers are doing this, you know, pro bono, they
are doing this, they get the benefit of business, they are doing it for us. Pro bono,
they're pretty busy, they have day jobs, so do we. So this is also us kind of taking spare
cycles and working on this project. And, again, like Mark said we want quality, not
quantity. We want more people to be involved, but we want to make sure that everyone is kind of on
the same page and everyone is going to be able to relax into this. And measured successes and
milestones. So far we have done pretty well in hitting some pretty significant milestones.
They might not be significant to a lot of people in the grand scheme of things, but it's
definitely accelerating to where we want to be. So IoT is still malleable enough. This is still
enough space that we can actually have an impact versus like some other spaces like --
web security has been solved or some shit, but you know, we're not going to have there is some
shit, but we don't have to shoe horn this into everything else. IoT we can make a difference now
before it comes catastrophic. This could also help consumers make better decisions as well.
If they see not so much an underwriters laboratory-type of thing but something similar, it
would give consumers a, sort of a yardstick to say, oh, this is been vetted, this vendor cares
and people can decide with their wallet, right? So if nothing else, if this goes haywire. We
helped vendors and got researchers to do doing cool stuff. At the end of the day,
that's not bad. So the site is BuildItSecure.ly. You can also reach -- there's a mailing list.
I think we actually did mention, the mailing list, the thing about that we have our vendors,
our partners and the researchers on the same mailing list. So there is no silo, and talk bad
about this vendor over here. That created a nice open communication, if there is a
question, someone says I'm going to be deploying firmware XYZ do you want to help me. So there is
no silanization. So with that I think we have a couple of minutes left if there are any
questions. Otherwise you can meet us in the chill out lounge afterwards. [Applause] >> And,
and thanks.