Bug en OpenSSL: Alternative chains certificate forgery

Llevábamos unos días analizando qué podría ser el nuevo bug que había sido anunciado en el proyecto OpenSSL en un parche nuevo. Después de un año y medio movido, con HeartBleed de por medio, todos estábamos listos para ver qué podría ser este fallo. En Eleven Paths habíamos incluso organizado una vigilancia especial por si en había que sacar una Prueba de Concepto rápido para nuestros sistema de pentesting persistente. Pero al final, aunque es de riesgo muy alto, no será tan crítico como lo fue Heartbleed que permitía robar datos masivamente.

Figura 1: Alternative Chains Certificate Forgery en OpenSSL

El fallo que se ha anunciado en OpenSSL se ha bautizado como Alternative Chains Certificate Forgery y se le ha asignado el CVE-2015-1793. El problema se encuentra en la forma en la que algunas versiones de OpenSSL verifican la cadena de confianza de un certificado digital. Es decir, salvo que se haga una implementación de un proceso de Certificate Pinning, un certificado digital se da por bueno si está firmado por una cadena de certificados que lleva a una raíz de confianza.

Verificación de la cadena de confianza

En un certificado A, si esté está firmado por un certificado B, emitido por una entidad certificadora de primer nivel C de la que se confía, entonces se dará por correcto y no se lanzará ninguna alerta de seguridad. Esta validación de certificados se produce tanto cuando un navegador cliente tiene que verificar el certificado de un servidor web, como cuando un servidor tiene que verificar el certificado de un cliente en un proceso de autenticación de usuarios basado en certificados digitales.

Figura 2: Bug de Alternative Chains Certificate Forgery en OpenSSL

Sin embargo, el bug de Alternative Chains Certificate Forgery permite que, en determinadas condiciones y en 4 versiones en concreto de OpenSSL, se pueda hacer que esa verificación de cadena de confianza hasta un certificado raíz se de por buena aún no siendo correcta del todo la cadena de certificación.

Entornos de explotación

En otras palabras, alguien podría usurpar la identidad de un servidor si el cliente utiliza el software de OpenSSL en el cliente (no lo usan Apple Safari, Internet Explorer, Chrome o Firefox, pero sí muchas aplicaciones móviles o de escritorio clientes) que combinado con un ataque de phishing o pharming ayudarán a robar datos de cliente, o lo que es más peligroso aún, alguien podría suplantar el certificado de un cliente en un entorno de autenticación de usuarios basado en certificados digitales como si se pudiesen crear todas las credenciales a gusto -

Figura 3: Configuración de autenticación de cliente SSL en servidor NGINX con OpenSSL

Este último escenario es el realmente peligroso, ya que se podría conseguir acceder a sistemas informáticos creando los certificados adecuados de los usuarios que tienen acceso a la plataforma. Por esto, es necesario que se actualice cuanto antes el software si estás haciendo uso de este tipo de autenticación en tus plataformas.

Saludos Malignos!

Automatizar ataques de Pharming con dispositivos de red

Cuando los escándalos provocados por las filtraciones de Edward Snowden estaban en pleno apogeo se habló del programa Black Budget, que estaba orientado a tomar el control de las redes mediante la infección de routers, switches o access points. Al final, los motivos por los que es una buena idea los recogí en este artículo en detalle.

Figura 1: Información del programa "Black Budget"

Es evidente que muchos de esos dispositivos pueden estar en redes de empresas, pero el número de dispositivos conectados a Internet y a la red de una empresa u organización pueden ser infinitos, y pueden abarcar cámaras de vigilancia, routers 2G/3G o los mismos PLCs. Algunos routers mostrado la contraseña en el banner otros PLCs enviándola como comportamiento por defecto.

Figura 2: Banner de un router mostrando la password por defecto

El problema es que una vez que se tiene acceso a uno de esos dispositivos de red no solo se puede tener acceso a la red, sino que en muchas ocasiones se tiene acceso a los servidores DHCP o DNS de la organización, lo que le permitiría a cualquier atacante hacer el hombre en medio dentro de la red y manipular todo el tráfico. Se podrían hacer ataques de red en IPv4 o IPv6 a gusto, como phishing para robar las credenciales, de evilgrade, pasar el tráfico por JavaScript Botnets, etc... En la imaginación del atacante está el límite cuando se controla el DHCP y el DNS de la red.

Encontrar sistemas mal securizados con Telnet es absurdamente sencillo y se puede hacer con un poco de hacking con buscadores con el servicio Shodan. Por defecto no se permite el servicio Telnet por lo que hay que comprar unos créditos para agregar el puerto 23 a la lista de puertos por los que se pueden filtrar los resultados, pero no están capados de la lista de resultados. Por supuesto no salen todos, y si quieres encontrar todos los servicios Telnet necesitas añadir el addon a Shodan o escanearte tu Internet.

Figura 3: Servicios Telnet descubiertos en Shodan

Buscando una cadena común de login en Telnet es posible encontrar cientos de miles de sitios con el servicio Telnet abierto. Después habría que hacer un poco de trabajo para averiguar la contraseña del sitio, pero con una buena base de datos de contraseñas por defecto asociadas a banners de dispositivos, más las cuatro o cinco típicas, llegar a controlar un buen número de dispositivos es bastante sencillo.

Figura 4: Una shell msh

Una vez en esos dispositivos lo más habitual es encontrarse con sistemas Linux/UNIX reducidos, donde se han quitado muchos servicios. En este ejemplo en concreto han quitado hasta el shadow, y la password del administrador está en el fichero /etc/passwd.

Figura 5: Servicios de red en el dispositivo

Saber si un dispositivo te va a dar acceso al resto de la red es sencillo, basta con mirar los procesos y ver si tiene configurado por defecto el servicio DHCP, lo que nos permitiría configurar a todos los clientes. En este caso, el dispositivo está configurando el servicio de DNS de toda la red para que apunte a la dirección 192.168.1.1.

Figura 6: Configuración del servicio DHCP para todo el segmento de red

Que como se puede ver con un simple ifconfig es él mismo. El servicio de DNS lo está redirigiendo a través de resolv.conf, lo que implica que simplemente está haciendo de DNS Open Resolver a las direcciones configuradas en el fichero de configuración /etc/resolv.conf, que por supuesto se pueden modificar.

Figura 7: Configuración de servidores DNS a usar en resolución

Hacer ataques de pharming a una red entera con unas simples modificaciones en los ficheros de configuración dhcpd.conf o resolv.conf darían a atacantes - por ejemplo criminales especializados en el fraude online como los que hicieron el famoso DNS Changer - la posibilidad de automatizar ataques masivos.

Eso si el equipo está configurado como servidor DHCP o con el servicio Open DNS Resolver, pero si no es así, siempre se puede configurar un nuevo servicio DHCP en la red, o planificar otros ataques de red. Poco ha pasado aún para lo que puede pasar en un futuro si alguien automatiza un ataques para distribuir malware con solo cambiar unas líneas de código en un par de archivos del sistema.

Saludos Malignos!