One of the reasons why vulnerability and patch management is different in OT as compared to IT is the fact that the majority of OT products, technologies, and designs are insecure by design. If you are new to OT security, you might wonder what that actually means, and this is what this article is about.
You will never see a CVE for the worst OT vulnerabilities
If your only source for vulnerability information is the CVE data feed, you are missing the show in OT — and you will end up with a completely inaccurate idea of what your risk is. The worst exploitable flaws in OT products will never be reported by NIST, and there is not going to be a security patch or new firmware version that would mitigate these vulnerabilities.
Talk to NIST or somebody at DHS/NCCIC and they will usually shrug their shoulders. A common, yet completely nonsensical rationale is that design vulnerabilities are known for many years (as if this were a good reason for inactivity) and won’t be fixed, so why send out alerts and advisories about these.
The basics: Insecure technology and product design
Take any modern OT network technology or product design and check for cyber security features, such as authentication and authorization. If you find some, call yourself lucky. No matter if you look at Modbus, Ethernet/IP, Profinet and similar communication protocols, the basic assumption is that they are all running in trusted environments where every endpoint is legitimate and well-behaving.
Look at proprietary DCS protocols for client/server communication. Do endpoints establish trust relationships before allowing each other to modify sensitive paramters of your process control? Only in your dreams. Do controllers check the ladder logic or firmware for authenticity before execution? Nada. Don’t be fooled by Ninety-style CRCs that might be used for integrity checks, they have nothing to do with authenticity. (Side note: Ease on that irrelevant CIA/AIC nonsense before you have fully understood, and communicated, the authenticity problem.)
But is this really relevant?
You now want to have some more concrete arguments how designed-in vulnerabilities could possibly be exploited and cause trouble. The first thing to understand is that only a fool will attempt to take advantage of some cross-site scripting vulnerability in a PLC’s embedded web server if legitimate commands are available to reliably mess up a process.
Let’s look at an example. In one of the most popular PLC products, you can erase the main executive control loop with a simple, legitimate command at run time. You don’t even need to hack your butt off all night in order to figure out what this command would look like. All you need to do is connect an engineering station to such PLC, execute the engineering software’s built-in command to delete an operations block by clicking the mouse, and trace network traffic using Wireshark. Then replay that command in your attack software. Easy enough.
As a result, the target’s I/Os are frozen, but the command interface still works. If you wanted to, you can now energize all outputs using another legitimate command. Do that in a real-world environment and chaos is almost guaranteed. We had pointed the vendor in question to this issue eleven years ago, without any meaningful response.
Have designed-in vulnerabilities ever been used in real-world attacks?
You bet. Remember Stuxnet? One of the most reported characteristics of the malware was a man-in-the-middle attack ON the controller, which we had discovered in November 2010. (As a side note, almost every single publication on this displayed utter misunderstanding because the MITM is mostly associated with the second version of Stuxnet, in which it is completely absent; it’s only in the first version of the malware that executes on a Siemens S7-400 controller.)
This exploit is an incredible, mind blowing stunt that raises a control engineer’s hair once that it is fully understood. It helped the attackers to modify process parameters without any protective logic kicking in. The fact that operators were fooled as well is the lesser interesting fact. Imagine if you can fool protection and safety systems which are intended to thwart disaster within milliseconds — because they may have to — in order to understand the magnitude of the problem.
Now let’s fast forward to 2019. Guess what, you can still use the same exploit on the same product line. Even nine years later, it’s guaranteed to work, since the product architecture was never changed. And sure as hell there never was an ICS-CERT advisory or alert on the topic. All of this because we’re talking about a legitmate product feature that is used by some to simulate process inputs. So just use that simulation feature in a creative way and you got your cyber weapon.
Many times, reading an OT product’s manual and exploring its legitimate features will yield more vulnerabilities than having a group of hackers use their cyber Ninja techniques to find buffer overflows in code. Fortunately, most hackers don’t like to read manuals, but you shouldn’t bet on it.
As long as you only focus on published vulnerabilities for your OT/ICS systems that are delivered by NIST and similar data feeds, you are just scratching the attack surface. You are throwing resources at vulnerabilities that may not be worth bothering with until you have addressed the much deeper stuff which, if exploited by professionals, can really ruin your and your customers’ day; maybe even your company.