Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Responsable .NET

    ShellShock : « l’attaque est simple, facilement automatisable et aux conséquences désastreuses »
    ShellShock : « l’attaque est simple, facilement automatisable et aux conséquences désastreuses »
    entretien avec Check Point sur la faille dans Bash

    Le séisme « Shellshock » secoue depuis quelques jours le Web. Le sujet est actuellement sur toutes les lèvres dans le monde de la sécurité informatique et même au-delà. Shellshock est considérée comme plus désastreuse qu’Heartbleed, qui était pourtant l’une des pires failles qu’auraient connu Internet.

    La vulnérabilité touche l’interpréteur en ligne de commande Bash qui est utilisé comme Shell par défaut par les systèmes d’exploitation Linux et Unix. La « National Vulnerability Database » utilisée par le gouvernement américain pour suivre les failles de sécurité informatique, a donné à cette vulnérabilité le score maximal (10/10) pour sa « gravité », son « impact » et son « exploitabilité ».

    En moins d’un an, l’univers de l’open source et Internet se retrouvent agiter à deux reprises par des vulnérabilités dans deux outils massivement utilisés. Deux situations qui mettent en exergue le risque d’une utilisation trop importante d’une même technologie.

    Dans l’optique d’apporter plus de détails sur cette faille, les mesures à prendre pour se protéger, les implications, etc. la rédaction de Developpez.com s’est entretenue avec Thierry Karsenti, Directeur Technique Europe chez Check Point, fournisseur des solutions de sécurité du système d’information.


    Developpez.com : Pouvez-vous revenir en détail sur cette vulnérabilité et son principe ?

    Thierry Karsenti : La vulnérabilité découverte touche BASH, un interpréteur de ligne de commande présent sur des millions d’équipements informatiques (Linux, Mac OS, routeurs, serveurs web, caméras IP et autres objets connectés, etc.). Cette vulnérabilité est présente depuis une vingtaine d’années, et consiste à abuser d’un bug pour exécuter à distance un code malveillant.

    Developpez.com : Quel est l’impact de cette faille et comment un pirate peut-il l’exploiter ?

    Thierry Karsenti : L’attaque est très simple à mettre en œuvre, facilement automatisable, et aux conséquences désastreuses, puisqu’elle permet de prendre le contrôle complet du système vulnérable. Cela ouvre donc la voie à l’espionnage massif, le vol ou la destruction de données, la mise à mal des infrastructures critiques…


    Developpez.com : Comment vérifier que son équipement est vulnérable ?

    Thierry Karsenti : Une simple ligne de commande permet de tester son système. De nombreux exemples circulent sur Internet pour pouvoir faire soi-même la vérification. Une autre approche est de solliciter son fournisseur d’équipement pour savoir s’il est vulnérable ou non. Enfin, il existe déjà des outils qui permettent de scanner son système d’information à la recherche d’équipements vulnérables.

    Pour rappel, si vous souhaitez vérifier si votre système est vulnérable, vous pouvez utiliser la ligne de code suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    env x='() { :;}; echo vulnérable' bash -c "echo ceci est un test"
    Si votre système est vulnérable, vous obtiendrez en sortie :

    vulnérable
    ceci est un test
    Thierry Karsenti, Directeur Technique Europe chez Check Point

    Developpez.com : Quels sont les risques pour les serveurs vulnérables ?

    Thierry Karsenti : Les risques sont majeurs puisque l’attaquant peut prendre entièrement le contrôle de l’équipement.

    Developpez.com : Qu'est-ce qui rend Shellshock plus grave que Heartbleed ?

    Thierry Karsenti : Heartbleed concernait des versions logicielles des 2 dernières années. Shellshock concerne toutes les versions de BASH, et offre une surface d’attaque bien supérieure. Tous les vecteurs d’attaque ne sont d’ailleurs pas encore pleinement connus.

    Developpez.com : Le bug est présent depuis 22 ans. Qu’est-ce que cela implique ?

    Thierry Karsenti : Cela augmente considérablement le risque d’avoir des équipements vulnérables dans son système d’information. Par ailleurs, certains équipements vulnérables n’auront peut-être pas de correctifs, car trop anciens et donc plus mis à jour par leurs fournisseurs (même si les clients continuent pour certains de les utiliser…).

    Developpez.com : Avez-vous observé des attaques qui exploitent cette faille ?

    Thierry Karsenti : Il y a de nombreux scanners pour tester en masse les vulnérabilités d’équipements sur Internet. Certains d’entre eux ne se contentent pas de détecter les vulnérabilités, mais prennent le contrôle des systèmes identifiés comme vulnérables et installent un cheval de Troie (bot).

    Developpez.com : Quelles mesures devraient prendre les administrateurs pour se protéger ?

    Thierry Karsenti : Il est urgent de faire l’inventaire des systèmes vulnérables, et planifier le plus rapidement possible une mise à jour. En parallèle, il convient d’utiliser des solutions de sécurité type prévention d’intrusion pour minimiser le risque et gagner du temps dans cette course contre la montre.

    Developpez.com : Deux failles graves la même année dans des outils open source très utilisés. Cela remet-il en question la sécurité des solutions open source ?

    Thierry Karsenti : Plus que l’open source, cela met en exergue le risque d’utilisation massive d’une même technologie, d’un même code, ou d’une même application. Cela était vrai quand Windows était omniprésent (Microsoft était alors souvent pointé du doigt sur le banc des accusés), cela touche aujourd’hui naturellement le logiciel libre qui est d’une certaine manière victime de son succès !
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre chevronné
    Edit : Okay, je suis une grosse bille , je viens de capter.
    J'ai cru comprendre dans "la faille est présente depuis 22 ans" le fait qu'on l'avait découverte il y a 22 ans.

    Du coup je suis HS.

  3. #3
    Membre habitué
    @SofEvans
    La faille est présent depuis 22 ans mais elle vient tout juste d'etre trouvé et est deja corrigé sur pas mal de grand distribution linux, tous simplement.

    Vu qu'elle est pas mal utilisé et que les anciens systèmes ne sont plus mise a jours, cela a un impact plus large que les autres failles d'avant.

  4. #4
    Nouveau membre du Club
    ShellShock !!!
    "Thierry Karsenti : Plus que l’open source, cela met en exergue le risque d’utilisation massive d’une même technologie, d’un même code, ou d’une même application. Cela était vrai quand Windows était omniprésent (Microsoft était alors souvent pointé du doigt sur le banc des accusés), cela touche aujourd’hui naturellement le logiciel libre qui est d’une certaine manière victime de son succès !"

    A mon avis ce type a quelque chose à vendre : des chaussures, des aspirateurs, du couscous-merguez ?
    Qu'on nous donne une statistique sur le nombre d'incidents dus à cette "faille majeure" presque apocalyptique depuis 22 ans

  5. #5
    Membre à l'essai
    J'ai aussi un peu de mal à comprendre comment cette faille peut être si catastrophique?! Je comprends bien que d'anciens systèmes ont la failles et ne seront plus mis-à-jour, mais encore faut il pouvoir exploiter la faille! Si je comprends bien, il faut avoir l'autorité de lancer une commande bash pour exécuter le code.

    Sur un réseau protégé (par un firewall par exemple), comment un pirate peut il l'exploiter?

    Ce type dit que la faille est exploitable facilement?! Comment?

    Je pense comme @Ph. Marechal, ce type a un truc à vendre

  6. #6
    Expert éminent
    Citation Envoyé par BenDeVil Voir le message
    Sur un réseau protégé (par un firewall par exemple), comment un pirate peut il l'exploiter?

    Ce type dit que la faille est exploitable facilement?! Comment?

    Je pense comme @Ph. Marechal, ce type a un truc à vendre
    À ce que j'ai vu, tu peux mettre la commande dans le USER-AGENT et dans les entêtes HTTP

    Bash 'shellshock' scan of the Internet
    What is a specific example of how the shellshock bash bug could be exploited?

  7. #7
    Membre extrêmement actif
    Citation Envoyé par BenDeVil Voir le message
    J'ai aussi un peu de mal à comprendre comment cette faille peut être si catastrophique?! Je comprends bien que d'anciens systèmes ont la failles et ne seront plus mis-à-jour, mais encore faut il pouvoir exploiter la faille! Si je comprends bien, il faut avoir l'autorité de lancer une commande bash pour exécuter le code.

    Sur un réseau protégé (par un firewall par exemple), comment un pirate peut il l'exploiter?

    Ce type dit que la faille est exploitable facilement?! Comment?
    Bis repetita....

    Oui cette faille est exploitable extrêmement facilement.

    http://www.developpez.net/forums/d14...critique-bash/

  8. #8
    Membre expérimenté
    Cette "faille" est juste honteusement survendu.


    Cette "faille" n'offre pas de zero day, pas d'escalation des privilège, pas d'execution fantome.
    Elle permet juste de faire de l'injection de commande dans un string bash: woot woot !


    J'ai envie de dire, si en 2014 vous utilisez encore du bash derrière des scripts CGI pour vos serveurs sans jail, sans containers: vous méritez de vous faire hacker.
    It's not a bug, it's a feature

  9. #9
    Expert confirmé
    Je me dois de répondre ici à tous les adorateurs de l'Open Source qui semblent un peu dans le déni.

    Il n'y a pas besoin de s'introduire dans le système pour exécuter cette faille. Un simple site malveillant suffit à utiliser la faille à l'aide d'un en-tête HTTP. Bref tu peux l'attraper en surfant ou en utilisant des logiciels liés à des sites web (apache et ton site web par exemple), tout comme HeartBleed. Si tu héberges un site web qui par exemple utilise un Web Service ou un autre site internet devenu douteux (facebook au hasard), tu peux attraper la faille.
    Bref c'est tentaculaire. Si tu n'as pas résolu la faille et qu'une de tes applications est liée à une autre qui n'a pas résolue la faille, tu peux l'attraper.

    Au lieu d'être dans le déni, mettez votre parc informatique à jour pour vous protéger, comme on le fait avec Windows !

    Et comme dit plus tôt, en effet utiliser des CGI c'est dangereux. Mais voila il y a beaucoup de vieilles solutions, comme celles des banques programmées en Cobol.

  10. #10
    Nouveau Candidat au Club
    Je me dois de répondre ici à tous les adorateurs de l'Open Source qui semblent un peu dans le déni.
    Un peu ? t'es encore gentil.

    Les failles dans l'OpenSource sont bonne. ils vont encore dire que c'est bien de l'avoir découverte, que c'etait grace a l'ouverture du code et tous ca...

    J'ai envie de dire, si en 2014 vous utilisez encore du bash derrière des scripts CGI...
    Ils trouve déjà que migrer depuis Windows XP est trop. Faut pas leur demander de suivre l’évolution de l'informatique .

  11. #11
    Membre actif
    Et l'evolution de l'informatique c'est quoi ? Windows 8 ? Si c'est le cas, je prefere ne pas "evoluer".

  12. #12
    Expert confirmé
    Citation Envoyé par Thomas404 Voir le message
    Et l'evolution de l'informatique c'est quoi ? Windows 8 ? Si c'est le cas, je prefere ne pas "evoluer".
    Windows 7 et Windows Server 2012 R2 sont déja très bien. Ils sont maintenus jusqu'à au moins 2018. Et je ne parle pas des distributions Linux, à condition de les mettre à jour. Linux n'est pas invulnérable, il suscite surtout moins d'intérêt pour les hackeurs.
    Et pour Windows 8, avec un petit logiciel tu peux restaurer le menu démarrer et là plus de problème. je le trouve plutôt bon si on met cet aspect de côté. De toute façon il n'y a pas de version serveur basée sur Windows 8.

    Je me demande ce que sera Windows 9.

  13. #13
    Nouveau Candidat au Club
    Si c'est le cas, je prefere ne pas "evoluer".
    A toi de voir. Mais t'as pas vraiment le choix je te signal. Je ne cherche pas a te convaincre. Tous fonctionne bien pour moi ne te tracasse pas. Et Windows 8.1 fonctionne très bien et j'en sort beaucoup plus que de W7.Meme des pensionnés arrive a l'utiliser et voient les avantages. Si toi t'arrive pas a l'utilisé c'est pas mon problème.

  14. #14
    Nouveau Candidat au Club
    De toute façon il n'y a pas de version serveur basée sur Windows 8.
    W2012 R2 partage le même noyau que W8.1

  15. #15
    Membre extrêmement actif
    Pour les trois gus au dessus:
    https://fr.wiktionary.org/wiki/hors-sujet

  16. #16
    Nouveau Candidat au Club
    Pour les trois gus au dessus:
    https://fr.wiktionary.org/wiki/hors-sujet
    Depuis quand t'es modérateurs ???

    Tu crois vraiment qu'on va faire ce que tu dis ? De plus répondre au question c'est pas HS.

  17. #17
    Expert confirmé
    Citation Envoyé par GHetfield Voir le message
    W2012 R2 partage le même noyau que W8.1
    Merci de l'info. Autant pour moi.

  18. #18
    Membre éprouvé
    Citation Envoyé par Thomas404 Voir le message
    Et l'evolution de l'informatique c'est quoi ? Windows 8 ? Si c'est le cas, je prefere ne pas "evoluer".
    l'évolution de l'informatique c'est tellement vaste que le restreindre a un Os...

    ensuite c'est toujours pareil , ce n'est pas en testant un produit une fois pendant 15 minutes qu'on se fait un avis ...



    Pour en revenir au sujet , c'est pas étonnant , pourquoi il n'y aurait que windows de touché , tous les systèmes ont leur faille , ou auront leur faille , En faire un arguments a l'adoption ou non d'un système me parait , Ridicule
    Garry
    La connaissance c'est ce qu'il manque à tout homme

  19. #19
    Membre régulier
    La faille est exploitable sur tous les serveurs qui:

    1) Déclenchent du code exécutable au travers de bash: par exemple un shell script, ou encore un exécutable qui utilise bash pour déclencher des actions.
    C'est le cas (possiblement) dans pas mal de serveurs HTTP Apache qui utilisent CGI

    2) Passent à ce code exécutable de l'information fournie par les clients, sous forme de variables d'environnement.
    C'est le cas des en-têtes HTTP (entre autres) dane le cas de ces mêmes serveurs.

    La faille se trouve dans le mécanisme fourni par BASH qui permet à un process parent de passer une fonction à un process fils sous forme de variable d'environnement, et qui par erreur, permet d'inclure du code malicieux qui sera automatiquement exécuté lorsque BASH va définir la fonction.

    Dans le scénario du serveur HTTP, un attaquant peut passer une entête HTTP (par exemple "user-agent") avec un contenu malicieux. Ce contenu se retrouvera sur le serveur dans une variable du genre HTTP_USER_AGENT. Elle sera interprétée par BASH comme décrit ci-dessus, menant à l'exécution du code malicieux. L'impact de ce dernier dépend du contexte d'exécution du serveur HTTP. Gare s'il tourne en root!

    La faille est bien réelle. Son impact potentiel est certain. Il est cependant limité au contexte que je cite plus haut: des serveurs HTTP qui utilisent CGI. Si vous en tourner un, alors il est vraiment important de patcher bash!

    Le fait que Apple n'ait pas encore publié de correctif pour OS X n'est pas un vrai souci: qui fait tourner un site web public sous Apache et CGI sur un Mac ? Même sur un serveur Mac ? Mais je trouve malvenu qu'Apple n'ait pas pris la peine de corriger. Il est vrai que Mac OS X inclut une version bien ancienne de bash.

  20. #20
    Expert confirmé
    Citation Envoyé par agodfrin Voir le message

    Le fait que Apple n'ait pas encore publié de correctif pour OS X n'est pas un vrai souci: qui fait tourner un site web public sous Apache et CGI sur un Mac ? Même sur un serveur Mac ? Mais je trouve malvenu qu'Apple n'ait pas pris la peine de corriger. Il est vrai que Mac OS X inclut une version bien ancienne de bash.
    Tu penses bien...Faire un patch ça coûte de l'argent et ça réduit les dividendes des actionnaires à la fin du mois.

    J'ai connu ça dans d'autres grandes entreprises...

###raw>template_hook.ano_emploi###