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:

Technique	Mitre	Administrator Rights
Winlogon Helper DLL	T1004	Yes
Port Monitors	T1013	Yes
Accessibility Features	T1015	Yes
Shortcut Modification	T1023	No
Modify Existing Service	T1031	Yes
DLL Search Order Hijacking	T1038	Yes
Change Default File Association	T1042	No
New Service	T1050	Yes
Scheduled Tasks	T1053	No
Service Registry Permission Weakness	T1058	No
Registry Run Keys	T1060	No
WMI Event Subscription	T1084	Yes
Security Support Provider	T1101	Yes
AppInit DLLs	T1103	Yes
Component Object Model Hijacking	T1122	No
Netsh Helper DLL	T1128	Yes
Office Application Startup	T1137	No
Application Shimming	T1138	Yes
Screensaver	T1180	No
Image File Execution Options Injection	T1183	Yes
BITS Jobs	T1197	No
Time Providers	T1209	Yes
PowerShell Profile	T1504	No
Waitfor	N/A	Yes
RID Hijacking	N/A	Yes

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);