Nuevo fallo de Microchoft

Microsoft ha publicado una soluci?rovisional para deshabilitar la carga de librer? de WebDAV y recursos compartidos remotos hasta que est?isponible una actualizaci?e seguridad que ayude a solucionar y bloquear parte de los ataques conocidos hasta el momento.

Para mayor seguridad puede deshabilitarse el cliente WebDaV mediante los siguientes pasos:

• Pulsar en inicio -> ejecutar y escribir Services.msc
• Bot?erecho sobre WebClient y selecionar propiedades
• Cambiar el tipo de inicio a Disable. En el caso de que est?jecut?ose pulsar Stop

Nota: Despu?de aplicar esta soluci?odav?es posible para un atacante remoto explotar esta vulnerabilidad provocando que Microsoft Office Outlook ejecute programas ubicados en el ordenador del usuario o en la red de ?a local (LAN) aunque se les pedir?onfirmaci?ntes de ejecutar dichos programas desde Internet.

Otra soluci?dicional consistir?en bloquear los puertos 139 y 445 en el cortafuegos. Estos puertos se utilizan para iniciar una conexi?on el componente afectado. Microsoft recomienda bloquear toda comunicaci?ntrante no solicitada desde Internet para impedir ataques que puedan utilizar otros puertos.

Esta vulnerabilidad se produce cuando un tipo de archivo vulnerable es abierto desde dentro de un directorio controlado por el atacante. Este directorio puede ser una unidad USB, un recurso compartido en red o WebDAV. En la mayor?de los casos, el usuario tendr?ue ir al directorio y despu?abrir dicho archivo. El fallo reside en la aplicaci?ncargada de gestionar dicho fichero que cargar?na DLL desde el directorio de trabajo.

Cuando una aplicaci?arga din?camente una librer?de enlace din?co (DLL) sin especificar un nombre de ruta de acceso completa, Windows intenta localizar el archivo DLL mediante la b?eda en una serie de directorios definidos. Si un atacante obtiene el control de uno de los directorios, pueden forzar a la aplicaci? cargar una copia de una DLL maliciosa en lugar de la DLL que la apliCacion esperaba. Estos ataques se conocen como «ataques de precarga DLL» y son comunes en la mayor?de sistemas operativos que soportan carga din?ca de librer? compartidas.

El siguiente ser?un ejemplo de carga de librer?de forma insegura:

DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL);

HMODULE handle = LoadLibrary(result);

De acuerdo con la funci?nterior, la aplicaci?uscar?schannel.dll» por medio de la ruta de b?eda menos segura. Si un atacante puede poner schannel.dll en CWD (Current Working Directory), se cargar?ncluso antes de que la aplicaci?usque los directorios de Windows para la librer?adecuada.

Esta vulnerabilidad, por tanto, puede ser explotada mediante el env?al usuario de un enlace a un recurso compartido, por ejemplo, servidorpeliculas junto con un conjunto de ficheros que se vean afectados por esta vulnerabilidad. El usuario intentar?brir cualquiera de esos ficheros, por ejemplo un fichero multimedia, y el programa encargado de reproducirlo cargar?na o mas DLL que contendr?el c?o malicioso. iTunes se vio afectado por este fallo de seguridad la semana pasada pero se ha descubierto que la mayor?de las aplicaciones para Windows tienen esta vulnerabilidad tambi?

Al parecer, dicho fallo de seguridad fue descubierto la semana pasada al investigar sobre la vulnerabilidad .lnk por el experto de seguridad HD Moore; pero seg?firma este, a principios de este a?Taeho Kwon y Zhendong Su de la Universidad de California, publicaron un documento titulado «Automatic Detection of Vulnerable Dynamic Component Loadings» donde ya se describ? las diferentes variantes de DLL hijacking adem?de mostrarse una lista de aplicaciones vulnerables.

Microsoft recomienda que los desarrolladores de software definan con claridad desde d? van a cargar librer? espec?cas y ha publicado recientemente un art?lo para MSDN denominado «Dynamic-Link Library Security» que proporciona orientaci? los desarrolladores sobre c?cargar las librer? de manera segura. De forma gen?ca las recomendaciones son:

• Siempre que sea posible, utilice un nombre de ruta de acceso completa al cargar una librer?
• Elimine el directorio actual de la ruta de b?eda mediante el uso de SetDLLDirectory;
• No utilizar SearchPath para ubicar una librer?
• No cargar librer? exclusivamente para identificar la versi?e Windows. En su lugar, utilice GetVersionEx, o una funci?imilar que ofrece la API de Windows.

Microsoft ha elaborado recientemente un documento para orientar y ayudar a los desarrolladores a entender este problema.

Mientras los fabricantes de software afectado desarrollen parches para solucionar el problema, se recomienda llevar a cabo las soluciones temporales propuestas por Microsoft y comentadas en el presente aviso t?ico