Explotación reciente de Fritz Box

Question

Explotación reciente de Fritz Box

#1 de Damon (4 votos)

6

Información de fondo:

Aproximadamente el 50% del ADSL y el acceso a internet por cable en Alemania (y presumiblemente partes de la UE) pasa por enrutadores AVM Fritz, ya sea textualmente o renombrado como p. ej. "1 & 1 Home Server" o "T-Online Box".
Estos son sistemas MIPS integrados con un par de puertos Ethernet, un conector ADSL o similar, y otras cosas opcionales (DECT, WLan, puertos USB) que ejecutan un derivado de Linux (2.6 ???).

Hace unas tres semanas, se conoció un exploit que permitía obtener acceso de root al enrutador. Al parecer, el exploit se ha utilizado para llamar a los números de servicio en las Falklands, cobrando a los usuarios involuntarios.

El primer comunicado de prensa público de AVM fue que esto no era una amenaza grave (¡qué otra cosa dirían!) porque requiere que se habilite el acceso remoto, lo cual no es el caso por defecto, y que la mayoría de los usuarios no han habilitado de todos modos .

Unos días más tarde, se reveló que la vulnerabilidad no tiene nada que ver con el acceso remoto, y que alguien podría hacerse cargo de su enrutador si simplemente visitó un sitio web que de otra forma sería inofensivo y que contiene una página con código malicioso. Se publicó una actualización del sistema operativo el mismo día.

Ayer, se alegó que se está publicando una descripción detallada en "sitios específicos de hackers", mientras que varios millones de enrutadores permanecen sin parchear (es decir, son vulnerables).

Preguntas:

1. ¿Cómo podría funcionar tal exploit, conceptual y prácticamente? ¹. Cuando visita un sitio web (o hace casi todo lo demás), su navegador ejecuta una consulta de DNS y abre una conexión TCP al host remoto. El enrutador transmite su consulta de DNS y luego NAT su paquete SYN (y el SYN-ACK, y todos los siguientes datagramas).
En otras palabras, el enrutador está prácticamente copiando paquetes de un puerto Ethernet a otro (actualizando la suma de comprobación de IP después de NAT, pero eso presumiblemente sucede en el hardware de todos modos, pero en cualquier caso las implementaciones de software de la suma de comprobación de TCP han sido sometidas a pruebas de estrés durante 40 años ¿Son bastante sólidos como una roca? Básicamente, como si estuviera haciendo un splice de un socket a otro, excepto que sucede en la pila de red.
¡Uno debería esperar seriamente que el simple reenvío de un paquete a otro puerto funcione de manera 100% confiable sin excepciones y sin ningún medio de ser explotado! El enrutador no valida ni ejecuta nada dentro de los datagramas, no hay razón para que el enrutador incluso mire el "blob binario" dentro de cada paquete (... y por lo que sé, no lo hace ¿realiza algún filtrado de contenido?).
Estoy desconcertado de cómo tal hazaña realmente podría funcionar. ¿Alguna idea?

2. Al ver cómo el "filtro de paquetes de Linux está dañado" parece ser la única explicación plausible (¿qué otra cosa podría ser?), ¿tengo motivos para empezar a entrar en pánico con respecto a mi servidor Debian?

¹ Tenga en cuenta que no estoy buscando una receta de procedimientos, y no quiero ejecutar un exploit.

exploit routing

pregunta Damon 10.03.2014 - 15:04

fuente

1 respuesta

Lea otras preguntas en las etiquetas exploit routing

¿Qué tan efectiva es la configuración de iOS "Enviar todo el tráfico a VPN" para disuadir los ataques basados en Wifi? ¿Está generando una clave RSA con contraseña y luego eliminándola es más segura que ninguna contraseña?

score 4 · Accepted Answer

Después de buscar todo el día y explorar unos cuantos miles de publicaciones más o menos irrelevantes en varios foros de usuarios y en un sitio que presumiblemente "prueba" la vulnerabilidad (la transcripción de telnet, sin embargo, no muestra nada más que una página HTML algo rota), Encontré un sitio de explotación actual .

Resulta que, como de costumbre, la información disponible públicamente era engañosa.

¿Qué es?

El exploit, sin detalles demasiado explícitos , es un ataque XSRF / inyección combinado, y una sofisticación de un ataque que se conoce al menos desde principios de 2009:

La interfaz web del enrutador, a la que se puede acceder en la LAN (y opcionalmente también de forma remota), tiene una interfaz de usuario localizada.
La interfaz web, que te permite cambiar la configuración y ejecutar algunos comandos, es un vector de ataque muy obvio, que puede ser (¡o eso crees!) frustrado al establecer una contraseña.
El exploit funciona porque el código de localización no verifica sus parámetros. Sin embargo, la localización incluye la página de inicio de sesión, por lo que la vulnerabilidad se ejecutará antes , incluso es necesario que se autentique. Por lo tanto, establecer una contraseña no evitará el ataque.
Esta es la única característica espectacular del presente exploit.
El enrutador pasará el idioma de la interfaz solicitada y no verificada a una utilidad que se ejecuta como root (... y ejecuta sus parámetros en un shell).
Una vez que se conoce ese hecho, el exploit se vuelve muy obvio: seleccione un idioma de interfaz de usuario seguido de un separador y cualquier comando de shell que desee ejecutar. Este es un ataque de inyección muy típico (como los ataques de inyección de SQL más conocidos).
Normalmente, esto se usaría para habilitar el acceso remoto y cargar las contraseñas / archivo de configuración a otro servidor a través de FTP, o descargar un marcador, o similar.
No se necesita "código malicioso" per se en el sitio web atacante. El ataque ocurre simplemente proporcionando una URL (para una imagen o similar) que apunta al nombre de red predeterminado del enrutador (o su dirección IP de emergencia) y contiene los comandos para ejecutar como POST variables.
En principio, esto podría hacerse en cualquier sitio inofensivo a través de un anuncio publicitario, incluso sin que el propietario del sitio lo sepa.
El navegador del usuario intenta abrir la URL y, por lo tanto, ejecuta el código en el enrutador.

¿Qué hacer al respecto?

Aparte de lo obvio, al actualizar el firmware (¡probablemente ya hace un mes!), se debe tener instalada una extensión de navegador que evite las solicitudes / scripts de sitios cruzados sospechosos, como NoScript o RequestPolicy. Esto es algo que todos deberían tener de todos modos.
Además, el bloqueo de los banners publicitarios es una consideración definitiva, si uno no lo hace de todos modos.

¿Qué pasa con la pregunta 2?

Ya que no es una vulnerabilidad de enrutador per se (es decir, un error en la pila de red), sino simplemente una explotación de una interfaz de usuario rota (que, de manera incidental, se ejecuta en el enrutador), otros sistemas Linux que no tienen esta interfaz no se ven afectados.