Fue anunciada una nueva variante del ataque NAT slipstreaming

Se dio a conocer una nueva variante del ataque NAT slipstreaming, que permite establecer una conexión de red desde el servidor del atacante a cualquier puerto UDP o TCP del sistema del usuario que abrió la página web preparada por el atacante en el navegador.

El ataque permite al atacante enviar cualquier dato a cualquier puerto de usuario, independientemente del uso del rango de direcciones internas de la víctima en el sistema de la víctima, el acceso a la red desde la cual se cierra directamente y es posible solo a través de un traductor de direcciones.

El principio de funcionamiento de la nueva variante de NAT slipstreaming attack (CVE-2021-23961, CVE-2020-16043) es idéntico al método original, las diferencias se reducen al uso de otros protocolos, que son procesados ​​por la ALG (Application Level Gateways).

En la primera variante del ataque, para engañar a la ALG, se utilizó la manipulación del protocolo SIP, que utiliza varios puertos de red (uno para datos y otro para control). La segunda opción permite manipulaciones similares con el protocolo VoIP H.323, que usa el puerto TCP 1720.

Además, la segunda versión propone una técnica para eludir la lista negra de puertos que son inaceptables para su uso con el protocolo TURN (Traversal Using Relays around NAT), que se utiliza en WebRTC para comunicarse entre dos hosts detrás de diferentes NAT.

Las conexiones TURN en WebRTC pueden establecerse mediante navegadores no solo para UDP, sino también a través de TCP y dirigirse a cualquier puerto TCP de red.

Esta característica permite aplicar el ataque de NAT slipstreaming no solo a H.323, sino también a cualquier otro protocolo combinado, como FTP e IRC, que están incluidos en la lista de puertos a los que no se les permite acceder a través de HTTP, pero no están incluidos en la lista de puertos prohibidos para TURN.

El método también permite eludir la protección agregada a los navegadores contra el primer ataque de NAT slipstreaming, basado en denegar las solicitudes HTTP al puerto 5060 (SIP).

El problema ya se ha solucionado en versiones recientes de Firefox 85, Chrome 87.0.4280.141, Edge 87.0.664.75 y Safari 14.0.3.

Además de los puertos de red asociados con el protocolo H.323, los navegadores también están bloqueados para que no envíen solicitudes HTTP, HTTPS y FTP a los puertos TCP 69, 137, 161 y 6566.

En el kernel de Linux, la funcionalidad del módulo conntrack ALG en netfilter es desactivado por defecto desde la versión 4.14, es decir De forma predeterminada, los traductores de direcciones basados ​​en nuevos kernels de Linux no se ven afectados por el problema.

Por ejemplo, OpenWRT no se ve afectado por el problema incluso al instalar paquetes con módulos ALG. Al mismo tiempo, la vulnerabilidad se manifiesta en la distribución VyOS, que usa el kernel de Linux 4.14, pero el indicador nf_conntrack_helper está explícitamente habilitado, lo que activa ALG para FTP y H.323.

El problema también afecta a muchos enrutadores de consumo que se envían con kernels de Linux más antiguos o que cambian la configuración de ALG. La capacidad de ataque también se ha confirmado para firewalls empresariales y traductores de direcciones basados ​​en hardware Fortinet (FG64, 60E), Cisco (csr1000, ASA) y HPE (vsr1000).

Como recordatorio, para llevar a cabo un ataque de NAT slipstreaming, es suficiente que la víctima lance el código JavaScript preparado por el atacante, por ejemplo, abriendo una página en el sitio web del atacante o viendo un inserto de anuncio malicioso en un sitio web legítimo.

El ataque consta de tres etapas:

• En la primera etapa, el atacante obtiene información sobre la dirección interna del usuario, que se puede determinar mediante WebRTC o, si WebRTC está deshabilitado, mediante ataques de fuerza bruta con la medición del tiempo de respuesta al solicitar una imagen oculta.
• En la segunda etapa, se determinan los parámetros de fragmentación de paquetes, para lo cual el código JavaScript ejecutado en el navegador de la víctima genera una solicitud HTTP POST grande (que no cabe en un paquete) al servidor del atacante, utilizando un puerto de red no estándar number para iniciar la configuración de los parámetros de segmentación de TCP y el tamaño de MTU en la pila de la víctima de TCP.
• En la tercera etapa, el código JavaScript genera y envía una solicitud HTTP especialmente seleccionada (o TURN para UDP) al puerto TCP 1720 (H.323) del servidor atacante, que, después de la fragmentación, se dividirá en dos paquetes: el primero incluye Encabezados HTTP y una parte de los datos, y el segundo forma un paquete H.323 válido, que contiene la IP interna de la víctima.

Fuente: https://www.armis.com