Google trouve un niveau d’attaques d’État-nation sur l’iPhone

En matière de sécurité mobile, les utilisateurs sont régulièrement avertis d’être extrêmement prudents et d’éviter les liens, les e-mails et les pièces jointes suspects. Mais la croissance des attaques sans clic contourne ces défenses souples.

Google a récemment percé une telle attaque, qui s’est avérée avoir touché un iPhone. « Nous estimons qu’il s’agit de l’un des exploits les plus sophistiqués sur le plan technique que nous ayons jamais vus, démontrant une fois de plus que les capacités (un fournisseur) rivalisent avec celles que l’on croyait auparavant accessibles à seulement une poignée d’États-nations », dit l’avis de Google.

La partie la plus effrayante du rapport Google — et il y a un parcelle des parties effrayantes – est qu’il viole l’une des règles non écrites des alertes de sécurité, à savoir qu’il est sous-optimal de signaler les détails d’une attaque pour laquelle il n’y a pas de défense efficace. Je suis d’accord avec Google ici sur le fait que les détails doivent être discutés afin que la communauté puisse concocter plus rapidement une défense.

« Il a été documenté que NSO propose à ses clients une technologie d’exploitation sans clic, où même des cibles très averties techniquement qui pourraient ne pas cliquer sur un lien de phishing ignorent totalement qu’elles sont ciblées. Dans le scénario sans clic, aucune interaction de l’utilisateur n’est requise. Cela signifie que l’attaquant n’a pas besoin d’envoyer de messages de phishing. L’exploit ne fonctionne que silencieusement en arrière-plan. À moins de ne pas utiliser d’appareil, il n’y a aucun moyen d’empêcher l’exploitation par un exploit sans clic. C’est une arme contre laquelle il n’y a aucune défense.

Sur cette pensée réconfortante, passons aux détails.

Le graphique qui n’est pas vraiment un graphique

La société à l’origine du logiciel utilisé dans ces attaques, NSO, aurait utilisé une fausse astuce GIF pour cibler une vulnérabilité dans l’analyseur PDF CoreGraphics. Les fichiers ont une extension .gif, mais ce ne sont pas des fichiers image GIF. Le nom est uniquement conçu pour empêcher un utilisateur de s’inquiéter.

« La bibliothèque ImageIO est utilisée pour deviner le format correct du fichier source et l’analyser, en ignorant complètement l’extension de fichier. En utilisant cette fausse astuce gif, plus de 20 codecs d’image font soudainement partie de la surface d’attaque sans clic d’iMessage, y compris des formats très obscurs et complexes, exposant à distance probablement des centaines de milliers de lignes de code.

Comme Google l’a noté, ces attaques sont difficiles à contrecarrer. Il est peu probable que le blocage de toutes les images GIF s’avère efficace. Premièrement, ces fichiers ne sont pas réellement des GIF. L’approche la plus simple consiste à bloquer n’importe quoi à l’aide d’une extension GIF, mais les méchants passeront simplement à une autre extension au son inoffensif.

(Remarque : Le rapport de Google indique qu’Apple a tenté d’annuler l’attaque GIF via des correctifs publiés en 2021. « Apple nous informe qu’ils ont restreint les formats ImageIO disponibles accessibles à partir d’IMTranscoderAgent à partir d’iOS 14.8.1 (26 octobre 2021), et a complètement supprimé le chemin du code GIF d’IMTranscoderAgent à partir d’iOS 15.0 (20 septembre 2021), le décodage GIF se déroulant entièrement dans BlastDoor.

La technique de compression

Il s’agit d’une tactique courante et légitime pour réduire la taille des fichiers en remplaçant certains caractères répétés. Cela entre un peu dans les mauvaises herbes: «Cela donne à la page de destination actuelle JBIG2Bitmap une valeur inconnue, mais très grande, pour h. Étant donné que cette valeur h est utilisée pour la vérification des limites et est censée refléter la taille allouée du tampon de sauvegarde de la page, cela a pour effet de « délimiter » le canevas de dessin. Cela signifie que les commandes de segment JBIG2 suivantes peuvent lire et écrire dans la mémoire en dehors des limites d’origine du tampon de sauvegarde de page.

Le résultat?

«En rendant des bitmaps de 4 octets aux coordonnées de canevas correctes, ils peuvent écrire dans tous les champs de la page JBIG2Bitmap et en choisissant soigneusement de nouvelles valeurs pour w, h et line, ils peuvent écrire dans des décalages arbitraires à partir du tampon de sauvegarde de la page. À ce stade, il serait également possible d’écrire sur des adresses mémoire absolues arbitraires si vous connaissiez leurs décalages à partir du tampon de sauvegarde de la page. Mais comment calculer ces décalages ? Jusqu’à présent, cet exploit s’est déroulé d’une manière très similaire à un exploit de langage de script canonique qui, en Javascript, pourrait aboutir à un objet ArrayBuffer illimité avec accès à la mémoire. Mais dans ces cas, l’attaquant a la possibilité d’exécuter du Javascript arbitraire, qui peut évidemment être utilisé pour calculer des décalages et effectuer des calculs arbitraires. Comment faites-vous cela dans un analyseur d’images en un seul passage ? En pratique, cela signifie qu’il est possible d’appliquer les opérateurs logiques AND, OR, XOR et XNOR entre les régions de mémoire à des décalages arbitraires à partir du tampon de sauvegarde JBIG2Bitmap de la page actuelle. Et puisque cela a été illimité…, il est possible d’effectuer ces opérations logiques sur la mémoire à des décalages arbitraires hors limites.

Il s’agit d’un problème de codage qui permet aux attaquants de s’introduire et d’exécuter du code non autorisé. Cette information est essentielle, car elle permet à la fois aux codeurs d’éviter ce trou de temps en temps et de donner au logiciel quelque chose de concret à trouver et à bloquer.

Attaques hors de portée

Un autre point de Google : « JBIG2 n’a pas de capacités de script, mais lorsqu’il est combiné à une vulnérabilité, il a la capacité d’émuler des circuits de portes logiques arbitraires fonctionnant sur une mémoire arbitraire. Alors pourquoi ne pas simplement l’utiliser pour construire votre propre architecture informatique et script ça !? C’est exactement ce que fait cet exploit. En utilisant plus de 70 000 commandes de segment définissant des opérations binaires logiques, ils définissent une petite architecture informatique avec des fonctionnalités telles que des registres et un additionneur et comparateur 64 bits complet, qu’ils utilisent pour rechercher la mémoire et effectuer des opérations arithmétiques. Ce n’est pas aussi rapide que Javascript, mais c’est fondamentalement équivalent en termes de calcul. Les opérations d’amorçage pour l’exploit d’échappement du bac à sable sont écrites pour s’exécuter sur ce circuit logique et le tout s’exécute dans cet environnement étrange et émulé créé à partir d’un seul passage de décompression à travers un flux JBIG2.

Google a tout à fait raison lorsqu’il affirme que ce genre de choses se rapproche du niveau de mauvaise qualité de l’État-nation. Mais au moins, ces détails aideront les DSI et les RSSI à commencer à le contourner.