S4: Safety System Attack Details

Friday, January 19, 2018 @ 05:01 PM gHale

By Gregory Hale
More details emerged from an assault on a safety system at a critical infrastructure in the Middle East where an attacker deployed malware designed to manipulate industrial safety systems along with controlling the distributed control system.

During a greatly anticipated presentation at the S4x18 conference in Miami, researchers from Mandiant and Dragos and experts from Schneider Electric, which was the vendor of the affected system, revealed more information on the details of the August 4 attack – and just as important, what was missing from the attack.

RELATED STORIES
S4: Network Monitoring Champion
S4: Lean OT Security
S4: Open-Minded Security? Just Try
Safety System, DCS Attacked

The user suffered a shutdown of the facility and the controllers of the targeted Triconex safety system failed safe and during the initial investigation they noticed there were some suspicious things going on and that is when they found the malware. The safety instrumented system (SIS) engineering workstation was compromised and had the Triton (it is also called Trisis and HatMan) malware deployed on it and also the DCS was compromised, so it is possible to envision an attack where the bad guy has the ability to manipulate the DCS while reprogramming the SIS controllers.

In terms of the safety system, Blake Johnson, industrial control systems security consultant at Mandiant, said during a presentation at the conference, in the period leading up to the outage, some downloads had been performed.

“Downloads of code and application logic to a controller; the source of the downloads was from a legitimate engineering workstation that their engineers would use to make programming changes to a controller, but they knew from reviewing their change management documentation no legitimate changes were intended during the time period. This triggered a forensic review.”

That call led to the recovery of the forensic artifacts from the engineering workstation that contained the attack script as well as the libraries which was the communications framework.

“We knew the controllers had been targeted by the attackers and payload files had been used against them, but a review of the controllers themselves, did not show payloads resident in memory,” Johnson said. “It did show an additional program in memory. We knew they had been modified in some way and a payload had been developed, but at this early stage in the investigation, we did not know why there was no payload present on the targeted controllers. No payload was recovered from the attackers. It is either they had it and didn’t bring it because they experienced this unexpected failure or they were not in the attack lifecycle where they had it prepared yet. They had gotten to the point where they had a foothold in the SIS environment on this engineering workstation, and had essentially reached the point of escalating privilege. They believed they had the capability to escalate privilege on the controller.”

Big Chill
Johnson went on to mention a potential chilling thought.

“If their desired impact was to simply stop production at the facility, there was a single command in the script that would have required eight lines of code. If all they wanted to do is stop production, it would not have required the significant investment they made to build this expensive and flexible framework to interact with these controllers. We want to see this other payload, if it exists. To understand the attackers’ motivation, we really need to understand what that final payload would have been.”

In a move not often seen, the vendor of the Triconex safety system hit in the attack, Schneider Electric, came forward at the conference to reveal more details they found.

“The malware’s intent was to install a Remote Access Trojan (RAT),” said Andrew Kling, director of cyber security and architecture at Schneider Electric.

“We see the developers and attackers in this situation had unrestricted access to develop this malware. It looks like malware that was under development,” Kling said. “They clearly had malitent here. There was something malicious they were planning. They had high skill that produced a RAT that ultimately gave the attackers read/write (privileges).”

Kling went on to say the attack was designed for a specific make and model of the Tricon controller.

“This attack had all the hallmarks of a nation-state attack,” Kling said. “We are talking security level four with unlimited resources, unlimited skills, unlimited time.”

The attack would require either a physical presence to the network or remote access, he said.

“You need the ability to load the malware into the Tricon, which means there had to be some sort of computer, laptop or PC to have access. In this case, the Tristation terminal was actually the machine used to launch the attack. Our Tricons come with a memory protect mode so there is a switch on the front panel that allows you to protect the memory from being written to. One of the precursors to this attack is the fact the key switch has to be in program mode.” In this case, it was.

More Detail
In doing a deeper dive into the attack, Paul Forney, chief security architect at Schneider Electric, said the attackers developed a library of protocols the Tristation would normally use.

“That is what it used to download things into the controllers,” Forney said. “It was a program to set up the status register that was going to be used by the injector tool itself to find out if I am on the right controller, if I am with the right version of the firmware, it knew where it was going, it knew where it was targeting and if any of these things would fail, it would bail. It had no real error codes. It was intended to work. There was no doubt in my mind it did not intend to fail.”

One of the codes Forney looked into was the Inject.bin, which looked like any other control program on the Tricon.

“It is going to run on a scan cycle. Every time a scan executes, it is going to do something else. The first three steps are trivial, it needs to know it is in the right place, it needs to be able to take time doing it because it is a TMR (Triple Modular Redundant) setup so you have to be able to replicate between controllers and if there any fault in that, the fault will show up and the operator will see them. By the way, the intent was not to crash the controllers, but to have power over them. Inject.bin is going to run once and say good by. There is nothing else to do. In order to do what it did, it had to elevate privileges. Once it elevated its privilege, it found a Zero Day, which was previously undiscovered in this 16-year-old controller. It was able to take itself from the user mode to an elevated privilege where he can now read and write the firmware memory.”

The attacker had gotten in and was ready to go, but the problem was the attacker made a mistake and two of the controllers entered the fault state which meant it would force the system to shut down. The fault state they encountered was due to a diagnostic failure associated with the attacker logic replicated amongst the main processer blades of the Triconex controller chassis. The malware itself did not intend in that moment to cause a fault or exception, the Mandiant researchers said.

Looking for More Answers
“We don’t know the ultimate attack here,” Kling said. “We know how they got ready for it, but we don’t know the attack.

The attackers had gotten to a certain point, but were not able to complete the mission.

“What we have done here is basically we have taken the governor off your car,” Forney said of the attackers. “If you get a car it can do 100 mph, but if you take the governor off you can do 180.”

Kling had mentioned what Schneider is now doing in the wake of the attack:
• We recognize the safety industry demands perfection, we take this seriously.
• We are aware that through the investigation we have uncovered a vulnerability and we are addressing it.
• We have updated our threat models to accommodate for this change in our threatscape.
• We continue to work closely with DHS and our security partners on detection and remediation efforts.
• Involving worldwide customer tech support and services group to understand the malware and armed with the tools to determine infection and eradication.
• While this is a single incident involving the Tricon 3008 v 10.3, we are proactively monitoring for indicators of compromise at other sites.
• Test all currently supported versions of Triconex products against this version of malware – is it transferable? It is a toolkit, so the intent may have been transferability, but this sample is not.
• Continue to work with our partner security firms on other detection mechanisms.
• Reinforcing security message of securing the SIS, protecting the Tricons, using the memory protection locks.

‘Call to Action’
As an industry, Forney mentioned we need to work together as much as possible, sharing information along with emphasizing basic common sense when it comes to SIS security and ICS in general. In addition, he said, the industry needs to proactively monitor indicator of compromises at all sites and learn from this incident, where it is possible to modify our threat model to include this changing landscape. Everyone should also develop new security defensive techniques and technologies as required.

“As an industry going forward, a lot of people think of this as a wake-up call, but I don’t,” Forney said. “I think it is a call to action. I hope vendors and customers, along with people selling security products or control system products, open their eyes to see information sharing has got to go two ways. You can’t be sitting there sucking in information from whatever you have; you have to have the response part as well.”



Leave a Reply

You must be logged in to post a comment.