 So title of this talk is home invasion 2.0. And we're going to be talking about smart home technologies. So we envision home invasion 1.0 as a guy breaking in a window and stealing your TV, you know, the standard sort of stuff. And home invasion 2.0 is what happens when you hook all sorts of things up to the Internet that you really shouldn't. Or that you really should think about a lot more. So before we start into talking about all this stuff, I would like to take a moment to introduce ourselves and explain just very briefly why you are listening to us and not some guy trying to sell you water on the sidewalk about these devices. So my name is Daniel Crowley. I take a unicorn furnace. And I am a managing consultant on the application security services team of trust waves spider labs division. My name is Jennifer Savage. I am a software engineer and a security contact for tabbed out. We make a mobile app that lets you pay your bar tab with your cell phone. So a bit of a hard space for security. I'm David Bryan, senior security consultant with trust wave spider labs penetration tester. So why are we here? We're here to talk about smart home technologies. What I mean when I say smart home technology is various devices in your home that are not traditional network connected devices like laptops and smart phones and printers and scanners and things like that. More odd non-traditional devices. So we're going to talk about some of what those are in a moment. Is anybody here like science fiction? Show of hands? Excellent. So my favorite kind of science fiction is dystopian science fiction. And for those of you not familiar with the term dystopian science fiction is about a world which has some sort of technology that has gone awry. So some dystopian science fiction is very serious like 1984. Although that's maybe not exactly science fiction. But some of them are very, very tongue in cheek. There's a movie that we heard about from several people where it's like a smart home and it starts attacking and trying to kill the people in it. Like there's a scene with a garbage disposal or something. Anyway, we have yet to see it and if anybody knows the name of the movie I would love to know that because I really want to watch it now. But anyway, what is it? It was an iRobot? Fair enough. Okay. I didn't want to see that because it looked like they completely ignored Asimov's book. But anyway. So anyway, usually dystopian fiction tries to serve as a warning for the future. Because science fiction so often becomes science fact. All of you probably have cell phones in your pocket. If you're smart they don't have the white fire Bluetooth enabled. And if you have a CDMA phone maybe here it's smart to just turn it off entirely. But anyway. So that was originally from the Star Trek communicator. So pretty bad ass, right? But science fiction becomes science fact and dystopian science fiction usually serves as a warning to people who would make these technologies as to how they need to, the considerations that they need to take into account when making these devices. And unfortunately the push to be first to market with a device with some new technology often gets in the way of listening to these warnings, making the important considerations. And this seems to be the case based on our research. So we took a look at a subset of the devices out there which connect to a network in your home. We're not going to be discussing every technology because there are a lot of them. And some notable ones that we did not include in this talk. There is an Android powered oven. Which, yeah. Because there have never been any problems with Android and an oven is perfectly safe. Mom, I jail break the oven. So smart TVs. There are some talks at Black Hat about smart TVs which were kind of interesting. IP security cameras. But this is just a sample of these things. But we, you know, and it's wide open. There doesn't seem to have been a lot of review on this stuff. So maybe hopefully this talk will inspire you to go out and take a look at smart home technologies, if any, that you have in your home or maybe your friend's home. So right now on the market, like Dan was saying, we have locks, thermostats, fridges, toilets, lights and toys. But in the future, we're going to have entire smart cities. They're building one right now in South Korea. It's called Songdo. Cisco is involved in the networking there. But they're describing it as a place where you can walk up to a window. The window is actually a screen that you can interact with. You can call home, talk to your kids. The city will schedule your day for you. It will schedule buses leaving and arriving and everything. And I would love to go test that. I don't know about the rest of you, but I think it's an absolutely awesome place to go and hack if we could just get permission to do that, right? So I'm going to talk today about a toy that was in my daughter's room. I have a daughter whose name is Ada. She's almost two. She'll be two in a month. And this is a toy I bought when I was a very busy mom, still breastfeeding, not getting enough sleep. And I wanted to be able to go into the other room and check on her and do it through my laptop and take a nap and make sure she was still sleeping her crib and whatnot. And it has a camera in it and a microphone, so you can do that with this. It also has a speaker. You can program it to wake you up in the morning, tell you when it's lunchtime, all kinds of stuff. It has an RFID reader and little RFID toys that she can run up to the bunny and hold it up to the bunny. Read the RFID, do whatever you program it to do through their online interface. Additionally, it has a USB port in the pack, a little bunny tail USB, and this is how you program it to connect to your Wi-Fi network. It occurred to me when I was no longer asleep deprived mother that I needed to test the security of this device that was in my daughter's room. And I found a lot of problems with it. So the first one is that in order to set up the Wi-Fi network, you enter your SSID and password into their web interface. It's transmitted, completely unencrypted, no SSL to their servers. The API calls that are used in order to communicate between, for instance, the iPhone app, the carrot servers and the carrots itself. It goes from the interface to the carrot servers to the carrots. Those API calls are completely unencrypted in SSL as well. So you can eavesdrop on them. And the setup package that you download, you download again over an unencrypted connection. There's code signing. So they did something right here. But the code signing, there's a way of bypassing it using a technique I call Python module hijacking. It's a little known attack and I'll teach it to you today. So what you're looking at here is a request made through the carrots API for the video stream from the bunny. Has an authentication token. That's one time use. Doesn't make sure that it's always being consumed by the same IP address. So you can just literally copy and paste it out of burp suite for instance or anything else and put it into your web browser and spy on the video stream. That was the first major problem. I would do things like go to the coffee shop, open up the iPhone app and check on my daughter and make sure she's still asleep, you know. And I would use the coffee shop wireless network without having tested to make sure that this connection was over SSL. So if you're a parent, you might be really scared to hear that that was happening. I know it freaked me out. So here's an example of viewing the video stream just through the web browser. So if you happen to have a connection between the carrot servers and the ability to eavesdrop on a connection between the carrot servers and the person downloading the Wi-Fi setup script from the carrot servers in order to set up their bunny and you can man in the middle of that connection, you can replace the download of the setup script with your own setup script and in that version of the setup script, you can get around the code signing using something called Python module hijacking. So if you've ever done DLL hijacking or LD preload vulnerability, anything like that, basically Python has something called the Python path. And your Python path is a list of places that Python will look for your modules that you import. So the first place it always looks is the same directory that the script is in. This is a problem because as an attacker, I can place a Python file that is the same name as one of the modules used by your script in the same directory as your script if I have the ability to do that. And your script when it runs will run under the same permission level, my module. So I can get it to run my code. So what's nice about this is that the setup script is signed using GPG and they check the signature before they run it. But this doesn't actually, this technique doesn't require modifying the code as Jen said. Right. So the code signing doesn't check the modules. So that's why this gets us around the code signing. Now, interestingly enough, the auto run Wi-Fi script actually uses a simple JSON dot, it imports simple JSON. So, and then it never uses it anywhere in the script. It never uses anything from that library in the script. I don't know why it imports it. But we were able to just create a simple JSON dot pi file that did what we wanted and throw it in the same directory as the setup script we downloaded and we had a bunny break. So just to recap, an attacker could man in the middle the insecure connection to the carrot server, replace the user's download with their malicious version, use a vulnerability to make the carrots run their code, that's the module hijack we just went over and potentially have a bunny botnet on their hands. There's also a potential for like a tag and release type attack where you get a carrot, buy it from carrots or from Amazon, eBay, whatever. Just buy a whole bunch of these things. Root all of them because when you go through the setup process a second time, not everything changes. It's not like you wipe the whole thing when you go through the setup process. So you could own a whole bunch of these things and then sell them on eBay or return them or something like that. So you, again, bunny botnet. All right, so let's, I think that's a slower method, but okay. So we're going to real quick display a video in which we eavesdrop on the video camera on the carrots. We cannot hear this. Why can't we hear this? Do you guys have the board turned up? Is the board turned up for the audio input on the laptop? Good. All right. Carrots app for the iPhone, the carrots controller app. And I'm going to move the carrots ears using the app. This will send a request via the carrots API to the carrot server. And then the ears respond by moving. Now I'm happened to be eavesdropping on that request over here. And if I look at the request itself, I can grab from it an authentication token. It's a one-time use token. But what I found is that I can reuse this actually and use it to capture video instead. So I'm going to grab the interactive ID and the one-time use token, copy it, go over here to my web browser, paste it in and change the action. So here it says the action is the ear moving. We're going to change the action to webcam. And let's see it needs to be webcam action equals video. Enter. And now on the machine that I'm using to eavesdrop on the carrots, I get a handy dandy webcam feed. Hi, guys. So this is eavesdropping on the carrot's toys webcam. Suddenly the bunny becomes really creepy, right? I thought it was cute before. My daughter still thinks it's cute. It's cute. And she, we leave it in her room unplugged and she runs up to it and hugs it and stuff. And I'm like, thank God it's unplugged. But I wanted to mention the fact that if you're eavesdropping, there is a start and a stop request that gets sent as part of the API calls. And the token after the stop request gets sent, the token is no longer reusable. However, if you're men in the middle of the connection, you can drop that stop request and instead continually send something called a keep alive request. And then at that point, you just have control over the bunny going forward as long as you maintain your keep alive. So this is a product called the Belkin WiIMO switch. First of all, I'd like to say that Belkin was real cool about all of this. We were going to reach out to Belkin and tell them about what we found. But they actually fixed everything before we could even tell them about it. So good on them for that. And they actually sent you guys. Yeah. Thank you. Yes. And what's more, they came to our black hat talk and they approached us afterwards and they told us, hey, thanks for finding this stuff. By the way, we have a program where if there's people finding security vulnerabilities in our stuff, you know, we can get them products for free so that they can do more testing because they recognize that we're doing free work for them. Yeah. So thank you Belkin. But the Belkin WiIMO switch is kind of an interesting little thing. It's a little box with a plug, a male and female electrical plug. You plug the back end into the wall and plug something into the front end and then whatever you've plugged in, you can turn that on and off from a network using an iPhone application from Belkin. And so the way that this works is over a protocol called UPNP. Has anyone heard of UPNP before? Right. So UPNP was designed for network auto configuration. And as a result, you can't have like zero interaction auto configuration if you have to put in a user name and password. So UPNP as a protocol does not require authentication. It doesn't involve authentication. So that's interesting, right? And so what this means because the interaction is via UPNP is that you can control the functions of this device as long as you're on the same local network as it. So Belkin doesn't have what I would consider a proper fix for this yet. But what they do is in the iPhone app, as soon as you use it for the first time, it tells you hey, just so you know, anybody on the same network as this thing can control it. So be careful where you put it. So it's not a proper fix, but they're at least giving enough information to the user for them to make some security decisions or understand the potential risk that comes with being able to control this without any authentication. But on top of that, in an older version, they had a vulnerable LibUPNP library, which meant remote no off route. So pretty cool stuff. And this is just a little Linux box, it turns out. So you could turn this thing into a point of persistence on the network. And a friend of mine, I was talking to him about this and he was saying this is funny stuff because if you're a forensics dude and you're trying to investigate a breach, you're probably not going to look at this little box on the wall as the source of attacks. And this thing hooks up to your Wi-Fi network so you could do maybe sniffing depending on what kind of card is in there. I haven't honestly found out. But you could at least launch attacks from it if you were to compromise it. So interesting stuff there. And I'd like to show you a little demo here if it works. So the demo gods really hate me. So we're going to talk about the Belkin WiIMO. I'm going to show you how to turn this on and off from your computer. So the WiIMO is an electrical outlet that you can control over the network. And the protocol involved is called UPNP. So Nmap has a nice NSE script called broadcast UPNP info, which tells us all the hosts within multicast range that will respond to UPNP queries. So it gives us the descriptor XML file for each one. So I'm going to take that and feed that to a tool here called UPNP request generator. And so it goes through and enumerates all the devices, services and actions and organizes them into various directories. So we want the basic event service because that has things that we want like set binary state which turns the WiIMO on and off. So we're going to cat set binary state. And the UPNP control just gives us the post request that the UPNP request generator has made. And we're going to give that to Burp repeater so that we can make that request. And I need to change this to either a one or a zero. See it's a boolean here. And we can see by the fact that there's no. All right. So the demo gods really hate me because this box broke like two hours before my black hat presentation. So I went to the backup video demo and it stopped like this last time. I have the video. So let me just. No. No. Okay. All right. We'll skip that. We'll skip that. But just you can turn it off from the network. But we have more demos to show you. So we'll move on to the Zonus bridge. So Zonus is a sound system. And basically this is a little bridge device. All of these speakers connect to. And then your laptop or your mobile phone or anything like that connects to the Zonus bridge. And you can feed it music from the controllers. And it goes out to the speakers all over your house, right? So pretty handy. And there's a really active community of people hacking on their own Zonus and the Zonus forums. It's kind of a fun little community of people. But the issue I have with the Zonus is that it spills all of this information. Excessive information about your controller. So if your personal laptop has all your music on it and you're using that for anything really else other besides controlling the Zonus, all that information is kind of here. I'll just show you. So right here we're looking at a list of network shares on my machine. Their permissions level and UUID and group ID of them. Is this Netstat? Yeah. So Netstat. Why do I need to look at, you know, why is the web interface exposed on the Zonus bridge on my network showing Netstat from my personal machine I installed the controller software on? Why is it doing that? Everybody on my network can see this information. Which one is the process list, I think? This is the process list for my personal machine. I cannot see that. The list of users, I think, from my machine. I have config and who am I? Who am I running as? You get the idea. It's excessive and, you know, it's useful information for an attacker. So we said they were smart toilets out there. You call this one. So there's a toilet called the Lixill Satis, a corporation called Lixill in Japan, of course. Name of the toilet is the Satis and it has an associated Android application which controls this toilet via Bluetooth. And there are several interesting functions on this. You can open and close the lid. You can make it play music. You control the flushing function. There's an air blow dryer from the underneath. There's a bidet. And so you can control all of this from your smart phone. Now, as it turns out, there is actually no authentication within the Android application. We didn't buy a toilet and I would have loved to make a bidet spray on stage, but it's like $6,000. I'm not buying a $6,000 toilet, but we took a look at the Android application and there was no username and password. We took a look at the user manual. There's nothing for setting up a username and password. We looked at diagrams after diagram after diagram of information on the control panel. There's no place to enter anything. There's like no keypad. There's just a series of buttons for basic things like flushing. And also, the app is weird. There's a default Bluetooth pin of 0, 0, 0, 0. And there's like a whole bunch of these. I understand why it's a poo, right, because it's a toilet. And I understand why it's blushing and has arms and legs because it's Japan. But I don't understand the police hat. So this is a poo leesman. And there are several of these poo leesmen and poo leeswomen as well in this Android application in a diary that you, or a log, if you will, of your bathroom activity. The jokes write themselves. They really do. I was trying to figure out a way to slip this particular one in, but I can't, so fuck the poo lees. So anyway, so let's talk about the Insteon Hub. Just for a minute, imagine, though, that you're sitting on the toilet and it starts screaming at you and spraying water up your bum. All right, so the Insteon Hub. I purchased this product back in December of 2012, so just last year. Got it, set it up on my network, installed it, paired it to a bunch of Insteon devices that I have. Insteon is essentially a home control device for home automation. Once I got it set up on my network, installed the iPhone app, then basically turned off the Wi-Fi on my iPhone so that it would take and go to the data network, ran TCP dump on my firewall so that I could capture all the traffic. And what I discovered was very, very disturbing. I discovered, A, it has no encryption, right? So anybody in between me and the Internet, which is a lot of people, could technically see what I'm doing, right? The other thing I discovered was that it has no authentication, right? Out of the box, this thing basically allows you to pull up a web interface and talk to it without setting any sort of authentication on it. So what I did at that point was I emailed support. I'm like, okay, here's this box. I can't put any username or password on this. How do I enable this? And they emailed back saying, oh, you don't have to worry about that, right? You don't have to worry about that because the application, our cloud application takes care of that. No, fail. So the other thing that this device allows you to see is time zone, right? Because you have to be able to set sunrise and sunset so you can turn on devices at night when it's dark out. That was kind of disturbing to me because I also found people tend to name these either with their address or their last name, right? I did a little bit of Google searching after that in January. I went, oh, this is really creepy. The fact that I could go to some city and basically find these devices and control people's home. Now you have to remember that this is also a device that can connect to garage door openers, door locks, alarm systems, motion sensors, surveillance cameras. It's pretty creepy. Now they did fix this in basically what I would call a product recall because in March of this year I got not one email but two emails and then shortly after that they followed up by actually calling me, which I thought was pretty weird. I've never had a vendor call me, right? And I said, oh, I suppose I'll take the new version. So I did grab the new version. And before we were preparing this talk, I think it was about three weeks ago or two weeks ago, I plugged in the device and started looking through it and went, oh, okay. They at least have auth on it, right? But it still lacks SSL. They have hard coded a username and password that's base 64 encoded and it's the Insteon ID of the hub, which is also the last three octets of the MAC address. Anybody see a problem with this? So I thought that was pretty bad. I mean, really what you could do is from the internet because all these systems in order to be able to control them from your iPhone when you're on the road, you have to port forward in that port, right? So from the internet, an attacker could typically or very easily run an attack that runs several days trying 16 million combinations. That's not hard at all. And I actually attempted this with Burp Suite. And it doesn't have any back off, so it kept going. It was like, oh, yeah. Nope. Wrong pin, wrong pin, wrong pin. Anyway. So next we're going to talk about a little green and white box called the Viralight. The Viralight is similar to the Insteon hub. It's another home automation gateway. It just hooks up your ethernet network to your home automation network, whether that's with Z Wave or Insteon or X10 or a mix of these and allows you to control it. So it's a pretty neat device and you can hook it up to a whole bunch of stuff. Again, door locks, garage door openers, motion sensors, carbon monoxide sensors, flood sensors, HVAC controls, all sorts of things. So a lot of stuff hooks up to this. And as it turns out, it's got a lot of problems. So just to start, there's no authentication on the web console by default, which means that any Tom Dick or Harry who can get on your home network can control this thing with a web browser. And it's just as easy as like click, click, click, click. Very, very simple. You can set a username and password on it, but it has several other problems that make this pretty much irrelevant. So, but first let's talk about their authorization, their different user roles. So you have a guest user and an admin user. There's also an information on the user which can see but not control devices. The guest user can control devices but not make permanent changes to the device. And the administrator has full control over the device. So they have different user roles. As a guest user, you can update the firmware. The firmware is not signed. The firmware is in a Squash FS package. So you can just unarchive it, backdoor it, rearchive it and push it to the thing. And then backdoor. Features. Yeah, so the vendor, by the way, said that all of these things were features. Until yesterday when they emailed me after my black cat talk and they really want to work with me now. Yeah, we saw your black cat talk and several news articles and well, we really think we'd like to work with you. There's also a settings backup option which you download an unencrypted archive from this of several configuration files including Etsy Password. And in this embedded version of Linux, Etsy Password also contains the hashes. So there's no shadow. So you get the hashes for all users including root. So you can crack the password and then SSHN is root. You also get the hashes for any password set on the web interface. And the passwords that you set on the local virulite get synced with their third party server for remote access. So owning it locally means you have control over it, over the internet now. So that's lovely. You also have, and this is my personal favorite, a little bit of functionality which allows you to just test some Lua code. So you can run a little bit of Lua code on the device from the web interface as a guest. And can anybody tell me what user account it runs as? Root. So that's lovely. So there's also path traversal. So you can pull any file you want. So you can get, Etsy Password cracked the hashes, SSHN is root. There's cross site request forgery. So you could trick somebody into performing some of the more nasty functions on the web interface using cross site request forgery. And on that note, there's also a UPNP interface which even if you've set a username and password on the web interface doesn't require any authentication. So you can control all these things. And there's actually a run Lua action on the UPNP interface as well. So you just always when you're on the same network have a way to control this thing to run code as root. Just straight up code as root using UPNP. No username and password required even if it's required on the web interface. So if that wasn't bad enough, they also have a vulnerable lib UPNP version. So you can root it that way. There's a server side request forgery problem. So there's a script on the virulite called proxy.sh which basically just takes a URL, visits it, grabs the response and gives it back to you. So you can use this thing as a proxy. And that's not so bad because right, who cares? There's all these other ways to compromise it. And this is not a terribly big deal. It still should be fixed. But it's still not a terribly big deal. Now, the thing is the way the remote access architecture, I got it, the way the remote access architecture works is that each virulite unit makes an SSH connection to a third party server run by the manufacturer. And that reaches out. And so when you do that, you port forward. It SSH's and port forwards on the forwarding server back to each virulite unit. Which means that if you can bypass the firewall on the forwarding server, you can directly access the web interface which of course means onage. So it means that if you can bypass the firewall in some way, you can own every single virulite that's out there. So that's not good because firewalls are completely impenetrable, right guys? But they do at least have a firewall which is good. However, the proxy.sh script that we talked about that allows you to use the virulite as a proxy also appears to exist. Appears and we can't test it because CFA and we don't like prison. We can't test it but there is a script called proxy.sh.php on the forwarding server which takes the URL and guess what it does with it? Same thing as proxy.sh. So there's a good chance that this is just a wrapper around proxy.sh or just a recoding in php. Which means if they have the same vulnerability, then you can talk to proxy.sh.php and say, hey, I want you to go out and fetch 127.001 port whatever. Which means that you can bypass the firewall accessing every virulite. Now that's if they're the same and I'm not sure but it strongly looks like it. So just to summarize, we have three methods of authentication bypass. We have seven methods to gain root. Two attacks are remotely exploitable because you can use the CSRF in conjunction with the UPNP interface in order to launch attacks by getting somebody to click a link. And there's a potential for onage of every single internet connected virulite. So it's a pretty bad scene. And now we're going to do some demonstrations for you starting with the carrots. So Jen? So I just flipped it on here. And I'm going to just show you the bunny break I talked about earlier. So right now it's loading Linux. It's noticing that there's a USB drive in the back and that it contains an auto run wifi script which means it needs to set up the wifi. In a moment it's going to announce that it thinks it's about to set up your wireless connection. And instead it's going to play a script I wrote that plays lol.mp3. I'm going to connect to the internet. We're going to hope that burp sweep doesn't crash on us today. Ready? Ready? All right. So the first one we're going to talk about here is the Insteon hub. So we've got this light up on stage connected to an Insteon device and the Insteon hub basically is connected to our little network here. So this, can everybody see that? Hopefully a little bit better. So this is basically a raw get request, right? There's no video on the screen. Don't unplug it. Don't unplug it. That made burp crash reliably. Can you see it? All right. We're not going to be able to see the... Do you see what's on my screen? No, it's not mirrored. It's not mirrored. It's showing a completely different desktop. All right. Do you see something coming across? Because I have no clue what's on the screen here. Can you try turning the mirroring back on? Yeah, I can do that. All right. So here's the raw request. Hopefully people can see that. Zoom out. All right. Good. So here's the raw get request. Basically what this is doing is sending to this three script. I'm assuming it's some sort of code that's turned on there. This request, which contains this device ID, right? This is the device that's sitting up on stage. So if we say go, it turns the light off. No authentication, right? Yay! We won. All right. I'm going to turn it back on and hand it over to Dan. Thank you, David. Remember that can be connected to your lock. So they say that if you put a gun on the table in act one, you must fire it by act three. We have a lock on this table. We don't have a gun. But we're going to lock and unlock this lock. So here's the lock. Locked. And I can send a UPNP request here. And you'll note that there's no username password or anything in here. And so I can hit go. And this changes the state of the lock. This is through the vera. Yeah. Thank you. Now I have one more trick and I'm going to need a volunteer from the audience. Great. Thank you, monkey. For those of you who don't know this, this is Vis. Thank you for helping us, Vis. What I'd like you to do is choose a pin, any pin. Let us know what it is and try to open the lock with that pin. Okay. One, yep. No. So what happens when you put in a pin that doesn't do anything like two, three, five, five? Nothing. Nothing happens. So what I'm going to do here is add an additional pin. So you said two, three, five, five? Two, three, five, five. So I hit go. And we'll give it a second or two to sync up with the lock there. And what I want you to do is go ahead and press the same pin, press two, three, five, five. Let's try this again. All right. That does it. That's all our demonstrations. I hope you enjoyed the show. Please tip your waitresses. One quick thing. Conclusion. Basically all these devices are internet connected and none of these manufacturers are doing the due diligence to put security into it. That's a pretty bad thing, right? Welcome to doing all right though. So thank you.