FTPShadowMove, ¿SUFICIENTEMENTE SIGILOSO? PARTE 4

Autor: Silvia Hernández Sánchez

RESUMEN

En esta publicación, se describirá el funcionamiento de la PoC de ShadowMove Gateway que fue desarrollada por @TheXC3LL [1], en el que se empleará un servidor basado en Linux en el que se encuentre desplegada una instalación estándar de vsftpd (en inglés, Very Secure File Transfer Protocol Daemon) y un dispositivo Windows que se comporte como agente que se comunique con el servidor, empleando el binario de sistema ftp.exe. Tras el envío de unos cuantos comandos que simulen una actividad normal, se ejecutará el binario de FTPShadowMove bajo el mismo usuario que envía comandos mediante las comunicaciones ya establecidas de FTP.

Palabras clave: FTPShadowMove, socket, handle, servidor, agente

 

SECUESTRANDO SESIONES FTP

El equipo formado por Amirreza Niakanlahiji, Qingyang Wang, Jinpeng Wei, Bei-Tseng Chu y Rabbi Alam [2] describe la prueba de concepto que desarrollaron de la siguiente forma:

Desarrollaron un sistema prototipo que podía secuestrar conexiones FTP establecidas entre un dispositivo con un sistema operativo Windows 10 y otro dispositivo con un sistema operativo Ubuntu 18.04. Éstos empleaban la instalación por defecto de ftp y no requerían de ninguna elevación de privilegios.

Con el desarrollo de FTPShadowMove, podían permitir a un atacante que descargará y cargará ficheros a un servidor FTP remoto sin autenticación.

Por un lado, en el protocolo FTP [1], un cliente usa una conexión TCP para enviar comandos hacia un servidor y recibe las correspondientes respuestas del servidor, lo que es conocido como canal de comandos.

Por otro lado, el cliente FTP usa otra conexión TCP para enviar o recibir datos como contenidos de fichero, siendo llamado este medio como canal de datos.

Un cliente puede abrir múltiples canales de datos para un canal de comandos que sea dado, siendo la autenticación solamente requerida para establecer el canal de comandos, lo que significa que un cliente no necesita reautenticarse para crear un nuevo canal de datos. Los atacantes que hayan secuestrado el canal de comandos pueden enviar solicitudes al servidor para abrir un nuevo canal de datos para ellos mismos, evitando cualquier colisión con los contenidos legítimos enviados por el cliente que estén siendo transferidos en canales de datos existentes. Aún aprovechando el canal de datos de esta manera, los atacantes tendrían que adoptar estrategias para prevenir una condición de carrera (dos procesos que compiten en una “carrera” por llegar antes que el otro) en el canal de comandos que es compartido.

Un cliente FTP puede solicitar la creación de un nuevo canal de datos de dos maneras:

  • FTP activo: El cliente envía el comando “Port” hacia el servidor, especificando el puerto que el servidor necesita conectar de vuelta para establecer la conexión.
  • FTP pasivo: El cliente envía el comando “PASV” hacia el servidor, preguntándole al servidor que escuche a un puerto que el cliente puede usar para conectarse, permitiéndole crear un canal de datos. Tras el envío de este comando, el servidor responde con la dirección IP y el puerto que necesita el cliente.

En otras palabras, la diferencia entre estos dos métodos la determina quién inicia la nueva conexión TCP. En este caso, el servidor inicia la nueva conexión TCP en modo activo y el cliente inicia la nueva conexión TCP en modo pasivo. Para el prototipo experimental se empleó el modo pasivo, el cual será recogido en esta publicación para su emulación.

 

EL PROTOTIPO EXPERIMENTAL

En primera instancia, se desplegó un servidor vsftpd en un sistema operativo Linux, en un VPS (en inglés, Virtual Private Server) alojado en Internet. Para el cliente legítimo se empleó el comando ftp y el Explorador de archivos de Windows (explorer.exe) para conectarse con el servidor configurado.

En segundo lugar, el inicio de sesión anónimo estaba bloqueado en el servidor, así que el cliente necesitaba enviar un nombre de usuario y contraseña que fueran válidos para poder conectarse. Tras esto, el cliente intercambiaba varios mensajes con el servidor para poder iniciar sesión en el servidor.

En tercer lugar, se ejecutaba FTPShadowMove bajo el mismo nombre de usuario que el cliente ftp. Esta técnica se aprovecha de que todos los manejadores (en inglés, handle) de ficheros son tratados por el driver de función auxiliar, conocido en inglés como Ancillary Function Driver o AFD, como manejadores de sockets por las llamadas a la API de Windows, lo que permite que se puedan duplicar con “WSADuplicateSocket()”.

Este prototipo comienza a duplicar todos los manejadores de ficheros hasta que encuentra aquellos con el nombre “\Device\Afd\”, para más tarde emplear la llamada a la api de Windows “getpeername()” para comprobar si pertenece a una conexión con el objetivo. Tras secuestrar la conexión FTP, al duplicar el socket correspondiente, comienza a enviar múltiples comandos para subir un binario a un directorio específico en el servidor.

 

LOS COMANDOS EN CRUDO DE FTP

Los comandos específicos y las respuestas del servidor de la prueba de concepto del prototipo, son los siguientes:

    1. Primer comando con FTPShadowMove: CWD /files/

Respuesta del servidor: 250 Directory successfully changed.

    1. Segundo comando con FTPShadowMove: TYPE I

Respuesta del servidor: 200 Switching to binary mode.

    1. Tercer comando con FTPShadowMove: PASV

Respuesta del servidor: Entering Passive Mode (54, 36, 162, 222, 176, 251)

    1. Cuarto comando con FTPShadowMove: STOR PoC2.txt

Respuesta del servidor: Entering Passive Mode

En el último comando que es enviado por este FTPShadowMove prototipo, se solicita la subida de un fichero denominado “PoC2.txt” en el servidor, el cual es interpretado como contenido binario y almacenado en /files/PoC2.txt.

En el prototipo, sólo se usan unos cuantos comandos en crudo de FTP, aunque pueden emplearse otros muchos como “SITE” que permite a un usuario ejecutar un número limitado de comandos a través del servidor FTP en una máquina anfitriona, sin requerir ningún tipo de autenticación. Otros comandos interesantes, derivados del uso de “SITE” son “EXEC” o “CHMOD”. En el caso de “EXEC”, permite accionar el ejecutable provisto al servidor, lo cual puede permitir que se detone malware.

Aunque el cliente de línea de comandos de ftp.exe de Windows no acepte, por defecto, los comandos en crudo de FTP, si que pueden enviarse comandos en crudo (en inglés, raw commands), a bajo nivel, gracias a las modificaciones realizadas en el código, lo que permite enviar este tipo de instrucciones al servidor, abusando del socket de un cliente FTP que no lo permite en alto nivel.

Que se puedan enviar este tipo de comandos, en bajo nivel, sugiere que la gran mayoría de clientes FTP para Windows (FileZilla, WinSCP, Cyberduck, entre otros)

 

LA EMULACIÓN DE FTPSHADOWMOVE

Primeramente, se realiza inicio de sesión con un usuario creado para realizar comunicaciones FTP.

En segundo lugar, tras compilar la prueba de concepto de X-C3LL, se realizan unas modificaciones en el apartado de “// Classic” [4], para más tarde ser ejecutado. Tras esto, se ejecuta un comando “dir” de alto nivel.

Imagen obtenida de la ejecución del código provisto por X-C3LL

Debido a que se pueden emplear los comandos en crudo, ya que la comunicación con el servidor ocurre a bajo nivel, se emplean los siguientes comandos:

  • TYPE I, cuyo homónimo de alto nivel del ftp.exe de Windows es “binary”.
  • PASV, cuyo homónimo de alto nivel del ftp.exe de Windows es “quote pasv”
  • STOR exito.txt, cuyo homónimo de alto nivel del ftp.exe de Windows es “put exito.txt”.

En el momento de ejecución, de la modificación realizada para FTPShadowMove, se observan unas respuestas del servidor, que pueden apreciarse en la imagen a continuación:

Imagen obtenida de la ejecución del código modificado para FTPShadowMove

Se destaca que la respuesta obtenida por el comando en crudo “PASV”, en la que devuelve el código 227 con el mensaje “Entering Passive Mode (192,168,1,68,143,151)” construye su respuesta, en la que provee la dirección IP con los 4 primeros números (192.168.1.68) y el puerto con la fórmula de X*256+Y, siendo X igual a 143 e Y igual a 151, dando como valor final, el puerto 36759.

Finalmente, tras el envío del último comando “STOR exito.txt”, se observa como este fichero TXT es almacenado dentro del servidor FTP, llegando mediante el socket abusado de FTPShadowMove.

Imagen obtenida de la ejecución del código modificado para FTPShadowMove

 

CONCLUSIÓN

En siguientes publicaciones, se realizarán pruebas de estrés con osquery y se intentará realizar diferentes métodos de detección para esta técnica novel, comprobando si realmente es imposible que FTPShadowMove sea detectado por este framework de instrumentación de sistemas operativos.

 

Silvia Hernández Sánchez

Threat Hunting & OSINT Specialist en Viewnext

 

BIBLIOGRAFÍA

[1] Juan Manuel Fernández (@TheXC3LL), Hijacking connections without injections: a ShadowMoving approach to the art of pivoting, 2021: https://adepts.of0x.cc/shadowmove-hijack-socket/

[2] Amirreza Niakanlahiji, JinpengWei, Md RabbiAlam, Qingyang Wang y Bei-TsengChu. ShadowMove: A Stealthy Lateral MovementStrategy, 2020: https://www.usenix.org/system/files/sec20-niakanlahiji.pdf

[3] J. Postel y J. Reynolds FILE TRANSFER PROTOCOL, 1985: https://datatracker.ietf.org/doc/html/rfc959

[4] Silvia Hernández Sánchez, FTPShadowMove, 2021: https://github.com/RitaVratask/FTPShadowMove/blob/main/FTPShadowMove.cpp