Technical Analysis of Potato Elevation of Privilege

Technical Analysis of Potato Elevation of Privilege

 

 

(Graphic independence)

0 × 00 Preface

A permission escalation tool named Potato was included a while ago. It was found that the Elevation of Privilege posture of the tool was not the same as that of the previous tool and was related to the WPAD agent. So we started the test and analysis, this article mainly analyzes the network data traffic to study the unique posture of this elevation tool. Analysis has learned a lot and hopes to share some things you have thought about. Please criticize and correct me!

The entire project code and program are on GitHub. Https://github.com/foxglovesec/Potato

It seems to be the code library established by foxglovesec and breenmachine on Github. It needs to be opened in VS2012 and later versions!

0 × 01 preliminary test

First, test the application scope and actual effect of the program:

The description of Potato indicates that permissions can be upgraded on Windows 7, 8, 10, Server 2008, and Server 2012. Let's look at it. Here's a list of tested systems.

-Windows 7 x86 and x64 systems can stably escalate permissions immediately (the term "immediate" will be explained later in the Analysis of Its Mechanism)

-Server 2008 R2 x64 can be Elevation of Privilege, but it takes about 30 minutes (related to Windows Updata time)

-Server 2012x64 can be Elevation of Privilege on the system, but it takes time to wait (longer, due to the time Windows updated certificate List)

-Windows 8 and 10 have the opportunity to test.

An important premise is that the Potato program is written in C # and must be supported by. Net Framework 3.5 or later.

0 × 02 Principle Analysis

Taking Potato's Elevation of Privilege on windows 7 as an example, the detailed analysis begins:

Potato-master \ source \ Potato \ bin \ Release is the directory of the program built in the Potato project.

Open cmd and run the following command as a normal user:

Potato.exe -ip 10.0.0.X -cmd "net user test /add" -disable_exhaust true

PS: Windows 7 SP1 x64 IP: 10.0.0.X

Enable the packet capture tool during the whole process of Potato. Wireshark cannot capture data packets on 127.0.0.1 loopback. therefore, rawcap.exe is used to capture data packets. This tool requires administrator privileges and is easy to use. files can be saved as pcap directly. Capture packets for 10.0.0.X and 127.0.0.1 at the same time. Rawcap.exe is used on a virtual machine to capture packets from 127.0.0.1 Loopback. It is used to test and capture network data on a physical machine.

Step 1: let yourself think that WPAD is its own 127.0.0.1

Supplement: WPAD (Web Proxy Auto-Discovery Protocol) Web Proxy Automatic Discovery Protocol

When the system enables automatic proxy discovery, the browser automatically searches for the proxy server in the current lan when you use the browser to access the Internet. If the proxy server is found, A configuration file named Proxy Auto-Config is downloaded from the Proxy server. This file defines the proxy server that users should use when accessing a URL. The browser downloads and parses the file, and sets the corresponding proxy server to the user's browser.

In Windows, when parsing the WPAD name, it will start from the hosts file of the local machine and then ask DNS. If we haven't figured out who WPAD is, the NBNS protocol is used for broadcasting. Potato mainly uses the NBNS protocol when implementing its first phase. However, when the native uses the NBNS protocol to ask who the WPAD is, Potato is still a common permission, it is impossible to use the sniffing technology to determine the time to send the WPAD response packet. The NBNS protocol is based on UDP and connectionless. Potato uses the technology called Local NBNS Spoofer here.

When the host uses NBNS to ask a host Name, it will issue the Name query package. If the respondent persists, the Name query response packet is returned. At this time, a problem occurs. How do you know the relationship between the query and the response? In fact, the Transaction ID field in the NBNS protocol is used to solve this problem.

 

The Transaction ID must be the same. Potato continuously sends the Name query respose response packet to port 137 of the Local Machine, while the range of the Transaction ID field is 0-65535. There are 65536 possibilities to try, when the local machine sends a Name query package for WPAD at a time, there is always a Transation ID that can correspond to it.

Is to actually intercept three data packets from many NBNS sent by Potato. Check TransationID.

 

Finally, let's look at the matching graph.

Potato achieves the goal of making yourself think 127.0.0.1 is WPAD. At this time, ping WPAD and you will find that it is 127.0.0.1.

 

The above is based on the NBNS protocol used by the inquirer to ask who the WPAD is, the host will first ask the DNS before using NBNS, if there is a WPAD In the DNS, the Inquirer will no longer use NBNS, the first stage of the purpose is not ruined?

The-disable_exhaust parameter solves this problem. It is called the UDP port depletion technology to invalidate DNS. Yes. It indicates that DNS uses the UDP protocol.

 

Potato binds every UDP port that can be bound. As a result, no source port can be used for UDP requests. After DNS failure, the Inquirer will have to use the NBNS protocol. Potato reached its first stage goal again.

PS: theoretically, as long as there is a fast enough connection, NBNS spoofing can be performed on any Windows host that can communicate with UDP port 137.

Step 2: Expand the fake WPAD proxy service on the local machine

The first stage completes spoofing on the local machine, making it think that 127.0.0.1 is WPAD, then the local machine will obtain the PAC file from the WPAD.

In windows, Internet Explorer automatically attempts to detect network proxy settings by accessing "http: // wpad/wpad. dat" by default. Surprisingly, this is also applicable to some windows services, such as Windows Update, but the specific situation is related to the Windows version. Potato binds port 80 of 127.0.0.1 and runs the http server. when it receives a request for "http: // wpad/wpad. dat", it will respond with the following content.

Access Port 80 of the WPAD you think, and obtain http: // wpad/wpad. dat.

 

Potato false WPAD proxy service response, PAC file:

 

Is its corresponding code section. The-wpad_exclude parameter of Potato will exclude the specified domain name, that is, the subsequent domain name will not go through the proxy.

 

In the second stage, Potato uses its own fake WPAD and PAC files to make the local machine use 127.0.0.1: 80 as a proxy for part of the traffic on the local machine (excluding wpad_exclude) all are redirected through servers running on 127.0.0.1 through Potato. This is what the local machine accesses. The data will be immediately thrown to port 127.0.0.1: 80.

Originally: 10.0.0.122> Internet

Now it is: 10.0.0.122> 127.0.0.1: 80> Internet

Potato itself has no permissions and cannot sniff data. However, after the second stage of Potato is completed, the data is directly thrown to Potato's 127.0.0.1: 80 ...... Become a man in the middle!

Step 3: Use the data redirection completed in the second stage, HTTP-> smb ntlm Relay

The last phase involves the NTLM authentication process. If any errors occur, please correct them! Thank you!

In the second stage, Potato has successfully changed itself into a man-in-the-middle. In Windows 7, there is a Windows Defender update mechanism that accesses the network through proxy settings. It is the HTTP data sent when the local Windows Defender update mechanism is started. Because of the successful implementation of the previous two phases, the system directly throws the data packet to the 127.0.0.1: 80 proxy.

 

In the previous test, the term "immediate" was used in Windows 7, which means that in Windows 7, Windows Defender can check the update immediately in some way to generate headrequests such as http://download.windowsupdate.com. PS: The HEAD request is only the header of the Request page.

Windows Defender update, triggered by % ProgramFiles % \ Windows Defender \ MpCmdRun.exe. It has a parameter-SignatureUpdate

 

It is the corresponding section in the Potato code.

 

One day, the following code runs with the mpcmdrun.exe-SignatureUpdate parameter. Windows Defender checks the update immediately to generate a request. In addition, the operation can take effect without the need for any permissions of mpcmdrun.exe-SignatureUpdate. When a request appears, the false http server of Potato responds to the request, and the returned HTTP status code is 302.

 

302 indicates temporary transfer. A redirection will be made and jump to the URL in the Location field. Redirect the page to http: // localhost/GETHASHES836186.

 

When the local machine sends a HEAD/GETHASHES836186 request to 127.0.0.1: 80, Potato responds to this request again, with the HTTP Status Code 401.

 

401 indicates that the current request requires user authentication. The response must contain a WWW-Authenticate header to ask the user information. This visible false http service tells the requester, use NTLM to authenticate your identity.

Next we start the HTTP-> smb ntlm Relay process. Insert a paragraph in README. md:

NTLM replay has long been known, but we often mistakenly understand the Windows NTLM authentication attack. The NTLM protocol is vulnerable to man-in-the-middle attacks. If an attacker can trick a user into using NTLM to authenticate the attacker's machine, the attacker can replay the authentication attempt on other machines. The previous exploitation of this attack was to allow the victim to use the SMB protocol to try NTLM authentication for the attacker. Attackers can replay these creden on the victim machine and obtain remote access using technologies such as pesexec. Microsoft has fixed this issue and used the challenge response mechanism to disable NTLM authentication for the same protocol. This means that SMB-> smb ntlm replay, from a host to the host itself, will not work. However, cross-protocol attacks, such as HTTP-> smb ntlm replay attacks, are still valid.

Since the http service tells the client that the request needs to be verified, the client starts the NTLM authentication process based on the HTTP protocol.

1. First, the client sends an NTLMSSP_NEGOTIATE authentication negotiation request to 127.0.0.1: 80 (that is, Potato.

 

127.0.0.1: 80 after receiving the authentication and negotiation from the client, the system sends a Request for the SMB Protocol-based Negotiate Protocol Request to the local port 445 MSRPC service instead of an urgent response. The RPC service responds.

 

Potato uses the HTTP-based NTLMSSP_NEGOTIATE authentication negotiation request sent from the client, decodes the authentication information Base64, and then replays it to the RPC service on port 445 of the local machine through the SMB protocol.

 

The authentication information in the above HTTP-based NTLMSSP_NEGOTIATE authentication negotiation request is base64-encoded and decoded.

 

Compared with the above SMB, it was confirmed that it was a replay attack.

2. Then, the local port 445 RPC service will respond to the NTLMSSP_NEGOTIATE request based on the SMB protocol and return a NTLMSSP_CHALLENGE response, which has a key Challenge NTLN Server Challenge.

 

This response will be sent to Potato, which uses Base64 encoding and then replayed to the client over HTTP.

 

3. The client uses the NTLN Server Challenge to encrypt the user and password, and then sends it to 127.0.0.1: 80.

 

Potato decodes the authenticated Base64 sent from the client and then replays it to port 445 of the local machine through the SMB protocol.

 

However, I found a problem later. In the above HTTP, the fields in the NTLM Secure Service Provider are empty. How can this problem be solved? After capturing the normal net use \ IP to log on to a host, it is also the NTLMSSP_AUTH package. See.

 

In normal authentication, NTLM Client Challenge in NTLMSSP_AUTH should exist. However, the above authentication does not exist, but the local machine actually thinks that the authentication is successful. The NT Status in Session Setup AndX Response indicates that the authentication is successful.

The key data in NTLMSSP_AUTH is empty, so I came up with a possible problem. I have actually verified the problem and will answer it later. I will release this question for the moment.

 

At this time, Potato seems to have system permissions, so it starts to create a service and start the service to execute commands. I will explain how permissions become system permissions together with the above questions.

 

This GetShellXXX is the service created by Potato.

 

The corresponding code is used to implement functions similar to ipvxec. It is actually used to create and start a service.

 

In Potato, the 'net user test/add' parameter in-cmd is successfully executed and the permission is raised. The third stage of Potato has also been successfully implemented!

In Windows 7, the whole running process of Potato is described above. The main difference between other system environments is that the update mechanism of Windows XXXX is different.

-In Windows 7, a new mechanism of Windows defenderis used, and the mpcmdrun.exe program allows this mechanism to check for updates immediately, so it can be stable and effective immediately.

-Windows Server 2008 does not have its own Defender. However, Windows Update can check the Update mechanism, but it cannot control the time when the machine checks the Update. The worst test case is about 30 minutes, windows Update may be checked once every 30 minutes. This is also good, at least not long. (The actual test can basically be at least 30 minutes)

-In Windows Server 2012, Windows 8, and 10, Windows Update may no longer use the proxy settings in "Internet Option (Internet Option)". WPAD is not checked. However, in these versions, there is an automatic update mechanism that downloads the Certificate Trust List (CTLs) every day. This mechanism also checks WPAD, and the worst case is 24 hours. (The actual test is satisfactory. After waiting for more than one hour, it may happen that the certificate trust list has been updated)

The test environment is not connected to the Internet, and there is little to do with the connection, as long as some update mechanism in the system works.

0 × 03 try to answer the previous questions

The problem that the client is Empty in the NTLMSSP_AUTH authentication packet sent to 127.0.0.1: 80.

 

 

After careful consideration, there is a possibility that the above authentication process 127.0.0.1: 80 to 127.0.0.1: 445 is equivalent to opening a CMD on net use \ 127.0.0.1, regardless of the permission size, input net use \ 127.0.0.1 will succeed.

Is there any data packet in this process? Of course! Use rawcap.exe to capture packets for 127.0.0.1 Loopback.

 

 

This is captured in the Window 7 environment. Why is the protocol SMB2? When sending a Negotiate Protocol Request, the client will indicate in this package what protocols it supports for authentication. (Dialects translates into "Dialects". It's interesting ~)

 

 

The server returns a Negotiate Protocol Respose, which contains the "dialect" it chooses ". There are several principles for the server to select Dialects. One is that it must be supported in the list of data packets sent from the client, the other is that it must be supported, and the third is that it is not high or low. High Version security is inevitable, but compatibility must be considered. It is also related to the settings in the Local Security Policy.

For example, the client is on the left and the server is on the right.

-XP-> xp ntlm 0.12

-Windows 7-> Windows 7 SMB 2

-Windows 7-> Server 2003 NTLM 0.12

-Windows 7-> Server 2008 SMB 2

The security of NTLM 0.12 is normal, and it seems that brute force cracking can be detected throughout the communication process. The timestamp is added to SMB2, And the replay attack will become invalid. Windows 7> Windows 7 does not use SMB 2 in this environment?

In fact, Potato is downgraded. When it sends a Negotiate Protocol Request packet to port 445 of the local machine, this packet is constructed by Potato, in its Dialects, only the NTLM 0.12 server can select NTLM 0.12 according to the above selection principles.

 

 

The security of NTLM 0.12 cannot defend against replay attacks. Many man-in-the-middle attacks have been downgraded.

 

 

Here is also Empty. It turns out that net use \ 127.0.0.1 does not need to be verified, but the authentication process has gone through again. The preceding questions can be explained. Including http: // localhost/GETHASHES836186, it seems that the authentication process is only repeated.

 

 

Potato only performs a relay, and its relay is used to provide the RPC service of the local machine during the process of authentication from the local machine to false http.

So there is one question left, how is the permission upgraded ???

After net use \ 127.0.0.1, a normal user on the local machine is successfully granted the normal permission. So where does the High permission come from? Draw a picture of the network data Behavior analyzed above, from top to bottom, indicating the time of occurrence.

 

 

The system permissions obtained by Potao later come from the client!

. Net use \ 127.0.0.1. If it is a net use \ 127.0.0.1 issued by a system service, the system permission must be obtained after successful execution. The same is true for HTTP requests. When an HTTP request comes from a high-Permission customer, the authenticated permission is also the corresponding high-permission.

In Windows 7, the following parameters are used to run the command with the mpcmdrun.exe parameter to start the Defender update. It is a normal permission to run the mpcmdrun.exe, indicating that the program is not a client that actually sends a HEAD request. After a simple static analysis, it is found that the Imports program does not have functions related to network communication. I guess the real client, the actual initiator of the HEAD request may be the Windows Defender (WinDefend) Service or the Windows Update (wuauserv) service, both of them are system-authorized and have been running since startup.

0 × 04 Summary

In summary, Potato is first trying to make itself a man-in-the-middle, then finding a method to trigger the Windows Update mechanism, or simply waiting for Windows to regularly check for updates. When an update request is checked, the system update service is used as a client with high permissions to send an http request. The Potato man-in-the-middle interface redirects the request in the response and requires the client to authenticate the request, using a high-Permission client to authenticate a local fake http service, the authentication data is forwarded to the system's RPC service, forcing the system's RPC service to think that the Potato man-in-the-middle is a customer with high permissions, this completes the Elevation of Privilege!

Disadvantages of Potato:

In Windows 7, Potato uses the update mechanism of Windows Defender to achieve immediate effect. In other environments, Potato uses the NBNS Spoofer Technology in the first phase of elevation of permission to quickly send a large number of data packets. The test shows that it consumes a lot of CPU, it also takes a long time. It has not been tested whether the host access network will be affected during this process. After all, some network data is sent to 127.0.0.1: 80.

The specific implementation of Potato code is not much said. It can be converted into other languages and written without relying on. NET, so that it is more suitable.