ClearEnergy ransomware can destroy process automation logics in critical infrastructure, SCADA and industrial control systems.

ClearEnergy-banner

Schneider Electric, Allen-Bradley, General Electric (GE) and more vendors are vulnerable to ClearEnergy ransomware.

Researchers at CRITIFENCE® Critical Infrastructure and SCADA/ICS Cyber Threats Research Group have demonstrated this week a new proof of concept ransomware attack aiming to erase (clear) the ladder logic diagram in Programmable Logic Controllers (PLCs). The ransomware a.k.a ClearEnergy affects a massive range of PLC models of world’s largest manufacturers of SCADA and Industrial Control Systems. This includes Schneider Electric Unity series PLCs and Unity OS from version 2.6 and later, other PLC models of leading vendors include GE and Allen-Bradley (MicroLogix family) which are also found to be vulnerable to the ransomware attack.ransomware attack.ransomware a.k.a ClearEnergy affects a massive range of PLC models of world’s largest manufacturers of SCADA and Industrial Control Systems. This includes Schneider Electric Unity series PLCs and Unity OS from version 2.6 and later, other PLC models of leading vendors include GE and Allen-Bradley (MicroLogix family) which are also found to be vulnerable to the ransomware attack.

Ransomware is a type of malware that infects computers and encrypts their content with strong encryption algorithms, and then demands a ransom to decrypt that data. “ClearEnergy attack is based on the most comprehensive and dangerous vulnerability that ever found in Critical Infrastructure, SCADA and ICS Systems, and affects a wide range of vulnerable products from different manufacturers and vendors. These attacks target the most important assets and critical infrastructure and not just because they are easy to attack but also hard to be recovered”. Says Brig. Gen. (ret.) Rami Ben Efraim, CEO at CRITIFENCE.

In 2016 we have seen a rise in ransomware, where the victims were businesses or public organizations that on one hand had poor security and on the other hand the alternative cost of losing business continuity was high. Last year there were reports of a targeted ransomware for PC and other workstation within critical infrastructure, SCADA and industrial control systems. A month ago, scientists from the School of Electrical and Computer Engineering in Georgia Institute of Technology have simulated a proof-of-concept ransomware attack (LogicLocker) in a limited scope designed to attack critical infrastructure, SCADA and industrial control systems.

ClearEnergy acts similarly to other malicious ransomware programs that infect computers and encrypts their content with strong encryption algorithms, and then demands a ransom to decrypt that data back to its original form, with one major difference. ClearEnergy is a malicious ransomware attack designed to target Critical Infrastructure and SCADA systems such nuclear and power plant facilities, water and waste facilities, transportation infrastructure and more.

“Although the codename ClearEnergy, the vulnerabilities behind ClearEnergy ransomware takes us to our worst nightmares where cyber-attacks meets critical infrastructure. Attackers can now take down our electricity, our water supply and our oil and gas infrastructure by compromising power plants, water dams and nuclear plants. Critical Infrastructure are the place in which terrorists, activists, criminals and state actors can make the biggest effect. They have the motivation, and ClearEnergy shows that they have also the opportunity.” Says Brig. Gen. (ret.) Rami Ben Efraim, CEO at CRITIFENCE.

Once ClearEnergy is executed on the victim machine it will search for vulnerable PLCs in order to grab the ladder logic diagram from the PLC and will try to upload it to a remote server. Finally ClearEnergy will start a timer that will trigger a process to wipe the logic diagram from all PLCs after one hour unless the victim will pay in order to cancel the timer and to stop the attack.

SCADA and Industrial Control Systems has been found to be weak in the recent years, against numerous types of attacks that result in damages in a form of loss of service which translate to a power outage, or sabotage. The damage that ClearEnergy attack can cause to the critical infrastructure is high since it can cause a power failure and other damages to field equipment, thus making the recovery process slow in most cases, and might even bring a plant to a halt.

ClearEnergy, which is based on vulnerabilities CVE-2017-6032 (SVE-82003203) and CVE-2017-6034 (SVE-82003204) that have been discovered by CRITIFENCE security researchers, disclosed profound security flaws in the UMAS protocol of the vendor Schneider Electric. UMAS protocol seems to suffer from critical vulnerabilities in the form of bad design of the protocol session key, which results in authentication bypass. “UMAS is a Kernel level protocol and an administrative control layer used in Unity series PLC and Unity OS from 2.6. It relies on the Modicon Modbus protocol, a common protocol in Critical Infrastructure, SCADA and industrial control systems and used to access both unallocated and allocated Memory from PLC to SCADA system. What worries our researchers is that it may not be entirely patched within the coming years, since it affecta a wide range of hardware and vendors.” Says Mr. Eran Goldstein, CTO and Founder of CRITIFENCE.

Following to the disclosure, Schneider Electric has confirmed that the Modicon family of PLCs products are vulnerable to the findings presented by CRITIFENCE and released an Important Cybersecurity Notification (SEVD-2017-065-01). ICS-CERT, Department of Homeland Security (DHS) released an important advisory earlier this morning ([April 11, 2017] ICSA-17-101-01). The basic flaws, which was confirmed by Schneider Electric, allows an attacker to guess a weak (1-byte length) session key easily (256 possibilities) or even to sniff it. Using the session key, the attacker is able to get a full control of the controller, to read controller’s program and rewriting it back with the malicious code.

“The recovery process from this type of cyber-attacks can be very hard and slow in most cases due to lack of management resources in the field of SCADA and process automation. Slow recovery process multiplied by the number of devices need be fixed, as well configuration restoration makes the recovery processes very painful”. Says Mr. Alexey Baltacov, Critical Infrastructure Architect at CRITIFENCE

“Recovering from such an attack would be a slow and tedious process, and prone to many failures. Every plant using PLC’s which is part of a production line and would have dozens of these devices all around the plant. Let’s assume that each PLC is indeed backed-up to its recent configuration. It would take a painstakingly long time to recover each and every one of them to its original status.” Says Mr. Eyal Benderski, Head of the Critical Infrastructure and SCADA/ICS Cyber Threats Research Group at CRITIFENCE. “This restoration process would take a long time, on which the plant would be completely shut down. The costs of that shut down could be substantial, and for critical processes it could affect for more than the down-time, as it is the case with energy plants. Consider a process which relies on keeping a constant temperature for a biological agent or chemical process. Breaking the process chain could require re-initialization that may be days and weeks long. Furthermore, since dealing with the OT network is much more complicated for operational reasons, on many occasions plants don’t even have up-to-date backups, which would require complete reconfiguration of the manufacturing process. Given these complications, plants would very much prefer paying the ransom than dealing with the minor chance that the backups will work as expected. Lastly, let’s assume the backups went on-air as soon as possible, what would prevent the same attack from recurring, even after paying?”

About the author:

CRITIFENCE is a leading Critical Infrastructure, SCADA and Industrial Control Systems cyber security firm. The company developed and provides SCADAGate+ unique passive cyber security technology and solutions designed for Critical Infrastructure, SCADA and Industrial Control Systems visibility and vulnerability assessment,  which allow to monitor, control and to analyze OT network cyber security events and vulnerabilities easily and entirely passively. CRITIFENCE development team and Critical Infrastructure and SCADA/ICS Cyber Threats Research Group combined from top experienced SCADA and cyber security experts and researchers of the IDF’s Technology & Intelligence Unit 8200 (Israel’s NSA) and the Israeli Air Force (IAF).

For more information about CRITIFENCE refer to: http://www.critifence.com

References

Vulnerabilities

CVE-2017-6032 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-6032

CVE-2017-6034 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-6034

SVE-82003203 http://www.critifence.com/sve/sve.php?id=82003203

SVE-82003204 http://www.critifence.com/sve/sve.php?id=82003204

Source code

ClearEnergy | UMASploit – https://github.com/0xICF/ClearEnergy

Advisories

Schneider Electric – SEVD-2017-065-01

ICS-CERT, Department of Homeland Security (DHS) – ICSA-17-101-01

 

News

SecurityAffairs – http://securityaffairs.co/wordpress/57731/malware/clearenergy-ransomware-scada.html

0xICF – https://0xicf.wordpress.com/2017/04/09/clearenergy-ransomware-can-destroy-process-automation-logics-in-critical-infrastructure-scada-and-industrial-control-systems/

VirusGuides – http://virusguides.com/clearenergy-ransomware-targets-critical-infrastructure-scada-industrial-control-systems/

CRITIFENCE – http://critifence.com/blog/clear_energy/

[CRITICAL] CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting. Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn’t immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users.

That patch is available here.

 

Issue Summary:

Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack. The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack. Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

 

Technical information:

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query. Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated. Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow. The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.

Exploitation:

Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact. As you can see in the below debugging session we are able to reliably control EIP/RIP.

(gdb) x/i $rip => 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req (gdb) x/a $rsp 0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042

When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril! Failed exploit indicators, due to ASLR, can range from:

  • Crash on free(ptr) where ptr is controlled by the attacker.
  • Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address.
  • Crash reading from memory pointed by a local overwritten variable.
  • Crash writing to memory on an attacker-controlled pointer.

We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development.

 

 

Credit:  Fermin J. Serna and Kevin Stadmeyer

Another Door to Windows | Hot Potato exploit

Microsoft Windows versions 7, 8, 10, Server 2008 and Server 2012 vulnerable to Hot Potato exploit which gives total control of PC/laptop to hackers

Security researchers from Foxglove Security have discovered that almost all recent versions of Microsoft’s Windows operating system are vulnerable to a privilege escalation exploit. By chaining together a series of known Windows security flaws, researchers from Foxglove Security have discovered a way to break into PCs/systems/laptops running on Windows 7/8/8.1/10 and Windows Server 2008/2010.

The Foxglove researchers have named the exploit as Hot Potato. Hot Potato relies on three different types of attacks, some of which were discovered back at the start of the new millennium, in 2000. By chaining these together, hackers can remotely gain complete access to the PCs/laptops running on above versions of Windows.

Surprisingly, some of the exploits were found way back in 2000 but have still not been patched by Microsoft, with the explanation that by patching them, the company would effectively break compatibility between the different versions of their operating system.

Hot Potato

Hot Potato is a sum of three different security issues with Windows operating system. One of the flaw lies in local NBNS (NetBIOS Name Service) spoofing technique that’s 100% effective. Potential hackers can use this flaw to set up fake WPAD (Web Proxy Auto-Discovery Protocol) proxy servers, and an attack against the Windows NTLM (NT LAN Manager) authentication protocol.

Exploiting these exploits in a chained manner allows the hackers to gain access to the PC/laptop by elevating an application’s permissions from the lowest rank to system-level privileges, the Windows analog for a Linux/Android root user’s permissions.

Foxglove researchers created their exploit on top of a proof-of-concept code released by Google’s Project Zero team in 2014 and have presented their findings at the ShmooCon security conference over the past weekend.

They have also posted proof-of-concept videos on YouTube in which the researchers break Windows versions such as 7, 8, 10, Server 2008 and Server 2012.

You can also access the proof of concept on Foxglove’s GitHub page here.

Mitigation

The researchers said that using SMB (Server Message Block) signing may theoretically block the attack. Other method to stop the NTNL relay attack is by enabling “Extended Protection for Authentication” in Windows.

 

 

Credit:  Vijay Prabhu, techworm