Review - 6 Advisories Published – 6-21-22

Today, CISA’s NCCIC-ICS published six control system security advisories for products from Siemens, Phoenix Contact (3), JTEKT, and Mitsubishi. All but the Mitsubishi vulnerabilities reported today by NCCIC-ICS were originally reported by Forescout’s Vedere Labs in their OT:ICEFALL report.

NOTE: Phoenix Contact republished an earlier, related advisory, that I will discuss this weekend.

OT-ICEFALL Report - “Vedere Labs has identified a set of 56 vulnerabilities affecting devices from 10 operational technology (OT) vendors that we are collectively calling OT:ICEFALL [link added].”

Siemens Advisory - This advisory discusses a use of client-side authentication vulnerability in the Siemens SIMATIC WinCC OA SCADA HMI system.

NOTE: ETM, the Siemens subsidiary that developed WinCC OA, published this article on the reported vulnerability disclosure/response process.

Phoenix Contact Advisory #1 - This advisory discusses a missing authentication for critical function vulnerability in the Phoenix Contact classic line industrial controllers.

Phoenix Contact Advisory #2 - This advisory discusses an insufficient verification of data authenticity vulnerability in the Phoenix Contact ProConOS software development kit.

Phoenix Contact Advisory #3 - This advisory discusses an insufficient verification of data authenticity vulnerability in the Phoenix Contact classic line industrial controllers.

JTEKT Advisory - This advisory discusses a missing authentication for critical function vulnerability in the JTEKT TOYOPUC PLCs.

Commentary

Back in 2012 when the original Project Basecamp disclosures (note most of the 2012 links no longer work) documented some of the problems that have been lumped into the term ‘insecure by design’, I had hoped that the control system vendor community would take a hard look at the security assumptions that they had made in designing their control system products. While a great deal of progress has occurred (just look at the vendor names that are not included in OT:ICEFALL report), too many vendors still assume that owner operators will (or even can) only use their devices in ‘secure networks’.

I am disappointed that NCCIC-ICS did not produce an alert based upon the OT:ICEFALL report and call out each of the vendors to report on their response. This is what the old ICS-CERT did (reluctantly to be sure) with the original Project Basecamp reports. In many ways, that Alert, did much to amplify the work that the researchers did and ended up expanding the industry’s work on increasing the basic security of control systems. The work is not done, but today’s advisories will help.

BTW: The original, mostly uncoordinated, Project Basecamp disclosures created a bit of controversy about coordinated disclosure. See my discussion about that controversy here.

 

For more details about these advisories, including a list of the 10 vendors identified in OT:ICEFALL, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/6-advisories-published-6-21-22 - subscription required.

February 2012 ICS Monthly Monitor

On Friday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published their February 2012 issue of the Monthly Monitor. This issue includes a brief description of a government facilities incident independently identified by ICS-CERT and a lengthy discussion about network-based intrusion detection systems (NIDS) for control systems.

Incident Description

The incident briefly described on the first page of the monitor deals with a government owned control system of a type frequently overlooked in the general discussion of industrial control systems, an environmental control system for a building. While not directly involved in the production of commercial products they may be used in an important support role in many manufacturing locations (clean rooms for instance).

In this instance ICS-CERT somehow (not discussed in the brief report for obvious reasons) detected the intrusion into the environmental control system of an unidentified state government building. Facility personnel had already detected unauthorized adjustments to the control system and had already reconfigured their system to remove internet access to the controls.

ICS-CERT determined that the access had been made through the Internet interface for the system even though it had been configured to require a password. The report does not note whether the password had been a default password, if it had been compromised or if it had been broken by a bruit-force attack.

The most interesting thing about this brief report is that ICS-CERT contacted the facility not the other way around. As with the ‘water system hack’ last year it is becoming increasingly evident that the services of ICS-CERT are not adequately known or facilities are reluctant to report incidents to the one government agency most likely to be able to help them deal with a control system intrusion or attack.

Situational Awareness

In the Situational Awareness article there is an informative write up about NIDS and two open source NIDS packages recently upgraded (SNORT) or being upgraded (Suricata) to be useful in detecting control systems intrusions. This information alone in the article makes it well worth reading, but the lengthy article also addresses two other ICS issues of at least equal importance; Project Basecamp and source code exfiltration.

Project Basecamp is certainly not new and it has been addressed by ICS-CERT in advisories and alerts, but this is the first time that ICS-CERT has actually described the Project Basecamp process and discussed its consequences (and yes, it does include the appropriate links to the source material). Nothing really new informationally here, but it is a valuable acknowledgement of the importance of Project Basecamp.

The recent public exposure of the source code for two Symantec products (Norton Anti-virus and PCAnywhere) is addressed in the portion of the article about source code. While these two specific incidents have been addressed in more depth elsewhere, this Monthly Monitor piece addresses the general potential importance of exfiltrating control system source code. While identification of system vulnerabilities is the most obvious problem with gaining access to the source code for any application this ICS-CERT write-up identifies an even scarier potential problem modifying the code to implant backdoors and other vulnerabilities and re-infiltrating the code on the vendor’s site for distribution. Similar problems could occur if doctored counterfeit copies of the system were sold on the black market.

The Situational Awareness article closes with a well-deserved plug for the ICS-CERT CSET Assessment Tool and the on-site assistance that ICS-CERT can provide for using that tool to conduct an in depth assessment of the security of a facility’s control system.

Another Good Monthly Monitor Issue

The other standard features of the Monthly Monitor provide a wealth of valuable ICS-CERT information (list of ICS-CERT alerts and advisories from February) and links to other sources of ICS security information. The plug for coordinated vulnerability disclosure includes even further expanded recognition of researchers who do not fully work ‘within the system’ on vulnerability disclosures by recognizing researchers who do assist in the validation of patches developed in response to their uncoordinated disclosures.

All in all this is another example of the type of open-source information sharing that should be the hallmark of any public-private partnership on ICS security.

Reader Comment: Basecamp Communications Devices

It took me a while, but I finally got a chance to ‘moderate’ a response to this weekend’s blog post on the Basecamp disclosure process from Dale Peterson; one of the drawbacks to traveling cross country by car is that you can’t do much work on the internet. Dale explains the reasoning for including the Koyo ECOM100 and notes that the Schweitzer alert was for a wireless communications device, the SEL 2032 Communications Processor.

As Dale points out, vulnerabilities in the communications nodes between the PLCs and the control system are essentially major vulnerabilities for the control system and the PLC; they can allow protected access to both. As such they were clearly fair game for analysis.

The only point that I was trying to make about the ECOM100 being a ‘ringer’ (and the same point should have been made about the Schweitzer device) is that the PLC vendors had clear public notice about what was going to happen with the research into their devices. Since they should have known about the disclosed vulnerabilities (especially the ones that were specifically designed into the systems), they have no cause to complain about the ‘uncoordinated disclosures’. They are the ones that put their customers at risk not Project Basecamp.

Unless the Project Basecamp team provided direct notification to Koyo and Schweitzer about their products being included in the evaluation, the same blanket dismissal of concerns does not apply. On the other hand, the process industry really does need to understand that these types of devices (and I assume that the same types of vulnerabilities will show up in many if not most of these types of devices currently in use) may provide a broad avenue of attack on control systems. This clearly needs to be recognized and addressed.

So with the caveat that the following does not apply if they received advanced notification of inclusion in the Project Basecamp investigation, I think that both Koyo and Schweitzer were poorly treated by an uncoordinated disclosure of their vulnerabilities. More importantly their customers may have been unduly put at risk by not allowing these two manufacturers a chance to correct the system defects before the vulnerabilities were made public.

Twenty lashes with an al dente noodle for each of the uncoordinated disclosures for these two manufacturers (again with an immediate pardon if they received advanced notification of inclusion in the process) to Dale Peterson for his unsportsmanlike conduct. On the other hand, I think that it is time to look at all of the devices and systems that we employ to control critical processes, so a small quiet kudo to Dale as a salve to his wounds for his efforts (and of course the hard work of the entire Project Basecamp team and supporters) to bring formal attention to this problem.

The Disclosure Debate – Basecamp Disclosures

I have been asked to weigh in on the ongoing debate about the recent PLC vulnerability disclosures by Digital Bond’s Project Basecamp. The apparent assumption behind the request is that since I am not a cybersecurity researcher, but rather a chemical facility security advocate, that I might have a different set of insights into the disclosure process. As I am almost always willing to provide my opinion on just about any topic, I could hardly turndown the request.

Ground Rules

First off I have to make clear that I have a professional relationship with Digital Bond. I periodically post on their blog about cybersecurity legislative matters. Dale Peterson has asked me to do so periodically, but he does not provide any remuneration beyond the access to a wider audience for my musings. He has personally made clear to me that I would have to really work hard to piss him off enough with any Project Basecamp criticisms to harm our professional relationship. That’s good to know, but it doesn’t really influence what I would write; people who know me well realize that I will express my professional opinions almost completely regardless of who will be upset by them or impressed by them.

Second, readers of this blog will almost certainly be aware that I generally come down on the side of full and open discussion of vulnerabilities. Over the last 4½ years I have described a number of potential physical vulnerabilities for chemical targets and discussed how they could most probably be successfully attacked by terrorists. I usually leave out critical details that only a well-trained terrorist or military man would be aware of so as not to encourage wannabes, but those details are not going to affect the response of defenders in any material fashion. And that is the key to the discussion of vulnerabilities on this blog; they are provided so that owners and operators of high-risk chemical facilities might better understand the risks they face.

Finally, I am not now, never have been, nor probably ever will be the owner of a control system. I have been a user as a process chemist, but I have never been responsible for the purchase, set up or protection of an industrial control system. It may be a subtle difference, but I don’t want anyone thinking that my musings in anyway represent the opinions of any portion of the chemical security community beyond the owner of this blog.

The Vulnerabilities Exist

The vulnerabilities that were discovered by Project Basecamp exist and have existed for some time. The Project Basecamp team went looking for these specific vulnerabilities because they exist in other PLCs, specifically the Siemens PLCs. And no one was really surprised that they were able to find these particular vulnerabilities.

The designers of these PLCs knew that these vulnerabilities were there. In many cases the vulnerabilities were apparently specifically designed into the equipment. The vendors could have corrected these vulnerabilities at any time.

Finally, Project Basecamp has been in the works for some time. Dale has been talking about what the team was going to be doing for quite some time. Nobody in the vendor community or the security researcher community or in the regulatory community should have been surprised by the results or the way in which they were communicated at the end of the Project.

Systems are at Risk

The facilities that use control systems that use these PLCs are at risk for potential attacks on their facilities employing the vulnerabilities that were reported by the Project Basecamp team. They have been at risk for such attacks since they first employed these devices. There has been some incremental increase in the level of that risk since Basecamp disclosures were made; how much of an increase no one really knows for sure.

The lack of surety is due to the fact that no one knows who else has been working on discovering the details behind these vulnerabilities and has already developed specific attack vectors using these vulnerabilities. In fact, using the Stuxnet model (or even the Duqu model) we don’t know how many facilities may have already been successfully attacked using these vulnerabilities.

Dale obviously selected a good team, but I would be extremely surprised if there weren’t hundreds of security researchers out there with skills at least as good as this team. Yes, I said hundreds. Do not forget that China and Korea (and probably Russia and India and Israel and …) have specifically gone about developing offensive cyber-warfare capabilities which would require developing thousands of cyber security research specialists; many of which would of necessity be focused on industrial control systems. And that’s not even considering the cyber-criminal underground that certainly exists.

The Upside

What has certainly increased is the awareness that these specific vulnerabilities exist and the methods to exploit them are now generally available. Any cyber-security contractor, ICS owner, or government regulator can use these tools to determine if a specific ICS installation is susceptible to attack using these vulnerabilities.

There will be some installations where other security measures already in place make an outside attack very difficult or perhaps impossible (I wouldn’t hold my breath waiting on that) to attack. There will be others where the local Junior High School computer nerd can own the facility. Most will fall somewhere in the middle between these two extremes.

Knowing the specific level of vulnerability and the mode of attack that could be employed, security controls can be put into place to mitigate (though certainly not eliminate) the risk of attack using these specific vectors. Most of these are well known and understood. ICS-CERT (and Digital Bond) have been talking about them for years.

Regulators should take specific note of the tools made available via the Project Basecamp disclosures. Any security inspection at a power transmission facility or high-risk chemical facility that does not use include the use of these tools to evaluate the security of the control systems employed at that facility cannot be called a real security inspection (Congress please note that this reality should be included in any ‘comprehensive cybersecurity legislation’ being developed in this session). ICS-CERT should immediately develop a training program for Federal, State and local government security inspectors in how to utilize these readily available tools to conduct such inspections.

The Downside

Sorry Dale. Your team has significantly lowered the knowledge threshold required to design and implement an attack on any control system using these devices. You have increased the number of potential attackers with the necessary skills to effect successful attacks using the tools that your team made possible. You are going to continue to catch some heat for that and it is certainly deserved. But you all knew that going in.

The Exception

Dale did slip a ringer in on us. Project Basecamp was advertised as a look at the vulnerabilities in PLCs. Including the Koyo ECOM100 was a bit of a surprise since it is not a PLC by any stretch of the imagination. I am surprised that no one has called Dale out on including this Ethernet connection device in the Project Basecamp investigation.

If they hadn’t found so many critical vulnerabilities in the ECOM100 I would have been one of the first to cry ‘Foul’. Realistically though, the communications between the PLCs and the control system are an important part of the operation of the PLCs. The wide spread implementation of Ethernet connections have made the modern use of the PLC possible; the older method of hardwiring each PLC was just too time consuming and the source of too much system downtime.

I only wish that Dale’s team had included a wireless server instead of an Ethernet device. These are becoming more widespread. In my opinion vulnerabilities in these servers potentially pose a much higher threat to the next generation of control systems as they may provide another undocumented link to the outside world.

The Way Forward

Cyber attackers will always respond quicker than system owners. But maybe we as a society need to have a public, very visible, successful attack on a modern control system. We need to understand that every tool has inherent risks associated with the tool. We require manufacturing facilities to have guards and safety devices in place to protect the workers from the inherent dangers associated with modern manufacturing equipment. Those guards and devices are now an integral part of the machine design, installation and maintenance process at modern manufacturing facilities. We really need to get to that same point with cyber-security tools.

So, maybe Project Basecamp disclosures will become the ICS version of ‘Unsafe at Any Speed’ or ‘The Silent Spring’ or even ‘The Jungle’; making the inherent vulnerabilities in modern industrial control systems more widely known. Industry never did appreciate Nader, Carlson or Sinclair, but society owes them all a large vote of thanks.

Thanks Dale.

ICS-CERT Publishes Five S4 Based Alerts Plus Two Other Alerts

On Friday the DHS ICS-CERT published 7 separate alerts, five of which referenced vulnerabilities that were publicly discussed at Digital Bond’s SCADA Security Scientific Symposium (S4) in Miami, FL. These alerts, combined with a similar alert published on Thursday, may mark just the tip of the iceberg as Dale Peterson noted on the DigitalBond.com blog that 30 students at a HMI hacking class before the actual symposium “were quickly finding 0days using ActiveX and File Format Fuzzing”.

Oh yes, the two other alerts. They were based upon uncoordinated disclosures by the Digital Security Research Group (DSecRG) for systems produced by WellinTech and WAGO.

S4 Alerts

The five S4 alerts issued Friday included a general alert for disclosures made during the Project Basecamp portion of S4. The alert notes that the reported vulnerabilities in multiple vendor products included “buffer overflows, backdoors, weak authentication and encryption, and other vulnerabilities that could allow an attacker to take control of the device and interfere or halt the process it controls” (page 1). The four other S4 related alerts dealt with specific vulnerabilities in systems from four separate vendors; those vendors were:

• Rockwell Automation

• Schneider Electric

• Koyo (Note: not a PLC vendor, but an Ethernet vendor that provides communications between PLCs and the actual control system)

• Schweitzer

Project Basecamp was a detailed search for and reporting of vulnerabilities in various PLC’s used by industrial control systems. Dale has become increasingly vocal over the last six months or so about his dissatisfaction at cybersecurity community’s disregard of the consequences of the insecure design of programmable logic controllers (PLC). In both his blog and in any other venue that would listen (or even pretend to listen) he has made it clear that everyone in the control system vendor and researcher community has known for at least 10 years that the basic PLC design has inherent cyber-security flaws that make them vulnerable to attack. These vulnerabilities were made painfully clear in the design of the Stuxnet virus.

Because the Stuxnet worm exploited vulnerabilities in the Siemens PLC, many of the Siemens security flaws have been publicly documented, while the rest of the industry breathed a sigh of relief that their systems weren’t being used by the Iran’s nuclear program. The whole point of Project Basecamp was to formally tell the world that Siemens was not alone in their ‘insecure by design’ problems.

That the world, at least the security professional side, has taken notice cannot be doubted. There has been significant discussions in a number of forums (on LinkedIn.com and on the SCADASec list for instance) and in the cyber related press. Unfortunately, most of that discussion has been about the public disclosure of the vulnerabilities (along with some Metasploit® modules published to aid in the exploit of those vulnerabilities) rather than on the potential effects of the vulnerabilities on real world control systems. Hopefully, the fait accompli provided by Dale and the Basecamp team will eventually allow for a more detailed discussion of the vulnerabilities and how to protect control systems from attack using those vulnerabilities.

ICS-CERT does make a valuable contribution (with a forgivable sideways slap at Project Basecamp) to that inevitable discussion in the general Basecamp alert. They note (page 2):

“This public release increases the potential for cyber attack on these devices, particularly if the devices are connected to the Internet. ICS-CERT reminds users that the use of readily available and generally free search tools (such as SHODAN and ERIPP) significantly reduces time and resources required to identify Internet facing control systems. In turn, hackers can use these tools combined with the exploit modules to identify and attack vulnerable control systems. Conversely, owners and operators can also use these same tools [emphasis added] to audit their assets for unsecured Internet facing devices.”

But, less anyone forget, the Iranian PLCs that were the Stuxnet target were not connected to the Internet, nor were their control systems. Many of the vulnerabilities reported by the Project Basecamp team will allow an attacker to exploit the vulnerabilities without having to target an internet connected PLC; it will require a higher skill level and more system knowledge. There are loads of attackers with the appropriate skills and system knowledge can be easily obtained via social engineering attacks. Internet-isolated control systems (if there are really such things in existence) are not safe from attacks based upon these vulnerabilities.

WellinTech Alert

The WellinTech alert provides initial information on a reported password encryption vulnerability in the KingSCADA product that could allow an attacker to read and use a user password, thus gaining user level access to a control system. Exploiting this vulnerability requires access to the SCADA server.

WAGO Alert

The WAGO alert concerns multiple vulnerabilities in the I/O System 750. The vulnerabilities include:

• Remote firmware download;

• Remote data leakage; and

• Remote access.

Interestingly a DSecRG press release notes that the WAGO disclosure of the 750 series controller vulnerabilities was made in support of Project Basecamp. Additionally the DSecRG web site notes two other control system vulnerabilities released by DSecRG on the same day. One deals with a default password vulnerability on Tecomat PLCs (more Project Basecamp fallout?) and an ActiveX vulnerability on an OPC system. I expect that we’ll see ICS-Alerts on these on Monday.