Hard-coded credentials open industrial control systems up to unauthorized access by malicious actors and threaten ICS security. Expert Ernie Hayden explains the threat and what enterprises can do about it.
Today's modern factories use multitudes of control systems to perform processes that ultimately produce manufactured goods and materials. A common device you'll see in various locations throughout a processing system is a programmable logic controller.
According to NIST SP 800-82 Rev. 2, "Guide to Industrial Control Systems (ICS) Security," a programmable logic controller (PLC) is a small industrial computer originally designed to perform the logic functions formerly executed by electrical hardware, such as relays, switches and mechanical timers or counters.
PLCs require computer code to operate and run. Access to PLC computer modules normally requires a username and password.
Recently, researchers discovered a vulnerability in Yokogawa Corp.'s Stardom PLC in which the username and password are hard-coded in the system and can enable attackers to gain unauthorized administrator access to the controller and operating system.
Yokogawa published a customer advisory on May 21, 2018, regarding this ICS security issue with hard-coded credentials. The Industrial Control Systems Computer Emergency Response Team (ICS-CERT), which is part of the U.S. Department of Homeland Security, also posted an advisory in this regard.
When considering industrial control system (ICS) components, as well as IoT devices, the issue of hard-coded credentials comes up frequently.
What is a hard-coded credential?
Hard-coding credentials is the software development practice of embedding authentication data -- user IDs and passwords -- directly into the source code of a program or other executable object. This is as opposed to obtaining the credentials from external sources or generating them at runtime.
The CERN Computer Security Team observed that "hardcoding passwords is a short name for putting non-encrypted (plain text) passwords and other secret data (like private keys etc.) into the source code."
Unfortunately, hard-coding credentials in ICS code and configuration scripts is a common -- if insecure -- coding practice. With this practice, system authentication is not required to read -- and, in some cases, modify -- configuration files, to add/change users, etc. Essentially, using hard-coded passwords tremendously increases the possibility of attackers guessing passwords.
Think of the vulnerability this way: If the hard-coded password is the same for each device or system of a particular brand and a malicious user tries to hack into the device, it is a simple matter of looking up the default password -- in the vendor manual or on specialized lists of passwords on the internet -- and logging in with complete access. With hard-coded credentials, exploit code is not needed to obtain unauthorized access to the vulnerable system.
The hard-coded credentials may also be accessible as Simple Network Management Protocol community names/strings. Again, this is a bad practice and could negatively affect system ICS security.
A hard-coded credential may also be inserted in code by the vendor to provide a backdoor to use for product testing.
How big is the problem for ICS security?
In its report, "Industrial Control Systems Vulnerabilities Statistics," Kaspersky Lab provided a troubling overview of the security challenges of ICS systems and components. In this report, Kaspersky showed that the second highest vulnerability in ICS components is the use of hard-coded credentials.
When the Mirai botnet first emerged in 2016, malware took over online devices such as IP cameras and home routers. It was not a very sophisticated attack in that the attackers took advantage of hard-coded default passwords in IoT devices.
In June 2013, ICS-CERT published an alert -- ICS-ALERT-13-164-01 -- that reported hard-coded password vulnerabilities affected roughly 300 medical devices across approximately 40 vendors. This hard-coded password vulnerability could have been exploited to change critical settings or modify device firmware. The affected devices included surgical and anesthesia devices, ventilators, drug infusion pumps, external defibrillators, and laboratory and analysis equipment, so it could have affected the health and well-being of patients.
Controls for hard-coded credentials
Embedding hard-coded credentials in ICS and IoT device code is not easy to prevent or identify. You can't readily audit the source code because it is not always public.
Chris Weber, co-founder of Casaba Security, noted that passwords in products are easy to find because they ship with the product or are in the owner's manual.
One way to enhance ICS security is to pay attention to alerts and advisories from ICS-CERT and address any new vulnerabilities -- hard-coded certifications or others -- on your systems and components. There were 73 hits on the ICS-CERT site using a simple search of the phrase hard-coded. Obviously, this is not a trivial issue for ICS-CERT.
Using usernames and passwords -- especially where passwords change periodically -- is inconvenient to the user. Therefore, hard-coding credentials will probably continue for many large-scale IoT deployments.
There are several ways for vendors and consumers to deal with this problem. For instance, rather than hard-coding credentials, vendors could use a first login mode that requires the user to enter a strong password when setting up the device.
Another control for ICS developers, integrators and administrators is to securely manage and protect cryptographic keys. The keys should be strong and should not be hard-coded, default, published or discoverable in any other way.
The Common Weakness Enumeration (CWE) database addresses embedded credentials in its definitions "CWE-259: Use of Hard-coded Password" and "CWE-798: Use of Hard-coded Credentials." These CWE definitions offer several potential mitigations for issues with hard-coded passwords/credentials, including:
Store passwords outside of the code in a strongly protected, encrypted configuration file or database protected from all outsiders, including users on the same system.
Use a first login mode requiring the user to enter a unique, strong password during configuration.
Apply strong, one-way hashes in a configuration database or file. This way, theft of the file/database still requires the attacker to try to crack the password.
Use generated passwords that are changed automatically and must be entered at time intervals set by a system administrator. These passwords will be held in memory and will only be valid for the chosen time interval.
The CERN Computer Security Team recommends the following best practices:
Finally, minimize network exposure for all of your control systems and devices and ensure they are not accessible from the internet. Consider monitoring using Shodan.
When procuring ICS systems and components, companies should ask ICS vendors to identify and replace all uses of hard-coded passwords prior to delivery.
For instance, in the report "Department of Homeland Security: Cyber Security Procurement Language for Control Systems," the procurement recommendations for ICS systems include the following:
"The Vendor shall provide a configurable account password management system that allows for selection of password length, frequency of change, setting of required password complexity, number of login attempts, inactive session logout, screen lock by application, and denial of repeated or recycled use of the same password.
"The Vendor shall not store passwords electronically or in Vendor-supplied hardcopy documentation in clear text unless the media is physically protected."
It also says that "the Vendor shall not introduce changes to password or authentication policy and management without explicit requirements to do so by the Purchaser or other designated authorized individual."
Other sources referenced in this article:
NIST Community Security Resource Center's "Guide to Industrial Control Systems (ICS) Security"
Unfortunately, this problem will probably be around for a long time. Using usernames and passwords -- especially where passwords change periodically -- is inconvenient to the user. Therefore, hard-coding credentials will probably continue for many large-scale IoT deployments.
However, this problem is being recognized by the U.S. federal government. In 2017, a bipartisan group of U.S. senators introduced a bill intended to ban hard-coded passwords in IoT devices. Bill S. 1691 -- Internet of Things (IoT) Cybersecurity Improvement Act of 2017 would require devices purchased by the U.S. government to meet certain minimum security requirements, ensuring the devices do not include hard-coded passwords.
Don't make it easy for attackers
Even if you are diligent and eliminate hard-coded passwords and credentials, one more vector of attack needs to be addressed.
It is a common issue that usernames/passwords for a human-machine interface, workstation or password-protected device are literally glued to the device, written on a piece of paper or written with an industrial-grade ink pen on the component cabinet. This is not only a bad practice, but it can enable successful external or insider attacks on systems and configuration files.
Always take the time to browse your plant and components, look for usernames and passwords, and scrub the facility of these bad habits while training your staff not to do this.
