The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
None
C
There is no impact on the confidentiality of the system; the attacker does not gain the ability to read any data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
None
A
There is no impact on the availability of the system; the attacker does not have the ability to disrupt access to or use of the system.
Below is a copy: Microsoft Windows CiSetFileCache TOCTOU Incomplete Fix
Windows: CiSetFileCache TOCTOU CVE-2017-11830 Incomplete Fix
Platform: Windows 10 1709 (including Win10S)
Class: Security Feature Bypass
Summary:
The fix for CVE-2017-11830 is insufficient to prevent a normal user application adding a cached signing level to an unsigned file by exploiting a TOCTOU in CI leading to circumventing Device Guard policies.
Description:
The previous issue I reported was due to not checking for write access on the target file handle when setting the cache. This allows a user application to abuse a TOCTOU and rewrite the file after the hash has been generated for the file. The only changed code seems to be below:
FILE_OBJECT target_file;
ObReferenceObjectByHandle(FileHandle, 0, *IoFileObjectType, &target_file);
if (target_file->SharedWrite) {
return STATUS_SHARING_VIOLATION;
}
if (target_file->WriteAccess) { Additional check for the file being opened for write.
if ((PsGetProcessProtection(PsGetCurrentProcess()) & 7) != ProtectedProcessLight)
return STATUS_SHARING_VIOLATION;
}
The fix was to add a check that the target file passed isnt writable. This combined with the check for FILE_SHARE_WRITE should mean the user cant hold on to a writable file handle. However, when the file handle is converted to a file object with ObReferenceObjectByHandle the desired access is 0, which means we can pass a handle with any granted access including SYNCHRONIZE or READ_CONTROL, which do not respect file sharing. So we can still exploit this issue by doing the following:
1. Open the file for write access.
2. Reopen another handle to the file for SYNCHRONIZE access. This works as this access right can be used regardless of the sharing mode.
3. Set cached signing level through the handle opened in 2.
4. Wait for oplock, rewrite file using handle opened in 1. Release oplock.
Proof of Concept:
Ive provided a PoC as a C# project. It will allow you to cache sign an arbitrary executable. If you want to test this on a locked down system such as Win10S youll need to sign the PoC (and the NtApitDotNet.dll assembly) so itll run. Or use it via one of my .NET based DG bypasses, in that case you can call the PoC_CacheSignature.Exploit.Run method directly. It copies notepad to a file, attempts to verify it but uses an oplock to rewrite the contents of the file with the untrusted file before it can set the kernel EA.
1) Compile the C# project. It will need to grab the NtApiDotNet v1.1.7 package from NuGet to work.
2) Execute the PoC passing the path to an unsigned file and to the output cache signed file, e.g. poc unsigned.exe output.exe
3) You should see it print the signing level, if successful.
4) You should not be able to execute the unsigned file, bypassing the security policy enforcement.
NOTE: If it prints an exception then the exploit failed. The opened catalog files seemed to be cached for some unknown period of time after use so if the catalog file Im using for a timing signal is already open then the oplock is never broken. Just rerun the poc which will pick a different catalog file to use. Also the output file must be on to a NTFS volume with the USN Change Journal enabled as thats relied upon by the signature level cache code. Best to do it to the boot drive as that ensures everything should work correctly.
Expected Result:
Access denied or at least an error setting the cached signing level.
Observed Result:
The signing level cache is applied to the file with no further verification. You can now execute the file as if it was signed.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44466.zip
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum