SHELL SHOCK : LES EXPLOITS ONT DÉMARRÉ ET LE MONDE TREMBLE…

[Jacques Cheminat – Silicon.fr – 26/09/2014]

5 questions sur la faille Shell Shock visant Bash

Le monde du web tremble avec l’annonce d’une faille baptisée Shell Shock qui touche l’interpréteur de commande Bash présent dans plusieurs systèmes. Plusieurs questions se posent sur cette menace, sa définition, son exploitation, son impact, etc.

A en croire les spécialistes de la sécurité, la faille Shell Shock est pire que la vulnérabilité Heartbleed qui avait touché la librairie de chiffrement Open Source, OpenSSL. En visant l’interpréteur de commande Bash dans les systèmes Linux ou certains OS, elle ouvre la boîte de Pandore des risques et des menaces. Nous avons posé 5 questions à des spécialistes de la sécurité informatique pour en savoir plus sur cette vulnérabilité.

1-Comment a été découvert Shell Shock ?

La faille a été découverte par un français, Stéphane Chazelas, qui travaille actuellement en Angleterre pour le fournisseur de CDN Akamai. Spécialiste du monde Linux/Unix et des télécoms comme l’indique sa page personnelle, il a trouvé un bug dans Bash (Bourne-Again shell) qui est un interpréteur de lignes de commande via des scripts. Il existe depuis plus d’une vingtaine d’années années (1993) et est devenu l’interprète standard de plusieurs systèmes Unix et distributions Linux, mais aussi des systèmes d’exploitation comme Mac OS X, Android et de manière plus limitée Windows avec le projet Cygwin.

Dans un entretien accordé à FairFax Media, Stéphane Chazelas précise que la découverte s’est déroulée il y a deux semaines. Il a aussitôt alerté Chet Ramey, en charge du support du code source Bash. En parallèle, il a aussi averti des fournisseurs d’infrastructures web et des éditeurs de distribution Linux comme Debian, Red Hat,Ubuntu, SuSE et Mandriva. Le problème est que « cette découverte a été débattue rapidement sur des forums réduisant ainsi le temps pour trouver une réponse de la part de l’ensemble des acteurs », explique Thierry Karsenty, directeur technique Europe chez CheckPoint.

Concrètement, la faille Shell Shock permet de modifier des variables d’environnement et d’exécuter du code à distance par le biais de scripts Apache CGI, des options DHCP et OpenSSH en s’appuyant sur Bash. Shell Shock est souvent comparée à Heartbleed. Loïc Guezo, directeur Europe du Sud chez Trend Micro, écarte néanmoins cette analogie. « Shell Shock n’est pas une faille traditionnelle. Dans le cas de Heartbleed, la vulnérabilité concernait la collecte de données, dans le cas de Bash, il s’agit d’une prise de contrôle d’un système ou d’un équipement. »

 

FAILLE HEARTBLEED : LA CHECK-LIST POUR S’EN SORTIR

LA PREMIÈRE LECON A RETENIR DE HEARTBLEED C’EST LA FAIBLESSE DU OPEN SOURCE  : Si la saga Heartbleed est loin de se refermer, ses premiers développements sont déjà riches d’enseignements. Sur certaines faiblesses du développement open source d’abord. « On prend ainsi conscience qu’une large part du chiffrement dans le monde dépend de quelques développeurs à temps partiel, remarque Arnaud Bidou. Le code incriminé a été validé et enregistré le 31 décembre 2011… à 23 heures ! Et les équipes de OpenSSL se sont affranchies des vérifications de conditions d’allocation mémoire (la source du bogue, NDLR). La fondation OpenSSL a expliqué avoir besoin de 6 personnes à plein temps pour travailler plus sereinement. Aujourd’hui, leur équipe est bien plus restreinte. Il serait peut-être temps de se pencher sur le financement d’une des principales infrastructures de sécurité du Web ».

[Reynald Fléchaux – SILICON – 18/04/2014]

Résolue la faille Heartbleed ? Loin de là. La librairie OpenSSL à l’origine de la vulnérabilité est embarquée dans de multiples équipements logiciels et matériels employés par quasiment toutes les DSI. Equipements qui devront être mis à jour. Et la seule application des patches est insuffisante.

Depuis le 7 avril, un nom et un logo, jusqu’alors inconnus, ont fait le tour du Web : Heartbleed, un cœur qui saigne. L’importance de cette faille de sécurité affectant la librairie de chiffrement SSL/TLS OpenSSL explique cet embrasement sur le sujet. Si les acteurs du Web ont très rapidement mis à jour leur librairie (vers la version 1.0.1g expurgée de Heartbleed), le problème est loin – très loin même – d’avoir été réglé. Et il ne se limite pas aux seuls acteurs du Web : toutes les DSI sont, de près ou de loin, concernées par Heartbleed en raison de l’emploi très courant de la librairie OpenSSL dans des logiciels et matériels du marché.

En 5 points, Silicon.fr vous livre une première check-list pour évaluer les risques et prendre les premières contre-mesures.

Un outil de test gratuit pour mesurer la vulnérabilité de vos serveurs et domaines est proposé par Qualys –  disponible sur : https://www.ssllabs.com/ssltest/index.html

1) Mesurer les risques

C’est évidemment la première question qui se pose aux DSI : quelles sont les informations que Heartbleed a pu permettre de dérober ? La réponse est simple : on n’en sait rien. Et c’est bien tout le problème. « A ce jour, on n’a aucune idée des dommages réels que va causer Heartbleed. Il est impossible de savoir quelles sont les données qui ont été exposées, surtout à posteriori, et qui les a récupérées. D’où les questions qui se posent sur son éventuelle utilisation par la NSA», remarque Renaud Bidou, le directeur technique de l’éditeur DenyAll. Concrètement, Heartbleed est un bogue (un classique problème d’allocation de mémoire) dans l’implémentation d’un protocole appelé Heartbeat, ajouté à OpenSSL en février 2012 afin d’améliorer les performances. La faille permet de récupérer 64 000 octets de mémoire. « Et cela concerne toutes les implémentations des versions infectées de OpenSSL : serveurs Web, VPN, reverse proxy… Dans ces 64 000 octets peuvent figurer des login et mots de passe mais aussi la clef privée du serveur, présente notamment lors d’un redémarrage de la machine », ajoute Renaud Bidou.

Bref, beaucoup d’informations extrêmement intéressantes pour des cybercriminels. Les couples login/mots de passe leur permettent d’effectuer des opérations illégitimes. La récupération de la clef privée ouvre encore davantage le champ des possibles. « C’est extrêmement sérieux : car, une fois en possession de ce sésame, un assaillant peut se faire passer pour le serveur légitime, via une attaque de type Man-in-the-middle », note Arnaud Soullié, auditeur sénior chez Solucom. « Nous sommes dans une phase de gestion de crise, après ce qu’il faut bien qualifier de dysfonctionnement majeur », résume Marc Cierpisz, manager du centre d’excellence Team Risk & Security de Devoteam. Gourou de la cybersécurité, Bruce Schneier avait d’ailleurs réagi en assurant que, sur une échelle de 1 à 10, Heartbleed valait un 11.