I recently picked up a GE D20 RTU from eBay. You might remember seeing one of these things reversed in Project Basecamp
. I had to send back the Basecamp RTU back to the owner, so it was time to get one of my own.
The eBay unit was intriguing because it is a D20ME, the predecessor model to the one in Basecamp (that was a 'D20ME2'). Another cool thing about it was that it had a 10.0.0.0/8 ip
address sticker in the photo. Could it be a still-configured RTU? I
shelled out the money to find out.
Functionally it's equivalent (same amount of ram, same amount of flash, and even Ethernet), just a previous generation board. On this unit, the mainboard had 'bluewire' all over it, whereas the Basecamp model had a clean mainboard, and only bluewire kludges on the I/O modules. I'm really surprised to see such hardware schlock on critical infrastructure.
I built a serial cable to interface with the system, wired up the power supply, and booted it up. The default westronic/rd password was in use. So I snarfed the NVRAM (some ultra low voltage sram, luckily the batteries were still good). The D20 configuration is a binary tree of application configs. If you took my 'Hacking PLCs training class' you got a quick introduction to the configuration format. I wrote a parser for the file previously. This time, I got an opportunity to really use my parser to extract more than just the usernames and passwords.
The RTU contained a complete configuration. This might not seem like a big deal, but consider this: GE D20 configurations contain 'tag data' similar to an OPC server. Tag data, if you're new to control systems, provide some human meaningful mapping between I/O for the control protocol (Modbus in this case). Tag data teaches you what you can control using an unauthenticated industrial protocol. While it's possible for a hacker to mess up a control system without this data, it is far easier to target an attack, and to hide it from operators, with this data. With tags, we know what the operators are going to be looking at on their HMI, and what they can control.
So this D20 was configured to monitor and operate a circuit breaker on a 360kV step-up transformer at a power plant owned by the Shell natural gas company. The RTU comment fields for logic contain upgrade notes, so I get the names of two engineers (Shell employees, one I could find on the Internet, the other has no internet presence). It also contains the IP addresses of Shell's Emerson Delta V DCS used to control the turbines in the power plant. Probably the RTU would report to the DCS that a breaker operation is underway, so that the control system can more quickly throttle down the generators and maintain their rotational speed (but better to ask a generator guru here, I'm mostly guessing).
Some IP addresses (for the DCS) are 10.0.0.0/8 addresses, but other systems which this D20 communicates with are IANA assigned addresses owned by Shell oil company. Probably these are hosts in a DMZ, but possibly they're on Shell's corporate network. ICMP doesn't reach these systems, so I would probably need access to Shell's corporate network at a minimum to touch them.
The logs in the RTU show its service dates. It was placed into service about six years ago and removed from service only two months ago. The d20 that was shipped to me was 'cut' from service -- the power cables to the power supply were literally cut off. Normally the D20 uses a fancy power board with fuses and a few serial ports, but luckily it does run just by splicing in a standard 120V power cable here in the US. All of the extra boards were cut off and removed, so it booted into fail state (ladder logic and other applications failed because the IO they rely on could not be contacted).
The RTU comes from the Tenaska Gateway generating station,
which produces nearly 1GW of electricity for Texas. That makes it pretty significant. It's interesting to get so much data from the RTU. Control systems tend not to change much. Since the station is only about 12 years old, it's unclear if the control points would change with the replacement of the RTUs. The working theory is that Shell tossed these RTUs to replace with something different, perhaps the now-released GE D20MX?
Numerous security contact points at Shell did not return phone calls nor emails about the RTU find. I would like to thank EnergySec/NESCO for helping reach out to Shell, and to Digital Bond for helping with some power plant analysis.
I hope that this analysis causes at least a little stir -- I've said this before
but it bears repeating: embedded controllers contain a ton of information about your process when you remove them from service. Unfortunately I've purchased quite a lot of still-configured equipment, parted ways with a lot of it (sent back to the original owner). Shell in this case never got in touch with me about getting the equipment back.
Controllers have no security. Be sure to properly dispose of your equipment. When in doubt, send it back to the manufacturer -- they'll know how to properly wipe the controller before scrapping it or selling as refurbished.
And if you're an attacker/terrrormonger, buying used equipment is a great way to learn about potential targets. The goal of a terror campaign is of course to target whatever you can...buying some preprogrammed equipment makes sense: choose your target based on what data is available and what opportunities present themselves.
Keep an eye out on the IOActive blog
, where I'll be posting a howto on analyzing used industrial equipment. Also keep an eye out for some tools releases in the coming weeks. At the S4 conference there should be some fun ICS hacking tools coming out.