lunes, 13 de septiembre de 2010

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.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Adobe Reader zero-day attack ? now with stolen certificate
http://www.securelist.com/en/blog?weblogid=2287

Security Advisory for Adobe Reader and Acrobat
http://www.adobe.com/support/security/advisories/apsa10-02.html

CVE-2010-2883 Adobe 0-Day
http://contagiodump.blogspot.com/2010/09/cve-david-leadbetters-one-point-lesson.html

Vulnerabilidad crítica en Apple QuickTime permite ejecución de código
http://www.hispasec.com/unaaldia/4328

La nueva variante del Stuxnet vuelve a estar firmada con un certificado válido
http://www.hispasec.com/unaaldia/4288

No hay comentarios:

Publicar un comentario en la entrada