Nueva investigación: descubrimos cómo eludir SmartScreen a través de un COM Hijacking y sin privilegios

martes, 2 de abril de 2019

La técnica de COM Hijacking tiene una base teórica muy simple, similar a la de DLL Hijacking: ¿Qué ocurre cuando una aplicación busca un objeto COM inexistente en el equipo donde se está ejecutando? ¿O cuando el objeto existe pero no se encuentra en la clave de registro donde se buscó? Un atacante podría crearlo él mismo con información adulterada, por ejemplo, una ruta que en vez de llevar a la DLL buscada, conduzca a la víctima a una creada por un atacante. Se puede aprovechar el orden en el que, por defecto, el programa intentará buscar este objeto. De esta forma, hemos conseguido eludir SmartScreen en Windows.

Pequeña introducción
COM (Component Object Model) es un modelo de interfaz binaria para componentes de software que permite comunicación entre procesos y creación dinámica de objetos independientemente del lenguaje en la que éstos fueron programados. COM ofrece una ABI (Application Binary Interface) estable que no cambia con las diferentes versiones de los compiladores. Esto resulta muy atractivo para desarrolladores de C++ si el código debe ser compartido con clientes que usan diferentes versiones de compiladores.

Comúnmente los objetos COM son compilados como una DLL, pero la manera de utilizarlos es especial. Los objetos COM deben ser identificables de forma unívoca en el momento de ejecución y para esto, se utiliza una identificación conocida como GUID, por ejemplo:

{CB4445AC-D88E-4846-A5F3-05DD7F220288}

Cada objeto COM está registrado con su correspondiente GUID, acompañado por una o más claves que proporcionan información sobre el objeto en sí, tal como la ruta real de su DLL específica. Habitualmente los objetos COM son registrados bajo las siguientes rutas del registro: HKLM\SOFTWARE\Classes\CLSID o HKLU\SOFTWARE\Classes\CLSID. Allí, bajo la clave GUID correspondiente, se suelen utilizar las claves de registro InprocServer, InprocServer32, InprocHandler e InprocHandler32 para proporcionar las rutas a la DLL del objeto. Si el objeto COM se encuentra bajo la raíz HKEY_LOCAL_MACHINE (HLKM), significa que está disponible para todos los usuarios del equipo y que se ha creado con permisos de administrador del sistema. Mientras que los creados bajo raíz HKEY_CURRENT_USER (HCKU) son válidos para el usuario actualmente autenticado y no necesariamente creados por un administrador.

El orden de búsqueda del sistema es interesante. Un escenario típico es acudir primero a la rama del usuario y luego a la rama del equipo donde se ejecuta. Pensemos en una aplicación que, al iniciarse, necesita utilizar las funciones del objeto COM ubicado en la siguiente clave de registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CB4445AC-D88E-4846-A5F3-05DD7F220288}\InprocServer32

 Sin embargo, antes de buscarlo allí, la aplicación busca primero en la siguiente ruta:

HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{CB4445AC-D88E-4846-A5F3-05DD7F220288}\InprocServer32

Suponiendo que esta última clave no existiese, estaremos frente a una aplicación vulnerable a COM Hijacking. Llevar a cabo la técnica no implica más que crear la siguiente estructura en el registro:

HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID
{CB4445AC-D88E-4846-A5F3-05DD7F220288}
InprocServer32
(Default) = C:\DLLsMaliciosas\miDLL.dll

COM Hijacking como persistencia
La técnica de COM Hijacking para lograr persistir presenta varias ventajas frente al resto de técnicas tradicionales para anclarse en el inicio. Lo mejor es contar con un objeto COM nativo, invocado cada vez que se inicia el sistema. El principal problema de esto es que los objetos COM nativos suelen encontrase en HKCR (classes root) en vez de en el registro propio del usuario, por lo que un usuario por sí mismo no debería poder acceder.

Lo cierto es que HKCR es en realidad una vista virtual de lo que vemos tanto en HKCU como en HKLM. Lo que significa que si se desea escribir una clave en

HKCR\CLSID\{A47979D2-C419-11D9-A5B4-001185AD2B89} 

se podría llegar a conseguir creándola en

HKCU\Software\Classes\CLSID\{A47979D2-C419-11D9-A5B4-001185AD2B89}

Por tanto, para realizar el hijack al objeto COM nativo en Windows, se podría crear la clave  tal como se observa en la siguiente imagen y cómo inmediatamente se propaga.

Registry Editor Windows imagen
 Registry Editor Windows 2 imagen

Debido a que se trabaja sobre HKEY_CURRENT_USER (HKCU), no se necesitan permisos de administrador para realizar el ataque. Una vez creada la clave del registro, el código contenido en la DLL introducida se ejecutará cada vez que la aplicación vulnerable halle al objeto COM secuestrado y cargue la DLL maliciosa.

Elevar privilegios a través de Event Viewer y Task Scheduler
Para elevar privilegios a través de una técnica como la de COM Hijacking, se debe aprovechar una aplicación vulnerable que se ejecute con privilegios elevados y con integridad del proceso alta. Las aplicaciones Event Viewer y Task Scheduler invocan un proceso elevado y de integridad alta llamado mmc.exe. Se utiliza por varias aplicaciones de Windows para la administración. Las funcionalidades mencionadas buscan objetos COM en la siguiente ruta:

HKCU\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32

¿Qué ocurriría si se realizara un COM hijack a ese objeto? La siguiente línea consigue un hijack:

powershell.exe -Command {$Path="HKCU:\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32";$Name="(Default)";$Value="C:\\MisDLLs\epp1.dll";New-Item -Path $Path -Force;New-ItemProperty -Path $Path -Name $Name -Value $Value}

Una vez invocado el proceso vulnerable este encontrará el objeto COM (en principio no adjudicado) y ejecutará la DLL maliciosa, que en este caso es una shell de meterpreter ubicada en "C:\MisDLLs\epp1.dll"

Debido a que el proceso vulnerable se ejecuta elevado y posee integridad alta, la shell proporcionada podrá disponer de privilegios de SYSTEM sin inconvenientes. Una técnica similar se ha usado para eludir UAC.

Pasando desapercibido: SmartScreen es vulnerable a COM Hijacking
Hace un tiempo descubrimos, cómo atacantes conseguían eludir SmartScreen aprovechando técnicas de DLL Hijacking. Esta aproximación consigue efectos similares, pero de diferente forma, cada vez que se ejecuta un programa en Windows, SmartScreen se ejecuta para intentar protegernos. Sin importar qué programa es, cada ejecución pasa por SmartScreen, que consulta en la nube si el programa podría llegar a suponer un riesgo para el sistema.

Windows protected your PC imagen

Pero SmartScreen es vulnerable a COM Hijacking, cada vez que un binario se ejecuta, se ejecuta  también SmartScreen, y cada vez que se ejecuta SmartScreen se buscan varios objetos COM en el registro sin éxito. Entre ellos:

HKCU\Software\Classes\CLSID\{A463FCB9-6B1C-4E0D-A80B-A2CA7999E25D}\InprocServer32.

A través de una DLL, se puede realizar un hijack a este objeto ejecutando en la consola de Powershell el siguiente comando:

Powershell imagen

Tras la ejecución del script anterior, cualquier programa que ejecute el usuario hará que se ejecute SmartScreen y a su vez será ese mismo proceso quien se ocupará de cargar y ejecutar la DLL maliciosa, devolviendo en este caso una shell de meterpreter. En la prueba de concepto, usamos simplemente una DLL que mostraba un Hola Mundo, dejando morir al proceso que se supone debería protegernos.
 
Windows Defender SmartScreen has stopped working imagen

Aunque también se puede simplemente, utilizarlo para anularlo y persistir.



Hemos alertado a Microsoft sobre esta potencial vulnerabilidad que permitiría persistencia y eludir una función de seguridad pero ha declarado que esta comportamiento es por diseño.

Todo el estudio completo en:



Innovación y laboratorio en ElevenPaths

No hay comentarios:

Publicar un comentario