Tribune Lexsi : autopsie de la surprenante vulnérabilité Apple – SSL

Cloud
apple-faille-implementation-ssl

Apple a mis à jour son système iOS (iPhone et iPad) puis Mac OS X, suite à une vulnérabilité critique touchant son implémentation de SSL/TLS. Analyse de trois experts de Lexsi (cabinet de conseil en cybersécurité).

Apple vient de faire une mise à jour de son système iOS (iPhone et iPad) suite à une vulnérabilité critique touchant son implémentation de SSL/TLS.

Cette vulnérabilité, référencée depuis le 8 janvier 2014 mais présente depuis environ un an et demi, permet à un attaquant situé entre un utilisateur et un serveur distant, de visualiser ou modifier les données échangées au sein d’une connexion SSL (attaque Man-in-The-Middle).

Le navigateur Safari ainsi que de nombreuses applications (Mail, iCloud, Twitter…) s’appuyant sur cette librairie sont donc impactées par cette vulnérabilité. La vulnérabilité affecte les versions iOS 6.x (avant la version 6.1.6 disponible depuis hier – 24/02/2014) et les versions iOS 7.X (avant la version 7.0.6 disponible depuis avant-hier).

Elle affecte également le système Mavericks de MacOS X (Une mise à jour pour Mac OS X est maintenant disponible) et d’Apple TV (mais aucun correctif n’est disponible actuellement).

L’analyse et le point de vue de trois experts de Lexsi (cabinet de conseil en cybersécurité) : Nicolas Kerschenbaum, Miguel Enes et Fabien Jobin.

Petit rappel sur le SSL pour mieux comprendre la vulnérabilité Apple
SSL (Secure Socket Layer) est un protocole initialement créé par Netscape afin de protéger les échanges entre un client et un serveur en :
– Vérifiant l’identité du serveur (authentification);
– Chiffrant les données (confidentialité);
– Garantissant l’intégrité des données échangées (intégrité et non répudiation).

Analyse du code Apple :

Le code vulnérable se situe donc dans libsecurity_ssl/lib/sslKeyExchange.c et plus précisément dans la fonction SSLVerifySignedServerKeyExchange :

analyse-code

Comme nous pouvons le voir dans le code ci-dessus, le troisième appel à SSLHashSHA1.update est suivi de deux instructions goto fail. Bien que l’indentation du code source puisse nous induire en erreur, le problème se situe ici.

En effet, l’analyse minutieuse du code source montre que, quel que soit le résultat de l’appel à la fonction SSLHashSHA1.update(&hashCtx,&signedParams), le flux d’exécution ira systématiquement en goto fail retournant, en cas de réussite de la fonction précédente (valeur de retour égale à 0), la valeur err qui n’aura pas été affectée par les appels aux fonctions SSLHashSHA1.final() et sslRawVerify().

Schématiquement, le code se présente ainsi :

code-apple-lexsi
Notons qu’il faut que les trois fonctions SSLHashSHA1.update et que la fonction ReadyHash ne retournent pas d’erreur afin que la valeur de err soit égale à 0 permettant un retour “valide” de la fonctionSSLVerifySignedServerKeyExchange. La signature du message ServerKeyExchange ne sera donc jamais vérifiée permettant d’usurper l’identité du serveur.

Cette vulnérabilité aurait-elle pu être découverte plus tôt ? Il est étonnant que cette faille de sécurité n’ait été découverte que maintenant. En effet, il faut savoir que le fichier contenant le code vulnérable est disponible publiquement sur les serveurs d’Apple. Une analyse statique de ce code aurait rapidement permis de détecter la faille de sécurité. Notons que ce type de faille, i.e. faille logique est un bon cas d’école.

Notre expérience en audit de code spécialisé en détection de vulnérabilités, nous a appris à maintes reprises que les vulnérabilités les plus dramatiques viennent généralement d’une erreur d’implémentation.

Réflexion sur cette vulnérabilité très étonnante

En effet nous avons montré que la dernière partie du code, celle qui vérifie effectivement les paramètres échangés, n’est jamais exécutée (c’est ce qu’on appelle dans le jargon du “code mort”).

On pourrait être tenté de penser qu’une société comme Apple utilise des logiciels de qualité de code permettant notamment de détecter les portions de code jamais appelées/inutiles. Ceci lève beaucoup de questions :
– Apple utilise-t-il des outils de qualité de code ?
– S’ils sont utilisés, pourquoi les développeurs n’ont pas traité l’alerte ?
– Pour les plus techniques, quelles sont les options de compilation utilisées ? En effet, suivant le compilateur utilisé, des options de compilations auraient pu mettre en évidence la présence de code mort, comme le soulève Matt Suiche dans son billet.
– Est-ce volontaire ? Les plus paranoïaques penseront sûrement qu’il s’agit d’une faille intentionnelle, c’est-à-dire une backdoor. L’esprit de Snowden, Prism et Big Brother NSA.

Il est très fort probable que cette vulnérabilité soit exploitée prochainement à grande échelle avec des scénarios très simples comme la mise en place de faux hot-spots Wifi réalisant automatiquement l’attaque de Man-in-The-Middle pour récupérer des identifiants/mots de passe ou encore de numéros de cartes bancaires. Des personnes travaillent d’ailleurs sur le sujet pour diffuser des outils clés en main. Le fameux “Attention à ne pas vous connecter n’importe où” n’aura jamais été aussi vrai !

Vous êtes vulnérable ? Rien de plus simple, vous avez juste à visiter l’un des deux sites (inoffensifs) https://gotofail.com ou https://www.imperialviolet.org.

Recommandations

Pour se protéger sur iPhone, il suffit d’installer la dernière mise à jour iOS (version 6.1.6 ou 7.0.6 suivant votre système). Il s’agit d’une petite mise à jour.

Simultanément à la diffusion de cette tribune Lexsi à la presse, Apple a proposé un correctif pour Mac OS X.

Rappelons que certains programmes (Firefox ou Chrome par exemple) n’utilisent pas les librairies du système et ne sont donc pas affectés.

(Credit photo illustration : Shutterstock.com – Copyright: Olivier Le Moa)


Lire la biographie de l´auteur  Masquer la biographie de l´auteur