Je peux devenir Apple, et toi aussi

Divulgation publique de la vulnérabilité d'un tiers à la signature de code Apple

Contrairement à certains travaux précédents, cette vulnérabilité ne nécessite pas de droits d'administrateur, elle ne nécessite pas de code JIT ou de corruption de mémoire pour contourner la vérification de signature de code. Tout ce dont vous avez besoin est un fichier Fat / Universal correctement formaté, et la vérification de la signature du code affichera un résultat valide.

Résumé

• Un détour trouvé par une API tierce pour signer du code vous permet de présenter n'importe quel code signé par Apple.
• Tous les fournisseurs et projets open source bien connus sont notifiés (voir la liste ci-dessous). Des correctifs leur sont disponibles .
• Il est possible que le problème affecte d'autres programmes tiers qui utilisent les API de signature de code officielles d'Apple.
• Les développeurs sont responsables de la bonne utilisation de l'API de signature de code. Il existe des outils de piratage de démonstration (PoC) pour les tests.
• S'applique uniquement à macOS et aux anciennes versions d'OSX.

Vendeurs concernés

• VirusTotal - CVE-2018-10408
• Google - Père Noël, molcodesignchecker - CVE-2018-10405
• Facebook - OSQuery - CVE-2018-6336
• Développement d'objectifs - LittleSnitch - CVE-2018-10470
• F-Secure - xFence (également LittleFlocker) CVE-2018-10403
• Objective-See - WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (et autres) - CVE-2018-10404
• Yelp - OSXCollector - CVE-2018-10406
• Noir de carbone - Réponse Cb - CVE-2018-10407

L'importance de la signature de code et son fonctionnement sur macOS / iOS

La signature de code est une construction de sécurité qui utilise une infrastructure à clé publique (PKI) pour signer numériquement du code compilé ou même des scripts pour garantir qu'il est fiable et que le code est authentique. Sous Windows, vous pouvez presque tout signer de manière cryptographique: des binaires .NET aux scripts PowerShell. Sur macOS / iOS, la signature de code se réfère principalement aux binaires Mach-O et aux packages d'application pour permettre uniquement l'exécution de code approuvé en mémoire.

Les antivirus, les systèmes de sécurité et la réponse aux incidents, ainsi que les outils médico-légaux analysent les signatures pour identifier le code de confiance parmi ceux qui ne sont pas fiables. La vérification des signatures accélère l'analyse. Divers outils utilisent des informations de signature de code pour mettre en œuvre des mesures de sécurité: ce sont des listes blanches, des antivirus, des systèmes de réponse aux incidents et de recherche de menaces. Compromettre la signature du code dans l'un des systèmes d'exploitation les plus populaires signifie saper la construction de sécurité de base, dont dépendent de nombreuses opérations de sécurité de l'information de routine.

Des problèmes ont déjà été trouvés dans la signature du code ( 1 , 2 , 3 , 4 , 5 ). Contrairement à certains travaux précédents, cette vulnérabilité ne nécessite pas de droits d'administrateur, elle ne nécessite pas de code JIT ou de corruption de mémoire pour contourner la vérification de signature de code. Tout ce dont vous avez besoin est un fichier Fat / Universal correctement formaté, et la vérification de la signature du code affichera un résultat valide.

Détails de vulnérabilité

L'essence de la vulnérabilité est que le chargeur Mach-O et l'API de signature de code ne sont pas utilisés pour vérifier les signatures de code de manière incorrecte. Cette différence peut être exploitée en utilisant un binaire Universal / Fat spécialement conçu.

Qu'est-ce qu'un fichier Fat / Universal?

Fat / Universal est un format binaire qui contient plusieurs fichiers Mach-O (fichier exécutable, dyld ou package), chacun se concentrant sur une architecture CPU spécifique (par exemple, i386, x86_64 ou PPC).

Prérequis

• Le premier Mach-O du fichier Fat / Universal doit être signé par Apple, il peut s'agir d'un fichier i386, x86_64 ou même d'un PPC.
• Un code binaire ou étranger malveillant auto-signé doit être compilé sous i386 pour macOS x86_64.
• Le CPU_TYPE dans l'en-tête Fat du binaire Apple doit être défini sur un type de processeur non valide ou un type qui n'est pas natif du chipset hôte.

Sans passer les codes SecRequirementRef et SecCSFlags correspondants, l'interface du programme API de signature de code ( SecCodeCheckValidity ) vérifiera le premier binaire du fichier Fat / Universal pour l'origine de la signature (par exemple, Apple) et vérifier l'authenticité de la signature. Ensuite, l'API vérifiera la conformité et l'authenticité de la signature de tous les autres fichiers binaires dans le fichier Fat / Universal, mais sans vérifier la racine de confiance de l'autorité de certification . La raison pour laquelle le code malveillant ou le code «non signé» doit être i386 est que l'API de signature de code est configurée par défaut pour vérifier la signature de code pour l'architecture CPU native (x86_64).

L'une des raisons pour lesquelles le code auto-signé réussit le test est que, même dans les binaires Apple principaux, le champ TeamIdentifier est défini sur not set . L'illustration ci-dessous montre le binaire Mach-O valide, signé par Apple (python.x64), à côté du Mach-O auto-signé (ncat.i386). Les deux ont `TeamIdentifier = not set`.



Par exemple, j'ai signé le binaire en utilisant l'ID développeur et j'ai essayé in lipo de le combiner avec le binaire Apple en un seul fichier Fat / Universal. Ce type de signature de code échoue.



Mon PoC initial est ncat (de nmap), que j'ai appelé ncat.frankenstein. Ici, le fichier Fat résultant contient le binaire python x86_64 signé Apple et le binaire ncat i386 auto-signé (adhoc). Un binaire auto-signé est facilement créé avec codesign -s - target_mach-o_or_fat_binary . Voici à quoi cela ressemble dans MachOView:



Si vous exécutez ce fichier, alors python x86_64 démarrera:



Et la signature du code est en cours de vérification:



Comment ai-je exécuté le binaire auto-signé ncat?

Pour cela, définissez un type CPU_Type non valide ou un processeur non natif (par exemple, PPC). Ensuite, le chargeur Mach-O ignore le binaire Mach-O avec une signature valide et exécute du code malveillant (non signé par Apple):



Ensuite, ncat.frankenstein est exécuté et le résultat de la validation sera valid :



Nous avons publié ncat.frankenstein et quatre autres exemples afin que les développeurs puissent vérifier les vulnérabilités de leurs produits.

Recommandations

Sur la ligne de commande

Dépend de la façon dont vous vérifiez le code signé. Si vous utilisez codesign, vous connaissez probablement les commandes suivantes:

• codesign –dvvvv - vidage de l'autorité de certification et TeamIdentifier (ID développeur)
• codesign –vv - vérification stricte de toutes les architectures

Mais pour vérifier correctement ce type d'abus, vous devez ajouter l'exigence de certificat d'ancrage avec les commandes suivantes:

• codesign -vv -R='anchor apple' ./some_application_or_mach-o # pour le code signé par Apple
• codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # pour le code signé par Apple et Apple

Une telle commande affichera une erreur lors de la vérification du code avec la signature de quelqu'un d'autre:



Vous pouvez utiliser la commande spctl , mais elle nécessite une analyse minutieuse de la sortie de la commande. Par exemple, le binaire Mach-O avec la signature d'Apple (/ bin / ls) et Safari renvoie ce qui suit:



Et voici le résultat d'une application signée par Apple:



Notez la ligne «(le code est valide mais ne semble pas être une application)» pour / bin / ls, qui ne réussit pas le test. A titre de comparaison, voici le résultat du fichier Fat / Universal ncat.frankenstein:



Le fichier ncat.frankenstein Fat / Universal ne montre pas que le code est valide. Par conséquent, je ne peux pas recommander spctl pour vérifier manuellement les binaires Mach-O hors ligne. Utilisez simplement codesign avec les drapeaux appropriés.

Pour les développeurs

En règle générale, les développeurs vérifient les binaires Mach-O ou Fat / Universal à l'aide des API SecStaticCodeCheckValidityWithErrors () ou SecStaticCodeCheckValidity () avec les indicateurs suivants:

• kSecCSStrictValidate
• KSecCSCheckAllArchitectures

Ces indicateurs doivent garantir que tout le code chargé en mémoire dans le fichier Mach-O ou Fat / Universal est signé de manière cryptographique. Cependant, ces API ne fournissent pas de validation appropriée par défaut, donc les développeurs tiers doivent isoler chaque architecture dans le fichier Fat / Universal et vérifier que les identités correspondent et sont cryptographiquement robustes.

La meilleure façon de tester chaque architecture imbriquée dans le fichier Fat / Universal est d'appeler d'abord SecRequirementCreateWithString avec l'exigence «ancre apple», puis SecStaticCodeCheckValidity avec kSecCSDefaultFlags | kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | kSecCSEnforceRevocationChecks en référence à l'exigence; comme indiqué dans le code source patché de WhatsYourSign .

En passant la «pomme d'ancrage» à la fonction SecRequirmentCreateWithString, cet appel fonctionne de manière similaire à la commande codesign -vv -R='anchor apple' , nécessitant la chaîne de confiance Apple Software Signing pour tous les binaires imbriqués du fichier Fat / Universal. En outre, en passant des drapeaux et l'exigence de SecStaticCodeCheckValidity, toutes les architectures sont vérifiées pour cette exigence et des vérifications de révocation sont appliquées.

Démonstrations

L'outil de codesign de codesign d'Apple et la nécessité d'utiliser le drapeau -R .



LittleSnitch - la vérification du fichier Fat / Universal sur le disque ne fonctionne pas, mais LittleSnitch vérifie correctement le processus en mémoire.





LittleFlocker - F-Secure a acheté LittleFlocker, et maintenant il s'appelle xFence.



F-Secure xFence (anciennement LittleFlocker)



Objective-See Tools

Taskexplorer





WhatsYourSign



Facebook OSquery est le résultat d'échantillons de logiciels malveillants et / bin / ls comme exemple valide.



Emission de Google Santa - Fileinfo montre que ncat.frankenstein est sur liste blanche:



Refuser l'exécution ncat (non signé) et l'autorisation d'exécution ncat.frankenstein:



Journal Santa.log affichant les événements de l'exemple précédent:



Réponse du noir de carbone



VirusTotal - exemple bash_ppc_adhoc avant d'installer le correctif dans VirusTotal:

Dates de divulgation

22/02/2018: Un rapport et un PoC ont été envoyés à Apple pour contourner les systèmes de sécurité tiers.

01/03/2018: Apple a répondu que les développeurs tiers devraient utiliser kSecCSCheckAllArchitectures et kSecCSStrictValidate avec l'API SecStaticCodeCheckValidity, et la documentation du développeur sera mise à jour en conséquence.

03/06/2018: un rapport et un PoC ont été envoyés à Apple pour contourner les drapeaux et vérifier strictement la codesign .

16/03/2018: Informations supplémentaires envoyées à Apple.

20/03/2018: Apple a déclaré qu'il ne voyait pas cela comme un problème de sécurité qui devrait être résolu directement.

29/03/2018: Apple a déclaré que la documentation pourrait être mise à jour, mais "[...] les développeurs tiers devraient faire un travail supplémentaire pour vérifier que toutes les identités dans le binaire universel sont les mêmes s'ils veulent présenter un résultat significatif."

04/02/2018: premier contact avec le CERT / CC et collaboration ultérieure pour clarifier l'étendue et l'impact de la vulnérabilité.

04/09/2018: tous les développeurs tiers connus affectés par la vulnérabilité sont notifiés en coordination avec CERT / CC.

18/04/2018: dernier contact avec le CERT / CC avec une recommandation selon laquelle la divulgation publique d'informations sur un blog est préférable pour informer les autres développeurs tiers qui utilisent l'API de signature de code d'Apple en privé.

06/05/2018: dernier contact avec les développeurs avant publication.

06/12/2018: divulgation d'informations.

En conclusion

Merci à tous les développeurs tiers pour leur travail acharné et leur professionnalisme dans la résolution de ce problème. Les vulnérabilités de signature de code démoralisent particulièrement les bogues, en particulier pour les entreprises qui tentent de fournir une meilleure sécurité que celle par défaut du système d'exploitation.

---

GMO GlobalSign Russia ACTION pour les abonnés Habr


Vous pouvez obtenir des informations supplémentaires en contactant le responsable GlobalSign par téléphone: +7 (499) 678 2210, ou remplissez le formulaire sur le site Internet en indiquant le code promo CS002HBFR.