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

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