ICS/SCADA vendor discloses in-depth analysis of a recent targeted attack against one of its customers.
[UPDATED 12:50pmET with information from Schneider’s customer advisory issued today]
S4x18 CONFERENCE – Miami – Industrial control systems giant Schneider Electric discovered a zero-day privilege-escalation vulnerability in its Triconex Tricon safety-controller firmware which helped allow sophisticated hackers to wrest control of the emergency shutdown system in a targeted attack on one of its customers.
Researchers at Schneider also found a remote access Trojan (RAT) in the so-called TRITON/TRISIS malware that they say represents the first-ever RAT to infect safety-instrumented systems (SIS) equipment. Industrial sites such as oil and gas and water utilities typically run multiple SISes to independently monitor critical systems to ensure they are operating within acceptable safety thresholds, and when they are not, the SIS automatically shuts them down.
Schneider here today provided the first details of its investigation of the recently revealed TRITON/TRISIS attack that targeted a specific SIS used by one of its industrial customers. Two of the customer’s SIS controllers entered a failed safe mode that shut down the industrial process and ultimately led to the discovery of the malware.
“Once the malware was inside the controller, it injected the RAT into memory by exploiting a zero-day vulnerability in the firmware, and escalating its privileges” to do so, says Paul Forney, global cybersecurity architect for Schneider Electric’s product security office in North America, in an interview.
Schneider plans to release an update for the entire Version 10X firmware family. In the meantime the company has issued advisories for its affected customers as well as tools to detect and mitigate the attack.
Forney, here today at the S4x18 ICS/SCADA conference, publicly shared the first details of just how TRITON/TRISIS operated on the company’s Triconex Tricon safety-instrumented systems (SIS), resulting in the rare shutdown of the live safety systems. SIS systems are not typically under the domain of security teams, and operate under triple redundancy in case one system fails.
The victim organization was running Verison 10.3 of the Triconex firmware, according to Schneider, which declined to specify the name, location, or industry sector of the victim organization. But one security firm – Dragos Inc. – that studied the malware, says the victim is an industrial customer in the Middle East.
Teams of researchers from Dragos and FireEye’s Mandiant last month each published their own analysis of the malware used in the attack, noting that the smoking gun – a payload that would execute a cyber-physical attack – had not been found.
But it turns out TRITON/TRISIS was literally a fail and didn’t make it to an actual cyber-physical attack phase, according to Schneider’s analysis. “We now know a real attack probably never took place. There was a mistake in the development of the malware that accidentally caused the Triconex to … be tripped and taken to a safe state. As a result, this malware that was in development was uncovered,” says Andrew Kling, director of cyber security and software practices for Schneider Electric.
FireEye also noticed that there was a “bug” in the payload delivery system. “The script was successful, but it backed itself out. We don’t believe that was supposed to happen,” explains Blake Johnson, a consultant with Mandiant, a FireEye company.
Johnson says there was no other payload found that would have led to a full-blown attack. “They [the attackers] either had it or didn’t deploy it because they screwed it up … or they hadn’t created the capability yet.”
The researchers weren’t able to pinpoint the attacker’s ultimate goal, either. “The ultimate intent is speculation. We simply don’t know,” Kling says. “You can go from simple intellectual property theft, all the way up to Hollywood script material,” he says, alluding to a worst-case cyber-physical attack.
TRITON/TRISIS Up Close
Schneider obtained the malware from the victim’s infected controller system, and studied its behavior on the proprietary Triconex Tricon controller. The attackers had specifically targeted the victim’s controller and older firmware configuration, indicating that they were intimately familiar with the system. But still unknown is just how the attackers conducted the reconnaissance phase prior to the malware infection.
Schneider’s controller is based on proprietary hardware that runs on a PowerPC processor. “We run our own proprietary operating system on top of that, and that OS is not known to the public. So the research required to pull this [attack] off was substantial,” including reverse-engineering it, Forney says. “This bears resemblance to a nation-state, someone who was highly financed.”
The attackers also had knowledge of Schneider’s proprietary protocol for Tricon, which also is undocumented publicly, and used it to create their own library for sending commands to interact with Tricon, he says.
Forney points out that the malware technically had infected the safety controller, and the “attack itself would come much later” if it had not been found out.
TRITON/TRISIS is an attack framework made up of the two programs: one exploits the Triconex zero-day flaw to escalate user privileges and allowed the attacker to manipulate the firmware in RAM and then implant the RAT, the second program, according to Schneider.
“It’s running in the highest privilege of the machine, and that’s going to allow an attacker to interface with that RAT to do what it wants,” Forney explains.
The RAT basically is there awaiting instructions: to read or write in memory or a control program, for example. “Once it’s set up and ready to go the very moment [the attacker] wants the [safety] controller to not do what it’s intended to do,” Kling says.
For an attacker to leverage TRITON/TRISIS, he or she would need access to the safety network and control of a workstation on the network – such as the Triconex TriStation Terminal – and the Tricon memory-protection mode must be set to “PROGRAM,” he explains.
Schneider’s Forney and Kling say they have no knowledge of any other victims of the malware.
Game-Changer
The attack represents the first such incident to affect the OT engineering department, notes Rob Lee, CEO and founder of Dragos. “It’s not targeting the operational level of HMIs or SCADA devices,” he says, but instead at the targeting engineering systems to change the logic on a system dedicated to protecting physical environments and people.
“You’re going to see TRISIS have a longer-term impact than probably anything else for the engineering community,” he says.
The attack was a wakeup call for other ICS/SCADA vendors as well; their safety controller systems, too, can be juicy targets of sophisticated attackers. An attacker with this level of skill is now an industry-wide problem, notes Schneider’s Kling. “It could be any of our competitors,” targeted this way as well, he says.
An attack that manipulates the memory of a controller is something “no one saw” coming, adds Forney.
Schneider has shifted gears internally in the wake of the attack, updating its threat model for safety system attacks, and memory injection. “We need to adapt our procedures and development processes to adapt to this new reality, and we are actively doing that now,” Kling says.
Defense
While the Triconex Tricon firmware update is being “fast-tracked” by Schneider, the vendor in the meantime is providing defense and mitigation strategies for customers to thwart the attack. Once the firmware is ready, the vendor will send tech support teams onsite to “re-burn and re-flash” the firmware, Forney says.
Schneider has built TRISIS/TRITON detection tools for its support teams, and is providing customers detection and cleanup recommendations in new advisories issued today. Among the recommendations: ensure the physical memory-protection switch is in RUN mode and not PROGRAM mode (except during scheduled programming), which could leave it vulnerable to malicious code.
In its customer advisory, Schneider recommends:
- Ensure the cybersecurity features in Triconex solutions are always enabled.
- Safety systems must always be deployed on isolated networks.
- Physical controls should be in place so that no unauthorized person would have access to the safety controllers, peripheral safety equipment or the safety network.
- All controllers should reside in locked cabinets and never be left in the “PROGRAM” mode.
- All Tristation engineering workstations should be secured and never be connected to any network other than the safety network.
- All methods of mobile data exchange with the isolated safety network such as CDs, USB drives, DVD’s, etc. should be scanned before use in the Tristation engineering workstations or any node connected to this network.
- Laptops and PCs should always be properly verified to be virus and malware free before connection to the safety network or any Triconex controller.
- Operator stations should be configured to display an alarm whenever the Tricon key switch is in the “PROGRAM” mode.
But Reid Wightman, a vulnerability analyst at Dragos, warns that if an attacker can upload logic to the controller firmware, he or she can override the behavior of that physical switch. “Even if it’s in RUN mode, it can be tricked into believing it’s in PROGRAM mode and allowed to accept code.”
He says he’s studied multiple vendors’ embedded controllers, and most have security weaknesses in the firmware, including the use of third-party libraries. “You can’t trust a controller anymore,” he notes.
Related Content:
Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio
Article source: https://www.darkreading.com/vulnerabilities---threats/schneider-electric-triton-trisis-attack-used-0-day-flaw-in-its-safety-controller-system-and-a-rat/d/d-id/1330845?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple
