Shellshock : introduction
Au vu des analyses que l’on peut lire dans la presse, cette faille dépasserait en ampleur la précédente star des medias (Heartbleed dans OpenSSL), et menacerait internet de congestion en cas de ver qui comme Slammer avait ralenti internet en 2003 !
Ce premier article fait partie d’une paire consacrée au sujet shellshock, et passe en revue l’essentiel à savoir sur le sujet.
Un second article développera le fait que la faille concerne aussi les systèmes industriels et embarqués, et qu’elle sera beaucoup plus difficile à corriger dans ces environnements que sur les serveurs web.
Shellshock ?
Shellshock est un jeu de mots intraduisible en français : shell veut à la fois dire coquillage (d’où le logo du pétrolier Shell), obus (qui explose) et interface de ligne de commande et de scripts sur les unix (ouvrir un « shell »). Littéralement, on pourrait donc traduire par « déflagration d’obus » (et surtout l’impact sur les gens à proximité qui sont « sonnés »), ce qui est assez adapté vu le bruit médiatique. Ou, plus proche de la description du problème : le choc d’une grosse faille dans l’un des shell (unix) les plus populaires : bash. Pour découvrir l’histoire du shell bash, remplaçant avantageusement sh, tcsh et autres csh, voir cet article sur wikipedia.
Bash est pré-installé sur la plupart des distributions linux et sur MacOS X, et on peut en général l’installer sur tous les systèmes de type unix, ce qui fait travailler ces jours-ci beaucoup d’ingénieurs systèmes, car même sur les systèmes HP-UX et IBM AIX, par défaut dépourvus de bash, un sysadmin a pu vouloir l’installer pour raison de préférence personnelle.
Les mises à jours sont en train de sortir pour les distributions linux, une première rustine est sortie le jour de communication de la faille (25 sept), ce qui est logique, mais la correction totale avec un bash mis à jour prend un peu plus de temps.
Quelle est la faille et comment l’exploiter ?
En gros, un positionnement futé des variables d’environnement suivi du lancement d’une commande « shell » causerait l’interprétation par le shell de code inséré dans ces variables (pour un exemple de positionnement de code dans une variable et d’exploitation, ainsi que l’exploitation actuelle sur serveurs web, voir cet article de 01net), ce qui revient à faire exécuter du code arbitraire. Il faut pour cela avoir une interface qui le permette (positionner des variables et provoquer l’exécution d’une commande shell), et par exemple le serveur web Apache peut jouer le rôle d’interface (avec appels shell via CGI, voir l’article wikipedia d’où est tiré le schéma ci-dessous), ainsi que de nombreux systèmes de bases de données qui peuvent également effectuer les deux actions.
Cela permet donc l’exécution de code arbitraire sur de très nombreux systèmes connectés à internet. Une telle attaque conduit en général, une fois réussie, à ouvrir un « remote shell », c’est à dire une vraie connexion distante permanente à un shell, qui permet ensuite de tout faire : taper des commandes, télécharger d’autres codes, et essayer d’exploiter d’autres attaques pour prendre le contrôle du serveur ou de serveurs voisins. L’attaque se poursuit soit en « jouant » sur le réseau interne auquel est connecté l’ordinateur, permettant d’en attaquer d’autres via la même faille ou d’autres failles, soit de constituer un botnet (objet de cet article de 01), en pilotant à distance des milliers d’ordinateurs infectés pour mener des attaques massives. C’est ce qui est en train de se passer maintenant, car les exploits étant disponibles sur internet, tout « bon » gestionnaire de botnet se doit de l’exploiter pour développer son réseau.
Quelles sont les cibles potentielles ?
A fortiori tous les systèmes sous linux et Mac OS X sont concernés. Mais aussi… un certain nombre d’équipements de type « appliance », qui fonctionnent sous linux ou une version d’unix, par exemple des produits de Tenable, Cisco, Juniper… Parce que linux est libre et adaptable aux besoins et capacité des systèmes, il est employé par la plupart des constructeurs. Le nombre de systèmes impactés est donc considérable.
Une conséquence est bien entendu que le temps de mise à disposition des correctifs de sécurité (patch) va s’en ressentir, vu le nombre de correctifs à générer.
Les cibles sont tous les systèmes directement connectés à internet, mais pas seulement. Des logiciels malveillant exploitant la faille peuvent être diffusés : il est en effet relativement simple d’écrire un petit binaire pouvant s’envoyer comme pièce jointe, pour détecter et infecter des systèmes à l’intérieur des entreprises. Outre mettre à jour les serveurs (patchs de sécurité), il va falloir aussi mettre à jour les signatures de détection d’intrusion. Celles-ci sont en train d’être mises à disposition par les éditeurs d’outils de détection d’intrusion (Tenable, sourcefire) et de pare-feux applicatifs (WAF pour HTTP).
Il est donc indispensable de tester réellement ses systèmes pour répertorier ceux qui sont vulnérables, en utilisant l’un des outils de tests de vulnérabilité « shellshock » mis à disposition : on en trouvera une sélection ainsi que des éléments sur les signatures snort sur ce forum.
« L’internet à genoux » ou « ne paniquons pas » ?
Le niveau de danger que représente shellshock est analysé différemment, avec deux extrêmes que pourraient constituer la version 01net avec son risque d’internet à genoux, et ce post sur le blog bitdefender.
La vérité est sans doute entre les deux, car un ver qui se diffuserait comme slammer est peu probable dans le cas shellshock, au moins sur internet, car de nos jours la plupart des exploitants de systèmes connectés sur internet reçoivent les informations sur les failles de sécurité et appliquent rapidement les correctifs. Restent les systèmes industriels, dont certains sont connectés sur internet comme différentes études l’ont démontré, mais on y reviendra dans le prochain article.
Par contre, dire comme dans le post de bitdefender qu’il ne faut s’inquiéter « que si le système est vulnérable » (comprendre au delà de la faille shellshock), est très optimiste, l’auteur semblant considérer que l’exécution de commandes bash sans droits particuliers n’amène pas grande conséquence, sauf si ont parvient à faire une escalade de privilège (c’est son analyse). C’est oublier la possibilité d’ouvrir une connexion externe via ssh ou simplement nc (netcat), pour permettre un accès de l’extérieur à ce système, et l’exploiter soit pour faire des attaques sur l’intranet, soit pour l’intégrer à un botnet en téléchargeant et en exécutant d’autres programmes, toujours sans privilèges, certes… La machine présentant la faille shellshock n’est dans ces cas pas corrompue, mais elle sert à attaquer son environnement. D’accord, il y a beaucoup d’autres attaques / exploit permettant de faire cela (un simple exécutable – pas foncièrement malveillant – envoyé par email…) mais pas aussi automatiquement sur un grand nombre de cibles.
Les box internet
L’éditeur de ce blog (qui a eu la gentillesse de relire l’article) s’est spontanément posé la question de la vulnérabilité des box internets, construites pour la plupart sinon toutes sur base linux. Cela représente de fait la plus forte base installée de systèmes linux directement connectés à internet (par définition) et disposant pour la majorité d’entre elles de serveurs web, qui permettent au client d’en consulter l’état et de faire des modifications de configuration.
En fait, le risque est très faible : les box sont toutes configurées avec un pare-feu interdisant par défaut toutes les connexions entrantes, elles font l’objet d’une forte attention sur le sujet de la sécurité, et surtout elles peuvent être facilement mises à jour à distance par les opérateurs. Cela ne sera donc pas un relais de ce type d’attaque.
A suivre…
Pour ce qui concerne les SI standards, il faudra suivre l’actualité mais a priori l’impact est surtout relatif à la constitution de botnets, les systèmes dans les serveurs et les appliances réseaux font l’objet d’une forte attention des DSI et la faille, si elle n’est pas déjà patchée, le sera sous peu.
Pour les SI industriels et dans les infrastructures critiques, c’est une vulnérabilité de plus qui se rajoute à un liste déjà bien longue. Nous en étudierons l’impact dans un prochain article.