Historique des correctifs Apple

Cette année, a1exdandy et moi avons parlé lors de conférences VolgaCTF et KazHackStan avec une présentation des programmes Patch Diffing écrits sur Objective-C, et comment l'utiliser pour rechercher et trouver des vulnérabilités 0 et 1 jour dans les produits Apple. Vous pouvez regarder la vidéo de la présentation ici , et pour lire l'article, bienvenue à cat.

Binary Diffing est le processus de comparaison de deux fichiers exécutables afin de trouver des similitudes et des différences entre eux. Patch Diffing est un cas particulier de Binary Diffing lorsqu'un fichier vulnérable est comparé à un fichier fixe (fichier avec un patch). Vous pouvez donc savoir quelles corrections le développeur a apportées et comprendre quelle était la vulnérabilité.

Il y a quelques années (notamment en 2013), un article a été publié sur les programmes Patch Diffing pour Windows, auxquels nous avons également participé. Nous vous recommandons de vous familiariser avec celui-ci si vous êtes intéressé par cette rubrique en lien avec le système d'exploitation Windows. Dans le même article, nous parlerons de l'analyse des programmes pour apple OS.

Comment la différenciation binaire et la différenciation de patchs peuvent-elles être utiles?

La tâche principale de Binary Diffing est de suivre les modifications apportées à l'application. Pour ce faire, vous devez prendre l'ancienne version et la comparer avec la nouvelle pour voir quels changements le développeur a ajoutés et comment ils sont mis en œuvre.

Examinons les situations dans lesquelles cela peut être utile:

• Analyse du développement du programme : en comparant les nouvelles et anciennes versions, vous pouvez comprendre comment l'application se développe, quelles nouvelles fonctionnalités sont ajoutées, qui sont supprimées et quels changements le code existant a subi.
• Importation des connaissances existantes : dans les programmes qui n'utilisent pas d'informations symboliques, les ingénieurs en rétro-ingénierie doivent consacrer beaucoup plus de temps à étudier la logique et à rechercher les vulnérabilités. Mais il arrive que dans une version du logiciel, les développeurs laissent accidentellement ou délibérément des informations symboliques. Ces informations peuvent être portées à partir de là vers la version logicielle dont vous avez besoin. Par exemple , les employés de Google Project Zero utilisant Binary Diffing ont pu obtenir des caractères pour de nouvelles versions Windows d'Adobe Reader à partir de versions plus anciennes pour d'autres systèmes d'exploitation, ce qui les a aidés à trouver des vulnérabilités;
• Formation sur les vrais logiciels : à notre avis, Patch Diffing est un excellent moyen de passer facilement de l'étude de petits problèmes CTF à la recherche de vrais logiciels. En explorant le correctif, vous pouvez regarder la vraie vulnérabilité d'un grand logiciel avec toutes ses fonctionnalités (tout en sachant avec certitude que la vulnérabilité est présente dans le code). En explorant les erreurs dans un produit, vous pouvez progressivement passer à la recherche des mêmes vulnérabilités. En prime, vous pouvez essayer d'écrire des exploits pour eux;
• Création d'exploits d'un jour : lorsqu'un développeur a déjà publié un correctif, vous pouvez rapidement l'analyser, écrire un exploit pour cette vulnérabilité et obtenir un exploit d'un jour. Dans le même temps, il y a ce que l'on appelle le Patch Gapping - le temps entre la sortie du patch et son installation directe par les clients. Pendant ce temps, un exploit d'une journée peut fonctionner avec succès et bénéficier à son auteur (installer les mises à jour en temps opportun!) Jusqu'à ce que tout le monde installe le correctif publié par les développeurs. Il existe des situations où une vulnérabilité est corrigée dans une bibliothèque, mais les programmes utilisent toujours une version obsolète de la bibliothèque. Voici quelques exemples intéressants de Patch Gapping pour Chrome et WebKit ;
• Recherche de vulnérabilités à 0 jour : peu importe à quel point cela peut paraître étrange, en analysant les correctifs, vous pouvez également trouver des vulnérabilités précédemment inconnues (vulnérabilités à 0 jour). Les développeurs se trompent également et, par conséquent, dans le processus de création d'un correctif, la vulnérabilité peut ne pas être fermée correctement. Ainsi, en analysant un patch, vous pouvez trouver un moyen de le contourner. Par exemple, les développeurs d'Apache Struts ont corrigé une vulnérabilité cinq fois, mais le correctif ne fonctionnait que dans sa sixième version! De plus, souvent un développeur, accomplissant clairement la tâche qui lui a été assignée pour corriger une certaine vulnérabilité, peut ne pas remarquer ce qui se passe dans les sections voisines du code. Il pourrait y avoir exactement la même vulnérabilité à proximité, et en cas de détection, ce sera 0 jour. Il est important d'étudier le modèle d'une erreur de développeur détectée et d'essayer de trouver quelque chose de similaire dans le même programme. Si le développeur a fait une erreur à un endroit, la probabilité de répéter la même erreur ailleurs est élevée.

Il existe un mythe selon lequel masquer les informations sur les correctifs de vulnérabilité augmente la sécurité. Cependant, les attaquants, en règle générale, ont déjà développé une infrastructure pour analyser les correctifs, de sorte qu'ils trouveront rapidement les données qui les intéressent. Cacher les vulnérabilités complique le travail de ceux qui sont responsables de la protection du système, car sans un accès complet aux informations, il est impossible de comprendre l'importance de ce correctif pour l'entreprise. À ce sujet, nous vous recommandons fortement de lire l'article «Rashomon ofclosure» du chercheur Halvar Flake, où la situation est vue sous différents angles.

Les vulnérabilités découvertes ne sont pas toujours cachées intentionnellement. Les développeurs peuvent ne pas attacher une importance particulière à certaines des lacunes de leur produit et les corriger sans publicité, comme un bogue normal.

Nous sommes sûrs que ce ne sont pas toutes les situations dans lesquelles vous pouvez utiliser la différenciation binaire et la correction de patch, et dans les commentaires, vous pouvez écrire vos propres scripts.

Boîte à outils

De la théorie, nous passons progressivement à la pratique. Naturellement, faire manuellement la différence binaire est une entreprise folle. Une boîte à outils complète a été développée depuis longtemps, comprenant à la fois des programmes autonomes et des plugins pour les analyseurs binaires populaires: Diaphora, BinDiff, DarunGrim, YaDiff, rizzo, Realyze, Turbodiff, patchdiff2, rematch et autres.

Interface BinDiff.

Interface Diaphora

En pratique, nous n'utilisons principalement que les deux premiers (ils sont présentés dans les captures d'écran ci-dessus). La plupart des outils actuels, malheureusement, ne sont pas encourageants avec la qualité du travail, ou sont complètement abandonnés. Il existe maintenant de nouveaux outils utilisant ML, mais leur qualité laisse beaucoup à désirer, bien qu'ils aient des idées intéressantes pour comparer des fichiers binaires de différentes architectures.

Je voudrais également noter séparément les outils récemment apparus pour comparer le code open-source dans les fichiers binaires: Pigaios et Karta. Il s'agit d'une direction très intéressante et utile. Ils collectent des métriques à partir du code source, puis les utilisent pour comparer des fonctions dans des fichiers binaires. Ceci est très utile en l'absence de caractères et de liens statiques. La tâche de ces outils est de mapper des fonctions d'un fichier à des fonctions d'un autre.

Comparaison des correctifs pour les systèmes d'exploitation Apple

En règle générale, les applications pour Apple OS écrivent sur Objective-C. Il s'agit d'une extension orientée objet pour C, basée sur des paradigmes de langage Smalltalk avec son propre runtime.

Si nous ouvrons le programme sur Objective-C dans un analyseur binaire (dans notre cas, c'est un IDA), nous verrons quelque chose comme ceci: les fonctions en C / C ++ auront des noms abstraits, et les fonctions en Objective-C seront appelées très joliment. (Nous dirons tout de suite que nous ne considérons pas les situations d'obscurcissement de code - c'est une histoire distincte.) Cela facilite l'ingénierie inverse: il est facile de voir quel objet est appelé, quelle méthode est utilisée et quels arguments il contient. De plus, ces informations symboliques simplifient considérablement le travail avec les outils de comparaison de fichiers binaires. Il vous permet de cartographier rapidement et avec un nombre minimum de fonctions d'erreurs.

Lorsqu'il n'y a pas de symboles, les outils doivent utiliser des algorithmes internes pour l'analyse, l'heuristique, etc. Naturellement, ils ne fonctionnent pas toujours correctement.

Cas d'utilisation où la différence de patch était très utile

Probablement, cette présentation (au format de 45 minutes) et cet article n'auraient pas vu le jour si récemment, Apple n'avait pas surpris la communauté mondiale de la recherche à plusieurs reprises. Regardons ces cas.

Cas 1: CVE-2019-8606

En mai 2019, iOS 12.3 pour iPhone a été publié, où la vulnérabilité avec laquelle il était possible d'installer le jailbreak a été corrigée. En juillet de la même année, Apple a publié la version 12.4, où le jailbreak a recommencé à fonctionner: les employés ont accidentellement retiré le patch de protection. La version corrigée n'a été publiée qu'après un mois: tout ce temps, tout appareil sur la dernière version pouvait être facilement soumis à des opérations de jailbreak. Tout cela a été découvert grâce au patch différent.

Cas 2: CVE-2019-7278 et CVE-2019-7286

L'expérience personnelle avec Patch différant lors de la conférence Hack in the Box dans son rapport Recréer un jailbreak iOS 0 jours à partir des correctifs de sécurité d'Apple a été décrite par le chercheur en sécurité Stefan Esser. Il a parlé de CVE-2019-7278 et CVE-2019-7286 - ils sont remarquables pour ceux qui ont été découverts grâce au Google Threat Analysis Group lors de leur utilisation réelle par les attaquants (ITW, dans la nature). Apple a reçu des informations à leur sujet, mais ni eux ni les gars de Google n'ont révélé de détails techniques. Stefan s'est alors demandé ce que les attaquants utilisaient. Nous vous recommandons fortement de lire son rapport, car il parle également du processus de comparaison des composants du noyau et de l'espace utilisateur.
Fait intéressant: un jour ou deux avant le discours de Stefan, Project Zero Ian Beer a publié une série d'articles «Une plongée très profonde dans les chaînes d'exploitation iOS trouvées dans la nature» , ce qui a quelque peu confondu les cartes pour le chercheur;)

Cas 3: checkm8

Les appareils Apple utilisent deux chargeurs de démarrage: Bootrom et Iboot. Le premier commence à fonctionner dès que l'appareil s'allume. Il est en mémoire morte et ne peut pas être mis à jour. Iboot est un chargeur de démarrage de deuxième niveau qui améliore l'authentification qui s'exécute dans la chaîne de démarrage.
La particularité des chargeurs est qu'ils partagent le code. Au début de l'année dernière, les spécialistes ont comparé les mises à jour pour Iboot et ont constaté qu'Apple avait corrigé une vulnérabilité dans la pile USB. Sachant que le même code est utilisé dans la partie non mise à jour de Bootrom, ils ont réalisé que cette vulnérabilité existe également là-bas. Puis le développement de l'exploit checkm8 a commencé. Désormais, tous les appareils basés sur des puces de A5 à A11 (de l'iPhone 4s à l'iPhone X) sont complètement vulnérables, et il est possible d'y exécuter votre propre code. Dans le même temps, sur les appareils des versions XR et 11, cette vulnérabilité est déjà fermée, et il n'y a eu aucun rapport de cela d'Apple.
Donc, sachant où il a été corrigé et comment le code est divisé, vous pouvez trouver des trucs vraiment cool!

Notre histoire: CVE-2019-8574

En mai, Apple a publié une nouvelle mise à jour pour ses appareils. Nous avons examiné la liste des vulnérabilités corrigées et trouvé l'utilitaire sysdiagnose. Ce programme collecte des informations de diagnostic à partir de diverses sources et les transfère à l'utilisateur sous la forme d'une archive pour une analyse plus approfondie, un support ou un centre de service. Il semblait impossible d'influencer la façon dont elle recueille les informations. La description du correctif indiquait que la vulnérabilité pouvait être utilisée pour élever les privilèges et était une erreur de corruption de mémoire, ce qui nous intriguait encore plus. Et l'auteur de la découverte lui-même n'a publié aucune description de lui-même ...

Vous pouvez appeler sysdiagnose sur macOS en appuyant sur Ctrl + Option + Maj +., Ou en utilisant la commande sudo sysdiagnose. Sur les appareils iOS, vous devez maintenir enfoncées la touche marche / arrêt et les touches de volume.

Patch Apple différent dans la pratique

Si vous souhaitez patcher différents appareils Apple, vous devez obtenir deux versions de la mise à jour (ancienne et nouvelle). Sur macOS, vous pouvez analyser des fichiers dans le catalogue de mises à jour logicielles. Cette méthode n'aide pas toujours, car Apple supprime certaines mises à jour. Les mises à jour se trouvent également dans le répertoire / Library / Updates. Vous pouvez trouver le firmware pour les appareils iOS sur le site Web ipsw.me.
Pour macOS, vous devez extraire les fichiers exécutables, les fichiers de bibliothèque, les frameworks et le noyau à l'aide de l'utilitaire Suspicious Package.
Pour les appareils iOS, les choses sont un peu plus compliquées. La mise à jour elle-même est une archive ZIP. Dans cette archive, vous devez trouver le fichier kernelcache: à l'intérieur se trouve le noyau et son extension. Cependant, avant l'analyse, vous devez convertir le fichier au format Mach-O. Cela peut être fait en utilisant les utilitaires img4tool, joker, jtool2 et autres.
Le firmware du composant utilisateur se trouve dans la plus grande image DMG: il contient le système racine et les fichiers exécutables. Cependant, si vous regardez les bibliothèques et les frameworks partagés, ils ne seront pas là. Le fait est que pour optimiser l'espace, ils sont placés dans dyld_shared_cache. Ce fichier contient toutes les bibliothèques de l'iPhone et occupe plus de 1 gigaoctet, ce qui complique son analyse. Si vous devez télécharger une partie distincte du fichier ipsw, utilisez l'utilitaire ipsw ( https://github.com/blacktop/ipsw ).

Patchdifting CVE-2019-8574

Pour étudier le patch CVE-2019-8574, nous obtenons un fichier de Library / Updates et extrayons deux fichiers exécutables sysdiagnose (anciens et nouveaux) à l'aide du paquet suspect, puis vérifions les mises à jour via des utilitaires pour comparer les codes binaires, par exemple Diaphora ou BinDiff (ils sont beaucoup mieux que l'éditeur hexadécimal).

Comment fonctionne le patch

Pour l'architecture x86_64, nous n'avons trouvé qu'une seule fonction modifiée. Il y a plus de changements dans ARM, mais ils sont insignifiants.

Le problème venait de la méthode [SDTask start]: elle a ajouté une nouvelle vérification. Dans la figure, vous pouvez voir comment un appel à une fonction isAppleInternal est appelé et la présence de la sous-chaîne / usr / local dans un chemin est vérifiée.

Comme indiqué précédemment, sysdiagnose collecte des informations à partir de diverses sources. Les sources peuvent être soit des fichiers (par exemple, un journal des événements), soit la sortie de certaines commandes d'informations (par exemple, répertorier les processus ou les threads à l'aide de ps) - ces tâches sont stockées dans sysdiagnose en tant qu'objets SDTask. La méthode [SDTask start] démarre l'exécution des tâches. Dans la figure ci-dessous, vous pouvez voir le code dans lequel toutes les tâches sont formées. Tous les chemins des fichiers exécutables et leurs arguments sont écrits directement dans le programme, et il existe des tâches provenant de divers répertoires, dont / usr / local.

Ainsi, avant d'installer le correctif, n'importe quelle tâche peut être effectuée quel que soit l'emplacement du fichier exécutable. Après l'installation du correctif, la fonction isAppleInternal est appelée, qui vérifie si l'appareil est un appareil de test interne d'Apple. S'il s'agit d'un périphérique interne, la tâche est effectuée de manière standard et, si elle est côté client, la présence de la sous-chaîne / usr / local / dans le chemin du fichier exécutable de la tâche est vérifiée. Si une sous-chaîne est trouvée, la tâche ne sera pas terminée.

Rappelons que dans la description de la vulnérabilité, il a été dit qu'il s'agit d'une erreur de corruption de mémoire, mais dans le patch nous n'avons rien remarqué de tel ... A notre avis, il s'agit d'une vulnérabilité logique bien exploitée et stable.

Comment l'exploiter

Pour exploiter la vulnérabilité, vous devez effectuer les étapes suivantes:
Créez n'importe quel fichier exécutable (script binaire ou shell) que sysdiagnose lance à partir de / usr / local / bin, et placez-y notre charge utile. La liste des fichiers valides est donnée ci-dessous. Il est important que le gestionnaire de paquets de brassage soit installé sur le système: il permet à l'utilisateur de créer des fichiers dans / usr / local / sans augmenter les privilèges.

Il est nécessaire d'appeler sysdiagnose. Dans le même temps, notre charge utile sera exécutée avec les droits d'utilisateur root, et sa sortie sera placée dans l'archive que sysdiagnose forme. Ainsi, nous obtenons une élévation de privilèges. Cependant, l'exécution de sysdiagnose lui-même nécessite des privilèges élevés. Mais, comme mentionné ci-dessus, sysdiagnose peut également être lancé à l'aide du raccourci clavier, et cela fonctionne même à partir de l'écran de verrouillage macOS.
Cette vulnérabilité peut être utilisée pour créer divers programmes malveillants.

/usr/local/bin/airplayutil /usr/local/bin/amstool /usr/local/bin/apsclient /usr/local/bin/audioDeviceDump /usr/local/bin/cdcontexttool /usr/local/bin/cddebug /usr/local/bin/cdknowledgetool /usr/local/bin/dastool /usr/local/bin/idstool /usr/local/bin/imtool /usr/local/bin/keystorectl /usr/local/bin/pmtool /usr/local/bin/xcpm /usr/local/efi/bin/efi-perf 

Il est intéressant de noter que d'autres vulnérabilités pourraient être associées au gestionnaire de paquets de brassage, ou plutôt à la possibilité d'écrire dans / usr / local / sans privilèges.

Conclusion

Avec cette étude, nous aimerions montrer l'importance et la criticité des correctifs différant non seulement pour les attaquants, mais aussi pour augmenter la sécurité des produits logiciels. Malheureusement, le patch peut non seulement fermer la vulnérabilité, mais aussi jouer entre les mains de l'attaquant.

Néanmoins, cette approche permet non seulement d'étudier les vulnérabilités connues, mais aussi d'en rechercher de nouvelles comme elles. Par conséquent, nous pensons que le patch diffing est un must have pour tout chercheur.