Hacking a VFD?
So, many years ago, I was brought into a conversation about Profibus and the Stuxnet aka Olympic games hacking job with the Iranians over gas centrifuges. (I do not have any direct knowledge of the actual hack). I summarized how I would do it and someone else in the coffee shop in Chicago got really interested in the discussion, and I have never been shy about opinions…..
Iran Hacking Opinion
Here is the summary, the Iranians used Vacon and their own version of a VFD (no details on this one) over Profibus to the Siemens PLC. Since the drives had to be set up with an expanded limit to 90,000 rpm or the equivalent linear speed of Mach 2. The drive had zero speed overhead. So how do you create a catastrophic failure with something that fast? If the PLC programmers decided to take control of the current limits, acceleration and deceleration rates (ramps) like a motion controller — the hacked PLC could have easily ramped up and then stopped the drives repetitively in a catastrophic fashion breaking or cracking the gas centrifuges aluminum casing without going into the drive itself. Why attack the drive when the PLC is the target of the hack?
Over the years I have accessed many areas of drive manufactures parameters to make changes or to develop alternative ways to communicate with the drive. In many cases the keypads are modus rtu natively and can be RS485 or RS232. I used to use a PLC coprocessor to write custom sequences interrupting multiple 232 connections allowing control on a drive with no real fieldbus capabilities. All of this was over an old school modem. (This brings back memories of all the free phone calls I used to make…) IMHO, there are ways to many parameters that can be written to, but to create a serious failure, all of the protections have to be turned off even if something atune to critical speed is changed. It would be better just to stop and prevent re-start for many applications that need to run due to their critical nature like process controls. I digress, security has always been a question. And now, remote monitoring has brought us into uncharted territory with IOT and Industry 4.0.
Recent Threat News about Rockwell 525
From the link, you can see Rockwell 525 has some challenges. I personally have always felt that industrial protocols have been long overdue for more security scrutiny, especially the ones more commonly found in plants using Common Industrial Protocol (CIP) (ODVA). The threat assessors stated that the flaw in the 525 allows an attacker to crash the CIP in a way that it does not accept any new connection, the current connections however, are kept active, giving attackers complete control over the device.” Furthermore, to exploit the vulnerability, a bad actor could send a precise sequence of packets effectively crashing the CIP network stack. But, why attack the drive when you can attack the PLC is again the question. Well, mostly because the new drives pack more functionality in the drives and less control resides in the PLC….
Not to bash Rockwell, they have a problem and they know it. It seems to me that the idea of security is an after-thought unlike others that have a specific digital foundation like ABB. ABB sees hacking a VFD as a possibility and takes rigorous steps through testing as part of ABB Ability….you cannot have a real digital strategy without security as a priority.
Dragos does an annual report and the findings are curious: “Nearly 72% of advisories cover HMI, Engineering Workstation (EWS), and Field Device/Industrial Networking components. Mitigating vulnerabilities in these types of systems does little to reduce an industrial impact – an attacker that is in a position to target these systems will likely achieve their goal without use of vulnerabilities.” Anytime we set up a remote link or cellular connection, we go over potential threats and remedies to the design with the plant’s IT folks and sometimes, it does not make sense to do it. Like everything else, the conversation must be had with the correct folks. These threats like hacking a VFD are not going away.
C. Tolbert VP Engineering