Discussion :

[Olivier Famien]

Le malware XDOR.DDOS refait surface sur la plateforme Linux
et gagne en complexité selon les architectures

Depuis septembre 2014, Linux fait face à un type d’attaques d’un genre nouveau. En effet, c’est à cette date que le blog Malware Must Die a publié sa découverte qui, force est de constater, ne ressemble en rien aux mawlawres habituels auxquels on a l’habitude de faire face.

Appelé XOR.DDOS, ce dernier utilise des attaques DDOS qui sont des attaques par déni de service ayant pour but de rendre indisponible un service ou d’empêcher l’accès à celui-ci en raison de sa persistance. Depuis quelques jours, XOR.DDOS a été à nouveau détecté par FireEye.

Cette fois, il semble beaucoup plus complexe, car en plus d’utiliser une technique d’attaque par force brute SSH, ce malware est capable de s’exécuter en fonction de l’architecture Linux à laquelle il est confronté. Ainsi plusieurs compilations ont été détectées sur le réseau et s’adressent à différentes architectures Linux (AMD64, x86, ARM…). Les supports les plus vulnérables sont les systèmes embarqués et les objets connectés. FireEye souligne qu’il est écrit en C/C++ contrairement aux malwares usuels qui sont conçus avec des langages de haut niveau. Nous comprenons pourquoi il est si véloce. Cela dénote également de la volonté d’infecter à un très bas niveau les systèmes Linux.

XOR.DDOS lance son attaque brute force SSH à partir d’une adresse enregistrée sous le nom Hee Thai. Ces attaques sont exécutées de manière persistante jusqu’à ce qu’elles puissent avoir accès au compte root du système. Une fois le système infecté, la machine abritant l’adresse citée arrête l’attaque et se déconnecte. Une autre machine avec une IP différente se connecte à partir d’une commande distante SSH et vu que les serveurs OpenSSH ne créent pas de journal pour les accès distants même quand celui-ci est configuré en mode détaillé, l’infiltration est donc invisible. C’est une attaque très élaborée avec des scripts Shell d’une taille considérable. Les images étant plus parlantes, ci-dessous un schéma descriptif.

Pour s’en prémunir ou plutôt pour contenir les attaques avant qu’une nouvelle compilation ne pointe le nez, il est recommandé de désactiver les accès distants du compte root (chose qui devrait être fait systématiquement). Le serveur SSH doit être également configuré pour n’accepter que les clés chiffrées. Il est enfin souhaitable d’installer un utilitaire réseau de détection des attaques par force brute (par exemple, fail2ban), ce qui permettra de prévenir les intrusions dès qu’une attaque est lancée. Toutefois, nous précisons que dès que le système est infecté, aucun outil ne permet à l’heure actuelle de se débarrasser de l’infection.

Source : Malware must Die, FireEye

Et vous ?

Que pensez-vous de ces attaques ?
Qui pourrait véritablement en être l'auteur ?

[rupteur]

Pour s’en prémunir ou plutôt pour contenir les attaques avant qu’une nouvelle compilation ne pointe le nez, il est recommandé de désactiver les accès distants du compte root. Le serveur SSH doit être également configuré pour n’accepter que les clés chiffrées. Il est enfin souhaitable d’installer un utilitaire réseau de détection des attaques par force brute, ce qui permettra de prévenir les intrusions dès qu’une attaque est lancée.

C'est quand même la base non ?
Fail2ban pour contrer les attaques brutes et PermitRootLogin =no pour le ssh (changer en plus, le port 22 en "autre chose")

[23JFK]

Sauf que les objets connectés, (et parfois, certaines machines plus complexes de type desktop, serveurs, routeurs...) fonctionnent souvent avec une configuration de type mono-utilisateur qui ne peut être autre que le superuser. Et il n'est alors pas toujours possible de personnaliser les configurations de ces appareils sous peine de les rendre inutilisables.

[rupteur]

Sauf que 'quelque chose' qui se connecte plusieurs fois avec un mauvais mot de passe ce n'est quand même pas normal.

[Nairolf21]

Ce genre de malware m'inquiète un peu, même si je me dis que statistiquement, il n'y a peu de chances d'en être victime

Pour certains d'entre vous (rupteur), ce genre de recommandations expliquées ici semblent aller de soi, et d'être de l'ordre de l'évidence. Mais pour moi par exemple qui ne suis sur Linux que depuis récemment, je ne sais pas comment configurer mon port ssh, et je n'ai jamais mis en place fail2ban. Devrais-je l'avoir mis ?

Si ce genre de chose semble être évidente, pourquoi ne sont-elles pas configurés par défaut sur une installation d'Ubuntu, par exemple (Xubuntu, dans mon cas précis) ?

[AoCannaille]

Il me semble que sur la version desktop d'ubuntu (la "normale" donc, la version serveur est souvent délaissée pour une debian pure) le serveur ssh est désactivé par défaut. Encore plus sécurisé

[Tryph]

Si ce genre de chose semble être évidente, pourquoi ne sont-elles pas configurés par défaut sur une installation d'Ubuntu, par exemple (Xubuntu, dans mon cas précis) ?

sur Xubuntu, je pense pas qu'un serveur ssh soit installé par défaut.
donc pas de souci.

Sauf que les objets connectés, (et parfois, certaines machines plus complexes de type desktop, serveurs, routeurs...) fonctionnent souvent avec une configuration de type mono-utilisateur qui ne peut être autre que le superuser. Et il n'est alors pas toujours possible de personnaliser les configurations de ces appareils sous peine de les rendre inutilisables.

j'ai souvent vu le compte "admin" (avec en général un mot de passe par défaut = "admin", ce qui est tellement malin...) sur les objet connectés, rarement (jamais?) le compte "root".

[MikeRowSoft]

Pourvu que les systèmes d'exploitations virtualisés ne soit pas une ouverture pour une infection plus sérieuse de tout un système de virtualisation. L'authentification étant légitime (mais pas légale) même forcé les outils antivirus (même au niveau des CPU) ne peuvent pas grand chose. Vraiment astucieux se malware.

[elssar]

Ce genre de malware m'inquiète un peu, même si je me dis que statistiquement, il n'y a peu de chances d'en être victime

Pour certains d'entre vous (rupteur), ce genre de recommandations expliquées ici semblent aller de soi, et d'être de l'ordre de l'évidence. Mais pour moi par exemple qui ne suis sur Linux que depuis récemment, je ne sais pas comment configurer mon port ssh, et je n'ai jamais mis en place fail2ban. Devrais-je l'avoir mis ?

Si ce genre de chose semble être évidente, pourquoi ne sont-elles pas configurés par défaut sur une installation d'Ubuntu, par exemple (Xubuntu, dans mon cas précis) ?

Salut,

La partie client de openssh est installée par défaut sous ubuntu tu peux check en faisant ssh -V. Par contre pour la partie serveur il faut installer le paquet. Il n'est pas donc possible de se co sur toi par défaut. Après si tu installes openssh dans son intégralité, oui il y a des mesures à prendre mais parfois il faut aller aussi au bout des choses. Quel intérêt de prendre une distrib linux, si tu ne l'utilises pas à son plein potentiel ?

Je prends l'exemple de fail2ban c'est un paquet très facile à installer. Après oui il faut config l'envoie de mail (éventuellement), ça demande quelques très légères connaissances de smtp, mais rien de très compliqué.

Mais je pense que c'est pas bon de mâcher le travail des gens. C'est important de comprendre les choses, si tu installes de base toutes les mesures de sécurités, comment veut tu les comprendre ? Alors que si tu config par toi même, normalement tu comprendra leurs intérêts, par exemple déplacer le port 22 pour éviter les bruteforce génériques.

[Beanux]

OU alors si on est pas aidé de ses 10 doigts, ou qu'on a pas la possibilité d'interdire le compte root (ou de passer par une clé), on change le port ssh (de préférence un port non commun).

Certes c'est pas la panacée, ça ne remplace pas la sécurisation du serveur, mais ça reste assez simple pour déjouer les scan de ce type.

[DarkHylian]

C'est quand même la base non ?
Fail2ban pour contrer les attaques brutes et PermitRootLogin =no pour le ssh (changer en plus, le port 22 en "autre chose")

Un de mes profs en admin sys, il y a longtemps, me disait que fail2ban (que j'utilise en parcimonie) est une fausse solution.
Je n'avais pas vraiment compris pourquoi à l'époque.

Maintenant, je commence à voir le pourquoi du comment :
Si tu utilise des chaînes de proxy, ou que tu t'amuse à émettre des requêtes avec des IPs différentes, f2b ne sert à rien, à part bloqué je ne sais combien d'IP derriere (et donc si quelque de légitime veut se connecter en passant par un proxy parce qu'il ne peut pas faire autrement, ben il peut pas)(est-ce que le vpn serait une solution dans ce cas ? ).

Du coup, je vois la chose comme ça : f2b ne sert qu'à "verrouiller" provisoirement des accès anormaux, mais ça n'empêche pas, et je dirais mieux, ça incite à augmenter le niveau de protection du poste.
Quand on active f2b, je pense qu'il faut se demander "pourquoi on l'active", "quel faille on essaye de combler", et "combien de temps on compte le laisser" (ça a au moins le mérite de se fixer un objectif).
Et faire en sorte que f2b ne reste actif que le temps de combler les failles en question, car de toute façon, lui-même ne permet pas de s'en prémunir.

Bon, c'est juste mon avis, et je pense qu'il y a plus avisé que moi.
D'ailleurs, si vous avez des bonnes infos en termes de sécurité de serveur, je serai ravi de m'en inspirer, parce que ça commence à faire un petit moment que mon pti serveur privé se sent traversé par des courants d'air.

[EDIT]
En relisant l'article, je vois que "OpenSSH ne génère pas de journal blablabla" ... mais il me semble que, dans le monde Unix/Linux/Bsd, on peut paramétrer quelque part la possibilité d'enregistrer un journal pour toutes les connexions effectuées vers le serveur, quelque soit le port et le service ciblé. Je me trompe ?

[DarkHylian]

Sauf que 'quelque chose' qui se connecte plusieurs fois avec un mauvais mot de passe ce n'est quand même pas normal.

Ça peut être toi, bourré en soirée, qui essaye de te connecter sans te souvenir de ton pass depuis un poste qui ne t'appartient pas (c'est la raison du down, y'a pas de méchanceté ni de malice là dedans)

[rupteur]

Ça peut être toi, bourré en soirée, qui essaye de te connecter sans te souvenir de ton pass depuis un poste qui ne t'appartient pas (c'est la raison du down, y'a pas de méchanceté ni de malice là dedans)

Ben justement, si je suis pas capable de saisir mon mot de passe, il vaut mieux que le système me bloque

de plus fail2ban permet de ne bloquer qu'un certain temps. (le temps de décuver par exemple...)

[monwarez]

En relisant l'article, je vois que "OpenSSH ne génère pas de journal blablabla" ... mais il me semble que, dans le monde Unix/Linux/Bsd, on peut paramétrer quelque part la possibilité d'enregistrer un journal pour toutes les connexions effectuées vers le serveur, quelque soit le port et le service ciblé. Je me trompe ?

Effectivement avec un firewall, on peut avoir un log des connections faites ,le problème serait juste que l'on ne saurait pas forcément distinguer les connections avec succés de celles sans succés(au sens de combinaison utilisateur/mot de passe correctes), à moins d'utiliser un sniffeur réseau(ou autre type d'analyseur réseau) pour sauvegarder tous les paquets à destination du serveur OpenSSH, et encore il faut pouvoir les dechiffrer s'ils le sont.