Cadena de vulnerabilidades zero-click en invitaciones de Calendar en macOS

 (medium.com/@mikko-kenttala)
1 puntos por GN⁺ 2024-09-14 | 1 comentarios | Compartir por WhatsApp
  • Una falla en el procesamiento de adjuntos de invitaciones en Calendar de macOS permitía a un atacante escribir y eliminar archivos arbitrarios dentro del sandbox de Calendar, y este problema derivó en una cadena de ejecución remota de código y acceso a datos de Photos
  • La primera etapa, CVE-2022-46723, no saneaba correctamente entradas de recorrido de rutas como FILENAME=../../../PoC.txt en la sección ATTACH, por lo que los archivos adjuntos podían guardarse fuera de la ubicación prevista
  • La cadena de ejecución remota de código aprovechaba el comportamiento Open File de Calendar durante la actualización de Monterey a Ventura para inyectar varios archivos y combinaba DMG, montaje SMB y esquemas de URL personalizados
  • En la etapa de Photos, se aplicaba una configuración maliciosa con defaults import para cambiar la System Photo Library a /var/tmp/mypictures/Syndication.photoslibrary, haciendo que las fotos originales de iCloud se sincronizaran en un directorio no protegido por TCC
  • Apple corrigió todas las vulnerabilidades relacionadas entre octubre de 2022 y septiembre de 2023; la vulnerabilidad de Photos se gestionó como CVE-2023-40434 y el bypass de Gatekeeper como CVE-2023-40433

Recorrido de rutas en adjuntos de Calendar

  • Una invitación maliciosa de Calendar podía incluir un archivo adjunto, y la falta de validación del nombre del adjunto permitía recorrido de directorios
  • El atacante podía especificar una ruta arbitraria en la sección ATTACH, como FILENAME=../../../PoC.txt
    • La ubicación normal de guardado era ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • Con el comportamiento vulnerable, el archivo se guardaba en ~/Library/Calendar/PoC.txt
  • Si ya existía un archivo con el mismo nombre, el nuevo archivo se guardaba como PoC.txt-2, pero cuando más tarde se eliminaba el evento o adjunto enviado por el atacante, podía eliminarse el PoC.txt con el nombre original
  • Este comportamiento también podía usarse para eliminar archivos existentes dentro del sandbox de Calendar en el sistema de archivos
  • Se confirmó que la vulnerabilidad existía al menos en la versión más reciente de macOS Monterey 12.5, y que macOS 13.0 beta4 ya no era vulnerable

Cadena ampliada a ejecución remota de código

  • La vulnerabilidad descubierta justo antes del lanzamiento de macOS Ventura se amplió a ejecución remota de código aprovechando el proceso de actualización de versión y la función Open File de Calendar
  • El atacante inyectaba varios archivos mediante la vulnerabilidad de escritura arbitraria de archivos de Calendar y configuraba la cadena de RCE para que funcionara al actualizar de Monterey a Ventura

  • Composición de los archivos inyectados

    • 000Hacked-$RANDOM.calendar
      • Contenía datos de Calendar que parecían un calendario “Siri Suggested”
      • Incluía eventos recurrentes y funcionalidad de alertas, y estaba configurado para abrir otros archivos inyectados
    • CalendarTruthFileMigrationInProgress
      • Era un archivo que hacía que el Calendar existente se actualizara y fusionara desde el formato antiguo hacia una nueva base de datos
    • CalPoCInit.dmg
      • Hacía que la primera alerta de Calendar abriera ~/Library/Calendars/CalPoCInit.dmg
      • El Bookmark del .DS_Store dentro del DMG incluía una referencia a una imagen de fondo en un servidor Samba externo
      • Aunque CalPoCInit.dmg estuviera en cuarentena, el montaje ocurría sin quarantine flag
    • stage1.url
      • Hacía que la segunda alerta de Calendar abriera ~/Library/Calendars/stage1.url
      • Este archivo incluía una URL file:///Volumes/CalPoCPayload/MyMidiTest.app que apuntaba a una app dentro del volumen Samba montado en el paso anterior
      • Cuando Finder abría /Volumes/CalPoCPayload/, la indexación se producía automáticamente y MyMidiTest.app quedaba indexada
      • El Info.plist del bundle de la app registraba el handler del esquema de URL personalizado mymiditest
    • stage2.url
      • Hacía que la tercera alerta de Calendar abriera ~/Library/Calendar/stage2.url
      • Este archivo referenciaba mymiditest:// para ejecutar la app maliciosa sin interacción del usuario

Bypass de Gatekeeper y ejecución de la app

  • La ejecución de mymiditest:// era posible porque la app estaba dentro del montaje Samba creado por el exploit y esa ubicación no tenía quarantine flag
  • La app mymiditest escribía en /var/tmp/ los archivos necesarios para la etapa 3 y ejecutaba el script en Terminal con open /var/tmp/PhotosPoC.sh
  • La cadena completa estaba diseñada para inyectar varios archivos a fin de salir del sandbox de Calendar, eludir las mitigaciones de Gatekeeper con el truco de SMB y luego ejecutar código arbitrario

Acceso a fotos de iCloud cambiando la configuración de Photos

  • La etapa posterior a la ejecución remota de código se centraba en cambiar la configuración de Photos para acceder a datos sensibles de fotos del usuario, en particular iCloud Photos
  • Normalmente, TCC debería restringir el acceso a archivos sensibles como los de Photos, pero al cambiar la configuración de Photos, la System Photo Library podía apuntar a una ruta no protegida por TCC
  • El atacante podía crear un archivo de configuración de Photos que usara otra System Photo Library e importarlo con defaults import
  • En la cadena PoC, la etapa 2 preparaba automáticamente una configuración que usaba /var/tmp/mypictures/Syndication.photoslibrary como System Photo Library
    • Los archivos de configuración maliciosos relacionados se creaban en /var/tmp/mypictures/*.plist
    • Se cerraban las aplicaciones relacionadas con Photos que estuvieran en ejecución
    • La configuración original se respaldaba en /var/tmp/mypictures/*-orig.plist
    • La configuración maliciosa se importaba desde /var/tmp/mypictures/
    • La nueva biblioteca de fotos se abría en Photos con open /var/tmp/mypictures/Syndication.photoslibrary
  • Syndication.photoslibrary era una biblioteca de plantilla vacía y, cuando Photos se ejecutaba con ella como nueva System Photo Library, se activaba la sincronización de iCloud y los archivos originales se descargaban en un directorio no protegido
  • Los archivos sincronizados en disco se copiaban a un nuevo directorio bajo /var/tmp/PoCLoot$RANDOM/
  • Con pequeñas modificaciones, el PoC podía copiar los datos a un recurso externo o publicarlos en un servidor web externo mediante el comando curl

Calendario de correcciones y problemas pendientes de bounty

  • La cadena completa tenía que superar las barreras de seguridad de macOS en orden
    • Inyectaba varios archivos en Calendar para eludir el sandbox y activar la siguiente etapa
    • Eludía las mitigaciones de Gatekeeper con el truco de SMB para ejecutar código arbitrario
    • Eludía la protección de TCC para acceder a datos sensibles como iCloud Photos
  • Antes de la corrección, era posible enviar una invitación maliciosa de Calendar a un usuario de Apple iCloud y robar iCloud Photos sin interacción del usuario
  • Apple corrigió todas las vulnerabilidades relacionadas entre octubre de 2022 y septiembre de 2023

  • Línea de tiempo

    • 2022-08-08: reporte de escritura y eliminación arbitraria de archivos dentro del sandbox de Calendar
    • 2022-10-24: corregido en macOS Monterey 12.6.1 y Ventura 13
      • Este ítem no tenía CVE, y Ventura beta3 era vulnerable
    • 2022-11-14: entrega de un PoC que ampliaba la vulnerabilidad de Calendar a ejecución arbitraria de código y bypass de Gatekeeper
    • 2022-12-04: entrega de un PoC de acceso a iCloud Photos
    • 2023-02-20: se agregó crédito y CVE CVE-2022-46723 para la vulnerabilidad de Calendar
    • 2023-03-27: el bypass de Gatekeeper fue corregido en macOS Ventura 13.3
      • En ese momento no tenía CVE ni crédito
    • 2023-09-26: la vulnerabilidad de Photos CVE-2023-40434 fue corregida y se otorgó crédito
    • 2023-10-09: anuncio de bug bounty relacionado con el bypass de Gatekeeper y la vulnerabilidad de Photos
    • 2023-12-21: se otorgó crédito CVE-2023-40433 al bypass de Gatekeeper
    • 2024-09-12: todavía no había bounty para la vulnerabilidad original de escritura y eliminación arbitraria de archivos en Calendar CVE-2022-46723
    • Actualización del 2024-10-20: Apple determinó que la vulnerabilidad de escritura y eliminación arbitraria de archivos en Calendar CVE-2022-46723 no era elegible para bounty porque solo afectaba a macOS Monterey y Ventura ya no tenía ese problema desde la fase beta

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-14
Opiniones en Hacker News

  • Me alegra no usar iCloud Photo Library, pero es extraño que, si cambias la ubicación de la fototeca, la nueva ubicación no reciba ninguna protección
    Si configuro /var/tmp/mypictures/Syndication.photoslibrary como fototeca del sistema y abro Photos, habría esperado que el exploit fallara porque la app Photos debería proteger ese directorio
    Hice una prueba rápida en Sonoma 14.6.1: si mantienes presionada la tecla Option y abres Photos para crear una nueva fototeca en ~/Pictures, una app sin permisos de acceso completo al disco ni permisos de fotos tiene denegado el acceso a esa carpeta
    Pero si creas la nueva fototeca en /tmp, la misma app sí puede acceder, y este comportamiento es confuso e inconsistente
    Si Apple realmente quiere admitir mover la fototeca a cualquier parte del sistema de archivos, también debería aplicar correctamente la protección

    • Hasta cierto punto se entiende. Históricamente, /tmp ha sido un lugar en la jerarquía de directorios donde cualquiera puede leer y escribir, y no es una buena opción para guardar datos privados
    • TCC desde hace tiempo ha sido algo raro y bastante lleno de agujeros de esta forma
    • En Linux ahora es mucho más fácil aislar todo que en macOS
      Incluso sin AppArmor ni Firejail, la mayoría de los servicios reciben por defecto un directorio temporal dedicado

  • En este hilo se habla mucho del pago de recompensas por bugs, pero si una gran empresa tecnológica que opera un programa permanente de recompensas no paga, en general es muy probable que tenga alguna razón para hacerlo
    Los incentivos de estos programas están casi todos alineados hacia pagar recompensas por reportes legítimos
    Es un caso poco común en el que los incentivos están bastante bien alineados: la empresa crea un programa de recompensas para fomentar cierto tipo de investigación, y no pagar recompensas legítimas va en contra de ese objetivo
    La persona responsable del lado del proveedor tampoco está gastando su propio dinero, y el monto no es significativo para la empresa
    Normalmente, los integrantes del equipo que opera el programa están motivados a pagar más, no menos

    • No. Es porque el equipo de product security que investiga y paga las recompensas por bugs de Apple está pésimamente administrado y es ineficiente
      Hace poco lo movieron de la oficina del programa SWE a SEAR (security engineering & arch), y al gerente también lo echaron hace poco y se fue a AirBNB
      La mayoría del equipo son ICT2 e ICT3 al nivel de recién egresados, personas que no pasarían entrevistas de programación en otras áreas de la empresa, y trabajan principalmente como clasificadores de bugs
      Pasan más tiempo yendo a conferencias y conviviendo con hackers que frente a la computadora trabajando
      El gráfico del portal de “investigación en curso” no hace más que subir, así que los correos se siguen acumulando y ni siquiera intentan ponerse al día
      Para que las personas que deberían recibir recompensas y no las reciben vean avances, tienen que presionar públicamente en Twitter a Ivan, el responsable de SEAR
    • Puede ser cierto. Quizá el deficiente programa de recompensas por bugs de Apple sea resultado de incompetencia y no de mala fe deliberada
      Pero ¿eso les importa a los investigadores de seguridad o al público? No. Sin importar por qué está roto, Apple tiene que arreglar su programa de recompensas
      Al final, esta publicación del blog es solo otro ejemplo más en un montón ya enorme[1][2][3][4][5]
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • Si no se quiere decir que el autor distorsionó la situación, no sé qué “muy buena razón” podría haber cuando hay un registro claro de que alguien reportó el bug mucho antes de que se corrigiera
      En el mejor de los casos parece la típica burocracia lenta, y eso no es una muy buena razón
      Si la empresa realmente fomenta estas cosas, no debería tardar más de un año en aprobarlas
      La lógica puede ser correcta, pero al ver situaciones así, cuesta sostener que “la empresa es tacaña o, como en casi cualquier otra situación, excesivamente burocrática” sea menos plausible que “hay una razón válida para no pagar una recompensa que en apariencia cumple los requisitos”
      Si el autor describió el caso con precisión, parece mucho más plausible que los incentivos que operan en todas las demás partes también se hayan filtrado a esta área
    • ¿Alguna vez has reportado un problema de seguridad o privacidad a Apple? Yo sí. Todavía tengo al menos un asunto abierto con Apple
      Uno de ellos se puede arreglar con una sola línea de código, sin efectos secundarios, y lleva dos años abierto
      El equipo de seguridad de Apple no está interesado o es incompetente; cualquiera de las dos opciones es mala
      Ha sido una de las experiencias más frustrantes y exasperantes que he tenido en computación
      Claramente quieren que no comparta el problema públicamente, pero solo lo arrastran indefinidamente
      Sinceramente, estoy llegando a mi límite
      No me importa la recompensa; solo quiero que el bug se arregle
      Les daría todo el margen posible si pudiera creer que están tratando el asunto con seriedad, pero cuesta creerlo
    • Ha habido muchos casos documentados en los que grandes empresas tecnológicas directamente se negaron a pagar
      Cambian las reglas de participación después del hecho, bloquean discretamente a investigadores de seguridad de programas de recompensas en curso, remiten divulgaciones de buena fe a las autoridades, o los administradores actúan con una mezquindad extrema
      Justamente porque “para la empresa el monto no es significativo”, este manejo desastroso resulta aún más difícil de entender

  • Otra forma de manipular la bandera de cuarentena. La otra es este enlace: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    Parece que demasiados sistemas distintos pueden modificar esta bandera de cuarentena

  • “Un atacante puede enviar a la víctima una invitación de calendario maliciosa que incluya un archivo adjunto… Antes de la corrección, era posible enviar una invitación de calendario maliciosa a cualquier usuario de Apple iCloud y robarle iCloud Photos sin interacción del usuario.”
    ¿Qué tan amplio es este alcance? ¿Significa que, desde cualquier lugar en macOS, cualquiera puede enviarle una invitación arbitraria a cualquier persona que use iCloud? ¿Quién no querría algo así?

    • No intento ser sarcástico, pero ¿de qué otra forma deberían funcionar las invitaciones?
    • No entiendo. ¿En qué se diferencia recibir una invitación de calendario de recibir cualquier otro correo? ¿macOS, por diseño, procesa algo automáticamente para las invitaciones de calendario?
    • ¿No pasa lo mismo con Google Calendar?
    • No parece ser algo específico de iCloud. En general, las invitaciones se detectan automáticamente desde el correo electrónico
      Las invitaciones de calendario han sido una fuente de spam desde hace mucho, así que no sorprende que también haya vulnerabilidades

  • “Si el archivo especificado por el atacante ya existe, el archivo indicado se guarda con el nombre PoC.txt-2. Sin embargo, si el evento/archivo adjunto enviado por el atacante se elimina más tarde, se elimina el archivo con el nombre original (PoC.txt). Esta vulnerabilidad puede usarse para eliminar archivos existentes dentro del ‘sandbox’ del sistema de archivos.”
    Esto es mala ingeniería

  • No me gusta mucho el estado de la recompensa aquí. Desde el punto de vista de los investigadores de seguridad, ¿es común esperar tanto con Apple u otras empresas del nivel de FAANG?

    • Muchísimo

  • La etapa 1 por sí sola ya es una vulnerabilidad absurda. ¿Cómo es que Apple no consideró esto?
    “Un atacante puede establecer una ruta arbitraria para el archivo en la sección ATTACH, como FILENAME=../../../PoC.txt, y lograr un ataque de recorrido de directorios.”

    • Esto muestra un problema más grande que podría existir en cualquier empresa. Seguramente alguien en Apple escribió una función de biblioteca para manejar esto de forma segura, pero ¿cómo se puede obligar a que usen esa función?
      Especialmente si quien revisa el código tampoco conoce esa biblioteca, es difícil evitar que alguien lo vuelva a implementar desde cero de manera insegura
      ¿Existe alguna solución moderna para este tipo de problema?

  • Cada vez que aparece un agujero de seguridad grande que no tiene que ver con seguridad de memoria, me entusiasma de una forma rara
    Sé que es un poco mezquino, pero me gusta la idea de que todo el tiempo y la energía invertidos en Rust terminen quedando en nada por un solo bug de recorrido de rutas

  • ¿Lockdown Mode bloquea esto?

    • Es pura especulación, pero espero que sí
      Pensando en los exploits anteriores relacionados con adjuntos de imágenes de cero clics, parece que Lockdown Mode se creó para bloquear cosas así, y supongo que todos los archivos se tratarían de esa forma

  • Wow. Es un exploit bastante de la vieja escuela
    Recuerdo haber leído sobre cosas como rutas dentro de nombres de archivo hace unos 10 años