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.
Conclusion
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.
For more information on how to effectively deal with cyber-physical vulnerabilities check out this related blog article and the videos on our Youtube channel.