1 pièce(s) jointe(s)
Mal utilisé, l’API de vérification du code signé d’Apple pourrait rendre indétectable des malwares sur macOS
Une mauvaise utilisation de l’API de vérification du code signé avec l’outil d’Apple pourrait rendre du code malicieux indétectable sur macOS
rapporte Josh Pitts
Alors que de nombreuses raisons peuvent pousser les individus à acquérir les appareils d’Apple, certaines personnes et entreprises mettent en avant les arguments de la sécurité. La firme de Cupertino elle-même n’hésite pas à démontrer à la moindre occasion que la sécurité de ses systèmes et de ses appareils constitue un des points sur lesquels elle a bâti sa réputation. L’an dernier par exemple, Apple a soutenu officiellement que les antivirus ne sont plus admis sur son App Store, car elles promettraient des fonctionnalités qui ne pourraient être exécutées en raison de la configuration de son système mobile iOS. Pour autant, ces systèmes ne sont pas à l’abri de failles exploitables par des tiers malveillants.
Récemment, un chercheur en sécurité nommé Josh Pitts et travaillant chez Okta, une entreprise américaine de sécurité, a découvert un bogue créé par des tiers en utilisant l’API de signature de code pour vérifier que les binaires exécutés sont pourvus de certificats d’authentification émis par Apple et donc dépourvus de code malicieux. Il convient de souligner que la signature de code est un mécanisme de sécurité qui utilise une infrastructure de clé publique pour signer numériquement du code compilé ou même des langages de script afin de garantir une origine de confiance et s’assurer que le code déployé n’a pas été modifié. Sous Windows, vous pouvez signer de manière cryptographique tout ce que vous voulez en partant des binaires .NET aux scripts PowerShell. Sur macOS/iOS, les développeurs doivent signer leurs applications achevées avant que celles-ci n’atteignent l’App Store. Cela permet de s’assurer que le code des binaires et des applicatifs Mach-O signé qui s’exécute dans la mémoire du système est digne de confiance. Une fois le code signé vérifié, les acteurs de la sécurité peuvent s’en servir pour accélérer leurs processus d’investigations en intégrant dans une liste blanche le code de confiance afin de le séparer du code non fiable.
Dans la récente découverte rapportée, Pitts a noté que des tiers malveillants pourraient signer du code avec l’outil d’Apple et cacher dans le même paquet, du code non fiable signé par un tiers sans que des logiciels utilisant l’API de vérification de code d’Apple pour vérifier que le code d’une autre application est sain puissent détecter le code malveillant caché. Pour cela, l’acteur malveillant a besoin dans un premier temps signer le fichier Fat/ Universal. Un fichier Fat/Universal est un format binaire qui contient plusieurs fichiers Mach-O (exécutable, dyld ou bundle), chacun ciblant une architecture de processeur natif spécifique (exemple : i386, x86_64 ou PPC).
Ensuite, le code binaire malveillant, ou code non fourni par Apple, doit être signé ad hoc et compilé i386 pour un macOS x86_64 bits. Pitts précise que la raison pour laquelle le code malveillant, ou code « non signé », doit être du type i386, est que l’API de signature de code a une préférence pour l’architecture du processeur natif (x86_64) et échouera dans la vérification de code non signé s’il est du type x86_64. Enfin, le paramètre CPU_TYPE dans l’entête Fat du binaire d’Apple doit être défini sur un type non valide ou sur un type de processeur qui n’est pas natif du chipset hôte. Une fois cela effectué, lorsque certains développeurs utiliseront dans leurs applications l’API d’Apple pour vérifier la validité de la signature du code du binaire, le loader Mach-O chargera le binaire Mach-O valablement signé et exécutera le code malveillant (non signé Apple). Le problème ici n’est pas la signature du code, mais plutôt la manière d’utiliser l’API de vérification de signature d’Apple pour vérifier l’authenticité du code.
Pitts précise que pour que l’application tierce puisse détecter que le code signé contient une partie de code non signé par Apple, il faut que les développeurs effectuant la vérification avec leur application utilisent les commandes ci-dessous avec l’API de vérification du code signé afin de s’assurer que toutes les architectures sont passées en revue :
Code:
- codesign -vv -R='anchor apple' ./some_application_or_mach-o # for Apple signed code
- codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # for Apple signed code and Apple developer signed code
À ces commandes, d’autres paramètres peuvent être également ajoutés.
Pitts rapporte qu’après avoir intégré du code personnellement signé à une application signée avec l’outil d’Apple, plusieurs applications et outils interagissant avec son code n’ont pas été en mesure de détecter que le code personnellement signé pouvait être du code malicieux. Parmi ces logiciels, nous avons Little Snitch, xFence, TaskExplorer, WhatsYourSign, Google Santa, Facebook OSQuery, VirusTotal et bien d’autres encore. Un mail a été envoyé à ces différentes entreprises et des correctifs sont déjà disponibles.
Source : Okta, Motherboard Vice
Et vous ?
:fleche: Pensez-vous que la mauvaise utilisation de l’API de vérification de la signature de code par des tiers pourrait remettre en cause la sécurité sur macOS ?
:fleche: Quels commentaires faites-vous des applications n’utilisant pas comme il se doit l’API de vérification des certificats numériques d’Apple ?
Voir aussi
:fleche: Apple annonce formellement le bannissement des antivirus de son App Store dans une récente mise à jour de sa politique destinée aux développeurs
:fleche: No iOS Zone : une faille zero-day qui permet de rendre hors service les appareils iOS 8 dans une zone couverte par un Wifi malveillant
:fleche: Une faille de sécurité de macOS High Sierra permet de se connecter en tant que root sans mot de passe, mais il existe un moyen de la contourner
:fleche: L’API pour les captures d’écran sur macOS pourrait être exploitée pour voler des mots de passe et autres informations sensibles, rapporte Felix Krause
:fleche: Deux failles zero-day découvertes dans OS X affectent les versions 10.9.5 à 10.10.5
