La nueva medida de seguridad de Chrome pretende contener toda una clase de ataques web


Un primerísimo plano del dedo sobre el icono de Chrome en el smartphone.

Durante más de una década, Internet ha sido vulnerable a una clase de ataques que utilizan navegadores como cabeza de puente para acceder a enrutadores y otros dispositivos confidenciales en una red de destino. Ahora Google finalmente está haciendo algo al respecto.

A partir de la versión 98 de Chrome, el navegador comienza a reenviar solicitudes cuando los sitios web públicos desean acceder a puntos finales dentro de la red privada de la persona que visita el sitio web. Actualmente, las solicitudes fallidas no impiden que se realicen las conexiones. En cambio, solo se registran. En algún momento alrededor de Chrome 101, suponiendo que los resultados de esta ejecución de prueba no indiquen que gran parte de Internet se romperá, será obligatorio que los sitios web públicos tengan un permiso explícito antes de que puedan acceder a los puntos finales detrás del navegador.

La eliminación gradual planificada de este acceso se produce cuando Google está habilitando una nueva especificación conocida como acceso a la red privada que permite que los sitios web públicos accedan a los recursos de la red interna solo si los sitios web lo han solicitado específicamente y el navegador accede a la solicitud. Las comunicaciones de PNA se envían mediante el protocolo CORS o Cross-Origin Resource Sharing. Según el esquema, el sitio público envía una solicitud de verificación previa en la forma del nuevo encabezado Access-Control-Request-Private-Network: true. Para que se conceda la solicitud, el navegador debe responder con el encabezado apropiado Access-Control-Allow-Private-Network: true.

Intrusión en la red a través del navegador

Anteriormente, de forma predeterminada, los sitios web tenían la capacidad de usar Chrome y otros navegadores como proxy para acceder a los recursos dentro de la red local de la persona que visitaba el sitio web. Si bien los enrutadores, las impresoras u otros recursos de la red a menudo están bloqueados, los navegadores predeterminados, debido a que deben interactuar con tantos servicios, pueden conectarse a prácticamente cualquier recurso dentro del perímetro de la red local. Esto ha llevado a una clase de ataque conocida como CSRF, abreviatura de Cross-Site Request Forgery.

Tales ataques han sido teorizados y llevados a cabo en la naturaleza durante más de una década, a menudo con consecuencias significativas. En un incidente de 2014, los piratas informáticos utilizaron CSRF para cambiar la configuración del servidor DNS para más de 300 000 enrutadores inalámbricos.

El cambio hizo que los enrutadores comprometidos usaran servidores DNS maliciosos para resolver las direcciones IP que los usuarios finales intentaban visitar. Por ejemplo, en lugar de visitar el sitio web auténtico de Google.com, el servidor malicioso podría devolver la dirección IP de un sitio web engañoso que el usuario final no tiene motivos para creer que es malicioso. La siguiente imagen, realizada por investigadores del Team Cymru, muestra los tres pasos involucrados en estos ataques.

Tres etapas de un ataque que modifica la configuración de DNS de un enrutador al explotar una vulnerabilidad de solicitud entre sitios en la interfaz web del dispositivo.
Agrandar / Tres etapas de un ataque que modifica la configuración de DNS de un enrutador al explotar una vulnerabilidad de solicitud entre sitios en la interfaz web del dispositivo.

Equipo Cymru

En 2016, los patrocinadores del mismo ataque volvieron a lanzar un malware llamado DNSChanger. Como expliqué en ese momento, la campaña funcionó contra los enrutadores domésticos y de oficina de Netgear, DLink, Comtrend y Pirelli de la siguiente manera:

DNSChanger utiliza un conjunto de protocolos de comunicación en tiempo real conocidos como webRTC para enviar las llamadas solicitudes de servidor STUN utilizadas en la comunicación VoIP. En última instancia, el exploit puede canalizar el código a través del navegador Chrome para Windows y Android para llegar al enrutador de la red. Luego, el ataque compara el enrutador objetivo con 166 huellas dactilares de imágenes de firmware de enrutador vulnerables conocidas.

Suponiendo que la especificación PNA sea completamente efectiva, Chrome ya no permitirá tales conexiones a menos que los dispositivos dentro de la red privada lo permitan específicamente. Aquí hay dos diagramas que muestran cómo funciona.

Google

A lo largo de la carretera

Cuando Chrome 98 y versiones posteriores detectan una solicitud de red privada, primero envía una «solicitud de verificación previa». Si la solicitud de verificación previa falla, la solicitud final aún se enviará, pero aparecerá una advertencia en el panel de problemas de DevTools.

«Cada solicitud fallida de verificación previa da como resultado una búsqueda fallida», escribieron el ingeniero de Google Titouan Rigoudy y el desarrollador de Google Eiji Kitamura en una publicación de blog reciente. “De esta manera, puede probar si su sitio web funcionaría después de la segunda fase de nuestro plan de implementación. Los errores se pueden diagnosticar de la misma manera que las advertencias utilizando los paneles DevTools mencionados anteriormente”.

Siempre y cuando Google esté seguro de que no habrá interrupciones masivas, las solicitudes de verificación previa deben aprobarse para que se lleven a cabo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *