Nota del autor: Este blog se basa en una charla que presenté en JNUC 2022 en San Diego, California, el 28 de septiembre de 2022. Se ha actualizado con la información más reciente. La grabación del video está disponible en línea.
Prólogo
Hubo una campaña publicitaria popular que se transmitió entre 2006 y 2009. Presentaba a una PC, representada por un John Hodgman a menudo resfriado y enfermo con un traje demasiado grande. Frente a PC estaba Mac: un Justin Long moderno y bien vestido. Este conjunto de anuncios era de Apple, y los anuncios generalmente transmitían la idea de que "las Mac no se infectan con virus".
Esta campaña fue increíblemente popular, pero, lamentablemente, sembró en la comunidad de usuarios de Apple la creencia de que sus Mac no podían ni podrían infectarse con virus. Esta idea ha permeado la década, y ahora, en 2023, para muchos sigue siendo válida. Sin embargo, en la última década, este mito se ha desmentido cientos, si no miles, de veces, con CVE, días cero, malware, adware e incluso ransomware que apuntan al ecosistema de macOS.
Curiosamente, hablaremos de algunas herramientas que Apple lanzó justo en la época en que se transmitían estos anuncios, lo que nos muestra que, mientras Apple reforzaba su mensaje de inmunidad a los virus, al mismo tiempo lanzaba herramientas para intentar proteger a los usuarios.
Me gusta pensar en las herramientas de seguridad de Apple como un oso polar en una tormenta de nieve: aunque no puedas verlo, sigue ahí. Hay muchas herramientas diferentes que vienen incluidas con una computadora Mac nueva. Hablaremos de algunas de esas herramientas, qué hacen, cómo funcionan y si son suficiente seguridad para los usuarios finales.
La lista de herramientas que veremos es la siguiente:
- TCC
- File Quarantine
- Gatekeeper
- XProtect
- Malware Removal Tool (MRT)
- XProtect Remediator (XPR)
TCC
TCC, que significa Transparency, Consent, and Control (transparencia, consentimiento y control), es un conjunto de bases de datos que reside en el sistema macOS.
Le mostrará al usuario una alerta cuando una aplicación intente usar servicios específicos por primera vez.
Por ejemplo, en esta captura de pantalla, el usuario intenta activar la cámara y el micrófono a la vez. El CoreServicesUIAgent le muestra una alerta al usuario, pidiéndole que elija "Aceptar" o "Rechazar" el uso de dicho servicio por parte de la aplicación.
Dentro de System Preferences > Privacy & Security, podemos ver qué aplicaciones (clientes) han solicitado servicios específicos. En el siguiente ejemplo, vemos cuatro aplicaciones diferentes que han solicitado Full Disk Access. Esto no se limita a Full Disk Access (FDA), sino que también puede abarcar la cámara, el micrófono, las carpetas de usuario, los servicios de ubicación, el calendario, los contactos, etc.
Por debajo, TCC es una base de datos sqlite. Hay una en el directorio raíz, y además, una por cada usuario en la máquina. Podemos abrir esas bases de datos, así que abramos el directorio TCC raíz y veamos algunas entradas.
Dentro de esta base de datos, tomemos la tabla access y veamos algunos elementos.
Esto nos da mucha información, así que podemos poner algunas restricciones en nuestra consulta para obtener solo la información que considero relevante por ahora.
Una muestra de lo que podríamos obtener es
com.HuntressLabs.Agent | 6 | 0 | kTCCServiceSystemPolicyAllFiles
Estos campos se corresponden con algunos significados diferentes.
El primer campo es el cliente que hace la solicitud. En este caso, un Huntress Agent falso está solicitando permisos.
La segunda columna, llamada auth_reason, indica cómo se solicitó. En nuestro caso, se envió mediante una política MDM PPPC.
Tercero, está la respuesta que dio el usuario (o lo que especificó la política): si aprobó o rechazó la solicitud.
Por último, está el servicio que se solicitó. En nuestro ejemplo, vemos que es kTCCServiceSystemPolicyAllFiles. En términos de Apple, esto solicita acceso completo al disco.
La idea de Apple detrás de TCC es darle al usuario más poder sobre su software y aplicaciones. Esto ayuda a evitar que el software se extralimite y acceda a partes del sistema para las que el usuario no ha dado permiso explícito.
Dentro del conjunto de herramientas de Apple, TCC es algo particular en comparación con otras herramientas y cómo operan, así que profundicemos en los detalles de la seguridad de macOS.
Verificar, bloquear, remediar
El sistema operativo de Apple opera en tres pasos para proteger fundamentalmente a sus usuarios. Esto es su 'verificar, bloquear, remediar'. Repasaremos cada uno de estos pasos y los relacionaremos con la herramienta que Apple usa para aplicar esa funcionalidad.
Empezaremos desde arriba con Gatekeeper, pero, antes de hacerlo, sería un error no hablar de un paso preventivo fundamental de Gatekeeper, llamado File Quarantine.
File Quarantine
File Quarantine está diseñado para informarte cuando una aplicación descargada de internet se ejecuta por primera vez. Esto se introdujo en OS X 10.5 Tiger y, en esencia, intenta impedir que una aplicación descargada de internet se abra sin el permiso explícito del usuario. Gatekeeper se construye sobre esta base.
Una vez que descargamos una aplicación y la abrimos, obtenemos la solicitud, de nuevo, del CoreServicesUIAgent preguntándonos si queremos abrir esta aplicación descargada de internet. Al hacer clic en 'Abrir', se activa una marca en los metadatos de cuarentena. Podemos ver estas marcas en los metadatos de atributos extendidos.
Si ejecutamos xattr <path_to_application> desde la línea de comandos, se mostrará la lista de atributos extendidos. El que nos interesa por ahora es el atributo com.apple.quarantine. Luego podemos imprimir el contenido de ese atributo.
Imprimirá una breve línea de contenido.
0083; 61730334; Safari; 7512FB1C-56E8-458B-88B3-DC9816210A8D
La primera columna es la marca. Si este número es algo como 0083 o 0081, esto le indica a Gatekeeper que la aplicación en cuestión debe verificarse antes de abrirla. Este número se actualiza según la acción del usuario después de la apertura inicial.
La segunda columna es una marca de tiempo hexadecimal. En una base de datos, esto corresponde a algo llamado Mac Absolute Time. 61730334
La tercera columna representa el navegador desde el cual se descargó nuestra aplicación. Descargamos el instalador de Chrome desde Safari.
Por último, hay un UUID asociado con la aplicación. Esto se usa principalmente dentro de la base de datos donde se almacena como identificador.
Una vez que Gatekeeper ha verificado esta información, la primera marca se actualiza a algo como 01c2 o 01c3.
Toda esta información se almacena en la base de datos LSQuarantine en ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2. Desde aquí, podemos analizar los eventos en esta base de datos.
Ahora podemos ver el UUID de la información original de cuarentena, así como de dónde se descargó la aplicación, la marca de tiempo y más.
Entonces, ¿cómo funciona Gatekeeper junto con la cuarentena de archivos?
Gatekeeper
Como contexto, Gatekeeper es básicamente una interfaz para el binario spctl en macOS.
Puedes usar spctl directamente desde la línea de comandos para verificar si una aplicación está firmada y notariada, que es la función principal de Gatekeeper.
Esto te informa que la aplicación MaliciousApp no está firmada y Gatekeeper no permitirá que se abra, mientras que la siguiente aplicación sí lo haría.
La diferencia entre Gatekeeper y la cuarentena de archivos es que Gatekeeper se aplica a algo que se está ejecutando, no necesariamente algo que se abrió solo desde internet. Por ejemplo, si descargaras un gif o una imagen y la abrieras en la aplicación nativa de Apple Preview, no se verificaría. Además, Gatekeeper solo se ocupa de elementos en los que se hace doble clic. Si yo creara un script bash y le agregara el tipo de archivo .command, se convertiría en un script en el que se puede hacer clic. El script .command en el que se puede hacer clic sería verificado por Gatekeeper, pero un simple script .sh que se ejecuta desde la línea de comandos no lo sería.
Si una aplicación está bloqueada, te aparecerá una ventana emergente que te informa que no se puede abrir, porque proviene de un "desarrollador no identificado".
Gatekeeper primero verifica si la aplicación está firmada. Luego verifica si ese firmante es legítimo o no.
Primero verifica la base de datos de Gatekeeper para ver si el ID del equipo o desarrollador es un ID conocido como malicioso. Esta se encuentra en /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resournces/gk.db. Es otra base de datos sqlite que podemos consultar.
Estamos verificando si ese ID de equipo se encuentra en esta lista de 132 elementos.
La base gk.db se usa para el bloqueo, sin embargo, también hay bases de datos adicionales en el directorio /var/db, y más específicamente dentro de gkopaque.bundle y gke.bundle que se usan para la inclusión en la lista de aceptados.
Gatekeeper posteriormente verifica el estado de notarización, que es un proceso que los desarrolladores realizan al desarrollar software. Es un paso adicional que Apple usa para verificar que el software no sea malicioso. Gatekeeper también realiza verificaciones adicionales, como confirmar que las aplicaciones notariadas no hayan sido modificadas por un proceso no autorizado, incluso después de la primera vez que se abren con doble clic.
Otra función de Gatekeeper es verificar si el archivo tiene activado el bit de cuarentena. Si contiene, por ejemplo, la marca 0083, Gatekeeper igual necesita verificarlo. Una vez que el usuario ha aprobado la apertura de la aplicación descargada, Gatekeeper realizará sus otras verificaciones.
Un aspecto de Gatekeeper ha sido usado (y abusado) habitualmente por los actores de amenazas. Gatekeeper, por un diseño intencional de Apple, puede anularse. Esto se puede hacer simplemente haciendo clic derecho en la aplicación y seleccionando abrir. Esto permite al usuario anular Gatekeeper. La razón detrás de esto es que los usuarios puedan instalar aplicaciones aunque no estén firmadas. Personalmente, tengo algunas aplicaciones sin firmar que sé que son seguras, y sin esta capacidad de anulación, no podría abrirlas. El malware como Shlayer usa esta capacidad para evadir los mecanismos de seguridad de Apple y engañar a los usuarios mediante ingeniería social para que abran sus aplicaciones.
XProtect
Pivotando hacia el 'Bloque', XProtect actúa como un pseudo-antivirus en macOS.
En esencia, es una lista estática de reglas YARA que se lanzó el 30 de noviembre de 2017. Yara está diseñado para capturar, en este caso, malware, al examinar los bytes o cadenas dentro de un archivo, en lugar del hash del archivo al ID de desarrollador. Esto le permite a Apple ampliar su alcance y potencialmente descubrir muestras de malware que aún no se han visto en circulación. Este archivo XProtect.yara contiene una lista bastante exhaustiva de reglas.
Junto a este archivo yara hay una colección de listas de propiedades (plist).
El primero del que hablaremos es el LegacyEntitlementAllowlist.plist. No podemos decir con 100 % de certeza para qué sirve, pero, según el nombre, tiene sentido especular que es una lista de aplicaciones que necesitan algún tipo de permiso heredado para ejecutarse.
El siguiente archivo se llama XProtect.meta.plist. Este bloquea cosas como complementos maliciosos o extensiones maliciosas de Safari. Cada entrada incluye un ID de desarrollador y un ID de paquete que busca bloquear. También busca cierto software desactualizado, como Flash o Java.
El último de los cinco archivos en total es un XProtect.plist. Este archivo tiene entradas llamadas Description, LaunchServices y Matches.
La Description es bastante sencilla: el nombre del malware. LaunchServices indica qué tipo de URI debe activarla. Puede ser algo como com.apple.application-bundle, com.microsoft.word.doc o com.apple.installer-package. Por último, Matches es un arreglo de objetos de diccionario que le indica a XProtect cómo detectarlo, mediante el NSURLTypeIdentifierKey.
Entonces, si XProtect detecta algo, ¿cómo puede saberlo el usuario? Pues bien, le mostrará una ventana emergente indicando que encontró algo y que debe moverlo a la Papelera. Si el usuario decide hacerlo, se escribirá un archivo de diagnóstico en el disco. Este se ubica en ~/Library/Logs/DiagnosticReports/XProtect_XXX-Mac.diag.
Ahora tenemos un registro de que XProtect sí detectó y bloqueó algo, pero... ¿qué hay de la remediación?
MRT
La Herramienta de eliminación de malware (MRT) es un escáner del sistema que busca rutas de archivo específicas. Si detecta algún objeto en esa ruta, lo elimina. A diferencia de otras herramientas de las que hablamos, MRT está estructurado como una aplicación básica, dentro de un paquete de aplicación. Dentro de la estructura de archivos hay varios binarios diferentes: uno llamado MRT y otro llamado mrt-helper.
MRT se ejecuta sin ninguna interacción del usuario y puede realizar tareas de remediación en segundo plano, pero curiosamente, también se puede ejecutar directamente desde la línea de comandos.
Entonces, si tenemos malware en una de las rutas, MRT debería remediarlo justo al ejecutarlo desde la línea de comandos.
Según NixHacker, si colocamos el ejecutable de MRT en un desensamblador, podemos ver algunas de las diferentes rutas que busca. Por ejemplo, el malware OSX.ATG2.A busca cuatro rutas diferentes.
Si luego simplemente creamos archivos vacíos en cada una de esas ubicaciones, podemos ver si MRT efectivamente los remedia.
Ahora bien, aunque los archivos están vacíos y en realidad no contienen malware, su sola existencia en esas rutas de archivo debería activar MRT. Vamos a probarlo y a averiguarlo.
Sin embargo, parece que MRT se está retirando de macOS.
XProtect Remediator
En el lanzamiento de macOS 12.3, Apple también lanzó una nueva herramienta para macOS llamada XProtect Remediator (XPR). XProtect Remediator recuerda a MRT en el sentido de que es un paquete de aplicación, pero en lugar de solo dos binarios, hay catorce. Estos, en su mayoría, detectan familias específicas de malware, mientras que todo lo que no entra en alguna de ellas queda cubierto por el binario XProtect. También existe un binario XProtectRemediatorMRTv3, que tiene casi el mismo tamaño que el binario MRT dentro de MRT.app. Esto hace pensar que eventualmente reemplazará a MRT.app.
Puedes obtener visibilidad sobre XPR aprovechando los registros unificados, que forman parte de Endpoint Security de Apple.
Aquí puedes ver algunas entradas de muestra.
Parte de lo que hace que MRT y XProtect Remediator sean sustancialmente diferentes es que, mientras MRT escanea al reiniciar e iniciar sesión, XProtect Remediator escanea con una cadencia regular, y el escaneo del malware XCSSET (OSX.DUBROBBER) es el que se ejecuta con más frecuencia, cada una o dos horas.
Epílogo
Una pregunta común que surge al hablar de estas herramientas es: ¿necesito una solución de seguridad adicional o son suficientes estas herramientas?
Es una pregunta que creo que depende de tu postura de seguridad. Para un usuario final que usa su Mac para uso personal, aprovechar las herramientas existentes o preinstaladas de Apple probablemente sea suficiente. Si empiezas a usar Macs en tu negocio, ya sea una SMB o una empresa más grande, contar con cobertura de seguridad adicional será más beneficioso, ya que tendrás más usuarios que accederán a diferentes sitios web, herramientas de desarrollo, etc.
Las protecciones integradas de Apple son una capa importante, no toda la estrategia de seguridad del negocio. Consulta Huntress Managed EDR para macOS para obtener visibilidad, detección y respuesta de endpoints diseñadas específicamente, respaldadas por expertos en amenazas de macOS. Reserva una demo o inicia una prueba gratuita.
