Review – Public ICS Disclosures – Week of 7-29-23 – Part 2

For Part 2 we have eight vendor updates for products from Broadcom (2), Fujitsu, Mitsubishi (2), Moxa (2), and Omron. Finally, we have 24 researcher reports for vulnerabilities in products from Inductive Automation (4), Triangle MicroWorks (12), and ZKTeco (8).

Updates

Broadcom Update #1 - Broadcom published an update for their Apache httpd advisory that was originally published on September 13^th, 2022.

Broadcom Update #2 - Broadcom published an update for their follow-redirects advisory that was originally published on September 13^th, 2023.

Fujitsu Update - JP-CERT published an update for their Si-R series advisory that was originally published on July 26^th, 2023.

Mitsubishi Update #1 - Mitsubishi published an update for their Genisis64 advisory that was originally published on July 19^th, 2023 and most recently updated on February 9^th, 2023.

Mitsubishi Update #2 - Mitsubishi published an update for their Genisis64 advisory that was originally published on December 13^th, 2022 and most recently updated on February 9^th, 2023.

Moxa Update #1 - Moxa published an update for their NPort 5110 Series advisory that was originally published on June 10^th, 2022 and most recently updated on July 28^th, 2023.

Moxa Update #2 - Moxa published an update for their multiple switch series advisory that was originally published on June 14^th, 2023 and most recently updated on July 7^th, 2023.

Omron Update - Omron published an update for their CX-Drive advisory that was originally published on April 24^th, 2023.

Researcher Reports

Inductive Automaton Reports - The Zero Day Initiative published four reports of individual vulnerabilities in the Inductive Automation Ignition product.

Triangle MicroWorks Reports - The Zero Day Initiative published 12 reports of individual vulnerabilities in the Triangle MicroWorks SCADA Gateway product.

ZKTeco Reports #1-4 - Claroty published four reports for individual vulnerabilities in the ZKTeco BioAccess product.

ZKTeco Reports #5-8 - Claroty published four reports for individual vulnerabilities in the ZKTeco BioTime product.

 

For more details about these disclosures, including summary of changes in advisories, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/public-ics-disclosures-week-of-7-bf5 - subscription required.

Review – Public ICS Disclosures – Week of 4-8-23 – Part 3

For Part 3, we have 35 vendor updates from Schneider (4) and Siemens (31). We also have a researcher report for products from Triangle Microworks. Finally, we have five exploits for products from Paradox Security, Palo Alto Networks, FortiGuard, Schneider Electric, and Franklin Fueling Systems.

Updates

Schneider Update #1 - Schneider published an update for their EcoStruxure™ Control Expert advisory that was originally published on January 10^th, 2023 and most recently updated on March 14^th, 2023.

Schneider Update #2 - Schneider published an update for their SCADAPack Workbench advisory that was originally published on March 28^th, 2023.

Schneider Update #3 - Schneider published an update for their CODESYS V3 Runtime that was originally published on January 11^th, 2022 and most recently updated on March 14^th, 2023.

Schneider Update #4 - Schneider published an update for their BadAlloc advisory that was originally published on November 9^th, 2021 and most recently updated on March 14^th, 2023.

Siemens Update #1 - Siemens published an update for their SNMP in Multiple Industrial Products advisory that was originally published on February 11^th, 2020 and most recently updated on June 14^th, 2022.

Siemens Update #2 - Siemens published an update for their RUGGEDCOM ROS advisory that was originally published on July 12^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #3 - Siemens published an update for their SIMATIC WinCC advisory that was originally published on November 9^th, 2021 and most recently updated on July 12^th, 2022.

Siemens Update #4 - Siemens published an update for their Industrial Products advisory that was originally published on February 28^th, 2022 and most recently updated on July 12^th, 2022.

Siemens Update #5 - Siemens published an update for their Polarion ALM advisory that was originally published on December 13^th, 2022.

Siemens Update #6 - Siemens published an update for their RUGGEDCOM ROS-based V4 advisory that was originally published on November 8^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #7 - Siemens published an update for their PROFINET-IO (PNIO) stack advisory that was originally published on November 11^th, 2020 and most recently updated on June 14^th, 2022.

Siemens Update #8 - Siemens published an update for their OpenSSL component advisory that was originally published on June 14^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #9 - Siemens published an update for their SCALANCE advisory that was originally published on August 9^th, 2022 and most recently updated on January 10^th, 2023.

Siemens Update #10 - Siemens published an update for their Teamcenter Visualization and JT2Go advisory that was originally published on December 13^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #11 - Siemens published an update for their SCALANCE X-200 and X-300/X408 advisory that was originally published on September 14^th, 2021 and most recently updated on March 12^th, 2022.

Siemens Update #12 - Siemens published an update for their SIMATIC CP 343-1 Advanced/CP-443-1 advisory that was originally published on November 21^st, 2016 and most recently updated on December 10^th, 2019.

Siemens Update #13 - Siemens published an update for their Industrial Products advisory that was originally published on March 20^th, 2018 and most recently updated on January 10^th, 2023.

Siemens Update #14 - Siemens published an update for their SIMATIC S7-400 CPU advisory that was originally published on March 12^th, 2022 an most recently updated on August 9^th, 2022.

Siemens Update #15 - Siemens published an update for their Web Interface of SCALANCE and RUGGEDCOM Products advisory that was originally published on October 11^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #16 - Siemens published an update for their SIMATIC NET CP advisory that was originally published on September 14^th, 2021 and most recently updated on June 14^th, 2022.

Siemens Update #17 - Siemens published an update for their Webserver of Industrial Products advisory that was originally published on April 9^th, 2019 and most recently updated on January 10^th, 2023.

Siemens Update #18 - Siemens published an update for their Web Server Login Page of Industrial Controllers advisory that was originally published on November 8^th, 2022 and most recently updated on January 10^th, 2023.

Siemens Update #19 - Siemens published an update for their  TCP SACK PANIC advisory that was originally published on September 10^th, 2019 and most recently update on June 14^th, 2022.

Siemens Update #20 - Siemens published an update for their RUGGEDCOM ROS advisory that was originally published on September 13^th, 2022 and most recently updated on November 8^th, 2022.

Siemens Update #21 - Siemens published an update for their PROFINET Stack advisory that was originally published on March 12^th, 2022 and most recently updated on February 14^th, 2023.

Siemens Update #22 - Siemens published an update for their SCALANCE advisory that was originally published on December 13^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #23 - Siemens published an update for their OpenSSL 3.0 advisory that was originally published on December 13^th, 2022.

Siemens Update #24 - Siemens published an update for their Industrial Products advisory that was originally published on December 13^th, 2022 and most recently updated on January 10^th, 2023.

Siemens Update #25 - Siemens published an update for their Industrial Real-Time Devices advisory that was originally published on October 8^th, 2019 and most recently updated on January 10^th, 2023.

Siemens Update #26 - Siemens published an update for their OPC Foundation advisory that was originally published on May 10^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #27 - Siemens published an update for their SCALANCE X advisory that was originally published on July 12^th, 2022.

Siemens Update #28 - Siemens published an update for their SIMATIC PCS 7 advisory that was originally published on February 11^th, 2020 and most recently updated on April 12^th, 2022.

Siemens Update #29 - Siemens published an update for their RUGGEDCOM ROS advisory that was originally published on March 8^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #30 - Siemens published an update for their OpenSSL advisory that was originally published on February 8^th, 2022 and most recently updated on March 14^th, 2023.

Siemens Update #31 - Siemens published an update for their VX-Works advisory that was originally published on March 14^th, 2020 and most recently updated on June 14^th, 2022.

Researcher Reports

Triangle Microworks Report - The Zero Day Initiative published a report that describes a remote code execution vulnerability in the Triangle Microworks SCADA Data Gateway.

Exploits

Paradox Security Exploit - Giorgi Dograshvili published an exploit for a code injection vulnerability in the Paradox IPR512 IP monitoring receiver.

Palo Alto Networks Exploit - OMURUGUR published an exploit for a stored cross-site scripting vulnerability in the Palo Alto Networks Cortex XSOAR product.

FortiGuard Exploit - Mohammed Adel published an exploit for an uncontrolled resource consumption vulnerability in the FortiGuard FortiRecorder.

Schneider Exploit - Parsa Rezaie Khiabanloo published an exploit for a directory traversal vulnerability in an inadequately identified (SCADA-vis?) Schneider product.

Franklin Fueling Exploit - Parsa Rezaie Khiabanloo published an exploit for an information disclosure vulnerability in the Franklin Fuel Systems TS-550.

 

For more details about these disclosures, including a brief summary of the changes made in the updates, please see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/public-ics-disclosures-week-of-4-015 - subscription required.

ICS-CERT Publishes to New Advisories

Today the DHS ICS-CERT published new advisories for products from Cogent and Triangle MicroWorks (TMW). Both advisories are based upon coordinated disclosures.

Cogent Advisory

This advisory addresses multiple vulnerabilities in the Cogent DataHub. The vulnerabilities were reported by Alain Homewood. Cogent has produced a new version of the application that addresses three of the four identified vulnerabilities and ICS-CERT reports that Homewood has verified the efficacy of the mitigation measures for those vulnerabilities.

The vulnerabilities are:

• Reflected cross-site scripting, CVE-2014-72038;

• Directory traversal, CVE-2014-59156;

• Password hash with insufficient computational effort, CVE-2014-32537; and

• Many known vulnerabilities in OpenSSL version 1.0.0D.

ICS-CERT reports that a low to moderately skilled attacker could exploit these vulnerabilities (three of them remotely) with a variety of potential effects. The new version does not address the third vulnerability listed above; Cogent advises that they do not plan to address this vulnerability due to “compatibility issues with existing systems”. They explain (and Homewood agrees according to the advisory) that an adequately strong password will be an effective mitigation of this vulnerability.

Triangle MicroWorks Advisory

This advisory addresses Crain-Sistrunk DNP3 vulnerabilities in TMW SCADA Data Gateway. It addresses the two standard vulnerabilities in serial and IP communications. In fact the wording of this advisory is nearly identical with an ICS-CERT advisory published last fall that covered both the devices included in this advisory as well as TMW’s DNP3 Source Code libraries.

Interestingly this advisory points us at a TMW document that documents the changes that are referenced in this advisory. Unfortunately, that document only reports the changes that were made last fall in response to the earlier advisory. Something odd is going on here and what it is isn’t clear from the ICS-CERT advisory. 

BTW: The Project Robus web page does not yet list this second TMW advisory. Looking at their tally it would seem that we still have seven more Crain-Sistrunk advisories to be published by ICS-CERT.

TMW Blog Comment

It has come to my attention that my recent post on the ‘late response from Triangle MicroWorks’ may have been based upon incomplete information.

First off I have been informed that there were earlier direct communications from TMW to their customers long before their most recent post about the ICS-CERT vulnerability on their web site. These communications were not made via their web site; that would not be surprising, particularly if they were made before the publication of the ICS-CERT advisory. That would, in fact, be something that ICS-CERT would encourage; allowing the customers a chance to take corrective actions before the vulnerability became public. That is the whole point of the coordinated disclosure process

Second, I have been told that there were earlier versions of the post that I talked about on the web site, but they were recently removed in a house cleaning action that all web sites periodically undergo. Since I don’t routinely check most vendor web sites (other than when an advisory is issued) I would normally not become aware of such posts.

I became aware of the most recent TMW post because of a social media mention. I based my blog response on the wording of the TMW statements in the post and the fact that there is no other mention of the vulnerability on their web site. It appears that that may not have been an adequate basis for making the judgment that I made.

If I misinterpreted the situation, I apologize to the management, staff and customers of TMW and would be more than willing to provide them space on my blog to fully correct my miss-interpretation of the situation.

A Late Response from Triangle Microworks

Readers of this blog are well familiar with the on-going issue of improper input validation vulnerabilities in a variety of DNP3 protocol products from a number of different suppliers. There was yet another ICS-CERT advisory published yesterday. Each of the disclosures in this family have been coordinated disclosures by Crain-Sistrunk that remained tightly held until the affected vendor had patches or upgrades in place to fix their specific vulnerability. Only then did ICS-CERT publish the advisory for that vendor’s vulnerability.

A Late Announcement

This makes the announcement earlier this week on the Triangle MicroWorks web site more than a little odd. This is the first mention of the ICS-CERT advisory on their web site since that advisory was issued back in August. According to ICS-CERT they had a verified (by Crain-Sistrunk) update available then (no link was provided, just a note to contact the company) to correct this vulnerability. So, why the delay?

Now I don’t know the folks at TMW and I don’t follow the business side of this issue, so I can’t answer that question with any certitude. But I can tell you what it looks like to me like an attempt to ignore the problem, hoping that they would never have to admit to their customers that they had made a mistake. They corrected the coding problems; they get attaboys for that. But those attaboys get wiped out by the awshit that they get for not being proactive about getting the word out to their customers so that they could fix the existing problems in the installed systems.

Blame Shifting

To make matters worse the announcement attempts to minimize the extent of the problem by noting that the vulnerability “can only be exploited by a hacker when the security perimeter for the SCADA Network has been breached”. So this makes the problem not a coding issue, but a problem with the customer’s implementation of security.

Now, to be fair, there is an ongoing debate within the control system security community about the topic of ‘insecure by design’ and whether or not security is a perimeter defense issue or whether it should be focused on the interior devices. Both sides in that debate have legitimate points in support of their arguments.

Unfortunately, many of the slave devices affected by this vulnerability are placed in locations where no one is going to install real physical security safeguards to provide a reasonable security perimeter behind which these vulnerable devices can operate with impunity. Pole mounted devices and devices in remote locations protected by a simple fence are particularly vulnerable to the serial port vulnerability reported by Crain-Sistrunk.

I suppose it is the customer’s decision to deploy these devices in locations where their security cannot be assured. And that is a risk-benefit analysis that only the system owners can make. But to make that decision they must be fully aware of the potential vulnerabilities that they are accepting.

Bigger Problem than Reported by ICS-CERT

There is another attaboy that TMW gets for information in this announcement. The original ICS-CERT advisory only reported vulnerabilities associated with the outstation source code library produced by TMW. According to this week’s notice:

“A similar vulnerability was discovered shortly after, which could affect customers using our DNP3 Master Source Code Library.”

Looking at the language used here it looks like TMW is self-reporting an expanded vulnerability that they discovered. I think that it is always a good thing for vendors to self-report vulnerabilities, it demonstrates an on-going commitment to increasing the security of their devices and code.

I look forward to seeing ICS-CERT update their TMW advisory to reflect the additional vulnerability.

DNP3 Application Note

So why would TMW be making this late statement about their corrected vulnerability if they had been trying to publicly ignore it for so long? It looks like the reason is related to last week’s release of the new DNP3 User Group application note addressing this exact issue. While many people don’t directly follow the ICS-CERT advisories, most anyone that would buy the various DNP3 code libraries from TMW would be expected to notice that announcement from the DNP3 Users Group.

In fact, yesterday TMW posted another announcement on their web site specifically about that topic. Interestingly they close that post with the following comment:

“We are pleased to report that the coding practices at Triangle MicroWorks already exceed these recommendations.”

I’m surprised that they didn’t add that their DNP3 libraries have been fuzz tested by an outside independent security research team; Crain-Sistrunk.

ICS-CERT Publishes Deceptively Simple Advisory

Today the DHS ICS-CERT published an advisory for twin improper input validation vulnerabilities in products from Triangle MicrWorks. The vulnerabilities were reported by Adam Crain and Chis Sistrunk in a coordinated disclosure.

The Advisory

ICS-CERT reports that the twin vulnerabilities exist separately in serial and IP communications. The serial version is only locally exploitable and the IP version may be remotely exploited. ICS-CERT reports that a higher skill level is required to exploit the serial version of the vulnerability because “physical access to the device or some amount of social engineering is required”. I’m not sure why social engineering skills are considered to be a ‘high skill level’ unless they have determined that advanced social engineering skills are required for the serial exploit.

According to ICS-CERT the successful exploit of either version of the vulnerability could result in a denial of service situation because the software could be sent “into an infinite loop” requiring a manual reset.

Triangle MicroWorks has produced an update and release notes to resolve the vulnerabilities. Actually a causal review of the release notes makes it clear that much (32 pages of much) more than just this vulnerability was fixed in this update. It makes good sense to fix multiple problems in a single update, but I have to wonder if the release was delayed to fix these security vulnerabilities or if the release of the security fix was delayed to fix other problems as well. ICS-CERT reports that Adam has validated the efficacy of the update.

The Rest of the Story (apologies to Paul Harvey)

I got an interesting email from Adam pointing out that this is a bigger issue than it may look like in the advisory. Adam notes:

“Note that this is a source code library. TMW has > 50% market share. We don't know where this code is deployed/sold and DHS lacks authority to force disclosure.”

Now this is not an uncommon problem. In fact, I have mentioned similar situations with a number of software vulnerabilities as have others. Fortunately (sarcasm alert) this is only a denial of service vulnerability. It’s not like it allows an attacker to execute arbitrary code, so it’s not a real problem (end sarcasm alert).

Adam makes a good point about the lack of authority of DHS, except that he’s making that lack of authority too specific in his complaint. Let’s face it, outside of the federal government, DHS (and most emphatically including ICS-CERT) has no cybersecurity authority to compel industry to do anything. At most they have the gentle power of persuasion and the threat of disclosure to try to modify the behavior of the advised (as opposed to regulated) industries.

If this had been an uncoordinated disclosure, Adam would have had exploit code posted on a web site somewhere and other researchers could have explored other DNP3 applications to see if the same exploit could be found on other systems. Without that that other researchers will just have to look at a variety of TCP packets to see what works on the Triangle MicroWorks supported systems  and then evaluate the rediscovered exploits (or maybe new ones, you never can tell) on other systems. That probably won’t be a significant delay.

This raises a couple of interesting questions:

How many of the ‘other’ researchers will notify the vendor in a coordinated disclosure versus selling the vulnerability to the highest bidder?

Has Triangle MicroWorks notified each of it customers that the vulnerability is affecting their systems?

How many of the downstream vendors do not have the  application expertise to adapt the Triangle MicroWorks update to their own system.