GE D20 Metasploit Modules Make Compromise Demo Easy

PLC Hacking

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 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.

  1. 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.
  2. 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.

Moving Forward

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:
Project Basecamp
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.


  1. SCADAguy says

    You shold talk to the GE Energy rep again. The D20MX project was cancelled last year and the D400 requires external board to communication with the custom I/O (read: more rack space required in already full racks). The path forward for D20 installations isn’t at all clean.
    D25 installations are in worse shape – same software architecture and nothing remotly like it on the GE horizon. The primary choice seems to be a ‘forklift’ replacement of the RTU.

  2. Transtrophe says

    Any similar observations with the GE FANUC series 90/20 or 90/30 PLCs?

Leave a Reply