Microsoft se penche sur XorDdos, cheval de Troie Linux qui cible l’IoT et Docker
Le 23 mai 2022 à 08h20
1 min
Internet
Internet
L'activité de XorDdos, un cheval de Troie Linux découvert en 2014 et utilisé pour exécuter plusieurs techniques d'attaques DDoS, aurait explosé de 254 % ces derniers temps, expliquent les chercheurs de Microsoft 365 Defender.
XorDdos profiterait de la croissance de l'Internet des objets (IoT), des clusters Docker mal configurés dans le cloud, et se propagerait via des attaques par force brute SSH à la recherche de mots de passe « faibles », résume ZDNet.
« Nous avons constaté que les appareils initialement infectés par XorDdos ont ensuite été infectés par d'autres logiciels malveillants tels que la porte dérobée Tsunami », utilisé pour déployer le mineur de crypto-monnaie open source XMRig.
« Nous avons observé dans des campagnes récentes que XorDdos cache les activités malveillantes de l'analyse en écrasant les fichiers sensibles avec un octet nul. Il inclut également divers mécanismes de persistance pour prendre en charge différentes distributions Linux », note Microsoft.
Le cheval de Troie serait même capable de « se relancer automatiquement lorsqu'un système est redémarré grâce à plusieurs scripts et commandes qui le font s'exécuter automatiquement au démarrage d'un système ».
Le 23 mai 2022 à 08h20
Commentaires (20)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 23/05/2022 à 09h32
Alors pour une fois que c’est une attaque sur les systemes linux, pourquoi une image centree sur microsoft ? Pour dire qu’ils compatissent ?
Le 23/05/2022 à 09h53
Il faudra m’expliquer comment
permet de lutter contre
La logique m’échappe.
J’arrive pas à inclure la première ligne de la première citation dans l’encadré noir.
La 2ème citation ne veut rien savoir non plus.
Le 23/05/2022 à 10h35
Les conteneurs sont “magiques” permettent une souplesse inégalée etc.
Pour le dev, qualif, POC… peut être.
Quand je me suis intéressé (y-a 7 ou 8 ans, ça a peut être évolué depuis) à la techno, je m’étais aperçu du travail de mises à jours des images qui était dissuasif (pour de l’hébergement web).
Suis resté aux “anciennes” méthodes (serveur mutu avec Vhost Apache)
Le 23/05/2022 à 11h45
En gros, la base de l’attaque est très classique (brute force ssh).
Du coup auth par fichier (ou même ssh tarpit) devrait suffire (voir même juste un mot de passe complexe).
Le 23/05/2022 à 12h11
Ouais, j’ai lu l’article, c’est un chouette exemple d’informercial en vrai.
Les attaques requièrent en premier lieu qu’un fichier local ait été créé qui porte le “vrai” vecteur d’attaque mais rien n’est précisé sur ni comment ce fichier est créé, ni quels paramètres de configuration d’un navigateur il faut surveiller (ou s’il existe un site de liste noire d’urls à éviter).
Ensuite, les “conseils” ne sont que des arguments de souscription à la solution de sécurité maison. Même pas les bases de type “vérifiez la robustesse des mots de passe” ou “en entreprise mettez en place une liste blanche de sites consultables” etc…
Le 23/05/2022 à 12h19
+1
C’est en fait une faille pour ceux qui laisse des comptes comme test, password : test
Franchement le brute force SSH faut vraiment le vouloir pour se faire avoir.
Rien de neuf sous le soleil.
Le 23/05/2022 à 15h34
Qui laisse un serveur ssh avec authentification par mot de passe et pas uniquement par clef ssh ?
Le 23/05/2022 à 16h32
JVachez.
Le 23/05/2022 à 17h14
J’allais le dire.
C’est parmi les règles du B-A BA de la sécurité. Pas de ssh root, authentification par clé uniquement.
Ben qu’ils pleurent pas s’ils se font défoncer comme s’ils avaient un Oracle dont ils n’avaient pas compris que dans “changeoninstall” il y avait une directive.
Le 23/05/2022 à 16h04
Je dirais tout ceux qui créent un kublet pour voir si “ca marche”… et quand ca marche, ils ne touchent plus à rien.
Le 23/05/2022 à 21h24
@Cumbalero: Encore faut-il savoir mettre en place une clef d’autentification.
Perso, j’utilise un mot de passe fort non Root et un 2fa top et des adresses IP dédiées.
Le 24/05/2022 à 05h45
Une commande sur le client pour générer la clé (allez, 2 si on la protège correctement) et une sur le serveur pour charger la clé publique, il faut vraiment le vouloir pour pas y arriver…
Mais c’est vrai que ça vaut la peine que ssh ait une option pour automatiser ça encore plus. Exemple si je fais ssh –genkey user@server, il utilise la clé si elle existe, sinon en crée une et l’installe dans authorized keys (après avoir demandé le password, évidemment).
Maintenant reste le problème de pouvoir mettre en place une clé.
Sur un IoT je n’y crois pas, sur un serveur géré par l’IT je conçois qu’ils soient frileux: la sécurité d’un password serveur dépend de l’administrateur IT, la sécurité de la clé privée dépend de l’utilisateur final; s’il ne met pas de pw dessus, c’est openbar en cas de leak.
Le 24/05/2022 à 17h11
Dans certains cas, j’utilise la bonne vieille méthode du login+passe, après il y a un fail2ban sur le serveur pour éviter les attaques.
Faudrait que je regarde si quelqu’un a fini par ajouter une option dans SSH du style “pas plus de N tentatives de connexion par seconde - ou par minute”, en retenant les 100 ou 1000 dernières IP qui ont échoué à s’authentifier.
(ou même plus de 1000 à tout hasard, sachant que ça ne va pas prendre des masses de mémoires de conserver ça)
Le 24/05/2022 à 17h21
“Dans certains cas”, ça manque un peu de précision.
Le 24/05/2022 à 17h26
Mon PC perso déjà, depuis une vingtaine d’années :-) .
Détail (ou pas), la connexion en root est désactivée, enfin c’est par défaut depuis longtemps me semble.
Le 24/05/2022 à 20h34
Certes, mais pourquoi ?
Le 24/05/2022 à 22h34
Ben parce que c’est plus simple et que ça fonctionne :-) .
Et je peux me connecter depuis n’importe où facilement à partir du moment où j’ai un client SSH, même depuis un simple Mac (avec le terminal puisque c’est de l’Unix en-dessous).
Je me sers aussi d’authentification SSH par clé quand c’est utile (connexions automatisées par exemple, ou des “scp” qui sont en batch).
Le 25/05/2022 à 13h31
Je ne me connecte plus en ssh depuis une machine inconnue depuis que j’ai un client ssh et ma clef sur mon téléphone. Ça doit bien faire dix ans.
Le 25/05/2022 à 14h39
J’ai un client SSH sur mon Android depuis des années, mais si j’ai un ordi sous la main, mon mobile reste dans ma poche. Je trouve ça pénible de taper sur mobile alors que je tape super vite sur un clavier et sans regarder (sans parler du confort de lecture et du copier-coller facile sur ordi).
Le 25/05/2022 à 17h16
Dans “certains cas”, “il me semble”.
Je comprends pas, ca manque effectivement de précision.
C’est quoi ces approximations monsieur Je Sais Tout ?