
Extracteur d'artefacts de journaux de vulnérabilités Airborne pour iOS depuis LogArchive CVE-2025-24252
Ce script est conçu pour aider à identifier les traces potentielles de l'ensemble de vulnérabilités « Airborne » (affectant principalement le protocole AirPlay d'Apple) en interrogeant les journaux système iOS à partir d'un bundle .logarchive. Il automatise l'exécution de plusieurs commandes log show adaptées pour trouver des anomalies qui pourraient être associées à ces vulnérabilités.
Avertissement : Cet outil est fourni à des fins informatives et d'investigation uniquement. La présence d'entrées de journal correspondant à ces requêtes ne confirme pas de manière définitive une compromission. Les entrées de journal doivent être analysées dans leur contexte. L'absence de résultats ne garantit pas qu'un appareil est sécurisé. Assurez-vous toujours que vos appareils sont mis à jour avec les dernières versions du système d'exploitation.
Ce script a été développé par Anton Shustikov [email protected] (actuellement CEO de cakescats) dans le cadre du projet CakesCats.
CakesCats est une initiative axée sur :
Anton Shustikov est consultant en sécurité de l'information et en fintech avec une vaste expérience dans la création de systèmes de sécurité. Il est le fondateur du projet éducatif non commercial CakesCats et contribue par des articles à des publications comme Forbes et le magazine « Xakep ». Son travail implique souvent l'investigation de menaces numériques et la promotion d'une bonne hygiène numérique.
« Airborne » est le nom donné à un ensemble de vulnérabilités (découvertes par Oligo Security dans leurs recherches originales) affectant le protocole AirPlay d'Apple et le kit de développement logiciel (SDK) AirPlay. Ces vulnérabilités peuvent toucher une large gamme d'appareils Apple (iPhone, iPad, Mac, Apple TV, etc.) et des appareils tiers utilisant le SDK AirPlay (par exemple, enceintes connectées, récepteurs).
Aspects clés des vulnérabilités de type « Airborne » :
rapportd qui gère la communication de dispositif à dispositif.Ce script exécute une série de commandes log show avec des prédicats soigneusement élaborés. Ces prédicats sont conçus pour filtrer la vaste quantité d'informations contenues dans les journaux système iOS afin d'identifier les indicateurs potentiels de compromission ou d'activité anormale qui pourraient être liés aux vulnérabilités de type « Airborne ».
Le script recherche :
mediaserverd, AirPlayXPCHelper, rapportd, mDNSResponder).La sortie de chaque requête est enregistrée dans un fichier texte séparé, nommé de manière descriptive, dans un répertoire de résultats horodaté, ce qui permet une analyse ciblée de différents types d'artefacts potentiels.
log show et ce script sont destinés à être exécutés sur macOS..logarchive) : Vous avez besoin d'une archive de journaux système iOS (un bundle, qui est techniquement un répertoire) provenant de l'appareil que vous souhaitez analyser. Elle peut généralement être obtenue via :
sysdiagnose : Déclenchez une sysdiagnose sur l'iPhone (généralement en appuyant simultanément sur Volume Up + Volume Down + Bouton latéral, mais les combinaisons peuvent varier selon le modèle et la version d'iOS). Une fois la sysdiagnose générée (cela peut prendre plusieurs minutes), elle peut être envoyée par AirDrop à un Mac ou accessible lors de la synchronisation de l'iPhone avec un Mac (souvent dans Finder, à l'emplacement de synchronisation de l'iPhone, dans un fichier .tar.gz). Le .logarchive se trouvera dans le contenu extrait de la sysdiagnose.bash.Enregistrer le script :
Enregistrez le code du script (fourni ci-dessus) sous le nom airborne_artifact_extractor.sh (ou tout autre nom avec une extension .sh).
Le rendre exécutable : Ouvrez votre application Terminal, accédez au répertoire où vous avez enregistré le script, puis exécutez la commande suivante :
chmod +x airborne_artifact_extractor.sh
Vérifier l'attribut de quarantaine macOS (important pour les scripts téléchargés) : Si vous avez téléchargé ce script depuis Internet, macOS peut le mettre en quarantaine, ce qui peut l'empêcher de fonctionner correctement, voire de fonctionner du tout.
xattr airborne_artifact_extractor.sh
com.apple.quarantine, supprimez cet attribut en exécutant :
xattr -d com.apple.quarantine airborne_artifact_extractor.sh
Si vous rencontrez toujours des problèmes pour exécuter le script, en particulier s'il se trouve dans un répertoire comme ~/Downloads, assurez-vous que votre application Terminal dispose des autorisations nécessaires (par exemple, « Accès au disque complet » dans Réglages Système -> Confidentialité et sécurité) pour accéder à l'emplacement du script et à l'archive de journaux.
^M (par exemple, /bin/bash^M: bad interpreter: No such file or directory)Si vous rencontrez une erreur comme bash: ./votre_nom_de_script.sh: /bin/bash^M: bad interpreter: No such file or directory, /usr/bin/env: ‘bash\r’: No such file or directory, ou des messages similaires impliquant les caractères \r ou ^M lors de l'exécution du script, cela est probablement dû à des fins de ligne au format Windows (CRLF - Carriage Return Line Feed) au lieu de fins de ligne au format Unix (LF - Line Feed).
Cela se produit généralement si le fichier du script a été créé ou modifié sur un système Windows, puis transféré vers macOS ou Linux sans convertir les fins de ligne. Les systèmes Unix attendent uniquement LF comme terminateur de ligne, et le caractère CR supplémentaire (\r ou ^M) est mal interprété comme faisant partie du chemin de l'interpréteur ou des commandes.
Solution : convertir les fins de ligne avec dos2unix
Le moyen le plus simple de résoudre ce problème est d'utiliser l'utilitaire dos2unix.
Installer dos2unix :
Sur macOS (avec Homebrew) : Si vous n'avez pas Homebrew, installez-le d'abord à partir de brew.sh. Puis exécutez :
brew install dos2unix
Sur les distributions Linux basées sur Debian/Ubuntu :
sudo apt update
sudo apt install dos2unix
Sur les distributions Linux basées sur Fedora/RHEL :
sudo dnf install dos2unix # (ou yum pour les versions plus anciennes)
Convertir le fichier du script :
Accédez au répertoire contenant airborne_artifact_extractor.sh et exécutez :
dos2unix airborne_artifact_extractor.sh
Cette commande convertira les fins de ligne sur place.
Solutions alternatives (si dos2unix n'est pas disponible ou préféré) :
Avec sed :
sed -i.bak 's/\r$//' airborne_artifact_extractor.sh
(Cette commande modifie le fichier sur place et crée une sauvegarde airborne_artifact_extractor.sh.bak. Sur certaines versions de sed, en particulier sur macOS, l'option -i nécessite une extension pour le fichier de sauvegarde, comme -i '.bak' ou -i '' pour aucune sauvegarde si pris en charge. Pour macOS, vous pourriez avoir besoin de sed -i '' 's/\r//g' airborne_artifact_extractor.sh)
Avec tr :
tr -d '\r' < airborne_artifact_extractor.sh > airborne_artifact_extractor_unix.sh
chmod +x airborne_artifact_extractor_unix.sh
# Utilisez ensuite airborne_artifact_extractor_unix.sh
Éditeurs de texte : La plupart des éditeurs de texte modernes (comme VS Code, Sublime Text, Atom, Notepad++) permettent de changer les fins de ligne. Ouvrez le fichier du script, trouvez le paramètre des fins de ligne (généralement dans la barre d'état ou le menu Fichier/Édition), et changez-le de « CRLF » ou « Windows » à « LF » ou « Unix ». Puis enregistrez à nouveau le fichier.
Après avoir converti les fins de ligne, essayez d'exécuter à nouveau le script. N'oubliez pas de vous assurer également qu'il dispose des permissions d'exécution (chmod +x airborne_artifact_extractor.sh).
Exécutez le script depuis le Terminal, en fournissant le chemin vers le bundle .logarchive et des paramètres de plage horaire facultatifs :
./airborne_artifact_extractor.sh /chemin/vers/vos_journaux_iphone.logarchive [paramètres_plage_horaire]
Arguments :
R1 (Obligatoire) : Le chemin complet ou relatif vers le fichier/bundle .logarchive.
[paramètres_plage_horaire] (Facultatif) : Paramètres de plage horaire standard de log show. S'ils sont omis, le script analysera par défaut les journaux du --last 7d (7 derniers jours).
Exemples :
--last 24h (pour les 24 dernières heures)
--last 3d (pour les 3 derniers jours)
--start "AAAA-MM-JJ HH:MM:SS" --end "AAAA-MM-JJ HH:MM:SS" (pour une plage horaire spécifique). Important : assurez-vous que la chaîne date-heure est entre guillemets.
Configuration du fuseau horaire : Le script inclut des paramètres de fuseau horaire en haut, que vous pouvez modifier :
TZ_SETTING : définit le fuseau horaire utilisé pour interpréter les arguments --start et --end que vous fournissez. Par exemple, s'il est défini sur "Etc/GMT-7" (ce qui correspond à UTC+7), et que vous utilisez --start "2025-04-10 00:00:00", cela sera traité comme minuit le 10 avril dans le fuseau horaire UTC+7. Si vous souhaitez que le script utilise le fuseau horaire local actuel de votre Mac pour ces arguments, vous pouvez définir TZ_SETTING="" ou commenter cette ligne.
TIMEZONE_DISPLAY : spécifie le fuseau horaire pour formater les horodatages dans les fichiers journaux de sortie via l'option log show --timezone. Exemple : "Asia/Bangkok" pour UTC+7. Choisissez un nom de fuseau horaire reconnu par votre système.
Exemples de commandes :
Analyser les journaux des 7 derniers jours (comportement par défaut) :
Bash
./airborne_artifact_extractor.sh /Volumes/ExternalHD/iOS_Logs/iPhone13_archive.logarchive
Analyser les journaux des 48 dernières heures : Bash
./airborne_artifact_extractor.sh ./My_iPhone_Sysdiagnose.logarchive --last 48h
Analyser les journaux pour une plage horaire spécifique (les heures seront interprétées selon TZ_SETTING) : Bash
./airborne_artifact_extractor.sh ../Log_Archives/device_XYZ.logarchive --start "2025-04-05 00:00:00" --end "2025-04-06 23:59:59"
Fichiers de sortie
Le script créera un nouveau répertoire nommé airborne_traces_YYYYMMDD_HHMMSS (où YYYYMMDD_HHMMSS correspond à la date et à l'heure actuelles) dans le même répertoire que le script (ou dans votre répertoire de travail actuel si le répertoire du script n'est pas accessible en écriture). Dans ce dossier, vous trouverez plusieurs fichiers .txt, chacun contenant la sortie d'une requête spécifique. Les noms de fichiers sont préfixés par des numéros pour l'ordre :
01_critical_process_errors.txt : Défauts et erreurs pour les processus critiques.
02_process_termination_exceptions.txt : Terminaisons inattendues ou exceptions dans les processus clés.
03_kernel_panics.txt : Événements de panique du noyau.
04_airplay_subsystem_errors.txt : Erreurs et défauts dans le sous-système AirPlay.
05_mdns_errors.txt : Erreurs et défauts dans mDNSResponder (Bonjour).
06_airplay_pairing_auth_failures.txt : Problèmes d'appairage, d'authentification ou de connexions AirPlay/rapportd.
07_network_connection_errors.txt : Erreurs de connexion réseau provenant des processus concernés.
08_networkd_errors.txt : Erreurs dans le service système networkd.
09_sandbox_violations.txt : Messages liés aux violations de sandbox.
10_profile_activity.txt : Activité liée aux profils de configuration.
Interprétation des résultats
Les fichiers vides sont courants : Un fichier de sortie vide signifie qu'aucune entrée de journal n'a correspondu aux critères de cette requête spécifique pour la plage horaire donnée. Dans de nombreux cas, c'est un bon signe, indiquant l'absence de ces indicateurs suspects particuliers.
Concentrez-vous sur les schémas et les corrélations : Un message d'erreur isolé n'est souvent pas indicatif d'une compromission. Recherchez des groupes d'erreurs, des séquences suspectes d'événements à travers différents fichiers journaux, ou des erreurs qui corrèlent avec des moments où vous avez rencontré un comportement inhabituel de l'appareil ou où vous utilisiez des services potentiellement vulnérables comme AirPlay.
ECONNRESET dans les journaux rapportd (souvent dans 06_... ou 07_...) : Ils indiquent des terminaisons brutales de connexion TCP. Bien qu'ils puissent être causés par des problèmes réseau bénins (mauvais Wi-Fi, problèmes de routeur), dans le contexte d'une investigation sur les vulnérabilités « Airborne », ils méritent un examen plus approfondi. Ils pourraient signifier une instabilité causée par une tentative d'exploitation sur votre appareil ou sur un appareil pair, ou une interférence réseau.
Les plantages (types défaut ou panique) dans mediaserverd, AirPlayXPCHelper (souvent dans 01_..., 02_...), ou les paniques du noyau (03_...) sont généralement des indicateurs forts d'instabilité système qui pourrait être liée à une exploitation si elles se produisent de manière inattendue ou lors d'interactions réseau ciblées par « Airborne ».
Le contexte est essentiel : Examinez toujours les résultats des journaux en tenant compte de votre connaissance de l'utilisation de l'appareil à ce moment-là, de l'environnement réseau dans lequel il se trouvait, et de tout symptôme réel observé.
N'hésitez pas à forker ce dépôt, à suggérer des améliorations, à signaler des problèmes ou à ajouter des requêtes plus spécifiques qui pourraient aider à identifier les traces de telles vulnérabilités.