800+ IT
News
als RSS Feed abonnieren📚 Chaining 5 Bugs for Code Execution on the Rockwell FactoryTalk HMI at Pwn2Own Miami
💡 Newskategorie: Hacking
🔗 Quelle: thezdi.com
In January 2020, the inaugural Pwn2Own Miami contest was held at the S4 Conference and targeted Industrial Control System (ICS) products. At the contest, the team of Pedro Ribeiro and Radek Domanski chained together five different vulnerabilities to achieve code execution on the Rockwell FactoryTalk View SE, which earned them $25,000 and 25 points towards Master of Pwn. Now that patches are available from the vendor, they have graciously provided the following write-up, demonstration video, and Metasploit module.
This post describes a chain of vulnerabilities that were found by Pedro Ribeiro (@pedrib1337) and Radek Domanski (@RabbitPro). These bugs were put to use in ZDI's Pwn2Own Miami 2020 competition in January. The vulnerabilities described are present in the Rockwell FactoryTalk View SE Human Machine Interface (HMI), version 11.00.00.230. Older versions are likely exploitable, but this has not been confirmed by Rockwell.
The default configuration is exploitable by an unauthenticated attacker, who can achieve remote code execution as the IIS user on a Windows installation. The attack relies on the chaining of five separate vulnerabilities, which are described below. The first vulnerability is an unauthenticated project copy request, the second is a directory traversal, and the third is a race condition. To achieve full remote code execution on all targets, two information leak vulnerabilities are also abused.
This blog describes the vulnerability details in the order that they were discovered, followed by a list of the exploitation steps necessary to chain them together and achieve unauthenticated remote command execution. Here’s a quick video of these bugs in action:
Vulnerability Details
FactoryTalk SE exposes several REST endpoints on Microsoft IIS that are accessible remotely. One of these endpoints is at /rsviewse/hmi_isapi.dll, which is an ISAPI DLL handler that performs several actions that deal with FactoryTalk project management.
The ISAPI DLL was loaded and briefly analyzed in Ghidra to understand its basic functionality. However, this turned out to be unnecessary, as all the steps described in this advisory were discovered with a pure black-box penetration testing approach.
Vulnerability #1: Unauthenticated Project Copy Request
One of the actions implemented by hmi_isapi.dll is StartRemoteProjectCopy. This can be initiated by issuing an HTTP GET request to:
In the example above:
-- <TARGET> refers to the server running FactoryTalk.
-- <PROJECT_NAME> must be an existing project on the server.
-- <RANDOM_STRING> can be any random string as the name implies,
-- <LHOST> is the IP address of the attacker's host.
After this request is sent, if <PROJECT_NAME> exists on <TARGET>, then <TARGET> will issue an HTTP GET request to <LHOST> as follows:
<RNA_ADDRESS> is an internal address scheme used by FactoryTalk. It does not matter for our exploitation purposes and can be safely ignored.
In fact, the requested content can be completely ignored by <LHOST>, which only has to respond with:
After receiving this response, <TARGET> will send a HTTP GET request to the following URL in <LHOST>:
The <LHOST> should respond with whatever content it wants to be written to <FILENAME> on <TARGET>:
The <TARGET> will then proceed to write <FILE_DATA> to <FACTORYTALK_HOME>\_bak\<FILENAME>, perform some actions on it (these actions were not determined since it did not matter for exploitation purposes), and finally delete <FILENAME>. All of these actions all occur in less than a second.
The default <FACTORYTALK_HOME> for FactoryTalk SE is C:\\Users\\Public\\Documents\\RSView Enterprise.
Vulnerability #2: Directory Traversal
Once the first vulnerability was identified, the next objective was to obtain remote code execution. At this point, the data in the file and the filename were completely controllable, but this did not mean it was possible to execute arbitrary code.
The easiest way to achieve RCE is to write a file with ASP or ASPX code to the IIS directory.
This was easily achieved by abusing a directory traversal vulnerability in the <FILENAME> provided in Snippet 3 (above). If <LHOST> responds as in Snippet 3 with <FILENAME> set to:
The <TARGET> will then write <FILE_DATA> (taken from Snippet 5) to <FACTORYTALK_HOME>\\SE\\HMI Projects\\shell.asp. Since this directory is configured as a virtual directory in IIS, the ASP file will be immediately executed once it is accessed.
Vulnerability 3: Race Condition
As described previously, <FILENAME> is only written and accessed for less than one second, and then immediately deleted. To be able to execute the ASP code, the file will need to be accessed as soon as it is written.
This is a classical race condition vulnerability, and exploitation will be explained in the next section.
Bonus vulnerabilities #4 and #5: Information Leak on GetHMIProjects and GetHMIProjectPaths
To achieve reliable exploitation, it is necessary to know <PROJECT_NAME> and its path on the FactoryTalk server. These steps are not necessary for a demonstration proof of concept, but a real, weaponized exploit would certainly need them. The provided Metasploit module does implement these steps.
An unauthenticated attacker can obtain the list of projects by sending the following HTTP GET request to an affected FactoryTalk server:
FactoryTalk will then respond with:
The project name is visible in the XML, and, after it is extracted, it can then be used in a subsequent request that will show the project's path:
The response will contain the full path of the project:
The returned path can then be used to calculate the correct directory traversal needed to deploy the ASP file that will be used to achieve remote code execution.
Exploitation - Chaining Everything Together
To exploit the three vulnerabilities described above and achieve remote code execution on FactoryTalk, the exploit works in the following in order:
1 - Obtain a list of projects on the server.
2 - Fetch the actual directory of the project to calculate the correct directory traversal path.
3 - Start an HTTP server that is ready to answer the requests from FactoryTalk as explained in the previous section.
4 - Start a thread that continuously tries to access the path where the malicious ASP file will be created.
5 - Issue the requests described in the previous section to initiate the remote project copy.
After the previously described requests are sent, the exploit will respond with the ASP code, which will be fetched by FactoryTalk, written to the location specified, and then immediately accessed by the thread that issues constant requests. This allows the attacker to “win” the race condition and execute the ASP code as the IIS user.
Metasploit Module
We provided a Metasploit Module for those who wish to test their systems to determine exploitability. The Metasploit module provided does exactly all of these steps in order and can be seen in action in the video above. You can access the module here.
Conclusion
We hope you enjoyed this write-up of the multiple bugs we used for this Pwn2Own Miami entry. Rockwell patched these bugs in late June of this year and assigned them CVE-2020-12027, CVE-2020-12028, and CVE-2020-12029. Unfortunately, the public advisory seems to have moved to a location that requires a login to read it. However, if you are a Rockwell customer, we highly recommend contacting your support representative to ensure you have the latest patches for your FactoryTalk deployment.
...