warxim/vucsaAplicación cliente-servidor deliberadamente vulnerable para aprender pruebas de penetración de clientes pesados no HTTP. Incluye desafíos de inyección SQL, RCE, ataques XML, sobrelectura de búfer y vulnerabilidades de control de acceso.
La aplicación cliente-servidor vulnerable (VuCSA) está diseñada para aprender/presentar cómo realizar pruebas de penetración en aplicaciones cliente-servidor que no son HTTP. Está escrita en Java (con interfaz gráfica JavaFX).
Actualmente, la aplicación vulnerable contiene los siguientes desafíos:
Si deseas saber cómo resolver estos desafíos, consulta el sitio web de PETEP, que describe cómo usar la herramienta de código abierto PETEP para explotarlos.
Consejo 1: Antes de comenzar a hackear, no olvides revisar la estructura de datos de los mensajes a continuación. Al modificar el tráfico de red, probablemente tendrás que considerar la estructura, especialmente los bytes de longitud del payload.
Consejo 2: La mayoría de los desafíos se pueden explotar mediante la modificación del tráfico de red. Por lo tanto, se recomienda usar un proxy TCP o enganches de procesos para las pruebas.
Consejo 3: Algunos desafíos tienen validación de entrada y restricciones, algo común en clientes pesados, pero eso no significa que el servidor utilice la misma validación.
En este desafío, tu objetivo es manipular el tráfico de red entre el cliente y el servidor de manera que conduzca a una sobrelectura de búfer.
El desafío de ejecución de comandos representa una vulnerabilidad muy simple de ejecución de comandos. El objetivo es ejecutar un comando malicioso en el servidor.
El desafío de inyección SQL contiene una entrada de búsqueda vulnerable a inyección SQL, pero como pronto notarás, la entrada no te permite ingresar los caracteres que necesitas.
El desafío de enumeración se basa en un formulario de inicio de sesión simulado que no está protegido contra enumeración. ¿Podrás encontrar los 5 usuarios y adivinar sus contraseñas?
En este desafío, puedes encontrar múltiples vulnerabilidades XML:
El desafío de control de acceso horizontal representa un lector de documentos que permite al usuario ver sus propios documentos y leer su contenido. El objetivo es encontrar 5 documentos de otros usuarios.
El desafío de control de acceso vertical se basa en un panel de usuario simulado, que muestra información básica del usuario. El objetivo es encontrar una funcionalidad de administrador oculta y comprobar si es posible usarla como usuario Invitado.
La vulnerabilidad de deserialización RCE utiliza serialización/deserialización de Java para transmitir datos a través de la red. La aplicación contiene dos rutas que puedes usar para lograr la ejecución remota de código mediante la vulnerable deserialización de Java.
Puedes encontrar ambas rutas examinando el archivo JAR del servidor o mirando el código fuente.
El objetivo es crear exploits para ambas rutas y ejecutar un comando malicioso en el servidor.
Consejo: Puedes usar el JAR del servidor como biblioteca para facilitar la creación del exploit.
Necesitas Java 11 o una versión más reciente para ejecutar VuCSA.
Nota: Para Mac con arquitectura ARM64 (chips M1, M2), usa la compilación especial para Java 17.
Para ejecutar el servidor y el cliente vulnerables, puedes usar uno de los lanzamientos en GitHub o ejecutar gradle assemble, que crea paquetes de distribución (tanto para Windows como para Unix). Estos paquetes contienen scripts sh/bat que ejecutarán el servidor y el cliente usando JVM:
# Linux / Mac
chmod +x client.sh server.sh
./client.sh
./server.sh
# Windows
client.bat
server.bat
Nota: Estos scripts de ejecución contienen variables útiles, incluida la ruta al ejecutable de Java. Es posible que debas cambiarla si no la tienes en PATH o si usas varias versiones de Java.
La configuración del servidor se crea automáticamente si no existe
y luego se carga desde server.json en el mismo directorio donde se ejecuta el servidor:
{
"network": {
"serverHost": "0.0.0.0",
"serverPort": 8765
}
}
La configuración del cliente se puede especificar en la aplicación en ejecución.
El proyecto se divide en tres módulos:
Los mensajes transmitidos entre el servidor y el cliente tienen el siguiente formato simple:
[tipo][destino][longitud][payload]
32b 32b 32b ???
Estas cuatro partes tienen el siguiente significado:
Para enviar payloads personalizados, es posible que debas actualizar la longitud del payload. De lo contrario, no funcionará correctamente. En el tutorial, se desarrolla un script automático para corregir los bytes de longitud del payload.
La aplicación cliente-servidor vulnerable (VuCSA) contiene múltiples vulnerabilidades, que pueden explotarse de varias maneras. La guía oficial para explotar estas vulnerabilidades utiliza el Proxy de Pruebas de Penetración de código abierto (consulta Metodología PETEP).
En la metodología PETEP, se explica todo el proceso de explotación de los desafíos, incluyendo payloads útiles.