Faiblesses connexes
CWE-ID |
Nom de la faiblesse |
Source |
CWE-264 |
Category : Permissions, Privileges, and Access Controls Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control. |
|
Metrics
Metric |
Score |
Sévérité |
CVSS Vecteur |
Source |
V2 |
7.2 |
|
AV:L/AC:L/Au:N/C:C/I:C/A:C |
[email protected] |
EPSS
EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.
EPSS Score
Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.
EPSS Percentile
Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
Informations sur l'Exploit
Exploit Database EDB-ID : 39311
Date de publication : 2016-01-24 23:00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes
Source: https://code.google.com/p/google-security-research/issues/detail?id=573
Windows: Sandboxed Mount Reparse Point Creation Mitigation Bypass Redux
Platform: Windows 10, not tested any other OS
Class: Security Feature Bypass
Summary:
The fix for CVE-2015-2553 can be bypassed to get limited mount reparse points working again for sandbox attacks.
Description:
Not sure if this is the only way but you can bypass the fix (which limited ProcessDeviceMap in a sandbox) by instead abusing shadow object directories. NtCreateObjectDirectoryEx takes an additional parameter of a handle to a shadow directory which works similar to the ?? -> GLOBAL?? fallback. If you can create a named object directory (so normal low IL or EPM sandboxes) you can create a dummy directory which shadows GLOBAL??. You can then construct the dos device path using something similar to my last poc by overriding the lookup for C: or GLOBALROOT by dropping an object directory or symlink. If you set the reparse point it will be redirected to an arbitrary location which you control. You can now release the inner object directory or symlink which means the shadow directory version of the name will be found meaning the higher privileged application will pick up the real target.
For example while setting reparse point you can get:
\BaseNamedObjects\Dummy\C:\windows -> \Device\NamedPipe\
if you now release the C: object directory you get:
\BaseNamedObjects\Dummy\C:\Windows -> \GLOBAL??\C:\Windows
This does have a few limitation from the previous attack:
1. You must be able to create a named object directory, but that's most places outside of a Chrome renderer.
2. The reparse point only works as long as the object directory exists, so probably the lifetime of the attacking process but that's probably okay for a typical privilege escalation.
Proof of Concept:
I’ve provided a PoC which will demonstrate the bypass. It should be executed at low integrity using psexec or modifying the executable file’s ACL to low. You can compare the operation to the command shell’s mklink tool that will fail to create the mount point at low integrity. The archive password is ‘password’. Follow these steps:
1) Extract the PoC to a location on a local hard disk which is writable by a normal user.
2) Execute the poc executable file as low integrity passing two arguments, the path to a directory to create (must be somewhere than can be written to as low integrity user such as AppData\Temp\Low) and the arbitrary file path to set the mount point to. For example:
poc.exe c:\users\user\appdata\local\low\abc c:\notreal
3) While the PoC is running you can now list the directory and get access to its contents.
Expected Result:
It shouldn’t be possible to create a mount point pointed at a location not writable by low integrity user
Observed Result:
The mount point is created successfully.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39311.zip
Exploit Database EDB-ID : 39310
Date de publication : 2016-01-24 23:00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes
Source: https://code.google.com/p/google-security-research/issues/detail?id=589
Windows: Sandboxed Mount Reparse Point Creation Mitigation Bypass Redux 2
Platform: Windows 8.1, not tested any other OS
Class: Security Feature Bypass
Summary:
The fix for CVE-2015-2553 can be bypassed to get limited mount reparse points working again for sandbox attacks by abusing anonymous token impersonation.
Description:
This is another way of bypassing fix introduced in CVE-2015-2553 to block access to creating mount point reparse points. In this case instead of using the per-process device map directory we can use the fact that the anonymous token can support a per-user device map directory. If this doesn’t exist (which seems to be rare it gets created) the kernel uses ZwCreateDirectoryObject inside SeGetTokenDeviceMap.
So instead of creating an anonymous directory object and setting it as the per-process device map we do everything while impersonating the anonymous token and open \?? as the root directory. We can then use the same trick as in the original PoC to set the mount point by pointing it at \Device\NamedPipe. This works because traversal is not blocked due to you not fixing MSRC case 21132.
I guess this could be fixed by passing the OBJ_IGNORE_IMPERSONATED_DEVICEMAP flag when checking for the writable directory, but of course that might go horribly wrong somewhere. Or perhaps the anonymous authentication ID shouldn’t create a per-user device map?
This does have a limitation from the previous attack as it doesn’t work if the process has a restricted token as NtImpersonateAnonymousToken returns STATUS_ACCESS_DENIED although I believe it would work from AppContainer assuming the device map hadn’t already been created (otherwise not sure the DACL would allow access).
Proof of Concept:
I’ve provided a PoC which will demonstrate the bypass. It should be executed at low integrity using psexec or modifying the executable file’s ACL to low. You can compare the operation to the command shell’s mklink tool that will fail to create the mount point at low integrity. The archive password is ‘password’. Follow these steps:
1) Extract the PoC to a location on a local hard disk which is writable by a normal user.
2) Execute the poc executable file as low integrity passing two arguments, the path to a directory to create (must be somewhere than can be written to as low integrity user such as AppData\Temp\Low) and the arbitrary file path to set the mount point to. For example:
poc.exe c:\users\user\appdata\local\low\abc c:\notreal
3) While the PoC is running you can now list the directory and get access to its contents.
Expected Result:
It shouldn’t be possible to create a mount point pointed at a location not writable by low integrity user
Observed Result:
The mount point is created successfully.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39310.zip
Exploit Database EDB-ID : 38474
Date de publication : 2015-10-14 22:00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes
Source: https://code.google.com/p/google-security-research/issues/detail?id=486
Windows: Sandboxed Mount Reparse Point Creation Mitigation Bypass
Platform: Windows 10 (build 10240), earlier versions do not have the functionality
Class: Security Feature Bypass
Summary:
A mitigation added to Windows 10 to prevent NTFS Mount Reparse Points being created at integrity levels below medium can be bypassed.
Description:
Windows 10 has added some new mitigations to block the creation or change the behaviour of certain symbolic links when issued by a low integrity/sandboxed process. The presumed aim to to make it harder to abuse these types of tricks to break out of a sandbox.
In earlier builds on Windows 10 NTFS Mount Reparse Points were blocked outright from a sandboxed process, however in 10240 (what can only be assumed a final build) the check was moved to the kernel in IopXXXControlFile and changed slightly so that sandboxed processes could create some mount points. The check is roughly:
if (RtlIsSandboxedProcess()) {
if(ControlCode == FSCTL_SET_MOUNT_POINT) {
if (FsRtlValidateReparsePointBuffer(buffer) && buffer->ReparseTag == TAG_MOUNT_POINT) {
NTSTATUS status = ZwOpenFile(..., buffer->ReparseTarget, FILE_GENERIC_WRITE, ... , FILE_DIRECTORY_FILE);
if (!NT_SUCCESS(status)) {
return status;
}
}
}
The kernel is therefore checking that the target of the mount point is a directory and that the current process has write access to the directory. This would sufficiently limit the ability of a sandboxed process to abuse this to write files at a higher privilege. Unfortunately there’s a perhaps unexpected problem with this check, the sandboxed process can redirect the ZwOpenFile call arbitrarily to something it can open for write, yet the original value is set as the mount point. This is because the file open check is being made inside the process which is doing the call which means it honours the user’s device mapping.
While the sandboxed process cannot change the per-user drive mappings, it can change the process’s device map using NtSetInformationProcess with the ProcessDeviceMap information class. As we can create arbitrary object directories and symbolic links (which while they also have a mitigation it only prevents a higher privilege process following them, which we don’t care about) we can build a completely fake device map which redirects the open to another directory. A good target turns out to be \Device\NamedPipe\ (note the trailing slash) as that can be opened from any privilege level (including Chrome renderer processes) for write access and as a directory. So if we want to set an arbitrary mount point to say \??\c:\somewhere we can build something like:
<UNNAMED>(DIR) -> C:(DIR) -> somewhere(LINK to \Device\NamedPipe\)
If we set the unnamed directory to the process device map we can bypass the check and create the mount point.
Perhaps from a fix perspective you could query for the opened path and use that to write to the NTFS reparse point rather than using the original value.
Proof of Concept:
I’ve provided a PoC which will demonstrate the bypass. It should be executed at low integrity using psexec or modifying the executable file’s ACL to low. Ensure you use the correct version for the architecture on Windows, as there seems to be a bug in NtSetInformationProcess which blocks Wow64 apps from setting the process device map. You can compare the operation to the command shell’s mklink tool that will fail to create the mount point at low integrity. The archive password is ‘password’. Follow these steps:
1) Extract the PoC to a location on a local hard disk which is writable by a normal user.
2) Execute the poc executable file as low integrity passing two arguments, the path to a directory to create (must be somewhere than can be written to as low integrity user such as AppData\Temp\Low) and the arbitrary file path to set the mount point to. For example:
poc.exe c:\users\user\appdata\local\low\abc c:\notreal.
Expected Result:
It shouldn’t be possible to create a mount point pointed at a location not writable by low integrity user
Observed Result:
The mount point is created successfully.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38474.zip
Products Mentioned
Configuraton 0
Microsoft>>Windows_10 >> Version -
Microsoft>>Windows_7 >> Version -
Microsoft>>Windows_8 >> Version -
Microsoft>>Windows_8.1 >> Version -
Microsoft>>Windows_rt >> Version -
Microsoft>>Windows_rt_8.1 >> Version -
Microsoft>>Windows_server_2008 >> Version -
Microsoft>>Windows_server_2008 >> Version r2
Microsoft>>Windows_server_2008 >> Version r2
Microsoft>>Windows_server_2012 >> Version -
Microsoft>>Windows_server_2012 >> Version r2
Microsoft>>Windows_vista >> Version -
References