Vulnerabilities > CVE-2015-2370 - Permissions, Privileges, and Access Controls vulnerability in Microsoft products
Attack vector
LOCAL Attack complexity
LOW Privileges required
NONE Confidentiality impact
COMPLETE Integrity impact
COMPLETE Availability impact
COMPLETE Summary
The authentication implementation in the RPC subsystem in Microsoft Windows Server 2003 SP2 and R2 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 does not prevent DCE/RPC connection reflection, which allows local users to gain privileges via a crafted application, aka "Windows RPC Elevation of Privilege Vulnerability."
Vulnerable Configurations
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 | Windows 8.1 - DCOM DCE/RPC Local NTLM Reflection Privilege Escalation (MS15-076). CVE-2015-2370. Local exploit for windows platform |
| file | exploits/windows/local/37768.txt |
| id | EDB-ID:37768 |
| last seen | 2016-02-04 |
| modified | 2015-08-13 |
| platform | windows |
| port | |
| published | 2015-08-13 |
| reporter | monoxgas |
| source | https://www.exploit-db.com/download/37768/ |
| title | Windows 8.1 - DCOM DCE/RPC Local NTLM Reflection Privilege Escalation MS15-076 |
| type | local |
Msbulletin
| bulletin_id | MS15-076 |
| bulletin_url | |
| date | 2015-07-14T00:00:00 |
| impact | Elevation of Privilege |
| knowledgebase_id | 3067505 |
| knowledgebase_url | |
| severity | Important |
| title | Vulnerability in Windows Remote Procedure Call Could Allow Elevation of Privilege |
Nessus
| NASL family | Windows : Microsoft Bulletins |
| NASL id | SMB_NT_MS15-076.NASL |
| description | The remote Windows host is affected by a privilege escalation vulnerability in the Microsoft Remote Procedure Call (RPC) due to incorrectly allowing DCE/RPC connection reflection. A remote, authenticated attacker can exploit this vulnerability, with a specially crafted application, to elevate privileges. Note that in order to exploit this issue, an attacker would first have to log onto the system. |
| last seen | 2020-06-01 |
| modified | 2020-06-02 |
| plugin id | 84748 |
| published | 2015-07-14 |
| reporter | This script is Copyright (C) 2015-2019 and is owned by Tenable, Inc. or an Affiliate thereof. |
| source | https://www.tenable.com/plugins/nessus/84748 |
| title | MS15-076: Vulnerability in Windows Remote Procedure Call Could Allow Elevation of Privilege (3067505) |
| code | |
Seebug
| bulletinFamily | exploit |
| description | Windows: DCOM DCE/RPC-Local NTLM Reflection Elevation of Privilege Platform: Windows 8.1 Update (not tested on Windows 7, 10) Class: Elevation of Privilege #### Summary: Local DCOM DCE/RPC connections can be reflected back to a listening TCP socket allowing access to an NTLM authentication challenge for the LocalSystem user which can be replayed to the local DCOM activation service to elevate privileges. #### Description: Note, before we start I realize that you didn't fix the WebDAV => SMB one, you might conclude that this is a won't fix as well but I couldn't find good documentation on how to improve the security situation with the DCOM-DCE/RPC to mitigate it (at least anything which seemed to work). Also the behaviour is slightly different. I did point out in the original report that WebDAV wasn't necessarily the only way of getting an NTLM authentication challenge, with the DCE/RPC being a specific example. Anyway on to the description. When a DCOM object is passed to an out of process COM server, the object reference is marshalled in an OBJREF to the stream. For marshal-by-reference this results in an OBJREF_STANDARD stream being generated which provides enough information to the server to locate the original object and bind to it. Along with the identity for the object is a list of the RPC binding strings (containing a TowerId and a string). This can be abused to connect to an arbitrary TCP port when an unmarshal occurs by specifying the tower as NCACN_IP_TCP and a string in the form “host[port]”. When the object resolver tries to bind the RPC port it will make a TCP connection to the specified address and if needed will try and do the authentication based on the security bindings. If we specify the NTLM authentication service in the bindings then the authentication will use basic, NTLM. We just need to get a privileged COM service to unmarshal the object, we could do this on a per-service basis by finding an appropriate DCOM call which takes an object, however we can do it generically by abusing the activation service which takes a marshalled IStorage object and do it against any system service (such as BITS). So this gets us a reflected NTLM authentication challenge, but what to do with it? There are at least 3 uses for this: 1) Use the NTLM for reflection back to the local SMB service (as per the WebDAV version) but of course this is considered former site. 2) Locally negotiate the NTLM which will give you back a full impersonation level token for the LocalSystem (even done as a normal user). This is of most use for escaping Local Service/Network Service because you can combine this with the SeImpersonatePrivilege for token kidnapping. 3) Reflect the NTLM back to a local RPC TCP endpoint, this is what we'll do for a proof-of-concept. It turns out that a number of RPC endpoints over TCP enforce at least RPC_C_AUTHN_LEVEL_CALL or RPC_C_AUTHN_LEVEL_PKT level security on the RPC channel. This, like SMB signing, makes it difficult to do reflection attacks. However not all services do, for example the DCOM IRemoteSCMActivator service doesn’t seem to enforce signing for the call (only requires RPC_C_AUTHN_LEVEL_CONNECT). While by default it does require authentication as an administrator we get that from the LocalSystem NTLM reflection. This allows us to create any out-of-process COM object locally as LocalSystem (unless it's already a COM service where it uses the identity of the service). While you can create the object there's a problem, you can’t typically communicate with the object afterwards. Services such as WMI to listen on TCP so can be accessed using the NTLM reflection afterwards however this enforces signing so any calls will fail. You can request a NCALRPC binding from the activation but this will be limited by the ability of the current user to bind to it. It turns out that our answer to this problem has already been used once, we can abuse the same IStorage marshalling in the activation process to initialize an object through IPersistFile or IPersistStorage before returning back to the caller. As long As you can find an object which runs out of process, can be initialized through one of those interfaces and does something exploitable during initialization we can use it to elevate privileges. A good example is everyone's favourite a COM object, the OLE Packager. As shown by various researchers, specifically Haifei Li (see https://blogs.mcafee.com/mcafee-labs/dropping-files-temp-folder-raises-security-concerns). This will drop arbitrary files to the user's temporary folder during the IPersistStorage initialization. The temporary folder for the localsystem is %windir%\temp which is writable by normal authenticated users. Also while it's a DLL server it is registered with an AppId supported DllSurrogate so we can create it out-of-process. Due to the way the target path during initialization is created it doesn't look obvious how you'd exploit this, especially as we can’t create file-level symbolic links as a normal user. One attack we can do is as we control the filename we can use the $INDEX_ALLOCATION trick to convert a directory junction to a file level symbolic link. However that leaves you with a timing issue as a call is made to PathFileExists which will then fall back into generating the temporary file. Considering the packager, if it fails to initialize causes heap corruption in Dllhost (seriously) this isn't a good approach. Instead we can abuse the operation of PathFindFileName which has odd behaviour if the path ends with a slash, specifically it assumes the last component is the name plus the tailing slash, it doesn't remove it. You also have to use the forward slash otherwise it doesn't work (you get an invalid name when generating the temporary file). So if we use the path, c:\path\somefile/ in the package it first checks the %windir%\temp\somefile to see if it exists. We can drop a directory at that location so that the check continues to generate the temporary file. The code will then try the %windir%\temp\somefile/ (2) which as Win32 handles both slashes tries to create a file inside a directory we control, which we set as a junction to a system directory (we can change the file name as well but that's left as an exercise for the reader). #### Proof of Concept: I’ve provided a PoC which creates an arbitrary file at local system privileges. In the PoC, the file is typically called ‘ (2)’ or similar, however through the combined junction/object manager symlink attacks this can be created with any name you like (just the PoC doesn't bother to do so). The PoC has only been tested on 64 bit Windows 8.1 update. 1) Extract the PoC to a location on a local harddisk which is writable by a normal user 2) Execute Poc_DCERPCNTLMReflection_EoP.exe file as a normal user 3) There should be a ‘ (2)’ file created in the c:\windows directory, with arbitrary content. Expected Result: The NTLM reflection should fail Observed Result: The NTLM reflection succeeds and an arbitrary file is created as a privileged user Known Issues with the PoC: 1) If an existing instance of the package class is running as local system it will not reinitialize the object and the exploit will not work. 2) Sometimes the virus fails completely during the reflection attack, this is typically indicated by a lot of error output being display to the console. Re-running the poc usually fixes this. Attachment: [poc.zip](<http://paper.seebug.org/papers/Archive/poc/CVE-2015-2370.zip>) |
| id | SSV:93042 |
| last seen | 2017-11-19 |
| modified | 2017-04-25 |
| published | 2017-04-25 |
| reporter | Root |
| title | MS15-076 Windows: DCOM DCE/RPC Local NTLM Reflection Elevation of Privilege (CVE-2015-2370) |