L’onde de choc de ShellShock

publié par Bitdefender Enterprise France, le 02 octobre 2014

Si vous avez eu un peu de temps libre pour parcourir l’actualité et que vous vous intéressez à l’informatique, vous avez sans doute entendu parler de Shellshock. Cette vulnérabilité, comme beaucoup d’autres, soulève de nombreuses questions et l’objectif de cet article est d’apporter une réponse à certaines d’entre elles.

Quel est le problème ?

Bash (Bourne-again Shell) est l’interpréteur en ligne de commandes présent sur la plupart des environnements Unix. Il est assez pratique pour exécuter des commandes, en particulier lorsqu’elles sont appelées à partir de scripts. La vulnérabilité est globalement liée à la façon dont Bash analyse les variables d’environnement (utilisées pour définir le contexte des commandes). Elle permet aux personnes accédant aux variables d’environnement d’y insérer du code arbitraire. Au lieu de simplement définir le contexte d’exécution, Bash exécute les commandes injectées.

Suis-je vulnérable ?

En théorie oui. En pratique, probablement pas. Si vous utilisez un système basé sur Unix, y compris Linux, techniquement, votre système présente vraisemblablement cette vulnérabilité. Cela ne signifie pas pour autant qu’un attaquant peut en prendre possession à distance Pour que cela soit possible, votre système doit remplir un ensemble de conditions assez précises :

  • Un accès distant, une application Web étant l’exemple typique
  • Une application qui fait appel à Bash
  • Un système vulnérable

Si vous utilisez une application qui appelle Bash, directement ou indirectement (Dash, par exemple), vous êtes concerné par ce problème. La façon la plus courante d’appeler Bash est via des scripts CGI, pour rendre un site web dynamique (pour poursuivre avec l’exemple). Au cours de son exécution, le script accepte les entrées (inputs). Une partie de cet input pourrait être la variable USER-AGENT dans une conversation HTTP. Il est possible d’exécuter du code dans cette variable (au moyen de cette vulnérabilité).

Devrais-je paniquer ?

Uniquement si vous êtes vulnérable. Pour être vulnérable, d’une manière qui puisse intéresser une entité distante, vous devez réunir les critères présentés(cf les points listés ci-dessus).

Pour être clair si j’ai un accès local à vos systèmes *nix et que cela inclut la possibilité d’appeler Bash, je peux utiliser cette vulnérabilité pour exécuter des commandes arbitraires, dont la première serait d’élever mes privilèges locaux. Cependant, si je peux exécuter Bash, soit vous m’avez ouvert un accès via une application accessible à distance soit j’ai un accès local (auquel cas je dispose de nombreuses options locales pour mener à bien l’élévation de privilèges dont j’ai besoin).

L’onde de choc de Shellshock

Mais comment exploiter la vulnérabilité ?

Si votre application, qui accepte les inputs distants, n’appelle pas Bash, alors vous ne risquez rien.Par exemple, une application Web Java s’exécute dans un espace dédié à Java. À moins que le code Java n’appelle des commandes Bash, il ne sera pas possible d’exploiter cette vulnérabilité. Elle ne peut se manifester et être utilisée sans disposer d’un chemin et s’il s’avère que celui-ci appelle Bash et transmet également des variables d’environnement.

Qui devrait s’inquiéter ?

La plupart des applications acceptant les données distantes et qui ont été créées ces dix dernièresannées n’appellent pas Bash. Il s’agit plutôt de marchés verticaux dans lesquels de l’ancien code (en termes informatiques) s’exécute encore. Le secteur de la santé, des finances et les institutions gouvernementales sont autant de marchés verticaux qui ne sont généralement pas reconnus pour leur agilité. Il est possible qu’ils aient encore des URL contenant /cgi-bin/, ce qui pourrait être problématique.

À quoi d’autre devrais-je prêter attention ?

Les applications, de par leur nature-même, devraient être considérées de la même façon que les utilisateurs finaux. Si vous autorisez les applications à s’exécuter en tant que root/admin c’est comme si vous remettiez les clés de votre royaume à toutes les personnes utilisant cette application.

Même si vous exécutez une application, par exemple Apache, sans privilèges particulier, vous devez prêter attention à ce qui est appelé par cette application et partir du principe que toute application peut appeler du code (que cela vous plaise ou non).  Par exemple, il peut sembler simple d’exécuter des tâches CRON en tant que root et il semble bien que ce soit le cas pour la plupart des administrateurs. Cette vulnérabilité montre que ne pas être suffisamment rigoureux avec les permissions peut avoir de lourdes conséquences. Une application Web qui appelle Bash peut être manipulée à distance pour exécuter des commandes, et appeler CRON à ces fins aura très probablement pour but d’élever immédiatement les permissions.

Quelle est la conclusion ?

Il ne s’agit pas du second épisode d’Heartbleed. Ces deux vulnérabilités ne sont pas comparables. Heartbleed est une fuite de données, Shellshock donne la possibilité d’exécuter du code. L’impact potentiel de chacune est indéniable mais très différent.

Hearbleed avait un champ d’application extrêmement large mais ne permettait pas de prendre immédiatement possession des systèmes ciblés (bien qu’extraire des données puisse de fait y conduire). Shellshock permet d’exécuter du code, pas simplement d’extraire des informations et là où Shellshock pourra être appliqué, il causera bien plus de dommages que Heartbleed. Cependant, le nombre et l’influence des cibles qui sont vulnérables à Shellshock sont, de par la nature de la vulnérabilité elle même, pas aussi importants qu’avec Heartbleed.   

En d’autres termes, ne paniquez pas, mais restez vigilant !

Cet article a été rédigé par Shaun Donaldson.

Bitdefender Enterprise France

Bitdefender est le spécialiste européen des solutions antimalware. Ses technologies proactives classées n°1 en détection et en prise de ressources par les organismes de tests indépendants protègent plus de 500 millions d’utilisateurs.