CVE-2018-8212: DISPOSITIVO GUARD / CLM BYPASS UTILIZANDO

Device Guard y los entornos de scripts iluminados que vienen con él son una combinación letal para interrumpir la actividad del atacante. Device Guard evitará que se ejecute código no aprobado al colocar lenguajes de scripting como PowerShell y Windows Scripting Host en un estado bloqueado. Para operar en un entorno de este tipo, la investigación de los bypass puede ser muy útil. Además, hay ventajas de evasión que pueden venir con la ejecución de código no firmado a través de scripts o programas firmados / aprobados.

Cuando la búsqueda del modo de lenguaje restringido (CLM) se desvía en el contexto de Device Guard, investigar los módulos de PowerShell firmados por Microsoft para detectar llamadas que permitan la ejecución de código arbitrario y sin firma siempre es un esfuerzo fructífero, ya que la mayoría de los módulos de Microsoft PowerShell estarán firmados (es decir, implícitamente aprobado por la política). Para combatir el abuso de los módulos PowerShell firmados para evitar CLM, Microsoft agregó una verificación para asegurarse de que un módulo solo pueda ejecutar las funciones exportadas si el módulo está cargado en CLM ( CVE-2017-8715 ). Esto significa que, aunque un script puede estar firmado y permitido según una política, ese script solo puede ejecutar funciones que se exportan explícitamente a través de Export-ModuleMember. Esta adición reduce significativamente la superficie de ataque para los módulos PowerShell firmados, ya que las funciones no exportadas estarán sujetas a CLM, al igual que el código sin firmar.

Si bien esta adición reduce la superficie de ataque, no la elimina por completo. Al analizar los archivos del módulo PowerShell con firma de Microsoft para las funciones que permitieron la ejecución de código sin firmar, "MSFT_ScriptResource.psm1" del módulo de configuración de estado deseado (DSC) surgió. Este módulo está firmado por Microsoft y tiene una función llamada "Get-TargetResource" que toma un parámetro "GetScript":

Al observar esta función, el código pasado a través de -GetScript se agrega a un nuevo bloque de secuencias de comandos a través de [ScriptBlock] :: Create (). Después de hacerlo, pasa los parámetros psbound a la función "ScriptExecutionHelper".

Si echamos un vistazo a "ScriptExecutionHelper", todo lo que hace es tomar los parámetros psbound (que incluyen nuestro ScriptBlock recién creado) y ejecutarlo a través del operador de llamada (&):

Dado que todo esto sucede dentro de un módulo firmado por Microsoft, se permite que el módulo se ejecute en modo FullLanguage (es decir, sin ninguna restricción impuesta). Para abusar de esto, todo lo que tenemos que hacer es pasar nuestro código malicioso de PowerShell a Get-TargetResource a través del parámetro -GetScript. Pero, ¿no se supone que la mitigación Export-ModuleMember de CVE-2017-8715 previene el abuso de funciones? Mirando las funciones exportadas en "MSFT_ScriptResource.psm1", la función de abuso "Get-TargetResource" se exporta realmente para nosotros:

¡Excelente! Para probar esto, podemos agregar un código C # arbitrario (que simplemente toma la raíz cuadrada de 4) a una variable de PowerShell llamada código $:

Después de hacerlo, solo debemos importar el módulo PowerShell "MSFT_ScriptResource" y llamar a "Get-TargetResource" con "Add-Type -TypeDefinition $ code" como el parámetro -GetScript. Cuando esto se ejecute, el módulo PowerShell firmado de Microsoft se cargará en el modo FullLanguage (ya que está firmado y permitido a través de la política de Device Guard), y el código que se pasa a la función Get-TargetResource también se ejecutará en el modo FullLanguage:

Como puede ver arriba, estamos ejecutando en el modo de lenguaje restringido y obtenemos la raíz cuadrada de 4 fallidos, ya que esas llamadas de método están bloqueadas. Luego agregamos nuestro código "malicioso" a la variable $ code. Todo lo que hace este código es tomar el SquareRoot de 4, como intentamos hacer anteriormente. Una vez hecho esto, el módulo "MSFT_ScriptResource" se importa y nuestro código "malicioso" se pasa a "Get-TargetResource" a través del parámetro -GetScript. Cuando esto se ejecuta, se ejecuta la llamada Add-Type y se ejecuta nuestro código "malicioso", lo que evita el CLM en Device Guard. Se debe tener en cuenta que habilitar el registro de ScriptBlock aún capturará el intento de omisión de CLM.

Este error fue corregido a través de CVE-2018-8212 . Si está interesado, Microsoft recientemente agregó omisiones como esta al programa de recompensas de la Seguridad de la Aplicación WDAC: https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria

Aclamaciones,

Matt N.