Conférence Programmez ! DevCon #1 « Après-midi Windows 10 IoT »

Venez découvrir Windows 10 IoT, un Windows dédié aux objets connectés et au Raspberry Pi. Vous saurez tout sur l’architecture, le développement, le déploiement d’une app pour IoT et découvrir le back-end IoT ! Plus d'informations.

Kaspersky raconte la traque d'une faille zero-day dans Silverlight

Par:
fredericmazue

jeu, 14/01/2016 - 15:29

Kaspersky Lab a découvert une vulnérabilité « Zero Day » dans Silverlight. Cette faille exploitée pouvait potentiellement offrir un accès total à un ordinateur infecté, lui permettant ainsi d’exécuter du code malveillant afin de dérober des informations confidentielles et de se livrer à d’autres activités illicites. La vulnérabilité a été corrigée dans la dernière mise à jour de sécurité publiée par Microsoft ce mardi 12 janvier 2016. Sa découverte est le fruit de cinq mois d’enquête ayant fait suite à un article paru dans Ars Technica. Kaspersky raconte :

A l’été 2015, une cyberattaque lancée contre la société Hacking Team (connue pour le développement de « spyware légal ») a fait les gros titres. L’un des articles à ce sujet, publié dans Ars Technica, mentionnait une fuite dans des échanges supposés entre des représentants de Hacking Team et Vitaliy Toropov, un développeur indépendant de programmes exploitant des vulnérabilités. Entre autres choses, l’article citait une correspondance dans laquelle Toropov tentait de vendre à Hacking Team une faille Zero Day particulièrement intéressante : il s’agissait d’exploiter une vulnérabilité présente depuis quatre ans et toujours non corrigée dans la technologie Microsoft Silverlight. C’est cette information qui a mis la puce à l’oreille des chercheurs de Kaspersky Lab.

L’article en question ne fournissant aucune autre information sur la faille exploitée, les chercheurs ont entamé leur enquête en partant du nom du vendeur. Ils ont rapidement découvert qu’un utilisateur qui se nommait Vitaliy Toropov était un contributeur très actif de la base de données open source des vulnérabilités (OSVDB), où tout un chacun peut publier des informations dans ce domaine. En analysant son profil public sur le site OSVBD.org, les chercheurs de Kaspersky Lab se sont aperçu qu’en 2013, Toropov avait publié une preuve de concept (POC) décrivant un bogue dans la technologie Silverlight. Ce POC portait sur une ancienne vulnérabilité connue et aujourd’hui corrigée. Cependant, il donnait également des détails supplémentaires qui ont indiqué aux chercheurs de Kaspersky Lab comment l’auteur écrivait du code destiné à exploiter cette faille.

Au cours de l’analyse effectuée par les experts de Kaspersky Lab, certaines chaînes de code spécifiques se démarquaient véritablement. Grâce à ces informations, ils ont créé plusieurs règles de détection pour les technologies de protection de Kaspersky Lab : dès lors qu’un utilisateur, ayant accepté de communiquer des données sur les menaces à Kaspersky Security Network (KSN), rencontrait un logiciel malveillant qui présentait le comportement correspondant à ces règles de détection, le système marquait le fichier comme extrêmement suspect et adressait une notification à la société pour qu’il soit analysé. Cette tactique partait d’une hypothèse simple : si Toropov avait tenté de vendre l’exploitation d’une faille Zero Day à Hacking Team, il y avait de fortes chances pour qu’il ait fait de même auprès d’autres éditeurs de spyware. A la suite de cette activité, d’autres campagnes de cyber espionnage pouvaient s’en servir afin de cibler et d’infecter des victimes sans méfiance.

Cette hypothèse était fondée. Plusieurs mois après la mise en œuvre des règles spéciales de détection, un client de Kaspersky Lab a été la cible d’une attaque employant un fichier suspect présentant les caractéristiques recherchées. Quelques heures plus tard, quelqu’un (peut-être une victime des attaques) se trouvant au Laos a envoyé à un service multiscanner un fichier ayant les mêmes caractéristiques. Les experts de Kaspersky Lab, en analysant l’attaque, ont découvert que celle-ci exploitait en fait un bogue inconnu de la technologie Silverlight. Les informations concernant cette faille ont été communiquées sans délai à Microsoft pour validation.

« Bien que n’étant pas sûrs que la faille que nous avons découverte soit en fait celle évoquée dans l’article d’Ars Technica, nous avons de bonnes raisons de penser que c’est bien le cas. En comparant l’analyse de ce fichier aux travaux précédents de Vitaliy Toropov, nous sommes parvenus à la conclusion que l’auteur de l’exploitation de la vulnérabilité découverte récemment et l’auteur des POC publiés sur OSVDB sous le nom de Toropov était une seule et même personne. En même temps, il n’est pas impossible que nous ayons trouvé une autre faille Zero Day dans Silverlight. Globalement, ces recherches ont contribué à rendre le cyberespace un peu plus sûr en mettant au jour une nouvelle vulnérabilité Zero Day et en la révélant de manière responsable. Nous encourageons tous les utilisateurs des produits Microsoft à mettre à jour leurs systèmes dès que possible afin de corriger cette vulnérabilité », commente Costin Raiu, Directeur de l’équipe GReAT (Global Research & Analysis Team) de Kaspersky Lab.

La faille se situait dans la classe BinaryReader. Elle est décrite en détail dans un très intéressant billet technique sur SecureList, que nous résumons ici. Lors de l'instanciation de cette classe, il est possible de définir sa propre implémentation de l'encodage de caractères :

Dans cet encodeur, il est possible d'utiliser son propre décodeur

A l'exécution, la classe BinaryReader utilise une méthode InternalReadChars qui est estampillée unsafe car elle réalise des manipulation de pointeurs:

Si l'index passé à InternalReadChars est vérifié en amont de l'appel, il ne l'est plus ensuite.

Comme l'index est ensuite incrémenté en fonction du nombre d'octets lus par la méthode GetChars du décodeur de l'encodeur personnalisé, Il suffit que l'implémentation du code de GetChars soit malicieuse, pour aller écrire dans une mémoire illicite. Kaspersky donne un exemple de code.

Ce code, à la première itération, recule le pointeur de 18 octets en retournant un faux nombre d'octets lus : return -(18). L'appelant InternalReadChars de GetChars ne se pose pas de question existentielle quant à la valeur farfelue retournée. Il modifie son pointeur avec elle et continue d'itérer. GetChars, en fonction du nombre d'itérations, écrit alors dans la zone mémoire illicite.

Encore et toujours les pointeurs... :-)