Sobre Stuxnet y la vulnerabilidad de los iconos de los accesos directos

Hoy Microsoft ha liberado la tan ansiada actualización de seguridad que corrige la vulnerabilidad VU#940193, descrita en este artículo. Aprovecho para recomendar que si no lo ha hecho ya, acuda a Windows Update para instalar esta actualización y mantener su sistema al día.

La vulnerabilidad en cuestión se aprovecha de que el manejador de iconos de accesos directos (.lnk y .pif) que incorpora Windows no valida lo suficiente las estructuras del acceso directo a la hora de cargar el correspondiente icono. Más concretamente, la vulnerabilidad se produce cuando el acceso directo está diseñado de tal manera que la DLL Shell32.dll descuidadamente llama a la API LoadLibrary con una DLL maliciosa como parámetro. La API LoadLibrary invoca al método principal (DllMain) de la DLL maliciosa, por lo que ya tenemos un bonito rootkit instalado en nuestro sistema.

La gran repercusión de esta vulnerabilidad se debe principalmente a estos puntos:

• Estaba siendo explotada por varios virus sin que el fabricante hubiera lanzado la correspondiente actualización de seguridad.
• La automatización de la vulnerabilidad es bastante elevada. Simplemente con abrir un dispositivo USB infectado (sin necesidad de hacer clic en nada más), el sistema queda infectado.
• El código malicioso misteriosamente aparece con una firma digital de dos fabricantes de hardware bastante conocidos: JMicron y Realtek Corporation.
• Control de cuentas de usuario (UAC) mitiga pero no evita que el software malicioso que aprovecha la vulnerabilidad cause daños importantes en el sistema, pese a tener privilegios limitados.

Nos planteamos dos cuestiones principales:

¿La firma digital es garantía de seguridad?

Ciertamente las firmas digitales en el software han venido siendo un indicador de que el fabricante que lo proporciona no intentará hacer nada malo, al menos conscientemente. De hecho, Windows se basa cada vez más en las firmas digitales para ayudar al usuario a decidir si es recomendable ejecutar o instalar cierto software; tómese como ejemplo la implementación de Control de cuentas de usuario (UAC), que muestra un color diferente dependiendo de si el ejecutable lleva firma digital, no la lleva, o es parte de Windows.

Lo que es cierto es que los autores de malware son conscientes de este hecho y cada vez más intentan incorporar una firma digital en su código malicioso. El asunto es más goloso si cabe puesto que el software antivirus suele hacer la vista gorda cada vez que se encuentra con un fichero firmado digitalmente. La cruda realidad es que actualmente ya hay varias cepas de malware que incluyen de alguna forma una firma digital. El caso más sencillo es el malware que adjunta una firma digital inválida, copiada de algún fabricante de renombre. La firma digital será catalogada como no válida, obviamente, pero el usuario puede que solo se dé cuenta de ello al intentar ejecutar el programa, al ver el correspondiente aviso en la ventana de Control de cuentas de usuario.

Otra manera que usan los autores de malware es conseguir que su código sea firmado por una autoridad de certificación con un nombre de empresa. Lamentablemente, pese a que las autoridades de certificación digan lo contrario, se han dado bastantes casos de certificados otorgados a autores de malware. Afortunadamente, las políticas de control de certificación de código en modo núcleo son bastante más estrictas, por lo que incluir un controlador malicioso en un sistema Windows Vista/7 de 64 bits es tarea complicada.

La última forma, y la que quizá podría haber aprovechado Stuxnet, consiste en robar la clave privada Authenticode a una empresa de desarrollo de software. Existe malware especializado en obtener certificados, como por ejemplo Ursnif o Zeus. Los desarrolladores de aplicaciones suelen usar la misma máquina para desarrollar y para acceder a Internet, por lo que no es raro que esas máquinas acaben infectándose y permitiendo que el atacante acceda ilegítimamente a esos certificados digitales. En el caso de Stuxnet aún hay dudas al respecto principalmente porque se da la casualidad de que las empresas cuyos certificados han sido robados (Realtek y JMicron) comparten ciudad, por lo que podría tratarse de algún tipo de filtración humana.

¿Control de cuentas de usuario es la solución a los virus?

Ni Control de cuentas de usuario, ni el uso de una cuenta de usuario limitado nos garantizan que nuestro sistema no se infecte, ni tampoco que si se infecta los daños sean poco importantes. Es cierto que un entorno sin privilegios administrativos evita que los programas maliciosos tengan el control total de máquina (crear servicios, instalar software adicional, instalar controladores, etc.), pero no es menos cierto que los autores de malware están centrándose en elaborar código malicioso que haga el máximo daño posible sin necesidad de privilegios administrativos. Recuerdo cierto virus que cifraba los documentos personales del usuario y posteriormente le pedía dinero para poder recuperarlos. En concreto, Stuxnet inyecta “ganchos” en ciertas funciones de algunas DLL del sistema (como Ntdll.dll o Kernel32.dll), con el objetivo de engañar al sistema cuando, por ejemplo, intente listar los ficheros de un directorio. En este vídeo se puede ver como el virus se oculta automáticamente incluso en una cuenta con privilegios limitados.

Stuxnet se ha propagado a una gran velocidad y con solo abrir un dispositivo USB infectado, pero si algo podríamos aprender de este virus es que por sí solo un usuario con privilegios limitados aún es vulnerable a daños importantes en su equipo, y que la firma digital en el software no es indicador de ausencia de peligro. Como siempre, la recomendación es mantener unas estrictas políticas de restricción de software (especialmente en empresas), unidas a unas prácticas de sentido común y complementadas con un antivirus/cortafuegos, así como con un sistema operativo y aplicaciones actualizados.