Vulnerabilities > CVE-2016-3225 - Permissions, Privileges, and Access Controls vulnerability in Microsoft products
Attack vector
LOCAL Attack complexity
MEDIUM Privileges required
NONE Confidentiality impact
COMPLETE Integrity impact
COMPLETE Availability impact
COMPLETE Summary
The SMB server component in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 allows local users to gain privileges via a crafted application that forwards an authentication request to an unintended service, aka "Windows SMB Server Elevation of Privilege Vulnerability."
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| OS | 10 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Accessing, Modifying or Executing Executable Files An attack of this type exploits a system's configuration that allows an attacker to either directly access an executable file, for example through shell access; or in a possible worst case allows an attacker to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
- Leverage Executable Code in Non-Executable Files An attack of this type exploits a system's trust in configuration and resource files, when the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high. The attack can be directed at a client system, such as causing buffer overrun through loading seemingly benign image files, as in Microsoft Security Bulletin MS04-028 where specially crafted JPEG files could cause a buffer overrun once loaded into the browser. Another example targets clients reading pdf files. In this case the attacker simply appends javascript to the end of a legitimate url for a pdf (http://www.gnucitizen.org/blog/danger-danger-danger/) http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here The client assumes that they are reading a pdf, but the attacker has modified the resource and loaded executable javascript into the client's browser process. The attack can also target server processes. The attacker edits the resource or configuration file, for example a web.xml file used to configure security permissions for a J2EE app server, adding role name "public" grants all users with the public role the ability to use the administration functionality. The server trusts its configuration file to be correct, but when they are manipulated, the attacker gains full control.
- Blue Boxing This type of attack against older telephone switches and trunks has been around for decades. A tone is sent by an adversary to impersonate a supervisor signal which has the effect of rerouting or usurping command of the line. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded Telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authorization for administrative functions. While the infrastructure is different than standard current applications like web applications, there are historical lessons to be learned to upgrade the access control for administrative functions.
- Restful Privilege Elevation Rest uses standard HTTP (Get, Put, Delete) style permissions methods, but these are not necessarily correlated generally with back end programs. Strict interpretation of HTTP get methods means that these HTTP Get services should not be used to delete information on the server, but there is no access control mechanism to back up this logic. This means that unless the services are properly ACL'd and the application's service implementation are following these guidelines then an HTTP request can easily execute a delete or update on the server side. The attacker identifies a HTTP Get URL such as http://victimsite/updateOrder, which calls out to a program to update orders on a database or other resource. The URL is not idempotent so the request can be submitted multiple times by the attacker, additionally, the attacker may be able to exploit the URL published as a Get method that actually performs updates (instead of merely retrieving data). This may result in malicious or inadvertent altering of data on the server.
- Target Programs with Elevated Privileges This attack targets programs running with elevated privileges. The attacker would try to leverage a bug in the running program and get arbitrary code to execute with elevated privileges. For instance an attacker would look for programs that write to the system directories or registry keys (such as HKLM, which stores a number of critical Windows environment variables). These programs are typically running with elevated privileges and have usually not been designed with security in mind. Such programs are excellent exploit targets because they yield lots of power when they break. The malicious user try to execute its code at the same level as a privileged system call.
Exploit-Db
| description | Microsoft Windows - Net-NTLMv2 Reflection DCOM/RPC (Metasploit). CVE-2016-3225. Local exploit for Windows platform. Tags: Metasploit Framework (MSF), Local |
| file | exploits/windows/local/45562.rb |
| id | EDB-ID:45562 |
| last seen | 2018-10-08 |
| modified | 2018-10-08 |
| platform | windows |
| port | |
| published | 2018-10-08 |
| reporter | Exploit-DB |
| source | https://www.exploit-db.com/download/45562/ |
| title | Microsoft Windows - Net-NTLMv2 Reflection DCOM/RPC (Metasploit) |
| type | local |
Metasploit
description Module utilizes the Net-NTLMv2 reflection between DCOM/RPC to achieve a SYSTEM handle for elevation of privilege. Currently the module does not spawn as SYSTEM, however once achieving a shell, one can easily use incognito to impersonate the token. id MSF:EXPLOIT/WINDOWS/LOCAL/MS16_075_REFLECTION last seen 2020-06-09 modified 2018-10-04 published 2018-08-03 references - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3225
- http://blog.trendmicro.com/trendlabs-security-intelligence/an-analysis-of-a-windows-kernel-mode-vulnerability-cve-2014-4113/
- https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/
- https://github.com/breenmachine/RottenPotatoNG
reporter Rapid7 source https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/windows/local/ms16_075_reflection.rb title Windows Net-NTLMv2 Reflection DCOM/RPC
Msbulletin
| bulletin_id | MS16-075 |
| bulletin_url | |
| date | 2016-06-14T00:00:00 |
| impact | Elevation of Privilege |
| knowledgebase_id | 3164038 |
| knowledgebase_url | |
| severity | Important |
| title | Security Update for Windows SMB Server |
Nessus
| NASL family | Windows : Microsoft Bulletins |
| NASL id | SMB_NT_MS16-075.NASL |
| description | The remote Windows host is missing a security update. It is, therefore, affected by an elevation of privilege vulnerability in the Microsoft Server Message Block (SMB) server when handling forwarded credential requests that are intended for another service running on the same host. An authenticated attacker can exploit this, via a specially crafted application, to execute arbitrary code with elevated permissions. |
| last seen | 2020-06-01 |
| modified | 2020-06-02 |
| plugin id | 91603 |
| published | 2016-06-14 |
| reporter | This script is Copyright (C) 2016-2019 and is owned by Tenable, Inc. or an Affiliate thereof. |
| source | https://www.tenable.com/plugins/nessus/91603 |
| title | MS16-075: Security Update for Windows SMB Server (3164038) |
| code | |
Packetstorm
data source https://packetstormsecurity.com/files/download/149689/ms16_075_reflection.rb.txt id PACKETSTORM:149689 last seen 2018-10-06 published 2018-10-05 reporter Mumbai source https://packetstormsecurity.com/files/149689/Windows-Net-NTLMv2-Reflection-DCOM-RPC.html title Windows Net-NTLMv2 Reflection DCOM/RPC data source https://packetstormsecurity.com/files/download/151182/ms16_075_reflection_juicy.rb.txt id PACKETSTORM:151182 last seen 2019-01-16 published 2019-01-16 reporter breenmachine source https://packetstormsecurity.com/files/151182/Microsoft-Windows-Net-NTLMv2-Reflection-DCOM-RPC-Privilege-Escalation.html title Microsoft Windows Net-NTLMv2 Reflection DCOM/RPC Privilege Escalation
Seebug
| bulletinFamily | exploit |
| description | ## Overview As we mentioned a number of times throughout our talk, this work is derived directly from James Forshaw’s [BlackHat talk](https://www.youtube.com/watch?v=QRpfvmMbDMg) and [Google Project Zero research](https://bugs.chromium.org/p/project-zero/issues/detail?id=325&redir=1). I highly recommend reviewing both of these resources to anyone interested in pursuing this topic. The idea behind this vulnerability is simple to describe at a high level: 1. Trick the “NT AUTHORITY\SYSTEM” account into authenticating via NTLM to a TCP endpoint we control. 2. Man-in-the-middle this authentication attempt (NTLM relay) to locally negotiate a security token for the “NT AUTHORITY\SYSTEM” account. This is done through a series of Windows API calls. 3. Impersonate the token we have just negotiated. This can only be done if the attackers current account has the privilege to impersonate security tokens. This is usually true of most service accounts and not true of most user-level accounts. Each of these steps are described in the following 3 sections. ## NTLM Relay to Local Negotiation NTLM relay from the local “NT AUTHORITY\SYSTEM” (we will just call it SYSTEM for brevity) account back to some other system service has been the theme for the Potato privilege escalation exploits. The first step is to trick the SYSTEM account into performing authentication to some TCP listener we control. In the original [Hot Potato exploit](https://foxglovesecurity.com/2016/01/16/hot-potato/), we did some complex magic with NBNS spoofing, WPAD, and Windows Update services to trick it into authenticating to us over HTTP. For more information, see the original blog post. Today, we’ll be discussing another method to accomplish the same end goal which James Forshaw discussed [here](https://bugs.chromium.org/p/project-zero/issues/detail?id=325&redir=1). We’ll basically be tricking DCOM/RPC into NTLM authenticating to us. The advantage of this more complex method is that it is 100% reliable, consistent across Windows versions, and fires instantly rather than sometimes having to wait for Windows Update. ### Getting Started We’ll be abusing an API call to COM to get this all kicked off. The call is “CoGetInstanceFromIStorage” and to give you some context, here is the relevant code: <pre class="brush: cpp; title: ; notranslate" title="">public static void BootstrapComMarshal() { IStorage stg = ComUtils.CreateStorage(); // Use a known local system service COM server, in this cast BITSv1 Guid clsid = new Guid("4991d34b-80a1-4291-83b6-3328366b9097"); TestClass c = new TestClass(stg, String.Format("{0}[{1}]", "127.0.0.1", 6666)); // ip and port MULTI_QI[] qis = new MULTI_QI[1]; qis[0].pIID = ComUtils.IID_IUnknownPtr; qis[0].pItf = null; qis[0].hr = 0; CoGetInstanceFromIStorage(null, ref clsid, null, CLSCTX.CLSCTX_LOCAL_SERVER, c, 1, qis); } </pre> I’m far from being an expert on COM. The “CoGetInstanceFromIStorage” call attempts to fetch an instance of the specified object from a location specified by the caller. Here we are telling COM we want an instance of the BITS object and we want to load it from 127.0.0.1 on port 6666. It’s actually a little more complex than that, because really we’re fetching the object from an “IStorage” object, not just passing a host/port directly. In the code above “TestClass” is actually an instance of an IStorage object in which we’ve replaced some bits and pieces to point back to “127.0.0.1:6666”. ### Man-In-The-Middle So, now we have COM trying to talk to us on port 6666 where we’ve spun up a local TCP listener. If we reply in the correct way, we have have COM (running as the SYSTEM account) try to perform NTLM authentication with us. COM is trying to talk to us using the RPC protocol. I’m not particularly fluent in RPC and wouldn’t be surprised if there were slight variations based on Windows versions. In order to avoid many headaches, we’re going to use a trick in order to craft our replies. What we will do is relay any packets we receive from COM on TCP port 6666, back to the local Windows RPC listener on TCP port 135\. Since these packets we’re receiving are part of a valid RPC conversation, whatever version of Windows we are running will respond appropriately. We can then use these packets we receive back from Windows RPC on TCP 135 as templates for our replies to COM. If that’s not clear, the following shows the first few packets of this exchange in WireShark:  Notice that the first packet we receive (packet #7) is incoming on port 6666 (our listener, this is COM talking to us). Next, we relay that same packet (packet #9) to RPC on TCP 135\. Then in packet #11, we get a reply back from RPC (TCP 135), and in packet #13, we relay that reply to COM. We simply repeat this process until it’s time for NTLM authentication to occur. You can think of these initial packets as just setting the stage for the eventual NTLM auth. ### NTLM Relay and Local Token Negotiation Before we dive into the NTLM relay details, let’s look at it at a high level. The following is from our slide deck:  On the left in blue are the packets that COM is going to send to us on TCP port 6666\. On the right, in red, are the Windows API calls that we’re going to make using data that we pull out of those packets. Let’s look a little closer at the API calls on the right, since most people will not be familiar with them. In order to locally negotiate a security token using NTLM authentication, one must first call the function “AcquireCredentialsHandle” to get a handle to the data structure we will need. Next, we call “AcceptSecurityContext”, and the input to this function will be the NTLM Type 1 (Negotiate) message. The output will be an NTLM Type 2 (Challenge) message which is sent back to the client trying to authenticate, in this case, DCOM. When the client responds with an NTLM Type 3 (Authenticate) message, we then pass that to a second call to “AcceptSecurityContext” to complete the authentication process and get a token. Let’s look at the packet capture and break this all down… #### Type 1 (Negotiate) Packet After relaying a few packets between RPC and COM, eventually COM is going to try to initiate NTLM authentication with us by sending the NTLM Type 1 (Negotiate) message, as shown in packet #29 of the packet capture below:  This is where things start to get interesting. Again, we relay this to RPC (on TCP 135), and RPC will reply with an NTLM Challenge. But there’s one more thing going on here that you don’t see in the packet capture. When we receive the NTLM Type 1 (Negotiate) message from COM, we rip out the NTLM section of the packet (as shown below), and use it to begin the process of locally negotiating a token:  So, as discussed above, we call “AcquireCredentialsHandle”, and then “AcceptSecurityContext”, passing as input the NTLM Type 1 (Negotiate) message we pulled out of that packet. #### NTLM Type 2 (Challenge) Packet Recall that we forwarded the NTLM Type 1 (Negotiate) packet to RPC on port 135, RPC will now reply with an NTM Type 2 (Challenge) packet which can be seen in our packet capture above in packet #33\. This time, we do NOT simply forward this packet back to COM, we need to do some work first. Let’s take a closer look at the two NTLM Type 2 (Challenge) packets from the capture above:  Notice the highlighted field “NTLM Server Challenge” and the field below it “Reserved”, and that they differ in value. This would not be the case if we had simply forwarded the packet from RPC (on the left) to COM (the one on the right). Recall that when we made the Windows API call to “AcceptSecurityContext”, the output of that call was an NTLM Type 2 (Challenge) message. What we’ve done here is replace the NTLM blob inside the packet that we are sending to COM with the result of that API call. Why would we do this? Because we need COM, running as the SYSTEM account to authenticate using the NTLM challenge and “Reserved” section that we are using to negotiate our local token, if we did not replace this section in the packet, then our call to “AcceptSecurityContext” would fail. We’ll talk more about how local NTLM authentication works later, but for now just know that the client who is trying to authenticate (in this case SYSTEM through COM) needs to do some magic with the “NTLM Server Challenge” and “Reserved” sections of the NTLM Type 2 (Negotiate) packet, and that we’ll only get our token if this magic is performed on the values produced by our call to “AcceptSecurityContext”. #### NTLM Type 3 (Authenticate) Packet So now we’ve forwarded the modified NTLM Type 2(Negotiate) packet to COM where the “Challenge” and “Reserved” fields match the output from “AcceptSecurityContext”. The “Reserved” field is actually a reference to a SecHandle, and when the SYSTEM account receives the NTLM Type 2 message, it will perform authentication behind the scenes in memory. That is why it is so crucial that we update the “Reserved” field… Otherwise, it would be authenticating to RPC instead of US! Once this is completed, COM on behalf of the SYSTEM account will send us back the NTLM Type 3 (Authenticate) packet. This will just be empty (because all the actual authentication here happened in memory), but we will use it to make our final call to “AcceptSecurityContext”. We can then call “ImpersonateSecurityContext” with the result of the final call above to get an impersonation token. So now we’ve forwarded the modified NTLM Type 2(Negotiate) packet to COM where the “Challenge” and “Reserved” fields match the output from “AcceptSecurityContext”. The “Reserved” field is actually a reference to a SecHandle, and when the SYSTEM account receives the NTLM Type 2 message, it will perform authentication behind the scenes in memory. That is why it is so crucial that we update the “Reserved” field… Otherwise, it would be authenticating to RPC instead of US! Once this is completed, COM on behalf of the SYSTEM account will send us back the NTLM Type 3 (Authenticate) packet. This will just be empty (because all the actual authentication here happened in memory), but we will use it to make our final call to “AcceptSecurityContext”. We can then call “ImpersonateSecurityContext” with the result of the final call above to get an impersonation token. ## Using the ImpersonationToken The following diagram (youtube play bar included) from James Forshaw’s BlackHat talk [“Social Engineering the Windows Kernel”](https://www.youtube.com/watch?v=QRpfvmMbDMg) shows the pre-requisites to impersonating the token that we have now negotiated:  From this, it is clear that if we want to impersonate the token, we better be running as an account with SeImpersonate privilege (or equivalent). Luckily this includes many service accounts in Windows that penetration testers often end up running as. For example, the IIS and SQL Server accounts. |
| id | SSV:93043 |
| last seen | 2017-11-19 |
| modified | 2017-04-25 |
| published | 2017-04-25 |
| reporter | Root |
| title | MS16-075 Windows SMB Server Elevation of Privilege Vulnerability (CVE-2016-3225) |