Shellshock est un bug dans l’interpréteur de commandes de l’interface Bash qui existe depuis 30 ans et a été découvert comme une menace importante en 2014. Aujourd’hui, Shellshock reste toujours une menace pour les entreprises.
La menace est certes moins risquée que l’année de sa découverte. Cependant, dans une année où les priorités de sécurité ont été recalibrées pour suivre le paysage chaotique, c’est un bon moment pour revenir sur cette menace et les facteurs sous-jacents qui maintiennent ces attaques en vie aujourd’hui.
Pourquoi Shellshock est-il pertinent en 2020 ?
Shellshock est une vulnérabilité critique en raison de l’escalade des privilèges accordée aux attaquants, qui leur permet de compromettre les systèmes à volonté. Bien que la vulnérabilité ShellShock, CVE-2014-6271, ait été découverte en 2014, on sait qu’elle existe toujours sur un grand nombre de serveurs dans le monde. La vulnérabilité a été mise à jour (CVE-2014-7169) peu de temps après et a été modifiée jusqu’en 2018.
La principale raison pour laquelle Shellshock est encore utilisé n’est pas un choc. Cette vulnérabilité est une attaque simple et peu coûteuse que les mauvais acteurs peuvent déployer contre une cible inconnue. Des correctifs sont disponibles depuis l’entrée CVE, mais toute organisation ne disposant pas de systèmes de gestion des correctifs appropriés peut encore être vulnérable.
Shellshock était encore proéminent en 2017. Lorsque les attaquants n’ont besoin que de quelques compétences de base en programmation, d’un serveur et d’un accès à un logiciel malveillant, ce n’est pas surprenant. De plus, le coût de la réalisation d’une attaque ne dépasse guère quelques dollars par mois. Le calcul est en faveur des attaquants. Des connaissances minimales, peu d’efforts et un faible coût équivalent à une stratégie de piratage facile.
Malgré toute la couverture médiatique importante sur la cybersécurité et même une alerte du ministère de la Sécurité intérieure, certains systèmes ne sont toujours pas patchés. Dans un exemple, les responsables du Center for Election Systems n’ont pas appliqué un correctif qui a compromis les systèmes électoraux de Géorgie.
Comment Shellshock fonctionne-t-il ?
En termes simples, Shellshock est une vulnérabilité qui permet aux systèmes contenant une version vulnérable de Bash d’être exploités pour exécuter des commandes avec des privilèges plus élevés. Cela permet aux attaquants de prendre potentiellement le contrôle de ce système.
En plongeant plus profondément dans la technique, Shellshock est un bug de sécurité dans le shell Bash (GNU Bash jusqu’à la version 4.3) qui fait que Bash exécute des commandes bash non intentionnelles à partir de variables d’environnement. Les acteurs de la menace qui exploitent cette vulnérabilité peuvent émettre des commandes à distance sur l’hôte cible. Bien que Bash ne soit pas intrinsèquement tourné vers Internet, de nombreux services internes et externes, tels que les serveurs web, utilisent des variables d’environnement pour communiquer avec le système d’exploitation du serveur.
Si ces entrées de données ne sont pas sanitisées – le processus standard de codage qui garantit que le code ne fait pas partie de l’entrée – avant l’exécution, les attaquants peuvent lancer des commandes de requête HTTP exécutées via le shell Bash.
Vulnérabilité en détail
Les serveurs web ne sont pas les seules ressources réseau vulnérables. Les serveurs de messagerie et les serveurs DNS qui utilisent BASH pour communiquer avec le système d’exploitation pourraient également être affectés. Si BASH se trouve normalement sur les systèmes basés sur Unix, les organisations utilisant des systèmes basés sur Windows ne sont pas à l’abri. Celles-ci utilisent probablement des appareils ou du matériel qui sont vulnérables. N’oubliez pas que BASH peut faire partie de routeurs domestiques, de nombreux appareils IoT et de systèmes intégrés.
Shellshock peut même être utilisé pour lancer des attaques par déni de service (DOS).
Voici la ligne de code (une déclaration de fonction Bash suivie d’un point-virgule et la commande ‘sleep’ exécutée à partir de trois chemins possibles pour s’assurer qu’elle soit exécutée) :
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
Cette commande « sleep » force le serveur à attendre vingt secondes avant de répondre. Ce faisant, les ressources de la machine sont essentiellement prises en otage parce que la machine ne peut rien faire d’autre pendant vingt secondes.
Une commande de sommeil peut être inoffensive, mais un attaquant peut être en mesure de la remplacer par un code malveillant. Ensuite, ce code peut menotter le serveur ou la ressource afin qu’il soit incapable de traiter toute demande.
Le risque de permettre à des internautes nuisibles d’exécuter à distance les commandes de leur choix est élevé. En utilisant l’ouverture, les mauvais acteurs peuvent lancer des programmes sur le système, créer des connexions sortantes vers leurs propres systèmes et exécuter des logiciels malveillants.
Peut-être le plus critique, la vulnérabilité peut être exploitée pour voler des données et des informations confidentielles stockées sur le système comme des détails de cartes de crédit, des mots de passe et des informations personnellement identifiables (PII).
Est-ce que Shellshock sévit toujours ?
Shellshock n’est pas aussi répandu qu’il l’était lorsqu’il a été découvert en 2014. Imaginez le défi de devoir patcher tous les serveurs vulnérables de votre entreprise (et, ils étaient nombreux à l’époque).
Cela dit, Shellshock reste un problème.
Par exemple, il existe une cybermenace et une campagne de vulnérabilité en cours appelée « Sea Turtle » qui tire parti des enregistrements DNS pour accéder à des systèmes sensibles. Pour que les attaques réussissent, il faut un certain nombre de vulnérabilités matérielles et logicielles courantes – Shellshock étant l’une d’entre elles.
Bien qu’elles ne soient pas aussi répandues qu’auparavant, chaque entreprise devrait s’assurer que tous les matériels et logiciels sont patchés et à jour.
Comment savoir si vous êtes affecté
Parce que Shellshock a six ans, de nombreux scanners de vulnérabilité sont disponibles. Certains d’entre eux sont gratuits. L’un d’eux, bashcheck, peut être téléchargé en utilisant Github.
Pour les personnes techniques, taper une simple commande dans l’invite Bash fera également l’affaire :
env X= »() { :;} ; echo Bash is Infected » /bin/sh -c « echo completed »
env X= »() { :;} ; echo Bash is Infected » `which bash` -c « echo completed »
env VAR= »() { :;} ; echo Bash is Infected’ bash -c « echo completed »
Si l’invite renvoie un message « Bash is Infected », il est temps de mettre à jour et de corriger. Si votre sortie ne renvoie pas « Bash est infecté », elle répondra avec quelque chose comme:
bash : warning : VAR : ignoring function definition attempt
bash : error importing function definition for `VAR’
Bash Test
Si vous souhaitez tester la vulnérabilité de sites web ou de scripts CGI spécifiques, l’outil suivant peut vous aider : Outil de test de la vulnérabilité ‘ShellShock’ de Bash CVE-2014-6271. Dans l’un des deux champs de saisie, entrez l’URL du site Web ou du script CGI que vous souhaitez tester et cliquez sur les boutons bleus.
Ce que nous pouvons apprendre sur les menaces de cybersécurité
La plus grande leçon pour l’entreprise ici – et elle mérite d’être répétée – est de patcher vos systèmes.
Les équipes qui peuvent réduire les temps de patching sont en meilleure position pour transférer ces ressources vers des préoccupations de sécurité plus pressantes. Bien que certaines entreprises considèrent la gestion des correctifs comme une responsabilité informatique plutôt qu’une responsabilité de sécurité, la gestion des correctifs doit toujours être en tête des préoccupations des départements de sécurité, car elle est essentielle à la posture de sécurité d’une entreprise.
Si vos systèmes sont encore vulnérables aujourd’hui, il y a probablement des problèmes opérationnels sous-jacents qui devraient être abordés. Shellshock est une vulnérabilité très ancienne avec des correctifs disponibles pour presque tous les systèmes. La meilleure façon de se protéger contre ce type de vulnérabilité est de maintenir vos systèmes à jour, en appliquant tous les correctifs publiés pour cet exploit.
Lorsque vous patchez des actifs, généralement un processus simple, vous devriez adopter une approche stratégique.
Les correctifs testés en profondeur sont un excellent moyen de minimiser l’impact sur l’entreprise – comme un serveur critique fonctionnant avec un ancien OS, par exemple. Si un système ne peut pas être patché immédiatement, le risque potentiel de la vulnérabilité doit être mis en balance avec l’impact sur l’entreprise.
Shellshock n’est qu’une vulnérabilité parmi une longue liste de vulnérabilités avec lesquelles l’entreprise doit composer. La gestion du flux apparemment sans fin de vulnérabilités est et sera toujours une stratégie critique qui sous-tend la cybersécurité.
Liste de contrôle pour une organisation sécurisée
Pour une gestion réussie des vulnérabilités, les entreprises doivent avoir la capacité de réussir dans ces trois domaines :
- Identifier rapidement les vulnérabilités potentiellement impactantes : La rapidité est primordiale ici. Avoir tout le monde sur la même page avec un plan solide devrait favoriser des temps de réaction plus rapides.
- Déterminer le niveau de gravité de la vulnérabilité : Connaître la tolérance au risque de votre organisation contribuera grandement à déterminer la gravité d’une vulnérabilité. En fonction de votre infrastructure réseau, certaines vulnérabilités sont plus dommageables que d’autres.
- Avoir un plan d’action qui équilibre l’urgence de la sécurité avec l’impact potentiel sur les environnements de production : Trouver un équilibre entre la sécurité et la production et la productivité est un obstacle constant, mais les organisations qui ont les plans les mieux définis pour la gestion des vulnérabilités trouvent généralement le meilleur équilibre.
Pour le chercheur indépendant en sécurité Rod Soto, la plus grande leçon tirée de Shellshock était qu’Internet est basé sur de nombreuses applications vulnérables et porte toujours le potentiel de compromettre une grande partie de ses segments.
« La façon de gérer ces vulnérabilités potentielles à l’avenir est de garder la communication ouverte et transparente entre les développeurs, les mainteneurs et les professionnels de la sécurité », dit Soto. « Ainsi, si une vulnérabilité aussi étendue et importante est découverte, la coordination entre toutes les parties concernées peut être utilisée pour patcher ou atténuer les systèmes affectés. »
Même dans les cas où votre entreprise réussit à atténuer les risques liés à Shellshock ou à toute autre vulnérabilité, vous ne pouvez pas supposer que votre plan de réponse est parfait. Le plan de réponse doit être un document vivant, qui respire, et doit être revu souvent afin que votre organisation puisse répondre rapidement aux menaces.
Enfin, comme dans tout scénario post-attaque, il y a des questions que vous devriez poser lorsque vous passez en revue chaque phase du plan.
- Quelles parties du plan ont été réussies ?
- Quelles parties du plan n’ont pas été réussies ?
- Que n’avons-nous pas fait que nous réalisons maintenant que nous devions faire ?
- Qu’avons-nous appris qui nous permet d’être mieux préparés à la prochaine vulnérabilité qui se présente à nous ?
Shellshock est peut-être une vieille attaque, mais pour un attaquant, elle coche toutes les cases pour exploiter des victimes qui n’ont pas une bonne hygiène de sécurité.