2011 August

August 2011

‘Morto’ worm tries weak passwords and default account names to spread using Remote Desktop Protcol

Most of our SCADA and Process Control clients have either already segmented their network architecture, or are in the process of segmenting their networks. Having defined networks for each functional area of the system is a great first step.

However, if you are using RDP (Remote Desktop Protocol) to jump or hop across network segments, make sure that you have changed the default account names and passwords associated with the RDP logon process because a new worm attack is live right now attempting to crawl through networks around the world, and it is taking a gamble that some have left default accounts and weak passwords in place.

Researchers working on the Morto worm say that it infects Windows workstations and Windows servers, and spreads by uploading a Windows DLL file to a targeted machine. The worm looks for weak administrator passwords in Remote Desktop on an organization’s network, attempting everything from “12345” to “admin” and “password.”

Like most C&C malware, once Morto compromises one system, it connects to a command and control server to download information and to update its payload. It also terminates processes for locally running security applications in order to ensure its activity continues uninterrupted. Even if it can not load onto the local machine or pull down its C&C malware, Morto still tries to connect to targeted host systems. It tries common default account names like “admin” and “guest.” Morto is also known as Trojan horse Generic24.OJQ (AVG); Trojan.DownLoader4.48720 (Dr.Web) ; Win-Trojan/Helpagent.7184 (AhnLab); Troj/Agent-TEE (Sophos); and Backdoor:Win32/Morto.A.

During our assessment process, we always find plant control systems that are still using default Windows accounts, so I can bet that there will be control systems impacted by this worm. We always recommend changing the default account names, and modifying the key service account passwords on a routine basis, but this is not always feasible in operational systems.

The best recommendation is to integrate 2-factor authentication into management and administrative services like RDP. Instead of only needing the username and password to log into remote hosts, the administrator would need a key fob with a OTP (One Time Password) AND the correct username and password to log into the remote host. This extra step for authentication not only prevents automated attacks from leveraging harvested passwords or bruteforce attempts, but also helps prevent the insider threat, since the logon process requires something you know PLUS something that you have in your possession.  Implementing 2-factor authentication is the best practice for authentication to SCADA and Control System resources from the Corporate IT and other external networks.

We hope this advice is helpful for our industrial control systems clients, and please pass this link and message onto others in your workplace and at home.

Cheers,
Jonathan

Beware of Using Public Cellular Carriers for Last Mile SCADA Communications

You may have seen the recent alert from NERC entitled  “Telephony-enabled Weakness.”  It describes how an attacker could utilize a clear text GSM (Global System for Mobile Communications), CDMA (Code-Division Multiple Access), and other cellular phone network devices or SIM (Subscriber Identity Module) card to manipulate a control system microprocessor which can receive signals, but is not capable of secure reception.

We were aware of the potential security vulnerabilities of using a public cellular infrastructures several years ago when several of our clients asked us about a class of PLC and RTU COMM cards that plugged directly into the controller backplane or snap into the controller. These communications cards allow the PLC to utilize cellular networks as either their primary or secondary communications channel.  We raised this security concern with AT&T because they assign sudo public IP addresses to these communication modules. The reason I say sudo is that AT&T claims that the IP addresses they assign to the modules are “private” and in a block of IPs assigned to the client. They also claim that their MPLS network has various security features that prevents one client on their cellular network from accessing another client’s cellular-connected devices.

When NERC approached us early about this vulnerability, we were able to quickly turn around very specific content, language, and Visio graphics to enhance the messaging to the electric sector community. We created the first diagram below that visually shows how an attacker with an entry point into the carrier networks could route cellular commands to the COMM modules directly connected to the PLC or RTU backplane.


The advice that we gave to our clients about a year ago was not to trust the cellular carriers, but treat them like the Internet. Assume that over time, they will become compromised. If they wanted to continue to utilize them as a communications medium, we advised them to not use the cellular communication cards that racked directly into the PLC backplane. That is extremely dangerous because they are placing the core of their PLC or RTU system directly on a foreign network. Instead, we advised them to purchase a separate hardware device that accepts a GSM SIM card. We advised them to place a small firewall between their PLCs and the embedded cellular device, and tunnel over the cellular network as if it was the Internet. We created the next diagram below as a way to visualize using a small inexpensive field firewall to create an encrypted tunnel through the carrier network.


We were glad to be able to contribute to the NERC advisory, and continue to support not only our clients, but the larger SCADA Security community at large. I hope briefings like this one can continue to help shine a light in areas of our infrastrucutre that need additional attention. Our goal is not so much to expose areas of weakness, but to offer clear and precise guidance that can help mitigate these security findings.

More to come on this subject…

Jonathan

PLCs and RTUs Still Lack Security Features

At last week’s BlackHat press conference, we were able to participate in a press event specifically dealing with the number of recent security findings related to SCADA systems and PLCs/RTUs. We continued to send out the message that embedded devices such as PLCs and RTUs simply do not have the level of security commensurate with the level of risk represented by the functions that these devices serve in the SCADA system. Dillon showcased the research work that he did to send replay attacks back to several models of Siemens PLCs. He was able to use Wireshark to capture network traffic containing commands to turn outputs (lights) ON and OFF. He then took the captured packets, extract the protocol commands, then create Metasploit modules to send the exploit to the PLCs. It was an excellent use of replay attacks.

I then made the comment that these replay attack vulnerabilities are not unique to Siemens PLCs. Almost all PLC, RTU, and control system components that utilize routable TCP/IP based protocols are vulnerable to replay attacks. The issue goes much deeper than the fact that these devices do not have any timing capabilities to thwart replay attacks.  Even after we initially discovered this over 8 years ago, these embedded devices continue to lack authentication, encryption, and almost all vendors that we are aware of allow any device on the same subnet to send command and control signals to PLCs that directly impacts real-world IO (inputs and outputs.)

Many of the control system vendors took their RS-232 serial protocols, which did not have authentication requirements built into the specifications, and simply encapsulated their old serial protocols in TCP/IP. In our training class, we break down ModbusTCP, and after you peel off the header information, the same old ModbusRTU structure still exists. PLCs, RTUs, Variable Speed Drives, MCC equipment, “smart” instruments, smart meters, and basically any control device with a routable IP protocol interface can not make a determination between the actual SCADA Master IO Servers that poll them for information or send them commands and another device on the same network. The equipment will accept a command from any IP-enabled device on its same subnet.

This means that either an attacker that has accessed the network remotely, or malware that has made its way into the control system network can also send commands to process and safety controllers and make the physical plant equipment do whatever the attacker or malware wants. It can easily open ALL valves in a plant, turn ON and then OFF all pumps in a plant very quickly, or cause pressure to ramp up to unsafe levels. An attacker or malware that has made it onto the SCADA network can do anything that an operator sitting in front of the HMI can do, including even issuing an ESD (emergency shut down) command.

I hope this message gets out to the industry, and to the control system vendors. We need to start designing and selling control systems that are truely secure out of the box, and also roll out solutions that can secure the exisitng legacy systems out in the field today.

Jonathan

Leave a Reply