Proyectando un framework de seguridad para dispositivos de red

Hace un año y medio me reencontré con un antiguo amigo del barrio, Josué. Cuando lo vi me acordé de un chico delgado y tímido que estudiaba conmigo en el IES Juan Gris de Móstoles. Me interesé por él, por lo que había hecho con su vida y mi sorpresa fue que, tras contarme sus aventuras y su fase de emprendedor, había comenzado a estudiar en la Universidad Rey Juan Carlos. Cuando me comentó que había comenzado con un Grado en Informática me alegré. Josué me pidió alguna idea para realizar su TFG. Recuerdo darle algunas y la que más le gustó fue la de un framework modular para pruebas de seguridad en dispositivos de red que pudiera usarse en trabajos de ethical hacking, entendiendo dispositivos de red como switches o routers.

Figura 1: Proyectando un framework de seguridad para dispositivos de red

El TFG debía llevar una parte de seguridad, la cual ya era obvia con la idea, y una parte de ingeniería del software. Por ello, se debía escoger una metodología ágil y que se viera reflejado como se seguía esta. En concreto, se utilizó Scrum para llevar a cabo el proyecto. Según el diagrama UML del framework se tendría algo así:

Figura 2: Esquema del framework de ataques de red

Existen dos componentes diferenciados, el núcleo que se encargará de procesar comandos y datos que el usuario proporciona y una componente secundaria que son los módulos que implementan las diferentes pruebas. La interacción por parte del usuario con la herramienta se realiza a través de una terminal o consola escrita en Python. Josué se encargó de implementar una serie de comandos para poder interactuar con los módulos y poder lanzar las funcionalidades.

En la siguiente imagen donde se ejecuta el framework sobre un máquina Kali Linux se puede ver los comandos que admite la herramienta. Como se puede ver no hay un gran número de comandos, pero la flexibilidad que aporta es grande para en un futuro poder ir metiendo nuevos ataques a redes IPv4 & IPv6.

Figura 3: Comandos en el framework de ataques de redes

Recuerdo también alguna que otra tarde de bar dónde hablábamos de las funcionalidades y de las pruebas que debería tener la herramienta de cara a su Trabajo Fin de Grado y un posible uso posterior por otros usuarios. Tras debatir, entre cervezas, llegamos a la conclusión de que al menos la herramienta debería tener:

• Capacidades de Spoofing.
• Capacidades de recopilar información con técnicas como el Banner Grabbing.
• Capacidad para realizar fuerza bruta.
• Capacidad para realizar escaneos de puertos y servicios por sí sola.
• Capacidad de lanzar un exploit conocido contra un dispositivo de red. Por ejemplo, aprovecharse de un CSRF en el panel de gestión de un router. • Capacidad de poder crear módulos propios y extender la herramienta.

En la siguiente imagen, se pueden ver el número de módulos que Josué implementó para la versión de su TFG. Tengo que decir, que recuerdo a Josué “quejándose” porque yo no hacía más que decirle, este tiene que estar sí o sí, y este otro también...

Figura 4: Lista de módulos implementados en la versión actual

PoC: Probando el framework

En esta primera prueba de concepto del uso de esta herramienta se cargará un módulo llamado sshbruteforce. Con este módulo se puede realizar fuerza bruta mediante un diccionario a un servicio SSH. En el caso de que se consiguiera acceso al servicio de SSH a través del diccionario, se consigue una sesión la cual se puede utilizar para interactuar con el dispositivo que tiene el servicio.  Para evitar estos ataques, ya os dejé un artículo que explicaba en detalle cómo fortificar en modo paranoico un servicio SSH con técnicas de port-knocking, Latch, TOTP y cerfificados digitales evitando ataques de enumeración de usuarios.

En el siguiente video se puede ver una demostración de la carga del módulo, la configuración de éste, la ejecución y el uso de las sesiones en la herramienta. Nos recuerda al más puro Metasploit, aunque, he de decir que el objetivo ha sido crear una herramienta ampliable por cualquiera que permita implementar de pruebas de auditoría a routers y switches.

Figura 5: Ataque de diccionario a un servidor SSH

Ahora, se va a mostrar un video de cómo se disponen de módulos que implementan exploits contra dispositivos de red con vulnerabilidades conocidas. Esto es algo interesante, y disponer de una gran base de datos sobre ellos sería importante. En este caso, la prueba se realiza contra un dispositivo de red de CISCO. La vulnerabilidad explotada es un CSRF y el módulo lo que hace es comprobar si la vulnerabilidad existe o no existe en dicho dispositivo.

Figura 6: Explotación de una vulnerabilidad conocida en dispositivo CISCO

Por último, y ya que no puede faltar, un módulo que nos permita escanear puertos abiertos de los dispositivos a través del flag SYN de TCP. En el video se puede visualizar como se carga el módulo, se configura un listado de puertos que se quieren comprobar y el módulo comienza la creación de peticiones TCP contra la máquina destino.

Figura 7: Escaneo de puertos con el framework

Desde aquí quiero felicitar a Josué por el trabajo bien hecho y por su propuesta para matrícula de honor por su Trabajo Fin de Grado en la Universidad Rey Juan Carlos. Espero que sigas con el proyecto y que sigas “hurgando” en la seguridad de los dispositivos de red y que tu ejemplo anime a otros chavales a hacer sus propios proyectos.

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

CloudShark: Tus credenciales en las trazas PCAPs de la nube

Hace ya algún tiempo que salieron los primeros servicios que permitían analizar ficheros PCAP en la nube. Es decir, analizar ficheros con capturas de tráfico de red que eran subidos a la nube para ser analizados, como el caso del servicio Immunity Stalker del que os hablé allá por el ya lejano 2012. Hoy os vengo a hablar de otro servicio que implementa el interfaz del popular Wireshark, pero en cloud, y que tiene el nombre de CloudShark.

Figura 1: CloudShark. Tus credenciales en las trazas PCAPs de la nube

La idea del servicio es bien sencilla. Haz una captura de red en formato PCAP con tu sniffer de red favorito y súbela a CloudShark para poder visualizar los paquetes y el contenido de los mismos. Hasta aquí todo va bien, pero cuando vemos que las capturas que se suben con los servicios gratuitos sin autenticar quedan expuestas a todo el mundo, y que las opciones de protección contra el indexado y caché de los buscadores no están fortificadas, la cosa se puede complicar.

Figura 2: Buscando en Google en las capturas indexadas de CloudShark

De esto se dio cuenta mi amigo rootkit, y tras estar jugando un rato con las búsquedas, se puede ver que es muy fácil acceder a contraseñas de servicios de todo tipo. Muchas de ellas en redes locales, muchas otras de servicios en Internet.

Figura 3: Traza de una conexión FTP en red local

Afinando las búsquedas y sacando el máximo del hacking con buscadores es posible localizar usuarios de WordPress, usuarios de servicios FTP, usuarios de administración de dispositivos de red o casi cualquier cosa que se te ocurra buscar en este servicio. 

Figura 4: Traza de petición HTTP POST de login a una web con usuario y contraseña

Si alguien estuviera buscando víctimas al azar o servidores que utilizar para lanzar un ataque desde ellos, desde luego ir a ver qué hay ya en CloudShark publicado en Google es una forma muy sencilla de hacerse con un servidor aleatorio sin realizar mucho trabajo, tal y como se puede ver en las imágenes.

Figura 5: Trazas de sesión de administación de un WordPress

Si vas a hacer un trabajo de ethical hacking en un cliente y has hecho una captura PCAP del tráfico de un segmento, no la subas a un servicio en Cloud sin asegurarte de que no va a quedar expuesto a todo el mundo e indexado en un buscador, ya que podrías poner en riesgo la seguridad de tu cliente. Ten cuidado y sé cuidadoso con los datos que capturas en tu trabajo.

Saludos Malignos!

Michael Lynn & CISCO IPv6: El CISCOGate en BlackHat USA

Como me lo he pasado genial leyendo el libro de Microhistorias, aprovechando que ahora estoy jugando un poco más con IPv6 y con el ánimo de levantaros un poco más las ganas de aprender sobre la seguridad y el hacking de este protocolo de direcciones de 128 bits, os voy a refrescar la historia de Michael Lynn y el CISCOGate, que en el año 2005 dio la vuelta al mundo merced a un vídeo que escandalizó a propios y extraños sobre lo que sucedió en BlackHat USA ese año.

La historia comenzó con un bug parcheado por CISCO en Abril de 2005 en la implementación de la pila IPv6 de sus routers. Sin embargo, según el investigador de seguridad Michael Lynn que trabajaba en la empresa de seguridad ISS (Internet Security Systems), la información que CISCO había publicado sobre el bug no era toda verdad y el riesgo era mucho mayor. Michael Lynn encontró la forma de tomar el control total de los routers y quería hacer una demostración en BlackHat USA.... que no gustó mucho a CISCO.

Figura 1: Michael Lynn dando la conferencia en BlackHat USA 2005 en Vegas

Al principio ISS aprobó la charla de Michael, pero tras presiones de CISCO una vez que se había anunciado la charla en la agenda de BlackHat USA, la empresa ISS decidió prohibir la charla y que diera una charla genérica de CISCO IOS Security, obligando a que se quitaran los DVDs con el whitepaper y las diapos de la charla grabadas en él, y que se... arrancara el whitepaper del libro de presentaciones. No os perdáis el siguiente vídeo.

Al final Michael Lynn dio la charla explicando el bug y la forma de explotarlo, algo que llevó a que fuera demandado por CISCO, ISS, y se denunciara a todos los que publicaran alguna información de aquel fallo, montándose un gran debate sobre el "Responsible Disclosure" en aquella época.

Figura 2: Carta de amenaza a uno de los que publicaron las diapositivas

Hoy en día es posible encontrar las diapositivas sin demasiada dificultad de aquel bug y su forma de explotarlo en la implementación del protocolo IPv6, pero durante un tiempo estuvo perseguido, algo que hoy en día llamaría mucho la atención.

Saludos Malignos!

Ataque David Hasselhoff a un Cisco VoIP Phone

El Ataque David Hasselhoff está yendo cada vez más lejos. Primero en los equipos PC, para pasar a estar dentro de los R.A.T.s, luego en las Apple Stores, en los iPads, en los puntos de información de turismo ... ¡si hasta me lo comí yo en el Asegúr@IT Camp 4! Sin embargo, he decir que este último me ha encantado y sorprendido a la par: En la pantalla de un teléfono CISCO VoIP. 

Figura 1: David Hasselhoff Attack en el menú de un CISCO VoIP

El momento de ver la cara de la persona que se encuentre con la imagen inferior no tiene precio y merece la pena por tanto hacer el trabajo para implantarla allí, que no es tan complicado como parece.  Los atacantes, utilizando este artículo Hacking The Cisco 7940 IP Phone, se las apañaron para configurar el servidor TFTP con la famosa fotografía de David Hasselhoff y sus perritos. Después nada, a jugar con los menús del teléfono y descargarla en el terminal para echarse unas risas.

Saludos Malignos!

Common Vulnerability Reporting Framework 1.1

Los días que hay muchos advisories de trabajo siempre pienso en mi amigo Sergio de los Santos echando "ofús". Esos días debe filtrar todos los documentos publicados por los fabricantes de software para que sean distribuidos a través de su servicio SANA y para ello debe pegarse con las maneras que cada uno de los fabricantes tienen de poner disponible esa información, así que sé que tiene una tarea larga por delante, por muy automatizados que tengan los procesos internos.

Esto es algo que sucede en casi todos los frameworks de gestión de vulnerabilidades, consolidación de reportes, o integración de resultados, en los que se muestra el expediente de seguridad del fabricante para ampliar la información del bug.

Para evitar esto se está trabajando en estandarizar la forma en la que se publica y consume esta información en un formato de documento definido como Common Vulnerability Reporting Framework, en el que se intenta crear un tipo de documento en XML que sea capaz de ser producido y procesado de manera estándar.

Figura 1: Esquema del schema de CVRF 1.1

El formato del documento está siendo definido por ICASI (An Internet Consortium for Advancement of Security on the Internet), y en el whitepaper publicado, además de justificar la necesidad de un consenso para hacer más fácil gestionar esta información, expresan la necesidad de seguir trabajando en la integración y evolución de otros formatos estandarizados para comunicarse, como son:

- Security Content Automation Protocol
- Common Platform Enumeration
- Common Weakness Enumeration
- Open Vulnerability and Assessment Language

Hoy en día, modelos como el CVSS para medir la criticidad de una vulnerabilidad son ampliamente utilizados - aunque algunos fabricantes adapten esas métricas y la expresen de otra forma -, pero todos estos esfuerzos en estandarización del advisory ayudarán a que haya un lenguaje completo y no solo una "manera de hacer las cosas", para que sea mucho más sencilla la tarea de consumir toda la información de seguridad que se produce.

Algunos fabricantes ya han anunciado que comenzarán a utilizarlo, como es el caso de Microsoft o de CISCO, que incluso ha publicado un manual en dos partes con un ejemplo de cómo transformar un advisory de CISCO a formato CVRF 1.1.

- The Missing Manual: CVRF 1.1 (Part 1 of 2)
- The Missing Manual: CVRF 1.1 (Part 2 of 2)

Espero que en el futuro, mi amigo Sergio de los Santos eche menos "ofús" los días que se hayan publicado muchos security advisories, y le quede más tiempo para otras cosas.

Saludos Malignos!

Los registros de servicios

Como en los últimos años me toca "torturar" a mis alumnos de los masters con algún trabajo que los vuelva locos. En este caso tengo a un grupo de tres sufriendo para generar una base de datos de registros en servidores DNS predecibles que permitan estrujar un servidor en un proceso de auditoría para pintar el mapa de red. La idea es poder incorporar toda esa base de datos a la FOCA, para poder reconocer nuevos servidores y nuevos roles.

A los registros well-known que actualmente busca FOCA, es decir, NS, SOA (para sacar el primary.master), MX, SPF, version.bind y registros PTR, se pueden añadir, en primer lugar los registros de servicio que utilizan los dominios de Microsoft, luego esos que han utilizado en Microsoft para cosas particulares, como WINS o WPAD, y luego los que se han estandarizado para publicar los servicios proporcionados por organización y que permitan ser encontrados por protcolos de autodescubrimiento, tales como los servicios de VOIP, presencia o comunicaciones varias. Cuando esté el proyecto terminado y presentado, os pondré la lista final de todos los registros analizados.

Al final, si tienes catalogados qué aplicaciones o protocolos usan qué registros de servicios, basta con hacer consultas de tipo SRV y descubrir más información de la organización, algunos ejemplos:


Figura 1: Registros SIP en Adobe


Figura 2: Registros Kerberos en Debian


Figura 3: Registro Ldap en la Universidad de Michigan


Figura 4: Registros jabber en Google


Figura 5: Resgistros XMPP Server en Google


Figura 6: Registros SIP en Oracle


Figura 7: Registros SIP en CISCO
Interpretar los regisros SRV no es demasiado complicado, son unos puertos, prioridades y servidorers que ofrecen esos servicios. Datos jugosos, sin duda, para un pentesting.

Saludos Malignos!

Locos por el Uptime II

Durante el año 2007 estuve contado como iba el uptime de 14 sitios web elegidos de una manera totalmente partidista y pendenciera. Fueron 14 sitios relativos a empresas de tecnología. La clasificación el año pasado la encabezó Google que con 50 minutos consiguió que su web fuera la que más tiempo estuvo dando servicio de las 14 elegidas. Sin embargo, Yahoo!, que no estaba entre las elegidas sólo falló 1 minuto y 16 segundos el año 2007, así que la he puesto en la lista del 2008. Durante el 2008 ni Yahoo! ni Google han sido los que mejor lo han hecho, siendo dos de las tres únicas webs que han empeorado sus resultados.


Tabla de Resultados Uptime 2008
Cómo ya sabéis, estos resultados se sacan realizando comprobaciones del servicio web mediante la respuesta de la página principal. Esto no habla de mejor uptime de máquinas sino de servicio, así que, para conseguir estos resultados se implementan arquitecturas complejas y con servicios de respaldo intentando dar el mejor porcentaje de servicio.

Sólo Spectra e IBM llegan a obtener 4 nueves en porcentaje de Uptime, HP y Apple consiguen que su web deje de responder menos de 1 hora al año y llama poderósamente la atención el hecho de que la web de CISCO haya estado sin dar servicio más de 2 días. Ubuntu ha conseguido bajar del día de parada con lo que habrá que pensar en dejar de rezar a San Ubuntu y volver a rezar al gran dios Sol, que además da 2 días de dencaso en lugar de uno.

Los links a las tablas de Uptime los tienes en:

[www.ubuntu.com],[www.youtube.com],[www.sun.com],[toshiba.com],[cisco.com],[www.dell.com],[www.redhat.com],[www.oracle.com],[www.ibm.com],[www.hp.com],[www.amd.com],[www.apple.com],[www.microsoft.com],[www.google.com], [www.Yahoo.com]

Saludos Malignos!

¿He sido yo?

En esa etapa de mi vida dónde Oracle era gran parte de mi trabajo cotidiano me sucedió una anécdota que he contado muchas veces para explicar la importancia de la protección de los CPDs. En este caso el problema era que todos los días, alrededor de la mañana, un servidor SUN con Oracle nos tiraba las conexiones de red de todos los servicios ¿cuál era el problema? Tras no encontrar nada, un día, antes de la hora me fui con un par de compañeros a monitorizar el servidor. Cuando esta allí, armado con mi top en una ventana y con el profile en la otra la respuesta salió a la luz. Entró, blandiendo una pulidora industrial para dejar bien limpio y reluciente el suelo de la sala, la señora de la limpieza y la enchufó a la SAI del servidor provocando un baile de lucecitas en la SAI y un horroroso parpadeo en el servidor. No lo tiraba abajo, creo que el término más correcto, para que nos entendamos, sería que lo “zarandeaba”.

¿Y por qué me he acordado de esto? Pues sucedió algo el miércoles tarde, la web de Cisco completa estuvo 3 horitas … y cuatro minutos sin dar servicio, como se puede ver en el gráfico de Pingdom sobre la web de CISCO. Dejaron de dar servicios a clientes y partners durante todo ese tiempo.

Imagen: Grafico de Cisco.com en Pingdom
La explicación que han dado a través del blog ha sido:

“We have traced the cause of the issue to an accident during maintenance of a San Jose data center that resulted in a power outage in that facility. We would like to thank our customers and partners for their patience. We expect to resolve the issue shortly”

Vaya, parece que tuvieron un problemita durante el mantenimiento y se les fue la luz. Supongo que al irse la luz también fallaron los sistemas de alimentación ininterrumpida, los sistemas redundantes del CPD, los planes de contingencia, los generadores de emergencia, etc…Lo curioso, es que el problema en San José sólo les afectó a ellos. Menos mal que llegaron a tiempo para publicar los nuevos expedientes de seguridad.

Esto suena cómo que han debido contratar a Steve Urkel como nuevo jefe de mantenimiento o a lo mejor estaba de visita con Carl o con Laura o con Eddie Winslow paseando por allí después de tomar un helado en el burger de su tia. ¿Quién sabe?

¡Saludos Malignos!