Public ICS Disclosures – Week of 06-23-18

This week we have a vendor advisory and two updates of previously issued advisories from Siemens. Additionally, OSIsoft released a new version of their PI SDK 2018 that, according to the release notes, addresses (among other issues) “potential security issues in PI SDK code as identified by Synopsis Static Analysis (Coverity)”.

Siemens Advisory

This advisory describes “service of the affected products listening on all of the host’s network interfaces on either port 4884/TCP, 5885/TCP, or port 5886/TCP could allow an attacker to either exfiltrate limited data from the system or to execute code with Microsoft Windows user permissions”. The vulnerability was reported by Chris Bellows and HD Moore from Atredis Partners and Austin Scott from San Diego Gas and Electric. Siemens has provided new versions for some of the affected products to mitigate the vulnerability and identified work arounds for others. There is no indication that any of the researchers have been provided an opportunity to verify the efficacy of the fix.

RAPIDLab Update

This update provides new information on two vulnerabilities that was previously reported by Siemens on June 12^th, 2018. The new information is an acknowledgement that the vulnerabilities were reported by Oran Avraham from MEDIGATE. This advisory has not been reported by ICS-CERT.

Spectre and Meltdown Update

This update provides new information on the Spectre and Meltdown vulnerabilities in Industrial Products that was last updated on May 29^th,  2018. The new information provides new version and mitigation information for HMI Panels with SIMATIC WinCC V14.

Commentary

You have to give OSIsoft credit for turning to an outside agency (Coverity) to have static code analysis done on their product. This independent evaluation is an example of going the extra mile in secure code development. What is not clear, however, from the release notes on this product is whether or not the code issues being corrected existed in the earlier versions of the development kit.

If the corrected vulnerabilities were in earlier versions, I would have preferred to see an enumeration of those vulnerabilities in a security advisory so that users could conduct a proper risk assessment to see if their situation necessitated an immediate upgrade to this newer version. OSIsoft has a strong history of identifying and correcting security issues, so I suspect that they felt that either the vulnerabilities were related just to new code or that they vulnerabilities in the previous code were so minor as to not require specific notification.

ICS-CERT Updates Advantech Advisory and Publishes New Advisory

The afternoon the DHS ICS-CERT updated the Advantech advisory that they published last week. Additionally a new advisory was published for vulnerabilities in an Adcon telemetry gateway.

Advantech Update

This update corrects the name of the researcher who reported the vulnerability in an uncoordinated disclosure. The researcher is now being reported as HD Moore. The confusion apparently arose because Tod Beardsley authored the blog post that publicly disclosed the vulnerability, but even that post credited HD Moore with the discovery.

Adcon Advisory

This advisory describes multiple vulnerabilities in the Adcon Telemetry A840 Telemetry Gateway Base Station. The vulnerabilities were reported by Aditya K. Sood. Adcon has contacted all known customers to offer an upgrade to a more secure and stable version. There is no indication that Sood has verified that the newer version is free of the indicated vulnerabilities.

The vulnerabilities are:

• Hard-coded credentials - CVE-2015-7930;

• Improper authentication - CVE-2015-7931;

• Clear text transmission of sensitive information - CVE-2015-7932; and

• Information exposure - CVE-2015-7934

ICS-CERT reports that a relatively unskilled attacker could remotely exploit these vulnerabilities to gain administrative access to the target.

The reason for the unusual mitigation measure is that Adcon describes the affected device as obsolete and no longer supports the device.

ICS-CERT Publishes Another Siemens Advisory

Today ICS-CERT published an advisory for an improper access control vulnerability in the Siemens’ interface cards used to connect workstations to PROFINET IO. The vulnerability was reported by Christopher Scheuring and Jürgen Bilberger from Daimler TSS GmbH in a coordinated disclosure.

This Vulnerability

ICS-CERT notes that a relatively low skilled attacker could remotely exploit this vulnerability to execute a DoS attack or execute arbitrary code. The Siemens security advisory for this vulnerability notes that the vulnerability is exploited by sending specially crafted packets to network port 17185/UDP. They recommend that the devices only be deployed on trusted networks.

Siemens has developed a firmware patch that closes the default debugging port that underlies the vulnerability. Once again ICS-CERT does not provide a comment that the firmware patch efficacy has been evaluated by the original researchers or ICS-CERT. Again, we are left to wonder if this is an editorial oversight or if there are questions about the effectiveness of the patch.

Siemens ProductCERT published an advisory on this vulnerability on February 13^th and last updated it on February 18^th. Here it is more than a month later and ICS-CERT is just now getting around to publishing their advisory.

Another Siemens Vulnerability

I don’t routinely check the Siemens ProductCERT web site unless there is an ICS-CERT report on a Siemens product; there are just too many web sites and so little time. Today I found another vulnerability reported bySiemens back in February that has yet to be acknowledged by ICS-CERT. This one has to do with multiple stack-based buffer overflow vulnerabilities in the OZW and OZS web servers for the Siemens building control systems. The vulnerabilities would allow DoS attacks and remote code execution.

These vulnerabilities wer reported by HD Moore of Rapid7. Actually the vulnerabilities exist in a third-party library (libupnp) for the UPnP protocol. Rapid7 has produced a Metasploit modules for some of the vulnerabilities. This is a standard procedure for Rapid7 to publish exploit code for the vulnerabilities that they identify after the vendor has had a chance to publish a fix for the vulnerability.

Since these vulnerabilities exist in a third-party application they may affect a large number of other products that use the UPnP protocol and the libupnp library.