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!

lunes, noviembre 20, 2017

Telefónica Open Future Blockchain Challenge

El día 21 de Noviembre es el último día para presentar tu propuesta para conseguir una plaza en el hackathon que tendrá lugar en Madrid el próximo fin de semana. Un fin de semana para disfrutar de la tecnología y Blockchain para la gente que le gusta hacer cosas - y no solo quedarse en la fase de ideación -. Yo creo que me voy a pasar por allí a ver quiénes son los doers de estas tecnologías.

Figura 1: Telefónica Open Future Blockchain Challenge_

El challenge ha sido convocado por Telefónica Open Future, buscando ideas frescas e innovadoras alrededor de la tecnología Blockchain, algo en lo que llevamos tiempo trabajando en la casa.  Las bases de la convocatoria las he subido a SlideShare para que las tengáis disponibles aquí mismo.


Queda poco tiempo ya, pero si tienes una idea en mente a medio desarrollar, esta es una oportunidad única para que aceleres sus construcción. Preséntala, y vente al hackathon en Madrid para defenderla y ganar los premios. Blockchain ha venido para quedarse y cada vez está presente en más y más proyectos, así que esta es una ocasión ideal para meterse de lleno en ella. Además, recuerda que nuestros compañeros Felix y Yaiza escribieron un libro en 0xWord sobre la tecnología Blockchain que merece la pena que leas si quieres introducirte en este mundo.

Saludos Malignos!

domingo, noviembre 19, 2017

Cómo hacer tu primer ataque de diccionario a un router con Python

En este artículo voy a explicar cómo preparé un ataque de diccionario dirigido al sistema de autenticación de routers, switches o dispositivos de red utilizando Python. Con este ataque se va a intentar averiguar los usuarios y contraseñas para acceder al panel de administrador de un dispositivo, utilizando archivos de texto con listas de usuarios y listas de contraseñas, es decir, es un ataque de diccionario.

Figura 1: Cómo hacer tu primer ataque de diccionario a un router con Python

Estos diccionarios se pueden crear manualmente, por medio de herramientas, o encontrar por Internet los ya creados. Hay diccionarios de todo tipo, desde listas generadas en GitHub, hasta diccionarios generados con passwords reales filtradas ordenadas por popularidad. En este caso, como idea, puedes buscar en la siguiente web: https://wiki.skullsecurity.org/Passwords

Figura 2: Passwords en Skullsecurity

La mayoría de los routers vienen con usuarios por defecto y muchos de los dueños no suelen cambiar la contraseña que viene configurada por defecto. Es por esto por lo que se aplica este ataque fácilmente desde hace mucho tiempo - no solo con los routers -.
- Default Passwords: Adelante por favor 
- Gracias por tu password, router
Sin embargo, si se cambia las contraseña que viene por defecto, y se pone una compleja - de cierta longitud y combinación de números, letras minúsculas, mayúsculas y símbolos - entonces este mecanismo tendrá pocas probabilidades de éxito.

Una PoC de BruteForce en Python

He preparado un script en Python para realizar este ataque, que he probado solo en routers CISCO y Huawei. A continuación se puede ver el código, hay que tener en cuenta que esta versión va a recorrer ambos archivos en su totalidad, lo que puede ser lento si los archivos son extensos, al final mostraré un pequeño cambio para parar cuando encontremos la primera combinación exitosa.

Por supuesto, no es una herramienta profesional con multithreading y organización probabilística o que utilice un sistema de medición de latencias para acelerar o decelerar el número de peticiones en paralelo. Es solo una PoC para probar algo que no solo tiene que ver con las contraseñas por defectos, sino con las protecciones de número de intentos fallidos. Como se verá, no hay ninguna protección en la mayoría de los sistemas testeados contra los ataques de fuerza bruta, incluso sin son como éste.

Figura 3: Código de BF para la PoC en Python

Ahora voy a comentar un poco el código: lo primero que hacemos es importar los módulos que necesitamos (urllib.request, http.client, sys). He creado un par de funciones, que se explican por partes:

- Función get_realm: recibe un parámetro, que es la dirección IP del objetivo. Se encarga de realizar una petición GET al objetivo para conseguir el valor de la cabecera www-Authenticate, por ejemplo de la siguiente devolvería myRealm, si no se puede conseguir el valor, se acaba el script:
WWW-Authenticate: Basic realm="myRealm"
- Función attack: recibe 3 parámetros, la dirección IP del objetivo, y 2 ficheros (que son abiertos antes de pasarlo, por comodidad). Creo una variable booleana, para mostrar información al final si no se encuentra una combinación con éxito, llamo a la función get_realm y se va a recorrer los dos ficheros (usuario y contraseñas) con dos bucles for, para comprobar cada posible combinación. Dentro del bucle se van a crear las conexiones, para la autenticación pasamos los siguientes datos: Realm, IP, Usuario y Contraseña

Se comprobará la respuesta, si se obtiene un código 200 es que todo fue bien, por lo que tenemos usuario y contraseña, y se muestra que fue correcto, en caso contrario el login no es válido y saltará una excepción en la siguiente línea:
pag = ur.urlopen("http://" + str(ip))
Entonces, se informa de que la combinación usuario y contraseña no es correcta.

- Main: Por último tenemos la parte main del script, donde se pregunta al usuario la dirección IP y los ficheros (que  son abiertos, si algo va mal se informa y se sale del programa), y con esta información se llama a la función attack vista antes. Los archivos de texto que he usado aquí son pequeños y ambos contienen el mismo contenido, por ejemplo en la siguiente imagen se puede ver el de usuarios:

Figura 4: Ficheros users.txt

Si ejecutamos el código sobre un router de prueba que tiene cambiada la contraseña, tenemos la siguiente salida:

Figura 5: Resultados de un router con las contraseñas por defecto cambiadas

Ahora vamos a ejecutarlo contra un router en el que se encontrarán 2 combinaciones válidas, aquí esta la captura:

Figura 6: Router con dos aciertos de combinaciones

Existe una librería distinta a la usada aquí, que te permitirá también realizar conexiones HTTP de manera más sencilla: request. Por si no la conocías, puedes echarla un vistazo. Como comente antes, para que el script acabe en la primera combinación exitosa de usuario y contraseña, hay que hacer una pequeña modificación en la función attack, borrando la variable find y teniendo el siguiente código en el if que comprueba si el código de respuesta es 200:

Figura 7: Comprobación de salida con éxito 

Llega el momento de despedirse. Este solo es un ejercicio para los que estamos aprendiendo que he querido compartir. Por supuesto, no solo faltan los controles que he indicado al principio, sino que se podrían añadir fases de fingerprinting del dispositivo para probar solo las contraseñas de esos modelos, se podrían detectar la existencia de sistemas de autenticación con 2FA, detectar errores por límites de intentos y bloqueos de cuenta, o incluso si son vulnerables a algún exploit conocido que leakee usuarios. Cuanto más aprendas, más puedes ampliar estos ataques contra los sistemas de login. Puedes seguir aprendiendo a escribir scripts en Python que se encuentren destinados al hacking con dos libros que utilizo yo: Python para Pentesters y Hacking con Python. Hasta la próxima.

Autor: Josué Encinar García (@JosueEncinar). Ingeniero de Software, estudiante del Máster Universitario en Seguridad de Tecnologías de la Información y de las Comunicaciones en la Universidad Europea de Madrid. Analista de Seguridad en Accenture.

sábado, noviembre 18, 2017

Conferencias, charlas y eventos para la semana del 20 al 26 de Noviembre @0xWord @LUCA_d3 @ElevenPaths

Un sábado más os traigo la lista de eventos, charlas, cursos, conferencias y actividades en las que vamos a participar desde ElevenPaths, 0xWord, LUCA y compañeros de Telefónica. Yo voy a estar en algunas de ellas, así que tomad nota de lo que te pueda interesar para que nos veamos por ahí.

Figura 1: Conferencias, charlas y eventos para la semana del 20 al 25 de Noviembre

El martes día 21 de Noviembre yo estaré en el XVI Congreso de Directivos CEDE. Será en la ciudad de Alicante, de donde proviene parte de mi familia. La lista de ponentes está compuesta por una miriada de profesionales y ejecutivos con una larga trayectoria, así como con una gran responsabilidad. Tienes toda la información en el web del congreso.

Figura 2: XVI Congreso de Directivos CEDE

El miércoles 22 de Noviembre, nuestro compañero Pablo San Emeterio participara´en el congreso CyberSec17, que tendrá lugar en Madrid. Una charla dentro de un evento con un cartel de grandes profesionales del sector.

Figura 3: CyberSec17 en Madrid

El jueves 23 de Noviembre tendrá lugar online una nueva ElevenPaths Talk, en esta ocasión dedicada a los ataques y la seguridad de los sistemas de comunicación móvil. Si te gusta este tema, te recomiendo la última edición del libro "Hacking y Seguridad en Comunicaciones Móviles". La información de esta charla que será publicada online la tienes aquí:

Figura 4: ElevenPaths Talk sobre ataques GSM, 2G, 3G y LTE

Los días 24 y 25 de Noviembre, en Sevilla, tendrá lugar una nueva edición de la SecAdmin Conference, en la que tendrás los libros de 0xWord para poder adquirirlos firmados por nuestro compañero Pablo González. Además, entre la lista de los ponentes - que es enorme e impresionante - estará también Pablo San Emeterio, CSA de ElevenPaths. Toda la información en la web: 

Figura 5: SecAdmin Conference 2017 en Sevilla

Y por último, en Madrid, los días 24, 25 y 26 tenemos un hackathon muy especial sobre BlockChain en Madrid, dentro de OpenFuture. Mañana os dejo más detalles en el post del domingo.

Figura 6: Blockchain challenge en Madid

Además de estos eventos, nuestra CEO de LUCA D3, Elena Gil, participará los días 22 y 23 de Noviembre en el 9º Congreso Nacional de Crédito en Barcelona. Y esto es todo lo que os traigo para esta semana, espero que disfrutéis el fin de semana.

Saludos Malignos!

viernes, noviembre 17, 2017

Cómo integrar Latch Cloud TOTP en aplicaciones #NodeJS (& .NET)

La charla de esta semana en las CodeTalk For Developers que hacemos en ElevenPaths ha versado sobre cómo sacare más partido a Latch, al tiempo que fortificas tus aplicaciones web. En este caso, hemos elegido los sistemas de Latch Cloud TOTP para fortificar las identidades que son utilizadas en aplicaciones NodeJS y .NET.

Figura 1: Cómo integrar Latch Cloud TOTP en aplicaciones NodeJS (& .NET)

La tecnología NodeJS se ha puesto muy de moda, gracias a su versatilidad y comodidad en el desarrollo de aplicaciones, tanto web como escritorio, así que hemos decidido dedicar una sesión para los amantes del código para que integren sistemas de Time One-Time Password server side, que estén sincronizados con Latch Cloud TOTP.

Figura 2: CodeTalk sobre Cómo integrar Latch Cloud TOTP en apps NodeJS (& .NET)

El seminario tiene una hora y media de duración, así que relájate, disfruta, y si has programado ya alguna app en NodeJS o .NET no te la pierdas. Verás lo rápido que se puede mejorar la seguridad de tus aplicaciones con Latch Cloud TOTP.

Saludos Malignos!

jueves, noviembre 16, 2017

Libro gratuito: Ciberseguridad "Una estrategia informático/militar"

Nuestro compañero Alejandro Corletti Estrada ha publicado un nuevo libro, en este caso una obra de 245 páginas, que propone un enfoque relacionando temas militares con su forma de implementarlos a través de los diferentes protocolos de telecomunicaciones para lograr una adecuada estrategia de "Ciberdefensa".

Figura 1: Libro gratuito: Ciberseguridad "Una estrategia informático/militar"

El libro se publica bajo licencia Copyleft para su descarga gratuita en formato electrónico y libre uso en actividades docentes sin fines de lucro. En su versión impresa sí tiene coste, y puede solicitarse en la dirección info@darFe.es o comprarlo vía este enlace: Comprar Libros en DarFe. En este vídeo tienes una presentación de la obra, que cuenta con un prólogo de Julio Ardita.


Figura 2: Presentación del libro

Por último, si lo quieres descargar, además de hacerlo desde la web de DarFe donde se encuentran otros libros para estudiar, puedes acceder a él vía esta publicación en SlideShare.


En el vídeo, el autor hace hincapié en el capítulo final que es una especie de resumen gráfico del libro, pero lo mejor es que te leas el libro y saques tus propias conclusiones.

Saludos Malignos!

miércoles, noviembre 15, 2017

#Metasploit: Automatizar scripts con msfrpcd y msfrpc

Llevaba tiempo queriendo echar un vistazo a los binarios msfrpcd y msfrpc que vienen con Metasploit Framework. Son dos binarios que para muchos están ahí, pero que si no toca automatizar nada no tenemos ni en la cabeza o, ni siquiera, hemos probado alguna vez. Hoy vamos a hablar sobre la automatización de acciones en Metasploit utilizando para ello RPC.

Figura 1: Metasploit: Automatizar scripts con msfrpcd y msfrpc

Si vamos al Github de Metasploit podemos encontrar información sobre RPC y la interacción con el framework y la instancia del "objeto framework" de Metasploit. Además, y como vamos a ver, es muy intuitivo y sencillo, por lo que ‘a pelo’ podemos hacer automatizaciones en scripts.

Rapid 7 ha publicado documentación de la RPC API, la cual si no la conoces te recomiendo que le eches un ojo. Al final, podrás llevar a cabo cualquier acción sobre el framework desde tu script de forma remota, consiguiendo la automatización de tareas en un Ethical Hacking. Y si lo que te gusta es el código, puedes ir directamente a los recursos o código fuente que hay en el Github oficial.

Figura 2: Framework de Metasploit en GitHub

Para ejecutar el daemon de msfrpc utilizaremos el binario msfrpcd. Con este binario podemos configurar una contraseña para que nadie pueda conectarse si no la sabe. Se puede configurar SSL para que la conexión fuera protegida. Incluso, podríamos ‘currarnosconfigurar Latch en Metasploit, al menos para la parte del servidor RPC. Para ejecutar el demonio en nuestro Kali Linux lanzamos la instrucción que se puede ver en la imagen.

Figura 3: Ejecución de msfrpcd

Una vez tenemos lanzado el demonio, deberemos conectarnos desde el cliente, en este caso el binario msfrpc. Decir que para este ejemplo se ha utilizado otra máquina Kali Linux para llevar a cabo la conexión remota al framework de Metasploit. El binario msfrpc se conectará al servicio RPC remoto a través de la siguiente instrucción msfrpc –P [contraseña] –a [dirección IP remota del servidor].

Una vez conectamos con el servicio RPC nos encontramos que obtenemos un objeto RPC. Con este objeto podemos realizar cualquier llamada e interacción con el framework como si estuviéramos en local. Es decir, podremos utilizarlo para automatizar cualquier acción. Da para otro post indicar que existe una gran cantidad de librerías en Ruby, Python y otros lenguajes, que permiten interactuar a través de RPC con Metasploit. Abstrayendo al desarrollador, pero hoy queremos bajar al nivel bajo de la cuestión.

Para ejemplificar una primera llamada muestro el método call del objeto rpc. Si nos fijamos podemos realizar acciones introduciendo una serie “comandos” en el interior del método. Realmente no son comandos, son métodos del objeto remoto. Otra función que estamos probando es module.info. Esta función o método pertenece al objeto remoto module.

Figura 4: Objeto module

Como podemos ver el juego es sencillo. Mirar la documentación o el código de cada clase y ver qué métodos existen para que a través del objeto rpc puedan ser invocados.

Explotando una vulnerabilidad desde RPC

Para seguir con el ejemplo, configuramos una llamada a module para que ejecute el método options. Los parámetros para esta acción, como puede verse en el código de Github de Metasploit, son rpc_options(mtype, mname), dónde mtype indica el tipo de módulo del queremos las opciones y mname indica el nombre/ruta del módulo. En este caso debemos ejecutar la instrucción rpc.call(module.options', 'exploit', [nombre del módulo]). Siendo ‘exploit’ el valor de mtype y [‘nombre del módulo’] el valor de mname. A continuación, se muestra un ejemplo de esto.

Figura 5: Invocación del exploit via rpc.call

Se obtienen las diferentes opciones. Esto puede ser almacenado fácilmente en una variable, por ejemplo, ejecutando var = rpc.call(module.options', 'exploit', [nombre del módulo]). Como vemos que el tipo que se retorna es un hash, se puede acceder fácilmente a los campos mediante las key, por ejemplo, var[‘WORKSPACE’].

Figura 6: Acceso vía variables

Vuelvo a hacer hincapié en la importancia de mirar la documentación o el código directamente de las funciones y clases de la parte de RPC. Sabiendo el uso básico de Metasploit y mirando la documentación se puede hacer, prácticamente, cualquier cosa de forma remota.

En la propia documentación del Github de Metasploit podemos encontrar ejemplos que pueden ser utilizados para comenzar. Como vemos, antes de cada función encontramos los parámetros de cada método y el tipo de dato que se retorna, incluyendo también información sobre las excepciones que puede dar.

Figura 7: Documentación en GitHub de Metasploit

Para finalizar, vamos a configurar en una máquina Windows 7 un servidor FTP Utility, el cual podéis encontrar en Exploit-DB su binario vulnerable y montarlo en vuestro laboratorio para las pruebas. Además, utilizando la conexión RPC vamos a configurar una variable llamada opts con los parámetros típicos de configuración del módulo de explotación, como son: LHOST, LPORT, PAYLOAD o RHOST. Esto es lo que he comentado antes, es la parte básica del uso de Metasploit.

También hay que indicar que, previamente a la configuración de la variable opts debemos utilizar un módulo que recoja las posibles sesiones que consigamos, si la explotación funciona. Para ello hay que ejecutar:
• Opts={“LHOST”=>[IP], “LPORT”=>[PORT], “PAYLOAD”=>[El que se quiera]} 
• Ahora ejecutamos el módulo multi/handler: rpc.call(‘module.execute’, ‘exploit’, ‘multi/handler’,opts)

Figura 8: Configuración de opts y ejecución de exploit para FTP Utility

Tras ejecutar la configuración y lanzamiento del módulo se puede obtener una sesión si la máquina es vulnerable. Ejecutando la función session.list podemos encontrar la sesión obtenida, tal y como se puede ver en la imagen. Lo importante es quedarse con el identificador para poder lograr interactuar con ella más adelante.

Figura 9: Lista de sesiones

Para finalizar el ejemplo, podemos utilizar session para interactuar con Meterpreter. En la imagen vemos como con la función meterpreter_write escribimos por el identificador de la sesión correspondiente, mientras que si queremos leer los resultados debemos ejecutar meterpreter_read. Es realmente sencillo y potente.

Figura 10: Sesión vía Meterpreter

Como se ha mencionado anteriormente, existe la posibilidad de utilizar librerías que abstraen de todos los detalles, pero quizá lo interesante es conocer lo que hemos visto por debajo. Quizá otro día hablemos de las librerías que existen o mostremos un pequeño ejemplo de automatización gracias al uso de este tipo de llamadas.

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 14, 2017

Path 2 (Latch) y Path 4 reciben las patentes en USA

Una de las características de ElevenPaths es la innovación. Está en nuestro ADN desde el día que comenzamos a hacer tecnología aquel pequeño grupo de apenas veinte personas que junté para disfrutar con la tecnología. La dinámica de trabajo con la que empezamos a movernos se dividió entre los productos que venían de Informática64 (MetaShield Protector & FOCA - esta última la evolucionaríamos a Faast -) y la creación de nuevas líneas de innovación.

Figura 1: Path 2 (Latch) y Path 4 reciben las patentes en USA

Durante el primer año y medio abrimos cinco líneas de investigación, a las que llamamos Path 1, Path 2, Path 3 y Path 4. En aquel momento buscábamos que todo lo que pudiera salir de ellas acabara en patentes que ayudarán a la creación de nuevos productos dentro de Telefónica.

Figura 2: Patent Wall of Fame 2013 en Telefónica con compañeros de ElevenPaths

El proceso de las patentes es algo engorroso y que generalmente se hace de forma defensiva, sobre todo si planeas que tus productos lleguen a mercados tan complicados como el de Estados Unidos, pero con paciencia y trabajo depositamos las patentes Path 2 y Path 4, ya que en la fase de investigación tuvimos que abandonar Path 1 y Path 3.

¿Qué pasó con los primeros Paths?
- Path 1 lo abandonamos porque vimos que no tenía recorrido comercial y que lo que debíamos hacer era movernos rápidamente a nuevas ideas. Descubrimos que había empresas que hacían cosas similares a lo que pretendíamos hacer con muy poco éxito - y algunas de ellas murieron al poco -, así que con pena, nuestro primer proyecto se fue al cajón
- Path 2 se convirtió en Latch, una de los servicios estrella de ElevenPaths que seguimos viendo crecer día a día y que cada vez tiene más usuarios, plugins, integraciones y relevancia. Poner pestillos para controlar las tecnologías es parte de la historia de ElevenPaths. Depositamos las patentes correspondientes para proteger la tecnología. 
- Path 3 también hubo que abandonarlo. Descubrimos que había patentes que protegían para otras empresas lo que nosotros queríamos hacer y no tenía sentido que nos embarcáramos en este proyecto ya que íbamos a enfrentarnos a posibles problemas de competencia. Además, si ya hay alguien que lo está haciendo, no era necesario que lo hiciéramos en ElevenPaths. Nuestra idea era focalizarnos en "Tecnologías que nadie está haciendo, o que nosotros pudiéramos hacer de forma distinta o mejor". 
- Path 4 fue una de esas tecnologías que nosotros podíamos hacer de forma distinta, y aportar una solución novedosa para proteger los sistemas. Sin embargo, cuando llegamos a la fase de producto vimos que no era el momento de lanzarlo, así que lo dejamos solo en una patente para pensarnos si desarrollar la tecnología completa en un futuro.
A finales de aquel primer año habíamos depositado patentes de Path2 y Path4 en ElevenPaths y estaban en fase A1, es decir, depositadas y en proceso de revisión en Europa y Estados Unidos. Este último mercado el más difícil y agresivo de todos.

Figura 3: Patente de Path 4

Así que comenzamos el proceso que nos ha llevado un largo periodo de tiempo de defensa de la innovación, pero a día de hoy  Path 4 tiene su patente concedida y Path 2 también - aunque aún no se ha actualizado en todas las webs -.


Para todos los que estuvimos involucrados en los inicios de ElevenPaths ver como de las ideas iniciales que planteamos sobre la mesa se han ido cumpliendo los plazos, y siguiendo la senda que nos marcamos desde el principio es algo que da mucha satisfacción. Aún mantenemos ese espíritu y seguimos implicados en innovar y patentar nuestras tecnologías todos los años. Gracias a todos los que creísteis en ElevenPaths al inicio. 

Saludos Malignos!

lunes, noviembre 13, 2017

Mensajes cifrados, Mensajes ofuscados: Skrypted, Esteganografía & Estegoanálisis

Los sistemas de comunicaciones seguras son unos de los más analizados por los equipos de seguridad de todas las compañías. Por supuesto, en ElevenPaths esta es una línea de trabajo desde el día en que comenzamos a andar, y por ello mantenemos líneas de investigación permanentes. Hoy os traigo un par de referencias a cosas que en las que hemos trabajado, unas referentes a sistemas de comunicación cifradas y/o ofuscadas usando esteganografía y estegonanálisis y otra referente a la protección y cifrado de mensajes cuando estos están en el equipo.

Figura 1: Mensajes cifrados, Mensajes ofuscados: Skrypted, Esteganografía & Estegonálisis

La primera de las referencias es una charla que hemos impartido dentro de nuestros ElevenPaths Talks en la que analizamos el funcionamiento y el estado del arte de las herramientas y técnicas utilizadas en covert channels, tan conocidas en el mundo de la Esteganografía y el Estegonanális, que nosotros tocamos ya en el libro de 0xWord.


Figura 2: ElevenPaths Talks 3: Esteganografía & Estegoanálisis

La segunda de las referencias es una solución que añade una capa de cifrado a los mensajes de las conversaciones de Skype que tenemos almacenadas en el equipo. Éstas, por defecto, se almacenan sin ningún tipo de cifrado, y dentro de uno de nuestros Equinox, el equipo del Laboratorio de ElevenPaths desarrolló Skrypted, una pequeña herramienta que permite cifrar los mensajes.

Figura 3: Skrypted para descargar

Su fucionamiento se ha explicado en el blog de ElevenPaths, pero puedes ver un claro ejemplo de cómo se utiliza en este vídeo que os he subido a Youtube, donde se ve paso a paso cómo se roba una base de datos de Skype con un simple fichero Excel malicioso y cómo ésta se encuentra protegida.

Figura 4: Funcionamiento de Skrypted

Tienes la explicación completa de todo el proceso de robo de la base de datos usando un Excel malicioso, cómo la base de datos se cifra y se protege, en la charla que el equipo del Laboratorio de ElevenPaths impartió durante nuestro Security Innovation Day 2017.


Figura 5: Innovation "A path to success"

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