 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'll be fun. 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 Staslaw with Duo Security as well. Thank you. Thank you. So IOT, you know, if you've been in this space for a while, you've probably more affectionately known similar things as M2M, so machine 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 like five years and now everyone's just like, yeah, cloud computing, cool. But everyone wanted to be like, oh, that's not a thing and this is bullshit and no one will ever do this. So I think IOT is the same way. You know, probably get past 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, especially for infosec research. A lot of the talks I think we'll be seeing at DEF CON for many years to come will be around these kinds of devices. There's 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 routers, 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 household in five years? There's a lot going on there. The attack service, whether it's 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 at Best Buy that reverse proxy out into the office. That would be great for you. In terms of the overall environment, there's a lot going on just in terms of how diverse the technologies are. So the ecosystem is 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, you know, manually do it? What's that going to look like again when you're at scale? And then the problem we've always had with embedded hardware is you get random, you know, ODMs, you have firmware that no one's actually done security audit 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 putting on your network. You're buying a piece of hardware, putting 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, you know, tying to something else you're doing. So where does your data go when it goes to the IOT? It's the same problem as cloud, right? Where's my data at? 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 that hardware has a good service provider on the back end. And like I mentioned, reverse proxy connections. If you haven't done this kind of research yet, you'll see a lot of devices traversing through all of your, you know, perimeter security, going out to the internet and then exposing web interfaces on a public port through, you know, one of the service providers. So again, for attackers this is a kind of a big deal. Internet of Things, line of insanity trademarked by me, unofficially. So if you think about IOT and you think about attack surface, right? IP cameras seem crazy because there are camera in your home recording you, audio, video, whatever. But really that's kind of the purpose of this realm of technology. It's convenience, yes there's some risk, but at the same time if I'm in Vegas I can see my home right now and that's pretty cool. If you go down the line though, you know, an egg tray that's connected, tells you how soon your eggs are going to expire. That is like, 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 tray in their office. You know, we get really really scared when like fridges start sending spam. How about you actually have, you know, someone running code execution from your egg tray or running wire shark from an egg tray? That, that should scare you. So one of the things that we've noticed is, so there is IOT, you know, you're probably familiar with a lot of big commercial vendors who kind of occupy the IOT space, but lately there's been this, this explosion in terms of just anyone can buy any one of these things like an electric amp. They don't even have to really understand hardware or software. They buy this thing, they solder some stuff maybe or they get their friend to do it and they go to this web-based IDE and they plug in some code and then they get $800,000 on Kickstarter. 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, 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 entry is $25 to become a new IOT vendor. I don't know if any of you are familiar with some of the Wi-Fi enabled light bulbs, but this is one of the things that we started to think about. We actually have some Wi-Fi enabled light bulbs back in one of our offices and you see something like Phillips which is a $60 Wi-Fi enabled light bulb which you would assume all things being equal, Phillips 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 were going to be deploying these light bulbs across your office so that you could 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 to as low, 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's basically stacks all the way down, right? Just like with mobile we've built on top of existing services and added in a whole new device running its own software stack with its own vulnerabilities and its own 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 this spaghetti of so security much connect. So to point out, you know, if this and that, we're not talking about volumes in their service or anything else, but we want to talk about kind of the principle that when you have all 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 of this is 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 light bulb 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, you know, 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 vulnerability in one of the APIs that they're using for customers. What could that mean to, you know, people actually, you know, leveraging these platforms? So government, of course, that DEF CON is always a tricky topic. I think though if you've paid attention, you know, the FTC is ideally there at all times to help consumers protect their interests, whether that's companies lying to you, that's companies 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 has actually been pretty forward on this. They, you know, they've had panels at CES. They have, you know, meetings 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, you know, a pathetic vulnerability that should never get out the door from any respectable business and 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, like, you don't want to be left behind. If the government's ahead of you in technology, we've got a problem. So think about what you're working on. You know, 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 through some of these. So even obviously the talk that preceded ours and many of the talks that will probably happen throughout this entire conference, and I'm sure none of you are, you know, strangers to this, but hardware security is kind of a, kind of a, can be a death knell for a lot of these devices. And as we showed with the $25 to $130 devices that are out there, a lot of these devices that are out in production use just sort of generic, you know, system on chips or development boards. And they're designed to basically, you know, facilitate rapid prototyping, quick development. They don't really have a lot of security features for a variety of reasons. Maybe, you know, they just want to, they want to make it as agile as possible. They want to make it as quick as possible. They want to have low power consumption. They, you know, 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, you know, microcode or any, any number of things. Finding, finding one issue in one of those things could affect a whole swath of devices that it might not even be by the same vendor. Like we said, there's almost no expertise required to really become an IoT vendor at this point. So the kind of least common denominator for any of this is, I'm not really a great hardware hacker, but this is cropped up time and time again is literally like these devices getting shipped out in production with things as simple as UART headers still exposed. And, you know, you just drop right to a root shell on one of these devices and you start stealing all the things. And then you go and repeat that on every other single one of those devices. Software security is still a big issue here as well. Because a lot of the environments that, electric imp in particular, or as an example, you're kind of restricted as to what language you can actually develop in. So that might, you know, people might not necessarily, if it's something like a really low end or really, really like great embedded device, you might have to learn C and people continue to fuck up and not learn C correctly. So they do things like use functions that they're not supposed to, right? There's dangerous behavior repeating itself because me right 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 an operating system, you know, if the OS is already loaded there or you're using some vendor provided OS, they might not have taken into account simple things like exploit mitigations. They might have even done things like, you know, a DAP-ASLR or an X or XN. They might not be doing any sort of linker, you know, mitigations, nothing. So even 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's like, you know, there's zero, pretty much zero memory address randomization. So the dependency on other libraries, you know, if you think about things like OpenS, Heartbleed for instance, relying on these other opaque or even 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 these devices, there might be some really weird goofiness. One of the, 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 then controls it, it cannot, you know, act in either mode when they don't necessarily enable things like even, you know, web or even WPA or WPA2 or they just have some other exploitable behavior. There are cases where they will transmit things like software updates over plain text or if they do transmit them securely or over SSL or TLS, they don't sign the, you know, the firmware update blobs 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, wherein the vendor might provide a support account for updates or remote support and, you know, maybe there's a static SSH key shared across all of these devices or the same hard-coded password, things of that nature, and then these are complicated even furthermore by use of other technologies like Sixlopan, ZigBee, et cetera, and then the simple example where you can go and spend, I think, $50 and plug a GSM modem onto your device and, you know, well, there are talks here that will discuss yet again how ridiculous GSM is. So com security is still a really, really, really hard thing to solve apparently when you're a small IoT vendor. Kind of getting back to the fact that the IoT device you have really is not just an IoT device, right? It's really just kind of a hub for a bunch of services that are then going to connect to it from, like, four or five 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. And what we're seeing, what we're not seeing, a, authentication against these devices was really there. It just will, you know, say, oh, well, this is embedded hardware. Clearly you can't see what these calls are over a network and have no protection on them because they think no one's going to look at this kind of stuff or signing requests to, you know, ensure integrity to what API calls you're making in the first place. So, OAS, mobile, you know, web top 10, 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 in these IoT devices as well. So if you're looking to, you know, get a shell on one of these devices, maybe it has a SQL server because why not add a SQL server to everything? And maybe it has a web app with, you know, poor code handling. Well, guess what, now you, you know, write your PHP shell or, you know, CGI app to drop it on that IoT device. And now you have, you know, CNC over this entire network of IoT devices in that home. So just kind of conflating all these different technologies that we already screw 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've seen those go really badly, we'll talk a little bit about that today, but not too much. If you think about cloud infrastructure and the services that people stand up, whether it's a pass or they're doing infrastructure like EC2 or something, a lot of these cases, they might understand how to get the software out, which probably isn't true, but they at least know how to get a nice piece of hardware out. And then they're saying, oh, well, we need all this infrastructure now to support this. Well, they're going to have infrastructure vulnerabilities. They're going to have, you know, OSs they didn't patch. They're going to have, you know, 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's hard enough to get people to update their routers, but at the level of coverage in IoT that I think we'll 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, you know, all these different examples across your life and in technology, you know that some things you bootstrap by opening the mobile app and saying like, oh, new firmware version, hit, you know, update. And then some of them you hold a 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 web interface. 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, very commonly is auto-updating firmware. Now you can make, you know, pros and cons to whether you should auto-update firmware. Certainly for the vendor it's a lot harder for a process to get right and have recovery mode and all that. But again, how many of these are we going to have and what's that going to 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 stacks that are compromised now? So let's jump into some failures. We're going to kind of start it. So a lot of this section of the talk 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's going on. So the trend that I mentioned earlier, basically they had a CGI app on this thing where it was viewing video. And don't let the slash and nonny part fool you. That's not supposed to be an anonymous endpoint for this thing. They actually just failed at, I think it was a code regression on some of the firmware that was across dozens of their cameras. And in this case, the first time this 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's vulnerable to this. And you could just watch the video stream by just going to this URL on any IP you could find off Shodan or Google. So kind of a big risk for people that bought this camera thinking like, yeah, trend that legit company they've been around for a while. In this case, this is all you do. You go to Google, do in 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 QA 101. 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 a selenium test or anything else that would have very quickly caught that this was a problem. So second one, you know, IOActive has done always 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's ever got a key burn knows how this feels. They had the key and the passphrase actually hard coded in the firmware. So the firmware got dumped. They extracted the signing key and the pass phrase. And now they're at a point as an attacker where you could actually sign valid firmware. So if you can man in the middle 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 onto that device. So, you know, TLDR on this one and we're going to, I think, 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 like 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 does not mean someone can't just dump memory and get all the ASCII out of that binary and, you know, go through it. So, the context security was looking at these LIFIX devices and what they discovered is that so Six Low Pan, another low power, you know, IPV6 over this low power mesh network, inside of the device once again hard coded symmetric key for encrypting all sorts of data, including credentials, Wi-Fi 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 per usual and once they add the bulb to their network, you just capture traffic, decrypt it with symmetric key and then you get all their Wi-Fi credentials and then you just jump onto their Wi-Fi network and you creep on them there as well. So, again, repeating the same exact thing from before, don't want them to be found, they will be found, so that's why Guby and Dolan are over there. So another example here, this is a whole automation gateway that was built by a large utility provider, what they did was they actually outsourced all this to another service provider who gives these basically like white label devices that connect to their infrastructure so that they can go on there and you know, have your lights flip on and off, have your pool pump flip on and off and automated all through this beautiful web interface, it was really ugly, it wasn't that beautiful, it can be controlled through a mobile app as well, so you talk to this magical cloud site and then it over this reverse connection to this gateway will push down directives to all sorts of OSP, you know, web top 10 101 things and then the gateway itself had unfettered console access, there were UR headers exposed that dumped you right into a root shell, there was no privilege separation for any services on the device, the same support credentials were used to manage all of these devices and then on the other side, on the ZigBee side of it where it was, so this is sort of an example of, you know, we start to kind of encroach upon utility and more ICS type stuff. Cool, so that's some pretty cool stuff that other people had squared away in this space, so this next topic someone actually did last year, does anyone have or had an eyes on IP camera? There's plenty of people and there's got to be one or other, so a couple of examples, so IP camera, you know, I bought it, I had the best of intentions, I happened to scan my network one day as you do and there was talent listening and whenever talent listening in 2013 at this time you should just stop what you're doing, figure out why talent is on your network and stop it immediately. So into trying to break into this device and do bad things to it, set up. So the mobile app in this case, again, people assume mobile apps safe, they're encrypted, well, when you have them in your phone and you start them, guess what, they decrypt, so you dump memory and you get the decrypted version of this and in this case, you know, in this IDA screenshot, this was actually shell scripting that connected over Telnet to do the firmware upgrade kickoff. Over Telnet firmware upgrade, this is what we're talking about in IoT and the Internet of Fails, like 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 guess what, have access to root on every single camera because this isn't the mobile app, this isn't, you know, one off thing, this is every single one. Let's congratulate our team. Oh, I feel so much better now. I just want to point out, I love that Internet of Fail comment about the Internet of Things. Is there anything different? Isn't that just a synonym? Well, it's true. It'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 at DEF CON, so let's face it, you guys are fine. And this is a service layer. So Amazon Web Services was being used to actually store the video recording, so if you had an alert, like a motion alert sound alert, it recorded, drop it to S3, your mobile app would then go, hey, I need to see that alert and then it would pull it up. So in this case, there were, there was no authentication required to hit the end points for S3, so they weren't using IAM or any strings, probably for the actual file digest. And there was no SSL. So A, if you're in a coffee shop and someone's on the network, guess what, they're going to see the same video you're watching on your phone. B, if you have a shit ton of time and a cluster and want to piss off AWS, you can probably get through a little bit of key space and maybe find a video or two. But it's one of those things, they don't want to encrypt it at rest and they don't actually protect it with anything more than just a file name string. So if you thought your video of you getting out of the shower and walking by was going to be deleted off the internet securely, I wouldn't hold hope out. So yeah, simple things like AWS has identity access management. It's very easy. You can give credentials per user, block things off, put it in and say, hey, Amazon, you could actually just encrypt before you upload. Simple as that. And yes, good cat video is cat videoing. So you guys enjoy that for a second? Okay. Getting back to my tirade against APIs, is it always probably implement or is the lol sec? Okay. So API calls, in this case, the API calls that were actually going out, again, if you encrypt anything. And the secret token in the API call, this is how you can tell always probably implement is 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 rainbow table that, crack it because they were going to be a terrible password anyways, and now you can just log in as well, 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 okay to do. So when we do things like use, you know, one password or last password dash lane or whatever, and we're like, yeah, we have one password per site. Guess what? I didn't know that this was a vendor. I did pass 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's happening in IoT. Remember, this is one device. All of those things that you're seeing on the screen are either a direct vulnerability I found, just a terrible failure of best practices or just a total compromise of security for all customers. To the point where everyone was on S3 was the place they stored everyone's videos without any kind of segmentation. So we're supposed to say that this vendor is redacted, but yeah, whatever. So these are real issues that we identified maybe six or seven months ago. Well, even longer. So basically just kind of give you an idea. This device is basically a little embedded device. There's mobile app that goes with it and it talks to AWS and pushes messages back and forth and down and uses Electric M for the hardware platform. So do your homework. So the session IDs for there to talk to their service to actually manage and push messages down to this device were just based on Unix epoch period. It was just the Unix epoch as time stamp for when you logged into that service. So it's a very small boot, right? So enumerate all the recent time stamps. Just, you know, brute force through them. So you then become a user simply with this little browser header. So clearly the fix is use real session management, right? This is all back to top, you know, top 10 OOSP 101 basic web security stuff. And by the way, the impact here is pretty bad because it doesn't work. So they also have a system where you can buy credits to then send messages to these various devices. So you would purchase these credits via an app purchasing inside of the mobile application. Now, as it turns out that it was client-side enforcement basically, like the client would tell the server how many credits it wanted. So whatever you say. So you could just basically pick a number, any number, signed integer, add and remove credits as you felt fit. So you get that many 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 creepers control. So there was also this sort of, I don't really want to just basically a major fuck-up where 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 technically, like that's generally how it works. Here, however, you could ask the user or whoever your target is to be your friend and immediately access their stuff. So you could send messages to this device. So ask 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 real authorization process for all these things and don't actually transmit anything about the target back that the attacker could then use. Actually have that 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 mobile apps 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 was something like 300,000 services have still been identified live out on the internet that are vulnerable to heart bleed, probably other things as well. But you have to ask yourself what about these devices that are deployed internally or the services that they're 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 light bulb that you bought, if that happens to be vulnerable to something like this do you really think that you're going to actually get that addressed, that the vendor actually cares? They might even be a fly-by-night operation. Or maybe I have the expertise to deal with this. So one problem that we're seeing and why we're so interested in this space and 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 a Kickstarter, Indiegogo, Dragon Innovation, you know, there's a lot of IoT crowd funding and I think of like 80 grand, you have to do R&D, prototyping, software development, hardware management, cloud services, hiring, marketing, sales people, 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 and they're going to, you know, again, everyone has the best of intentions, right? And that's why this road is paid, you know, to hell . We're, you know, we're going to be in a really bad place, much worse than we are now, which is already pretty bad, and, you know, if you look at postscapes.com or devices.woolformalpha.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 crowd funded a device, and this is the kind of stuff all of us are going to want to buy, but at, you know, what cost, right? If you're a security researcher to Belkin or Cisco or Samsung, at least mean something, right? They're like, oh, security research, okay. These vendors with two people on staff that are both like, maybe like one product designer and one like guy that's okay at mobile apps, they don't know what security research is, they probably don't come to DEF CON, and they're going to be the people that are trying to triage bugs and thinking that you're breaking into their company and they're doing terrible things to their company when all we were doing was testing the device locally in our home. Crowdfunding, again, a lot of this is coming out of crowdfunding, it's not just speaking of platitudes, literally some of these devices are that you might be using right now actually, we're 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 matter. 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, I'm sure many of you probably have as well, these small vendors, even some large ones, even to this day, that's why we still have CFA reform like that, they don't quite get why you're coming to them telling them that their baby is ugly, so like why would anyone want to hack my device, what 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, they might be strapped for cash or they're just trying to get the product out the door, so the nasency of this space as well means that certain researchers, even if you're badass, super mega cool exploit dev, but haven't really ever interacted with an IoT vendor before, especially one person, so we'd kind of like to bridge that gap between much like other initiatives I've done before for the traditional space, we'd kind of like to make sure that stuff gets 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 they're not going to get it, they're going to be focused on the small company, like the vendor that is kick-started or is bootstrapped, because more often than not, not entirely, but more often than not, they're going to have no money, even some of the big vendors don't actually have as many secure resources on staff as you would like to know or like to think and so primarily we're looking at trying to bridge that gap for them and help them get better access to devices you don't have to throw away after two days, that's pretty cool. We're also trying to curate resources on the site so if you want to know hey, what's, I'm an engineer, what's the one doc I should look at for iOS security, what's the one REST API presentation I should look at and we'll try to curate some of those on the site and just give resources that we think are pretty legit and hopefully they don't have a timeline in a second, but where we're at now is so Dropcam just got acquired by Nest for $555 million unrelated to our impact on them, I assure you, at least I haven't got a check cut yet and Belkin just came on so obviously we talked earlier about IOActive and Belkin's research, you know, Brian over at Belkin actually has really, really good security pedigree and he really does have a lot of resources to make things more secure for all the cool stuff they have coming out. Dip Jar is actually an incubator start-up out of Boston and they're 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 want to just kind of go and like say here's two bucks and who else do we have here, 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 STEM innovation who made the eyes on camera, he saw my research previously and at this new company he doesn't want to do it the wrong way, so we get really cynical about companies not giving a shit but I had a little bit of a shock when I was a student, I was in a search group and people were saying that there are companies that are trying to work hard on security and we should support them so amazing researchers and Steve Ridley, Don Bailey, NCC group as a whole and then bug crowd providing their platform pro bono to us a private communication between them and the best part about all of this is all 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, you know, 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 this space and we're going to have researchers looking at pre- production hardware doing assessments against them, getting them bugs and actually making these devices better before they go into people's hands rather than after. But again, they'll be at DEF CON hopefully next year talking to you about some of the stuff they broke because that's part of the deal. And in terms of timeline, we just started this up in February at Beeside 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 like, oh yeah, 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 Pinocchio to two of our researchers. So that's kind of our first line in the sand that hey, we accomplished something we were trying to accomplish. And we have a lot more coming out for the next few months and we'll be bringing more researchers on. We have contact details at the end if you want to look at some of that. But, you know, Pinocchio's got the hardware bug crowds set up 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 do bugs have to get fixed, when are we going to drop bugs. And just some of the stuff that any kind of coordinated disclosure goes through when you do this sort of process. And we're growing. It's not about, again, like it's not about having the most people on our website. 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 security research is, how it works, why people do it, why we're at DEF CON in the first place, right? 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 race it entirely. And don't be afraid to actually reach out to people. And vice versa, don't be afraid to, you know, we encourage collaboration. We want people to want to do this. We want this to be a community effort so we can actually have an impact. And 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 and it gets, you know, gets us visibility and gets them resources. So of course we did have some aggressive goals initially but we stepped back and kind of just, you know, made it a little more comfortable. We doubled the timeline basically. And since these people are, a lot of the researchers are doing this, you know, pro bono, they're doing this, of course they get the added benefit of maybe business but they're doing it for us pro bono, they're pretty busy. They have day jobs, so do we. So this is also us, you know, 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's kind of on the same page and that, you know, everyone's going to be able to relax into this. And then measured successes and milestones. I mean, so far we've done pretty well and at least hitting some pretty significant milestones. They might not seem significant to a lot of people or in the grand scheme of things but it's definitely accelerating us toward where we want to be. So IoT is still malleable enough. This is still a nascent enough space that we can actually have an impact versus some other spaces like, you know, web security has been solved or some shit but, you know, we're not having to like kind of shoehorn all these fixes into everything else. IoT, we can still kind of, we can actually kind of make a difference now before it becomes, you know, catastrophic. This could also help consumers make better decisions as well if they see not really so much an underwriters laboratory type thing but maybe something similar. It would at least give consumers a sort of yardstick to say, oh, well, this has been vetted, you know, this vendor clearly cares and people can kind of decide with their wallets, right? So we figured that if nothing else in this, you know, goes completely haywire. We at least helped a few vendors. We at least got some researchers to do some cool stuff and at the end of the day that, you know, that's not bad. So the site is build at secure.ly. You can also reach, there's a mailing list which I think we actually didn't mention. The mailing list, the thing about that is we have both our vendors, our partners and the researchers all on the same mailing list. So there's no siloization of everyone. Like, you know, we'll talk bad about this vendor over here. It's created a very nice open communication medium where if there's a question, somebody says oh, I'm going to be deploying firmware XYZ soon. Does anyone want to help me test it? That happens just universally. There's no siloization whatsoever. The Twitter account is at build at secure.ly. And of course, Mark and I can be reached at these two, you know, duo email addresses and you can stalk us on Twitter. So with that I think we have a couple minutes left if there are any questions. Otherwise, you can meet us in the chill out lounge afterwards. And thanks. Thanks, guys.