Apple n’a cessé de vanter et de vendre ses systèmes d’exploitation comme les plus sûrs au monde. L’affaire Pegasus démontre, au contraire, que loin d’être invulnérables, iOS et MacOS peuvent être attaqués, avec des conséquences lourdes sur la vie privée de leurs utilisateurs. Si la plupart de ces failles sont demeurées secrètes, certains éléments publiés permettent de comprendre comment Pegasus réussit à s’infiltrer jusqu’au cœur de smartphones réputés imprenables. 

Quand on demande aux utilisateurs avertis quels sont les systèmes d’exploitation les plus sûrs qu’ils connaissent, on peut parier qu’ils répondront soit MacOS, soit Linux. Rares sont ceux qui songerait à citer Windows, a priori. Il faut dire que le produit phare de Microsoft n’a cessé, au long des années, de donner une piètre image de ses performances, rythmées par les nombreux bugs et autres écrans bleus qui furent – et sont parfois encore – le quotidien de ses utilisateurs.

Il faut cependant faire attention, car nous avançons ici en terrain miné. La mauvaise réputation de Windows résulte avant tout de son instabilité. Certes, le système d’exploitation compte de nombreuses failles; mais ce que les utilisateurs subissent au quotidien relève plus du syndrome du crash aléatoire que de la cyberattaque – même si, malheureusement, ces dernières – les ransomware, entre autres – tendent à se multiplier. Il convient de soigneusement distinguer instabilité et sécurité. Un système peut crasher toutes les cinq minutes, tout en garantissant une sécurité absolue. La réciproque est également possible : un système qui ronronne se révèlera n’être qu’une vulgaire passoire.

Aux yeux du profane, la plupart du temps ces deux notions se confondent : stabilité rime avec sécurité. Cette opinion ne repose sur aucun fondement factuel, juste une sensation. Le discours marketing d’Apple se nourrit de cette sensation de sécurité faussement éprouvée par les utilisateurs de Mac et d’iPhone, qu’il n’hésite pas à qualifier de « machines les plus sûres du monde ». Le même sentiment d’impunité affecte également, pour d’autres raisons, les utilisateurs de Linux. Il est vrai que ces deux systèmes ont jusqu’ici été relativement peu ciblés par les attaques; il ne faudrait cependant pas voir dans cette immunité une conséquence de la qualité de leur code, mais plutôt le constat d’une réalité économique : avec des parts de marché assez faibles, le bénéfice tiré d’éventuelles cyberattaques sur ces plates-formes ne compense pas l’investissement économique, assez lourd, nécessaire à l’identification puis l’exploitation des vulnérabilités. Mais les choses changent, et l’affaire Pegasus en est un bon exemple.

L’exemple de la vulnérabilité CVE-2016-4656

On peut se demander comment, en l’espace de quelques cycles CPU, une application malveillante arrive à prendre le contrôle total d’un téléphone tant vanté pour sa sécurité et sa robustesse, pour le transformer en parfaite petite «balance»? Si le mécanisme de pénétration des versions les plus récentes de Pegasus n’a pas été rendu public, certains groupes de white hackers ont analysé des failles par lesquelles ce même logiciel avait déjà réussi, il y a cinq ans, à forcer les barrières érigées par les développeurs d’Apple. L’exemple le mieux documenté est lié à la mise à jour iOS 9.3.5 de 2016, correspondant à la faille dénommée CVE-2016-4656. Apple ne publie jamais les détails de ses patches, pour éviter que des groupes malveillants ne profitent des informations avant que tous les utilisateurs aient eu le temps d’installer un correctif. A posteriori cependant, il est possible de savoir quels éléments du noyau ont été modifiés en comparant les deux versions binaires successives. En principe, le binaire du noyau ne devrait pas être lisible. Effectivement, celui d’iOS 9 était protégé par un triple mécanisme : le binaire était crypté, et seul le firmware savait à quel endroit se trouvait la clef de décryptage (1). De plus, à chaque mise en route du téléphone, le noyau se plaçait à une adresse RAM aléatoirement choisie : le décalage entre l’adresse théorique du noyau et son adresse réelle est appelée «KASLR». Enfin, le noyau résidait évidemment en mémoire superviseur, à laquelle les applications n’ont normalement pas accès.

Alors, comment faire ? En pratique, le mécanisme de décryptage du noyau d’iOS 9 avait une faiblesse : il décryptait toujours le code au même endroit en mémoire superviseur (kernel cache), puis copiait le résultat à l’adresse définitive une fois le KASLR déterminé. Il suffisait donc de gagner accès à l’espace superviseur pour récupérer non seulement le code du noyau, mais les symboles qui allaient avec et qui indiquaient où résidait chaque fonction. Gagner cet accès, quitte à lire le noyau octet par octet, n’était pas très complexe, comme le prouve la suite. Une liste de failles plus récentes, dont certaines permettent de calculer le KASLR, est disponible sur le blog du projet Zéro de Google 

La plupart de ces failles utilisent des mécanismes de bas niveau du noyau, une tâche simplifiée par le fait que Apple publie une grande partie de ses noyaux en Open Source sous le nom XNU. Comme toute arme à double tranchant, la publication du code permet également à des auditeurs externes de repérer des failles avant que celles-ci ne soient exploitées.

Source : L’informaticien