Windigo : des milliers de serveurs Linux piratés pour infecter

Le par  |  27 commentaire(s)
serveur facebook

Une opération cybercriminelle toujours en cours a compromis une dizaine de milliers de serveurs UNIX et Linux avec un cheval de Troie. Spam et malwares menacent les internautes.

Depuis au moins 2011 et une première alerte avec la compromission de serveurs de la Linux Foundation, une opération cybercriminelle baptisée Windigo est passée sous les radars de détection.

serveursSelon un rapport publié par ESET et en collaboration avec plusieurs agences nationales de sécurité, plus de 25 000 serveurs UNIX et Linux ont été compromis à un moment donné par un cheval de Troie et transformés en une véritable plateforme de diffusion de spam et malwares. Rien de moins que 35 millions de messages de spam par jour. Quelque 10 000 serveurs seraient encore sous le contrôle de Windigo.

Le constat est pour le moins inquiétant, d'autant que de l'ordre de 60 % des sites Web dans le monde sont hébergés sur un serveur Linux. ESET note que plus de 700 serveurs Web dirigent actuellement les internautes vers du contenu malveillant.

La menace pour l'internaute qui consulte un site infecté prend diverses formes en fonction du système d'exploitation qu'il utilise. Pour Windows, c'est le risque d'une installation d'un malware, tandis que pour OS X, Windigo préfère afficher des publicités pour des sites de rencontres. Même l'iPhone n'est pas oublié avec une redirection vers des contenus pornographiques.

Le but recherché par les cybercriminels peut être le vol de données personnelles et manifestement l'intention de gagner de l'argent.

Afin de compromettre les serveurs, les attaquants ont eu recours à une backdoor OpenSSH dénommée Ebury qui est installée manuellement par des cybercriminels. Ils ont donc tiré parti de mauvaises configurations et d'un manque de contrôles de sécurité après des vols d'identifiants. L'implémentation d'une solution d'authentification forte aux serveurs aurait pu faire barrage.

ESET précise en tout cas qu'il ne s'agit pas ici d'exploiter une vulnérabilité de Linux ou des outils libres pour des communications sécurisées utilisant le protocole SSH.

Aux administrateurs systèmes sous UNIX et aux webmasters, ESET recommande d'exécuter une commande afin de vérifier une compromission ou non :

$ ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System clean" || echo "System infected"

Le cas échéant, ni plus ni moins qu'un formatage et une réinstallation doivent être envisagés...

" Nous sommes conscients que formater votre serveur et repartir de zéro est un traitement radical. Mais, si des hackers sont en possession d'un accès distant à vos serveurs suite au vol de vos identifiants administrateur, il ne faut prendre aucun risque "

, commente Marc-Etienne Léveillé, chercheur en sécurité chez ESET.

Il ajoute :

" Malheureusement, certaines victimes avec qui nous sommes en contact savent qu'elles sont infectées mais n'ont pour l'instant rien fait pour nettoyer leurs systèmes mettant ainsi en danger toujours plus d'internautes. "

Complément d'information

Vos commentaires Page 1 / 3

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1689022
" Nous sommes conscients que formater votre serveur et repartir de zéro est un traitement radical. Mais, si des hackers sont en possession d'un accès distant à vos serveurs suite au vol de vos identifiants administrateur, il ne faut prendre aucun risque "

entièrement d'accord.
Le #1689042
Que vient faire secure shell dans les serveurs web ? Je ne vois pas comment ça peut marcher ni comment ça peut envoyer des spams. De toutes façons, je désactive systématiquement ssh, rlogin et autre telnet, etc... sur mes serveurs.
Le #1689052
penseurodin a écrit :

Que vient faire secure shell dans les serveurs web ? Je ne vois pas comment ça peut marcher ni comment ça peut envoyer des spams. De toutes façons, je désactive systématiquement ssh, rlogin et autre telnet, etc... sur mes serveurs.


et tu t'y connecte comment ?
Le #1689072
<TROLL>
Vous vous êtes trompés : Vous avez écrit "serveurs UNIX sous Linux" alors que ce doit être "serveurs Windows". Non ?

Ah bon...
</TROLL>

Ca fait du bien d'inverser les rôles de temps en temps. Même si on est pas vendredi
Le #1689202
FredPG a écrit :

penseurodin a écrit :

Que vient faire secure shell dans les serveurs web ? Je ne vois pas comment ça peut marcher ni comment ça peut envoyer des spams. De toutes façons, je désactive systématiquement ssh, rlogin et autre telnet, etc... sur mes serveurs.


et tu t'y connecte comment ?


Normalement, on n'est pas forcé de se connecter à distance. C'est même fortement déconseillé.
Le #1689212
Le 1er Avril est plus tot cette annee?

Etant donne que la commande ssh -G n'existe pas (man ssh), c'est normal que ce script envoi un message "System infected".

Le #1689312
penseurodin a écrit :

FredPG a écrit :

penseurodin a écrit :

Que vient faire secure shell dans les serveurs web ? Je ne vois pas comment ça peut marcher ni comment ça peut envoyer des spams. De toutes façons, je désactive systématiquement ssh, rlogin et autre telnet, etc... sur mes serveurs.


et tu t'y connecte comment ?


Normalement, on n'est pas forcé de se connecter à distance. C'est même fortement déconseillé.


Et ton serveur web, tu l'administres comment? avec un phpmyadmin? parceque niveau sécurité, c'est vraiment pas du tout terrible.

pour sécuriser ssh, c'est assez simple: désactiver la possibilité de se logger en root, ne pas permettre l'authentification par login/mot de passe qui ne résistera pas à un bruteforce, mais utiliser des clefs RSA 4096 bits asymétriques + une passphrase costaud (en cas de vol de laptop avec les clefs en question dessus… ). Ça prend en tout et pour tout 5 minutes:

- générer ses clefs rsa avec ssh-keygen. copier les clefs publiques en question sur le serveur.
- éditer le fichier /etc/ssh/sshd.config
- Premièrement, changer le port d'écoute du serveur ssh (22 par défaut, bien connu)
- PermitRootLogin no # NO, NO, NO, NEVER!!
- RSAAuthentication yes
- PubkeyAuthentication yes
- HostbasedAuthentication no
- PasswordAuthentication no #NO, NO, NEVER.
- UseLogin no # NO,NO,NO, NEVER!

Ça doit bien faire 10 ans que j'utilise ssh, et personne ne m'a jamais pété un de mes serveurs - je me marre en regardant les logs, avec quelques bots qui tentent des login/mot de passe rigolos comme tout, comme par exemple "phpmyadmin", "mysql", "cornflakes", "admin", "root" et qui se font jeter comme des malpropres car l'identification est basée sur une clef asymétrique bien complexe.

Pour secure encore un peu, fail2ban et/ou quelques règles iptables bien senties: je me contrefiche de dropper la moitié de la planète par /8 entiers s'ils tentent de se logger sans la bonne clef et sans la bonne passphrase.
Le #1689322
Tux15 a écrit :

Le 1er Avril est plus tot cette annee?

Etant donne que la commande ssh -G n'existe pas (man ssh), c'est normal que ce script envoi un message "System infected".


bah d un autre cote ca vient d un vendeur d antivirus, cest dans son interet que tous les systemes renvoient " system infected".

meme le mien renvoie le message !!
Le #1689332
lidstah a écrit :

penseurodin a écrit :

FredPG a écrit :

penseurodin a écrit :

Que vient faire secure shell dans les serveurs web ? Je ne vois pas comment ça peut marcher ni comment ça peut envoyer des spams. De toutes façons, je désactive systématiquement ssh, rlogin et autre telnet, etc... sur mes serveurs.


et tu t'y connecte comment ?


Normalement, on n'est pas forcé de se connecter à distance. C'est même fortement déconseillé.


Et ton serveur web, tu l'administres comment? avec un phpmyadmin? parceque niveau sécurité, c'est vraiment pas du tout terrible.

pour sécuriser ssh, c'est assez simple: désactiver la possibilité de se logger en root, ne pas permettre l'authentification par login/mot de passe qui ne résistera pas à un bruteforce, mais utiliser des clefs RSA 4096 bits asymétriques + une passphrase costaud (en cas de vol de laptop avec les clefs en question dessus… ). Ça prend en tout et pour tout 5 minutes:

- générer ses clefs rsa avec ssh-keygen. copier les clefs publiques en question sur le serveur.
- éditer le fichier /etc/ssh/sshd.config
- Premièrement, changer le port d'écoute du serveur ssh (22 par défaut, bien connu)
- PermitRootLogin no # NO, NO, NO, NEVER!!
- RSAAuthentication yes
- PubkeyAuthentication yes
- HostbasedAuthentication no
- PasswordAuthentication no #NO, NO, NEVER.
- UseLogin no # NO,NO,NO, NEVER!

Ça doit bien faire 10 ans que j'utilise ssh, et personne ne m'a jamais pété un de mes serveurs - je me marre en regardant les logs, avec quelques bots qui tentent des login/mot de passe rigolos comme tout, comme par exemple "phpmyadmin", "mysql", "cornflakes", "admin", "root" et qui se font jeter comme des malpropres car l'identification est basée sur une clef asymétrique bien complexe.

Pour secure encore un peu, fail2ban et/ou quelques règles iptables bien senties: je me contrefiche de dropper la moitié de la planète par /8 entiers s'ils tentent de se logger sans la bonne clef et sans la bonne passphrase.


comme d hab la faille est dans l interface chaise clavier...

on pourra creer le systeme d exploitation parfait, si il y a un ane aux manettes...
Le #1689362
lidstah a écrit :

penseurodin a écrit :

FredPG a écrit :

penseurodin a écrit :

Que vient faire secure shell dans les serveurs web ? Je ne vois pas comment ça peut marcher ni comment ça peut envoyer des spams. De toutes façons, je désactive systématiquement ssh, rlogin et autre telnet, etc... sur mes serveurs.


et tu t'y connecte comment ?


Normalement, on n'est pas forcé de se connecter à distance. C'est même fortement déconseillé.


Et ton serveur web, tu l'administres comment? avec un phpmyadmin? parceque niveau sécurité, c'est vraiment pas du tout terrible.

pour sécuriser ssh, c'est assez simple: désactiver la possibilité de se logger en root, ne pas permettre l'authentification par login/mot de passe qui ne résistera pas à un bruteforce, mais utiliser des clefs RSA 4096 bits asymétriques + une passphrase costaud (en cas de vol de laptop avec les clefs en question dessus… ). Ça prend en tout et pour tout 5 minutes:

- générer ses clefs rsa avec ssh-keygen. copier les clefs publiques en question sur le serveur.
- éditer le fichier /etc/ssh/sshd.config
- Premièrement, changer le port d'écoute du serveur ssh (22 par défaut, bien connu)
- PermitRootLogin no # NO, NO, NO, NEVER!!
- RSAAuthentication yes
- PubkeyAuthentication yes
- HostbasedAuthentication no
- PasswordAuthentication no #NO, NO, NEVER.
- UseLogin no # NO,NO,NO, NEVER!

Ça doit bien faire 10 ans que j'utilise ssh, et personne ne m'a jamais pété un de mes serveurs - je me marre en regardant les logs, avec quelques bots qui tentent des login/mot de passe rigolos comme tout, comme par exemple "phpmyadmin", "mysql", "cornflakes", "admin", "root" et qui se font jeter comme des malpropres car l'identification est basée sur une clef asymétrique bien complexe.

Pour secure encore un peu, fail2ban et/ou quelques règles iptables bien senties: je me contrefiche de dropper la moitié de la planète par /8 entiers s'ils tentent de se logger sans la bonne clef et sans la bonne passphrase.


Coté soft, on se fournit chez Apache, le tout-venant c'est du httpd, le sensible c'est du httpCore. Pas de ssh, ni admin à distance.
Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]