Se descubre otro 0 day en Adobe Acrobat muy sofisticado

A estas alturas, ya no es noticia que se descubra un problema de seguridad en los gestores de PDF de Adobe previamente desconocido y siendo aprovechado por los atacantes. Últimamente, es el día a día de esta compañía. Este último fallo de seguridad destaca porque es muy sofisticado, elude las protecciones de los últimos Windows, y además está firmado digitalmente.

Se ha descubierto un nuevo ataque contra las últimas versiones de Adobe Reader y Adobe Acrobat. Se trata de un desbordamiento de memoria intermedia al realizar una llamada a la función strcat en la libraría CoolType.dll y permite a un atacante ejecutar código en el sistema si la víctima abre (con estos programas de Adobe) un fichero PDF que utilice un tipo de letra manipulada. El fallo es público, está siendo aprovechado por atacantes en estos momentos y Adobe ya lo ha reconocido. La propia compañía confirma que no existe parche ni contramedida propia disponible (habitualmente era suficiente con desactivar JavaScript para, al menos, mitigar el problema, pero no es el caso en esta ocasión). Ha actualizado su alerta para indicar que, gracias a Microsoft's Enhanced Mitigation Evaluation Toolkit (EMET) es posible bloquear el ataque.

Este escenario, aunque potencialmente muy peligroso, no es sorprendente ni nuevo. Sorprende sin embargo las peculiaridades con las que los atacantes han aprovechado el fallo para ejecutar el código arbitrario (que, evidentemente, resulta en malware). Lo más llamativo es que los atacantes han trabajado a fondo para poder aprovechar la vulnerabilidad usando técnicas muy parecidas a dos de las que recientemente hemos hablado en una-al-día: Las que usara hace poco Rubén Santamarta para aprovechar un fallo en Quicktime; y el uso de certificados reales para firmar el malware, como el "reciente" troyano Stuxnet.

A primera vista, el fallo no es sencillo de explotar. Al desbordar la memoria, la pila queda en un estado no demasiado "ideal" para utilizar la dirección de retorno adecuada y ejecutar código. Para eludir estos problemas, los atacantes han usado una librería icucnv36.dll que no soporta ASLR (básicamente, siempre está en la misma zona de memoria y esto sirve de referencia para lanzar código) y han usado una técnica conocida como ROP (Return oriented programming). Hasta aquí, el ataque es muy parecido al que descubrió Santamarta en Quicktime, y demuestra una gran habilidad del atacante. Para colmo en este caso, dado que la librería no da mucho juego (no importa funciones interesantes que permitan fácilmente la llamada a código) el atacante se vale de otras menos potentes que, combinadas, consiguen su objetivo. Todo un alarde de conocimientos.

Una vez ejecutado, el binario que ejecutan los atacantes (incrustado en el PDF, aunque también descarga otros) está firmado con un certificado real y robado, igual que hizo Stuxnet hace un par de meses (se trata del malware que se ejecutaba gracias a la infame vulnerabilidad en los archivos LNK de Windows). En este caso se trata de un certificado robado a Vantage Credit Union. Otro toque de profesionalidad. Hay quien pronostica que el malware firmado será tendencia en 2011.

Adobe tiene previsto su siguiente ciclo de actualizaciones en octubre, pero (una vez más), seguro que publica un parche antes. Desde hace tiempo, el periodo de tres meses que eligieron para publicar parches les viene demasiado largo, y las excepciones en las que han tenido que romper el ciclo y publicar parches "a destiempo" han sido numerosas.

Fuente Hispasec.com

Atacan nueva vulnerabilidad "dia cero" de Adobe PDF

Adobe sonó hoy la alarma por una nueva falla de día cero en su software Reader/Acrobat para PDF, advirtiendo que hackers están explotando activamente la vulnerabilidad en la práctica.

Los detalles de la vulnerabilidad aún no son públicos pero la repentina advertencia de Adobe es una señal segura que documentos PDF manipulados están siendo usados por hackers maliciosos para tomar el control completo de máquinas con las últimas versiones del Adobe Reader/Acrobat instalado.

Aquí está la advertencia de Adobe:

Existe una vulnerabilidad critica en Adobe Reader 9.3.4 y versiones anteriores para Windows, Macintosh y Unix, y Adobe Acrobat 9.3.4 y anteriores para Windows y Macintosh. Esta vulnerabilidad (CVE-2010-2883) podría causar un crash y potencialmente permitir a un atacante tomar control del sistema afectado. Hay informes que esta vulnerabilidad está siendo explotada activamente en la práctica.
Adobe está en el proceso de evaluar la fecha para una actualización que resuelva esta vulnerabilidad.

De forma inquietante, Adobe dice no poder ofrecer ningún consejo previo al parche para ayudar a los usuarios a frustrar los ataques.

Lamentablemente, no podemos ofrecer ninguna mitigación. Sin embargo, Adobe esta compartiendo activamente información sobre esta vulnerabilidad (y las vulnerabilidades en general) con socios en la comunidad de seguridad para permitirles desarrollar rápidamente los métodos de detección y cuarentena para proteger a los usuarios hasta que esté disponible un parche. Como siempre, Adobe recomienda a los usuarios seguir las mejores prácticas de seguridad manteniendo sus programas anti-malware y definiciones actualizados.

Una portavoz de Adobe describió el ataque como "limitado" pero advirtió que eso puede cambiar con la disponibilidad pública del código de explotación. Dijo que la compañía fue notificada ayer sobre los ataques (martes 7 de septiembre de 2010) a través de información de una compañía privada compañera.

Los programas afectados incluyen:

* Adobe Reader 9.3.4 y versiones anteriores para Windows, Macintosh y UNIX
* Adobe Acrobat 9.3.4 y versiones anteriores para Windows y Macintosh

El próximo lote de parches para Adobe Reader/Acrobat está programado para el 12 de octubre de 2010 pero es probable que la compañía publique una actualización fuera de calendario para este asunto.

ACTUALIZACIÓN: Un PDF de ejemplo del ataque está disponible públicamente. Apunta a usuarios Windows, afecta a Acrobat 8 y 9, explota múltiples versiones a la vez, y elude [las protecciones] DEP y ASLR.

Fuente Segu-Info.com.ar

Fallo de seguridad en la carga dinámica de librerías en Windows

FUENTE INTECO.ES

Importancia: 5 - Máxima
Fecha de publicación: 24/08/2010
Recursos afectados
Multitud de aplicaciones para Windows (todavía no confirmadas)

Descripción

Se ha publicado un fallo de seguridad relacionado con la carga dinámica de librerías que afecta a multitud de aplicaciones para Windows y que pueden permitir a un atacante ejecutar código malicioso y comprometer un equipo.
Solución

Microsoft ha publicado una solución provisional para deshabilitar la carga de librerías de WebDAV y recursos compartidos remotos (se abre en nueva ventana) hasta que esté disponible una actualización de 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ón derecho sobre WebClient y selecionar propiedades
* Cambiar el tipo de inicio a Disable. En el caso de que esté ejecutándose pulsar Stop

Nota: Después de aplicar esta solución todavía 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 área local (LAN) aunque se les pedirá confirmación antes de ejecutar dichos programas desde Internet.

Otra solución adicional consistiría en bloquear los puertos 139 y 445 en el cortafuegos. Estos puertos se utilizan para iniciar una conexión con el componente afectado. Microsoft recomienda bloquear toda comunicación entrante no solicitada desde Internet para impedir ataques que puedan utilizar otros puertos.
Detalle

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ía de los casos, el usuario tendrá que ir al directorio y después abrir dicho archivo. El fallo reside en la aplicación encargada de gestionar dicho fichero que cargará una DLL desde el directorio de trabajo.

Cuando una aplicación carga dinámicamente una librería de enlace dinámico (DLL) sin especificar un nombre de ruta de acceso completa, Windows intenta localizar el archivo DLL mediante la búsqueda en una serie de directorios definidos. Si un atacante obtiene el control de uno de los directorios, pueden forzar a la aplicación a 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ía de sistemas operativos que soportan carga dinámica de librerías compartidas.

El siguiente sería un ejemplo de carga de librería de forma insegura:

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

HMODULE handle = LoadLibrary(result);

De acuerdo con la función anterior, la aplicación buscará "schannel.dll" por medio de la ruta de búsqueda menos segura. Si un atacante puede poner schannel.dll en CWD (Current Working Directory), se cargará incluso antes de que la aplicación busque los directorios de Windows para la librería adecuada.

Esta vulnerabilidad, por tanto, puede ser explotada mediante el envío al usuario de un enlace a un recurso compartido, por ejemplo, \\servidor\peliculas\ junto con un conjunto de ficheros que se vean afectados por esta vulnerabilidad. El usuario intentará abrir cualquiera de esos ficheros, por ejemplo un fichero multimedia, y el programa encargado de reproducirlo cargará una o mas DLL que contendrán el código malicioso. iTunes se vio afectado por este fallo de seguridad la semana pasada pero se ha descubierto que la mayoría de las aplicaciones para Windows (se abre en nueva ventana) tienen esta vulnerabilidad también.

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ún afirma este, a principios de este año, Taeho Kwon y Zhendong Su de la Universidad de California, publicaron un document o titulado "Automatic Detection of Vulnerable Dynamic Component Loadings" donde ya se describían las diferentes variantes de DLL hijacking además de mostrarse una lista de aplicaciones vulnerables.

Microsoft recomienda que los desarrolladores de software definan con claridad desde dónde van a cargar librerías específicas y ha publicado recientemente un artículo para MSDN denominado "Dynamic-Link Library Security" que proporciona orientación a los desarrolladores sobre cómo cargar las librerías de manera segura. De forma genérica las recomendaciones son:

* Siempre que sea posible, utilice un nombre de ruta de acceso completa al cargar una librería;
* Elimine el directorio actual de la ruta de búsqueda mediante el uso de SetDLLDirectory;
* No utilizar SearchPath para ubicar una librería.
* No cargar librerías exclusivamente para identificar la versión de Windows. En su lugar, utilice GetVersionEx, o una función similar 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écnico