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. #21
    Membre chevronné
    Citation Envoyé par laerne Voir le message
    Il y avait une énorme faille de sécurité dans le libc de linux il y a 4 ans, qui permettait de passer root. Genre dans la lib que 99.9% des applications utilisent… C'est bizarre à l'époque la masse populaire n'en a vraiment pas vraiment été effrayé/scandalisé. Les gens concernés ont juste fait un mise à jour quoi. Je me demande ce qu'il s'est passé depuis 4 ans pour que le public soit aussi sensible sur ces questions d'un coup.
    Mais c'est une excellente chose, je trouve. La prise de conscience est le premier pas vers la liberté. La sécurité des systèmes, c'est primordial, que ça soit un serveur critique ou simplement mon téléphone.

    Ce qui s'est passé ? Edward Snowden.
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

  2. #22
    Membre régulier
    Citation Envoyé par Traroth2 Voir le message
    "la vulnérabilité pourrait constituer une plus grande menace que Heartbleed"
    ...
    On est très, très loin de Heartbleed, là, quand même...
    Il est vrai que la comparaison avec Heartbleed est peut-être osé mais cette faille bénéficie de deux "avantages", elle est beaucoup plus simple à mettre en place et au contraire de Heartbleed qui ne permettait que de récupérer des données, elle peut permettre de prendre le contrôle d'un serveur.

    Ce sont les raisons qui me font penser qu'on maximise son effet. Attention, je ne dis pas pour autant qu'elle est bénigne !

    C'est un peu comme pour la tempête en 99, aucune alerte du coup les suivantes même pour des trucs sans gravité, on avait une foison
    d'alertes

  3. #23
    Membre extrêmement actif
    Citation Envoyé par Traroth2 Voir le message
    Sérieusement, on est en train de parler d'une faille qui nécessite que le pirate puisse déposer un script sur le serveur et l'exécuter en root.
    Totalement faux.

    Citation Envoyé par Traroth2 Voir le message

    Ou alors qu'il connaisse un script appelé depuis une application web et qui sette des variables d'environnement à partir de paramètres saisis dans une interface web.Toujours en root...
    Re totalement faux.

    Lis les commentaires précédent

    Et arrêtez de penser que sans compte root on ne peut rien faire. Ça limite l'action oui, mais ça n'empêche pas de foutre la grouille. Et il "suffit" qu'un hacker utilise une fois connecté une faille de privilege escalation pour passer root. Une faille n'est qu'un outil, un hacker pour arriver à ses fins utiliseras plusieurs failles complémentaires.

  4. #24
    Membre régulier
    Testé sur mon Thomson TO7-70 tout va bien, ma machine ne semble pas être concernée

  5. #25
    Membre chevronné
    Citation Envoyé par benjani13 Voir le message
    Totalement faux.



    Re totalement faux.

    Lis les commentaires précédent
    Les commentaires n'apprennent pas grand-chose. Donc je suis allé voir la description de la faille, ici.

    Effectivement, elle est potentiellement plus sérieuse que ce qui est décrit dans l'article, car un exploit n'a pas besoin de connaitre le nom d'une variable. Il suffit qu'une variable soit settée pour qu'on puisse exécuter du code. Par contre, CGI n'est pas juste un exemple d'angle d'attaque, c'est pratiquement le seul permettant un exploit public. Par OpenSSH, il faut des identifiants.

    Citation Envoyé par benjani13 Voir le message

    Et arrêtez de penser que sans compte root on ne peut rien faire. Ça limite l'action oui, mais ça n'empêche pas de foutre la grouille. Et il "suffit" qu'un hacker utilise une fois connecté une faille de privilege escalation pour passer root. Une faille n'est qu'un outil, un hacker pour arriver à ses fins utiliseras plusieurs failles complémentaires.
    Oui, et si en plus, il y a une faille "maître du monde", tu deviens le maître du monde.

    Je ne dis pas que cette faille est anodine, mais ça concerne (surtout) les applications web en CGI s'appuyant sur bash. Ca limite quand même énormément les possibilités d'exploit. Je maintiens qu'on est extrêmement loin de Heartbleed. Il reste que la faille est présente dans bash depuis 22 ans. Ca rappelle que la question de la sécurité informatique n'a pas toujours été aussi importante qu'aujourd'hui. Je me souviens d'une époque où Internet, c'était quelques millions d'utilisateurs et pas franchement d'enjeu à ce niveau, finalement (pas d'online banking, pas de commerce, pas beaucoup de messages persos)...
    J'appelle "Point Traroth" le moment dans une discussion où quelqu'un parle des Bisounours. A partir de ce moment, toute discussion sérieuse devient impossible, puisque la légitimité d'une des parties pour exposer son point de vue est mise en cause. C'est juste un anathème, un moyen de décrédibiliser les autres sans avoir à discuter.

  6. #26
    Membre extrêmement actif
    Citation Envoyé par Traroth2 Voir le message
    Les commentaires n'apprennent pas grand-chose. Donc je suis allé voir la description de la faille, ici.
    Je me permet de m'auto citer (première page):
    Citation Envoyé par benjani13 Voir le message
    Pour ceux disant qu'une faille côté applicative est nécessaire, on pourrait le croire selon la news mais c'est faux. Il y a des vecteur d'attaques direct.

    Cf:
    http://seclists.org/oss-sec/2014/q3/650

    Le meilleur vecteur d'attaque est le script CGI. Si un script CGI est en place, on peut l'appeler avec des données modifiés dans la requêtes (afin d'insérer le code malicieux). Or, les headers de la requêtes sont mapé dans des variables d'environnement (spécification de CGI). Et donc le code malicieux se retrouve dans une variable d'environnement, code qui sera exécuté.

    J'ai vu un code d'exploit passant par un script CGI.

  7. #27
    Membre émérite
    je viens de tester sur mon poste chez moi (Ubuntu 14.04) et sur mon serveur dédié (Debian 7.5): aucun problème bien qu'un "echo $SHELL" m'affiche "/bin/bash" sur les deux...

  8. #28
    Membre confirmé
    Citation Envoyé par Traroth2 Voir le message
    Je ne dis pas que cette faille est anodine, mais ça concerne (surtout) les applications web en CGI s'appuyant sur bash. Ca limite quand même énormément les possibilités d'exploit.
    Il y aussi le probleme de dhclient qui tend a faire tourner un script propre a la distribution (transmet les infos de la connection via des variables d'environnement et lance bash). Ce qui veut dire que lors de la connection a un DHCP rogue, dhclient peut etre utilise pour injecter du code. La partie marrante, c'est que dhclient tourne avec les privileges d'admin. Donc n'importe quel DHCP peut injecter du code a distance en tant que root et sans avoir a connaitre le mot de passe.

  9. #29
    Expert confirmé
    Citation Envoyé par TNT89 Voir le message
    Il y aussi le probleme de dhclient qui tend a faire tourner un script propre a la distribution (transmet les infos de la connection via des variables d'environnement et lance bash). Ce qui veut dire que lors de la connection a un DHCP rogue, dhclient peut etre utilise pour injecter du code. La partie marrante, c'est que dhclient tourne avec les privileges d'admin. Donc n'importe quel DHCP peut injecter du code a distance en tant que root et sans avoir a connaitre le mot de passe.
    ça revient tout de même à avoir accès au réseau de la cible
    à moins de te connecter au réseau de la cible tu ne peut pas l'attaquer comme ça
    Rien, je n'ai plus rien de pertinent à ajouter

  10. #30
    Membre extrêmement actif
    Citation Envoyé par TiranusKBX Voir le message
    ça revient tout de même à avoir accès au réseau de la cible
    à moins de te connecter au réseau de la cible tu ne peut pas l'attaquer comme ça
    J'ai déjà vu une conférence d'un pentester, le gars disait que c'était pas rare lors d'audit de trouver dans des agences (banque ou autres) des prises ethernet accessible aux clients (volontairement ou non). Prises ethernet non coupées du réseau de l'agence bien entendu

  11. #31
    Responsable .NET

    Shellshock : la faille dans Bash exploitée par des pirates
    les correctifs publiés seraient incomplets

    La faille dans Bash, baptisée « Shellshock », est actuellement le sujet chaud dans le monde de la sécurité informatique.

    Cette faille touche les systèmes d’exploitation Linux et Unix, y compris éventuellement OS X. Elle affecte donc des millions de PC, Mac, serveurs et routeurs dans le monde. Selon des estimations, Shellshock pourrait affecter près de 70 % des serveurs Web.

    Shellshock se situe au niveau de la manipulation des variables d’environnement dans Bash. Avec des variables spécialement conçues, un pirate pourrait utiliser cette vulnérabilité pour exécuter à distance des commandes Shell. « Lors de l’exécution d’un programme Bash, ce dernier charge des variables d’environnement. La valeur de ces variables peut être statique, mais Bash autorise aussi à charger des fonctions. C’est dans le parsing de cette fonction que réside le problème. En effet, un attaquant peut injecter des commandes à la fin de la fonction », explique Trend Micro.

    Shellshock : une faille d’une grande gravité

    Shellshock a été rapidement rapprochée de la faille Heartbleed, qui avait touché OpenSSL en avril dernier et avait fait trembler le Web. Plusieurs chercheurs en sécurité s’accordent même sur le fait que cette faille représenterait une menace plus importante que Heartbleed.

    Alors que Heartbleed pouvait être utilisée pour le vol de données personnelles, Shellshock, quant à elle, permettrait de causer encore plus de dégâts. Un exploit pourrait permettre de prendre le contrôle intégral des équipements affectés, d'accéder à des informations confidentielles, de procéder à des modifications sur l’OS, etc. La faille existerait dans le Shell de Linux depuis pratiquement 20 ans.

    La « National Vulnerability Database », un système utilisé par le gouvernement américain pour suivre les failles de sécurité informatiques, a donné à cette vulnérabilité le score maximal (10/10) pour sa « gravité », son « impact » et son « exploitabilité ». De plus, la faille a été étiquetée comme « très simple à exploiter ». « Avec un simple copier/coller d’une ligne de code, vous pouvez obtenir de bons résultats », avait affirmé Dan Guido, PDG du cabinet de sécurité Trail of Bits.

    Des correctifs incomplets

    A la suite de la divulgation de cette faille, des correctifs ont été immédiatement publiés par les développeurs de l’outil. Plusieurs fournisseurs de systèmes d’exploitation Linux, notamment Red Hat, Debian et CentOS, ont mis à la disposition des utilisateurs des patchs.

    Cependant, des chercheurs en sécurité ont découvert des failles dans ces mises à jour. Les correctifs ne permettraient donc pas de protéger complètement Bash des injections de code via les variables d’environnement. De plus, les correctifs seraient sujets à une exception « null-pointer » pouvant entrainer un crash de l’outil.

    Bien que les correctifs soient marqués comme incomplets, il est néanmoins conseillé de les appliquer, le temps que de nouveaux correctifs soient disponibles.

    La faille déjà exploitée par des pirates

    Shellshock serait déjà exploitée par des pirates. Des chercheurs en sécurité auraient identifié des vers informatiques qui se propageraient assez rapidement pour analyser les systèmes vulnérables et les infecter.

    Le cabinet de sécurité Kaspersky Lab affirme avoir découvert un ver informatique qui exploite cette faille pour infecter des ordinateurs. Le malware serait capable de prendre le contrôle d’une machine affectée, de lancer des attaques DOS (déni de service) pour perturber des sites Web et de scanner un réseau pour trouver les autres équipements vulnérables, y compris des routeurs.

    D’autres rapports font état de l’utilisation du botnet « wopbot » (qui exploite également Shellshock) par des pirates pour essayer de créer un réseau de zombies et infecter des serveurs vulnérables. Le botnet procéderait à un scan d’Internet pour trouver des serveurs vulnérables. Les pirates derrière « wopbot » auraient lancé une attaque DOS contre les serveurs hébergés par Akamai Technologies, société américaine spécialisée dans la mise à disposition de serveurs de cache pour les entreprises.

    « Avec honeypot, nous avons trouvé plusieurs machines qui tentent d’exploiter la vulnérabilité Bash », a déclaré Jamie Blasco, directeur du laboratoire de sécurité AlienVault. « La majorité d’entre elles est utilisée pour vérifier si des systèmes sont vulnérables. D’autre part, nous avons trouvé deux vers qui exploitent activement la vulnérabilité pour installer des logiciels malveillants sur les systèmes affectés. Les équipements infectés sont contrôlés par des serveurs de C&C pour effectuer essentiellement des attaques DoS. »

    Pour l’instant, le moyen de se protéger est de patcher en urgence ses serveurs, même si les patchs sont incomplets.
    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

  12. #32
    Membre confirmé
    Effectivement cette faille est grave. Et pas besoin d'être connecté en root, pour par exemple lancer un service telnet sur un port qui ne serait pas firewallé, donnant un accès... et lire le contenu des fichiers de configuration de la base de donnée par exemple, récuperer des infos importantes comme des mots de passe ou reinitialiser un mot de passe en particulier pour acceder au compte etc...

    ça permet aussi d'installer incognito des clients http qui transformerons le serveur en puissante machine pour du DDoS, avec un c&c sur twitter par exemple...

    Pour tout ça vraiment pas besoin d'accès root...

    Et les services CGI, principaux services visés par cette faille, sont assez nombreux, ne serait-ce que les configuration de php ou ruby en fastcgi / cgi-bin.

    Les variables d'environnement sont settés pour par exemple màpper les headers http vers le service cgi. Envoyer ça a un script cgi executera le code:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    curl --header "Cookie: () {:;}; echo 'vul' > /tmp/vulnerability" --header "Host: () {:;}; echo 'vulnerable' > /tmp/vulnerability" --header "Referer: () {:;}; echo 'vulnerable' > /tmp/vulnerability" monsite.com/un-service-cgi
    Bref alarmiste, effectivement il y a de quoi!

    Vive nginx en mode reverse proxy et ton serveur d'application sur un port bindé en local, ça évite déjà pas mal d'attaques de bases!

  13. #33
    Membre régulier
    Citation Envoyé par Hinault Romaric Voir le message


    « Avec honeypot, nous avons trouvé plusieurs machines qui tentent d’exploiter la vulnérabilité Bash », a déclaré Jamie Blasco, directeur du laboratoire de sécurité AlienVault. « La majorité d’entre elles est utilisée pour vérifier si des systèmes sont vulnérables. D’autre part, nous avons trouvé deux vers qui exploitent activement la vulnérabilité pour installer des logiciels malveillants sur les systèmes affectés. Les équipements infectés sont contrôlés par des serveurs de C&C pour effectuer essentiellement des attaques DoS. »
    C'est du pinaillage mais je préfère le signaler, honeypot n'est pas un logiciel ou un système !
    Il s'agit d'une méthode de défense que l'on peut qualifier d'active. Le but est de mettre en place un leurre pour attirer les personnes malveillantes dessus et voir, entre autres, comment l'attaquant va faire pour essayer de compromettre le système cible. A partir des données collectées, on a la possibilité de renforcer la sécurité du réseau et de se prémunir contre de futures attaques !

  14. #34
    Membre averti
    comment appliquer le patch
    question de noob,
    comment appliquer ce patch :
    http://lists.gnu.org/archive/html/bu.../msg00083.html
    Merci d'avance

  15. #35
    Membre confirmé
    Citation Envoyé par mapmip Voir le message
    question de noob,
    comment appliquer ce patch :
    http://lists.gnu.org/archive/html/bu.../msg00083.html
    Merci d'avance
    En fonction de ta machine, globalement les paquets avec le fix sont déjà dans les repositories, genre pour une debian
    un simple "apt-get install bash" devrait résoudre le probleme. Enfin, pour repondre a un 'noob' (par un autre noob), je ne m'aventurerais pas a recompiler le bash avec un patch...

    C'est comme recompiler ssh-deamon à distance, tu risque de perdre les acces à ta machine

    Sinon http://jungels.net/articles/diff-pat...n-minutes.html

    ./configure && make && make install

    etc... Mais je recommande pas

  16. #36
    Membre averti
    Citation Envoyé par anykeyh Voir le message
    En fonction de ta machine, globalement les paquets avec le fix sont déjà dans les repositories, genre pour une debian
    un simple "apt-get install bash" devrait résoudre le probleme. Enfin, pour repondre a un 'noob' (par un autre noob), je ne m'aventurerais pas a recompiler le bash avec un patch...

    C'est comme recompiler ssh-deamon à distance, tu risque de perdre les acces à ta machine
    je suis sur centos 6, j'ai fait yum update bash, ca me réinstalle la 4.1.2 datant de 2009...

  17. #37
    Membre extrêmement actif
    Citation Envoyé par mapmip Voir le message
    question de noob,
    comment appliquer ce patch :
    http://lists.gnu.org/archive/html/bu.../msg00083.html
    Merci d'avance
    "Bash-4.1 Official Patch 12" Si c'est officiel ça devrait être dans les dépôts. Tente un update de ton système.

    EDIT= Grillé

  18. #38
    Modérateur

    La plus part des distributions Linux sont ou on mis à disposition à jour, mais toujours rien pour Mac.
    Ça devrait arriver la semaine prochaine.
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  19. #39
    Rédacteur

    D'ailleurs Mac par défaut ils sont toujours à Bash 3.x ?

    (J'avais installé la version 4.2.45 via brew perso, mais ils ne sont toujours pas à jour sur ces correctifs).

  20. #40
    Responsable .NET

    Shellshock : de nouveaux correctifs disponibles
    Apple minimise les conséquences pour les utilisateurs d’OS X

    Mise à jour du 30/09/2014, des correctifs disponibles pour OS X

    Apple a publié des correctifs pour les utilisateurs d’OS X pour corriger la faille critique « Shellshock » dans Bash. Les correctifs sont disponibles pour OS X Lion, OS X Mountain Lion et OS X Mavericks.

    Aucun correctif n’est disponible pour les versions d’OS antérieures à la 10.7. La prochaine préversion d’OS X Yosemite intégrera directement le correctif. Apple ne compte donc pas publier un correctif pour les utilisateurs des préversions de Yosemite en cours de tests.

    Les correctifs d’Apple mettent à jour le Shell Bash d’OS X qui passe de la version 3.2.51 à la version 3.2.53. Avant la sortie de ces correctifs, Apple avait signalé qu’OS X était protégé par défaut contre des attaques distantes exploitant cette vulnérabilité, sauf si l’utilisateur a configuré les services Unix avancés sur le terminal.

    Maj de kOrt3x

    De nouveaux correctifs sont disponibles pour l’interpréteur en ligne de commande Bash. Ces mises jours corrigent les problèmes qui avaient été rencontrés avec les précédentes mises à jour qui avaient été publiées pour patcher la faille « Shellshock ».

    Les premiers correctifs pour « Shellshock » avaient été publiés par les développeurs de Bash et les fournisseurs de systèmes d’exploitation Linux et Unix quelques jours après la révélation de la vulnérabilité découverte par le développeur français Stephane Schazelas. Quelques heures après, des experts en sécurité avaient affirmé que d’autres failles similaires à Shellshock étaient encore présentes dans Bash. Toutefois, les nouvelles failles n’avaient pas la même gravité que Shellshock.

    Les nouvelles versions de Bash viennent corriger tous ces problèmes. Les correctifs ont été publiés par les développeurs de Red Hat. Oracle a également préparé des correctifs pour ses systèmes d’exploitation Oracle Linux et Solaris. Le géant des bases de données a également affirmé que plus de 30 de ses produits étaient vulnérables à Shellshock.

    Apple de son côté a minimisé les conséquences pour les utilisateurs de Mac. Bien que les récentes versions d’OS X, y compris OS X Mavericks soient vulnérables. Un porte-parole d’Apple a affirmé que les utilisateurs de son système d’exploitation ne devraient pas s’inquiéter. Selon celui-ci, OS X serait protégé par défaut contre des attaques distantes exploitant cette vulnérabilité, sauf si l’utilisateur a configuré les services Unix avancés sur le terminal. Néanmoins, Apple promet de publier un correctif dans les jours qui suivent. En ce qui concerne iOS, il ne serait pas concerné par cette vulnérabilité, tout comme les systèmes d’exploitation Windows.

    Pour rappel, « Shellshock » est considérée comme une faille bien plus grave que Heartbleed. Elle a obtenu un score de 10/10 pour sa « gravité », son « impact » et son « exploitabilité » sur le système utilisé par le gouvernement américain pour suivre les failles de sécurité informatique. La vulnérabilité se situe au niveau de la manipulation des variables d’environnement dans Bash. Avec des variables spécialement conçues, un pirate pourrait utiliser cette vulnérabilité pour exécuter à distance des commandes Shell et prendre le contrôle total d’un poste affecté.

    La faille daterait de 1992 (22 ans), bien avant que Bash ne se retrouve dans la majorité des serveurs utilisés sur le Web. La faille pourrait donc demeurer une préoccupation pendant un certain moment, d’autant plus que certains systèmes encore utilisés pourraient ne jamais recevoir de correctifs, puisqu’ils ne sont plus pris en charge par leur fournisseur.

    Des experts en sécurité ont affirmé que des malwares exploiteraient déjà ces vulnérabilités. Des pirates auraient mis sur pied des programmes pour scanner le Web et détecter les systèmes vulnérables afin de prendre leur contrôle et y installer des virus.


    Source : Red Hat, Reuters
    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