>> 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.