Detalles y evolución de la vulnerabilidad RPC/DNS de Microsoft Windows

La vulnerabilidad RPC/DNS en Microsoft Windows está dando que hablar por su gravedad y rápida evolución. El pasado día 13 de abril emitíamos un boletín con carácter de urgencia previendo el potencial alcance del problema. Las sospechas se han confirmado y hoy esta vulnerabilidad supone una seria amenaza en muchos entornos.
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.

Fuente: Hispasec Sistemas