Este nuevo ataque afecta directamente a tu navegador de Internet

Los cibercriminales no descansan, siempre andan buscando nuevos objetivos a través de la explotación de brechas de seguridad. En este caso, unos nuevos ataques que afectan a los navegadores de Internet podrían comprometer nuestra seguridad. Samy Kamkar ha descubierto los ataques Slipstream NAT que afectan a nuestros navegadores, y que ya os explicamos cómo funcionaban en RedesZone. Los desarrolladores de los navegadores más populares ya se están preparando para bloquear esta nueva técnica de ataque, y hoy en RedesZone os vamos a explicar cómo lo harán.

Cómo funcionan los ataques Slipstream NAT

El descubridor del ataque ha sido el investigador de seguridad Samy Kamkar y el método de ataque ha sido denominado como NAT Slipstreaming. Los ataques Slipstream NAT requiere que las víctimas visiten un sitio web malicioso del atacante o un sitio con anuncios creados con fines malintencionados. Samy Kamkar ha proporcionado un esquema de demostración de este ataque para mostrar su funcionamiento.

Los ataques Slipstream NAT explotan el navegador del usuario, junto con el mecanismo de seguimiento de conexión Application Level Gateway (ALG) integrado en NAT, enrutadores y firewalls, mediante el encadenamiento de la extracción de una IP interna a través de un ataque de tiempo o WebRTC, detección remota automatizada de MTU y fragmentación de IP. Además, debido a que es el NAT o firewall el que abre el puerto de destino, esto evita cualquier restricción de puerto basada en el navegador.

Los ataques Slipstream NAT aprovechan el control arbitrario de la porción de datos de algunos paquetes TCP y UDP sin incluir HTTP u otros encabezados. En este caso, el ataque se basa en una nueva técnica de inyección de paquetes que afecta a los principales navegadores tanto modernos como antiguos. También hay que añadir que se trata de una versión modernizada de la técnica NAT Pinning de Samy Kamkar de 2010 que fue presentada en DEFCON 18 + Black Hat 2010. Además, se han incluido nuevas técnicas para el descubrimiento de direcciones IP locales.

En cuanto al ataque, hay que señalar que requieren que la NAT o el firewall admitan ALG (Application Level Gateways), que son obligatorios para protocolos que puedan usar múltiples puertos (canal de control + canal de datos) como SIP y H323 (protocolos VoIP), FTP, IRC DCC, etc.

Otras investigaciones y prueba de concepto

Samy Kamkar realizó otros descubrimientos que no se utilizan en este ataque. No obstante, podrían utilizarse potencialmente para la realización de otro tipo de ataques. En este sentido averiguó:

[list]
• La fragmentación de IP permite el control total de todos los datos en la sección de datos de IP. Esto se traduce en un control total de un encabezado UDP, incluidos los puertos de origen y destino en el paquete desbordado.

[list]
• Si ya se ha tomado un puerto, el puerto escuchado se incrementa hasta que el puerto se desborda a 0.

[list]
• STUN no tiene la autenticación implementada en ningún navegador moderno.

Los navegadores se preparan para bloquear este ataque

Los responsables de los navegadores web para detener los ataques Slipstream NAT tienen previsto bloquear los puertos TCP 5060 y 5061 usados ​​en este ataque agregándolos a la lista restringida.

Según Adam Rice que es el desarrollador de Chromium, se pretende bloquear las conexiones HTTP y HTTPS a los puertos SIP 5060 y 5061. Así, esto hará que fallen las conexiones a los servidores que utilicen los puertos mencionados anteriormente. Gracias a estos cambios las conexiones a servidores en esos puertos como por ejemplo http://web.com:5060/ o https://web.com:5061/ ya no funcionarían. Además, mejorarían las medidas de seguridad, ya que las pruebas que activan un servidor en un puerto arbitrario se espera que sean más difíciles de utilizar de lo que lo son ahora mismo.

Por último, los navegadores Firefox, Safari, Chromium y Chrome están trabajando para tener lo antes posible solucionados los ataques Slipstream NAT, pero aún no se sabe cuándo lo harán, el día 4 de noviembre se incorporó la solución al problema en el bug tracker de Chromium, por lo que aún tardaremos unas semanas en verlo en la versión estable final.