A Shocking Flaw

Here’s an all too often overlooked item in the security architecture of industrial networks.

Below is a diagram of an industrial network architecture we’ve seen in a number of places.

In the diagram, a PLC with multiple network interfaces, in this case a PROFINET-enabled Siemens S7-300 or a S7-1500, is used to connect to the SCADA network on one side, and on the other side – to the I/O network.

Let’s imagine the following scenario:

1. An attacker has gained access to a host in the SCADA network (10.0.0.x).
2. The attacker wants to directly attack the I/O devices at 192.168.0.x, in order to sabotage the industrial process.

The question is: What should the attacker do in order to reach the I/O devices?

Think about it, then scroll down to see the answer.

Here’s the diagram of the industrial network architecture:

If you answered “nothing”, that’s the correct answer.

The S7-300, S7-1500 and other controllers with multiple network interfaces are sometimes used to “separate” the SCADA and I/O networks.

However, there is no such separation. If you use this feature, from the perspective of the SCADA network, there’s full L2+ access to the I/O network, and vice-versa.

The PROFINET interface on the S7-1500 (for example, the S7-1511 PN model) is a network switch, allowing anyone from the SCADA network full access to the I/O network, and vice versa.

From the perspective of the attacker, the network is completely flat.

As documented in the manual entry for the S7-1500 PROFINET-enabled CPU:

Source: Siemens, S7-1500 CPU 1511-PN Manual

And as documented in the manual entry for the S7-300 PROFINET-enabled CPU:

Source: Siemens, S7-300 CPU 319-3 PN/DP Manual

How Cyber Attackers Manipulate this Flaw

All an attacker has to do in order to access the I/O network directly, is to take a device in the SCADA network, add an IP address in the I/O network and then communicate with the field devices (in the I/O network) over any protocol they choose (Ethernet, IP, TCP, UDP, ICMP, etc).

This means that for example, if you have PROFINET I/O modules running on the I/O network, they’re accessible from ANY IP on the SCADA network, both by L2 (direct Ethernet) and by L3 (IP).

If you use this topology and you trust the I/O network to be separate from the OT network, this is a major flaw in your architecture.

How to Check if your I/O Field Network is Accessible From your SCADA Network

1. Perform the test during maintenance windows or in production with caution. Contact SCADAfence support if you need help.
2. Find out what is the IP range for your I/O network / fieldbus.
3. Select an IP address that’s not in use, in the I/O network range.
4. Change the IP of a test machine in the SCADA network using the following command:

netsh int ipv4 add address "Local Area Connection" 192.168.0.253 255.255.255.0

1. Then, ping an I/O controller, a sensor, a PLC, or any other IP that answers pings in the I/O network. If you got a response back, your I/O network is flat together with your SCADA network.

How to Discover These Vulnerabilities Automatically

This flawed design has been discovered by the SCADAfence Platform: The platform has been used to monitor both the SCADA and I/O networks of a certain industrial facility. Although the I/O network was supposed to be segmented from the SCADA network, in the sensor installed in the SCADA network, the SCADAfence security teams have seen broadcasts originating from the I/O network. When the SCADAfence security teams inspected the topology further, they discovered that in contradiction with what the system integrator and OT team believed – the networks were connected and were completely flat.

How Many Networks are Separating Between I/O and SCADA Using A Network Switch?

For the purpose of this research, it was a network misconfiguration that the SCADAfence platform helped uncover. Nonetheless, this question is very important for OT & IoT network security.

This network architecture flaw is a very clear example of how network packet analysis is a fundamental technology for the security of OT and IoT networks.

If you want to try out the SCADAfence Platform and uncover all of the vulnerabilities in your OT network, we will be glad to help you. Book your free demo here: https://l.scadafence.com/schedule-a-demo-scadafence

Hey, I’m SCADAGirl.

I’m a cybersecurity superhero that ensures that OT & IoT networks are safe.

Here is my commentary on the latest headlines in OT & IoT security.

 

ICS Advisory (ICSA-20-224-04) Siemens SCALANCE, RUGGEDCOM 

SCADAfence Research – Siemens SCALANCE and RUGGEDCOM switches, as well as security network segmentation devices are exposed to a Remote Code Execution vulnerability. A successful exploitation can significantly lower the security of the target organization’s network by allowing attackers to access OT networks that are supposed to be protected by those devices.

Additionally, Siemens Desigo CC Windows Application, which is designed for controlling and programming Building Management Systems (BMS) is vulnerable to a Remote Code Execution vulnerability. A successful exploitation may result in the attackers controlling or sabotaging the BMS system.

Bugs in HDL Automation Expose IoT Devices to Remote Hijacking

SCADAfence Research  – New vulnerabilities were discovered in an automation system for smart homes and buildings that allowed taking over accounts belonging to other users and control associated devices. The vulnerabilities found in those devices might allow attackers to take control of the building’s air conditioning system, lightning and more. For more on BMS security, click here.

Vulnerable Perimeter Devices: A Huge Attack Surface

SCADAfence Research – JSOF, a local team of cybersecurity researchers, released the second whitepaper on their DNS client exploitation vulnerability (CVE-2020-11901) that got CVSS score of 9.1. This was the vulnerability that was demonstrated in their video. They show this vulnerability to be really severe but in my opinion it is less severe than they market it. The vulnerability is the DNS client of target devices. Because most of the affected devices don’t use DNS at all (i.e,PLCs / OT devices / Medical devices) generally use direct IP addresses to communicate – not DNS hostnames, thus it is not possible to attack them. Also, if some of them do send DNS queries, you have to be in some sort of MITM to see them and send them a response with an exploit.

The latest vulnerabilities in various gateway servers possess a threat to organizations who didn’t patch. Research shows the various gateways exposed to the internet – F5 Big-IP (1M devices), Citrix NetScalar Gateway (80K devices), Palo Alto Global Protect (60K devices), Microsoft Remote Desktop Gateway (40K devices), amongst others. For more on IoT security, click here.

ICS Advisory (ICSA-20-212-02) Mitsubishi Electric Multiple Factory Automation Engineering Software Products

SCADAfence Research – Numerous Mitsubishi Engineering Software Products are vulnerable to remote code execution and denial of service vulnerabilities – A total of 3 vulnerabilities were discovered. Among the software impacted are Mitsubishi’s PLC programming software GX Works2 and GX Works3. Also other network configuration software are impacted. Successful exploitation of this vulnerability may allow threat actors to take over engineering workstations. For more vulnerabilities that we found in Mitsubishi Electric products, click here.

ICS Advisory (ICSA-20-210-02) Softing Industrial Automation OPC

SCADAfence Research – A buffer overflow allowing Remote Code Execution influencing all Softing Industrial Automation OPC products (OPC servers for PLCs & networks) was discovered. OPC is a way of communication in OT networks, thus, successful exploitation may result in controlling the OPC servers. Attackers leveraging this can cause sabotage to industrial processes.

 

Overview

As the NSA urges companies to secure their industrial networks, two vulnerabilities were found in Schneider Electric Triconex SIS devices. Both of the vulnerabilities reside within the Tricon Communication Module (TCM) which connects the Triconex SIS to Ethernet networks. The first vulnerability (CVE-2020-7486) is a Denial of Service attack that causes the TCM to enter a fault state, and the latter (CVE-2020-7491), a more serious one, is a legacy debug port exposed to the network, that allows attackers to get root style privileges on the TCM, and upload malicious firmware to it.

While the vulnerabilities themselves are severe, exploiting them will not directly impact the SIS operation. In case of a failure in a plant, SIS operations will work normally. 

Most SIS devices use the key switch methodology, where a physical switch controls the state of the SIS. When the SIS is operating normally, this switch should be in the ‘Run’ state. In order to harm the SIS from the TCM by uploading malicious code to it, the SIS key switch must first be physically changed to ‘Program’ or ‘Remote’.

 

Hiding Malicious Activity, As Seen In Stuxnet

Leveraging CVE-2020-7491, an attacker can write its own firmware to the TCM. Because the TCM resides between the SIS and the OT Ethernet network, malicious code installed on it TCM can be used to hide or modify activity sent or received by the SIS.

SIS HMIs are usually connected to the Ethernet network. These HMIs can be fed incorrect information from the TCM module, causing fake SIS data to be displayed in the HMI. 

Moreover, the TCM could hide the malicious code blocks from the programming software, rendering it undetected from engineers. 

Similar practices have been seen in the past in the Stuxnet campaign, hooking network code to hide malicious activity. A rootkit was installed on PCs with engineering software and a part of its operation was to hide the infected PLC code blocks from being seen in the programming software.
Moreover, Stuxnet prevented operators from noticing its set of instructions sent to peripheral devices (centrifuges, etc) by hiding those instructions from the process image output. These monitoring and HMIs devices were fed incorrect information showing that the PLCs are functioning normally, and no out of the ordinary instructions were sent to them.

 

Mitigation Recommendations

1. There are countless vulnerabilities in industrial equipment, and more vulnerabilities are discovered every day. A safety net in the form of a passive, industrial network traffic monitoring system (such as the SCADAfence Platform), will be able to slow down all attacks, enabling you to respond, and will detect most attack vectors. Such products increase the cost of an attack, in a way that makes the attack irrelevant for most attackers. See our webinar on Efficient Industrial Cyber Security Programs for more information.
2. Update the TCM modules using the latest firmware from Schneider Electric. Updates can be found in the official advisory – Legacy Triconex  Product Vulnerabilities
3. Make sure SIS devices are behind a firewall and only communicating in ports they should communicate in. Both vulnerabilities were found in undocumented services communicating on non standard ports.

SigRed Overview

SigRed is a vulnerability that was exposed yesterday (July 14th 2020) by the security firm Check Point. Successful exploitation of the vulnerability could lead to a malicious actor gaining control of the organizational DNS server, often leading in turn to domain administrator privileges, allowing the attacker complete control of any domain-joined Windows machine.

The vulnerability lies in Microsoft’s DNS server and could be triggered from either inside the network, by an attacker controlling an internal asset, or, in some conditions (as stated below), from outside the network, making it even more dangerous.

As Microsoft Active Directory is deeply integrated with DNS services, the DNS service is virtually always enabled on domain controllers. An attacker gaining control of a domain controller through the DNS service could lead to a complete compromise of the network, allowing the attacker complete access to all Windows machines joined to the domain, whether patched or not, using the domain administrator privileges of the compromised domain controller. Even if the compromised DNS server does not serve as a domain controller, It is likely that the Domain administrator credentials are stored locally and can be retrieved by a tool such as Mimikaktz. Furthermore, the attacker is also able to return custom responses to DNS, allowing man-in-the-middle for unencrypted protocols, such as HTTP, FTP and others.

Exploitation Methods

The precondition for this exploit is that the local organization’s DNS server is configured to recursively resolve queries to external domains using root-hints. This configuration is the default configuration when the DNS service is installed.

Exploitation is either impossible or further complicated in the following cases:

1. The DNS server is an authoritative server of a DNS zone and does not recursively resolve queries to other domains.
2. The DNS server is part of an independent DNS infrastructure, such as an air-gapped network. In such a case, the attacker will need either write access to the DNS server or existing control over an authoritative DNS server serving an arbitrary zone on the network.
3. The DNS server is configured to use a forwarder server (such as 8.8.8.8 or 1.1.1.1) instead of directly using root hints. In such a case, the attacker will need to propagate the attack through the chain of recursive calls, which has not yet proven possible but cannot be completely discarded.

The vulnerability can be exploited in two ways:

1. From inside the network:
   An attacker that has a hold of an asset inside the network, can compromise the organization’s local DNS server by sending queries for external domain records which are controlled by the attacker (e.g. http://www.evil.com). Such a request will cause the local DNS server to communicate directly with the attacker’s DNS server. A malicious crafted response from the attacker’s server could lead the attacker to compromise the local DNS server.
2. From outside the network:
   An attacker can send a malicious link to a user inside the network to a website it controls (via e-mail, for example). Once the user opens the link in either Microsoft Edge Legacy or Internet Explorer (does not apply to Google Chrome, Mozilla Firefox or Microsoft Edge Chromium, not tested on other browsers), a malicious web page is sent back to the client that causes the client itself to perform a series of DNS queries to the local organization’s DNS server, that in turn, would query the attacker’s DNS server, at which point the DNS server can be compromised in the same manner as presented above.

 

Exploitability in OT Networks

Most OT networks have Windows endpoints that are used for process control, technical maintenance and others. An attacker successfully exploiting this vulnerability from either inside or outside the network can gain domain administrator privileges, allowing full access to all domain-joined workstations and servers even if already patched.
At this point, the attacker will be able to install ransomware, malware, steal information, disrupt OT operations and/or access any machine in the domain for any purpose.

As many OT networks are slower to patch systems than IT networks, they are exposed for a longer period of time, allowing attackers to exploit this vulnerability. As a successful exploitation often results in domain administrator privileges, a single unpatched DNS server is sufficient to compromise the entire network, even if all other DNS servers are already patched.

Mitigation Recommendations

Microsoft has released a patch (July 14th 2020) to the vulnerability. We urge everyone to update their Microsoft Windows Servers as soon as possible.

If for any reason one is unable to currently patch its Windows Servers, running the following command would limit the DNS response size to 0xFF00 (65280), and will prevent the vulnerability from running

 

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters” /v “TcpReceivePacketSize” /t REG_DWORD /d 0xFF00 /f && net stop DNS && net start DNS

As part of our mission to secure the world’s OT, IoT and Cyber Physical infrastructures, we invest resources into offensive research of vulnerabilities and attack techniques.

Ripple20 are 19 vulnerabilities revealed by Israeli firm JSOF that affect millions of OT and IOT devices. The vulnerabilities reside in a TCP/IP stack developed by Treck, Inc. The TCP/IP stack is widely used by manufacturers in the OT and IoT industries and thus affects a tremendous amount of devices.

Among the affected devices are Cisco Routers, HP Printers, Digi IoT devices, PLCs by Rockwell Automation and many more. Official advisories by companies who confirmed having affected devices can be found here, in the “More Information” section.

The most critical vulnerabilities are three that can cause a stable Remote Code Execution (CVE-2020-11896, CVE-2020-11897, CVE-2020-11901) and another that can cause the target device’s memory heap to be leaked (CVE-2020-11898).

On behalf of our customers, we set out to explore the real impact of these vulnerabilities, which we’re now sharing with the public.

The research has been conducted by researchers Maayan Fishelov and Dan Haim, and has been managed by SCADAfence’s Co-Founder and CTO, Ofer Shaked.

Exploitability Research
We set out to check the exploitability of these vulnerabilities, starting with CVE-2020-11898 (the heap memory leak vulnerability), one of the 19 published vulnerabilities.

We created a Python POC script that is based on JSOF official whitepaper for this vulnerability. According to JSOF, the implementation is very similar to CVE-2020-11896, which is an RCE vulnerability that is described in the whitepaper. Also mentioned about the RCE vulnerability: “Variants of this Issue can be triggered to cause a Denial of Service or a persistent Denial of Service, requiring a hard reset.”

Trial Results:
Test 1 target: Samsung ProXpress printer model SL-M4070FR firmware version V4.00.02.18 MAY-08-2017. This device is vulnerable according to the HP Advisory.

Test 1 result: The printer’s network crashed and required a hard reset to recover. We were unable to reproduce the heap memory leak as described, and this vulnerability would have been tagged as unauthenticated remote DoS instead, on this specific printer.

Test 2 target: HP printer model M130fw. This device is vulnerable according to the HP Advisory.

Test 2 result: Although reported as vulnerable by the manufacturer, we were unable to reproduce the vulnerability, and we believe that this device isn’t affected by this vulnerability. We believe that’s because the IPinIP feature isn’t enabled on this printer, which we’ve verified with a specially crafted packet.

Test 3 target: Undisclosed at this stage due to disclosure guidelines. We will reveal this finding in the near future.

Test 3 result: We found an unreported vendor and device, on which we can use CVE-2020-11898 to remotely leak 368 bytes from the device’s heap, disclosing sensitive information. No patch is available for this device. Due to our strict policy of using Google’s Responsible Disclosure, we’ve reported this to the manufacturer, to allow them to make a patch available prior to the publication date.

Key Takeaways
We’ve confirmed the exploitability vulnerabilities on our IoT lab devices.

On the negative side: The vulnerabilities exist on additional products that are unknown to the public. Attackers are likely to use this information gap to attack networks.
On the positive side: Some devices that are reported as affected by the manufacturers are actually not affected, or are affected by other vulnerabilities. It might require attackers to tailor their exploits to specific products, increasing the cost of exploitation, and prevent them from using the vulnerability on products that are reported as vulnerable.

SCADAfence Research Recommendations
Check your asset inventory and vulnerability assessment solutions for unpatched products affected by Ripple20.
The SCADAfence Platform creates an asset inventory with product and software versions passively and actively, and allows you to manage your CVEs across all embedded and Windows devices.
Prioritize patching or other mitigation measures based on: Exposure to the internet, exposure to insecure networks (business LAN and others), criticality of the asset.
This prioritization can automatically be obtained from tools such as the SCADAfence Platform.
Detect exploitation based on network traffic analysis.
The SCADAfence Platform detects usage of these exploits in network activity by searching for patterns that indicate usage of this vulnerability in the TCP/IP communications.
If you have any questions or concerns about Ripple20, please contact us and we’ll be happy to assist you and share our knowledge with you or with your security experts.