Microsoft Spotted 15 High-Security Vulnerabilities in Industrial SDK Used by Power Plants (arstechnica.com) 23
Ars Technica reports that Microsoft "disclosed 15 high-severity vulnerabilities in a widely used collection of tools used to program operational devices inside industrial facilities" (like plants for power generation, factory automation, energy automation, and process automation).
On Friday Microsoft "warned that while exploiting the code-execution and denial-of-service vulnerabilities was difficult, it enabled threat actors to 'inflict great damage on targets.'" The vulnerabilities affect the CODESYS V3 software development kit. Developers inside companies such as Schneider Electric and WAGO use the platform-independent tools to develop programmable logic controllers, the toaster-sized devices that open and close valves, turn rotors, and control various other physical devices in industrial facilities worldwide... "A denial-of-service attack against a device using a vulnerable version of CODESYS could enable threat actors to shut down a power plant, while remote code execution could create a backdoor for devices and let attackers tamper with operations, cause a PLC to run in an unusual way, or steal critical information," Microsoft researchers wrote.
Friday's advisory went on to say: "[...] While exploiting the discovered vulnerabilities requires deep knowledge of the proprietary protocol of CODESYS V3 as well as user authentication (and additional permissions are required for an account to have control of the PLC), a successful attack has the potential to inflict great damage on targets. Threat actors could launch a denial-of-service attack against a device using a vulnerable version of CODESYS to shut down industrial operations or exploit the remote code execution vulnerabilities to deploy a backdoor to steal sensitive data, tamper with operations, or force a PLC to operate in a dangerous way."
Microsoft privately notified Codesys of the vulnerabilities in September, and the company has since released patches that fix the vulnerabilities. It's likely that by now, many vendors using the SDK have installed updates. Any who haven't should make it a priority.
"With the likelihood that the 15 vulnerabilities are patched in most previously vulnerable production environments, the dire consequences Microsoft is warning of appear unlikely," the article notes.
A malware/senior vulnerability analyst at industrial control security firm Dragos also pointed out that CODESYS "isn't widely used in power generation so much as discrete manufacturing and other types of process control. So that in itself should allay some concern when it comes to the potential to 'shut down a power plant'." (And in addition, "industrial systems are extremely complex, and being able to access one part doesn't necessarily mean the whole thing will come crashing down.")
On Friday Microsoft "warned that while exploiting the code-execution and denial-of-service vulnerabilities was difficult, it enabled threat actors to 'inflict great damage on targets.'" The vulnerabilities affect the CODESYS V3 software development kit. Developers inside companies such as Schneider Electric and WAGO use the platform-independent tools to develop programmable logic controllers, the toaster-sized devices that open and close valves, turn rotors, and control various other physical devices in industrial facilities worldwide... "A denial-of-service attack against a device using a vulnerable version of CODESYS could enable threat actors to shut down a power plant, while remote code execution could create a backdoor for devices and let attackers tamper with operations, cause a PLC to run in an unusual way, or steal critical information," Microsoft researchers wrote.
Friday's advisory went on to say: "[...] While exploiting the discovered vulnerabilities requires deep knowledge of the proprietary protocol of CODESYS V3 as well as user authentication (and additional permissions are required for an account to have control of the PLC), a successful attack has the potential to inflict great damage on targets. Threat actors could launch a denial-of-service attack against a device using a vulnerable version of CODESYS to shut down industrial operations or exploit the remote code execution vulnerabilities to deploy a backdoor to steal sensitive data, tamper with operations, or force a PLC to operate in a dangerous way."
Microsoft privately notified Codesys of the vulnerabilities in September, and the company has since released patches that fix the vulnerabilities. It's likely that by now, many vendors using the SDK have installed updates. Any who haven't should make it a priority.
"With the likelihood that the 15 vulnerabilities are patched in most previously vulnerable production environments, the dire consequences Microsoft is warning of appear unlikely," the article notes.
A malware/senior vulnerability analyst at industrial control security firm Dragos also pointed out that CODESYS "isn't widely used in power generation so much as discrete manufacturing and other types of process control. So that in itself should allay some concern when it comes to the potential to 'shut down a power plant'." (And in addition, "industrial systems are extremely complex, and being able to access one part doesn't necessarily mean the whole thing will come crashing down.")
Target code vulnerable? (Score:3)
I've done a little PLC programming, but never used CODESYS. So CODESYS is a development environment package, and it's vulnerable, but does that mean the vulnerability gets into the target PLC?
Re: Target code vulnerable? (Score:3, Insightful)
As I see it - if Microsoft is involved in PLC programming it makes it easier for attackers to target those systems.
This tells me that for mission critical systems air gapping them from the internet is essential.
Re: (Score:2)
This tells me that for mission critical systems air gapping them from the internet is essential.
This is a great way of creating a false sense of security. Airgap-it-and-done breeds of culture of bad security thanks to "we've airgapped it, we don't need to do X, Y or Z", and that's precisely how you end up with Stuxnet, a successful attack on an airgapped system. Oh you also failed to answer the OPs question.
Re: Target code vulnerable? (Score:5, Insightful)
Airgapping it is just one of the steps.
Unfortunately for many PLC systems they are quite a bit behind, and some of those systems were modern in the beginning of the 1990s and are still running.
Upgrading such a system is a multi-million dollar activity, so it's not done easily.
Re: (Score:1, Insightful)
Re: (Score:2)
Thank you, but I probably didn't pose the question well. Too often I assume people's knowledge about a subject.
PLCs do not run x86 code. That doesn't mean they're immune to attack of course. Stuxnet is proof it can be done. I don't know the numbers, but gobs of PLCs run standalone- no Ethernet connection, let alone Internet.
Point is, a PLC is NOT a PC running some PLC program- they're very specialized and most, if not all, are not x86 CPU, so it'd have to be a very specialized attack, like Stuxnet.
Place
Re: (Score:2)
Re: (Score:1)
Potentially: yes. If system developing the PLC code is compromised, then PLC code developed on that system, could be compromised as well.
It's not often heard of, but potentially very serious. This depends on # and type of customers that use the developed code. And how their systems are configured, deployed & managed.
See: supply chain attack [wikipedia.org]. There are some infamous examples.
Note that PLC-controlled systems tend to be very customer specific. So it would be hard to exploit or profit from an attack.
I Find the TRUTh reassuring.... but (Score:3, Insightful)
Re: (Score:1)
Re:I Find the TRUTh reassuring.... but (Score:4, Insightful)
It very much sounds like you haven't touched a PLC or control system in the past 15 years. They all have ethernet connectivity by default, down to the most simple and smallest PLCs on the market. The larger ones these days have multiple segregated networks and setting up a PLC these days requires as much knowledge about networking as it does industrial field wiring.
You're right about the junk protocols though, and that's a real bonus too. Modbus/TCP is literally designed to assume no security is required and the network is private.
But honestly your real Dunning-Kreuger moment is when you called Profinet a "balanced serial communication". Profitnet was literally one of the earliest implementations of industrial ... ethe... no actually I'll let you guess what the "net" part of "Profinet" stands for.
Re: (Score:1)
Modbus TCP is a packaging of serial Modbus so that it can be routed over TCP. The protocol has no security because the standard Modbus protocol is intended to operate over a dedicated serial link (RS485 in most of the RTUs I worked on) where the concept of an insecure network is kind of laughable. If someone can physically tap into your serial link somewhere, they can also just turn manual valves or push panel buttons to do whatever they want.
I've spent my whole career working in industrial automation, wate
Re: (Score:1)
Wifi networking on a PLC?
Sure, chief, lets put a radio remote into the machine that is ensuring that the cyclohexane in a pipeline keeps moving, because if it's bottled up in the pipes it can rise above it's LEL and literally explode sitting in the pipe, killing all of your buddies who happen to be working in the hexane unit that morning.
IT people should keep out of this kind of stuff.
Re: (Score:1)
Is that you, ChatGPT? Welcome back dude!
Ultimately the best security will be having an understanding with our adversaries that will focus on our mutual survival, (..)
Ultimately the best building security will be having an understanding with would-be thieves, that will focus on our mutual interests (..)
Yeah, sure. Try fences, sturdy doors, proper locks & camera's. And somebody / something checking the footage, with guards / cops on call.
Security advisorys from Microsoft (Score:1, Funny)
Worked in SCADA and this is the tip of the iceburg (Score:3)
A very common situation is the SCADA system is fantastically critical to what makes the company go; a factory, a refinery, a pipeline, a utility, etc. As we all know most IT departments have long ago lost the plot of why they exist, but in SCADA operations centers they often have kicked IT out. They run their own servers, they buy their own desktops for operators, everything. They might go back to their cubical and IT runs those computers, but often IT has little to absolutely nothing to do with SCADA including even provisioning networking as even this can be a bunch of weird.
This is a good thing in that there is no chance of the SCADA system going down and they have to get in line with the ticket system. The SCADA people will have their own experts who often deliberately live near the servers just so they can rush over in 12 minutes to solve any urgent problems.
But, it is also a bad thing because they aren't usually IT people. They are often some guy who programmed PLCs, then got into networking, and then was moved to the SCADA operations center. These guys often have a pile of knowledge covering a vast range of tech. A large distributed asset like a utility or pipeline could easily be 100+ years old and the equipment can pretty much cover the entire 10 decades of change. They may have paper tapes recording data in one place, modbus in another, MQTT in another, a bunch of proprietary communications protocols in another, acoustic modems, their own 1000km of fiber optics, satellite coms, some LTE, and on and on. In the server room there could be just about every OS in the last 40 years from VAX to a shiny new linux. The level of institutional knowledge one of these people typically has is insane. But what they often have no knowledge of is security. In this environment the very concept of regular upgrades scares the shit out of them. Often the software they use is super custom one off or low customer base software. Upgrades have a long habit of blowing things up. So, leaving a copy of windows NT 15 years behind is fine. Solaris 12 years since last upgrade is good. Nobody even blinks at a redhat install which hasn't seen an update in a few years. Why would you even think of upgrading the software on a PLC which controls something critical (as in blows up) if you don't have to.
Often they will have a few weird ass layers of VPNs and other crusty old security which they say is "bulletproof".
My theory is the reason these systems don't get hacked more is simply because most hackers don't know modbus, serial over UDP, are doing phone phreaking, or any of that. How many hackers know solaris? VAX?
Most of the industrial systems I have witnessed were the ultimate in security through obscurity; extreme obscurity. So this CODESYS thing is something that I laugh at. I don't know what product MS is trying to sell, but I can without hesitation say that the people in these larger industrial software companies aren't using CODESYS correctly anyway, and probably left a trail of SQL injection attacks (and other BS easy stuff) a mile long.
Like here is the level of stupid I can absolutely predict: If you look at the traffic going from almost any bit of their system to another bit there is a low chance it is being encrypted. If it is being encrypted they are doing it wrong, so the encryption is easy to break. Plus, basic security hygiene like ignoring repeated messages are probably not being done along with most message authentication. So, if you were to just repeat a message telling something to open a valve, it would probably just open the valve. But if you found some unencrypted messages and one of them read float for pressure which normal ranged around 100 and you set it to 100 trillion or something, their software would either happily ingest this new information and act accordingly (probably an alarm or a shutdown) or more probably, something would overflow and the software would crash. Or set valu
Re: (Score:1)
Per the comment about encryption in industrial protocols, you answered your own question earlier in the text. At my site we have some of the newest PLCs coming from Rockwell, and also machines that were designed before my brother was born in the mid 1980s. You aren't going to do AES on a machine with a 6809 processor that's got 1MiB of banked RAM.
Additionally, if an attacker is on your controls network, then you have already lost. Of course a command to open a valve is going to open a valve. The valve could
Re: (Score:1)
I should probably clarify also because it might not make sense to people who don't program PLCs, that they are not programming in C or Python or Rust or whatever today's shiny is. They are programmed in a set of 5 languages defined by an IEC standard, which languages and how close to the standard the implementation will be depends on the PLC vendor, but there are only really 3 or 4 serious vendors (Rockwell Automation, Siemens and Schneider Electric will account for most of the market on their own), so it's
Written from a position of ignorance. (Score:1)
It's obvious just by the wording being used in the article that the people involved in it's authoring have never worked in industrial automation and possess zero understanding of the field of the way problems are solved in it. The "toaster-sized devices" that "turn rotors," what the actual fuck. I guess maybe the author has seen a picture of a PLC one time, but has zero actual knowledge.
Twenty years ago PLCs were mostly on their own fieldbus implementations (ControlNet, Profibus, Modbus (serial, not TCP), D