HatMan Update Published – 03-01-19

Today the DHS NCCIC-ICS published an update to their malware analysis report (MAR) for HatMan; the safety system malware. The MAR was originally published on December 18^th, 2017 and previously updated on April 10^th, 2018. The update includes an updated YARA signature to identify a custom, Windows-based remote deployment tool that threat actors may have used.

NOTE: A number of minor formatting changes and a few inconsequential wording changes were also made in the document.

ICS-CERT Publishes 2 Advisories and 4 Updates

Yesterday the DHS ICS-CERT published a control system security advisory for products from Lantech. They also published a medical device security advisory for products from Philips. Additionally, they updated four previously published security advisories for products from Siemens (2), Nari, and Schneider.

Lantech Advisory

This advisory describes two vulnerabilities in the Lantech IDS 2102 Ethernet device server. The vulnerabilities were reported by Florian Adamsky. Lantech has not responded to ICS-CERT on these vulnerabilities.

The two reported vulnerabilities are:

• Improper input validation - CVE-2018-8869; and

• Stack-based buffer overflow - CVE-2018-8865

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to execute arbitrary code on the system through crafting malicious input.

Philips Advisory

This advisory describes three vulnerabilities in the Philips Brilliance CT Scanners. These vulnerabilities were self-reported. Philips has a new version that mitigates the vulnerabilities.

The three reported vulnerabilities are:

• Execution with unnecessary privilege - CVE-2018-8853;

• Exposure of resources to the wrong sphere - CVE-2018-8861; and

• Use of hard-coded credentials - CVE-2018-8857

ICS-CERT reports that a relatively low-skilled attacker with uncharacterized access could exploit these vulnerabilities to execute software or to view/update files including patient health information (PHI), directories, or system configuration.

NOTE: These vulnerabilities were not reported on the FDA Medical Device Safety Communications web site.

PROFINET Update

This update provides additional information on an advisory that was originally published on May 9^th, 2017 and updated on June 15, 2017,on July 25^th, 2017, on August 17^th, 2017, on October 10^th, on November 14^th,  November 28^th, 2017, January 18^th, 2018, January 25^th, 2018, January 27^th, 2018 and most recently on March 6^th, 2018. The new information includes updated version information and links to new versions for:

• SIMATIC CP 343-1 Std; and

• CP 343-1 Lean

Industrial Products Update

This update provides additional information on an advisory that was originally published on May 9^th, 2017 and updated on June 15, 2017,on July 25^th, 2017, on August 17^th, 2017, on October 10^th, on November 14^th, November 28^th and most recently February 27^th, 2018. The new information includes updated version information and links to new versions for:

• SINAMICS G130;

• SINAMICS G150;

• SINAMICS S120; and

• SINAMICS S150

These two updates were published yesterday by Siemens. Siemens also announced three new advisories (here, here, and here) and one additional update (here). I suspect that ICS-CERT will publish their advisories and updates next week.

Nari Update

This update provides additional information on an advisory that was originally published on January 25^th, 2018. Nari has released a new version that mitigates the vulnerability. There is no indication that the researchers from Kaspersky labs that initially reported the vulnerability have been provided an opportunity to verify the efficacy of the fix. When ICS-CERT published their initial report they had received no response from Nari.

Schneider Update

This update provides additional information on an advisory that was originally published on April 17^th, 2018. The new information includes:

• Revises attacker characterization (now “high skill level”);

• Changed CVSS base score to 9.0 (from 10.0) and the CVSS vector string for vulnerability #1;

• Changed the CVSS vector string for vulnerability #2; and

• Completely re-wrote mitigations section to include links to Schneider advisory and ICS-CERT Yara rule

ICS-CERT Updates HatMan Attack Report

Yesterday the DHS ICS-CERT updated their Malware Analysis Report on the HatMan ( or TRITON or TRISIS depending on which analysis you are looking at) attack on a Schneider  Triconex Tricon safety shutdown system installation in Saudi Arabia. While this is labeled as an ‘update’ it is closer to a complete re-write of the original document. The new information comes from a joint investigation by ICS-CERT and Schneider.

This is a technical report about the processes involved in the HatMan malware. It does include a mention of how the newly reported Schneider Triconex vulnerabilities were used by the malware. I will leave to more technically qualified personnel the task of reviewing the technical information provided in the report.

Having said that, there is one important point made about the operation of the malware on page 16. Under section 5.3.5 the report states:

“This code is run when the compromised TS protocol command is received and provides RAT-like functionality. Most importantly, it allows an actor to read and write memory—including within the in-memory firmware region—and execute arbitrary code regardless of the key switch position, including “RUN.” This allows an actor to effect changes on the controller while it is in full operation, not just while it is being reprogrammed.”

This may be the critical portion of the malware because it bypasses one of the primary protections designed into safety instrumented systems, essentially the manual safety switch. This type of protection is used in a number of control system elements (particularly PLCs) and is supposed to provide a level of control over the reprogramability of the devices. Being able to subvert this control re-emphasizes the ‘insecure by design’ nature of PLCs in particular. It is not clear from this report whether the techniques used in the HatMan malware against the Triconex devices would be adaptable to overcoming this safety switch feature in other systems.

Section 7 of the report, “Detection/Mitigation”, is well worth reading as a stand alone document. The statement about Yara rules, a standard detection tool advocated by ICS-CERT in many instances, should be read and memorized by researchers as a caution about relying on any specific tool:

“This is not a reliable method for detection, as the files may or may not be present on any workstation, and such a rule cannot be used on a Tricon controller itself; however, it could be useful for detection with agent-based detection systems or for scanning for artifacts.

And the final paragraph is probably the best summation of the current state of control system security that I have seen:

“Ultimately, the best mitigation strategy for this malware—and others of the same sort—is to employ defense in depth and follow any relevant best practices. Rather than solely attempting to protect vulnerable targets—such as the Triconex devices targeted by HatMan—one prevents an attacker from ever reaching them.”

Publicly Disclosed ICS Vulnerabilities – Week of 12-23-17

This week we have two vendor notifications that were not covered by ICS-CERT. These were for products from Siemens and ABB.

Siemens Update

Siemens announced another update to their July advisory about vulnerabilities in their SIPROTEC 4 and SIPROTEC Compact devices. ICS-CERT updated their advisory for the previous Siemens update, but has not done so for this one. I suspect this is a holiday delay.

Siemens is providing updated version information and mitigation measures for their SIPROTEC 7UT686.

ABB Advisory

Joel Langill provided a link to an ABB security advisory linked to the TRITON/TRISIS/HATMAN malware. While the TTH attack did not involve any ABB products, the company notes that “conceptually a similar attack can be leveraged against any safety system with a sufficiently similar design concept”. The advisory then goes on to provide a link to a product specific advisory (registration required) for the ABB System 800xA High Integrity safety instrumented system.

Since I am not a registered user I do not have access to the advice provided by ABB but I suspect that it pretty much reiterates standard security protocols for the device. That is not a bad thing in view of some the lapses reported in both the Dragos and FireEye reports. In fact, it might be a good idea for all vendors of safety instrumented systems to review those two reports and provide a security update for their products that emphasizes the lessons learned in the Saudi attack.

ICS-CERT Publishes Malware Report on ‘HatMan’ (TRITON or TRISIS)

Today the DHS published their malware report on HatMan the recently reported attack on a safety-instrumented-system. This is essentially the same information that was provided in the earlier FireEye and Dragos report. ICS-CERT did, however, include a link to the Schneider advisory on the malware.

The ICS-CERT report makes an interesting observation (pg 1):

“This report will discuss the malware as though it is entirely functional. We are aware that the malware may currently have bugs—due to descriptions of how it is behaving—that prevent it from effecting its desired changes. Though this report presents a “worst case scenario,” it should be considered accurate. We have no reason to suspect that the malware’s creators have not fixed its bugs, or that a functional copy does not exist somewhere that we have not yet seen.”

The report provides a copy of a Yara Rule for the detection of the three components of the HatMan malware. ICS-CERT prefaces this with the following warning:

“In addition, a YARA rule that matches the three binary components—trilog.exe, inject.bin, and imain.bin—is included as an appendix. This is not necessarily a reliable method for detection, as the files may or may not be present on any workstation, and such a rule cannot be used on a Triconex controller itself; however, it could be useful for detection with agent-based detection systems or for scanning for artifacts.”