Ce travail, réalisé par Silvanovich et son collègue, Samuel Groß, a également fait l’objet d’une présentation lors de la conférence Black Hat, qui a eu lieu cette année à Las Vegas.
L’article de Silvanovich est technique mais sans plus, il mérite donc que vous y jetiez un coup d’œil même si vous n’avez aucune expérience de codage à proprement parlé.
Elle nous rappelle notamment à quel point il est facile de rendre un logiciel vulnérable vis-à-vis d’attaques distantes, même si ce dernier ne correspond pas à l’image que vous vous faites d’un code côté serveur, et même s’il est exécuté sur un équipement que vous ne considérez pas être un serveur.
Ceci dit, malgré les révélations présentées dans cet article et la présentation faite lors de cette conférence, il n’y a pas lieu de paniquer.
Du moins, vous n’avez pas besoin de vous inquiéter si vous avez déjà installé les dernières mises à jour Apple, car les failles que Silvanovich a décrites en détail ont déjà été corrigées.
Si vous n’avez pas encore mis votre iPhone à jour vers iOS 12.4, faites-le dès maintenant !
Réglages → Général → Mise à jour logicielle est le moyen le plus rapide de vérifier.
Voici, néanmoins, quelques explications.
Un exploit qui autorise une RCE, raccourci pour Remote Code Execution, permet de faire exactement ce que son nom suggère.
RCE signifie que même des utilisateurs avertis peuvent être amenés à donner à des cybercriminels un accès total à leur appareil sans rien faire d’exceptionnel et sans avoir vu s’afficher le moindre avertissement.
Un exploit “fully remotable” (intégralement distant) est bien pire encore, car les utilisateurs n’ont rien à faire de particulier, à part avoir leurs appareils allumés et fonctionnant normalement.
Un site web piégé qui plante et prend le contrôle de votre navigateur donne à des cybercriminels la possibilité de lancer une attaque RCE.
De même, avant que Microsoft ne désactive par défaut AutoRun pour les périphériques USB, l’attaque surnommée “USB-stick-in-the-car-park” était considérée comme un moyen fiable de mener à bien une offensive RCE, car le malware choisi était généralement lancé dès qu’un individu connectait une clé USB piégée.
Aucune boîte de dialogue affichant le fameux Etes-vous sûr(e)? avec les boutons [OUI]/[NON] n’est apparue comme une sorte d’avertissement, vous permettant ainsi d’éviter ce malware.
Néanmoins, même si visiter un site web ou brancher un périphérique USB ne sont pas des actions qui sont impossibles à vous faire faire pour des cybercriminels, ces attaques ne sont pas pour autant considérées comme le Saint Graal des attaques RCE, car un certain engagement de la part des utilisateurs est nécessaire.
Une attaque entièrement distante “a lieu tout simplement”, à l’image du tristement célèbre Worm Internet de 1988 ou du super virus, très répandu, SQL Slammer de 2003.
Ces attaques ont envoyé des données réseau, que votre ordinateur scrutait délibérément, mais aucune technique particulière pour mettre un pied dans le système n’a été nécessaire en amont, une mauvaise gestion de la part de votre ordinateur a tout simplement suffit.
Cela permettait à des cybercriminels de packager le code exécutable à l’intérieur de leurs paquets de données et de lancer une RCE de manière automatique et sans surveillance.
L’une des méthodes d’attaque d’Internet Worm, par exemple, était d’exploiter des serveurs de messagerie mal configurés sur lesquels le mode de débogage était activé de manière incorrecte.
Si vous aviez laissé l’option de débogage activée par inadvertance, les emails présentés d’une certaine manière étaient traités comme des commandes à exécuter (!), et non comme des messages à transmettre. Le serveur de messagerie exécutait donc le malware immédiatement après l’avoir accepté.
Les emails du ver (worm) étaient donc immédiatement dangereux et aucun utilisateur n’avait réellement besoin de les recevoir au préalable, encore moins de les ouvrir ou d’extraire et ouvrir les pièces jointes.
Téléphones ≠ Serveurs
Vous pourriez penser que des appareils tels que des téléphones mobiles, qui ne fonctionnent généralement pas comme des serveurs, seraient en grande partie immunisés contre ce type d’attaque à distance.
Après tout, vous n’utilisez pas, en général, de serveur de messagerie ou de serveur SQL sur votre téléphone, et même si vous le souhaitiez, Apple ne laisserait probablement pas traîné ce type de logiciel sur l’App Store.
Même si vous deviez jailbreaker votre téléphone pour installer ce logiciel serveur, votre FAI pourrait ne pas autoriser les connexions réseau entrantes qui tenteraient d’atteindre votre téléphone de toutes les façons.
Mais, comme nous le rappelle Silvanovich, les téléphones reposent essentiellement sur les systèmes de messagerie, et il existe de nombreuses sortes de messages que nous nous attendons à recevoir avant même qu’ils n’arrivent véritablement sur nos appareils.
NB : Un appel entrant est l’exemple le plus flagrant : nous nous attendons à ce que le téléphone sonne et que le numéro de la ligne appelante soit récupéré et affiché, non seulement avant d’appuyer sur le bouton pour accepter l’appel, mais également lorsque notre téléphone est en mode verrouillé.
En d’autres termes, même si nous considérons les téléphones comme des clients réseau plutôt que comme des serveurs réseau, il existe de nombreuses applications côté client qui téléchargent, traitent, agissent et affichent automatiquement les données provenant d’une source externe arbitraire.
Nous ne parlons pas uniquement d’éléments tels que des mises à jour automatiques de logiciels ou d’anti-virus provenant d’un service connu, fiable et bien réglementé, mais également de contenus tels que des SMS ou des emails conçus, de manière inoffensive ou malveillante, par un acteur inconnu, non fiable et délibérément malveillant.
Silvanovich a identifié cinq principaux composants de traitement de messages présentant un intérêt pour l’iPhone, et couvrant les sous-systèmes iOS spécifiquement conçus pour extraire, traiter et vous informer automatiquement du contenu entrant : SMS, MMS, messagerie vocale Visual, email et iMessage.
En fin de compte, les chercheurs n’ont trouvé aucune faille exploitable dans les SMS ou les MMS, peut-être parce que ces sous-systèmes sont plutôt classiques et ont donc des fonctionnalités bien comprises et quelque peu limitées.
Mais les autres n’étaient pas aussi robustes.
Comme vous pouvez l’imaginer, plus il y a de fonctionnalités, de types de messages, d’options, de plugins et de formats de fichiers qu’une application peut prendre ne charge, plus il est probable qu’un bug existe lors d’une manipulation de fichiers conçus de manière inhabituelle, inconnue ou malveillante.
Par exemple, vous vous attendez à ce qu’un logiciel de traitement d’images ne pouvant afficher que les bons vieux fichiers BMP (structure de données simples et non compressées) soit moins susceptible de planter en manipulant des fichiers bizarres, qu’un logiciel pouvant gérer 72 fichiers image différents avec plusieurs niveaux de complexité.
Plus vous devrez écrire du code pour traiter les données entrantes et gérer toutes les variations possibles, plus il sera difficile de mener à bien cette tâche, plus les tests seront difficiles à mettre en œuvre, plus il sera probable de rencontrer des bugs subtils, et plus il faudra de temps pour que chaque chemin possible à travers ce code labyrinthique soit expérimenté lors du traitement des données réelles sur le terrain.
En termes simples, nous disons que sa surface d’attaque est plus grande.
Plus de code, plus de bugs
Bien que Silvanovich et Groß aient trouvé des vulnérabilités dans la messagerie vocale Visual et dans le système de traitement du courrier électronique d’iOS, celles-ci n’étaient en réalité pas très importantes.
Mais via iMessage, ils ont trouvé au moins huit failles de sécurité, répertoriées avec un numéro CVE : CVE-2019-8624, -8663, -8661, -8646, -8647, -8662, -8641 et -8660 (c’est l’ordre dans lequel elles sont traitées dans l’article, c’est pourquoi elles ne sont pas ici classées dans l’ordre numérique).
Notez que même si Apple considère CVE-2019-8661 comme ayant été corrigée dans son dernier avertissement de sécurité iOS, les Googlers n’ont pas révélé les détails de celle-ci car ils ne pensent pas que la mise à jour d’Apple ait résolu véritablement le problème.
Quoi faire ?
- Installez la dernière mise à jour iOS si vous ne l’avez pas encore fait. La plupart des bugs cités ci-dessus ne sont plus à craindre une fois que vous aurez installé les correctifs.
- Procurez-vous la nouvelle mise à jour dès sa publication. On dirait qu’Apple travaille toujours sur CVE-2019-8661 et que Google donne à l’entreprise un peu plus de temps pour traiter définitivement ce bug.
- En faire moins c’est risquer d’avoir plus de problèmes. Si vous êtes vous-même un programmeur, prenez garde à écrire du code qui en fasse plus que nécessaire, faites en sorte que votre code ne dépende pas de nombreux autres modules ou plugins que vous ne pouvez pas fiabiliser facilement, et ce quel que soit votre niveau de confiance en votre propre code et en son absence de bugs.
Billet inspiré de Update your iPhone – remote control holes revealed by researchers, sur Sophos nakedsecurity.
