Shulou(Shulou.com)05/31 Report--

This article is about how to analyze and use Microsoft vulnerability CVE-2017-11885. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

According to the description of CVE-2017-11885 on Microsoft's official website, the vulnerability can almost kill the full version of Microsoft's operating system. The POC about the vulnerability was disclosed on exploit-db in May 2018, and the POC was only tested against windows server 2003.

Since the cause of the vulnerability is not found in the relevant description, after obtaining the POC, try to reproduce and analyze the vulnerability.

The key code of POC is as follows:

The author has made a more detailed comment on the POC. From the layout and comments of the stub, the stub data in line 41 may be passed into the ecx of CALL off_64389048 [ECX*4]. If the ecx is a controlled value, then you can basically execute arbitrary code directly on the target system. Next, build a windows server2003 system and try to trigger the vulnerability through the POC.

This vulnerability exists only when the RRAS service is enabled by the operating system. In windows server2003, the vulnerability is configured through administrative tools-> routing and remote access. The results are as follows:

After the RRAS service is turned on, execute POC on another host and grab the package. It is found that SMB protocol is used for data transmission. The pcap packet data is shown below:

Open a random packet and find that the data is SMB protocol and sent through port 445. SMB protocol is followed by DCERPC protocol. The explanation of this protocol is as follows:

It is still a relatively old protocol, and the MSRPC protocol in Microsoft's operating system is an implementation of DCERPC, which can be regarded as the first generation of RPC protocol. Here is a brief introduction to the RPC protocol and its key contents.

RPC refers to the process on computer A, which calls the process on another computer B, where the calling process on An is suspended, and the called process on B begins to execute, and when the value is returned to A, the A process continues to execute. The interaction between An and B processes is shown in the following figure:

The development of RPC application is based on Cramp S mode. The contents of developing RPC in windows environment are as follows:

1.IDL file

2.ACF file (optional)

3. Client program

4. Server program

The IDL file is an interface description file. The key information needed to write the file includes the uuid registered by the program, the function call interface and the data structure definition of the parameters. ACF files can be used to create some relatively complex data structures, which are not paid much attention here. Use the MIDL program to compile the IDL file to generate the corresponding header files needed by the client and the server. Client programs and server programs contain the main programs that call key functions. The whole pattern is similar to our usual WINAPI call, for example, when we call the ReadFile function, we usually need to pass part of the parameters and get a return value. In RPC programming, the client program is responsible for passing the parameters, and the server program is responsible for receiving the parameters and performing the corresponding functions, and then returning the data. The whole process is transparent to the developer, but a call across computers. For details of RPC development, please refer to Microsoft's official documentation.

Links are as follows: https://docs.microsoft.com/en-us/windows/desktop/rpc/rpc-start-page

Here we mainly focus on the protocol transmission mode of RPC, the name of the endpoint, and the specific program interface calls. The POC uses impacket as a library to transmit SMB and rce protocols. In POC, remote named pipes are linked through transport.DCERPCTransportFactory ('ncacn_np:% s [\\ pipe\\ browser]'% target). The rpc protocol used is ncacn_np, and the general rpc protocol is as follows:

Moreover, as the underlying communication protocol of rpc, SMB generally communicates with ports 135,445. General RPC vulnerability mining tools such as spike query the name database of rpc service through specific ports to obtain some key information, as follows:

However, the server program in this vulnerability cannot obtain information through client query. The reason may be that the server uses dynamic binding when binding endpoints, and does not bind its own information to the name service. Generally, you need to call the following function to export your own information to a name service:

In this way, only specific programs can access the corresponding server programs, general msrpc fuzz tools can not get the specified information, and will not fuzz remote services, so this kind of fuzz tools are also difficult to find this type of vulnerability.

In addition to the protocol, the more important point is the remote endpoint. The POC uses the remote named pipe / pipe/browser, which is actually a little different from the RRAS protocol. Microsoft's official document [MS-RRASM] points out that if you need to interact with RRAS services, you should use the named pipe / pipe/ROUTER.

Of course, the discoverer of the vulnerability has his intention to use this named pipe, which involves another operating system flaw, namely MSRPC NULL sessions, which was studied a long time ago and may be used more in penetration. Another relatively important thing is uuid, which represents the identity of the only remote server program. The corresponding uuid in this POC is 8f09f000-b7ed-11ce-bbd2-00001a181cad. It is also stated in the official documentation that the uuid corresponds to the application of the RRAS service.

Then we begin to debug and analyze the vulnerability. Through testing on win7, winserver2003 and winserver2008, it is found that the vulnerability can only be triggered on winserver2003. Win7 has not found the function to configure remote routing. Although the RRAS service is enabled, the vulnerability cannot be triggered.

Because Microsoft no longer maintains the symbol table of win server2003, it is difficult to determine the key information of the function when debugging. At the same time, because the win server2003 used may have been patched, the shell did not rebound after the attack message was sent, and the operating system did not produce an exception. At that time, it was suspected whether the vulnerability needed other conditions to trigger. Then I looked at the event log record of win server and found an appcrash record. Click in to view the details as follows:

It can be seen from the figure that svchost.exe has crashed, and svchost has the function of managing and enabling services. Therefore, it is speculated that an exception occurred after the RRAS service received the attack message. The exception module is iptrmgr.dll. Use ida to open the dll, and jump to the offset to 0x17436 to view the code as follows:

The code here corresponds to the one provided in POC, and the next step is to debug the RRAS service using debugging tools. As a result of debugging in win server2003, many tools cannot be used, even the most basic windbg cannot be used, so we can only use the original OD to debug. Another problem is how to find the corresponding svchost program for RRAS, because the system will open multiple svchost programs. Without considering the use of other monitoring programs, you can use tasklist / M iprtrmgr.dll to display the svchost that is currently loaded with the iprtrmgr.dll module. It is almost certain that the svchost corresponds to the RRAS service, and the result is shown as follows:

Next, attach the program directly, and observe the status of the program at the breakpoint under the function where the crash occurs:

You can see that the value of ecx comes from eax, while eax comes from the third parameter. In memory dump, you can see that these are NDR (Network data representation) data constructed in POC. In MSRPC, the parameter format is encoded and decoded by NDR engine. For example, the client wants to pass a parameter of structure pointer type, which is defined in the IDL file when MIDL compiles IDL. The parameter will be encoded and converted into a data format that can be transmitted through the network by the NDR engine, decoded by the NDR engine on the server side, and passed on to the server program. The whole process is transparent to the programmer. In POC, the author exploits the vulnerability by constructing specific NDR data as server parameters. After observing the data at 0x64127058, it is found that there is a list of functions stored there, as follows:

There are a total of 0x23 functions, you can guess that the server determines the next function call according to the call number ECX value of the client, but when the incoming ecx can be controlled, then the flow of the whole program can be controlled through ROP technology.

The vulnerability discoverer exploits the vulnerability by finding a gadgets that contains jmp eax in memory, but due to a problem with the version of the application, the code at a specific address is not expected and points to an unreadable address, so an access exception is generated here, causing the application to crash.

Currently, the call stack of the program cannot be displayed properly, but it is not difficult to look at the stack pointer to find the following function calls:

The key here is mprdim.dll, which stores the server-side code stub stub. The mIDA tool of ida can be used to analyze the IDL data structure of RPC. By comparison, it is found that the code on win7 and winserver is basically similar, and there is also a loophole in win7. Because the dll on win7 can get symbols, all the following code is the corresponding win7 version. The analysis results of mprdim.dll under win7 using mIDA tool are as follows:

You can see that the function that triggered the vulnerability is RMIBEntryGetFirst, and the corresponding call number is 0x1e (30). The packet format of RRAS protocol can also be verified through wireshark:

Next, take a look at some of the key RPC data structures of the function, as follows:

This function and the corresponding data structure are defined in Microsoft's official documentation, as follows:

Starting from the second parameter, it corresponds to the three parameters we constructed. The third key parameter is the DIM_MIB_ENTRY_CONTAINER structure. When dwPid=10000 occurs, the structure points to MIB_OPAQUE_QUERY. The structure is declared as follows:

Among the functions that trigger the vulnerability, ecx represents dwVarID, while dwVarID corresponds to the number of the function, as explained by Microsoft:

It is reflected in ida as follows:

Looking at the entire implementation of the function through ida, it is found that the dwPid in the incoming data is only detected at the beginning, and the parameter range is not strictly checked, resulting in it finally pointing to the address of rop gadgets.

Looking at the key context information where the vulnerability is triggered, it is found that eax points to the buffer of the parameters passed in by the user, and the attribute of the memory is RWE (readable, writable and executable), which simply provides a perfect environment for vulnerability exploitation. There is no need to bypass DEP and other protection technologies through ROP, the vulnerability is more like a backdoor.

Of course, this is not the only function that has a loophole. Looking at the reference to the function table, you can find that the execution logic is basically similar. As long as you change the next function call number, it can also be triggered.

As mentioned earlier, the named pipe / pipe/browser is used for communication, which is enabled by default in winxp and win server2003 and is in an empty session format, which means that anonymous users can also access it without a user name or password, but on win server2008, Microsoft closes most of the named pipes, so even if the RRAS service is turned on, the previous communication cannot be established, and the vulnerability cannot be successfully exploited. The returned result is as follows:

Use the pipelist program to view the currently opened named pipes, and the results are as follows:

But all of them cannot be accessed remotely, and the results are as follows:

Therefore, if you want to successfully exploit this vulnerability, you must open a named pipe for an empty session, as follows:

This makes it possible to attack win server 2008 through POC, and most importantly, it is relatively easier to debug, using windbg and loading symbols for debugging.

Microsoft has patched the program by verifying the range of parameters, as follows:

The above is how to analyze and exploit Microsoft vulnerability CVE-2017-11885. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.