With the previous vigilante article answering the why of Project Basecamp, let’s get into what was found. This will take a while, and the full content will make its way onto the Basecamp research page on digitalbond.com and in the S4 Proceedings e-book.
The GE D20ME (worked on by Reid Wightman) faired the worst in Basecamp, and this is an extremely popular PLC in electric sector. There are numerous vulnerabilities and bugs that can either crash it or let an attacker take complete control. Let’s start with the two Metasploit modules that have been released via Rapid7 for the GE D20ME.
- d20pass module – the complete configuration of the D20 is downloaded from the TFTP server, including the usernames and passwords. The username and passwords are displayed and then stored in the Metasploit database for future use.
- d20tftpdb module – This module demonstrates what Reid calls an asynchronous command line. The D20 has a “feature” where you can TFTP a text file with a set of commands to command.log — commands such as edit arbitrary memory, list processes, debug processes, see where in memory processes live, … The D20 will run the commands and write the results to response.log. Since it is TFTP there is no authentication. The Metasploit module automates all this so it appears you have a command line. After a command is entered, the module creates the file, sends it to the D20 and reads the response. (Rapid7 Note: this module is currently still in the unstable Metasploit branch pending a little more QA work on getting this, pretty unique, command and channel all nice and automated.)
These are examples of “Insecure by Design”. They are features intentionally built into the product. But when you combine these two features you have a very scary and dangerous situation. An attacker can download the entire configuration, study it, determine what series of commands he wants to run to alter or crash the process, and then TFTP that set of commands to the device at a time of his choosing.
In his Basecamp presentation Reid went into a number of buffer overflows that could be turned into exploits that run arbitrary code, but it probably isn’t worth the trouble.
The bigger issue with the code quality is the fragility of the device. It is so easy to crash this device through fuzzing or other testing. Reid had one crash that took 50 hours to recover from despite his precautions and experience.
The GE D20ME is so old that, in our opinion, it is not worth spending significant effort fixing it. It should have replaced with a newer, supportable, robust and secure device shortly after 9/11 in 2001. GE seems to agree with this:
So the path forward for GE is actually straightforward:
- Focus on completing and releasing the very late replacement of the D20ME, the D20MX
- Insure that a robust and secure design has been implemented. Given the history, GE would benefit even more than most in having a 3rd party assessment — although I’m sure it will not be Digital Bond
- Be honest with customers on the vulnerabilities and fragility of the D20ME so they can make an informed decision on removing and replacing it with the D20MX or other product.