Today the DHS ICS-CERT published four advisories for vulnerabilities in control systems. Three were product specific for systems from Siemens, Mitsubishi and Iconics. One was for an open source protocol used by multiple vendors. Two of the advisories were initiated by ICS-CERT, one by a team of Malaysian researchers in a coordinated disclosure, and one by an anonymous researcher in an uncoordinated disclosure.
This advisory was initiated by ICS-CERT (needless to say in a coordinated disclosure) after discovering the vulnerability during an investigation concerning an unrelated product. This is an insecure ActiveX vulnerability in the GENESIS32 system. Interestingly the advisory never states that Iconics has produced a patch or upgrade for this vulnerability.
ICS-CERT reports that a moderately skilled attacker could exploit this vulnerability remotely, but nature of the vulnerability would require an authorized user to visit a specially crafted web site first. A successful exploitation could lead to the execution of arbitrary code.
An Iconics security document (that lists all 8 ICS-CERT Iconics’ advisories) reports that a patch has been developed and ICS-CERT is in the process of validating its efficacy. It also notes that the IcoLaunch.dll can be accessed via command line.
This advisory is also about an ActiveX vulnerability, this time in the McWorX application. The uncoordinated disclosure by Blake included proof-of-concept code was reported in an earlier ICS-CERT Alert. A patch is available for the affected version and newer versions do not include this vulnerability.
ICS-CERT reports that a moderately skilled attacker could use the publicly available exploit code to remotely exploit this vulnerability to execute arbitrary code.
The Mitsubishi patch download page explains that the patch loads a new version of IcoLaunch.dll, the same file that was a problem in the Iconics vulnerability. It would seem that ICS-CERT discovered the Iconics vulnerability while investigating the Mistubishi vulnerability. It makes me wonder what other vendor has used the same vulnerable version of IcoLaunch.dll in their product.
Mitsubishi also notes that the patch removes some functionality from the McWorX application. The report that they will work with individual customers to restore that functionality if necessary.
Those of you who follow @SCADAHacker @DigitalBond, or me on Twitter® will already have heard a discussion about this vulnerability as the Siemens ProductCERT published their alert on early Tuesday morning (US time). This advisory reports an uncontrolled resource consumption vulnerability in Rugged Com ROS devices. The vulnerability was discovered by Ling Toh Koh, Ng Yi Teng, Seyed Dawood Sajjadi Torshizi, Ryan Lee, and Ho Ping Hou of EV-Dynamic, Malaysia.
ICS-CERT reports that skilled attacker could remotely exploit this vulnerability to execute a DoS attack that would disable switching functionality until a cold reboot was executed. Siemens has developed a patch for one of the affected versions and continues to work on the others. ICS-CERT will update this advisory as Siemens produces the other patches.
Siemens is to be congratulated on their early public disclosure of this vulnerability even as much as ICS-CERT is to be castigated for their delay in their conveying this advisory to the US public.
NTP Reflection Advisory
This advisory is more than a little unusual. The vulnerability, a vulnerability to DoS attacks staged using Network Time Protocol (NTP) Reflection, has apparently been in use for some period of time. And the vulnerability is not found in a single device or application, but rather any number of products using the NTP service.
ICS-CERT reports that a low skilled attacker ‘would be able’ to remotely exploit this vulnerability remotely using publicly available ‘exploits’ to execute DoS attacks on various control systems. They go on to report that an upgrade that mitigates this vulnerability has been available since 2010.
I don’t know which is scarier the fact that this vulnerability remains uncorrected in so many systems that ICS-CERT was finally forced to report this vulnerability, or the fact that it has taken almost four years for ICS-CERT to finally report this vulnerability.