017 - Tron - wh01s17

Enumeración de servicios

El objetivo sólo expone SSH y HTTP. La portada se identifica como Master Control Program, por lo que comenzamos por enumerar rutas de la aplicación antes de probar credenciales:

❯ sudo nmap -p- -sS --min-rate 5000 -n -Pn -oG 01-allPorts 192.168.1.26
❯ nmap -sC -sV -p22,80 -oN 02-targeted.txt 192.168.1.26
Starting Nmap 7.94 ( https://nmap.org ) at 2024-02-03 14:14 -03
Nmap scan report for 192.168.1.26
Host is up (0.00037s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 1f:ed:64:93:84:b5:b2:e8:af:5a:0e:6f:52:af:4b:48 (RSA)
|   256 3d:df:6f:02:13:9e:15:f8:51:94:30:f8:45:e3:f2:93 (ECDSA)
|_  256 2f:f4:af:e1:f4:c4:a5:3b:50:bb:e5:b9:2a:9f:39:de (ED25519)
80/tcp open  http    Apache httpd 2.4.38 ((Debian))
|_http-title: Master Control Program
|_http-server-header: Apache/2.4.38 (Debian)
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: 1 IP address (1 host up) scanned in 6.65 seconds

Enumeración web

Gobuster descubre /MCP, además de robots.txt y varios directorios estáticos:

❯ gobuster dir -u 192.168.1.26 -w ~/Documentos/wordlists/SecLists/Discovery/Web-Content/directory-list-2.3-big.txt -x html,php,txt
...
/index.html           (Status: 200) [Size: 309]
/img                  (Status: 301) [Size: 310] [--> http://192.168.1.26/img/]
/manual               (Status: 301) [Size: 313] [--> http://192.168.1.26/manual/]
/robots.txt           (Status: 200) [Size: 623]
/font                 (Status: 301) [Size: 311] [--> http://192.168.1.26/font/]
/MCP                  (Status: 301) [Size: 310] [--> http://192.168.1.26/MCP/]
...

El código fuente del índice contiene una cadena con formato de usuario y contraseña, aunque ambos valores están codificados:

<!-- kzhh:SbWP9q94ZtE9qD  -->

Resolución de las pistas

En /MCP/tron.txt encontramos un diálogo y una cadena Base64:

MASTER CONTROL PROGRAM
----------------------
Ram:
Do you believe in the Users?
Crom:
Sure I do! If I didn't have a User, than who wrote me?

KysrKysrKysrK1s+Kz4rKys+KysrKysrKz4rKysrKysrKysrPDw8PC1dPj4+PisrKysrKysrKysrKy4tLS0tLi0tLS0tLS0tLS0tLisrKysrKysrKysrKysrKysrKysrKysrKy4tLS0tLS0tLS0tLS0tLS0tLS0tLS4rKysrKysrKysrKysrLg==

La primera decodificación no produce texto legible, sino un programa Brainfuck.

El resultado conserva símbolos característicos de Brainfuck, como +, >, <, [ y ]. Esa estructura confirma que Base64 era sólo la primera capa y evita tratar la salida como texto dañado:

❯ echo "KysrKysrKysrK1s+Kz4rKys+KysrKysrKz4rKysrKysrKysrPDw8PC1dPj4+PisrKysrKysrKysrKy4tLS0tLi0tLS0tLS0tLS0tLisrKysrKysrKysrKysrKysrKysrKysrKy4tLS0tLS0tLS0tLS0tLS0tLS0tLS4rKysrKysrKysrKysrLg==" | base64 -d
++++++++++[>+>+++>+++++++>++++++++++<<<<-]>>>>++++++++++++.----.-----------.++++++++++++++++++++++++.--------------------.+++++++++++++.

Al ejecutar el programa obtenemos player, que utilizamos como nombre de usuario. Dentro de /MCP/terminalserver hay otro archivo que describe un alfabeto invertido, equivalente al cifrado Atbash:

substitute
--------------------------
plaintext
abcdefghijklmnopqrstuvwxyz

ciphertext
zyxwvutsrqponmlkjihgfedcba
--------------------------

Aplicamos Atbash a la cadena del comentario. kzhh se transforma en pass y el segundo componente produce la contraseña real.

Cada transformación entrega el formato esperado por la siguiente: Base64 genera Brainfuck, el intérprete produce el usuario y Atbash convierte la última cadena en una credencial legible:

kzhh:SbWP9q94ZtE9qD
pass:SyWP9j94ZgE9jD

Acceso inicial mediante SSH

Iniciamos sesión con player:SyWP9j94ZgE9jD y recuperamos la primera flag.

Escalada mediante `/etc/passwd`

Durante la enumeración local comprobamos que player puede escribir en /etc/passwd, una vía de Writable Critical Files Privilege Escalation. Generamos un hash compatible con crypt mediante OpenSSL y sustituimos únicamente el campo de contraseña de la entrada de root.

El segundo campo de /etc/passwd suele contener x para delegar la verificación en /etc/shadow. Al reemplazarlo por un hash válido, su comprueba nuestra contraseña directamente. Conservamos UID y GID 0, por lo que la cuenta sigue siendo root:

player@tron:~$ openssl passwd
Password:
Verifying - Password:
z/ujeo9Mel5CY

Se utilizó su root con la contraseña elegida y se recuperó la flag.

Fin.