En la primera parte de esta nota, se describen los antecedentes de este ataque y las medidas de protección implementadas en los navegadores para evitarlos. Esta parte de la nota trata del método utilizado por Craig Heffner para comprometer routers y las medidas que se pueden tomar para evitarlo.

Como requisitos necesarios para realizar el ataque, el atacante necesitará gestionar un dominio, para manipular las respuestas DNS asociadas a él, y un servicio web asociado a ese dominio cuyas páginas web contendrán el código Javascript malicioso encargado de tunelizar las conexiones a través del navegador.

El proceso completo es el siguiente:

• Un atacante registra un dominio dominio-malevolo.com que apuntará a un servidor web encargado de servir el código Javascript a la víctima y que por tanto también debe estar bajo el control del atacante. Éste enviará a la víctima la URL de la web www.dominio-malevolo.com.

• La víctima al pulsar el enlace realizará una petición DNS para resolver dominio-malevolo.com. El servidor DNS devolverá a dicha solicitud dos registros A, es decir, dos IPs, siendo la primera de ellas la IP correspondiente al servidor web www.dominio-malevolo.com mientras que la segunda será la IP pública de la víctima (y que acaba de obtener en la propia petición DNS).

  

  Imagen extraída del documento "Remote Attacks Against SOHO Routers" de Craig Heffner

• El navegador del cliente web intentará conectarse con la primera dirección IP que aparece en la respuesta DNS; es decir, que conectará en un primer lugar con el sitio www.dominio-malevolo.com.

• Tras establecer conexión con la URL del atacante, el servidor Web establecerá una nueva regla en el Firewall de la misma máquina para bloquear futuras conexiones desde la IP del cliente.

• El cliente intentará realizar otra conexión XMLHttpRequest al servidor web, sin embargo éste rechazará la conexión mediante un TCP reset debido a la regla creada anteriormente.

• Aquí es donde viene la parte interesante ya que el navegador al no poder conectar con el servidor web utilizará la segunda dirección IP que recibió en la respuesta DNS (es decir, su propia dirección pública) que se corresponderá con la IP de la interfaz externa del router.

• A partir de este momento, el resto del trabajo es llevado a cabo por el Javascript cargado en el navegador del cliente permitiendo al atacante conectar con el router del cliente utilizando el mismo como Proxy.

Podría pensarse en responder a la petición DNS directamente con la dirección interna del propio router pero aparte de desconocer la misma se presentaría otro problema y es que el navegador al recibir la respuesta DNS (con la IP del servidor web y la IP interna del router), utilizará en primer lugar la IP privada sin tener en cuenta el orden de las IPs en dicha respuesta, por tanto no podría llevarse a cabo el ataque al no existir una conexión previa con el servidor web y no producirse la carga del Javascript malicioso.

Hay que recalcar que la vulnerabilidad en todo este escenario no viene de la carga de dicho Javascript ni del uso de respuestas DNS como se vio anteriormente sino del propio router, al aceptar paquetes provenientes en la LAN en su interfaz externa o pública. Craig Heffner se dio cuenta que la mayoría de fabricantes de routers no siguen buenas practicas (RFC 1122) en la gestión y configuración de las conexiones e interfaces del router.

La mayoría de routers ofrecen todos sus servicios (web, ftp, ssh, etc.) en todas sus interfaces en vez de especificar una en particular. Debido a esto, es necesario establecer ciertas reglas firewall que prevengan el acceso a dichos servicios desde el exterior, es decir, en la interfaz WAN (eth1 en el siguiente ejemplo):

	-A INPUT -i eth1 -j DROP

  -A INPUT -j ACCEPT

Pero lo importante aquí es que dichas reglas no prevendrán de una conexión de un usuario perteneciente a la Lan, por tanto, un usuario conectado a la interfaz etho (interface interna) podrá alcanzar la interfaz externa (eth1) y es aquí donde reside el problema y donde toma ventaja el DNS-rebinding ya que ni siquiera es necesario conocer la interfaz interna del router, únicamente con la IP de la interfaz WAN (obtenida en al petición DNS) el atacante podrá conectar a la misma usando como proxy el navegador de la víctima.

El único lado tranquilizador de este ataque es que el acceso al servicio de configuración web del router suele estar protegido por contraseña. El problema se presenta cuando gran parte de los usuarios no modifica la misma, confiándose de que únicamente es accesible por un usuario perteneciente a la LAN por lo que no resultaría complejo para un atacante encontrar tal contraseña por defecto viendo el modelo y fabricante del router.

Mitigación

En aquellos routers en los que sea posible añadir reglas Firewall bastaría con añadir una que impidiera conexiones desde IP privadas a la interface WAN. De la misma forma podría implementarse dicha regla en Firewalls, switches, etc. situados entre el router y los propios equipos de la red local.

Además es fundamental modificar la contraseña por defecto del router y utilizar conexiones HTTPS siempre que sea posible al menos hasta que nuevos parches sean publicados por los desarrolladores de firmware.

En el caso de no tener acceso al router o siempre y cuando no se posible llevar a cabo las acciones especificadas anteriormente, se recomienda deshabilitar Javascript de aquellos sitios en los que no se confíe y no abrir páginas que generen desconfianza.