Slashdot Mirror
Black Hat Talks To Outline Attacks On Home Automation Systems
colinneagle writes "If you use the Z-Wave wireless protocol for home automation then you might prepare to have your warm, fuzzy, happiness bubble burst; there will be several presentations about attacking the automated house at the upcoming Las Vegas hackers' conferences Black Hat USA 2013 and Def Con 21. For example, CEDIA IT Task force member Bjorn Jensen said, 'Today, I could scan for open ports on the Web used by a known control system, find them, get in and wreak havoc on somebody's home. I could turn off lights, mess with HVAC systems, blow speakers, unlock doors, disarm alarm systems and worse.' Among other things, the hacking Z-Wave synopsis adds, 'Zigbee and Z-wave wireless communication protocols are the most common used RF technology in home automation systems...An open source implementation of the Z-wave protocol stack, openzwave, is available but it does not support the encryption part as of yet. Our talk will show how the Z-Wave protocol can be subjected to attacks.'"
My cable company keeps sending me crap for home monitoring whereby you can control your alarm from your smartphone -- and I wouldn't trust that.
My energy company wants me to sign up for a smart thermostat where they can remotely change my temperature if they decide I should be using less energy -- and I sure as hell wouldn't want that.
Opening up access to these things from outside of your home sounds like it might be convenient, but it's a gaping security hold waiting to happen.
No way, no how would I want things like this. Because I have zero confidence that the people writing this give a shit about my security, just getting a product to market.
Lost at C:>. Found at C.
Because it's shiny.
They're not thinking of security, they're thinking "ZOMG, I can switch off teh lights from teh phone".
Nobody thinks that if there's a way for you to remotely control your home, there's a threat vector for someone else to remotely control your home.
Lost at C:>. Found at C.
Comcast is pushing their home automation/security system that ties into their servers.
Part of the advertising is to watch your kids come home from school and turn on the lights for them.
Now that is scary. Letting any idiot know when your kids are home alone.
i thought once I was found, but it was only a dream.
Connecting HA gear to the internet in a way that's both secure and works (especially with the manufacturer's own Android/iOS/ActiveX software) is actually pretty hard to do with real-world equipment, mainly because the overwhelming majority of stuff that's affordable (and shocking amounts of stuff that's supposedly top of the line) gets implemented with little more than symbolic security that's the equivalent of a TSA lock.
One of the most common ways embedded hardware gets connected to the Internet is via Wiznet w5100 modules (and variants). Basically, the w5100 is a bridge between UDP and a serial port. Data arrives on some port, and gets blindly sent to the serial port. Data comes in through the serial port, and gets sprayed out via UDP. There's some minimal logic that implements a half-assed 8-character "password" that -- at best -- might be equivalent to a 64-bit random number IF you hacked their setup utility to accept arbitrary byte values instead of just letters and digits (effectively turning it into more like a 40-bit random value). Keep in mind that there's no rate-limiting or lockout, so the only limiting factor at which someone can try to bruteforce you is your internet connection.
A few months ago, I estimated that an attacker who knows you have something specific behind a Wiznet interface that responds to a known command with a known response would take about 1-3 months to bruteforce if they kept the rate low enough to not noticeably affect your internet access or attract undue attention, and less than a weekend if they just all-out hammered you as fast as they could, trying only 8-character alphanumeric values and starting with those that begin with digits & plaintext English words.
That itself isn't necessarily the problem per se... there's nothing that says you can't encrypt the data being sent via UDP and in response, and implement stronger authentication and authorization checks on your own... except nothing actually DOES.
99.9% of the time, you have a circuit with almost no real network-level security that was developed with the assumption that someone with physical access to the serial port has already demonstrated some level of authorization, connected to a serial-ethernet bridge whose "security" is almost a complete sham, with predictable results: disaster.
Short answer: if you want to connect consumer gear over the internet, buy a Raspberry Pi, and use it as a middleware gateway device that accepts incoming connections via https, enforces its own strong authentication, passes no raw commands directly between the internet and embedded device, or at least requires that any raw value be signed with a pinned certificate. Then connect THAT to the embedded device through the Wiznet serial-ethernet adapter. Never, ever, EVER expose a serial port directly to the internet through a serial-ethernet adapter... I can almost guarantee that any such adapter that ISN'T built around a RPi and costs less than $200 is inherently insecure and a hack attack waiting to happen.
If you absolutely MUST expose some consumer-grade device with insecure ethernet-serial interface over the internet, at least hide it behind a router running OpenWRT/Tomato/dd-WRT and use something like port knocking and IP range-blocking to temporarily unblock access to your mobile device's current IP address for short periods of time when you intentionally enable it (keeping in mind that with many wireless providers, switching between HSPA/EVDO and LTE will radically change your IP address, and your address might change from request to request ANYWAY.
Mi Casa Verde makes the Vera home automation system. It's built on OpenWRT. For security systems it supports several different brands of Z-wave wireless sensors. It can control lights, locks, alarms, blinds, temperature, IP cameras, etc. It speaks Z-wave via a built in radio, but can also control Insteon and other home automation systems. And it's meant to be hacked and extended. You can even install a growl plugin for Vera, and then a growl notification app on your cell phone, if you want to be alerted by it. Nothing requires a monthly fee.
They offer a free service for remote access, but you certainly don't need them to do it for you. (All their service does is eliminate hassles with DNS and firewalls by serving as a proxy.) Some people simply poke a hole in their firewall allowing them to SSL directly into it.
The company is really good with their customers.
My only complaint is that no matter what they say, it still takes technical ability to set it up. It's not what I'd call plug-and-play ready to sell at Home Depot. No home automation system has reached that level of maturity yet.
John
> For criminy's sake. TLS is *there*. It's *free*. Why the hell aren't these guys using it??
Quite a few embedded home automation devices are built around 8-bit MCUs like the Atmel AVR family. You'd be massively challenged to get even a minimal subset of TCP/IP working with a chip like the Microchip ENC28J60 ethernet controller and an Atmel Atmega 128. SSL/TLS? ROFLMAO. It's not happening. You could probably kludge something with more chips and sram, but by that point, you'd be better off throwing in the towel and buying a RPi board.
Pre-RPi, ARM boards with additional RAM were pretty expensive (at least $80-150), so a $10 AVR plus $15 Wiznet board represented a huge cost savings. Now that you can get a RPi for $30, it's kind of stupid to keep building controllers with 8-bit MCUs and ethernet-serial bridge boards... but a year ago, the RPi basically didn't exist, and even 6 months ago, it was pretty expensive once you factored in rape-level shipping charges to the US. Genuinely cheap ARM chips with external RAM are game-changing for anything that involves communication over the internet.
For the morbidly-curious, here's a book that might give you somewhat of an idea of what USED to be involved with interfacing a microcontroller with a network over Ethernet pre-Wiznet w5100, and give the benefit of context to understand why that module (and its descendants) have been so wildly popular among embedded developers working with 8-bit microcontrollers.
http://www.amazon.com/Networking-Internetworking-Microcontrollers-Fred-Eady/dp/0750676981/ref=wl_it_dp_o_pC_S_nC?ie=UTF8&colid=75OKCKDXZ6YI&coliid=I2PABIRD1YO96X
The Microchip ENC28J60 falls somewhere between the older chips written about in that book and a "plug & play" module like the W5100. With the older chips, you were lucky to hack together your own personal networking protocol that (barely) managed to coexist on the same wire as NETBIOS, TCP/IP, and IPX/SPX. The ENC28J60 does for networking kind of what the ATI Rage Theater chipset did for MPEG-2 video compression... it accelerates and automates some of the grunt work of interacting with signals on the cable so you can pay attention to bigger details, like your actual protocol. I've never personally used it, but from what I've read, ENC28J60 TCP/IP is "do-able, but with a few cautions and limits". By comparison, the W5100 is pure black magic... to your embedded app, it turns the Internet and/or your local LAN into a big virtual serial cable.
When the w5100 came out ~5-6 years ago, embedded developers were LITERALLY dancing in the streets, because it was dirt cheap and "just worked". Security wasn't even a CONSIDERATION until 2-3 years later, when the consequences of exposing the serial ports of devices with no security besides physical access to the port started to really sink in... and the devices themselves had almost no serial-port security, because pre-Wiznet, an ethernet-serial adapter cost somewhere between $250 and $400... at RESELLER prices. Pre-w5100, serial ports just plain didn't get exposed to the internet, because the adapters to do it were too expensive to even contemplate.