Cadeia de vulnerabilidades de convite do Calendar no macOS com zero-click

 (medium.com/@mikko-kenttala)
1 pontos por GN⁺ 2024-09-14 | 1 comentários | Compartilhar no WhatsApp
  • Uma falha no processamento de anexos de convites do Calendar no macOS permitia que um invasor gravasse e apagasse arquivos arbitrários dentro do sandbox do Calendar, e esse problema levava a uma cadeia de execução remota de código e acesso a dados do Photos
  • A etapa 1, CVE-2022-46723, não sanitizava corretamente entradas com path traversal na seção ATTACH, como FILENAME=../../../PoC.txt, permitindo que anexos fossem salvos fora do local pretendido
  • A cadeia de execução remota de código explorava o comportamento Open File do Calendar durante o processo de atualização do Monterey para o Ventura, combinando injeção de vários arquivos, montagem de DMG e SMB, e um esquema de URL customizado
  • Na etapa do Photos, um defaults import aplicava uma configuração maliciosa para alterar a System Photo Library para /var/tmp/mypictures/Syndication.photoslibrary, fazendo com que fotos originais do iCloud fossem sincronizadas para um diretório não protegido por TCC
  • A Apple corrigiu todas as vulnerabilidades relacionadas entre outubro de 2022 e setembro de 2023; a falha do Photos recebeu CVE-2023-40434 e o bypass do Gatekeeper foi tratado como CVE-2023-40433

Path traversal em anexos do Calendar

  • Convites maliciosos do Calendar podiam incluir anexos, e a validação insuficiente do nome do arquivo permitia traversal de diretórios
  • O invasor podia definir um caminho arbitrário na seção ATTACH, como FILENAME=../../../PoC.txt
    • O local normal de armazenamento é ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • No comportamento vulnerável, o arquivo era salvo em ~/Library/Calendar/PoC.txt
  • Se já existisse um arquivo com o mesmo nome, o novo seria salvo como PoC.txt-2, mas quando o evento ou anexo enviado pelo invasor fosse apagado depois, o PoC.txt com o nome original poderia ser removido
  • Esse comportamento também podia ser usado para apagar arquivos existentes dentro do sandbox do Calendar no sistema de arquivos
  • Foi confirmado que a vulnerabilidade existia pelo menos até a versão mais recente do macOS Monterey 12.5, e que o macOS 13.0 beta4 já não era mais vulnerável

Cadeia expandida para execução remota de código

  • A vulnerabilidade descoberta pouco antes do lançamento do macOS Ventura foi expandida para execução remota de código usando o processo de atualização de versão e a função Open File do Calendar
  • O invasor injetava vários arquivos por meio da falha de gravação arbitrária de arquivos do Calendar e montava a cadeia para disparar durante a atualização do Monterey para o Ventura

  • Arquivos injetados

    • 000Hacked-$RANDOM.calendar
      • Contém dados de Calendar que parecem um calendário “Siri Suggested”
      • Inclui eventos recorrentes e recursos de alerta, e aciona a abertura de outros arquivos injetados
    • CalendarTruthFileMigrationInProgress
      • Arquivo que faz o Calendar existente atualizar e mesclar dados do formato antigo para o novo banco de dados
    • CalPoCInit.dmg
      • O primeiro alerta do Calendar aciona a abertura de ~/Library/Calendars/CalPoCInit.dmg
      • O Bookmark dentro de .DS_Store no DMG inclui uma referência de imagem de fundo em um servidor Samba externo
      • Mesmo que CalPoCInit.dmg esteja em quarentena, a montagem ocorre sem quarantine flag
    • stage1.url
      • O segundo alerta do Calendar aciona a abertura de ~/Library/Calendars/stage1.url
      • Esse arquivo contém a URL file:///Volumes/CalPoCPayload/MyMidiTest.app, que aponta para um app dentro do volume Samba montado na etapa anterior
      • Quando o Finder abre /Volumes/CalPoCPayload/, a indexação ocorre automaticamente, e MyMidiTest.app é indexado
      • O Info.plist do app bundle registra um handler para o esquema de URL customizado mymiditest
    • stage2.url
      • O terceiro alerta do Calendar aciona a abertura de ~/Library/Calendar/stage2.url
      • Esse arquivo referencia mymiditest://, executando o app malicioso sem interação do usuário

Bypass do Gatekeeper e execução do app

  • A execução de mymiditest:// era possível porque o app estava dentro de uma montagem Samba criada pelo exploit, e esse local não tinha quarantine flag
  • O app mymiditest grava os arquivos necessários para a etapa 3 em /var/tmp/ e executa o script no Terminal com open /var/tmp/PhotosPoC.sh
  • A cadeia completa foi montada para escapar do sandbox do Calendar com a injeção de vários arquivos, contornar as mitigações do Gatekeeper com o truque de SMB e então executar código arbitrário

Alteração das configurações do Photos para acessar fotos do iCloud

  • A etapa após a execução remota de código se concentra em alterar as configurações do Photos para acessar dados sensíveis de fotos do usuário, especialmente o iCloud Photos
  • Normalmente, o acesso a arquivos sensíveis por apps como o Photos deveria ser limitado pelo TCC, mas ao mudar as configurações do Photos era possível fazer a System Photo Library apontar para um caminho não protegido pelo TCC
  • O invasor podia criar um arquivo de configuração do Photos usando outra System Photo Library e importá-lo com defaults import
  • Na cadeia PoC, a etapa 2 prepara automaticamente uma configuração que usa /var/tmp/mypictures/Syndication.photoslibrary como System Photo Library
    • Os arquivos de configuração maliciosos relacionados são criados em /var/tmp/mypictures/*.plist
    • Os aplicativos relacionados ao Photos em execução são encerrados
    • A configuração original é salva em backup em /var/tmp/mypictures/*-orig.plist
    • A configuração maliciosa é importada de /var/tmp/mypictures/
    • A nova biblioteca de fotos é aberta no Photos com open /var/tmp/mypictures/Syndication.photoslibrary
  • Syndication.photoslibrary é uma biblioteca-modelo vazia, e quando o Photos é executado com a nova System Photo Library, a sincronização do iCloud é ativada e os arquivos originais são baixados para um diretório não protegido
  • Os arquivos sincronizados no disco são copiados para um novo diretório em /var/tmp/PoCLoot$RANDOM/
  • Com pequenas modificações, o PoC poderia copiar os dados para um recurso externo ou publicá-los em um servidor web externo com o comando curl

Cronograma de correções e questão pendente de bounty

  • A cadeia inteira precisava superar em sequência as barreiras de segurança do macOS
    • Injetar vários arquivos no Calendar para contornar o sandbox e ativar a próxima etapa
    • Contornar as mitigações do Gatekeeper com o truque de SMB para executar código arbitrário
    • Contornar a proteção do TCC para acessar dados sensíveis como o iCloud Photos
  • Antes das correções, era possível enviar um convite malicioso do Calendar para usuários do Apple iCloud e roubar o iCloud Photos sem interação do usuário
  • A Apple corrigiu todas as vulnerabilidades relacionadas entre outubro de 2022 e setembro de 2023

  • Timeline

    • 2022-08-08: reportada gravação e exclusão arbitrária de arquivos dentro do sandbox do Calendar
    • 2022-10-24: corrigido no macOS Monterey 12.6.1 e no Ventura 13
      • Esse item não recebeu CVE, e o Ventura beta3 era vulnerável
    • 2022-11-14: enviado PoC expandindo a falha do Calendar para execução arbitrária de código e bypass do Gatekeeper
    • 2022-12-04: enviado PoC de acesso ao iCloud Photos
    • 2023-02-20: adicionados crédito e CVE CVE-2022-46723 à vulnerabilidade do Calendar
    • 2023-03-27: bypass do Gatekeeper corrigido no macOS Ventura 13.3
      • Nesse momento não havia CVE nem crédito
    • 2023-09-26: corrigida a vulnerabilidade do Photos CVE-2023-40434 e atribuído crédito
    • 2023-10-09: anunciada recompensa de bug bounty relacionada ao bypass do Gatekeeper e à falha do Photos
    • 2023-12-21: atribuído crédito ao bypass do Gatekeeper com CVE-2023-40433
    • 2024-09-12: a recompensa ligada à vulnerabilidade original de gravação e exclusão arbitrária de arquivos no Calendar, CVE-2022-46723, ainda não existia
    • Atualização de 2024-10-20: a Apple decidiu que a vulnerabilidade de gravação e exclusão arbitrária de arquivos do Calendar em CVE-2022-46723 não se qualificava para bounty porque afetava apenas o macOS Monterey e o Ventura já não apresentava o problema ainda na fase beta

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-14
Comentários no Hacker News

  • Ainda bem que eu não uso o iCloud Photo Library, mas é estranho que, se você mudar a localização da fototeca, o novo local não receba proteção nenhuma
    Eu esperava que, ao definir /var/tmp/mypictures/Syndication.photoslibrary como fototeca do sistema e abrir o Photos, o app Photos passasse a proteger esse diretório, então o exploit falharia
    Fiz um teste rápido no Sonoma 14.6.1: se eu abrir o Photos segurando a tecla Option e criar uma nova fototeca em ~/Pictures, um app sem permissão de acesso total ao disco nem permissão para Fotos tem o acesso àquela pasta negado
    Mas, se eu criar a nova fototeca em /tmp, o mesmo app conseguia acessá-la, e esse comportamento é confuso e inconsistente
    Se a Apple realmente quer dar suporte ao recurso de mover a fototeca para qualquer lugar do sistema de arquivos, então a proteção também precisa ser aplicada direito

    • Até dá para entender. Historicamente, /tmp sempre foi um local no diretório hierárquico com leitura e escrita para qualquer um, então não é uma boa escolha para armazenar dados privados
    • O TCC já é assim há tempos: meio estranho e cheio de brechas
    • Hoje, no Linux, já é muito mais fácil isolar tudo do que no macOS
      Mesmo sem AppArmor ou Firejail, a maioria dos serviços recebe por padrão um diretório temporário dedicado

  • Há muita conversa neste fio sobre pagamento de recompensa por bugs, mas se uma grande empresa de tecnologia que mantém um programa contínuo de recompensas não paga, em geral há uma boa chance de existir um motivo para isso
    Os incentivos desses programas quase sempre são totalmente alinhados para recompensar envios válidos
    É um daqueles casos raros em que os incentivos estão bem alinhados: a empresa cria o programa de recompensas para incentivar certos tipos de pesquisa, e deixar de pagar uma recompensa legítima vai contra esse objetivo
    A pessoa responsável do lado do fornecedor não está gastando o próprio dinheiro, e o valor também não é significativo do ponto de vista da empresa
    Normalmente, os membros da equipe que opera o programa são motivados a pagar mais, não menos, em recompensas

    • Não. É porque a equipe de segurança de produto da Apple, que investiga e paga as recompensas por bugs, é pessimamente gerida e ineficiente
      Recentemente ela foi movida do escritório do programa SWE para a SEAR (security engineering & arch), e o gerente foi mandado embora há pouco tempo e foi para o AirBNB
      A maior parte da equipe é de ICT2 e ICT3 no nível de recém-formados, pessoas que nem passariam em outras entrevistas de programação dentro da empresa, e trabalham principalmente como triadores de bugs
      Passam mais tempo indo a conferências e convivendo com hackers do que trabalhando na frente do computador
      O gráfico no portal de “investigações em andamento” só continua subindo, então os e-mails só se acumulam e nem sequer tentam recuperar o atraso
      Se as pessoas que deveriam receber recompensa quiserem ver algum progresso, precisam pressionar publicamente Ivan, o responsável pela SEAR, no Twitter
    • Pode ser. O péssimo programa de recompensas por bugs da Apple talvez seja resultado de incompetência, e não de má-fé deliberada
      Mas isso importa para pesquisadores de segurança ou para o público? Não. Independentemente do motivo de estar quebrado, a Apple precisa consertar o programa de recompensas
      No fim, este post de blog é só mais um exemplo empilhado num monte que já é grande[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-...
    • A menos que isso queira dizer que o autor distorceu a situação, não consigo ver que “motivo muito bom” poderia existir quando há um registro claro de que alguém reportou o bug muito antes de ele ser corrigido
      Mesmo na melhor interpretação, isso parece uma típica burocracia lenta, e isso não é um motivo muito bom
      Se a empresa realmente incentiva esse tipo de coisa, não há razão para a aprovação levar mais de um ano
      A lógica pode até fazer sentido, mas diante de uma situação dessas é difícil dizer que “a empresa é mão de vaca ou, como quase sempre em outras situações, excessivamente burocrática” seja menos plausível do que “há um motivo legítimo para não pagar uma recompensa que aparentemente cumpre os requisitos”
      Se o autor descreveu o caso com precisão, parece muito mais plausível que os incentivos que funcionam em todos os outros lugares tenham contaminado também essa área
    • Você já tentou reportar um problema de segurança ou privacidade para a Apple? Eu já. E ainda tenho mais de um caso em aberto com a Apple
      Um deles pode ser corrigido sem efeitos colaterais com uma única linha de código, mas está aberto há dois anos
      A equipe de segurança da Apple ou não se importa, ou é incompetente, ou ambos, e nenhuma das opções é boa
      Foi uma das experiências mais irritantes e frustrantes que já tive na computação
      Eles claramente não querem que o problema seja compartilhado publicamente, mas ao mesmo tempo só continuam enrolando por tempo indeterminado
      Sinceramente, estou chegando ao meu limite
      Nem me importo com a recompensa, só quero que o bug seja corrigido
      Se eu pudesse acreditar que tratam o caso com seriedade, daria toda a folga possível, mas é difícil acreditar nisso
    • Houve muitos casos documentados de grandes empresas de tecnologia simplesmente se recusando a pagar
      Mudam as regras de participação depois do fato, bloqueiam discretamente pesquisadores de segurança de programas de recompensa em andamento, encaminham divulgações feitas de boa-fé para autoridades investigativas, ou têm administradores agindo de forma extremamente mesquinha
      O fato de que “o valor não significa nada para a empresa” torna esse tratamento desastroso ainda mais difícil de entender

  • Outra forma de mexer na flag de quarentena. A outra é este link: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    Parece que sistemas demais podem modificar essa flag de quarentena

  • “Um invasor pode enviar ao alvo um convite de calendário malicioso com um anexo de arquivo… Antes da correção, era possível enviar convites de calendário maliciosos para qualquer usuário do Apple iCloud e roubar o iCloud Photos sem qualquer interação do usuário.”
    Qual é exatamente o alcance disso? Quer dizer que, em qualquer lugar do macOS, qualquer pessoa podia enviar um convite arbitrário para qualquer usuário de iCloud? Quem iria querer isso?

    • Não é querendo ser sarcástico, mas de que outra forma convites deveriam funcionar?
    • Não entendi. Em que receber um convite de calendário é diferente de receber qualquer outro e-mail? O macOS, por design, processa automaticamente alguma coisa em convites de calendário?
    • O Google Calendar não é a mesma coisa?
    • Isso não parece ser algo específico do iCloud. Em geral, convites são capturados automaticamente a partir do e-mail
      Convites de calendário já são fonte de spam há muito tempo, então não é surpreendente que também tenham vulnerabilidades

  • “Se o arquivo especificado pelo invasor já existir, ele será salvo com o nome PoC.txt-2. Porém, se o evento/anexo enviado pelo invasor for apagado depois, o arquivo com o nome original (PoC.txt) será removido. Essa vulnerabilidade pode ser usada para apagar arquivos existentes dentro do ‘sandbox’ do sistema de arquivos.”
    Isso é má engenharia

  • Não gostei muito do estado da recompensa aqui. Do ponto de vista dos pesquisadores de segurança, é comum ter de esperar tanto assim com a Apple ou outras empresas de nível FAANG?

    • Muito comum

  • Só a etapa 1 já é uma vulnerabilidade absurda. Como a Apple não levou isso em consideração?
    “O invasor pode definir um caminho arbitrário para o arquivo na seção ATTACH, como FILENAME=../../../PoC.txt, e assim realizar com sucesso um ataque de directory traversal.”

    • Isso mostra um problema maior que provavelmente existe em todas as empresas. Alguém na Apple com certeza escreveu uma função de biblioteca para tratar isso com segurança, mas como obrigar as pessoas a usarem essa função?
      Especialmente se quem revisa o código nem conhece essa biblioteca, é difícil impedir que implementem tudo de novo de forma insegura desde o começo
      Existe alguma solução moderna para esse tipo de problema?

  • Sempre que aparece uma grande falha de segurança que não envolve memory safety eu fico estranhamente animado
    É meio mesquinho, eu sei, mas gosto da ideia de todo o tempo e energia investidos em Rust acabarem anulados por um simples bug de path traversal

  • O Lockdown Mode impede isso?

    • Palpite total, mas espero que sim
      Pensando nos exploits antigos relacionados a anexos de imagem sem clique, parece que o Lockdown Mode foi criado para bloquear esse tipo de coisa, então imagino que todos os arquivos sejam tratados dessa forma

  • Uau. É um exploit bem old-school
    Lembro de ter lido sobre coisas como caminho em nome de arquivo há uns 10 anos