Today Digital Bond released two new Metasploit modules affecting Schneider Modicon Quantum PLCs. I believe that these only affect PLCs with a “Unity” ethernet card, although I would guess that the exploit could be adapted to other controller types with minimal changes.
Both exploits takes advantage of the “Unity” protocol. This protocol is really just a special function code of the Modbus protocol. I don’t understand all of the fields of this sub-protocol, but I don’t have to — I just have to understand it well enough to replay it.
The first exploit initializes communication with the PLC and then sends a single packet to either start or stop the PLCs CPU. This stops all logic operation in the CPU until an engineer issues a new START command to the PLC. This is similar in nature to Rubén Santamarta’s STOP CPU payload for the Allen-Bradley ControlLogix. It appears that more vendors will have this designed-in insecurity. Manufacturers should consider requiring authentication in their control protocols to mitigate this attack.
The second exploit is a ‘Stuxnet payload downloader.’ It allows a remote user to download and upload ladder logic to a PLC. This module provides the basic information needed to pull off a Stuxnet attack. We provide a blank ladder logic upload for testing. This can be used to blank out the STL (Statement List) program in a Modicon. This module was built in just a few days total (much of the time was spent two nights before the talk, I had to correct for a bad assumption about the packet format for reading the existing logic out of the controller…oops).
Unauthenticated ladder logic upload is in my opinion the biggest issue in PLC security. Many PLCs end up using a proprietary protocol, or a protocol based upon a traditional SCADA protocol but using custom function codes, to perform ladder logic and configuration updates. The end result is that PLCs are ‘vulnerable’ by design. The era when vendors could say, “nobody understands this protocol, so it’s secure,” is over. The basic technique for overwriting ladder logic in a PLC is just too easy — a few hours of access to a controller and its software is all that is needed to break the system.
GE D20
We also released another Metasploit module for the GE D20: d20_tftp_overflow – General Electric D20ME TFTP Server Buffer Overflow DoS. This exploits a buffer overflow in the TFTP server that was disclosed at S4 in January.
WAGO 870 / 3S-Software CoDeSys
A new controller was also added to Basecamp, the WAGO 870 controller. This is an embedded Linux PLC running ladder logic by 3S-Software. The ladder logic may also be uploaded and downloaded without authentication, although I haven’t figured out the protocol well enough to produce a demo.
There are a lot of interesting things about the WAGO: it has hard-coded system accounts, which allow root access to what is essentially a server. Using this, I can install whatever additional software I please (well, as much as will fit in the limited 32MB of flash memory).
The 3S-Software CoDeSys system on this PLC is interesting for another reason. The process that executes the ladder logic is running with superuser privileges. The ladder logic file that is uploaded to the controller is actually compiled x86 code. So CoDeSys effectively provides a buffer overflow remote code execution, but without the ‘overflow’ part — you just upload binary with the protocol, and it will run with root privileges. I plan to have a PoC and metasploit module out for this in a few weeks. This metasploit module will be my first that can actually use metasploit payloads, since the controller is just x86 Linux.
Information on the new Metasploit modules may be found on our Project Basecamp Metasploit Modules page. All of the Project Basecamp Metasploit modules will be available in the Rapid7 Metasploit feed.
Image by davespencer