{"id":19996,"date":"2020-09-01T09:14:01","date_gmt":"2020-09-01T15:14:01","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=19996"},"modified":"2020-09-01T09:14:01","modified_gmt":"2020-09-01T15:14:01","slug":"black-hat-macos-macros-attack","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/black-hat-macos-macros-attack\/19996\/","title":{"rendered":"C\u00f3mo atacar macOS con una macro maliciosa"},"content":{"rendered":"

Muchos usuarios de macOS a\u00fan conf\u00edan en que sus equipos no necesitan protecci\u00f3n. Y, lo que es peor, los administradores de sistemas de las empresas en las que los empleados trabajan con hardware<\/em> de Apple suelen pensar lo mismo.<\/p>\n

En la conferencia Black Hat USA 2020<\/a>, el investigador Patrick Wardle intent\u00f3 cambiar la opini\u00f3n del p\u00fablico sobre este concepto err\u00f3neo presentando su an\u00e1lisis de malware<\/em> para macOS y construyendo una cadena de exploits<\/em> para tomar el control de una computadora Apple.<\/p>\n

\u00a0<\/p>\n

Microsoft, macros y Mac<\/h2>\n

Una de las formas m\u00e1s comunes de atacar a las computadoras que ejecutan macOS es a trav\u00e9s de documentos con macros maliciosas, es decir, a trav\u00e9s de aplicaciones de Microsoft Office. De hecho, a pesar de la disponibilidad de las propias aplicaciones de productividad de Apple, muchos usuarios prefieren utilizar Microsoft Office. Algunos lo hacen por costumbre; otros por la compatibilidad con los documentos que generan sus compa\u00f1eros.<\/p>\n

Por supuesto, todo el mundo conoce desde hace mucho tiempo la amenaza potencial que plantean los documentos que contienen macros. Por ello, tanto Microsoft como Apple cuentan con mecanismos para proteger al usuario.<\/p>\n

Microsoft alerta a los usuarios cuando abren un documento que contiene una macro. Adem\u00e1s, si el usuario decide iniciar la macro de todos modos, el c\u00f3digo se ejecuta en un sandbox<\/em> o entorno de pruebas que, seg\u00fan los desarrolladores de Microsoft, evita que el c\u00f3digo acceda a los archivos del usuario o cause otros da\u00f1os al sistema.<\/p>\n

En lo que respecta a Apple, la compa\u00f1\u00eda introdujo varias funciones de seguridad nuevas en la \u00faltima versi\u00f3n de su sistema operativo, macOS Catalina. En concreto, se incluyen la cuarentena de archivos y la \u201cnotarizaci\u00f3n\u201d, una tecnolog\u00eda que evita el lanzamiento de ejecutables desde fuentes externas.<\/p>\n

B\u00e1sicamente, la combinaci\u00f3n de estas tecnolog\u00edas deber\u00eda bastar para evitar cualquier da\u00f1o de macros maliciosas. En teor\u00eda, todo parece bastante seguro.<\/p>\n

\u00a0<\/p>\n\n

\u00a0<\/p>\n

Una cadena de exploits<\/em> extrae la macro del sandbox<\/h2>\n

En la pr\u00e1ctica, sin embargo, muchos mecanismos de seguridad se implementan de manera bastante problem\u00e1tica. Por lo tanto, los investigadores (o atacantes) pueden encontrar m\u00e9todos para evitarlos. Wardle ilustr\u00f3 su presentaci\u00f3n demostrando una cadena de exploits<\/em>.<\/p>\n

1. Omitir el mecanismo que deshabilita las macros<\/h3>\n

Tomemos como ejemplo el sistema que advierte al usuario cuando detecta una macro en un documento. En la mayor\u00eda de los casos, funciona seg\u00fan lo previsto por los desarrolladores. Pero al mismo tiempo, es posible crear un documento en el que la macro se inicie autom\u00e1ticamente y sin notificar al usuario, incluso aunque las macros se hayan deshabilitado en la configuraci\u00f3n.<\/p>\n

Esto es posible utilizando el formato de archivo Sylk<\/a> (SLK). Este formato, que utiliza el lenguaje de macros XLM, se desarroll\u00f3 en la d\u00e9cada de los 80 y se actualiz\u00f3 por \u00faltima vez en 1986. Sin embargo, las aplicaciones de Microsoft (por ejemplo, Excel) todav\u00eda admiten Sylk por razones de compatibilidad con versiones anteriores. Esta vulnerabilidad no es nueva y se describi\u00f3 con detalle<\/a> en el 2019.<\/p>\n

\u00a0<\/p>\n

2. Escapar del sandbox<\/em><\/h3>\n

Como acabamos de establecer, un atacante puede ejecutar una macro de forma invisible. Pero el c\u00f3digo se sigue ejecutando en el sandbox<\/em> de MS Office. Entonces, \u00bfc\u00f3mo puede el cibercriminal atacar la computadora? Bueno, resulta que no es tan dif\u00edcil escapar del sandbox<\/em> de Microsoft en Mac.<\/p>\n

Es cierto que no puedes modificar archivos que ya est\u00e1n almacenados en tu computadora desde el sandbox<\/em>. Sin embargo, s\u00ed puedes crearlos<\/em>. Este exploit<\/em> ya se ha utilizado antes para escapar del sandbox<\/em> y parece que Microsoft lanz\u00f3 una actualizaci\u00f3n para cerrar la vulnerabilidad. Sin embargo, el problema no lleg\u00f3 a resolverse y, como ha demostrado un an\u00e1lisis m\u00e1s detallado del parche, la soluci\u00f3n abord\u00f3 los s\u00edntomas, bloqueando la creaci\u00f3n de archivos desde lugares que algunos de los desarrolladores consideraban inseguros, como la carpeta LaunchAgents, que es la ubicaci\u00f3n de almacenamiento para las secuencias de comandos que se inician autom\u00e1ticamente despu\u00e9s de reiniciar el equipo.<\/p>\n

Pero \u00bfqui\u00e9n decidi\u00f3 que Microsoft tuviera en cuenta todas las \u201cubicaciones peligrosas\u201d a la hora de crear el parche? Como sucedi\u00f3, un script<\/em> escrito en Python y lanzado desde un documento de Office, y por lo tanto ejecutado en un sandbox<\/em>, se pudo usar para crear un objeto llamado \u201c\u00edtem de inicio\u201d. Cuando el usuario inicia sesi\u00f3n en el sistema, se genera un objeto con ese nombre de forma autom\u00e1tica. El sistema lanza el objeto, por lo que se ejecutar\u00e1 fuera<\/em> del sandbox<\/em> de Office y, por lo tanto, evitar\u00e1 las restricciones de seguridad de Microsoft.<\/p>\n

\u00a0<\/p>\n

3. Eludir los mecanismos de seguridad de Apple<\/h3>\n

Bueno, ahora sabemos c\u00f3mo ejecutar en secreto una macro y crear un \u00edtem de inicio. Por supuesto, los mecanismos de seguridad en macOS a\u00fan siguen evitando que se inicie la puerta trasera, que despu\u00e9s de haber sido creada por un proceso sospechoso desde el interior del sandbox<\/em> no es de confianza, \u00bfverdad?<\/p>\n

Por un lado, s\u00ed: los mecanismos de seguridad de Apple efectivamente bloquean la ejecuci\u00f3n del c\u00f3digo obtenido de esta forma. Por otro lado, hay una soluci\u00f3n alternativa: si insertas un archivo ZIP como un \u00edtem de inicio, en el siguiente inicio de sesi\u00f3n, el sistema descomprimir\u00e1 autom\u00e1ticamente el archivo.<\/p>\n

Todo lo que le queda por hacer al atacante es elegir la ubicaci\u00f3n correcta para descomprimir el archivo. Por ejemplo, el archivo se puede colocar en el mismo directorio que las bibliotecas de usuario, un paso por encima de aquel donde se supone que deben almacenarse los objetos de tipo Launch Agent (los que Microsoft considera peligrosos). El archivo en s\u00ed puede incluir un directorio llamado LaunchAgents, con el script<\/em> Launch Agent.<\/p>\n

Una vez descomprimido, el script<\/em> se ubica en la carpeta LaunchAgents para ejecutarse tras el reinicio del equipo. Al haber sido creado por un programa de confianza (The Archiver) y no tener atributos en cuarentena, puede usarse para lanzar algo m\u00e1s peligroso. Los mecanismos de seguridad ni siquiera evitar\u00e1n el inicio de este archivo.<\/p>\n

Como resultado, un atacante puede lanzar un mecanismo a trav\u00e9s de la shell<\/em> de comandos Bash para obtener acceso remoto (obteniendo as\u00ed la llamada shell<\/em> inversa). Este proceso Bash se puede utilizar para descargar archivos, que tambi\u00e9n carecer\u00e1n del atributo de cuarentena, lo que permitir\u00e1 al atacante descargar c\u00f3digo verdaderamente malicioso y ejecutarlo sin restricciones.<\/p>\n

En resumen:<\/p>\n