OSINT: Localizar personas con Shodan usando "Banner Grabbing"

A estas alturas del año suelo, como tanta gente, echar la vista atrás y pensar en cuanto viví en los últimos doce meses. Pero esta vez las circunstancias me han obligado a reflexionar sobre lo que la ciberseguridad me ha dado desde que, allá por 2008, Chema Alonso y yo escribimos aquel artículo sobre “Metadatos en Microsoft Office” e iniciamos un camino que nos llevaría a concebir herramientas como FOCA o Metashield Protector.

Figura 1: OSINT - Localizar personas con Shodan usando "Banner Grabbing".

Imagen hecha con Dall-e 2 (A happy hacker in Picasso style)

A mi cabeza han acudido recuerdos de la Black Hat y la gente con la que la compartimos. De tardes enteras que pasaron como un soplo mientras yo trataba de terminar el libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex". De charlas. De la fascinación que experimenté mientras descubría cosas nuevas (nuevas, al menos, para mí). De las ganas de transmitir aquello que estaba viendo.

Figura 2: Enrique Rando y Chema Alonso en la Open Source World Conference 2008

presentando OOMetaExtractor para analizar metadatos de OpenOffice.

No sé por qué. Pero me quedé un rato pensando en un par de debates organizados por Yolanda Corral en su programa “Palabra de hacker” en los que participé. Uno era sobre “OSINT y hacking con buscadores” y allí me encontré con Vicente Aguilera, Rafael Otal, Miguel Ángel Cotanilla y John Jairo Fernández. El otro se titulaba “¿Qué es Shodan? El buscador, al descubierto” y en él compartí un rato con Eduardo Sánchez, Jorge Coronado y Miguel Ángel Arroyo. 

Figura 3: Libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex"

de Enrique Rando, publicado en 0xWord.

No sé en cuál de los dos nos preguntó Yolanda  qué era lo que más nos había sorprendido encontrar. Lo que sí recuerdo fue mi respuesta: localizar personas en Shodan. Bueno, personas, en realidad, no, pero sí sus nombres y apellidos y, en algunos casos, su dirección. Y es que los servicios técnicos de algunas operadoras ponían por entonces esa información en los "banners" de varios de los servicios de los routers de sus clientes. Supongo que para asegurarse de que no se conectaban al equipo equivocado.

Localizar personas con "Banner Grabbing"  

Hoy en día esos resultados son mucho menos frecuentes. Quizá porque se configure mejor los servicios. Quizá porque se expongan menos. Pero aún es posible encontrar algunos. Por ejemplo, en las cabeceras del protocolo FTP.

Figura 4: Servicio FTP (¡FTP!) con el nombre y la dirección

de una persona en su banner

… o en los mensajes que se muestran al pedir credenciales de acceso:

Figura 5: Autenticación para la administración que identifica al cliente

Pensándolo bien, esta reducción el número de resultados quizá se deba a que la tecnología ha evolucionado y ya no es habitual conectarse al router mediante FTP o Telnet. Si esta es la razón… ¡tenemos un problema! Porque la tecnología cambia rápidamente, pero las personas no. Y posiblemente terminemos cometiendo viejos errores con nuevas herramientas.

Figura 6: Hacking Web Applications: Client-Side Attacks
de Enrique Rando, publicado en 0xWord.

Por ejemplo, muchas organizaciones publicaron en Internet servicios de Escritorio Remoto cuando la pandemia de COVID-19 nos obligó a confinarnos y se produjo aquel boom del teletrabajo. Pantallas de inicio de sesión comenzaron a ser recogidas por Shodan y más de una mostraban la plantilla completa de un centro de trabajo o una organización:

Figura 7: Todos los compis de la oficina tienen cuenta en este equipo.

Y Shodan lo sabe.

Y, volviendo a los servicios técnicos de algunas operadoras, si aún siguen necesitando tener seguridad de que no tocan el equipamiento equivocado o la línea de una persona distinta de la que tienen al teléfono, no será raro que haya quien solucione el problema a la antigua usanza.

Figura 8: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

 
Pero parece que con el equipamiento actual es mejor hacerlo en otros puntos. Quizá en la configuración de la conexión punto a punto sobre Ethernet (PPPOE) de la operadora con cada cliente, donde es posible realizar de forma sencilla una gestión centralizada del enlace. Así que… ¿por qué no hacer en Shodan una búsqueda del tipo “pppoe garcia” o “pppoe juan”?

Figura 9: No sé por qué, pero separan los apellidos del nombre con una arroba @

En definitiva: como siempre, lo de siempre. Y esta es solo la parte que Shodan ve. No os robo más tiempo por hoy. Quizá otro día haya ocasión de hablar de los sistemas de vídeo-vigilancia que gestionan varias cámaras y etiquetan cada una con el nombre de la calle que monitoriza...

PD: Aunque no sé cuándo se publicará, ni si se publicará, escribo esto el 31 de diciembre. Así que os deseo que en el nuevo año no haya un segundo que no viváis con ilusión por el siguiente. Que vuestros días se os hagan cortos porque estéis haciendo lo que os apasiona con la gente que queréis. Y que los meses os parezcan largos cuando recordéis vuestros logros.

Autor: Enrique Rando González.

Contactar con Enrique Rando

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]

Me encanta The Punisher. La tengo que ver a escondidas de mi Hacker & Survivor, que se asustan }:)

A post shared by Chema Alonso (@chemaalonso) on Nov 19, 2017 at 10:21am PST

[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!

Conquistar el mundo con OSINT & Known-Vulnerabilities (PARTE 2 de 2) #OSINT #Metasploit

Continuando con la primera parte de este artículo sobre cómo "Conquistar el mundo con OSINT & Known-Vulnerabilities", vamos a ver en esta parte la automatización del proceso completo para terminar con una Prueba de Concepto ficticia de lo que se podría realizar. Vamos a ello.

Figura 7: Conquistar el mundo con OSINT & Known Vulnerabilities (Parte 2)

¿Dónde están las máquinas?

Una de las ideas de esta prueba de concepto era poder demostrar que las máquinas víctimas podrían estar distribuidas por países. Esto demostraría que disponer de máquinas en distintas ubicaciones geográficas aporta un poderío y una ventaja al atacante. Para procesar la información y obtener la geolocalización de las máquinas que nos interesan se desarrolló un script que mediante un servicio similar a ip2location nos permite obtener esta información.

Figura 8: Obteniendo la localización

Como puede verse los valores que se almacenan son:

• La dirección IP de la máquina.
• El país dónde se encuentra la dirección IP.
• La región / ciudad dónde se encuentra la dirección IP.
• El código del país.
• El fichero / software dónde se encontró la máquina.

Una vez realizado todo este proceso se pueden sacar algunos datos curiosos. Por ejemplo, la aplicación PcMan FTP 2.0.7, la cual el texto de su interfaz está en algún idioma asiático solo tiene presencia en Taiwan. Lo más curioso es que si echamos un vistazo a exploit-db con la siguiente búsqueda nos daremos cuenta de que ese software tiene muchos agujeros. Por cada comando del FTP hay un Buffer Overflow, y uno se pregunta… ¿Este software está puesto ahí adrede o es casualidad?

Figura 9: Exploits en versiones de PCMan's FTP

Bien, tras analizar por encima diversos datos y ver que se cumplía uno de los objetivos de la prueba de concepto que era ver máquinas distribuidas por el mundo, debía realizar un script que me cogiera solo las direcciones IP para, a posteriori, poder crear el mapa gráfico. El script encargado de recolectar direcciones IP con sus códigos de país fue denominado xoxo2ip.rb. Este script facilitaba mucho la tarea de generateMap.rb, el cual utiliza un servicio online que nos presenta el mapa.

Figura 10: Script generateMap.rb

En la imagen anterior podemos ver la salida del script generateMap.rb, el cual me devuelve una dirección URL a la que podemos acceder para visualizar el mapa gráfico. Como se puede ver en el gráfico, dispondríamos de máquinas en una gran cantidad de países.

Figura 11: Ubicación de las máquinas localizadas

Como curiosidad, y por si alguien piensa en irse a la isla de Barbados, allí salía una máquina con software vulnerable. ¿La localizáis?

Hablemos del módulo: exploit_massive

Mi idea era automatizar desde un único nodo central el lanzamiento de exploits que se aprovechan de las vulnerabilidades conocidas. La forma más sencilla de llevar a cabo esto era aprovechar Metasploit para la PoC. Recordemos que en Metasploit ya existía algo similar denominado autopwn, y sigue existiendo un browser_autopwn. Mi idea era retomar la idea del mítico autopwn pero enfocado a algo que me sirviera en esta PoC.

El diseño de mi módulo es sencillo y lo puedo explicar en diferentes pasos. Todos quedáis invitados a mejorar la funcionalidad y mejorar el propio código. A continuación un resumen de lo que se hace en el módulo:

• El módulo cuando se ejecute la función exploit leerá de un fichero comentado anteriormente la información que tiene que configurar. Hay que recordar que el fichero contiene información sobre las direcciones IP, módulos de tipo exploit a utilizar, puertos dónde los servicios vulnerables escuchan, tipo de payload, etcétera.

• Por cada línea es un target distinto. De este modo cada línea es procesada en el cuerpo de la función exploit.

• La ruta del fichero se especifica a través de un atributo básico definido por nosotros, mediante el uso del mixin register_options. El atributo se denominó FILE_HOSTS.

• Otro atributo, en este caso tipado de avanzado, es el de UPGRADE. Este atributo admite 2 valores, true o false. Si el atributo avanzado se configura a true, cuando el módulo detecte una sesión que es de tipo shell, y no Meterpreter, se realizará un upgrade automático a una Meterpreter. Es una funcionalidad muy interesante, ya que de primeras algunos módulos no admiten un Meterpreter, por ejemplo el módulo unix/ftp/vsftpd_234_backdoor.

• El módulo proporciona información sobre la línea o target sobre el que se está lanzando el exploit. Se puede visualizar en la consola información como el host, el módulo del exploit que se está lanzando, el puerto remoto y el payload que se utilizará en caso de que la explotación se consiga.

Visto esto ahora comienza la parte iterativa. Por cada línea que se lee y se parsean los parámetros se debe configurar una variable denominada datastore. Esta variable almacena los valores de atributos como RHOST, LHOST, PAYLOAD, etcétera. En otras palabras todos los atributos o variables que pueden ser configurados desde la línea de comandos cuando tenemos cargado un módulo.

Por cada iteración debemos instanciar el módulo que se quiere utilizar, por ejemplo si el Target 1 es un servicio FTP con ProFTPd 1.3.3c se instanciará el módulo de tipo exploit para dicho software. Para llevar a cabo la instanciación se utiliza el objeto framework en el código. Este objeto permite al desarrollador utilizar y referenciar cualquier acción que se pueda llevar a cabo desde la línea de comandos. De este modo utilizaremos framework.modules.create([módulo exploit]) para instanciar de forma iterativa los módulos. Como se dijo anteriormente, por cada iteración hay que configurar varias cosas con los parámetros que se pasan a través del fichero hosts que nombré anteriormente.

Figura 12: Procesamiento de fichero de objetivos y configuraciones a realizar

Se utiliza el método check_simple para por cada módulo leído que se lanza contra un Target comprobar si la máquina remota sería vulnerable al exploit. La variable message almacena el resultado de la ejecución del método para posteriormente mostrarse al usuario por pantalla.

Una de las cosas más importantes es la ejecución del método exploit_simple, el cual recibe una serie de parámetros que son los atributos que queremos configurar, por ejemplo Target por defecto, datastore[‘PAYLOAD’], etcétera. El lanzamiento del método exploit_simple puede provocar la obtención de una nueva sesión, la cual será almacenada en la variable session_shell, tal y como puede verse en el código.

Figura 13: Lanzamiento de exploit por Target

Una vez lanzado el módulo y obtenida la sesión se comprueba si existe el cuarto parámetro, el cual reflejan atributos avanzados que puede contener el módulo de Meterpreter. El cuarto parámetro puede contener diversos atributos avanzados separados por comas. Cada elemento contiene una clave o key y un valor separados por ‘:’. Como se puede ver en la línea datastore[key] = value, permite configurar valores dentro del módulo.

Figura 14: Configuración de atributos por claves

Los atributos como InitialAutoRunScript y AutoRunScript nos permite ejecutar instrucciones automáticamente una vez la Meterpreter se encuentra ejecutándose. De este modo hay que tener en cuenta que realizar un pequeño script el cual ejecute automáticamente las instrucciones necesarias para subir binarios que “troyanizasen” dichas máquinas sería algo muy sencillo.

Figura 15: Ejecución de módulo de post explotación

 Por último hay que hablar de si la sesión que se consigue no es una Meterpreter y sí es una shell. En este instante si el atributo avanzado UPGRADE se configura como true se subirá automáticamente a través de la sesión de la shell. Esto se puede realizar gracias al módulo de post-explotación post/multi/manage/shell_to_meterpreter.

PoC: Escenario ficticio

Para la prueba de concepto se presenta un entorno multiplataforma. Es cierto que lanzar el módulo en un entorno real sería ilegal, y no es el objetivo de dicho módulo. El objetivo es que sea utilizado en auditoría y ayudar al pentester a simplificarse el trabajo. El escenario montado es el siguiente:

• En una máquina con Metasploit se lanzará el módulo. Esto es lo que llamamos el nodo central de la operativa.
• Habrá un sistema Windows 7 SP1 con un servidor HTTP de los evaluados en el estudio.
• Habrá un sistema Windows XP SP3 versión ingles con un servidor FTP, sí el de Taiwan que comenté anteriormente.
• Habrá un sistema Linux con un servidor FTP vulnerable.

Lo que se pretende con estas 3 muestras es reflejar la realidad de los entornos y el uso de aplicaciones o servicios vulnerables hoy día. Ahora, configurando módulo para lanzar el ataque masivo con el mínimo esfuerzo.

Figura 16: Configuración de módulo para lanzar ataque masivo

También se puede configurar el atributo UPGRADE para que en el caso del sistema Linux podamos ejecutar una shell y posteriormente un Meterpreter. Esto ocurre porque si vemos el detalle del módulo unix/ftp/vsftpd_234_backdoor, no proporciona la posibilidad de inyectar una Meterpreter directamente.

Ahora simplemente hay que ejecutar exploit y esperar a que las sesiones vayan llegando. Cómo es lógico, una mente maliciosa haría que en el atributo InitialAutoRunScript y AutoRunScript se ejecutase una instrucción que permitiese troyanizar la máquina, pero eso lo dejamos para otra vez.

Figura 17: Ejecución de exploit masivo

Como puede verse en la imagen, por cada línea del fichero hosts del módulo se irán lanzando módulos con la configuración especificada. El resultado final lo podemos imaginar, aunque no todas las máquinas fueran vulnerables, aplicando una ley del 50% de las encontradas con scans.io, podríamos hablar de una botnet de más de 25.000 máquinas con el mínimo esfuerzo. Al final, la verdad está ahí fuera, ya lo decía la gente de Expediente X.

Figura 18: Sesiones obtenidas en equipos vulnerables

Se pueden ver las sesiones logradas en esta prueba de concepto. Al final fue bastante divertido “trastear” con Metasploit y sus tripas en Ruby. Os animo a probar el módulo y seguir avanzando y mejorando sus versiones. ¡Diviértete!

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”
PD: Este artículo está dedicado a ti, hacker.

Conquistar el mundo con OSINT & Known-Vulnerabilities (PARTE 1 de 2) #OSINT #Metasploit

Hace unas semanas tuve la suerte de estar en el congreso Albahaca CON 2015 celebrado en Huesca. La ponencia que tenía un título parecido a "¿Cómo los chicos malos pueden conquistar el mundo?" En honor al inglés del gran Rafa Otal, es una idea sencilla basada en las fuentes abiertas de información y procesamiento de ésta con el objetivo de encontrar máquinas distribuidas por el mundo que contengan software vulnerable. Una de las preguntas que podemos hacernos es, ¿Qué es exactamente conquistar el mundo? Pueden ser muchas cosas, pero para algunos usuarios podría definirse como la posibilidad de tener mucha presencia, gran capacidad de cómputo y tener todo esto de manera distribuido alrededor del mundo. Con este fin es difícil parar o bloquear a este ejército cibernético.

Figura 1: Conquistar el mundo con OSINT & Known-Vulnerabilities (Parte 1 de 2)

El vector de partida en esta investigación son las fuentes OSINT, las cuales proporcionan gran cantidad de información. La pregunta de la charla es:

¿Si procesáramos las fuentes de forma adecuada obtendríamos información sensible la cual podría ser utilizada para obtener el control de un gran número de máquinas distribuido? 

La vía para tomar el control de las máquinas está claro que podría ser un exploit público. ¿Existirán muchas vulnerabilidades conocidas? Ésta es una pregunta de difícil respuesta, al menos podemos intuir que sí, pero a ciencia cierta es complejo decir si mucho o poco. Entonces, ¿qué queremos comprobar?

1. Encontrar las fuentes de información abiertas que pueden proporcionar información sobre software y máquinas en Internet. 

2. Listar para el caso particular un número de software y versiones concretas. 

3. Procesar esta información con el fin de detectar software no seguro y para el que existe un exploit público que permitiría a un usuario malicioso tomar el control de las máquinas. 

4. Una vez detectadas las máquinas con software vulnerable se necesita una herramienta que permita demostrar cómo se podría tomar el control de las máquinas. Para esta ocasión se quiere ejecutar un módulo de Metasploit implementado por mí para hacer algo muy similar a lo que hacía el famoso autopwn. 

5. Las máquinas, ¿Dónde están? La geolocalización es fácil de realizar. Nos interesa demostrar la distribución de las máquinas, por lo que se puede obtener el país y provincia dónde se encuentra la máquina. Esto nos proporciona la posibilidad de realizar un mapa distribuido, que siempre ayudará a ver todo el impacto gráficamente.

Figura 2: Esquema de idea de trabajo

Análisis de OSINT y escaneos a IPv4

El primer paso en todo esto es verificar de dónde sacar la información que queremos procesar. En primer lugar uno siempre se dirige a Shodan si quiere realizar búsquedas de dispositivos. En Shodan podréis encontrar resultados asombrosos con software como Freesshd 1.2.6 instalado en más de 20.000 máquinas en todo el mundo. Utilizando un listado de otras aplicaciones con vulnerabilidades conocidas fui buscando más resultados en Shodan y todo hacía indicar que los números de máquinas serían grandes.

Otra alternativa que me planteé fue la de utilizar ZMap para barrer el direccionamiento de IPv4 y mediante la herramienta ZGrab poder detectar máquinas con servicios vulnerables en Internet. Para el que no conozca ZGrab solo decir que la herramienta realiza una conexión al puerto en cuestión y nos permite almacenar el banner del servicio. En muchas ocasiones los servicios FTP, por ejemplo, nos proporcionan en el propio banner la información necesaria para detectar la versión. Hay que tener en cuenta que en otras ocasiones el banner que se puede leer de un servicio puede estar falseado, por lo que esta información no es 100% válida, aunque si nos permite hacernos una idea del número de máquinas que podríamos “trastear”.

Mientras pensaba en qué opción utilizar para obtener la información lo más en bruto posible mi compañero de Eleven Paths y amigo Rafa Sánchez me comentó un sitio web llamado scans.io. En este sitio podemos encontrar bases de datos gigantescas con diferentes scopes. Por ejemplo, encontré que cada mes realizan entre 3 y 4 escaneos a todo IPv4 con ZMap y ZGrab y publican los resultados de lo encontrado. Entonces recordé una de las cosas que me decían mucho los profesores en la Universidad: “reutiliza”. Así que pensé que utilizar estas bases de datos podría ser interesante.

Antes de seguir quiero dejaros qué tipos de bases de datos podemos encontrar en scans.io: escaneo completo a IPv4 con captura de handshakes en HTTPs, escaneos a IPv4 para detectar la vulnerabilidad de Heartbleed, escaneo completo a IPv4 con recopilación de banner grab, escaneos al primer millón de dominios de Alexa, escaneo completo a IPv4 y recopilación de servidores HTTP, certificados, etcétera. ¿Cuáles son las fuentes? Los escaneos son llevados a cabo por los equipos de Rapid7, Universidad de Michigan, Fedora Project, Project 25499, etcétera.

Cómo mencioné anteriormente vi que en scans.io existe un escaneo periódico, entre 3 y 4 veces mensuales, a los servidores FTP accesibles en IPv4 y que recolectaban los banners de dichos servicios. Decidí descargar unas cuantas versiones de las bases de datos, aunque cada una era entre 3 y 4 GB.

Procesar información de la base de datos y detección para estudio

Analizando el fichero json que nos descargamos de scans.io podemos ver qué campos son los que nos interesan. Accediendo al campo del banner y del host sabemos qué “escupe” el servicio cuando le preguntas y en qué dirección IP se encuentra. Para la ponencia fue interesante estudiar diferentes servidores FTP como son:

• ProFTPd 1.3.3c
• warFTPd 1.65
• WS_FTP Server 5.0.3
• WS_FTP Server 5.0.5
• PCMan FTPd 2.0.7

A priori, a muchos le sonarán de poco, pero para la prueba de concepto es más que suficiente. Todas estas aplicaciones son identificables por el banner que devuelven, aunque hay que recordar que existen honeypots que nos pueden engañar. Mediante el uso de expresiones regulares podemos ir detectando las versiones que se vuelvan en los banners y almacenándolos. La información recopilada por el primer script que se montó, denominado con un nombre original como procesar.rb, es la siguiente:

• Host
• Fecha
• Respuesta en la conexión (banner)

Además, el script cuando finaliza nos indica el número de máquinas que cumplen con las condiciones propuestas en la expresión regular.

Figura 3: Resultados del script tras procesar las expresiones regulares

Tras recopilar información sobre diferentes bases de datos de servicios FTP en IPv4 se pueden sacar algunas cosas en claro. Algo llamativo es la diferencia de máquinas entre los meses de Abril y Julio de 2015. En Abril de 2015 podemos encontrar con más de 14.000 máquinas que responden con banners de software vulnerable, asumiendo un 50% de falsos positivos, que pueden ser demasiados, podemos encontrar con más de 7.000 máquinas distribuidas vulnerables y que se encuentran a un “botonazo” para que cualquiera las pueda controlar, si no lo hacen ya.

Figura 4: Máquinas descubiertas en el escaneo de Abril de 2015

En el mes de Julio de 2015 se pueden encontrar en las bases de datos publicadas en scans.io más de 52.000 máquinas con alguno de los banners listados anteriormente. Se puede observar cómo las versiones de software vulnerables aumentan considerablemente. Quizá uno de los que más llama la atención sea el software ProFTPd 1.3.3c que incrementa los banners de 9546 máquinas a 35168.

Figura 5: Máquinas descubiertas en Julio de 2015

Procesar todas estas fuentes de datos OSINT a la vez, es decir, Shodan, Scans.io y los escaneos personalizados que se hagan para localizar los objetivos y los exploits que hay que ejecutar es una tarea perfecta para hacerlo usando Sinfonier. Con este proyecto - que puedes utilizar libremente en la versión Community -, puedes hacer topologías que procesen la información constantemente y vayan realizando las acciones necesarias.

En este caso se podría haber utilizado para que fuera el orquestador que localice los objetivos analizando los repositorios OSINT, para ello se utilizan los componentes SPOUT, localizar el exploit público desde otra fuente o tirando de bases de datos internos con los componentes BOLT y sacando con DRAINS los resultados. Si quieres conocer más sobre Sinfonier, en la Comunidad de Eleven Paths se ha abierto un foro para Sinfonier con el objeto de que puedas aprender más. Si te animas, tienes el Sinfonier Community Contest para llevarte hasta 3.000 USD en Bitcoins haciendo cosas como esta.

Creando el nodo central de ejecución (Remake de autopwn?)

Una vez identificadas las máquinas candidatas debemos pensar en centralizar esfuerzos. La idea de un nodo central de ejecución de exploits con toda la información procesada previamente nació de centralizar esfuerzos. Es cierto que quizá disponer de varias máquinas en el mundo y poder distribuir esfuerzos para la consecución del control sería una táctica mejor, pero la idea de la prueba de concepto es hacerlo lo más sencillo posible.

En la charla muchos vieron en este módulo una idea similar al autopwn de Metasploit, el cual ya no se encuentra en la edición Community. La información procesada previamente se clasifica en un fichero de texto con un formato específico, el cual será leído por el módulo que realicemos. El formato definido es el siguiente:

• Cada línea del fichero representa una máquina vulnerable en Internet encontrada mediante el uso de las bases de datos OSINT. 

• Los valores que deben ser leídos y que muestran diferentes atributos están separados por pipes. 

• El primer valor indica la dirección IP de la máquina vulnerable. 

• El segundo valor indica el módulo de Metasploit que debe ser cargado y configurado automáticamente. 

• El tercer valor indica el puerto remoto dónde el servicio se encuentra a la escucha. Este valor se leerá y configurará en el módulo automáticamente por nuestro módulo. 

• El cuarto valor indica qué tipo de payload se ejecutará en caso de que la ejecución del módulo indicado en el atributo 2 sea correcta. 

• El quinto valor es opcional, pudiendo indicar atributos avanzados de los módulos, como por ejemplo InitialAutoRunScript, el cual indica que cuando se ejecute un Meterpreter se migre automáticamente de proceso.

Figura 6: Información para automatizar la explotación de las máquinas vulnerables

Más adelante se podrán ver más detalles sobre el módulo, ya que tiene algunos detalles a bajo nivel que son interesantes. Además, se puede encontrar en mi Github.

Continuará: Conquistar el mundo con OSINT & Known-Vulnerabilities (PARTE 2 de 2)

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

Cifra el almacén de credenciales de tus herramientas o se lo pondrás fácil a tu adversario

Cuando estás en un Departamento de Administración de Sistemas o en un equipo IT siempre tienes el problema de cómo gestionar las credenciales de todos los servicios de los que necesitas echar mano cada día. El número de equipos a los que te conectas, el volumen de credenciales que usas - muchas veces incluso compartidas entre un equipo técnico - y con la cantidad de herramientas distintas con que lo haces es tan grande que al final necesitas guardar las configuraciones con los distintos perfiles de conexión. Algo que te permita, una vez abierta la herramienta de administración correspondiente abrir una sesión con solo hacer clic sobre el perfil adecuado. Lo que sí que te tiene que preocupar en ese entorno es, ¿cómo se protegen los almacenes de tus perfiles de conexión?

Figura 1: Cifra el almacén de credenciales de tus herramientas...
o se lo pondrás fácil a tu adversario

Cuando un grupo atacante está tratando de hacer un APT contra una organización, lo más probable es que busque el punto de entrada más sencillo. Para eso, como ya hemos visto en muchos casos, el Phishing Dirigido o Spear Phishing es lo más sencillo. Conseguir engañar a una persona para robarle una credencial interna o lograr ejecutar un programa con los permisos de usuario en el sistema es lo más rápido para entrar en la red del objetivo.

Conseguir credenciales para pivotar en la red

Una vez que se está allí hay que conseguir hacer la elevación de privilegios dentro la máquina o conseguir credenciales de otros sistemas y para ello hay muchas formas de sacarlas. Una de las estrategias más cómodas es la directamente buscarlas en el equipo, como ya os publiqué en el artículo de "Buscando passwords en servidores". En ese artículo se podría ver cómo con hacer búsquedas en entre los ficheros locales y en el registro del sistema utilizando sencillos comandos del propio equipo se puede llegar a obtener un buen volumen de identidades. Muchas de ellas permitirán elevar privilegios dentro del sistema o conectarse a otros equipos.

Figura 2: Credenciales de perfiles de conexión en Filezilla en texto claro

Algunos casos que ya hemos visto en el pasado han sido las credenciales RDP o Citrix que necesitan un proceso de cracking pero permiten la conexión o los ficheros de configuración de las herramientas como iSSH o el Filezilla que las guardan en claro dentro de los archivos de configuración si no se usa una clave maestra.

Figura 3: Descifrador para las passwords cifradas en ficheros de conexión RDP

Las credenciales de WinSCP

Este también es el caso de WinSCP, una popular herramienta de Windows que permite conectarse a servidores FTP o SFTP, y que utiliza un archivo de configuración WinSCP.ini para almacenar todas las contraseñas de los perfiles de conexión. Estos ficheros de configuración se pueden localizar incluso en Internet por medio de un sencillo dork como éste, que me mandó mi amigo rootkit, un enamorado del hacking con buscadores.

Figura 4: Ficheros de configuración de WinSCP.ini en Google

La gracia de estos ficheros de configuración es que la credencial viene almacenada con un cifrado reversible, pero a diferencia de lo que sucede en Citrix o RDP, estas passwords no utilizan un algoritmo basado en el sistema operativo, lo que permite a cualquiera que acceda a un fichero WinSCP.ini con passwords puede llegar a extraer todas las credenciales. Para localiza un fichero con credenciales en Internet basta con añadir la palabra Password al dork y listo.

Figura 5: Ficheros WinSCP.ini con passwords

Crackear las credenciales de un fichero de configuración de WinSCP

Cuando vi el fichero por primera vez supuse que el proceso de cracking tal vez sería costoso, pero nada de eso. Una vez está descargado se puede utilizar la herramienta WinSCPPwd con él y conseguir en texto claro todas las conexiones que están almacenadas en este fichero de configuración, como en este ejemplo que he hecho yo.

Figura 6: passwords descifradas y conexiones de red almacenadas

La solución, como parte de una estrategia de defensa en profundidad frente a APTs en la organización, además de poner todas las medidas posibles, debe incluir que cualquier almacén de credenciales y conexiones esté correctamente cifrado con una contraseña maestra robusta, certificados digitales o que las conexiones que se usen siempre tengan identidades protegidas por un 2FA para evitar su utilización descontrolada.

Saludos Malignos!

Latch: Cómo proteger las identidades digitales (IV de IV)

Con el objeto de permitir que Latch sea tan flexible como quieran las entidades que hacen uso de él, se abrieron los SDK en los lenguajes C, .NET, Java, PHP, Python y Ruby. Lo que se persigue es que la flexibilidad sea máxima y se puedan crear usos distintos para Latch, como los que por ejemplo a continuación se van a exponer.

Figura 12: SDKs para utilizar Latch

Tienes acceso a todos ellos en la zona de Developer de la web de Latch y en este documento tienes explicado en detalle cómo utilizar el SDK de Latch para .NET para aplicarlo a cualquier sitio web desarrollado con esta tecnología y en este ejemplo cómo implementarlo en un servidor FTP.

Control Parental

Al final, el control de un Latch no da nunca acceso a la privacidad de la cuenta, así que el que tenga una persona el control del mismo no le permitiría tener la posibilidad de acceder al sistema. En un entorno de control parental, la idea es que la persona que tiene las credenciales puede mantener el control absoluto de la privacidad de la cuenta, pero la persona que decide si puede conectarse o hacer uso de algunas de las opciones de granularidad que vengan definidas - como se vio en la tercera parte de este artículo - será otra.

Por supuesto, para crear este esquema, la cuenta que es controlada por el Latch debe estar de acuerdo con esta protección, y una vez que sea así, su acceso está restringido al control partental.

Figura 13: Esquema de Control Parental con Latch

Este control parental no sólo está pensado para Tutor Legal -> Hijo/a, sino también para entornos de identidades delegadas en las que se ha cedido el uso de las credenciales por necesidad del negocio. Por ejemplo, en casos en los que un empleado tenga que entrar a gestionar las cuentas bancarias de una empresa u otro servicio. El administrador o supervisor, podrá restringir el acceso completo a la misma o a las opciones de ella mediante el control del Latch.

Verificación de 4 ojos

Un esquema que nos solicitó uno de los clientes era el de aplicar Latch como un sistema de Verificación de seguridad de 4 y/o 6 ojos, poniendo para ellos latches cruzados que serían gestionados por otros empleados de la organización. Este esquema está pensado para sistemas críticos en los que hay que controlar los usos de los administradores.

Figura 14: Esquema de verificación en 4 ojos con Latch

El objetivo es que cada cuenta de administrador tiene uno o varios latches que están controlados externamente, de tal forma que siempre es necesaria la presencia de dos o tres personas para poder hacer una determinada acción.

Alerta y Reacción

En algunos entornos lo que se desea no es bloquear el acceso, si no tener la posibilidad de detectar una acción y tomar una medida reactiva. En un entorno en el que se hace un acceso SSH en el que se puede comprobar que alguien ha accedido con una cuenta, se podría comprobar si está el Latch cerrado o abierto, y en caso de estar cerrado tomar acciones, como podría ser la grabación de lo que está haciendo por pantalla o la desconexión de la sesión. Aquí tenéis la experiencia descrita por HackPlayers para fortificar SSH en modo paranoico.

Figura 15: Reacción a un Latch cerrado en una conexión SSH

En estos entornos la sesión inicial se establece, pero el dueño del Latch recibe la alerta y puede decidir qué hacer, como se hizo en el caso de SSH donde las sesiones son matadas.

Conclusiones

Al final, la idea abierta que subyace con Latch, en la que se diferencia totalmente entre una cuenta para gestionar los latches, que es independiente de la identidad protegida, independiente del número de teléfono móvil, y que no almacena ningún dato personal ni de acceso al sistema, permite toda la flexibilidad del mundo.

Para hacer mucho más fácil su integración, se han publicado plugins para Joomla, Drupal 6, PrestaShop, DotNetNuke, RedMine, WordPress y .NET Log in, pero esta semana sale una nueva remesa de plugins. En este artículo tienes cómo se configura en WordPress, aquí cómo se configura en Joomla, y este vídeo  te explica cómo hacerlo.


Figura 16: Cómo configurar Latch en Joomla
A día de hoy hay ya más de 400 sitios que están haciendo uso de Latch. Como el sistema es anónimo, nosotros no sabemos cuáles son. Se bajan el plugin, o usan el SDK y comienzan a proteger sus sitios. Si necesitas ayuda para implantarlo en tu sitio web, puedes ponerte en contacto con nosotros e intentaremos ayudarte.

Figura 17: Guía de Instalación de Latch en ACENS

Sí que puedes hacer uso de Latch en Acens - aquí tienes la guía de configuración, en 0xWord, Recover Messages y Nevele Bank - en todos ellos puedes sacarte una cuenta gratuita y probar cómo funciona - y en el Mobile World Congress os anunciaremos una buena lista de sitios grandes que están poniéndolo ahora en prueba. La app está disponible para iPhone, Android y Windows Phone, y en breve para Firefox OS y BlackBerry. Además, esta semana se subirán nuevas versiones con algunos bugs resueltos y sugerencias que nos habéis pasado.

Saludos Malignos!

************************************************************************************

- Latch: Cómo proteger las identidades digitales (I de IV)

- Latch: Cómo proteger las identidades digitales (II de IV)

- Latch: Cómo proteger las identidades digitales (III de IV)

- Latch: Cómo proteger las identidades digitales (IV de IV)

************************************************************************************