ué es la Vulnerabilidad 0.0.0.0 Day

Una vulnerabilidad crítica afecta a todos los navegadores web principales (Chromium, Firefox, Safari) y permite a los atacantes hackear redes locales.

El 0.0.0.0 Day surgió debido a la forma en que los navegadores manejan las solicitudes de red, lo que potencialmente permite a los hackers acceder a servicios confidenciales que operan en dispositivos locales.

La vulnerabilidad lógica permite que sitios externos interactúen con el software que se ejecuta localmente en macOS y Linux (localhost), y potencialmente ejecuten código arbitrario en el host del visitante, utilizando la dirección 0.0.0.0 en lugar de localhost/127.0.0.1. Windows no se ve afectado por este problema.

Correcciones en Progreso: Los Navegadores Bloquearán 0.0.0.0

Después de la divulgación responsable, las solicitudes HTTP a 0.0.0.0 ahora se están agregando a los estándares de seguridad a través de una solicitud de comentarios (RFC), y algunos navegadores pronto bloquearán completamente el acceso a 0.0.0.0. La dirección ya no estará permitida como dirección IP de destino en la especificación Fetch, que define cómo deben comportarse los navegadores al realizar solicitudes HTTP.

A principios de abril de 2024, Oligo informó sobre las vulnerabilidades a los equipos de seguridad responsables de cada uno de los principales navegadores. Los especialistas de cada empresa reconocieron la falla y trabajarán en la modificación del estándar correspondiente, además de implementar medidas de mitigación a nivel de navegador.

Eventualmente, todos los navegadores bloquearán 0.0.0.0, pero al mismo tiempo el mercado exige un estándar común.

La falta de un estándar final ha llevado a diferentes implementaciones en distintos navegadores. Es decir, cada navegador hoy maneja las solicitudes HTTP a redes internas o locales de manera diferente.

Correcciones de Navegadores

Google Chrome (y navegadores basados en Chromium, incluido Edge)

El 0.0.0.0 Day eludió el mecanismo PNA (Private Network Access) en Chromium, que bloquea el acceso de sitios web a 127.0.0.1, localhost y otras direcciones IP privadas a través de Javascript cuando se cargan desde sitios públicos.

Después del informe de Oligo Security, Chrome bloquea el acceso a 0.0.0.0 (Finch Rollout), comenzando desde Chromium 128. Google implementará gradualmente el cambio en las próximas versiones, completándolo en Chrome 133, después de lo cual la dirección IP estará completamente bloqueada para todos los usuarios de Chrome y Chromium.

Cabe señalar que el porcentaje de sitios web que se comunican con 0.0.0.0 está aumentando, según los contadores en Chromium. Tales páginas pueden ser maliciosas, y actualmente el porcentaje es del 0.015% de todos los sitios web. Con 200 millones de sitios en el mundo (a agosto de 2024), alrededor de 100,000 sitios públicos pueden estar comunicándose con 0.0.0.0. La figura a continuación ilustra este crecimiento.

Apple Safari

Los navegadores de Apple están basados en el motor WebKit. Después del informe de Oligo Security, Apple realizó cambios en WebKit</> que bloquean el acceso a 0.0.0.0. La empresa agregó una verificación de la dirección IP del host de destino. Si está compuesta solo por ceros, la solicitud es bloqueada.

Mozilla Firefox

Hasta el momento no hay una corrección en Firefox. Aunque está en proceso, Firefox nunca ha restringido el Private Network Access (PNA), por lo que técnicamente PNA siempre ha estado permitido. Desde este punto de vista, “no hay nada que corregir”, ya que PNA no estaba implementado originalmente en Firefox.

Después del informe de Oligo Security, Mozilla modificó la especificación Fetch (RFC) para bloquear 0.0.0.0. Firefox ha priorizado la implementación de PNA, aunque aún no está implementada. En el futuro, en Firefox 0.0.0.0 estará bloqueado y no dependerá de la implementación de PNA.

0.0.0.0 Day: Una Inmersión Más Profunda

Todos tenemos un navegador favorito que usamos a diario. Incluso las aplicaciones que no son navegadores suelen cargar recursos de dominios externos, como cuando se usan Google Analytics y SDKs similares, o cuando se integran scripts o videos.

Los desarrolladores siempre han implementado conceptos innovadores de seguridad en los navegadores, como el sandboxing y las cookies HTTPS-ONLY, o mecanismos como CORS (Cross-Origin Resource Sharing) para proteger tanto a los servidores como a los usuarios finales. Todas estas medidas de seguridad mantienen alejados a los sitios maliciosos que utilizan ataques CSRF de los datos personales de los usuarios, redes internas y aplicaciones locales.

Los navegadores pueden enviar solicitudes a prácticamente cualquier servidor HTTP utilizando Javascript. Al procesar la respuesta de sitios cruzados, los mecanismos de seguridad del navegador deciden qué acción tomar:

• Valid: transmitir los datos de respuesta al contexto de Javascript;
• Invalid: devolver una respuesta enmascarada o provocar un error específico (CORS, SOP, …).

Sin embargo, a veces la respuesta no tiene importancia. Con la vulnerabilidad 0.0.0.0 Day, una sola solicitud puede ser suficiente para causar daño. Antes de profundizar en los detalles, hagamos un poco de historia para comprender mejor.

¿Por qué un Sitio está Escaneando mis Puertos?

El fingerprinting digital de los usuarios de un sitio es una técnica bien conocida, con muchos propósitos. Su uso más común es la identificación de usuarios recurrentes, pero también puede ser utilizado por atacantes para recopilar información para campañas de phishing. Los sitios pueden aprender mucho sobre quién está visitando en ese momento, incluso si nunca has iniciado sesión.

En 2020, se descubrió que Ebay intentaba escanear los puertos del visitante inmediatamente después de cargar el sitio. El sitio usaba Javascript para escanear los puertos del host local (127.0.0.1), lo que creaba una huella digital única. Como el escaneo ocurre en el navegador, los firewalls del usuario no pueden evitar este proceso.

Los navegadores no deberían tener la capacidad de enviar tales solicitudes, ya que una sola solicitud podría llevar a una explotación. Durante muchos años, el Internet funcionó de esta manera y nadie le prestó mucha atención. Se necesitó tiempo para comprender completamente que este comportamiento podía provocar violaciones de seguridad, y para cuando se entendió, ya era parte de cada navegador, lo que hacía difícil corregirlo.

Un Error de 18 Años

Los servicios locales e internos siempre han sido un objetivo principal para los ataques. En 2006, Mozilla reportó un problema de seguridad interesante que fue descubierto antes del primer lanzamiento de Chrome en 2008. Curiosamente, el reporte de un error de hace 18 años sigue abierto.

En el reporte de error, un usuario afirmó que los sitios públicos atacaban su router en la red interna y creía que los sitios no deberían poder hacerlo.

En ese momento, las redes internas (y el Internet en general) no eran seguras por naturaleza: muchos servicios no tenían autenticación, y mucho menos certificados SSL o HTTPS, que no existían en todas partes. Los sitios web se cargaban a través de HTTP sin protección, y los atacantes usaban constantemente los navegadores con fines maliciosos.

Desde 2006, los hackers han explotado el hecho de que las solicitudes aún se envían, mientras los navegadores se enfocan en las respuestas. Por ejemplo, usando Javascript malicioso en un sitio controlado por el atacante, un ciberdelincuente podía cambiar la configuración del router doméstico o de oficina de la víctima.

Después de 18 años, cientos de comentarios y el problema aún permanece abierto. Durante este tiempo, el problema ha sido cerrado, reabierto, reclasificado como “grave” o “crítico” y hasta se ha explotado en condiciones reales. Por ejemplo, en junio de 2023, David Adrian, especialista en seguridad de Google, reportó varios casos de uso de la vulnerabilidad 0.0.0.0 Day.

A los acompañantes les resultó difícil llegar a un consenso sobre la naturaleza del error: ¿es una “vulnerabilidad”, afecta solo a Firefox o es una solicitud de mejora? Algunos desarrolladores de Firefox afirmaron que no era ni un error ni una función. No obstante, el informe de error permanecerá abierto hasta que Firefox implemente PNA.

Para activar el error bastaba con un solo HTTP-request; la respuesta no importaba. Ejemplos de scripts maliciosos ya habían sido documentados en 2006 en ataques a routers domésticos:

La falta de estandarización fue la principal fuente de todos los problemas, lo que creó la necesidad evidente de desarrollar un mecanismo básico de seguridad en todos los navegadores. El mundo ansiaba un estándar que ampliara el Cross Origin Resource Sharing (CORS) en todos los navegadores principales, permitiendo diferenciar entre redes locales, privadas y públicas.

Google se atrevió a llenar ese vacío al proponer el Acceso a Redes Privadas (Private Network Access, PNA).

¿Qué es PNA (Private Network Access)?

Durante mucho tiempo, no estaba claro cómo debían comportarse los navegadores cuando hacían solicitudes a redes locales o internas desde contextos menos privados. Dominios como attacker.com no deberían poder contactar con localhost en ningún escenario real.

Todos los navegadores principales dependían de CORS. CORS ayuda mucho, pero su rendimiento depende del contenido de la respuesta, por lo que las solicitudes aún se generan y envían. La historia ha demostrado que una sola solicitud HTTP puede atacar un router doméstico, y si eso es todo lo que se necesita, cada usuario debería poder evitar que dicha solicitud se realice.

PNA amplía CORS al limitar la capacidad de los sitios web para enviar solicitudes a servidores en redes privadas. PNA propone distinguir entre redes públicas, privadas y locales. Las páginas cargadas en un contexto menos seguro no podrán interactuar con contextos más seguros. Por ejemplo, attacker.com no puede contactar con 127.0.0.1 o 192.168.1.1, ya que estas direcciones IP se consideran más restringidas.

En la siguiente imagen se muestra la relación entre públicas, privadas y redes locales en el PNA.

¿En qué se diferencia PNA de CORS? Aunque CORS protege el contenido no deseado solo de ser cargado en contextos no seguros, lo hace a nivel de respuesta. Los recursos utilizados en la respuesta son enmascarados o eliminados. PNA refuerza esta capacidad al ofrecer la posibilidad de evitar que se envíe la solicitud por completo.

Probando 0.0.0.0: Eludiendo PNA

De acuerdo con la especificación actual de PNA, los siguientes segmentos de IP se consideran privados o locales:

Durante la investigación se descubrió que 0.0.0.0 no estaba en la lista de segmentos de IP considerados privados o locales por la especificación actual de PNA. Esto llevó a la conclusión de que los sitios aún podían enviar solicitudes a 0.0.0.0. Para probarlo, los investigadores configuraron un servidor HTTP falso en localhost (127.0.0.1) e intentaron acceder a él desde un dominio externo usando Javascript y la dirección 0.0.0.0.

El resultado fue que la solicitud llegó al servidor.

¿Qué ocurrió?

1. En un dominio público (.com), el navegador envió una solicitud a 0.0.0.0;
2. Un servidor ficticio escucha en 127.0.0.1 (solo en la interfaz loopback, no en todas las interfaces de red);
3. El servidor en localhost recibe la solicitud, la procesa y envía una respuesta;
4. El navegador bloquea la propagación del contenido de la respuesta en Javascript debido a CORS.

En otras palabras, los sitios públicos pueden acceder a cualquier puerto abierto en tu host, sin poder ver la respuesta.

Este es el elusión de la implementación actual de PNA y una debilidad inherente de los navegadores. Los especialistas informaron su hallazgo a los representantes de todos los navegadores como parte de una divulgación responsable. Sin embargo, para la prueba de concepto se requieren una amenaza real y un vector de ataque real.

Búsqueda de Aplicaciones Locales Vulnerables

Es necesario encontrar una aplicación que pueda verse afectada por la vulnerabilidad del 0.0.0.0 Day, y hay muchas aplicaciones en riesgo.

Cuando los servicios utilizan localhost, suponen que están en un entorno controlado. Esta suposición, que puede ser incorrecta (como en el caso del 0.0.0.0 Day), conduce a implementaciones inseguras del servidor. Por ejemplo, muchas aplicaciones omiten las llamadas al token CSRF y ponen en riesgo la autorización o autenticación, ya que se espera que funcionen en un entorno de red estrictamente controlado.

En algunos casos, puede que no se requiera autorización o autenticación, o que no haya verificación de tokens CSRF. Cuando una aplicación detecta que está en un entorno seguro o en una red aislada de confianza, permite la ruta POST HTTP sin autorización ni tokens CSRF, además de acceso de escritura a recursos y configuraciones, lo que permite ejecutar código. Incluso una sola solicitud HTTP podría ser suficiente para acceder a tus puertos.

Para encontrar una aplicación local que sea vulnerable a un ataque desde el navegador, primero se necesita un servidor HTTP que funcione en un puerto local (interfaz de red localhost). Para obtener ejecución remota de código, el servicio debe tener una ruta HTTP que permita escribir, configurar o modificar archivos y configuraciones.

Las aplicaciones tienen muchas terminales, y los servicios locales a menudo comprometen la seguridad, lo cual es una buena noticia para los atacantes. Los investigadores se enfocaron en el marco vulnerable Ray.

ShadowRay desde el navegador

Los especialistas de Oligo basaron su investigación en la campaña ShadowRay descubierta en marzo, que se dirige a la potencia computacional de IA. La vulnerabilidad permitió a los hackers explotar entornos no seguros. Oligo demostró que es posible realizar este tipo de ataque desde un navegador usando 0.0.0.0 como vector de ataque.

Primero, en la terminal derecha, se ejecuta un clúster local de Ray en localhost. Luego, en la terminal izquierda, se inicia un socket que escucha nuevas conexiones para abrir una Reverse Shell. La víctima hace clic en un enlace de un correo de phishing que activa el exploit. El exploit abre una Reverse Shell en la máquina de la víctima.

A continuación, se muestra un ejemplo del código utilizado para el exploit.

Cómo Funciona el Ataque en Diferentes Navegadores:

Google Chrome

Ejecutar ShadowRay desde un navegador es solo uno de los muchos ataques de ejecución remota de código (RCE) que pueden realizarse mediante este enfoque. A continuación, se describen algunos vectores de ataque usando el 0.0.0.0 Day.

Selenium Grid

En una reciente campaña llamada SeleniumGreed, los atacantes utilizaron servidores públicos de Selenium Grid para obtener acceso inicial a los sistemas de las organizaciones, explotando vulnerabilidades RCE conocidas. Se descubrió que en instancias locales de Selenium Grid es posible realizar un RCE al enviar una solicitud POST a http[:]//0.0.0.0:4444/ con una carga útil diseñada.

Otro vector de ataque interesante es usar un clúster local de Selenium Grid para ver sitios web con configuraciones inseguras del navegador con el fin de acceder a dominios internos y registros DNS privados detrás de una VPN.

Pytorch TorchServe (ShellTorch)

En julio de 2023, Oligo reveló varias vulnerabilidades críticas en ShellTorch a los desarrolladores de PyTorch de Amazon y Meta, que permitían la ejecución remota de código en PyTorch TorchServe, lo que finalmente permitía a los atacantes obtener acceso completo al servidor.

Los especialistas en IA que usan TorchServe en una red interna (local o con redireccionamiento de puertos) pueden verse comprometidos a través de 0.0.0.0, comprometiendo el clúster local de TorchServe que está detrás de firewalls y WAF.

Identificación de usuarios recurrentes basados en puertos abiertos

Otro vector de ataque interesante es la posibilidad de reconocer a usuarios anónimos escaneando puertos, incluso aquellos que no tienen cookies y nunca han iniciado sesión. Los resultados del escaneo de puertos locales pueden verificarse con datos adicionales, como User-Agent, dirección IP y otros identificadores obtenidos a través de servicios de escaneo de huellas digitales.

El escaneo reveló que diferentes personas dentro de una organización usan los siguientes puertos: