Spain DockerLabs (Hard)
Instalación
Cuando obtenemos el .zip nos lo pasamos al entorno en el que vamos a empezar a hackear la maquina y haremos lo siguiente.
unzip spain.zipNos lo descomprimira y despues montamos la maquina de la siguiente forma.
bash auto_deploy.sh spain.tarInfo:
## .
## ## ## ==
## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\______/
___ ____ ____ _ _ ____ ____ _ ____ ___ ____
| \ | | | |_/ |___ |__/ | |__| |__] [__
|__/ |__| |___ | \_ |___ | \ |___ | | |__] ___]
Estamos desplegando la máquina vulnerable, espere un momento.
Máquina desplegada, su dirección IP es --> 172.17.0.2
Presiona Ctrl+C cuando termines con la máquina para eliminarlaPor lo que cuando terminemos de hackearla, le damos a Ctrl+C y nos eliminara la maquina para que no se queden archivos basura.
Escaneo de puertos
Info:
Si entramos en el puerto 80 para ver la pagina web, vemos que no nos va a cargar, ya que se esta intentando conectar a un dominio en especifico llamado spainmerides.dl, por lo que lo añadiremos en el hosts:
Lo guardamos y volveremos a cargar la pagina.
Vemos una pagina normal y corriente, nada fuera de lo normal, por lo que vamos a fuzzear un poco.
Gobuster
Info:
Vemos que nos descubre una pagina llamada manager.php, si entramos dentro vemos que nos pone un archivo para descargarnos llamado bitlock, por lo que nos lo descargaremos y probaremos a ejecutarlo a ver que nos muestra.
Info:
Por lo que vemos nos pone que esta esperando alguna conexion en el puerto 9000 por lo que vamos a probar hacer lo siguiente:
Estando dentro de la conexion probaremos a enviar un texto:
Y en el binario donde estaba la escucha veremos lo siguiente cuando lo enviemos:
Por lo que vemos se ha enviado correctamente y le ha llegado al binario, a parte de que vemos que desbordamos la memoria del buffer por lo que podremos hacer un buffer Overflow.
Ingenieria inversa (bitlock)
Instalacion de GDB con PEDA/GDB con pwndbg
Lo que primero tendremos que hacer sera lo siguiente:
Y si iniciamos el programa con GDB pasandole como parametro el programa, se nos pondra el gdb-peda...
Pero si diera error por las versiones, podremos instalar esta otra herramienta que es mas poderosa:
Y si iniciamos gdb veremos lo siguiente:
Info:
Comprobacion de desbordamiento de Buffer
En el host, generamos una cadena de caracteres diseñada para intentar desbordar el buffer de la aplicación. Esto se logra con la herramienta pattern_create.rb:
Info:
Este patrón se usará como entrada en la aplicación para identificar cómo se maneja el buffer.
Conectamos al servicio vulnerable usando netcat:
Host:
Introducimos los 400 caracteres generados previamente. Para automatizar este paso, creamos un script en Python:
step1.py
Este script automatiza la conexión y el envío del patrón:
Antes de ejecutar el script, inicia la aplicación en GDB (preferentemente con pwndbg):
gdb (pwndbg)
Ahora en el host ejecutamos:
Resultado esperado en GDB: La aplicación debería mostrar un error de segmentación (SIGSEGV), indicando que el buffer fue desbordado. Observa el valor de EIP en los registros, que reflejará parte del patrón enviado.
Y en el GDB veremos algo asi:
Veremos que hemos conseguido pasarnos del buffer y nos muestra la direccion de memoria que nos importa llamado EIP que seria 0x61413761.
Identificación del Offset
Para determinar el desplazamiento exacto (offset) donde ocurre la sobrescritura, usamos pattern_offset.rb, proporcionando la dirección en hexadecimal obtenida en EIP:
Host
Info:
Esto indica que el offset es de 22 bytes, por lo que haremos lo siguiente, para automatizar todo este proceso:
step2.py
Creamos un nuevo script que utiliza el offset para sobrescribir el registro EIP con un valor controlado (BBBB):
Antes, tendremos que hacer lo siguiente en GDB para iniciar la aplicacion:
gdb (pwndbg)
Y ahora en el host ejecutaremos el script:
host
Resultado esperado en GDB: El registro EIP ahora debería estar sobrescrito con 0x42424242 (BBBB).
Por lo que veremos lo siguiente en el GDB:
Vemos que funciona y sobrescribe con B el EIP por lo que ahora tendremos que injectar un shellcode para que se nos haga una reverse shell al servidor aprovechando esta vulnerabilidad.
Verificación del Espacio Después del EIP
Queremos comprobar qué ocurre con los datos introducidos después del EIP. Para ello, añadimos datos adicionales (CCCC) al final del payload creando una variable after_eip y automatizaremos todo esto con un script:
step3.py
Ahora en el GDB tendremos que poner de nuevo run para ejecutar la aplicacion:
gdb (pwndbg)
Y en el host ejecutamos el script:
host
En el GDB tendremos que ver algo asi:
Resultado esperado: En GDB, verifica la pila (stack) para comprobar que los CCCC aparecen después del EIP. Usa este comando (x/300wx $esp)
Si ejecutamos x/300wx $esp para ver la información que hay en el pila vemos que nuestras Cs se están introduciendo al principio de la pila (stack), por lo que en este punto lo que debemos hacer es encontrar un OpCode el cual nos permita realizar un salto al ESP, es decir al principio de la pila.
Info:
Vemos que se esta realizando todo correctamente al principio de la pila y llenando esos huecos con la C que se corresponden con 0x43434343.
Identificación del OpCode para JMP ESP
Para redirigir la ejecución al principio de la pila (ESP), necesitamos identificar el código de operación (opcode) de un salto (JMP ESP). Usamos nasm_shell.rb:
Nos metera en una shell interactiva de la herramienta:
Y ejecutamos lo siguiente:
Info:
Esto indica que el opcode para JMP ESP es FFE4.
Ahora usaremos objdump para saber cual es la dirección de memoria la cual nos permite realizar el JMP ESP
Info:
Y veremos que la direccion de memoria es 0x0804948b.
Generar un Shellcode (Reverse Shell)
Ahora generaremos un shellcode con msfvenom de la siguiente forma:
El flag -b '\x00\x0a\x0d' excluye los caracteres nulos y de salto de línea, ya que podrían interrumpir la ejecución del payload. El flag -f py genera el código en formato Python para facilitar su inclusión en scripts.
Info:
Obtener una shell como el usuario www-data
Por lo que crearemos un script para automatizar todo esto y tambien añadiremos en el script una cadena de NOPS para que salte todo hasta nuestro shellcode y se ejecute nuestra rever shell.
step4.py
Desbordamiento del buffer: El payload comienza con A's para llenar el buffer hasta alcanzar el offset donde se sobrescribe el EIP (22 en este caso).
Dirección de retorno: Utilizamos la dirección de una instrucción jmp esp para redirigir la ejecución hacia nuestro shellcode. Esta dirección se obtiene mediante análisis del binario vulnerable usando herramientas como gdb.
NOP sled: Se añade una "pista" de NOPs (\x90) antes del shellcode para garantizar que cualquier variación en la dirección de salto no interfiera con la ejecución del payload.
Por lo que ahora tendremos que hacer lo siguiente:
gdb (pwndbg)
host
Y finalmente en otra terminal de nuestro host tendremos que ejecutar el script y asi obtender la shell:
Y si nos vamos a la escucha veremos lo siguiente:
Escalate user maci
Primero sanitizaremos la shell (TTY):
Si hacemos sudo -l veremos lo siguiente:
Vemos que podemos ejecutar el script time.py como el usuario maci, por lo que veremos que contiene dicho script:
Vemos que hay un archivo de configuracion el cual permite o no la deserializacion por lo que nos iremos aqui:
Dentro de esta carpeta veremos que el siguiente archivo tiene permisos de escritura, por lo que podremos modificarle:
Cambiaremos el off por el on para que asi se active y no nos de error el script:
Ahora ejecutamos el script:
Info:
Ahora si leemos el archivo que se nos ha creado en el /tmp veremos lo siguiente:
Info:
Por lo que vemos esta ejecutando el data.pk1 serializado, por lo que nosotros podremos serializar un /bin/bash para obtener la shell del usuario maci.
Lo guardamos y lo ejecutamos:
Info:
Ahora si ejeuctamos lo siguiente:
Con esto ya seremos el usuario maci.
Escalate user darksblack
Si hacemos sudo -l veremos lo siguiente:
Por lo que vemos podemos ejecutar el binario dpkg como el usuario darksblack, por lo que haremos lo siguiente:
Y con esto ya seremos el usuario darksblack.
Escalate Privileges
Si intentamos exportar el PATH correcto ya que no lo tiene correcto para que podamos ejecutar nuestros binarios con normalidad, nos pondra esto:
Info:
Por lo que tendremos que utilizar rutas absolutas, vamos a listar la /home del usuario:
Info:
Vemos que hay un archivo interesante llamado Olympus vamos a probar a ejecutarlo:
Info:
Vemos que nos pide un SERIAL para entrar en el modo administrador, por lo que le vamos hacer ingenieria inversa para descubrir cual es el SERIAL, vamos a pasarnoslo a nuestra maquina host, pero nos pasaremos el siguiente binario que se encuentra aqui:
Si listamos:
Info:
Por lo que vemos tiene pinta de contener el SERIAL.
Y en nuestro host:
Info:
Una vez que ya nos lo hayamos pasado, abriremos Ghidra.
Ghidra
Crearemos un nuevo proyecto y nos aparecera el siguiente icono:
Le daremos a dicho icono y despues importaremos el binario OlympusValidator para decompilarlo y ver donde se encuentra el SERIAL:
Si nos vamos a la function llamada spoof veremos lo siguiente:
Es lo que nos muestra cuando el SERIAL es correcto, por lo que vamos a decodificarlo:
Info:
Por lo que vemos nos muestra la contraseña de root, por lo que haremos lo siguiente:
Metemos como contraseña @#*)277280)6x4n0 y veremos que estaremos dentro como el usuario root:
PASO EXTRA:
Si nosotros queremos descubrir el SERIAL podremos irnos a la function llamada main y ver lo siguiente:
Vamos a decodificar lo que se esta comparando con el SERIAL:
Info:
Y si ejecutamos el OlympusValidator:
Info:
Last updated