*The relevant loopholes involved in this article have been reported to the manufacturer and repaired. This article is only for technical research and discussion. It is strictly prohibited to use them for illegal purposes, otherwise all consequences will be borne by yourself
I. overview
Advantech web access is a set of HMI / SCADA software based on browser architecture of Advantech company. The software supports dynamic graphic display and real-time data control, and provides the function of remote control and management automation equipment, which is widely used in the industrial field.
Advantech web access software has always been the favorite of vulnerability exploiters. A report of zdi pointed out that it had received 100 reports of Advantech web access software vulnerabilities in one day, and ics-cert also had a large number of related vulnerabilities. Recently, we have paid attention to cve-2017-16720 / cnvd-2018-00670 vulnerability of the software. Some places describe the vulnerability as path traversal vulnerability, some describe it as rce vulnerability, and give different scores. So what are the loopholes? It can be known by in-depth analysis.
2、 Preliminary analysis
It is obvious that zdi has made a more detailed mistake about this vulnerability. At a glance, 0x2711ioctl? IOCTL is a function of the device driver to manage the I / O channel of the device. Is the vulnerability related to the driver? After a large number of data review, we finally found the relevant explanation:
It turns out that the function call form of this service in Advantech web access software is very similar to the IO control function call of windows device, so this call method is used. From this explanation, it can also be found that the service runs on tcp4592 port by default, and remote access control can be performed based on RPC Protocol. What? With RPC? What kind of hole is it? Run POC in the environment first.
3、 Vulnerability debugging analysis
Download Advantech web access v.8.0 (the vulnerability exists in < = 8.3.2) and install it in win7x64 virtual machine. The corresponding port opening is shown in the following figure:
Since the vulnerability is related to RPC Protocol, use rpcview to view the process:
By selecting the process of webvrpcs.exe, the RPC service port (tcp592), UUID and version information of the interface can be easily obtained.
Obtain POC code at https://www.exploit-db.com/exploits/44278 and execute it. Calc.exe in the target machine runs successfully, and RPC Protocol interaction data can be found:
Reverse view the IDA of the target file (webvrpcs. Exe). Because the service (webvrpcs. Exe) uses the RPC Protocol, enable the IDA plug-in mdida to extract the RPC interface in the code and rebuild the related IDL (interface definition language) file. The following results are obtained in IDA:
The first step of POC code reading is to establish a connection. In the third RPC call, the second returned context handle is needed for the third time. As a parameter of the third call, RPC Protocol uses this mode to establish a stable connection between server and client
As you can see, the first call doesn't seem to be very useful (it can be verified finally). Because the vulnerability function points to 0 × 2711 IOCTL, and the opcode used in the call process is 1, in the output of midia, first select opcode 0 × 01, right-click decision, and get the function prototype as follows:
It can be seen that the function has five parameters, corresponding to the stubdata finally passed into call: four numeric parameters and one string parameter.
Open the IDA debugger, start with sub_andstep-by-step debugging. It is found that from the beginning to the final execution of calc.exe, the sequence of function calls in the whole process is as follows:
1、webvrpcs.exe:sub_401260
2、webvrpcs.exe:sub_402c60
3、webvrpcs.exe:sub_4046D0
4、drawsrv.dll:DsDaqWebService
5、drawsrv.dll:sub_100017B0
For the fourth function, dsdaqwebservice needs to check drawsrv.dll. It can be seen that the value of IOCTL is saved in EDX, and the code is reduced in IDA. It can be found that there are many branches / jumps, and the value of eax ultimately determines which branch the function will jump to next:
Take a few steps to jump to the problem function. Check the pseudo code as follows:
The function sub_100017B0 has a new process, and has a parameter lpCommandLine. In the function, Windows API CreateProcessA is called, and the parameter lpCommandLine is directly imported. Windows API is used for the detailed usage of function CreateProcessA. At the same time, in conjunction with Windows's rule of searching files in the system, the parameter can be used in the form similar to that in PoC.
command ="..\\..\\windows\\system32\\calc.exe"
It can also be used directly:
command = "calc.exe"
Verify the above idea: first, log off the first RPC call, and then change the command in the payload to the one shown above. If the command is executed again, the calculator will pop up successfully.
Four, summary
From the analysis of the whole vulnerability and POC analysis, the vulnerability should be characterized as Remote Code Execution Vulnerability rather than path traversal vulnerability, and the vulnerability has a great harm. Previously, Advantech claimed that the vulnerability has been fixed in v8.3, v8.3.1 and other versions, but the actual vulnerability exists, and the vulnerability in the latest version of v8.4.0 has been fixed. In addition, from IDA analysis, it can be found that there are a lot of jumps near the problem function, which means that there may be multiple ways to trigger the vulnerability (that is, multiple different CVEs). From the previously disclosed vulnerability, there are a lot of vulnerabilities similar to cve-2017-16720 analyzed in this paper. Guys, roll up your sleeves and dry up. A lot of CVEs are waiting for harvesting.
*Author of this article: ww5466064, this article is an original reward plan of freebuf, which is prohibited to reprint without permission.