Get best of the week

We continue to analyze vulnerabilities of industrial switches: we execute arbitrary code without a password



In Positive Research 2019, we reviewed the Moxa Industrial Switch Management Protocol. This time, we will continue this topic and analyze in detail the vulnerability CVE-2018-10731 in the Phoenix Contact switches of the FL SWITCH 3xxx, FL SWITCH 4xxx, and FL SWITCH 48xx line models identified by our experts. This vulnerability, detected in the device’s web interface, allows arbitrary code to be executed without knowing the device’s credentials and is rated at 9 out of 10 on the CVSS version 3 scale.

First look


The devices mentioned above are running Linux, and you can use the web interface to configure them. As with many other IoT devices, domestic and industrial, the web interface consists of many CGI applications that process user HTTP requests. In our case, CGI applications actively use the cgic library, which facilitates working with HTTP requests, and the functions of this library are built into the shared library libipinfusionweb.solocated in the device’s file system.

When processing an HTTP request, the web server passes the user request data to the CGI application as a set of environment variables. Their initial processing is performed by the mainlibrary function libipinfusionweb. Next, the function maincalls the function of the cgiMainCGI application, in which the further processing of the request takes place.



Figure 1. Processing an HTTP request

In the course of its work, the main function of the library libipinfusionwebcalls a function get_login_userthat determines whether the user has passed authentication on the system using the passed Cookie values.



Figure 2. Pseudo-code fragment of the main

function The function get_login_userreceives the value of the Cookie parameter c_sessionusing the function cookies_get_valueand stores it in a variable local_e0. The variable itself local_e0is an array of single-byte characters with a length of 0x80 and is located at a distance of 0xE0 from the beginning of the stack.



Figure 3. Fragment of the pseudo-code of the get_login_user function

However, in the function code cookies_get_valueit can be seen that the cgiCookieStringvalue of the Cookie parameter received by the function has a maximum length of 0x400 bytes.



Figure 4. A fragment of the pseudo-code of the cookie_get_value function

Thus, when passing a Cookie parameter longer than 0xE0 (224) characters, the function will get_login_usersave the value of this parameter to its stack, as a result of which all information on the stack that is behind the variable local_e0will be overwritten, including the address return function.

Note: When one function calls another, the return address is stored on the stack. Control is transferred to this address when the called function finishes its work. Accordingly, if you rewrite this address, you can gain control over the program execution process. For example, an attacker can replace this address with the address of a malicious shellcode located in the address space of the program.

Note that the rewrite of the return address occurs before authentication is verified, which makes it possible to exploit this vulnerability to an attacker who does not know the credentials of the device.

Exploitation


We examined several options for demonstrating the possibility of exploiting this vulnerability. The simplest thing is to write the payload code onto the stack (0x400 - 0xE0 = 800 bytes remains for it, it’s enough for the code) and rewrite the return address with the code address. Theoretically, this option was possible, since the processor of the vulnerable switch does not support the NX-bit function (that is, it allows the execution of code located anywhere, including on the stack), but in practice it had serious limitations.

The vulnerable switch processor has an MIPS architecture; many of the processor instructions in this architecture are encoded in byte sequences containing zero bytes. The buffer contents are written down to the first zero byte (due to the use of the functionstrcpy), therefore, it is only necessary to use operands that do not contain a null byte, which is impossible, since any payload would use at least several of these bytes.

When constructing the ROP chain, again, we would have to face the restrictions of the null byte: the address of the ROP gadgets should not contain zeros, which greatly complicates their search. By and large, we could only use one zero, copied by the strcpy function. This imposes a limitation on the creation of a full-fledged ROP chain, and in addition to this, the gadgets we needed were extremely few. However, during searches in the libipinfusionweb library, the following code fragment was found:



Figure 5. A fragment of the libipinfusionweb library's executable code

Provided that the contents of the register $ s0 are controlled, this code fragment allows you to execute an OS command using a function mysystem(initially this function did not have a name, but we renamed it, since it is very similar to the Linux system function).

Since we are rewriting the return address from the get_login_user function, this function will be executed to the end. In the epilogue of the get_login_user function, you can see that the value of the register $ s0 is restored from the previously saved value on the stack (at offset 0xD8 from the top of the stack). However, at this point, this area of ​​the stack is already under our control, that is, in fact, we can achieve control over the contents of the register $ s0 and thus execute arbitrary OS commands using the function mysystem.



Figure 6. A snippet of the get_login_user function executable code

Thus, in order to successfully demonstrate the exploitation of this vulnerability, we need to send as a parameter a Cookie c_sessionlong line containing:

  • OS string command, which will be subsequently passed to the mysystem function;
  • the address of this command on the stack;
  • new return address (address of the code fragment shown in Fig. 5).

The final payload should look like this:



Figure 7. Payload

At this point, we already had a shell on the device obtained using a vulnerability that needed administrator rights to operate. Therefore, we were able to obtain additional information that helped us to operate:

  • ASLR on the device under study was disabled - therefore, the addresses of the gadget used and the OS commands will always be the same.



Figure 8. ASLR status on the device under investigation

  • The range of memory addresses in which the stack could lie. To calculate the exact address, we went over all the addresses in this range.

As a payload, we implemented the download of a web shell, a CGI application with the following contents:

#!/bin/sh
eval $HTTP_CMD 2>&1

Since, according to the CGI protocol, the contents of the HTTP headers are transmitted to the CGI application in the form of environment variables with the names HTTP_ <Header Name>, this shell evalwill use the command to execute the contents of the CMD HTTP header. The figure below shows the result of the successful operation and execution of the ls command using the loaded shell.



Figure 9. The result of the successful operation and execution of the ls command

Conclusion


We have demonstrated the ability to exploit this vulnerability. As we already mentioned, its operation does not require knowledge of the password, and therefore can be performed even by an unauthenticated attacker.

Hacking an industrial network switch can compromise the entire production. Violation of network interaction can adversely affect the process until it stops completely.

Information about the vulnerability and PoC were transmitted to the vendor, who released the updated firmware version 1.34, and the identifier CVE-2018-10731 was assigned to the vulnerability itself.

Looking for a person


If you have a desire to do such things, we are just looking for a specialist in our team. We are engaged in security analysis of process control systems (large industrial / energy / transport facilities, etc.). On each project, we look for ways to stop or disrupt the operation of these objects. Each time we find many ways to influence the manufacturing process, exploring industrial hardware and software, analyzing proprietary network protocols. We find and report a lot of zirodey, write reports (not according to GOST) and do much more. When there is time, we speak at IB and not only conferences. Link to the vacancy: hh.ru/vacancy/36371389

Posted by Vyacheslav Moskvin, Positive Technologies

More articles:


All Articles