Rappelez-vous Heartbleed ? Si l’on en croit le battage médiatique d’aujourd’hui, Shellshock est dans la même ligue et avec un nom tout aussi génial bien que dépourvu d’un logo cool (quelqu’un dans le département marketing de ces vulves doit s’y mettre). Mais sérieusement, il a le potentiel d’être un biggie et comme je l’ai fait avec Heartbleed, je voulais mettre en place quelque chose de définitif à la fois pour moi de s’attaquer à la situation et pour les autres de disséquer le battage médiatique du véritable risque sous-jacent.
Pour planter le décor, laissez-moi partager un contenu de l’article de blog de Robert Graham qui a fait une excellente analyse sur ce sujet. Imaginez une requête HTTP comme celle-ci :
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Qui, lorsqu’elle est émise contre une série d’adresses IP vulnérables, donne le résultat suivant :
Pour faire court, Robert vient d’orchestrer un tas de machines externes pour le pinger simplement en émettant une requête soigneusement conçue sur le web. Ce qui est vraiment inquiétant, c’est qu’il a effectivement amené ces machines à émettre une commande arbitraire (bien qu’il s’agisse d’un ping plutôt bénin) et cela ouvre tout un monde de possibilités très sérieuses. Laissez-moi vous expliquer.
Qu’est-ce que Bash et pourquoi en avons-nous besoin ?
Sautez ceci si c’est une vieille nouvelle, mais le contexte est important pour ceux qui ne sont pas familiers avec Bash, alors établissons une compréhension de base. Bash est un shell *nix ou, en d’autres termes, un interpréteur qui vous permet d’orchestrer des commandes sur des systèmes Unix et Linux, généralement en vous connectant via SSH ou Telnet. Il peut également fonctionner comme un analyseur syntaxique pour les scripts CGI sur un serveur web, comme ceux que l’on voit généralement fonctionner sur Apache. Il existe depuis la fin des années 80, où il a évolué à partir d’implémentations antérieures de l’interpréteur de commandes (le nom est dérivé de l’interpréteur de commandes Bourne) et il est extrêmement populaire. Il existe d’autres interpréteurs de commandes pour les variantes d’Unix, mais Bash est l’interpréteur de commandes par défaut pour Linux et Mac OS X, qui sont évidemment des systèmes d’exploitation extrêmement répandus. C’est un facteur majeur qui explique pourquoi ce risque est si important – l’omniprésence de Bash – et il est décrit comme « l’un des utilitaires les plus installés sur n’importe quel système Linux ».
Vous pouvez avoir une idée de l’empreinte de Bash lorsque vous regardez les dernières statistiques de Netcraft sur les serveurs web :
Quand la moitié du net utilise Apache (que l’on trouve généralement sur Linux), cela représente une taille significative d’un très, très grand gâteau. Le même article de Netcraft rapporte que nous venons de franchir la barre du milliard de sites Web et, même si un grand nombre d’entre eux partagent les mêmes hôtes, cela représente tout de même un grand nombre d’installations Bash. Oh – ce ne sont que les serveurs web aussi, n’oubliez pas qu’il y a un tas d’autres serveurs fonctionnant sous Linux et nous reviendrons sur d’autres appareils avec Bash un peu plus tard aussi.
Bash peut être utilisé pour toute une série de fonctions administratives typiques, tout depuis la configuration de sites web jusqu’au contrôle de logiciels intégrés sur un appareil comme une webcam. Naturellement, ce n’est pas une fonctionnalité destinée à être ouverte au monde et en théorie, nous parlons d’utilisateurs authentifiés exécutant des commandes qu’ils ont été autorisés à exécuter. En théorie.
Quel est le bug ?
Laissez-moi commencer avec le CVE de la base de données de vulnérabilité du NIST car il donne une bonne idée de la gravité (surligné par moi):
GNU Bash à travers 4.3 traite les chaînes de traîne après les définitions de fonction dans les valeurs des variables d’environnement, ce qui permet aux attaquants distants d’exécuter du code arbitraire via un environnement trafiqué, comme le démontrent les vecteurs impliquant la fonction ForceCommand dans OpenSSH sshd, les modules mod_cgi et mod_cgid dans le serveur HTTP Apache, les scripts exécutés par des clients DHCP non spécifiés, et d’autres situations dans lesquelles la définition de l’environnement se produit à travers une frontière de privilèges de l’exécution de Bash.
Ils poursuivent en lui attribuant une note de « 10 sur 10 » pour la gravité ou en d’autres termes, aussi mauvais que possible. Ceci est aggravé par le fait qu’il est facile d’exécuter l’attaque (la complexité d’accès est faible) et peut-être le plus significatif, il n’y a pas d’authentification requise lors de l’exploitation de Bash via des scripts CGI. Le résumé ci-dessus est un peu alambiqué, alors ramenons-le à la mécanique du bogue.
Le risque est centré sur la possibilité de définir arbitrairement des variables d’environnement dans un shell Bash qui spécifient une définition de fonction. Le problème commence lorsque Bash continue à traiter les commandes du shell après la définition de la fonction, ce qui entraîne ce que nous classerions comme une « attaque par injection de code ». Reprenons l’exemple de Robert et prenons juste cette ligne :
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
La définition de la fonction est () { : ; } ; et la commande shell est l’instruction ping et les paramètres suivants. Lorsque cela est traité dans le contexte d’un shell Bash, la commande arbitraire est exécutée. Dans un contexte web, cela signifierait via un mécanisme tel qu’un script CGI et pas nécessairement en tant qu’en-tête de requête. Cela vaut la peine de lire l’avis de seclists.org où ils entrent dans plus de détails, y compris en indiquant que le chemin et la chaîne de requête pourraient être des vecteurs potentiels pour l’attaque.
Bien sûr, un moyen d’atténuer ce vecteur d’attaque particulier est simplement de désactiver toute fonctionnalité CGI qui fait des appels à un shell et en effet, certains le recommandent. Dans de nombreux cas cependant, cela va être un changement sérieusement cassant et, au minimum, un qui va nécessiter des tests approfondis pour s’assurer qu’il ne provoque pas de problèmes immédiats dans le site Web, ce qui, dans de nombreux cas, sera le cas.
La preuve HTTP ci-dessus est une preuve simple mais efficace, bien que juste une mise en œuvre sur un protocole commun. Une fois que vous commencez à jeter dans Telnet et SSH et apparemment même DHCP, la portée augmente de façon spectaculaire, donc en aucun cas nous parlons seulement de l’exploitation des serveurs d’applications web ici. (Apparemment, le risque n’est présent que dans SSH post-auth, mais à un stade aussi précoce de la divulgation publique, nous verrons inévitablement d’autres vecteurs d’attaque émerger encore.)
Ce qu’il faut aussi retenir, c’est que la portée des dommages potentiels s’étend bien au-delà du ping d’une adresse arbitraire comme dans l’exemple de Robert, c’est simplement une petite preuve soignée qu’il a pu orchestrer une machine pour émettre une commande shell. La question est la suivante : Quels dommages un attaquant pourrait-il faire lorsqu’il peut exécuter une commande shell de son choix sur n’importe quelle machine vulnérable ?
Quelles sont les ramifications potentielles ?
Le potentiel est énorme – « obtenir un shell » sur une boîte a toujours été une victoire majeure pour un attaquant en raison du contrôle qu’il lui offre sur l’environnement cible. Accès aux données internes, reconfiguration des environnements, publication de leur propre code malveillant, etc. C’est presque sans limite et c’est aussi facilement automatisable. Il existe déjà de très nombreux exemples d’exploits qui pourraient facilement être lancés contre un grand nombre de machines.
Malheureusement, lorsqu’il s’agit de l’exécution de code arbitraire dans un shell sur jusqu’à la moitié des sites Web sur Internet, le potentiel est assez large. L’un des plus évidents (et particulièrement méchant) est le dumping de fichiers internes pour une récupération publique. Les fichiers de mots de passe et les fichiers de configuration avec les informations d’identification sont les plus évidents, mais ils pourraient s’étendre à tout autre fichier sur le système.
De même, la même approche pourrait être appliquée pour écrire des fichiers sur le système. Il s’agit potentiellement du vecteur de défiguration de sites Web le plus facile que nous ayons jamais vu, sans parler d’un moyen très facile de distribuer des logiciels malveillants
Or, que dire de ceci : un mot que je vois souvent est « ver » :
Lorsque nous parlons de ver dans un contexte d’informatique malveillante, nous parlons d’une attaque auto-réplicative où un acteur malveillant crée un code capable de se propager sur des cibles. Par exemple, nous en avons vu une mise en œuvre très efficace avec le ver XSS MySpace de Samy, où un JavaScript soigneusement conçu a réussi à « infecter » les pages d’un million de victimes en moins d’un jour.
Le souci avec Shellshock est qu’une attaque de cette nature pourrait se répliquer à un rythme alarmant, en particulier au début, alors que la majorité des machines restent à risque. En théorie, cela pourrait prendre la forme d’une machine infectée qui rechercherait d’autres cibles et leur propagerait l’attaque. Cela ne se limiterait en aucun cas aux machines exposées au public ; si cela passe derrière le pare-feu de l’entreprise, les possibilités sont illimitées.
Des personnes travaillent actuellement à l’exploitation de ce problème. C’est ce qui rend ces premiers jours si intéressants alors que la course aux armements entre ceux qui se bousculent pour patcher et ceux qui se bousculent pour attaquer se réchauffe.
Quelles versions de Bash sont affectées ?
Les gros titres indiquent tout jusqu’à 4.3 ou en d’autres termes, environ 25 ans de versions de Bash. Étant donné que tout le monde continue à comparer cela à Heartbleed, considérez que les versions impactées d’OpenSSL s’étendent sur seulement deux ans, ce qui est une goutte d’eau dans l’océan comparé à Shellshock. Oui, les gens mettent à jour leurs versions, mais non, ils ne le font pas systématiquement et quelle que soit la façon dont vous le coupez, l’ampleur des machines à risque va être significativement plus élevée avec Shellshock que ce qu’elle était avec Heartbleed.
Mais le risque pourrait bien s’étendre au-delà de 4.3 également. Nous voyons déjà des rapports indiquant que les correctifs ne sont pas entièrement efficaces et, étant donné la vitesse à laquelle ils sont déployés, ce n’est pas si surprenant. C’est le genre de chose que ceux qui sont touchés par elle veulent garder un œil très attentif, pas seulement « patcher et oublier ».
Quand avons-nous appris la première fois et combien de temps avons-nous été à risque ?
La première mention que j’ai trouvée sur les ondes publiques était ce très bref résumé sur seclists.org qui fonctionne à environ 14h00 GMT mercredi (environ minuit ce matin pour ceux d’entre nous à l’extrémité est de l’Australie). Les détails sont apparus dans l’avis que j’ai mentionné plus tôt, une heure plus tard, donc vers le milieu de l’après-midi de mercredi en Europe ou le matin aux États-Unis. Il s’agit encore d’une nouvelle très récente, avec toutes les spéculations habituelles de la presse et les prédictions de Chicken Little ; il est trop tôt pour observer une exploitation généralisée dans la nature, mais cela pourrait aussi arriver très bientôt si le risque est à la hauteur de son potentiel.
Retournez au-delà de ce qui a été divulgué publiquement et le bogue a apparemment été découvert la semaine dernière par Stéphane Chazelas, un » spécialiste Unix/Linux, réseau et télécom » au Royaume-Uni. Ceci étant dit, dans le post d’Akamai sur le bogue, ils parlent de sa présence depuis « une longue période de temps » et, bien sûr, les versions vulnérables de Bash remontent à deux décennies et demie maintenant. La question, comme pour Heartbleed, sera de savoir si les acteurs malveillants en étaient conscients avant maintenant et même s’ils l’exploitaient activement.
Nos « choses » sont-elles affectées ?
C’est là que cela devient intéressant – nous avons beaucoup de « choses » exécutant potentiellement Bash. Bien sûr, lorsque j’utilise ce terme, je fais référence à l' »Internet des objets » (IoT) qui est la prévalence croissante de la claque d’une adresse IP et d’un adaptateur sans fil dans tout, de nos couverts à nos serrures de porte en passant par nos globes lumineux.
De nombreux appareils IoT exécutent des distributions Linux embarquées avec Bash. Ces mêmes appareils ont déjà montré de sérieuses vulnérabilités de sécurité dans d’autres domaines, par exemple les globes d’éclairage LIFX il y a quelques mois ont été trouvés pour fuir les informations d’identification wifi. Bien qu’il ne s’agisse pas d’une vulnérabilité Bash comme Shellshock, cela nous montre qu’en connectant nos objets, nous entrons dans un tout nouveau monde de vulnérabilités dans des endroits qui n’étaient jamais à risque auparavant.
Edit : Quelques personnes ont fait référence à la prévalence de BusyBox exécutant le shell Ash sur les appareils mobiles. Les appareils exécutant cela ne semblent pas être à risque de Shellshock. La difficulté pour un consommateur est qu’il ne sait pas ce qui est exécuté sur ses appareils, et cela inclut également des « choses » plus traditionnelles comme les routeurs. La longue histoire de ce bug signifie que nous avons plus de deux décennies d’appareils sur le marché qui sont passés par diverses évolutions de différents OS embarqués et nous avons maintenant un paysage très diversifié de machines et de coquilles couvrant une longue période de temps.
Cela entraîne de nombreux nouveaux défis ; par exemple, qui pense activement qu’ils devraient patcher régulièrement leurs ampoules ? Il faut également tenir compte de la longévité des appareils dans lesquels ces logiciels apparaissent et de la question de savoir s’ils sont réellement entretenus activement. Dans un cas comme celui des caméras Trendnet vulnérables d’il y a quelques années, il ne fait aucun doute qu’un grand nombre d’entre elles se trouvent encore sur le Web, car en termes de correctifs, il s’agit plutôt d’une proposition « à régler et à oublier ». En fait, dans ce cas, il existe un compte Twitter tout entier consacré à la diffusion des images qu’il a capturées de propriétaires peu méfiants de versions vulnérables. C’est un gros problème qui n’a pas de solution facile et qui va nous poursuivre pendant très longtemps.
Mais les shells Bash sont également présents dans de nombreux appareils plus courants, par exemple nos routeurs domestiques qui sont généralement tournés vers Internet. Vous vous souvenez de la dernière fois où vous avez patché le firmware de votre routeur ? Ok, si vous lisez ceci, alors peut-être êtes-vous le type de personne technique qui patche réellement son routeur, mais mettez-vous à la place du consommateur moyen et demandez-vous à nouveau cette question. Exactement.
Toutes nos affaires sont sur la pile Microsoft, sommes-nous à risque ?
Réponse courte « non », réponse longue « oui ». Je m’attaquerai d’abord à la plus facile – Bash ne se trouve pas nativement sur Windows et bien qu’il existe des implémentations de Bash pour Windows, ce n’est certainement pas commun et on ne le trouvera pas sur les PC grand public. Il n’est pas non plus clair si des produits comme win-bash sont réellement vulnérables à Shellshock en premier lieu.
La réponse plus longue est que ce n’est pas parce que vous opérez dans un environnement principalement centré sur Microsoft que vous n’avez pas Bash en cours d’exécution sur des machines servant d’autres objectifs discrets dans cet environnement. Lorsque j’ai écrit sur Heartbleed, j’ai fait référence au post de Nick Craver sur le déplacement de Stack Overflow vers SSL et fait référence à ce diagramme de leur infrastructure :
Il y a des composants non-Microsoft assis devant leur pile d’applications Microsoft, des composants que le trafic doit traverser avant d’atteindre les serveurs web. Ce sont également des composants qui peuvent avoir des privilèges élevés derrière le pare-feu – quel est l’impact si Shellshock est exploité sur ceux-ci ? Il pourrait être significatif et c’est le point que je fais ici ; Shellshock a le potentiel d’avoir un impact sur les actifs au-delà des seules implémentations Bash à risque lorsqu’il existe dans un écosystème plus large d’autres machines.
Je suis un administrateur système – que puis-je faire ?
Premièrement, découvrir si vous êtes à risque est trivial car c’est un risque si facilement reproductible. Il y a un test très simple que The Register suggère qui consiste juste à exécuter cette commande dans votre shell :
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Vous êtes « busted » echo’d back out et vous avez réussi à exploiter le bug.
Bien sûr, la priorité ici va être de patcher les systèmes à risque et le patch se résume essentiellement à s’assurer qu’aucun code ne peut être exécuté après la fin d’une fonction Bash. Les distros Linux comme Red Hat publient des conseils sur le patching du risque, alors sautez dessus en priorité.
Nous verrons inévitablement aussi des définitions pour les systèmes de détection d’intrusion et il y aura certainement des modèles communs à rechercher ici. Cela pourrait bien s’avérer une bonne mise en œuvre à court terme pour de nombreuses organisations, en particulier lorsqu’il peut y avoir des exigences de test onéreuses avant de déployer des correctifs sur les systèmes à risque. Qualys’ visent à avoir une définition pour détecter l’attaque assez rapidement et inévitablement d’autres fournisseurs IDS travaillent sur ce sujet autour de l’horloge aussi.
D’autres options plus drastiques comprennent le remplacement de Bash avec une implémentation alternative de shell ou le cordonage des systèmes à risque, les deux pourraient avoir des ramifications de grande envergure et ne sont probablement pas des décisions prises à la légère. Mais ce sera probablement la nature de ce bug pour de nombreuses personnes – des décisions difficiles qui pourraient avoir un impact commercial tangible afin d’éviter des ramifications potentiellement beaucoup plus importantes.
L’autre question qui va maintenant commencer à se poser souvent est de savoir si Shellshock a déjà été exploité dans un environnement. Cela peut être difficile à déterminer s’il n’y a pas de journalisation des vecteurs d’attaque (il n’y en aura souvent pas s’il est transmis par l’en-tête de la demande HTTP ou le corps du POST), mais il est plus probable d’être attrapé qu’avec Heartbleed quand, à défaut de pcaps complets, les charges utiles de battement de cœur n’auraient normalement pas été enregistrées nulle part. Mais tout de même, la réponse la plus courante à la question « avons-nous été attaqués via Shellshock » va être la suivante :
malheureusement, ce n’est pas « Non, nous avons des preuves qu’il n’y a pas eu de compromissions » ; plutôt, « nous n’avons pas de preuves qui couvrent la durée de vie de cette vulnérabilité ». Nous doutons que beaucoup de gens en aient – et cela laisse les propriétaires de systèmes dans la position inconfortable de ne pas savoir quelles compromissions, s’il y en a eu, ont pu se produire.
Laissons les spéculations sur la question de savoir si la NSA était dans le coup…
Je suis un consommateur – que puis-je faire ?
Cela dépend. Shellshock affecte les Macs donc si vous exécutez OS X, à ce stade cela semble être à risque ce qui d’une part est mauvais en raison de la prévalence d’OS X mais d’autre part sera facilement (et espérons-le rapidement) remédié en raison d’un mécanisme de mise à jour assez bien éprouvé (c’est-à-dire que les mises à jour peuvent être poussées à distance vers l’utilisateur).
Si vous êtes sur un Mac, le risque est facilement testé comme décrit dans cette réponse de Stack Exchange :
C’est un test facile, bien que je doute que l’utilisateur moyen de Mac se sente à l’aise pour passer à travers le correctif suggéré qui implique de recompiler Bash.
La plus grande inquiétude concerne les appareils sans chemin de patching facile, par exemple votre routeur. À moins de vérifier sur le site Web du fabricant la mise à jour du micrologiciel, ce sera une noix vraiment difficile à casser. Souvent, les routeurs fournis par les FAI sont verrouillés afin que les consommateurs ne modifient pas au hasard la configuration ou le micrologiciel, et il n’y a pas toujours de chemin de mise à jour à distance qu’ils peuvent déclencher. Si l’on ajoute à cela la multitude d’appareils et d’âges qui existent, la situation pourrait être particulièrement délicate. Bien sûr, ce n’est pas non plus le genre de chose que votre consommateur moyen va être à l’aise de faire lui-même.
En bref, le conseil aux consommateurs est le suivant : surveillez les mises à jour de sécurité, en particulier sur OS X. Gardez également un œil sur les conseils que vous pouvez recevoir de votre FAI ou d’autres fournisseurs d’appareils que vous avez et qui exécutent des logiciels intégrés. Méfiez-vous des courriels vous demandant des informations ou vous enjoignant d’exécuter un logiciel. De tels événements sont souvent suivis d’attaques de phishing qui exploitent les craintes des consommateurs. Les canulars ont actuellement des gens qui mettent leurs iPhones dans le micro-ondes, alors ne pensez pas un seul instant qu’ils ne vont pas exécuter un logiciel aléatoire qui leur est envoyé par e-mail comme un « correctif » pour Shellshock !
Summary
Selon toute vraisemblance, nous n’avons même pas commencé à sonder l’ampleur de cette vulnérabilité. Bien sûr, de nombreuses comparaisons sont faites avec Heartbleed et nous avons appris un certain nombre de choses de cet exercice. L’une d’elles est qu’il a fallu un peu de temps pour que nous réalisions à quel point nous étions dépendants d’OpenSSL. L’autre est qu’il avait une très longue traîne – des mois après qu’il ait frappé, il y avait encore des centaines de milliers d’hôtes connus laissés vulnérables.
Mais dans un sens, la comparaison avec Heartbleed n’est pas juste – ceci est potentiellement bien pire. Heartbleed permettait un accès à distance à une petite quantité de données dans la mémoire des machines affectées. Shellshock permet l’injection de code à distance de commandes arbitraires avant l’authentification, ce qui est potentiellement bien plus grave. À cet égard, je dois être d’accord avec Robert :
Il est encore très, très tôt – seulement une demi-journée depuis qu’il a atteint les ondes au moment de l’écriture – et je soupçonne que jusqu’à présent nous ne faisons qu’effleurer la surface de ce qui reste à venir.
Sécurité.