La sécurité pendant la semaine 34 : les patchs ne suffisent pas

On peut trouver de nombreuses raisons de ne pas corriger un bug immédiatement, ni ce semestre, ni même jamais. Pourtant, il faut résoudre le problème.

Quelle semaine épouvantable pour le monde de la sécurité informatique, mes amis ! Après une semaine amusante pendant laquelle nous avons découvert des bugs, des exploits zero-day et d’autres raretés convoitées par les chercheurs, voici le contrecoup douloureux d’avoir vu toutes ces intrusions dans des softwares vulnérables. C’est important, mais parfois très ennuyeux. A chaque fois, je me nourris grâce à une nouvelle fournée d’articles sur la sécurité informatique parus sur notre blog d’actualité Threatpost. Les trois articles qui font les gros titres sur les patchs sont plutôt difficiles à digérer.

Bon, quoi qu’il en soit, c’est important. On ne peut pas simplement trouver une vulnérabilité, comme ils disent. Le plus difficile, c’est de la corriger sans tout détruire. On peut trouver de nombreuses raisons de ne pas corriger un bug immédiatement, ni ce semestre, ni même jamais. Pourtant, il faut résoudre le problème.
Aujourd’hui, nous présenterons trois cas de bugs qui n’ont malheureusement pas été corrigés. Pour rappel, chaque semaine, l’équipe de Threatpost choisit trois nouvelles importantes que je vais commenter en longueur. Vous trouverez ici les articles précédents.

Autre bug sur Android, maintenant dans Google Admin

L’article du Threatpost. Les recherches de MWR.

Qu’est-ce qui a été découvert ?

Avez-vous déjà remarqué ces merveilleux articles sur des bugs qui paraissent en masse dernièrement ? Eh bien, une voiture a été piratée ? Voici une demi-douzaine de vulnérabilités trouvées dans des voitures ! D’abord, la faille Stagefright, ensuite quelques petits bugs, et maintenant, Google Admin et une fuite du sandbox.

security-week-34-kid

Google Admin, l’une des applications du système Android, peut accepter des URL d’autres applications. Apparemment, n’importe quelle URL fonctionne, même celles qui commencent par « file:// ». Par conséquent, une simple action sur le réseau, comme le chargement de sites Web, commence dans une sorte de gestionnaire de fichiers. Toutes les applications sur Android ne sont-elles pas isolées les unes des autres ? Zut, ce n’est pas le cas ! Google Admin jouit de privilèges, et en le trompant avec une URL indésirable, une application peut s’échapper du sandbox et accéder à des données privées.

Comment cela a été corrigé ?

Tout d’abord, permettez-moi de vous expliquer comment cette vulnérabilité a été dévoilée par des chercheurs indépendants. Elle n’a été découverte qu’au mois de mars, avec l’envoi d’un rapport à Google. Cinq mois plus tard, les chercheurs ont de nouveau regardé ce qui se passait et se sont aperçus que le bug n’avait toujours pas été corrigé. Le 13 août, l’information sur le bug a été dévoilée publiquement, incitant Google a publié enfin un patch.

Au fait, Google possède une équipe interne de chercheurs qui consacre son temps et ses efforts à traquer les bugs de partout, et pas seulement sur leurs propres softwares. Le Project Zero de Google accorde en général 90 jours à l’équipe avant de rendre public un bug. On peut alors se demander si Google est capable de publier lui-même un patch pendant cette période.
Or, avec Google Admin, quelque chose n’a pas du tout fonctionné. D’abord, il y avait en effet quelque chose qui ne fonctionnait pas. Ensuite, nous savons tous que les patchs ne permettent pas toujours de résoudre le problème sur tous les appareils Android vulnérables. Des mises à jour de sécurité tous les mois ? Et qu’en est-il d’un patch sur lequel on travaille pendant une demi-année ? Oui, oui, tout va bien.

security-week-34-kitten

Vulnérabilité ouverte dans les systèmes SCADA de Schneider Electric

L’article du Threatpost. L’alerte de ICS-CERT.

Bienvenue dans le monde merveilleux d’une infrastructure essentielle ! Veuillez vous assoir, mettez-vous à l’aise, n’appuyez pas sur ce bouton rouge effrayant et ne touchez pas à ces câbles qui sortent bizarrement de cette chose. Oui, il faut qu’ils sortent. C’est normal. Ca fait des années qu’ils sont comme ça. Si vous les touchez, nous sommes tous perdus !
Les systèmes SCADA font partie d’infrastructures essentielles. Ces dernières sont notamment responsables de la gestion d’éléments importants, comme les chaudières de vos immeubles ou même des centrales nucléaires. De tels systèmes ne sont pas supposés être éteints ou réinitialisés. Alors, ne jouez pas avec les paramètres et ne touchez à rien !


Si vous avez des questions, n’essayez rien vous-même, s’il vous plaît. Lisez plutôt notre article à ce sujet. Pendant ce temps, reconnaissons quand même que, malgré l’importance cruciale de ces systèmes, ils sont souvent déployés sur des PC normaux, avec de vieilles versions de Windows. Contrairement aux entreprises classiques, qui mettent à jour ou remplacent leurs hardwares et softwares environ une fois tous les cinq ans, certaines installations ou turbines industrielles, qui permettent de conserver à l’abri des substances chimiques mortelles, peuvent fonctionner 24h/24 et 7j/7 sur un même hardware depuis plusieurs décennies.

Qu’est-ce qui a été découvert ?

Eh bien, un grand nombre de bugs a été découvert de l’un de ces systèmes : Modicon M340 PLC Station P34 CPU de Schneider Electric. En résumé, cet ensemble de vulnérabilités permettrait à un intrus de s’emparer de presque tout ce que le système contrôle. Une faille majeure a été découverte ici (au fait, nous en trouvons souvent dans des routers et autres objets connectés) dans les justificatifs d’identité codés matériellement.

Ce qui a été codé matériellement dans les systèmes SCADA reste secret (pour des raisons évidentes de sécurité). Toutefois, nous émettons l’hypothèse selon laquelle il s’agissait d’identifiants de connexion par défaut, qu’un fournisseur avait transmis en vue de simplifier le service, ou d’un test de mot de passe en dehors du code qu’un fournisseur aurait oublié d’effectuer. Ou tout ce que vous voulez.

Comment cela a été corrigé ?

Le bug n’a pas été corrigé. Deux bonnes semaines se sont écoulées depuis que le chercheur Aditya Sood a présenté cette vulnérabilité à la conférence DEF CON, et aucun patch n’est encore sorti. C’est plutôt compréhensible. Un fournisseur est confronté à une tâche très difficile. En effet, un travail éprouvant, tel celui de corriger les softwares vulnérables, le devient encore plus car, au moment d’une baisse de productivité, un client pourrait causer des pertes considérables. Parfois, une baisse de productivité est tout simplement impossible.
Alors, combien de temps faudra-t-il pour qu’un patch soit publié ? Pendant combien de temps les opérations devront-elles être suspendues ? Est-ce que tout rentrera dans l’ordre, ensuite ? Toutes les caractéristiques des appareils auront-elles été prises en compte ? Dans l’ensemble, la situation est très embêtante, mais elle sert aussi de piètre excuse pour ne pas corriger le bug. A de nombreuses reprises, il a été prouvé que ne pas connecter à Internet des infrastructures essentielles, ou de les protéger simplement au moyen d’un pare-feu, ne constituaient pas de bonnes solutions.

security-week-34-keynote

Développeurs pendant la présentation

 

Un bug non corrigé sur Mac OS X

L’article du Threatpost.
Une fois de plus, nous abordons le thème de la responsabilité en cas de révélation. Pour ce qui est du bug de Google, les chercheurs ont eu cinq mois devant eux avant que l’information ne devienne publique, alors même que Google s’impose lui-même un délai de 90 jours. Combien de temps devrions-nous attendre ? Combien de temps devrions-nous laisser aux développeurs pour qu’ils comblent une telle faille ?
Si nous leur accordions une période suffisamment longue, les développeurs ne se ramolliraient-ils pas, en remettant toujours à plus tard le patch, car ils auraient tout le temps nécessaire ? Quoi qu’il en soit, il n’y a pas de délai de rigueur à respecter, même si tout le monde s’accordera sur le fait que révéler un bug au grand public, avant d’en avoir informé les développeurs, est une très mauvaise chose.

Qu’est-ce qui a été découvert ?

Voici un bon exemple de cas où les développeurs ont été avertis, ou non, ou peut-être, ou l’ont été avec un délai trop court. Dans tous les cas, ils n’ont pas eu suffisamment de temps pour réagir. Luca Todesco, un jeune chercheur de 18 ans, a révélé en détail une vulnérabilité grave qu’il a trouvée sur Mac OS X Yosemite et Mavericks (10.9.5 – 10.10.5), laquelle permet à un attaquant d’obtenir des privilèges root sur la machine exposée.

Le bug ne peut pas être exploité à distance : le pirate devrait pousser l’utilisateur à télécharger et à exécuter un exploit (ce qu’il arriverait certainement à faire). Il y a aussi une preuve de concept disponible, il suffit de la récupérer et de l’utiliser.

Comment cela a été corrigé ?

Eh bien, cela n’a pas encore été corrigé. Selon le chercheur, il n’a reçu aucun retour de la part d’Apple, malgré ses nombreuses tentatives pour en obtenir. Le fait d’avoir révélé publiquement une telle vulnérabilité ne l’inquiète pas : d’après lui, il a simplement exploré un nouveau jailbreak, c’est tout. Rien de bien grave !

https://twitter.com/qwertyoruiop/status/632966294804017153

C’est une mauvaise comparaison car un jailbreak est un processus que les utilisateurs, qui savent précisément ce qu’ils font, décident volontairement d’effectuer. On ne peut pas obliger un utilisateur d’iPhone à effectuer un jailbreak sur son appareil, à moins que l’utilisateur ne le veuille. Pour le bug découvert par Luca Todesco, ce n’est pas toujours le cas. Rien d’étonnant à ce qu’il ait été vivement critiqué par ses pairs :

Il n’est pas très clair si le nouveau bug découvert affecte le nouveau Mac OS X El Capitan. J’attends impatiemment la publication du patch.

Quelles sont les autres nouvelles ?

Microsoft a corrigé un bug sur Internet Explorer (au moins, quelqu’un a corrigé quelque chose) en publiant un patch d’urgence, le deuxième ce mois-ci.
Les données privées du site Web Ashley Madison pour les personnes mariées, qui avaient été volées par des hackers, ont maintenant été publiées en ligne, tel que l’avait annoncé le groupe qui a revendiqué ce piratage.

https://twitter.com/kaspersky/status/634349398198218752

Kaspersky Lab a découvert Blue Termite, une campagne de cyberintelligence qui se réclame déjà d’un grand nombre de victimes au Japon. Il n’est pas passé inaperçu que les cyberespions, actifs depuis plus de deux ans, ont soudainement intensifié leurs activités cet été, dès qu’ils ont pu mettre la main sur un exploit de Flash, lequel avait été divulgué dans les données volées par le groupe The Hacking Team.

Plus ancien

infosec-digest-32-book

« Justice »

Plutôt dangereux, qui affecte les fichiers .COM avec les fonctions DOS 43h, 4Bh, 3Dh, 56h. Le malware est rédigé à la fin des fichiers et altère 5 bytes au début (NOP; NOP; JMP Loc_Virus). Le processus pour compromettre COMMAND.COM utilise la même méthode que le virus Lehigh. Il dérobe régulièrement des données enregistrées sur le lecteur et les copie à un autre endroit. Il contient le texte :  » AND JUSTICE FOR ALL « . Détournements int 13h et int 21h.

Citation tirée de l’ouvrage « Computer viruses in MS-DOS », par Eugène Kaspersky, 1992. Page 72
Clause de non-responsabilité : cet article ne reflète que l’opinion personnelle de l’auteur. Elle peut correspondre à la position de Kaspersky Lab, mais pas nécessairement.

Conseils
Abonnez-vous et recevez tous nos titres à la une par e-mail
  • For all other countries