CoDeSys IDS Rules Easily Avoided

Project Basecamp
Locks had “long life” and names written on them.

I had a chance to chat with former Project Basecamp lead Reid Wightman about the Tofino/SCADAHacker IDS rules related to his exploit scripts. It was in conjunction with a soon to be released ioActive webinar on the CoDeSys issue. (btw, the webinar includes an intro to Project Basecamp/PLC security by me and then Reid digging into the CoDeSys security problems.)

The IDS rules were part of a whitepaper announced in the Tofino blog article Address SCADA Security Vulnerabilities Now, Not Later. The first thing you need to realize is these IDS rules detect legitimate activity by an HMI or engineering workstation. An attacker doesn’t find a vulnerability to attack the PLC, he uses a product feature. So even if these signatures were 100% effective detecting the activity, they could not discriminate if it is legitimate or illegitimate activity.

The signatures released were easily circumvented. Reid said it took 15 seconds. Perhaps that is hyperbole, but clearly it was only a couple of minutes. Here is Reid from an email:

I documented my code saying, “These packets probably aren’t necessary.” Those are the packets that Joel is detecting on. I commented them out, and it turns out they aren’t necessary.  I can just plain not send any of the packets except those absolutely necessary to send a command, and everything still works.  I’ve evaded the detection entirely by just commenting out a few lines of code.

This highlights the danger of writing an IDS rule to detect specific attack code rather than fully understanding the vulnerability. Not a slam on Joel & Eric, we have had and probably still have some attack rules rather than vulnerability rules in Quickdraw. Just realize a moderately skilled attacker will modify the attack to avoid the IDS.

One other small point — not all CoDeSys implementations use TCP/2455. In fact, our Wago uses TCP/1200. So check your device before implementing the current or future IDS rules.


There are two big picture points that need to be stated and clarified.

  1. Address SCADA Security Vulnerabilities Now, Not Later is correct in headline but wrong in content. Addressing the vulnerability should be getting a commitment from your vendor for an upgrade plan to add basic security / authentication / integrity to the PLC or other device. Addressing the vulnerability now is putting together a plan and budget to upgrade or replace your insecure by design PLCs. Throwing up some mostly ineffective compensating controls is not addressing security vulnerabilities. I can’t resist pointing back to my friend Eric Byres’ demonstration of this insecure by design PLC issue back in 2002/2003. Back then even I was pointing to compensating controls. I learned my lesson. We need to put the emphasis and resources on fixing the real problem, and not pretend these compensating controls are even close to adequate.
  2. ICS / SCADA Security IDS Rules Are Important Detection Measures – The fact that the initial rules were ineffective does not mean that IDS is not an important attack detection measure. Digital Bond published the first SCADA IDS rules as part of a DHS research project, and we are still a big believer that they are an important part of a monitoring and attack detection program. Quite frankly Joel and others have pointed out that the Quickdraw IDS rules have not been maintained and updated as they need to be. We are in discussions to rectify that problem and will be making an announcement in January prior to S4. It is a net plus that Joel, Eric and others are putting these out there for people to test and improve.

Image by ironypoisoning


  1. says

    Let’s start by saying that the IDS signatures were designed to target specific exploit code that was publicly disclosed – not all such attacks or exploit attempts. Just likes Reid’s PoC was developed to make a point, so was our sigs. Sure, if you modify the exploit PoC, the sigs won’t work – and we never said they would. The purpose was to detect someone using exploit code against a specific device.

    Next, the comments in the second paragraph “… these IDS rules detect legitimate activity by an HMI or engineering workstation …” are completely false. I have a full version of the CoDeSys engineering toolkit, plus a variety of other packages including HMI’s that I use regularly and the signatures on both SNORT and Tofino do NOT generate alerts when performing engineering or HMI functions against the target PLC. I am not sure where this information came from, but it is completely false.

    Next … if you read the instructions on the rule, it was clear that you had to modify the tcp comm port to utilize the specific ports implemented on your architecture. If you are going to slam our work, you could at least read the instructions on their use! If you want, you can easily modify your architecture to use something other than 1200 or 2455, which is why I provided editable rules (unlike Tenable who offer compiled NASL rules to detect this vulnerability).

    So … are you guys now going to criticize the work of Tenable and their Nessus signatures? This valuable tool is again based on the premise of protecting against known exploits, and not the infinite permutations that exist when an attacker starts modifying code. It was great to work with Ron and the guys on this project, and we all believe it did in fact add value.

    Finally, I don’t know what security camp you folks come from, but using a simple stateful packet firewall prevents ALL attacks originating from IP addresses that do not represent legitimate nodes that should be communicating with the device (such as a SCADA Server, engineering workstation, and possibly an HMI – though the HMI’s would typically coordinate comms through the SCADA Server). So, now, in addition to having identified the target, the attacker needs to obtain a valid IP address without detection and launch the attack remotely without detection. When reality is applied, the “actual applied” CVSS is very low, and the risk of attack becomes equally insignificant. This is why defense-in-depth is used along with compensating controls to provide potentially vulnerable devices from exploitation.

    Come on guys … are we defending against local or remote attacks here?

  2. says

    Joel –

    The rules detect legitimate access to my test PLCs as an attack. The attack tool’s ‘initialization frames’ are just packets that I saw between my EWS and my PLC. Every ‘static’ packet in my exploit demo is verbatim a packet that CoDeSys EWS software sends to my CoDeSys PLC.

    I think the big trouble here is that the protocol is closed. Without access to developer documentation from 3S Software, the likelihood of good, accurate, detection of protocol abuse is pretty hard. I’m glad that you gave it a shot. I’d love it if CoDeSys would open up some protocol documentation to make detection better and easier, but I’d say their priority should be to fix the known problems in the protocol first.

    On the down side, I don’t think accurate differentiation of legitimate use versus attack would be possible even then. As Dale points out, the sample exploit is just using the protocol, it’s not really ‘hacking.’


  3. Dale Peterson says


    I’m not going to go through another multi-round back and forth. We just have a fundamental disagreement about the urgency of fixing insecure by design field devices and control system protocols.

    I’d echo Reid’s comment that this type of exploit is designed by mimicking actual commands from an HMI or EWS. So if we had the product in the lab the exploit would have been identical to legitimate traffic from your HMI. It also highlights that there are a lot of implementation variations in the 100’s of products that integrate this software. (Also a warning that just because the exploit code doesn’t work on your PLC doesn’t mean it doesn’t have the vuln)

    Finally, I don’t think a fair reading of the post would say it slams your work.


  4. says

    I still think we have some configuration issues here. It would be nice to see this in a Camtasia session. Are you only considering the “” script in your analysis? In order to obtain the shell prompt with the “” script, there are no legitimate EWS or HMI commands that use this … so please help me if I am missing something here. Where is the sequence used in the shell sequence used as part of normal operations?

    Finally, it is interesting that you fail to acknowledge any credit to the other points mentioned in the response which were all part of the evaluation and mitigation strategies of the paper. When the sigs are properly deployed with additional rules for traffic flow anomalies and an industrial firewall is used in front of “inherently vulnerable and insecure devices by design”, this exploit would not be likely to succeed. Ok … you have proven this device is weak and I agree, but why won’t you acknowledge that these compensating controls significant reduce risk associated with a successful compromise.

    If you really want to have a good session at your S4 … you should actually let Reid or Luigi try to exploit weak targets when implement in the framework of a reasonable secure overall SYSTEM ARCHITECTURE and stop looking at the devices in isolation. I am game for something like this … and maybe we can finally agree that a device is not secure, but rather the overall “system” in order for an vulnerable to result in a compromise of the target asset —> the mechanical equipment under control of the ICS!


  5. says

    Dale, if your point was that Joel’s work is not an out-of-the-box perfect solution, I don’t think there is any disagreement. Inside these networks, all IDS activities will have to be heavily customized to have a chance at being effective. If the IDS squawks too much nobody will pay attention to it. Even then, there will be engineers asking how many IDS alarms they’re going to have to look at if the plant goes to an abnormal situation of _____. We’d like to think we could make such things really tight, but the reality is that we’re going to have to rely upon other methods as well. It will never be as secure or as sensitive as we’d like.

    Yes, it can be circumvented. Given the nature of real time protocols, the reality is that these networks will not be something you could expose directly to a potentially hostile environment.

    I think Joel’s point is that without building a full system, you don’t really have a meaningful example here. Of course Reid found a way to bust through. That’s like complaining that Fort Knox is insecure because the bathroom occupancy indicators can be defeated. We have to look at the larger picture.

  6. says

    Hi Joel –

    When I choose “Login” on CoDeSys with my PLC, the IDS signature packets are sent to the controller (no need to even open the PLC Browser shell). I included them in my exploit code because I thought that they were somehow related to initializing the communication. Turns out I was wrong. But the IDS signatures do indeed detect my normal, everyday use of CoDeSys as an attack.

    As you probably know, CoDeSys uses a plugin system for communicating with PLCs. I guess that your PLCs’ plugins don’t send the same packets as mine. Again, without access to the protocol spec (or access to all controllers made by all 261 vendors), we’ll never develop good, accurate IDS signatures.

    As for the rest, we’ll have to agree to disagree. We have different ideologies, that’s all.


Leave a Reply