Se publico en una conferencia Blackhat, una nueva version del ataque DNS Rebinding, el cual posibilita interceptar el trafico de una LAN, sorteando el firewall de una empresa o particular.
El codigo en Google se encuentra, es del MIT, asi que estan trabajando para solucionarlo seguramente, en *nix antes que en otros sistemas seguramente.
Mientras, les dejo la lista oficial de routers probados y vulnerables a este ataque, si poseen alguno de estos, bueno, mas abajo, al terminar la lista, les dejo algunas formas de mitigacion
Vulnerables:
Vendor Model H/W Version F/W Version Successful
.
ActionTec MI424-WR Rev. C 4.0.16.1.56.0.10.11.6 YES
.
ActionTec MI424-WR Rev. D 4.0.16.1.56.0.10.11.6 YES
.
ActionTec GT704-WG N/A 3.20.3.3.5.0.9.2.9 YES
.
ActionTec GT701-WG E 3.60.2.0.6.3 YES
.
Asus WL-520gU N/A N/A YES
.
Belkin F5D7230-4 2000 4.05.03 YES
.
Belkin F5D7230-4 6000 N/A NO
.
Belkin F5D7234-4 N/A 5.00.12 NO
.
Belkin F5D8233-4v3 3000 3.01.10 NO
.
Belkin F5D6231-4 1 2.00.002 NO
.
D-Link DI-524 C1 3.23 NO
.
D-Link DI-624 N/A 2.50DDM NO
.
D-Link DIR-628 A2 1.22NA NO
.
D-Link DIR-320 A1 1 NO
.
D-Link DIR-655 A1 1.30EA NO
.
DD-WRT N/A N/A v24 YES
.
Dell TrueMobile 2300 N/A 5.1.1.6 YES
.
Linksys BEFW11S4 1 1.37.2 YES
.
Linksys BEFSR41 4.3 2.00.02 YES
.
Linksys WRT54G3G-ST N/A N/A YES
.
Linksys WRT54G2 N/A N/A NO
.
Linksys WRT160N 1.1 1.02.2 YES
.
Linksys WRT54G 3 3.03.9 YES
.
Linksys WRT54G 5 1.00.4 NO
.
Linksys WRT54GL N/A N/A YES
.
Netgear WGR614 9 N/A NO
.
Netgear WNR834B 2 2.1.13_2.1.13NA NO
.
OpenWRT N/A N/A Kamikaze r16206 YES
.
PFSense N/A N/A 1.2.3-RC3 YES
.
Thomson ST585 6sl 6.2.2.29.2 YES
Como trabaja el ataque?
Los SOHO routers (Caseros) suelen tener interfaces administrativas de configuración y monitorización via LAN. Aunque estas interfaces suelen ser protegidas por contraseña, la mayoría de la gente no se molesta en cambiar las contraseñas por defecto. Y, aun cuando lo hace, las fallas de seguridad en el front-end puede permitir que la contraseña pueda ser robada de todos modos. Con acceso al router, el atacante podría configurar de nuevo (por ejemplo) la ruta todas las búsquedas de DNS a través de un servidor malicioso infectado, lo que permitiría que el trafico sea monitoreado e interceptado.
Los ataques DNS Rebinding no son nuevos, en una u otra forma han estado alrededor por casi 15 años presentes. Algunos entornos como Java y Flash han adoptado medidas para reducir la posibilidad de la explotación DNS-caché de las búsquedas para garantizar que el tráfico destinado para el mismo nombre siempre los objetivos de la misma dirección IP. Esto impide el acceso a la red local.
Los navegadores, también, tratar de protegerse contra estos ataques. Sin embargo, Heffner dice que su variación del ataque pasa por alto la protección basada en el navegadores, lo que permite DNS Redbinding qse produzca con éxito. También dice que los bypass han sido conocidos de hace mucho tiempo, su ataque es más la puesta en común de un conjunto de técnicas conocidas en lugar de algo novedoso en sí mismo.
Esto es, en parte, su motivación para la liberación de una herramienta para llevar a cabo este tipo de ataques-, dice que los escritores del navegador y los suministradores de routers han tenido "tiempo suficiente" para solucionar el problema, pero no lo han hecho (Demuestra que nadie toma conciencia de la seguridad en redes). Demostración y difusión de una efectiva explotación es, según él, la mejor forma de que los fabricantes hagan algo.
Mientras tanto, la mejor defensa es, probablemente, asegurarse de que el router no utiliza la contraseña predeterminada. Aunque esto no puede proteger contra la explotación de los defectos reales en el software del router, que por lo menos prevenir los ataques triviales que se realicen (es decir, seguro del todo no estas, pero... safas a los kiddie que bajan el codigo). Cambio de la dirección IP del router lejos de su valor por defecto típico también podría servir como una cierta protección( Suelen venir en 192.168.1.1, bueno, ponelo en 192.168.1.217 por ej), aunque el ataque podría ser usado para dirigirse a cualquier dirección IP en una red local, un poco de oscuridad tiende a funcionar bien contra ataques muy específicos.
Protecciones en conclusion:
* Habilitar HTTPS en la consola de administración en el dispositivo y no se olviden de desactivar la consola HTTP (si es posible, es decir, admin remoto).
* Utilizar una contraseña segura para el router (AdmIole_$)(@o__=hdUmK por ej). Cambiar el nombre de usuario por defecto de fabrica, siempre es admin, bueno, se puede editar muchas veces desde telnet, y que se llame peperina por ejemplo, si es posible depende el modelo.
* Deshabilitar el acceso al router de la consola de administración de cualquier red externa y restringirla a UN numero de IP conocido en la red interna. Esta opción suele ser accesible desde la consola de administración.
* Si deciden no utilizar los servidores DNS de forma automática proporcionada por el ISP, usen otra resolución recursiva (abierta, como google DNS o OpenDNS) o una resolución para uso del público, como OpenDNS o Google DNS. Esto te protegerá de la versión publicada de este código de ataque.
* Si es posible, agregar una regla de firewall que impida a los dispositivos de la red local el envío de paquetes al bloque de su dirección IP pública como miembro de ella, esto es, que los host locales no envien NADA a rangos como el nuestro, si tenemos 192.168.1.30, bloquear ese tipo de redes, en iptables se puede con reglas de bloqueo de redes privadas en el OUTPUT, ejemplo.
iptables -A input -i eth0 -p any -s 192.168.1.0/24 -d 190.172.90.0/24 -J REJECT
Eso denegaria el trafico de nuestra red en la placa eth0 hacia las IP del bloque externo, si tenemos Speedy por ej, depende el ISP, es facil mirar eso, que rango usa nuestro ISP, si, no vamos a poder usar la pc de router o cosas asi, pero bueno, todo no se puede no?.
Otro punto, es deshabilitar el forward, en las reglas de politica por defecto, DROP a todo el Fordward
Esto evitará que las direcciones IP en la LAN entren en contanto la direccion IP externa . Si el ISP cambia el bloque utilizado en su red, tendremos que modificar esta norma. Como beneficio, esta regla, evita el broadcasting en toda la red vecina, para los que tienen Telecentro, que se puede sniffear y comparten el nodo, viene excelente.
* Mantener el firmware de los dispositivos de red del router y otros actualizados la fecha.
Desde este ataque consiste en el uso de un código JavaScript malicioso, instalar el plug-in NoScript debe ser útil para prevenir ser víctimas de tales ataques, es una extension del firefox conocida, en google aparece.
OpenDNS también discute este tema, y afirmó que el uso de OpenDNS puede ser una solución válida para evitar estos ataques.
Bueno, si no tienen esos modelos, suertudos!, o si usan Fibertel o Cablemodem en general, esto se aplica a routers y redes como Speedy o Arnet que proveen un router, la otra, es poner el modem en modo bridge y marcar el PPPoe como se hacia antes.
No hay comentarios:
Publicar un comentario
Dejá tu comentario