Because media wont be able to cover all the technical details, and also I don’t want to engage in responding to comments on different news sites, I thought I’d rather share my methodology here. Hopefully you’ll take the time to read this story on how I tried to hack this smart house, and perhaps pick up on some great tips on securing your own. I also have to take some measures in the text below in order to protect the house-owner’s information. We have agreed that I must not be sharing any sensitive information.
Now, accessing this house from the Internett proved to be hard. I did several attempts in breaking into the solutions hosted at the IP address of the target house, however to my despair, none of the attacks gave me any good foothold into the network. I found one particular vulnerability I could use for potential remote code execution, but due to scope limitations I could not proceed here, and I notified the house-owner of the problems. I even tried to send phishing emails to the house-owner in order to compromise his credentials for logging in over VPN, but no to avail, this guy was tight! Well done! It turned out that the house-owner was quite above average when it came to being concerned and pro-active with security.
Now to the next step of the hack. Can I get access to the houses’ IoT if I am in the vicinity of the house? I traveled to Stavanger a long with a film team from NRK to do one of the most exciting “live demos” I’ve ever done. Those that know me know that I rarely put down a challenge to do some live hacking, and in this case I thought of what a could project this would be, to have the privilege to try hack the smartest house of all the smart houses. Cool! Arriving on-site, I am sitting in a white van on the parking lot, starting up my attempts to break into the house. My gut-feeling was that I had to be able to break into the LAN if I were to be able to demonstrate some interesting demos of what could be technically possible from an attackers perspective. I did bring an SDR just in case I wanted to try direct attacks against the different devices, but my gut feeling guided me into just attacking the LAN for maximum effect.
Attacking a wireless LAN is most typically done by sniffing for packets, then sending a de-auth request to one of the communicating parties, spoofing to be the Access Point. This will normally cause the network device, e.g. a mobile phone, to automatically reconnect, and thus authenticate, allowing attackers to capture the precious 4-way handshake. This handshake could be cracked, but how quickly?? This all depends on the strength of the password, and how much time and resources the attacker have available. I of course fired up Hashcat and let my GPU try solve the problem, but this would be down to sheer luck, and the strength of my wordlists. What if the house-owner had a really strong password? Then the entire day, the trip to Stavanger, the production of the show for the consumers, it would all be to waste. So I decided to use a HID attack on one of the computers of the home-owner. No password was given to me here, what so ever, but I simply plugged in a USB device for 10 seconds in one of the devices, and I simply stole the wireless key that way. Getting access to someones Wireless LAN should not be your last resort of defense, instead it should just be one of the barriers you expect to fail, and thus having other barriers of protection once they gain access. Could you protect your Wireless LAN against password cracking? Absolutely! And that’s also kind of the point of this TV show 😉
Once onto the LAN I was immediately baffled about the huge number of devices. As an attacker, I consider this as a good thing as it adds to the attack surface. Where do I start though? I fired up Nmap a long side with Eyewitness and had them scan the network, at the same time screenshotting all HTTP, HTTPS, VNC and RDP services. This allowed me to more quickly navigate the network. I found a conference solution that allowed me to reconfigure it. Through some of the reconfiguration menus I made the solution bring up already set passwords, and I made the solution reveal those passwords to me, adding to my dossier of important information for later. Additionally the lawn mower had a similar vulnerability which allowed me to view its clear-text password. This however is no good, as I wanted more, if not full access to the home, so I had to search more.
Eventually I stumped upon a HomeSeer application. I’ve already studied some of the technology present in smart-homes today, and I knew HomeSeer was one of the controllers which could be used to administer the house. It seemed like a rather complex application, one which I’d never worked with before. Nevertheless, I thought that this is the place I need to be, so I started to try penetrate it’s defenses. After a while I found a zero-day, authentication bypass, vulnerability in the HomeSeer controller, allowing me to remotely administer it with a Linux Shell. A side note that I didn’t think was necessary to mention, but apparently is, a zero-day vulnerability is a vulnerability that has no patch by the vendors, and in this case the vulnerability was not disclosed anywhere for me to find the information. This vulnerability was discovered by me, not by Googling for vulnerabilities. We’re currently undergoing responsible disclosure with the HomeSeer folks.
Jackpot, I thought, but as I started navigating the HomeSeer device, learning about it and how to control different devices, however it seemed that it was only able to see a selected number of devices, not as many as I’d previously seen in my Nmap scan. I wonder why, I thought to myself. Maybe I am not using the product correctly, or maybe there’s a menu option somewhere to display all the things. I didn’t know. Keep in mind, we’re running on a very short deadline here. Not a lot of time to make up for some good demos and hacks, so I really had to be efficient.
I eventually decided to go ask the home-owner to see how he reacted to me getting access to the controller, and getting my little Linux shell working. He was quite surprised, but not long after he goes “Aha! You’re at my test HomeSeer. Not my production HomeSeer!”. Whut? There’s another controller? Yes! Apparently there was two, but where was the other one? I reviewed my Nmap’s and Eyewitness scans, but to no avail did it show any similar boxes than the one I had just broken into. Why? I decided to ask again… The reason was simple, the other controller was .htaccess protected. It had a web-server based password before even getting into the controller application, so no wonder I didn’t see the application anywhere. I just thought this .htaccess prompt was “just another IoT”. Now, this is obviously the place I need to break into, so I start password guessing with multiple threads running simultaneously. Some threads are running password guessing using dictionary lists, and some were simply word mangling the existing passwords I had already stolen, i.e. going through numbers 0000-9999 at the end of each clear-text password, doing 1337-speak replacement and so on. Nothing worked!
Time is really becoming an issue by this point. We’re bound to leave soon, and this is the place where I wanted to demo, so after a chat, we decided to share this password to allow for all the cool demos to take place. In hindsight, this was unnecessary, and frankly I’m somewhat surprised to see all the haters saying “fake news” because a password was shared. Does this void the risk for all other smart-house owners? Have I not already broken into several of the devices, and proved that the brain itself, the controller, could also be broken into using 0-day exploits? Anyways, as I said, in hindsight it was unnecessary to share this password. I should’ve instead done a simple and clean ARP Cache Poisoning attack, and then telling the home-owner to authenticate the product, thus opening up for sniffing possibilities of the username and password. Other vectors could involve hacking more devices, finding a device which shares the password of the .htaccess, or finding a vulnerability or other application on the web-server, which could allow me to read or modify the .htaccess.
The previous password was the only password that was shared with me in the engagement, and honestly, the reason for doing so is to prove the consequences of someone gaining access to your smart-home devices. Why my fellow geeks and nerds are disliking this approach, I have no idea, but I challenge you to open up your perspectives and see the threat of our consumers. Not the individual threat of a hard-core smart-house geek with an extra interest for security. No, try to see how this could affect others. Our friends, family, neighbours, those which are getting smart-house features as “part of the package”, and have no idea how to run or operate these things.
That’s my 2-cents. It was a fun live-demo, that’s all. Not showing off the length of your e-peen.