While patch management already presents challenges for enterprises, it’s even more of a headache for manufacturers and other industrial firms – who may even need to shut down entire factory operations in order to apply fixes.
Sharon Brizinov, the principal vulnerability researcher with Claroty, has discovered and reported various security flaws in industrial control systems (ICS), including most recently a vulnerability in a software component used by various critical infrastructure systems (which he disclosed last week).
Brizinov told Threatpost that because CodeMeter is a third-party component utilized by various leading ICS products (including Rockwell Automation and Siemens), users may be unaware that it’s running in their environments. The issue is indicative of larger patch-management challenges in the industrial space, where there are difficulties not only for industrial system manufacturers, but for end users themselves, he said.
“When we’re talking about ICS, it’s a big more dangerous, and we should be more alert than the usual IT network,” Brizinov said in this week’s Threatpost podcast. “And that’s because operational-technology networks, SCADA networks, contain some dangerous parts.”
Below is a lightly edited transcript of the podcast.
Lindsey O’Donnell-Welch: Welcome back to the Threatpost podcast. This is Lindsey O’Donnell-Welch with Threatpost. And I am joined today by Sharon Brizinov, the principal vulnerability researcher with Claroty, who is going to be talking about some new critical security flaws that were recently discovered in a software component utilized by various industrial systems, as well as industrial control system security in general. So, Sharon, thank you so much for joining us today.
Sharon Brizinov: Yeah, thank you. Happy to be here.
LO: Great. So just to set the context a little bit here. Last week, researchers discovered six critical flaws in CodeMeter, which is a software management component that is licensed by several of the top industrial control system software vendors, such as Rockwell Automation, and Siemens. Now, CodeMeter, what it does is it gives these companies the different components and tools to help with their licensing models and to bolster security and protect against reverse engineering and piracy. So Sharon, can you tell us a little bit about these vulnerabilities, and, just to start, how you first discovered them?
SB: Yeah, sure. So we actually started the research, I think, one and a half years ago. We started to notice that a lot of products, especially in the ICS domain, are shaped and distributed alongside with a software called CodeMeter. So we were curious why CodeMeter was so common in the ICS domain. And we started to take a look at it. And we discovered, with our research, we discovered six different vulnerabilities that we were able to convert into two different attack scenarios. So we were able to prove that attackers can leverage these six vulnerabilities into the threat vectors that I mentioned. And in one of the attack vectors, attackers can attack the victims using a specifically crafted website. And the second attack vector, attackers can attack the victim by just remotely communicating with the CodeMeter server that is located on the machines.
LO: Right. So that sounds like there are varying levels of impact and kind of various levels of severity as well here. Where did the vulnerabilities exist? Were they all in the same area of CodeMeter? Or were they more distributed across the the software component?
SB: So actually, they’re distributed. So there are six vulnerabilities. So some of them are in the the protocol communication, part of CodeMeter. Some of them are in the way that code meter is parsing requests from web socket APIs. And some of them are related to license parsing, and license verifications. So it’s very, the places where we found the vulnerabilities are very different from one another.
LO: And can you talk a little bit more about the impact of the vulnerabilities and how easy they are to exploit? You had mentioned that, in one case, attackers could potentially send a specially crafted link, and that was one attack vector. What were the different types of attack scenarios there?
SB: Yeah, sure. So in the first attack vector that I mentioned, this is actually a very easy one to exploit. In this case, in this attack vector, an attacker will prepare a website somewhere on the internet. And it will prepare, specifically crafted JavaScript that once a victim will go on this website -using some phishing methods or other ways to lure the victim into the website – the website will send this specifically crafted JavaScript to the browser of the victim. And this JavaScript code, what it will do, it will actually communicate locally with the CodeMeter server and use some web socket API in order to trigger a vulnerability we found in the license mechanism. So the full flow for the first attack vector would be a victim going on a malicious website using some phishing methods, then the website will attack the CodeMeter through the browser, and it will inject a malicious license that will cause CodeMeter to stop working properly.
LO: Right. So it sounds like the impact here, too, would be, you know, remote code execution and enabling attackers to launch denial-of-service attacks and some other impacts there as well. It seems like it’s kind of like a broad spectrum, right?
SB: Yeah. So this was the first attack vector, and it was very easy to find, because lately, we have seen a rise in web socket usage. And there are a couple of implementation properties that when developers are implementing web socket, they really needed to to notice how they implement the web socket. Otherwise, it could open a door to attackers, just like in this case. So this was the first attack vector, which is kind of easy to exploit.
And the second attack vector that we were able to find, requires a little bit of more knowledge of some crypto graphical aspects and crypto graphical methods. In the second attack vector, attackers would need to directly connect and communicate with the CodeMeter server. So they would need to be on the same local area network as their victim. And in this case, they can send specifically crafted packets to the machine, to the CodeMeter server, and then trigger a couple of vulnerabilities that we were able to find.
LO: Right, and what would the impact be? If I successfully exploited what could an attacker do in that case scenario?
SB: Yeah, so in this case, attackers will be able to run code remotely. So that would be an RCE, remote code execution, on the remote machine.
LO: Right, right. It’s really interesting. I feel like with industrial security, the bar is really raised a bit over other types of security threats, just because of what that could mean for different industrial control systems, like programmable logic controllers, or other types of controls. And you know, what the real life impact would be for different industrial systems and machines – can you talk a little bit about what the real life attack or impact would look like for a victim here?
SB: Yes, you’re definitely right that when we’re talking about ICS, it’s a big more dangerous, and we should be more alert than the usual IT network. And that’s because OT networks, SCADA networks, contain some dangerous parts. So we have some machines, and we have some actuators in this network. So if an attacker can somehow attack this kind of network, they will be able to get access to very dangerous equipment that can endanger humans. And we’ve seen this multiple times in the past. So we have seen it with Stuxnet, the Stuxnet malware was able to cause some real damage, real physical damage. And that’s why we’re so alert when we’re talking about ICS security. Specifically, in this case, since CodeMeter is so widespread in those networks, because many ICS vendors integrated with CodeMeter, then if attackers will be able to exploit CodeMeter and attack CodeMeter, basically, it means that they will be able to get access to thousands of machines in OT networks. And that’s why it has a such a big impact because it actually opens a door for attackers to attack multiple computers, multiple machines on the ICS network.
LO: That could potentially be very damaging and you make a really good point that these challenges do exist, they’re kind of going beyond just CodeMeter and to affected vendors like Rockwell, like Siemens, and Rockwell and Siemens have released their own security advisories, but with CodeMeter being integrated into many ICS products, you know, what can users do to make sure their systems are safe? Because as you had mentioned, in the research users may be unaware that this this vulnerable component is still running in their environment.
SB: Yeah, exactly. So you’re definitely right. CodeMeter is a third-party component. So usually users will not install CodeMeter themselves. They will install, let’s say, a software by Rockwell Automation or any software by Siemens, and then along the installation bundle CodeMeter will be shipped and installed. So users will not install coordinator themselves, and therefore they won’t even know they have CodeMeter. And that’s why we developed a website that end users could go online, to our website, to our test web page, and actually test if the machine is vulnerable. So I definitely recommend anyone to go online to our website, to our test page and test if they’re vulnerable. And we have developed a couple of ways to understand if you’re vulnerable too, so we have some tools on our GitHub repository that system administrators could use these tools in their networks to mass scan their network and see what machines are running CodeMeter. So to summarize the answer a bit, first, I would like to recommend anyone to discover instances of CodeMeter in the network so they can do it by going to our test page or our GitHub repository, and download our scanning tool. And then to mitigate it, that’s another story and to mitigate it, first of all, I would recommend to follow Wibu’s own advisory. So Wibu always the company that developed CodeMeter, and they have their own advisory. But also I would recommend end users to read the advisories by the other vendors, let’s say, the Rockwell Automation vendor, or the Siemens, depending on the equipment and software they have installed.
LO: Yeah, definitely, for sure. And just taking a step back here and looking at industrial control system security and critical infrastructure security in general, I feel like patching in general in the industrial world is just a big challenge because of different things that need to happen. I mean, machines can’t be just shut down in order to patch and things like that. Can you talk a little bit about what types of challenges there are when it comes to patch management for industrial control systems, and also the process of disclosure in this situation as well, when you first notify them, when a fix was issued?
SB: So my team is responsible for finding vulnerabilities. So we assess different tickets, different products from the security, security angle, and we’re trying to find vulnerabilities so the defenders can think ahead. And once we discover a couple of vulnerabilities, we’re preparing a PoC, proof of concept. And then we’re preparing to report and we’re sending it to the vendor. From this point, the vendor needs to triage and make sure our report is valid. And once they do that, we’re starting to work with them in order to fix the vulnerabilities. So sometimes, the vendor asks for us, for more information or to explain a bit how we found it. And once the vendor has a pretty good idea of where their vulnerabilities are and how to patch it, they’re actually developing a patch or they’re developing a new release, and they’re releasing a new version with the fixed code. From this point, we’re starting to work with some CERTs organizations, so CERT organizations help to distribute the the information that new software releases are out and new patches are out. And we’re working with them too, so they can alert the community, specifically the industrial community, of new vulnerabilities and what are the patches. And from this point, it comes to the first part of your question. And so people know that some vulnerabilities exist, and they needed to patch their software.
And so it really depends right now, the type of the factory that or the network that we’re talking about. If we’re talking about an external network that has a some online access to the internet, then patching is much easier. So the admins will just download the patch, and we’ll install it. But if we’re talking about a production network, which is usually offline, it doesn’t connect directly to the internet. So what we’ll have to do is first test the patch offline in their lab. So usually they have a lab offline with all the equipment, which simulates and emulates actually the the real production line and they will test it in the lab to make sure there are no malfunctions and their software works well, with their code that’s running in the factory and the patches. And once they will verify this, they will move on to shut down the factory, maybe it will be on Saturday, maybe it will be on Sunday for a few hours. So patches could be applied when the machines are down. So that’s why it’s so complicated to patch software in production lines, because the administrators will need to work very hard in order to test it in their lab before applying the patches. And then when applying the patches, the factory must be shut down. Because they don’t want any damage to be caused if patches go wrong on a live production.
LO: Right? That’s pretty crazy that they have to, you know, completely shut down too. And I think when you look at IT and OT teams, and how they need to work together. One thing that is difficult for people on the security side to realize at least just how important downtime is for these different types of industrial machines. And I think that is really why patching is such a difficulty. You know, although it’s so necessary as well, as we’re seeing in this case. Now, can you talk a little bit more about what other challenges exist in general, when it comes to applying security controls or other security issues that exist in critical infrastructure that you’ve seen over your time looking for vulnerabilities in industrial control systems?
SB: Yeah, sure. So there are a couple of different categories of attackers, some attackers would like to attack OT networks just to install a ransomware. Because they know that if their ransomware campaign is successful, then the factory is being shut down. And it costs a lot of money to the factory owners, and they most likely pay the ransom. So this is one category of financial cyber criminals that just want to earn some money, and they want to install a ransomware in the network. Another category that we’ve encountered encountered in the past would be attackers, that are nation state sponsored, or a very advanced group that wanted to attack factories to get a foothold inside the OT network, just so they can prepare some kind of weapon, a physical weapon, that they can they can weaponize and use it whenever they need. So for example, they can even blow up a factory if they’re getting enough money from other criminals. So this is a very dangerous type of attacker. And it’s actually very rare to see an ongoing campaign like this, because the the complexity of this campaign, the complexity of this operation is very high. And you need some very advanced tools to maintain such an a campaign. So this is the second category. The third category would be spontaneous access to OT networks. So let’s say you have attackers on the IT network, and suddenly they discover a misconfiguration that allows them to go from the IT network to the OT network, and they just start to poke around and see what kind of computers and what kind of machines and other OT equipment is found on this network. And they’ll just try to use some exploits. Usually it won’t be any sophisticated exploits. So usually it will be one days, not zero days. And usually they could could be couched very quickly because they’re not very sophisticated. So I would categorize the different attackers into these three groups.
LO: Right, and I know at least with ransomware, I feel like ransomware attacks have steadily increased over the past year attacking industrial companies, especially when you look at like Norsk Hydro and some of the other vendors who have been targeted. So that seems like it’s an up and coming one. Is that what you’re seeing on your end as well?
SB: Yeah, so usually these attacks are opportunistic, so attackers will just release, you know, a phishing campaign or they will release some kind of virus that will try to copy itself to different networks. And if they’re successful, they will be able to infect OT network as well. And then if a malware or in this case ransomware is being spread in the OT network, it will be very beneficial for the attackers, because usually, factory owners will do anything to to continue the production line. So they don’t want to lose money. So they’ll do some analysis, will it cost them more to pay the ransom? Or to shut down their factory?
LO: Right, right. And Sharon before we wrap up is there anything else you wanted to highlight either relating to your recent discoveries of the six vulnerabilities in CodeMeter, or just in general, any trends that you may be seeing in the industrial security space?
SB: So I just want to sum up with saying that we have seen a high, high and increased usage of malware campaigns and other exploits targeting specifically OT networks. And that’s why we’re very focused on finding vulnerabilities before the attackers will find them. So my message to anyone is always patch. This is the most efficient way to overcome vulnerabilities and be alert.
LO: Great. Absolutely. Well, Sharon, thank you so much for joining us today on the Threatpost podcast and talking to us a little bit more about industrial control system security and these recent vulnerabilities.
SB: Yeah, sure. Happy to be here. And thank you very much, Lindsey.
LO: And to all of our listeners. Thank you for listening in to the Threatpost podcast today. If you have any questions or comments on industrial security, please reach out to us on our Twitter page @Threatpost and catch us on our next episode of the Threatpost podcast.
Also, check out our podcast microsite, where we go beyond the headlines on the latest news.