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.
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
Protegerse del exploit de Adobe.
Recientemente Microsoft ha lanzado EMET 2.0 que es una herramienta gratuita que implanta medidas de seguridad en las aplicaciones sin necesidad de ser compiladas de nuevo.
Utilizando esta herramienta es posible protegerse contra diferente tipos de exploits a ataques a aplicaciones de terceros y que generalmente son utilizadas sobre Windows.
Un ejemplo puede ser el reciente 0-day en Adobe Acrobat (uno de los cientos que abundan en las aplicaciones de Adobe). Para proteger Adobe Reader con EMET, el proceso es muy simple y se puede realizar por linea de comando o a través de su interface de la siguiente manera.
Descargar EMET (es gratuito) e instalarlo. Una vez instalado se ejecuta y por defecto EMET muestras las aplicaciones que se están ejecutando en ese momento y las medidas de protección que incorporan esas aplicaciones (DEP – Dynamic Data Execution Prevention, SEHOP – Structure Exception Handler Overwrite Protection, ASLR Space Layout Randomisation y Null Page Allocation)
Para proteger cualquier programa con EMET se debe agregar la aplicación deseada (botón “Configure Apps”) y indicar que se desea protegerla:
A partir de ese momento cada vez que se ejecute dicha aplicación, la misma será controlada por EMET para evitar la ejecución arbitraria de código no autorizado. Este proceso se debe realizar por única vez con cada aplicación a proteger.
Fuente: Segu-Info
