Dale mentioned this Digital Munition blog post, which talks about hacking a Control4 home automation controller. Incidentally, I used Control4 gear for my first testing of KillerBee and ZigBee analysis but we’ll save that for a later discussion. The Digital Munition post combined with some other recent work has me thinking about increased pervasiveness of embedded devices, particularly as it relates to Smart Grid efforts, and even more particularly as it relates to the use of those devices as a platform for launching upstream attacks.
If some of the Smart Grid efforts reach their potential in terms of scale, there are a lot of opportunities for launching attacks from distributed devices into the servers and networks that are required to manage it all (AMI Headend, Distribution Management, Outage Management, Billing, etc.). Control4 doesn’t necessarily fall into the category of a device that has upstream connectivity but there are some parallels about the device design that I think are going to present some security challenges for those that do need to communicate back to the local utility company. Here they are:
1.) User access to hardware
In case you are not aware, there is an InfoSec tenant that basically says, “If you have access to the hardware, you can almost always own and control the device and the data”. A good example of this is Travis Goodspeed’s work with extracting hardware-based ZigBee keys. When distributed devices are in customer homes or public places, this tenant will be a good one to remember. If I own one smart device and its connectivity, what can I access in the local mesh network? What can I access upstream?
2.) Use of standard hardware
So maybe not everyone is going to use GoodFET to extract data crossing a bus at a circuit board level. That’s OK, you can just use the standard interfaces that we’re all familiar with like USB. Using standard hardware is attractive from a financial perspective, but it also makes it easier to attack. What happens when I connect my laptop to the USB port on my smart meter or other device? I love this line from the Digital Munition blog “Eventually I simply took the device apart and mounted the USB drive that I found inside”.
3.) Use of standard operating system software
We’re seeing a lot of standard operating systems on these devices — not just your same old stripped-down, embedded types but more Linux and Windows-based devices. This means more general knowledge available and more utilities built right in. Again from the Digital Munition blog, “Adding a line to the passwd file was easy enough”. If that was easy enough, so will using standard utilities to map the network, then uploading some utilities of my own, and then turning the device into a proxy so I can take advantage of its connectivity and use my laptop to launch a full attack upstream.
4.) Little or no software-level security hardening
It’s a battle we’ve fought for a long time in the control system space – open by default configuration vs. secure by default. Unauthenticated remote firmware upload, default passwords, no attention to least privilege, and the list goes on. Combined with the other items in this list, it just makes things too easy for an attacker.
So what does all this mean? It’s important to be aware of the risks involved with pushing out technology and connectivity to areas outside your physical control. It means you need to treat these distributed networks and devices as hostile like the Internet. That should at least translate into good firewall design and monitoring. Assuming they do it and do it well, look at the DMZ designs and IDS implementations your corporate IT uses for Internet services like online bill pay. Make sure you are using at least that level of diligence and building security requirements into these projects and the procurement process.