Microsoft se penche sur XorDdos, cheval de Troie Linux qui cible l'IoT et Docker

Microsoft se penche sur XorDdos, cheval de Troie Linux qui cible l’IoT et Docker

Microsoft se penche sur XorDdos, cheval de Troie Linux qui cible l'IoT et Docker

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 ».

Commentaires (20)


Alors pour une fois que c’est une attaque sur les systemes linux, pourquoi une image centree sur microsoft ? Pour dire qu’ils compatissent ? :D


Il faudra m’expliquer comment



"Defenders can apply the following mitigations to reduce the impact of this threat:

Encourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
Use device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for Endpoint.
Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to use cloud-based machine learning protections that can block a huge majority of new and unknown variants.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode.
Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume. "


permet de lutter contre



"XorDdos is known for using Secure Shell (SSH) brute force attacks to gain remote control on target devices."


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.


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)


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).


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…


+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.


Qui laisse un serveur ssh avec authentification par mot de passe et pas uniquement par clef ssh ?


JVachez.:D


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.



(quote:2074144:alex.d.)
Qui laisse un serveur ssh avec authentification par mot de passe et pas uniquement par clef ssh ?




Je dirais tout ceux qui créent un kublet pour voir si “ca marche”… et quand ca marche, ils ne touchent plus à rien.


@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.



wanou a dit:


@Cumbalero: Encore faut-il savoir mettre en place une clef d’autentification.




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.



(quote:2074144:alex.d.)
Qui laisse un serveur ssh avec authentification par mot de passe et pas uniquement par clef ssh ?



(quote:2074155:127.0.0.1)
Je dirais tout ceux qui créent un kublet pour voir si “ca marche”… et quand ca marche, ils ne touchent plus à rien.



Cumbalero a dit:


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.



wanou a dit:


@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.




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)



OlivierJ a dit:


Dans certains cas, j’utilise la bonne vieille méthode du login+passe,




Dans certains cas”, ça manque un peu de précision.


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.


OlivierJ

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.


Certes, mais pourquoi ?


alex.d.

Certes, mais pourquoi ?


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).


OlivierJ

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).


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.


alex.d.

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.


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).



OlivierJ a dit:


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.




Dans “certains cas”, “il me semble”.



Je comprends pas, ca manque effectivement de précision.



C’est quoi ces approximations monsieur Je Sais Tout ?


Fermer