Tag Archives: SCADA

VPNFilter: Overview and removal

====================
Update: 24th October 2018:
====================
Researchers from Cisco’s Talos team have discovered further capabilities of this malware. As detailed below the 3rd stage of the malware features:

Provides plugins for the RAT (defined below in the original post) to extend its functionality.

However, the team was able to determine the following extra capabilities:

  1. Packet sniffing (obtain information from passing data packets (defined) on a network connection)
  2. JavaScript (defined) injection used to deliver exploit (a small piece of software used to trigger a known vulnerability to the advantage of an attacker) to a compromised device (most likely a router).
  3. Encrypted tunnelling (defined) to hide data the malware steals as well as the existing command and control data traffic.
  4. Creating network maps (defined)
  5. Remote connection/administration via SSH (Secure Shell)(defined)
  6. Port forwarding (defined)
  7. Create SOCK5 (defined) proxies (defined)
  8. DDoS (defined)

The good news about this malware is that from the Talos team’s research it does not appear that any malware samples remain active. However; they caution it is not possible to assume that this malware has finished its malicious actions and the possibility of its return remains.

Thank you.

====================
Update: 20th June 2018:
====================
If you would prefer a video or a podcast of how to remove this malware from your router, this Sophos blog post provides links to both. The video is hosted on Facebook but a Facebook account isn’t required to view it. Sophos also provide an archive of previous videos on the same Facebook page.

Thank you.

====================
Update: 6th June 2018:
====================
The Cisco Talos team have provided an updated list of known affected routers. I have added these to the list below with “(new)” indicating a new device on the existing list. I have also updated the malware removal advice to provide easier to follow steps.

Thank you.

====================
Original Post:
====================
In late May; a strain of malware known as VPNFilter affecting routers from the vendors listed below was publicly disclosed by the Cisco Talos team:

Affected vendors:
Asus RT-AC66U (new)
Asus RT-N10 (new)
Asus RT-N10E (new)
Asus RT-N10U (new)
Asus RT-N56U (new)
Asus RT-N66U (new)
D-Link DES-1210-08P (new)
D-Link DIR-300 (new)
D-Link DIR-300A (new)
D-Link DSR-250N (new)
D-Link DSR-500N (new)
D-Link DSR-1000 (new)
D-Link DSR-1000N (new)
Huawei HG8245 (new)
Linksys E1200
Linksys E2500
Linksys E3000 (new)
Linksys E3200 (new)
Linksys E4200 (new)
Linksys RV082 (new)
Linksys WRVS4400N
Mikrotik CCR1009 (new)
Mikrotik Cloud Core Router (CCR) CCR1016
Mikrotik CCR1036
Mikrotik CCR1072
Mikrotik CRS109 (new)
Mikrotik CRS112 (new)
Mikrotik CRS125 (new)
Mikrotik RB411 (new)
Mikrotik RB450 (new)
Mikrotik RB750 (new)
Mikrotik RB911 (new)
Mikrotik RB921 (new)
Mikrotik RB941 (new)
Mikrotik RB951 (new)
Mikrotik RB952 (new)
Mikrotik RB960 (new)
Mikrotik RB962 (new)
Mikrotik RB1100 (new)
Mikrotik RB1200 (new)
Mikrotik RB2011 (new)
Mikrotik RB3011 (new)
Mikrotik RB Groove (new)
Mikrotik RB Omnitik (new)
Mikrotik STX5 (new)
Netgear DG834 (new)
Netgear DGN1000 (new)
Netgear DGN2200
Netgear DGN3500 (new)
Netgear FVS318N (new)
Netgear MBRN3000 (new)
Netgear R6400
Netgear R7000
Netgear R8000
Netgear WNR1000
Netgear WNR2000
Netgear WNR2200 (new)
Netgear WNR4000 (new)
Netgear WNDR3700 (new)
Netgear WNDR4000 (new)
Netgear WNDR4300 (new)
Netgear WNDR4300-TN (new)
Netgear UTM50 (new)
QNAP TS251
QNAP TS439 Pro
Other QNAP NAS devices running QTS software
TP-Link R600VPN
TP-Link TL-WR741ND (new)
TP-Link TL-WR841N (new)
Ubiquiti NSM2 (new)
Ubiquiti PBE M5 (new)
UPVEL Unknown Models* (new)
ZTE ZXHN H108N (new)

Why should this malware be considered important?
The authors (thought to be a group funded by a nation state) of this malware are using it to hijack vulnerable routers (500,000 are known to have been compromised across 54 countries) for possible use in cyberattacks against the Ukraine. Indeed, the malware more recently began seeking out Ukrainian routers specifically. The Ukrainian Secret Service issued a security alert on this on the 23rd of May.

The malware has the ability to do so by utilising previously publicly disclosed (defined) vulnerabilities to gain access and persistence (namely remaining present after the router is powered off and back on) within these routers. Last week the FBI took control of this botnet and are now working to clean up the affected devices.

The malware is very sophisticated and can persist within a router even if the router is powered off and back on (becoming the second malware to have this ability, the first being the Hide and Seek botnet). The malware is made up of 3 stages:

Stage 1: Is responsible for the persistence (mentioned above).
Stage 2: Providing the capabilities of a remote access Trojan (RAT)(defined)
Stage 3: Provides plugins for the RAT to extend it’s functionality.

The malware also has the capability to do the following:

  1. Wipe the firmware (see Aside below for a definition) of routers rendering them useless
  2. Inspect the data traffic passing through the router (with the possible intention of obtaining credentials passing over the wire to gain access to sensitive networks)
  3. Attempt to locate ICS/SCADA devices (defined) on the same network as the router by seeking out port 502 traffic, namely the Modbus protocol (defined) with the option of deploying further malware
  4. Communicate via the Tor network (definition in the Aside below).

How can I protect my devices from this malware?
The FBI are asking anyone who suspects their internet router to be infected to first reboot it (turn on and off the router). This will cause an infected device to check-in with the now under FBI control C&C (command and control, C2 (defined) server to provide them with a better overview of the numbers of infected devices.

To completely remove the malware; reset the device to factory defaults (this won’t harm a non-infected either but please ensure you have the necessary settings to hand to re-input them into the router, your internet service provider (ISP) will be able to help with this). This will remove stage 1 of the malware (stage 2 and 3 are removed by turning the router on an off).

To prevent re-infection: Cisco Talos’ team recommendations are available from this link. Moreover the US CERT provide recommendations here and here. Symantec’s recommendations are provided here (especially for Mikrotik and QNAP devices).

Further advisories from router manufacturers are as follows (their advice should supersede any other advice for your router model since they know their own devices the best):

Linksys
MiktroTik
Netgear
QNAP
TP-Link

Further recommendations from Sophos are:

  • Check with your vendor or ISP to find out how to get your router to do a firmware update.
  • Turn off remote administration unless you really need it
  • Choose strong password(s) for your router
  • Use HTTPS website where you can

A very useful and easy to follow step by step walk through of removing this malware by BleepingComputer is available from this link with useful guidance for multiple router models.

Thank you.

=======================
References:
New VPNFilter malware targets at least 500K networking devices worldwide : Cisco Talos team
=======================

=======================
Aside:
What is firmware?
Firmware is semi-permanent embedded software code that allows a device to carry out its function by having the low-level hardware carry out useful sequences of events.

What is The Onion Router (Tor)?
The Onion Router (Tor) is an open source (defined) project with the goal of protecting your privacy by passing your web browsing activity through a series of anonymous relies spread across the internet. These relays act like proxy servers which encrypt and randomly pass the traffic they receive from relay to relay.

This web of proxies is sometimes referred to as the Dark web (a portion of the internet only accessible using the Tor network). This makes tracing the source of the source almost impossible.
=======================

Mitigating the Increasing Risk Facing Critical Infrastructure and the Internet of Things

With attackers and malware authors extending their reach to more and more areas of our everyday lives, both companies and individuals need to take steps to improve the security of their equipment/devices. It’s not just devices such as thermometers (while important) in our homes at risk; devices that impact health and safety as well as entire communities and economies are being / or will be targeted.

For example, last month a cyber-attack took place in Ukraine that while it only lasted approximately 1 hour, served to cause a power outage in an entire district of Kiev. The on-going investigation into this attack believes it to be the same attackers responsible for the December 2015 attack (that attack affected approximately 250,000 people for up to 6 hours).

In a similar manner, a smaller energy company (at an undisclosed location) was a victim of the Samsam ransomware (defined). The attackers initially compromised the web server and used a privilege escalation vulnerability (defined) to install further malware and spread throughout the network. The attackers demanded 1 Bitcoin per infected system. The firm paid the ransom and received a decryption key that didn’t work.

Fortunately, this energy company had a working backup and was back online after 2 days. The root cause of infection? Their network not being separated by a DMZ (defined) from their industrial networks. This Dark Reading article also details 2 further examples of businesses affected who use industrial systems namely a manufacturing plant and a power plant. Both were located in Brazil.

Mark Stacey of RSA’s incident response team says that while nation states have not yet employed ransomware in industrial systems, it will certainly happen. He cites the example of a dam, where the disabling of equipment may not demand a large ransom compared to the act of encrypting the data required for its normal operation.

Former US National Security Official Richard Clarke is suggesting the use of a tried and tested means of increasing the security of all deployed industrial control systems. As it is very difficult convincing those on the Board of Directors to provide budget for something that has not happened/may not happen, he suggests employing an approach similar to that of the Y2K bug. This would require introducing regulations that require all devices after a given date be in a secured state against cyber-attack. He advocates electric power, connected cars and healthcare providers follow this approach and notes that without regulation “none of this is going to happen.” Since these regulations would apply to all ICS/SCADA (defined) vendors, they would also not loose competitiveness

With security analysts predicting further compromises of ICS/SCADA equipment this year, we need to better protect this infrastructure.

For enterprises and businesses, the regulations proposed above should assist with securing IoT and ICS/SCADA devices. However, this is just the beginning. This scanner from Beyond Trust is another great start. As that article mentions the FTC is offering $100,000 to “a company that can discover an innovative way of managing and patching IoT devices.” Securing IoT devices is not an easy problem to solve.

However, progress is happening with securing critical infrastructure and Internet of Things (IoT)(defined) devices. For example, please find below resources/recommendations, tools and products that can help protect these systems and devices.

How can we better secure ICS/SCADA devices?
These devices power our critical infrastructure e.g. power, gas, communications, water filtration etc. The US ICS-CERT has a detailed list of recommendations available from the following links:

ICS CERT Recommended Practices
ICS-CERT Secure Architecture Design
ICS Defense In-Depth (PDF)

An ICS-CERT overview of the types of vulnerabilities that these systems face.

Securing IoT devices in industry
Free IoT Vulnerability Scanner Hunts Enterprise Threats (Dark Reading.com)
Defending the Grid
Network and IoT to underpin Trend Micro’s 2017 strategy

Securing IoT in the medical sector/businesses
Hospitals are under attack in 2016 (Kaspersky SecureList)
Fooling the Smart City (Kaspersky SecureList)

Recommendations for consumer IoT devices are the following
My previous recommendations on securing IoT devices
Blog Post Shout Out: New Wireless Routers Enhance Internet of Things Protection
Securing Your Smart TV
8 tips to secure those IoT devices (Network World)
Who Makes the IoT Things Under Attack? (Krebs on Security)

=======================
I hope that you find the above resources useful for securing ICS/SCADA as well as IoT devices that are very likely a target this year.

Thank you.

Yokogawa Electric Corp. Releases Industrial Control System Security Updates

Late last week the Yokogawa Electric Corporation released security updates for its industrial control systems to address 3 critical CVEs (defined). These products provide management and control functions for industrial systems as well as providing event analysis.

Each of these security vulnerabilities involves a stack overflow (please see Aside below for a definition). 2 of these vulnerabilities can be used by a remote attacker to cause a denial of service issue (defined) while the remaining vulnerability can enable a remote attacker to execute arbitrary code (carry out any action they choose).

Why Should These Issues Be Considered Important?
Since these products control large industrial systems e.g. the types used in pumping stations, power plants and large manufacturing plants there is the potential for these attacks to have physical consequences/destruction.

How Can I Protect Myself From These Issues?
Please follow the instructions within this ICS CERT security advisory (specifically the Mitigation section) to update any affected Yokogawa industrial products that you may be using. A full list of the affected products is also provided within that advisory.

Thank you.

=======================
Aside:
What is a stack overflow?

A stack is continuous block of memory. It is similar to a buffer (defined: please see the Aside within that post) which are used by functions (defined: please see the Aside within that post). These functions are part of a wider/larger program. The stack is a data structure (a method of organizing data).

Stacks are different to other data structures in that new items are added to the top of the stack (using a PUSH operation) and are removed from the bottom of the stack (using a POP operation). This is known formally as a Last In First Out (LIFO) data structure. Stacks grow/increase in size as more items are added to them but they grow from upper memory (higher values) to lower areas of memory (i.e. they grow from the top down as opposed to the bottom up).

Note that the PUSH and POP operations above correspond to the names of instructions to carry out these tasks in assembly language (defined).

Now that a stack has been described using the figure below I will explain how a stack overflow occurs:

Using some C code if we declare a string of length 20 but actually store 80 characters (shown as Function Variable Name within the figure below) rather than the 20 characters allocated we will cause a buffer overflow.

Stack_Overflow

If we make all of the characters within the string be the letter C (which is 0x43 in hexadecimal) when the buffer overflows it will overwrite both the values of EBP and EIP. While I mentioned that stacks grow into lower locations in memory, EBP and EIP will be overwritten since that the space that was allocated to them will instead be used by the 80 character string that we declared above. These registers will contain the letter “C” represented in memory as 0x43434343, as mentioned above.

In assembly language the EBP (extended base pointer) register points to the beginning of the local environment for a function and represents the base of the current stack frame. The ESP (extended stack pointer) points to the top of the stack (which is a lower memory address than the base of the stack).

Finally the EIP (extended instruction pointer) register contains the address of the original location in the overall program code where a function was called from so that the program can return to that location when that function has carried out it’s task. This address is known as the return address. As mentioned in previous blog posts (here and here) the goal of an attacker is to overwrite this return address with the address of their choice, usually pointing to shellcode (defined) that will exploit a vulnerability allowing them to carry out any action they choose which will usually consist of elevating their privilege as high as possible (root level on Linux/Unix/Apple Mac OS X and kernel/system level on Windows are preferred) and then using that privilege to install a backdoor (defined).

With the address within the EIP overwritten by the buffer overflow (which the attacker has been careful to ensure it is a value of their choice), when the function attempts to return to the original location from where it was called, it will instead return to the location the attackers wishes. When this happens the actions of the attacker’s choice (mentioned above) will be carried out.

If our program also contained a function such as printf() and this was used to print the values of the Parameters shown in the figure it too would encounter an issue since those parameters have been overwritten by our overflow. If their values were examined using a debugger such as GDB, they would contain 0x43434343, namely the letter C which was mentioned above.

As mentioned in previous blog posts (here and here) modern operating systems have built-in defences against such stack based overflows. In addition, Address Space Layout Randomization (ASLR)(defined) protects against these overflows since the attacker should not be able to accurately predict the memory address to place within the EIP register when they trigger an overflow. In addition, the memory locations of the EBP and ESP registers would also be randomized.

My thanks to the following references which assisted in the creation of this explanation:

Stack based buffer overflow Exploitation Tutorial by Saif El-Sherei
Exploiting Software: How to Break Code (Greg Hoglund and Gary McGraw) Addison-Wesley, 2004
=======================
Some sample C code that illustrates the text/description given above would be the following:

#include string.h
/*Declare the necessary string library (string.h) for the function that we will call. Please ensure to use the correct placeholder brackets on each side of string.h, namely <> I can't insert these directly into this post due to how WordPress interprets code*/
int main(argc, char *argv[])
{
char overflowString[20]; //declare a 20 byte string
//Copy 80 letter “Cs” into the above string
strcpy(overflowString, "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC");
return 0; /*Since our main function is declared as above it must return an integer value. We will return 0 for simplicity.*/
}

=======================

Siemens Issues Security Updates for SIMATIC HMI Devices and Software

In late August a set of security updates was made available by Siemens for its SIMATIC HMI devices, SIMATIC WinCC Runtime Advanced software, SIMATIC WinCC v7 software and SIMATIC NET PC-Software V12 and V13.

The HMI (Human Machine Interface) devices allow a user to easily interface with industrial control and supervisory control and data acquisition (SCADA) systems via widescreen displays and multi-touch devices. The SIMATIC WinCC Runtime Advanced and Professional software provide this capability. The SIMATIC NET PC-Software is required for communication between a controller (SIMATIC S7 controller) and PC-based solutions (e.g., SIMATIC WinCC).

These updates address 3 remotely exploitable CVEs (defined) which include resource exhaustion (defined), a man-in-the-middle (MITM) attack (defined) and password-hashing (defined) implementation flaws.

The resource exhaustion vulnerability could be exploited by an attacker if they were located on the network connection between an HMI panel and a PLC (i.e. a man-in-the-middle (MITM) attack) and they could send network packets to the HMI over TCP port 102. Such specifically crafted packets would result in a denial of service (defined) issue for these devices.

The separate man in the middle category of attack mentioned above involves a similar means of attack but this time the attacker is located between the PLCs and their communication partners allowing the attacker to both intercept the packets between these devices and to modify them.

Finally the password hashing vulnerability involves the attacker using the password hashes obtained through another means to grant themselves the same usage rights as the rightful users of those passwords to access SIMATIC WinCC and SIMATIC PCS 7 software.

Why Should These Issues Be Considered Important?
Using these vulnerabilities remote attackers could cause denial of service issues to the above mentioned Siemens devices and/or obtaining the permissions of legitimate users of the SIMATIC WinCC and SIMATIC PCS 7 software used to monitor and control these devices. With the large industrial systems these devices control/operate these flaws can have serious physical consequences (see the notable example mentioned below).

How Can I Protect Myself From These Issues?
Please follow the instructions within this ICS CERT security advisory (specifically the Mitigation section) to update any affected industrial Siemens products that you may be using.

One interesting aspect about these flaws is that the above mentioned Siemens HMI devices are in use by the well-known Large Hadron Collider located underground near Geneva, Switzerland and operated by the European Organization for Nuclear Research (CERN). This underlines the important functions that these devices control whether it be the Hadron Collider or your nearest power station.

Thank you.