Publican un 0-day que permite escalar privilegios en Windows debido a un bug en el programador de tareas (ALPC)

Hace un par de días @SandboxEscaper liberó en Twitter una vulnerabilidad de día 0 muy a tener en cuenta para escalar privilegios en Windows, junto con una PoC del exploit que funciona perfectamente en un Windows 10 de 64 bits con los últimos parches....

El servicio del programador de tareas tiene un endpoint ALPC (Advanced Local Procedure Call) que admite el método "SchRpcSetSecurity".

El prototipo se ve así:

    long _SchRpcSetSecurity(
        [in][string] wchar_t* arg_1, //nombre de la tarea
        [in][string] wchar_t* arg_2, //string del descriptor de seguridad
        [in]long arg_3);

Las tareas añadidas mediante el programador crean la carpeta/archivo correspondiente en c:\windows\system32\tasks. Esta función parece estar diseñada para escribir la DACL de las tareas ubicadas ahí y lo hace impersonalizándose. Sin embargo, por alguna razón, también comprueba si existe un archivo .job en c:\windows\tasks e intenta establecer la DACL, pero esta vez sin impersonación. Con cualquier usuario, incluso un usuario que pertenece al grupo de invitados, se pueden crear archivos en esta carpeta, simplemente podemos crear un hardlink a otro archivo (todo lo que necesitamos es acceso de lectura). Debido al enlace podemos permitir que el programador de tareas escriba una DACL arbitraria (ver el segundo parámetro de SchRpcSetSecurity) en un archivo de nuestra elección.

Por lo tanto, podemos aprovechar cualquier archivo al que tengamos acceso de lectura como usuario y que tenga permiso de escritura de DACL para SYSTEM, para sobrescribirlo y tomar control total de la máquina.

Explotación

El problema principal es que en una instalación por defecto, muchos archivos críticos solo pueden ser modificados por un instalador confiable (ni siquiera por system).

Mediante el siguiente script en PowerShell se pueden enumerar archivos sobre los que puede tomar el control. Simplemente ejecuta ./enumerate.ps1> output.txt

$aapsid = 'NT AUTHORITY\SYSTEM'

ForEach($file in (Get-ChildItem -recurse -Path 'C:\windows')) {
 
   $acl = Get-Acl -path $file.PSPath
   ForEach($ace in $acl.Access) {
      If(($ace.FileSystemRights -eq
           [Security.AccessControl.FileSystemRights]::FullControl) -and 
            $ace.IdentityReference.Value -in $aapsid) {
               Write-Output $file.PSPath
              
      }
        
   }
   
   }

Hay muchos posibles objetivos (además, se puede tomar el control de cosas en archivos del programa, y ​​si el objetivo lo comparten los administradores u otros usuarios, es posible que terminen ejecutando programas que puedes sobrescribir).

El segundo problema es que, si bien podemos tomar el control de todos estos archivos, la escritura a menudo está bloqueada ya que muchos archivos DLL ya están cargados en algún sitio, por lo tanto, se activará una infracción de uso compartido.

Pero puede haber tipos de archivos además de .dll que serían un mejor objetivo.

C:\Windows\System32\DriverStore\FileRepository\prnms003.inf_amd64_4592475aca2acf83\Amd64\printconfig.dll (El nombre de la carpeta puede variar)

Este fue uno de los dlls que se obtuvieron. Parece estar relacionado con la impresora xps, y no está cargado en el servicio de cola de impresión de forma predeterminada (podría suceder que ya esté cargado ... pero a menudo no es así).

Entonces, si comenzamos un trabajo de impresión usando la impresora xps, cargará este archivo DLL, que podemos sobrescribir aprovechando esta vulnerabilidad.

Payloads y consideraciones adicionales

El payload (que se utiliza para sobrescribir la dll/archivo de destino) se adjunta como un recurso en el proyecto de Visual Studio, se puede cambiar directamente en el código o cambiar exploit.dll en la carpeta resource.

También en el código estará la siguiente línea:

    HMODULE mod = GetModuleHandle(L"ALPC-TaskSched-LPE");

Esto tiene que reflejar el nombre de la dll final, o el PoC no funcionará, ya que no sabrá dónde buscar el recurso del payload.

Si el PoC no funciona, hay que verificar spoolsv.exe en el explorador de procesos y asegurarse de que printconfig.dll no está cargado. No debería suceder a menudo ... pero podría ser por cualquier razón...

Demo

De momento funciona en 64 bits, todavía necesita algo de trabajo adicional para soportar x86 ya que el payload es x64 y es necesario sobrescribir también la versión x86 de printconfig.dll.

Descarga: https://github.com/SandboxEscaper/randomrepo/blob/master/PoC-LPE.rar