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
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.Envoyé par laerne
Ce qui s'est passé ? Edward Snowden.
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
Totalement faux.
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.
Testé sur mon Thomson TO7-70 tout va bien, ma machine ne semble pas être concernée
Les commentaires n'apprennent pas grand-chose. Donc je suis allé voir la description de la faille, ici.Totalement faux.
Re totalement faux.
Lis les commentaires précédent
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.
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)...
Je me permet de m'auto citer (première page):
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...
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
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
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
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:
Bref alarmiste, effectivement il y a de quoi!
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2curl --header "Cookie: () {:;}; echo 'vul' > /tmp/vulnerability" --header "Host: () {:;}; echo 'vulnerable' > /tmp/vulnerability" --header "Referer: () {:;}; echo 'vulnerable' > /tmp/vulnerability" monsite.com/un-service-cgi
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!
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 !
comment appliquer le patch
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-patch-ten-minutes.html
./configure && make && make install
etc... Mais je recommande pas
je suis sur centos 6, j'ai fait yum update bash, ca me réinstalle la 4.1.2 datant de 2009...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
"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é
La plus part des distributions Linux sont ou on mis à disposition à jour, mais toujours rien pour Mac.
Ça devrait arriver la semaine prochaine.
La rubrique Mac
________________________________________________________________________
QuickEvent : Prise de rendez-vous rapide pour iPhone/iPad et iPod Touch (AppStore)
Mon Livre sur AppleScript : AppleScript: L'essentiel du langage et de ses applications
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).
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager