In addition to having a slew of backdoor accounts, an open telnet service, and an open WindRiver RPC-Debug service open on this device, it has an unsigned firmware, managed accounts that are stored with usernames and passwords in plaintext, and buffer overflows galore.
This device is another case where the ICS-CERT defined vulnerabilities are difficult to exploit unless your goal is Denial of Service. The designed-in insecurities are far easier to use, giving superuser privileges for both Telnet and FTP. User-definable account names and passwords for the HTTP service stored in plaintext files. The user-definable accounts can thus be retrieved using the backdoor access, giving an attacker access to a easier-to-use graphical interface to the process via the web GUI.
We’ll be putting out a Metasploit module for this device on February 14th:
modiconpass – This will retrieve the HTTP and other plaintext-stored passwords from the Modicon and print them, as well as store them in Metasploit’s loot system. The passwords are retrieved using backdoor FTP access.
Note that, like the GE D20ME modules, this isn’t really an exploit. We’re just using the backdoor access that Modicon gives us (they use it themselves) to provide access.
Denial of Service
The ethernet module can be crashed in many ways, all of which are untraceable unless the victim has an external intrusion detection system or packet logging system installed. These don’t stop the PLC from operating autonomously, but they do cause a loss of view and loss of control for the operator of the system.
The first crash is the vulnerable TFTP server. The TFTP server allows an attacker to write arbitrary files to the /RAM0 filesystem, which is a blank ramdisk. If the filesystem is filled, the device crashes. I haven’t determined the size of the filesystem, but uploading for example /dev/zeroes from a Linux box will definitely do the trick. There is now a check for this issue in Nessus, plugin #57600.
The next crash is in the HTTP server. Simply issuing a GET request with a long filename is enough. The request that caused the crash was a filename consisting of 1086 ‘A’s. It’s possible that this could be turned into a remote code execution exploit. I’ll look into this over the next week or two and update this post accordingly.
The next crash is in the FTP server. Issuing a FTP CEL request (anonymously) with a long argument crashes the device. This appears to be an old bug in vxWorks 5.4 which was fixed in 2002. It’s possible that this could be turned into a remote code execution exploit too. I’ll update in Mid-February after trying it with a debugger attached.
The HTTP and FTP server crashes are easily accomplished using the BED fuzzer, included with BackTrack 5 in /pentest/fuzzers/bed — just point the tool to the appropriate host, and fuzz the protocols.
Image by blackwing_de