This post was updated on August 5, 2021.
Nozomi Networks Labs has discovered five vulnerabilities affecting Mitsubishi safety PLCs that relate to the authentication implementation of the MELSOFT communication protocol.
A first set of vulnerabilities was disclosed to the vendor through ICS-CERT in January 2021. A second set was disclosed more recently through the same process. Currently, patches for these vulnerabilities are not available. The vendor has provided a series of mitigations which are described in the corresponding advisories.1 Considering the potential impact of these vulnerabilities we suggest you carefully assess your security posture and consider applying the proposed mitigations.
Thus, at this time we are not revealing the technical details of the vulnerabilities, or providing the PoCs (Proof of Concept) we developed to demonstrate potential malicious exploits. We are instead revealing general details out of concern that technical details could be disclosed in some form. This would leave asset owners without enough information to assess their security posture and take timely action before a potential attack occurs.
For Nozomi Networks customers, know that our Threat Intelligence service includes detection logic for these vulnerabilities and will alert you if an attack is taking place. For other asset owners, and members of the security community, this blog post informs you of the situation and provides general mitigations for protecting your operational environments.
Discovering and Disclosing the MELSOFT Authentication Vulnerabilities
At the end of 2020, Nozomi Networks Labs began a research project on MELSOFT, the communication protocol used by Mitsubishi safety PLCs and GX Works3, the corresponding engineering workstation software. We focused our analysis specifically on the authentication implementation, as we noticed that similar OT products from other vendors contain vulnerabilities in this attack surface.
In addition to disclosing the vulnerabilities to the vendor, we also proactively shared the PoCs we developed and all the technical details of our research with them. Mitsubishi analyzed our findings, and after acknowledging the vulnerabilities, devised a strategy to patch the issues.
As you may already be aware, software updates for products like safety PLCs or medical devices take longer to deploy than other software products, like the web browser you’re using to read this blog. This is because in addition to developing and testing the patch, vendors are required to comply with specific certification processes. Depending on the type of device and regulatory framework, the certification procedure could be required for each individual software update.
Why We’re Revealing the Vulnerabilities Now
While waiting for the patch development and deployment process to be completed, we deployed detection logic for customers of our Threat Intelligence service. At the same time, we started researching more general detection strategies to share with asset owners and the ICS security community at large.
It’s likely that the types of issues we uncovered affect the authentication of OT protocols from more than a single vendor, and we want to help protect as many systems as possible. Our general concern is that asset owners might be overly reliant on the security of the authentication schemes bolted onto OT protocols, without knowing the technical details and the failure models of these implementations.
For the same reason, what follows is a general description of the issues found in Mitsubishi safety PLCs and GX Works3. At this stage we won’t focus on all of the technicalities of MELSOFT authentication, nor describe the PoCs we’ve developed. Instead we provide what should be enough for security teams to assess the risks to their own environments.
Description of Mitsubishi MELSOFT Authentication Vulnerabilities
Threat Models
We considered two threat models in this research. In the first, the attacker is limited and can only exchange packets with the target PLC. In the second, in addition to exchanging packets, the attacker is also capable of sniffing the network traffic between the engineering workstation (EWS) and the target PLC.
MELSOFT Authentication Overview
In our research we analyzed MELSOFT over TCP port 5007. Authentication is implemented with a username/password pair. In this scheme the EWS first sends a packet containing the username in cleartext and receives a reply from the PLC. The reply contains a field that communicates to the EWS whether the username is valid for the PLC. If the username is valid, the EWS will send a second packet containing a hash generated from a set of elements. One of these elements is the cleartext password.
Following is a high-level description of the vulnerabilities we discovered.
Username Brute-force
To the best of our knowledge, the exposure of the username in cleartext over the wire has been addressed with a series of mitigations.2 We instead tried to understand whether the list of valid usernames could be revealed through brute-force techniques. To verify our hypothesis, we implemented a PoC, and the result is that usernames are effectively brute-forceable. The limiting factor for an attacker is the maximum length for a username, which is 20 characters.
Anti-password Brute-force Functionality Leads to Overly Restrictive Account Lockout Mechanism
Once we implemented the MELSOFT primitives to perform a successful authentication, we extended our initial PoC with a password brute-forcer that, given a valid user, would try a combination of passwords repeatedly until the correct one is found. Fortunately, in this case there’s an anti-brute-force mechanism in place that effectively blocks an attacker. However, the implementation of the mechanism is overly restrictive. It doesn’t just block a potential attacker using a single IP, it blocks any user from any IP from logging in for a certain timeframe.
The consequence of this design is that if an attacker sends a limited number of passwords to the PLC, enough to trigger the anti-brute-force protection, all users with legitimate credentials are effectively blocked from authenticating with the device. If an attack of this type is taking place, the asset owner has two options:
- Blocking the password brute-force packets from reaching the PLC and then waiting for the time window to expire before authenticating
- Physically rebooting the device and then authenticating immediately after the reboot process has completed
Leaks of Password Equivalent Secrets
We found two instances in which a secret derived from the cleartext password is leaked in a packet. An attacker that can read such a packet will be able to take this secret and use it to successfully become authenticated with the PLC. Due to the way the authentication is implemented, this secret is functionally equivalent to the cleartext password. We implemented a PoC that performs a successful authentication with this secret, rather than using the password in cleartext.
A further vulnerability concerning how sessions are managed is currently under discussion. We advise asset owners to follow the mitigations in this blog as well as those proposed by the vendor for the previously described vulnerabilities.
Devising an Attack Scenario by Chaining Together Multiple Vulnerabilities
If we chain together some of the identified vulnerabilities, several attack scenarios emerge. It’s important to understand this approach as real world attacks are often executed by exploiting several vulnerabilities to achieve the final goal.
In this case, an attacker can start its activity by analyzing an active session between the engineering workstation and the safety PLC. From this analysis they can understand how to reproduce a privileged command and then choose the right moment to continue with malicious activity, when they think there is the least chance of being noticed. The attacker will then ask the PLC for the list of the registered users. The reply will also contain the password equivalent secret for each registered user.
The next phase can then take place whenever is best to achieve the maximum impact. The attacker can now login with real credentials and change the safety PLC logic. They can then start a password brute-force attack to lock everybody out of the PLC. When engineers try to regain access to the PLC through the engineering workstation, they won’t be able to do so unless they first stop the password brute-force packets from reaching the PLC.
Finally, if the attacker goes the extra mile and changes the passwords of registered users, there is then no other choice but to physically shutdown the PLC to prevent potential harm.
Mitigations to Consider Right Now
We suggest asset owners consider the following general mitigations:
- Protect the link between the engineering workstation and the PLC, such that an attacker cannot access the MELSOFT authentication or authenticated packets in cleartext.
- Protect access to the PLC, such that an attacker cannot actively exchange authentication packets with the PLC.
The “static information” that is potentially leaked, and thus worth considering for update is:
- PLC usernames
- PLC passwords
In the future, once patches for the vulnerabilities described here are available, we’ll publish the technical details of our research and PoCs.
References:
- https://www.mitsubishielectric.com/en/psirt/vulnerability/index.html
- https://us-cert.cisa.gov/ics/advisories/icsa-20-175-01
