Nuevas técnicas de exploiting: Caso Adobe Reader
Se detectan nuevas técnicas de explotación en el último 0-day en Adobe Reader reportado por FireEye.
El pasado 12 de Febrero podíamos leer desde el blog de FireEye el último 0-day que afectaba a las versiones más recientes de Adobe PDF Reader (9.5.3, 10.1.5, y 11.0.1) el cual ha sido utilizado en ataques dirigidos contra ciertas organizaciones mediante spear phishing attacks. Lo que ha hecho realmente interesante a este exploit han sido las técnicas avanzadas empleadas para eludir ASLR (Address space layout randomization) y DEP (Data Execution Prevention) a partir de un memory disclosure y, sobre todo, las técnicas utilizadas para "escapar" de su sandbox. Incluso investigadores de Kaspersky, en declaraciones a Threatpost , indicaban que se trataba del primer exploit en eludir dicha sandbox en Acrobar Reader. Asimismo Roel Schouwenberg (investigador de seguridad de Kaspersky Lab) corroboraba el éxito de dicho exploit sobre un Windows 7x64 con un Adobe Reader 11.0.1. Por este motivo multitud de blogs de seguridad se han hecho eco de este 0-day durante los últimos días.
La vulnerabilidad útilizada para conseguir ejecutar código reside en el módulo AcroForm.api en donde se ha podido tener acceso a un puntero vtable mediante heap spray . Según se describe en el blog de McAfee dicho exploit consta de tres partes bien diferenciadas:
•Por un lado, el JavaScript necesario para generar el heap spray junto con el payload en el que se implementaban ROP gadgets para eludir ASLR y DEP, así como el Javascript para aprovecharse de la vulnerabilidad manipulando objetos XFA (Adobe XML Forms Architecture) . Lo interesante en este punto es que el shellcode utilizado para ejecutar código está implementando en la propia cadena ROP, la cual es construida en runtime tras comprobar la versión de Adobe Reader utilizada por la víctima (comprobación que es realizada también por medio de JavaScript). Con esta técnica se conseguiría eludir la mayor parte de métodos utilizados para la detección de shellcodes, los cuales se basan en el monitorización de determinadas direcciones dentro de módulos leǵitimos.
•Un objeto XFA codificado.
•Un stream binario relacionado con las DLL maliciosas que serán guardadas en disco y ejecutadas en memoria. Esto será llevado a cabo por el shellcode, el cual, se encargará de descrifrar una de las DLL y cargarla dentro del espacio de direcciones del proceso (dentro de la sandbox), además de descargarla en AppData\Local\Temp\acrord32_sbx . Dicha DLL a su vez permitiría guardar más DLLs y eludir el sandbox mediante la explotación de otra vulnerabilidad. Por último, el shellcode lograría cargar una segunda librería en memoria encargada de comunicarse con un dominio remoto. Para hacer más creíble el ataque, una de las DLL crearía un nuevo proceso para mostrar al usuario un documento PDF de señuelo.
Pueden observarse por tanto dos vulnerabilidades explotadas (clasificadas actualmente como CVE-2013-0640 y CVE-2013-0641), las cuales cuentan con técnicas muy sofisticadas para eludir las contramedidas del sistema operativo (ASLR y DEP) y a la propia sandbox de Adobe.
Tras las últimas investigaciones de FireEye, se ha podido comprobar que el código malicioso realiza diversas peticiones GET y POST contra un servidor remoto desde donde se descargaban nuevos payloads cuyo objetivo se está investigando actualmente.
Como dato curioso y, a raiz del campo "preferred Image Base" 666C utilizado por el malware, la gente de FireEye ha apodado este troyano como "Trojan.666" al pensar que dicha dirección pudiera hacer alusión a la canción "The Number of the Beast" de "Iron Maiden".
Estos hechos reflejan que las técnias de exploiting continúan evolucionando y perfeccionándose para eludir todo tipo de contramedidas, algo cada vez más demandado por cibercriminales que tratan de llevar a cabo ataques dirigidos contra todo tipo de organismos. De nuevo se corrobora que el uso conjunto de medidas de seguridad (Firewalls, IDS, AVs, software actualizado, herramientas auxiliares como EMET, etc.) será el arma más efectiva para frenar este tipo de ataques.
Como medida de prevención se aconseja habilitar la vista protegida (protected view) y deshabilitar de forma permanante JavaScript desde Edit -> Preferences -> JavaScript -> "Enable Acrobat JavaScript". El motivo es que JavaScript suele ser el detonante utilizado para llevar a cabo el heap-spray para conseguir situar el shellcode en un área predecible de memoria al permitir declarar variables de forma sencilla que son asignadas en memoria dinámica.
Fuente: Inteco
El pasado 12 de Febrero podíamos leer desde el blog de FireEye el último 0-day que afectaba a las versiones más recientes de Adobe PDF Reader (9.5.3, 10.1.5, y 11.0.1) el cual ha sido utilizado en ataques dirigidos contra ciertas organizaciones mediante spear phishing attacks. Lo que ha hecho realmente interesante a este exploit han sido las técnicas avanzadas empleadas para eludir ASLR (Address space layout randomization) y DEP (Data Execution Prevention) a partir de un memory disclosure y, sobre todo, las técnicas utilizadas para "escapar" de su sandbox. Incluso investigadores de Kaspersky, en declaraciones a Threatpost , indicaban que se trataba del primer exploit en eludir dicha sandbox en Acrobar Reader. Asimismo Roel Schouwenberg (investigador de seguridad de Kaspersky Lab) corroboraba el éxito de dicho exploit sobre un Windows 7x64 con un Adobe Reader 11.0.1. Por este motivo multitud de blogs de seguridad se han hecho eco de este 0-day durante los últimos días.
La vulnerabilidad útilizada para conseguir ejecutar código reside en el módulo AcroForm.api en donde se ha podido tener acceso a un puntero vtable mediante heap spray . Según se describe en el blog de McAfee dicho exploit consta de tres partes bien diferenciadas:
•Por un lado, el JavaScript necesario para generar el heap spray junto con el payload en el que se implementaban ROP gadgets para eludir ASLR y DEP, así como el Javascript para aprovecharse de la vulnerabilidad manipulando objetos XFA (Adobe XML Forms Architecture) . Lo interesante en este punto es que el shellcode utilizado para ejecutar código está implementando en la propia cadena ROP, la cual es construida en runtime tras comprobar la versión de Adobe Reader utilizada por la víctima (comprobación que es realizada también por medio de JavaScript). Con esta técnica se conseguiría eludir la mayor parte de métodos utilizados para la detección de shellcodes, los cuales se basan en el monitorización de determinadas direcciones dentro de módulos leǵitimos.
•Un objeto XFA codificado.
•Un stream binario relacionado con las DLL maliciosas que serán guardadas en disco y ejecutadas en memoria. Esto será llevado a cabo por el shellcode, el cual, se encargará de descrifrar una de las DLL y cargarla dentro del espacio de direcciones del proceso (dentro de la sandbox), además de descargarla en AppData\Local\Temp\acrord32_sbx . Dicha DLL a su vez permitiría guardar más DLLs y eludir el sandbox mediante la explotación de otra vulnerabilidad. Por último, el shellcode lograría cargar una segunda librería en memoria encargada de comunicarse con un dominio remoto. Para hacer más creíble el ataque, una de las DLL crearía un nuevo proceso para mostrar al usuario un documento PDF de señuelo.
Pueden observarse por tanto dos vulnerabilidades explotadas (clasificadas actualmente como CVE-2013-0640 y CVE-2013-0641), las cuales cuentan con técnicas muy sofisticadas para eludir las contramedidas del sistema operativo (ASLR y DEP) y a la propia sandbox de Adobe.
Tras las últimas investigaciones de FireEye, se ha podido comprobar que el código malicioso realiza diversas peticiones GET y POST contra un servidor remoto desde donde se descargaban nuevos payloads cuyo objetivo se está investigando actualmente.
Imagen extraída de www.fireeye.com/
Como dato curioso y, a raiz del campo "preferred Image Base" 666C utilizado por el malware, la gente de FireEye ha apodado este troyano como "Trojan.666" al pensar que dicha dirección pudiera hacer alusión a la canción "The Number of the Beast" de "Iron Maiden".
Estos hechos reflejan que las técnias de exploiting continúan evolucionando y perfeccionándose para eludir todo tipo de contramedidas, algo cada vez más demandado por cibercriminales que tratan de llevar a cabo ataques dirigidos contra todo tipo de organismos. De nuevo se corrobora que el uso conjunto de medidas de seguridad (Firewalls, IDS, AVs, software actualizado, herramientas auxiliares como EMET, etc.) será el arma más efectiva para frenar este tipo de ataques.
Como medida de prevención se aconseja habilitar la vista protegida (protected view) y deshabilitar de forma permanante JavaScript desde Edit -> Preferences -> JavaScript -> "Enable Acrobat JavaScript". El motivo es que JavaScript suele ser el detonante utilizado para llevar a cabo el heap-spray para conseguir situar el shellcode en un área predecible de memoria al permitir declarar variables de forma sencilla que son asignadas en memoria dinámica.
Fuente: Inteco
Comentarios
Publicar un comentario