Un fallo de diseño en los routers caseros facilita los ataques remotos

Via The Inquirer:

Expertos en seguridad han descubierto que un fallo en el UPnP hace que los routers domésticos sean hackeados y redireccionados a páginas web fraudulentas.

El exploit funciona incluso cuando el usuario ha cambiado la contraseña que trae por defecto el router y es independiente del sistema operativo o del navegador al que esté conectado el dispositivo, siempre y cuando tenga instalada una versión reciente de Adobe Flash.

El problema ha sido calificado de “grave” por Adrian Pastor, de la organización GNUCitizen. Reside en el Universal Plug and Play (UPnP), una arquitectura de software abierta presente en la mayoría de los routers domésticos y que se utiliza para que los equipos puedan hacer funcionar juegos, programas de mensajería instantánea y otras aplicaciones. Cuando el usuario está expuesto a un archivo Flash maligno escondido en una página web, los atacantes pueden utilizar la UPnP para modificar el router.

El ataque más serio que puede hacerse es cambiar los servidores que el router utiliza para acceder a las páginas web. Esto podría llevar al usuario a páginas de bancos que parecen verdaderas pero que no lo son y que van a robarle sus datos personales.

Entre los routers vulnerables se encuentran los de las marcas Linksys, Dlink y SpeedTouch. La mayoría de los routers vienen con la UPnP habilitada de fábrica. La única forma de evitar estos ataques es apagando la función, algo que puede hacerse en algunos dispositivos, pero no en todos.

Mas información sobre el error en servidor DNS de Microsoft Windows

Hablábamos el otro día sobre este serio problema de seguridad de Microsoft Windows,

Hoy encontramos mas información al respecto en Hispasec.

Microsoft confirmaba a través de una notificación oficial el día 13, la existencia de una vulnerabilidad que estaba siendo aprovechada por atacantes «de forma muy limitada» según la propia compañía. El problema se debe a un desbordamiento de memoria intermedia en la implementación de la interfaz RPC del servidor DNS (Domain Name System) de Windows a la hora de procesar peticiones mal formadas. Esto puede ser aprovechado por atacantes para ejecutar código arbitrario con privilegios de SYSTEM (control total sobre el sistema) si se envía una petición especialmente manipulada al sistema vulnerable.

Esto afectaría a un sistema sólo si mantiene un DNS (típicamente en servidores de Microsoft) y un potencial atacante tuviese acceso a unos puertos específicos. El ataque no sería posible exclusivamente a través de puerto 53, abierto habitualmente al exterior para las consultas DNS, sino que debe apoyarse de la capacidad de administración remota de DNS (a través de RPC) para explotar la vulnerabilidad y ejecutar código. Microsoft proporcionó un método para eliminar esta funcionalidad y proteger el sistema a falta de parche oficial.

Aun así, varios factores se han añadido a la ecuación para convertir esta vulnerabilidad en un verdadero peligro. Típicamente un controlador de dominio en red interna es también el servidor autorizado DNS del dominio. En una red interna, no suelen protegerse estos controladores tras un cortafuegos, o las reglas de filtrado pueden estar más relajadas. En ese caso, aunque no expuesto al exterior, el servidor podría quedar fácilmente comprometido desde la misma red interna. Si el controlador de dominio queda comprometido, el atacante habría llegado al corazón de una red interna controlada por el directorio activo.

El día 15, metasploit descubrió un exploit público capaz de aprovechar esta vulnerabilidad. Queda desde entonces abierta para todos la posibilidad de estudiar y experimentar con el fallo. El problema concreto parece estar en la función extractQuotedChar. Los ataques dejan de ser «limitados».

Además, aparece al poco tiempo un nuevo exploit (programado por Andrés Tarasco y Mario Ballano) que es capaz de aprovechar la vulnerabilidad sin necesidad de tener acceso al rango mencionado en un principio (1024-5000), sino que permitiría ejecutar código a través del puerto 445. Este puerto es usado para el protocolo SMB (Server Message Block) sobre TCP/IP, y se utiliza para el intercambio de ficheros, entre otros fines. Una vez más, este puerto no suele estar expuesto al exterior, pero mantiene e incluso agrava el problema en redes internas, donde estará abierto con casi toda seguridad. Este código también afecta a Windows 2003 con SP2.

Para colmo, se ha detectado un gusano que intenta aprovechar la vulnerabilidad. El nombre elegido es Rinbot, y una vez que logra ejecutar código, se conecta al dominio x.rofflewaffles.us y convierte a su víctima en zombie (parte de una botnet). La detección específica por parte de los antivirus es escasa todavía. Según el SANS, que ha usado VirusTotal para el análisis:

AhnLab-V3 2007.4.14.0 04.16.2007 Win32/IRCBot.worm.199680.I
AntiVir 7.3.1.52 04.16.2007 HEUR/Crypted
AVG 7.5.0.447 04.16.2007 Win32/CryptExe
DrWeb 4.33 04.16.2007 BackDoor.IRC.Sdbot.1299
eSafe 7.0.15.0 04.16.2007 Suspicious Trojan/Worm
Fortinet 2.85.0.0 04.16.2007 suspicious
Kaspersky 4.0.2.24 04.16.2007 Backdoor.Win32.VanBot.bx
Prevx1 V2 04.16.2007 Malware.Trojan.Backdoor.Gen
Symantec 10 04.16.2007 W32.Rinbot.A
Webwasher-Gateway 6.0.1 04.16.2007 Heuristic.Crypted

Sospechamos que esta vulnerabilidad provocará un nuevo parche fuera del ciclo habitual de Microsoft. De lo contrario no habría solución oficial hasta al menos el ocho de mayo. Se recomienda deshabilitar la capacidad de manejo remoto sobre RPC para los servidores DNS o bloquear el tráfico entrante no solicitado entre los puertos 1024 y 5000 e incluso 445 si no es necesario.

Para deshabilitar la capacidad de manejo remoto sobre RPC, en el registro, en la rama:

«HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters»

se debe añadir un valor DWORD llamado «RpcProtocol» con el valor 4. Es importante destacar que es necesario reiniciar el servicio DNS para que el cambio surta efecto.


Más Información:

Monday update on Microsoft Security Advisory 935964
http://blogs.technet.com/msrc/archive/2007/04/16/monday-update-on-microsoft-security-advisory-935964.aspx

Situation update on Microsoft Security Advisory 935964
http://blogs.technet.com/msrc/archive/2007/04/15/situation-update-on-microsoft-security-advisory.aspx

Vulnerability in RPC on Windows DNS Server Could Allow Remote Code
Execution.
http://www.microsoft.com/technet/security/advisory/935964.mspx

New Rinbot scanning for port 1025 DNS/RPC
http://isc.sans.org/diary.php?storyid=2643&rss

DNS Vulnerability being Exploited in the Wild
http://www.symantec.com/enterprise/security_response/weblog/2007/04/dns_exploit_time_is_upon_us.html

Ejecución de código arbitrario a través de RPC en servidor DNS de Microsoft Windows

Encuentro en Hispasec la siguiente noticia:

Ejecución de código arbitrario a través de RPC en servidor DNS de Microsoft Windows.

Este es un boletín con carácter de urgencia debido a la gravedad del fallo. Se ha encontrado una vulnerabilidad en el sistema DNS de Microsoft Windows que puede ser aprovechada por atacantes remotos para ejecutar código en el sistema.

El problema se debe a un desbordamiento de memoria intermedia en la implementación de la interfaz RPC del servidor DNS (Domain Name System) de Windows a la hora de procesar peticiones mal formadas enviadas a un puerto entre el 1024 y 5000. Esto puede ser aprovechado por usuarios no autenticados para ejecutar código arbitrario con privilegios de SYSTEM (control total sobre el sistema) si se envía una petición especialmente manipulada al sistema vulnerable.

Sólo se ven afectados los sistemas que ejecuten este servicio (DNS), que suele ser la gama «server» de Microsoft. Desde algunas fuentes afirman que ya se están produciendo ataques intentando aprovechar el fallo.

Se recomienda deshabilitar la capacidad de manejo remoto sobre RPC para los servidores DNS o bloquear el tráfico entrante no solicitado entre los puertos 1024 y 5000.

Para deshabilitar la capacidad de manejo remoto sobre RPC, en el registro, en la rama:
«HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters»
se debe añadir un valor DWORD llamado «RpcProtocol» con el valor 4.

Mas información.