miércoles, noviembre 22, 2017

¡Salta conmigo! Metasploit, Meterpreter, SSH, Port-Forwarding, Túneles & Exploits

Ya hemos hablado de la tunelización de conexiones con Proxychains, pero en esta ocasión quería mostrar un ejercicio fundamental en un proyecto de Ethical Hacking. Hablar de túneles, port-forwarding y pivoting con y sin Meterpreter. Un compendio de buenas prácticas y técnicas que ayudan a poder saltar y saltar entre diferentes máquinas y servicios de la organización.

Figura 1: ¡Salta conmigo! Metasploit, Meterpreter, SSH, Port-Forwarding, Túneles & Exploits

¿Qué es el pivoting?

Es una técnica, como dije anteriormente fundamental, utilizada para encaminar tráfico a través de un equipo comprometido en un test de intrusión. Estés en una máquina externa o una máquina interna, puedes necesitar conducir el tráfico a través de una máquina comprometida para buscar el compromiso de otros targets internos.

Figura 2: SSH & Meterpreter pivoting techniques "cheatsheet"

Al fin y al cabo, el pivoting permite ir enrutando el tráfico de red a través de diferentes máquinas que se van comprometiendo con el objetivo de lograr conectividad y acceso a otras subredes y máquinas, generalmente, más importantes de la red. En highon.coffee tienen unos cheatsheets bastante completos. En el artículo de hoy vamos a hacer un resumen de las posibilidades que tenemos, para ejemplificar a través de una pequeña prueba de concepto.

PoC: Pivoting con túneles SSH

Lo primero es hablar de SSH Port-forwarding. El propio SSH nos permite realizar este tipo de operaciones de manera sencilla. Proponemos el siguiente escenario:
• Máquina A con la dirección IP 10.0.0.1, dónde nosotros tenemos una shell. 
• Máquina B con la dirección IP 11.0.0.1, dónde nosotros tenemos una conexión a través de SSH. 
• Máquina C con la dirección IP 11.0.0.2, dónde esta máquina no tiene conectividad con la máquina 10.0.0.1, pero sí con la máquina 11.0.0.1.
Podríamos utilizar la opción –L de SSH para indicar un puerto local, por ejemplo 2222, al que enviaremos el tráfico. En nuestra máquina local se abrirá el puerto 2222 y SSH estará a la escucha. Es SSH, a través de dicho puerto, el encargado de reenviar el tráfico al puerto, por ejemplo, 22 de la máquina 11.0.0.2 a través del equipo 11.0.0.1.

Vamos a verlo de forma práctica. Ejecutando la instrucción ssh –L 2222:11.0.0.2:22 [user]@11.0.0.1. Recordemos que suponemos que la máquina 10.0.0.1 y la 11.0.0.1 tienen conectividad, pero la 10.0.0.1 no tiene con la máquina 11.0.0.2.

Figura 3: Abriendo la conexión en el puerto local 2222

Una vez que el usuario tiene acceso a la máquina 11.0.0.1, se ha creado el forward a través del puerto local 2222. Ahora, si ejecutamos un netstat –tulpn en nuestro Kali Linux podemos ver los procesos que están a la escucha en la máquina. Podemos ver de forma fácil como el proceso de SSH está a la escucha en el puerto 2222.

Figura 4: SSH a la escucha en el puerto 2222

Cuando queramos conectar con la máquina que se encuentra en la dirección IP 11.0.0.2, a la que no tenemos conectividad directa, pero sí a través de la 11.0.0.1, ejecutaremos el comando ssh –p 2222 [user]@127.0.0.1. Como se ve, estamos enviando la petición SSH a nuestro puerto local 2222 y a nuestro localhost. SSH recibe esta petición y hace el reenvío a través de la conexión o sesión abierta de la máquina 11.0.0.1 y de ésta salta a la 11.0.0.2. Ahora sí llegamos a la máquina 11.0.0.2.

Figura 5: Volcado de tcpdump que muestra el tráfico entre ambas máquinas

Como se aprecia en la imagen tenemos conectividad. Lo que nos interesa es ver qué tráfico y en qué forma llega a la máquina 11.0.0.2. En la máquina 11.0.0.1 configuramos un tcpdump y vemos cómo el tráfico que se envía hacia la máquina 11.0.0.2 va con dirección IP 11.0.0.1.

Figura 6: PoC de SSH Pivoting

PoC: Metamos a Metasploit en la ecuación

Ahora vamos a meter a Metasploit en el juego. Con el túnel creado entre la máquina 10.0.0.1 y 11.0.0.1, vamos a configurar el módulo de Metasploit para que pueda enviar el exploit a través del túnel, cuando éste llegue a la máquina 11.0.0.1 se hará forward y se enviará el exploit a la máquina 11.0.0.3. Ésta es una nueva máquina que metemos en la ecuación. Esta máquina es un Windows 7 y tiene un FTP vulnerable corriendo en el puerto 21.

Tenemos que crear un nuevo túnel con la máquina 11.0.0.1, el cual podemos hacerlo con la siguiente instrucción ssh –L 2222:11.0.0.3:21 pablo@11.0.0.1. De esta forma, en nuestra máquina local se abrirá el puerto 2222 en la interfaz de red 127.0.0.1 con el proceso de SSH y éste hará el forward al puerto 21 de la máquina 11.0.0.3 aprovechando la conexión con la máquina 11.0.0.3.

Podemos configurar el módulo de Metasploit para que RHOST apunte a 0.0.0.0, es decir, cualquier interfaz de red de nuestra máquina, incluyendo localhost que es dónde está a la escucha el puerto 2222. En RPORT, debemos utilizar el puerto 2222, ya que es el que está a la escucha en nuestra máquina.

Figura 7: Configuración de LPORT y RPORT en el módulo del exploit

Cuando ejecutamos el módulo podemos ver que éste se ejecuta, pero parece que no tenemos conexión o sesión. Aunque el exploit ha tenido éxito, no obtenemos sesión debido a que el payload se ha configurado de tipo bind y éste está atado al puerto 4444 de la máquina 11.0.0.3, a la cual no tenemos conectividad. Debemos, en este caso, crear un nuevo túnel que nos redirija al puerto 4444 de la máquina 11.0.0.3.

Figura 8: Conexión de nuevo tunel

Para conectarnos, utilizamos el módulo exploit/multi/handler con el que podremos buscar al Meterpreter que nos ha devuelto la explotación de la vulnerabilidad del servidor FTP. ¿Qué había ocurrido? La vulnerabilidad había sido explotada, y Meterpreter estaba ejecutándose en el puerto 4444 a la espera de que alguien se conectara a él.

Como se ve en la imagen, de nuevo RHOST apunta a 0.0.0.0 y LHOST, en este caso, apunta al puerto 2222, que es el de nuestra máquina local. Una vez lanzamos el módulo obtenemos la nueva sesión de Meterpreter y podemos ejecutar comandos.

Figura 9: Conexión con Meterpreter

Debemos tener claro que gracias al túnel SSH entre la máquina 10.0.0.1 y la máquina 11.0.0.1 hemos podido hacer forward del tráfico dirigido al puerto 21 de la máquina 11.0.0.3, utilizando como pivote a la 11.0.0.1, y, posteriormente, hemos realizado el mismo proceso, pero con el puerto 4444, para recoger el Meterpreter.

Figura 10: PoC Pivoting con Meterpreter

Una mejora sería utilizar un Meterpreter reverse para que la máquina 11.0.0.3 pueda conectarse a nosotros si tuviera conectividad desde dentro hacia fuera. Todo el proceso se puede ver en el vídeo de la PoC que tienes aquí.

PoC: Rizando el rizo. Dos saltos y pwned en el servidor FTP

Por último, se quiere saltar por dos máquinas antes de llegar al servidor FTP. Para ello, se abre el puerto 2222 en local y se indica que es a 127.0.0.1 dónde se lanza la petición con destino puerto 2223 en la máquina remota. Una vez se tiene acceso en la máquina 11.0.0.1, se abre el puerto 2223 y se indica que las peticiones que salgan de dicha máquina vayan al puerto 21 de la máquina 11.0.0.3. Puede resultar un poco lioso, pero os dejo una imagen que puede ayudaros.

Figura 11: Ahora dos saltos en vez de uno

Ahora, lanzamos el exploit con la misma configuración que en el paso anterior. El exploit pasará por la máquina 11.0.0.1, de la 11.0.0.1 pasa a la 11.0.0.2 y de ésta a la 11.0.0.3 dónde llega ya en plano, en la petición de protocolo FTP. De la máquina 10.0.0.1 a la 11.0.0.1 y de la 11.0.0.1 a la 11.0.0.2 hay dos túneles SSH. Cuando queremos preparar los túneles para recoger el Meterpreter de tipo bind. En la imagen se puede ver cómo queda la configuración de los túneles, para la recogida del Meterpreter en el puerto 4444.

Figura 12: Túneles preparados para la recogida de la sesión Meterpreter

Para acabar, vemos cómo obtener el acceso a la máquina Windows 7, que se encuentra a dos saltos de nosotros, sin ningún tipo de conectividad con la máquina Kali Linux dónde nos encontramos.

Figura 13: Goal!

Para más adelante dejamos la funcionalidad de Metasploit de Portfwd, con la que podemos hacer este tipo de cosas más sencillas, y tras conseguir la explotación con Metasploit. Sin duda, una técnica necesaria y que debemos manejar. Y no he querido rizar el rizo, pero si quieres que estas SSH sean solo tuyas, puedes ver el artículo de configurar SSH in paranoid mode.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

martes, noviembre 21, 2017

The Punisher & The Most Secure FTP Server [Spoiler Alert] #ThePunisher #SpoilerAlert

Normalmente me gusta prestar mucha atención a lo que está pasando en las series. Me encanta ver Elementary e intentar descubrir al asesino antes que Sherlock Holmes - de esta serie hay algunos capítulos fantásticos que tienen que ver con tecnología, como el de la IA del que os hablaré en algún momento-, o fijarme que el Sistema Operativo de Robocop está basado en un MS-DOS pero con el punto cambiado en el Command.com, o que en Mr. Robot no usaba passcode para el iPhone en el primer episodio de la primera temporada o, como os dejé hace poco, en Stranger Things usan una tabla periódica del futuro.

Figura 1: The Punisher & The Most Secure FTP Server [Spoiler Alert]

Ahora estoy disfrutando The Punisher, y ayer noche, en el carrusel de capítulos que me enchufé, me topé con una escena que me encantó. Si la quieres ver, para aquí, porque puede que te haga algo de SPOILER, así que como aún no la ha visto mucha gente, no está permitido desvelar cosas sin avisar. No como con el final de los Sopra... [Fade to black]

A post shared by Chema Alonso (@chemaalonso) on


[Spoiler Alert Begins Here]

En la escena, Micro (uno de los personajes principales de la serie) está a punto de subir un fichero a un servidor FTP para enviar un correo electrónico con un enlace al fichero a una persona de la NSA. Se supone que nuestro amigo Micro es miembro de la NSA, y para ello tiene una cuenta en The Most Secure FTP Server. La imagen y estética de la web del servidor FTP es espectacular.

Figura 3: El servicio FTP más seguro de la red: Ouh, yeah!!

La he subido a alta resolución por si queréis revisar todos los detalles con cuidado, que las carpetas y ficheros sin nombre en el desktop también tienen su gracia. Sin duda, lo más curioso es el navegador, la web del servicio FTP y la lista de medidas de seguridad que dice disfrutar el sitio, que podemos revisar una a una:
- Supports an Unicode Password: Esta es buena, se supone que puedes poner contraseñas con caracteres no imprimibles, lo que le da una gran seguridad a la contraseña para que alguien la averigüe. Por supuesto, para hacer más compleja la contraseña, a la derecha, debajo del login tenemos información de que la contraseña debe ser de más de 12 caracteres. 
Al final, está metiendo una contraseña compleja a un servicio online como forma de autenticación segura, algo que no es ni de lejos lo más seguro. Lo suyo es una autenticación multifactor, utilizando Tokens OTP o algo como Latch, certificados digitales, e incluso biometría - aunque esto iría un poco contra la privacidad - pero desde luego no meter contraseñas complejas, algo que tenemos que erradicar de los servicios online dando prioridad a los 2FA.
-  Completely anonymous e2e encryption: A lo largo del proceso no se ve muy claro cómo hace el e2e encryption, ni si se refiere a cuando el fichero se sube al servidor FTP o cuando se envía el correo electrónico vía enlace en un e-mail al destinatario, pero desde luego, para hacer el e2e el fichero debe ser cifrado en el cliente y descifrado en la máquina del destinatario, algo para lo que se necesita algún intercambio de claves entre emisor y receptor. Por supuesto, esto no pasa en ningún momento en la escena, así que el cifrado de las comunicaciones lo hacen reguleramente.
Figura 4: El servidor envía un e-mail cifrado con un enlace
Además, hay dos momentos en los que habría que cifrar. El primero cuando se sube el fichero al servidor FTP para que no quedara una copia un-encrypted en el disco duro del FTP, y una segunda cuando se cifra el e-mail. Dos veces en los que se debería usar la clave de cifrado del destinatario, algo que no aparece por ningún sitio. Raro, raro. Deberían dar un repaso al libro de Criptografía y cifrado de las comunicaciones digitales
- Free and Open Source: Genial. Eso significa que es Free and Open Source y por tanto, se supone que el código puede ser revisado por cualquiera para garantizar que no tiene bugs o puertas traseras - aunque luego pase como con TrueCrypt y toda la polvoreda de especulaciones que se levantó -. Ahora bien, eso tendría que comprobarlo el emisor en el cliente a la hora de cifrar y destinatario a la hora de descifrar, pero lo que haya en el servidor Web/FTP puede estar manipulado por cualquiera, así que está muy bien que lo pongan en la web de login, pero tiene poco sentido. Eso sí, da color.
- Metadata Protection: Esta es buena. Un hook a la memoria americana y el caso de las filtraciones de Edward Snowden con las políticas de Metadata Retention y el famoso PRISM que otorgaba a la NSA acceso a conexiones y llamadas de teléfono entre personas. En el caso del servidor FTP, se supone que ¿no guardan logs de conexión? 
Está claro que aunque el servidor no guarde logs de conexión, por el medio hay muchos dispositivos de red que pueden guardar logs del proceso, por lo que lo suyo sería no fiarse y conectarse vía TOR de forma segura - y desde una conexión que no esté en tu casa mejor que mejor -.
Además, el servidor está bajo un dominio .NET, lo que implica que no está en un hidden service y está sujeto a una legislación que debe cumplir y que si no lo hace, puede ser intervenido. Vamos, que lo del anonimato en las conexiones está regulera también.
- Antispam & Blacklist filters: Esta parte la he tenido que tomar con mucha imaginación para darle algo de sentido. He querido ver que, como se envía un mensaje de correo electrónico con el enlace al fichero en el servidor FTP Super-Seguro, el servidor tenía medidas para garantizar que el mensaje de correo electrónico que se envía ¿se va a saltar los filtros antispam y las listas negras?
Figura 5: El fichero ha sido enviado con un link vía AES. Oh, tell it again!
Desde luego no diréis que no he hecho un ejercicio de imaginación para interpretar estas medidas de seguridad en un servidor FTP. Aún así, garantizar que el mensaje va a saltarse eso es muy complicado, ya os dejé un artículo que explicaba ¿por qué mi correo electrónico llega como spam? Además, que se use AES para recibir el enlace al fichero ¿significa que se utiliza AES en el cifrado e2e del correo?
- Clock & Time-Zone Spoofing: Otra buena. Con mucha imaginación he querido ver que alguien se había leído los trabajos de investigación de mi amigo Sergio de los Santos para medir las zonas horarias de los archivos usando los metadatos del sistema operativo y del fichero ZIP. Vamos, que están preocupados por herramientas como nuestro GMTCheck de ElevenPaths, y que hacen una modificación de estos metadatos antes de cifrar e2e los ficheros. Esa herramienta se utilizó para investigar WannaCry. Mola, ¿no?
Figura 6: GMTCheck de ElevenPaths
- Multiples instances of server: Esta debe ser para evitar los ataques DDOS y ser resiliance ante intentos de eliminar el servicio de la red. Algo que si se basa en el nombre de dominio DNS no tiene mucho sentido para nada. Pero... vamos a jugar al pacto de ficción. Esto, además, será necesario para enviar el fichero desde 16 direcciones IP aleatorias para evitar que alguien en un man in the middle pueda recomponer el fichero cifrado. Rebuscado.
- Quick, encrypted set up: Configuración rápida y, eso sí, cifrada. Para que cuando te des de alta en tu cuenta gratuita todo vaya rápido, muy rápido y cifrado, muy cifrado.
Después de ver las medidas, me acordaba de este servidor FTP del ejercito de los Estados Unidos de América que tenía un mejor sistema de seguridad. Uno muy claro: Este servidor es inseguro pero ni lo toques.

Figura 7: Este servidor es inseguro

Visto todo esto, al final como era de esperar nada más ver lo anterior, el malo de la NSA descubre inmediatamente quién ha enviado este correo con ese archivo - goodbye e2e encryption y anonimato-, y a la mañana siguiente van a por él para matarle. Eso sí, toma la precaución de ponerse el smartphone en el bolsillo del corazón que detiene la bala cuando es disparado como ya ha pasado en la realidad. Un hacker precavido siempre guarda el smartphone ahí.

Figura 8: Al final la tecnología salva la vida de Micro parando la bala

Dicho esto, Micro se supone que es un hacker experto, así que lo de utilizar este servidor FTP tan seguro vía una web en HTTPs es cuanto menos poco creíble. Menos aún que envíe un CD/DVD con el vídeo - ¡ni tan siquiera un pendrive! - o que no haya hecho un análisis de los metadatos del mp4 antes de enviarlo ¡hombre, será posible!.

[Spoiler Alert Ends Here]

Esto no es nada más que una curiosidad. La serie mola mucho. El protagonista lo hace tan bien como lo hizo en Walking Dead y en la segunda temporada de Daredevil. Me encanta. Eso sí, no la veas con niños menores a los que les gusten los superhéroes si no conoces bien a Frank Castle, porque la sangre y los asesinatos son un continuo.Ya sabéis, si quieres saber dónde está The Punisher, solo debes seguir el rastro de cadáveres. Recuerda, If you are guilty...

Saludos Malignos!

Entrada destacada

Nuevo libro "Máxima Seguridad en Windows: Secretos Técnicos 4ª Edición" de @0xWord

Desde 0xWord se ha acelerado para tener a tiempo antes del verano la 4ª Edición del libro "Máxima Seguridad en Windows: Secretos Técn...

Entradas populares