The Dark Side of Mobility

Sure, the idea of “iPhone as HMI” is convenient, but it opens a whole new range of cyber vulnerabilities. Is the functionality worth the risk? Many users are already deploying the technology without sufficient safeguards.

By Matthew E. Luallen July 6, 2012

Search, select, purchase, and install. It’s that easy. Now you can join the ranks of the elite that can remotely manage their control systems from a smartphone, but should you take this step?

In November, the Curren Water District outside of Springfield, Ill., hit the news when it looked like a hacker located in Russia had not only compromised the utility’s network but also disabled a water pump. Further investigation showed the situation was not as it first appeared. Later reports indicated that the Internet activity from Russia was by an approved contractor while on vacation. The contractor apparently used a VPN to manage the control system using his smartphone while travelling in England, Germany, and Russia. This story illustrates some of the peculiarities connected to growing deployments of wireless, remote access, and portable user-following devices such as smartphones and tablets used with industrial networks.

We all understand and enjoy the productivity gains we have witnessed with the industrial technology revolution. The productivity of industrial facilities has grown exponentially while becoming vastly more efficient with reduced workforces. The trend has recently continued with adoption of cheaper and more resilient wireless capabilities and portable devices to sense, administer, and control our facilities. HMIs, maintenance interfaces, and remote administration functions that were once proprietary can now be installed and programmed in Apple’s iOS and Google’s Android operating systems. Human beings are excellent at making work simpler; however, how does one address the additional cyber risk that our traditional five senses do not manage? Many simply decide to ignore the problem and tell themselves that they will never be a target. They ask, “Why would someone come after my facility or supply chain?” The reality is that someone may not be targeting you specifically, but you may be a victim of a generic attack that exploits a vulnerability of your system that you don’t even know is there.

Stuxnet was a highly targeted attack, but cyber security researchers and most likely criminals who studied its lessons realized that creating a nontargeted attack was a much simpler process. The concern is that a sophisticated generic attack can impact industrial technology much more broadly and, even worse, not leave behind a sufficient trail to trace its source. Device portability, remote access, and wireless communication serve as excellent gateways into the control system infrastructure. That’s why they work so well in this context. Every asset owner that uses these gateways to the control system must protect them. The problem is that many don’t, as I am about to illustrate.

The Cybati IEEE 802.11 wireless node study

Google Android and Apple iOS devices serve the purposes of all three of the control system vulnerability gateways: They are wireless, support remote access, and are portable user-following devices. Over the past year, Android and iOS control system applications have become available for purchase or even free download. There are dozens of applications from both control system hardware suppliers and third-party software companies. One recent announcement is typical: “[The application] can be used to reset counters, change setpoints, or review production data. It is available now for free download to iPhone or iPad.” In most cases the vendors caution users that such applications should be protected; however, any application using these devices requires IEEE 802.11 wireless access to be existent or added to the control system environment. Why? Most Apple iOS and Google Android devices simply do not have the option to use physical network cabling. This fact led to the Cybati IEEE 802.11 wireless node study. 

The underlying assumption is that since so many applications have been added to the Apple iOS and Android store during the past year, the number of control systems with IEEE 802.11 access must have increased to support this and other types of wireless communication on industrial networks. The questions are: How was the IEEE 802.11 wireless configured? Do users connect directly to the control system environment or do they route it through a well-managed and adequately protected gateway? After reviewing some PLC user forums, it was apparent that our assumption of the worst was probably correct, but we still wanted to prove it with technical data.

Our search suggests the former is far more common than we would like to see. During February through April 2012, Cybati personnel covered nearly 4,000 miles of roads hunting for IEEE 802.11 a/b/g/n wireless transmissions. The specific target was the organizational unique identifiers (OUIs) of the popular control system hardware providers. OUIs are applied for by the network device provider and in this case the vendor(s) of the control system hardware. OUIs and even the full device MAC address are left unprotected in even the most secure security settings (WPA-2), commonly used IEEE 802.11 networks. We built our own “wardriving” kit using off-the-shelf components:

• iM2500 Pelican case modified with vent holes
• Dual USB-fans to circulate air
• Hyperjuice 150 Watt-hour battery
• Macbook Laptop with VMWare Fusion and Backtrack 5
• Insomnia Sleep Management Application (to disable MAC lid-closing sleep settings)
• Alfa AWUS036H external wireless card
   (AWUS036NH depending on ability to add drivers to Backtrack 5)
• External GlobalSat BU-353 USB GPS receiver (we purposely did not collect this data)
• External, outdoor-rated 2.4-2.5Ghz 8dbi gain omni-directional antenna (OA-2450-08-01), and
• Kismet and GISKismet Backtrack 5 applications.

Once we collected all of our data, we used structured SQL commands within the MySQL database created with GISKismet. These commands looked for the OUIs of vendors categorized within our control system hardware database (e.g., “select mac from clients where mac like ‘00:e0:62%’” for the Koyo Ethernet communications module or “select mac from clients where mac like ‘00:a0:3d%’” for the Opto-22 SNAP-PAC integrated 802.11 wireless). Note that this effort did not involve parking in industrial areas. Easily 95% of our travels did not stray from interstate highways; we drove at normal speeds and purposely bypassed large metropolitan areas wherever possible. Even with this limitation, we had no trouble finding a few control system components on protected wireless networks and on unprotected ones as well. After collecting data pertaining to over 27,000 wireless clients (including office, commercial, industrial, and even home wireless networks), nine of them were control system components. Not a large number, but even a small number means trouble as more environments investigate adopting iPad control applications. Some of our more targeted, urbanized area assessments have turned up many more devices; however, we will leave this to each of you to perform your own control system wardriving.

What could someone with malicious intent do with this data? Well, it depends. If the data associates control system mac addresses on an unprotected or poorly protected (WEP or weak passphrases) wireless network, an attacker can do whatever he wants since control system communication protocols such as Modbus, EtherNet/IP, PCCC, DNP3, ICCP, and others are natively unauthenticated. If the data is found to be associated with a RuggedCom device, the attacker now has the password for the default “factory” account and may attempt to gain access via dial-up modems or through the Internet using the results from a shodanhq query. Ultimately this type of recognizance is one of the first stages of entry in to a protected area, leading to a series of next steps that may take minutes, hours, or months to continue the exploitation process.

Defense-in-depth controls defeated

A commonly deployed mechanism to protect critical assets is to construct layers of defenses to allow sufficient time to deter, detect, and defend against intruders before they reach a critical asset. The defense-in-depth strategy controls include operational, cyber, and physical elements that span from the control room to remote field sites and even to third-party contractors’ home offices. However, what if several of the controls fail simultaneously due to failures of external trusts? External trusts are those that exist due to a business relationship. In the cyber world they normally include the hardware supply chain, operating system, application programmers, and system integrators. You trust that the defensive measures you have installed really work because your trust the source.

Stuxnet was successful because it caused all of those trusts to collapse simultaneously. Maybe you take comfort in the thought that the resources needed to create Stuxnet are not arrayed against you, but the barriers you have between your critical assets and bad guys already have holes in them. An invader may only need to punch through one more to have a clear path in.

Perhaps you tell yourself it can’t be that bad, but it is more likely worse than you realize. The past two years have seen certificate authorities compromised, including Verisign, Comodo, DigiCert, DigiNotar, and Gemnet. Even the recent investigations into the Flame exploit code reveal that it targeted certificates—in this case the victim was Microsoft and Windows updates. RSA Security’s key fob password algorithm was breached. Microsoft remote desktop software has shown recent vulnerabilities. Many PLCs, including Schneider Electric’s Modicon Quantum, Siemens, and others are fitted with hardcoded username and passwords. RuggedCOM’s entire product line has hardcoded usernames and passwords. ZTE Android operating system phones use software encoded usernames and passwords. The DuQu worm directly exposed a vulnerability in ClearType/TrueType fonts impacting Microsoft Windows, which later was understood to also impact Apple Macs, iPhones, iPads, and other operating systems. How many more examples do you need? The US-CERT maintains an alphabetical list for industrial systems. The list is huge and includes many companies that you will certainly recognize. Ultimately the risk is that each deployed system has an unknown back door to bypass your defense-in-depth controls. We cannot trust our own equipment—it has supply chain challenges. Add to your control system portable, wireless, user-following devices with remote access capabilities, and now the risks are compounded. Ideas to address this challenge will come later in this article.

How can you protect yourself?

Ultimately security is about constantly assuring organizational trust. Does trust change as new assets are procured, new people hired, assets decommissioned, and access granted and revoked? Absolutely! In the case of mobile devices and their applications, you are still performing the same operational tasks; however, now you are using a device that may not have sufficient local security controls, communicates wirelessly beyond your property lines, and may even follow the user throughout his or her lifestyle.

So, what should you do to protect your critical control system assets while enhancing productivity? First and foremost, you must investigate the true productivity gains and reduced costs of using mobile applications that have unfettered access to your control system. Local control of the environment is also at risk. The very concept of mobile applications implies that either access is granted through the Internet or wirelessly using an IEEE 802.11 protocol, or both. Most mobile applications operate on devices that do not have a hardwired option to connect to a network. Therefore, the recommendation at this time is that control system remote or local access should not be allowed from traditional consumer smartphones or tablets.

Portable electronic devices must not be categorized as tools like a hammer or wrench. These devices retain information about the control system environment and can cause additional harm if placed in untrustworthy hands. Whether the device is a traditional laptop, iPhone, iPad, or HART communicator, the tool may contain communication points, tags, configuration settings, logic, diagrams, blueprints, and specifics about the environment that a skilled attacker can leverage. Additionally, the portable device may serve as the entry point to the protected control infrastructure using cached remote access credentials and applications stored on iPhones, iPads, Androids, or other portable devices. Wireless devices may also be configured to multihome between IEEE 802.11 wireless networks and cellular networks creating an unwanted Internet gateway.

Ask yourself

Here are some questions you should ask yourself and the business before allowing remote access, wireless, and user-controlled portable devices on the control network.

• Operations: Who will use it? Where will it be used? When will it be used? How will it increase productivity?
• Personnel: How should current safety and security operations be altered to accommodate this mobile application?
• Security: Recognizing that security is a state of mind, what additional controls will be put in place now that a highly portable device can gain access to the control network using a local wireless network and/or an international telecommunication provider?

Ultimately you have to ask yourself whether the new mobile application is still valuable after considering these points. (If you aren’t fully convinced of the accuracy of the answers and the willingness of your people to practice safety protocols, don’t use the application.) This is your risk assessment and one that we cannot answer for your specific situation. However, never forget that adding this type of remote monitoring capability invariability increases your organization’s attack surface. Is it worth it?

Simple and quick recommendations

1. Do not allow portable devices within control system environments. A drastic suggestion, but it works.
2. If you must allow portable devices, choose ones that are intelligent enough to be protected with additional security controls such as hard-drive encryption, application white-listing, physical security tethers, and technician-controlled access such as restricted user account access with password complexity rules. The technicians using the systems should also be educated as to the need for the protective controls.
3. Do not allow commonly accessible wireless protocols. Use only wireless protocols with restricted access to hardware, software, and communication protocols.
4. Do not trust any portable and/or wireless device after it has been out in the field unless its use has been restricted. If you don’t know where it has been or who may have used it, quarantine it.

Consider these possibilities

Here are some additional questions and scenarios you may want to think about before you commit yourself:

• What happens if a consultant is remotely administering a system and his or her connection drops in the middle of an important update due to a telecommunication outage?
• What happens if an employee is administering the local system wirelessly and is disrupted due to wireless interference?
• How will you respond if you discover that your new mobile application operating system has a high-risk security flaw?
• Do the contractors working on your site have sufficient security to ensure that no one could break into their area and clone a strategic portable device without their knowledge?

If you’re already convinced that you have to have some hot new wireless remote app, you will be tempted to dismiss these suggestions as paranoid or at least overblown. The longer you go without a cyber incident, the more you will tend to believe that.

Risk in this context is difficult to characterize. You could operate for years with an utterly unprotected system and never be violated. Does that mean there is no risk? Of course not—you were just lucky, and that luck could run out at any moment. Conversely, a highly determined hacker may systematically probe and test a well-thought-out defensive system until he finds that one chink in the armor that can be pried open.

If you have a realistic and healthy fear of the cyber risks that exist, you should think long and hard before doing anything that increases your attack surface as much as adding mobile applications can. The risk may well prove to be greater than the actual productivity gained.

Matthew E. Luallen is chief security officer for Cybati and a regular contributor to Control Engineering.

More reading from Matt Luallen:

Cyber security vulnerability assessment

Security at the device level