La semaine dernière le site Dr Web avertissait les administrateurs système sur l'existence de Linux.Encoder.1, un racketiciel qui crypte de multiples répertoires d'un serveur Linux puis demande une rançon à son administrateur, s'il souhaite récupérer ses fichiers.

Dr Web vient de publier des informations complémentaires au sujet de Linux.Encoder.1. Les cybercriminels derrière ce malware utiliseraient une faille Zero Day du CMS Magento, pour uploader un fichier PHP sur le serveur attaqué.  

Ce fichier est ensuite exécuté via une simple requête HTTP. Il s'exécute à priori avec les droits de l'utilisateur Apache, qui est www-data bien souvent, mais cela dépend bien entendu des spécificités de la configuration du serveur attaqué. Ceci lui donne le droit d'encrypter les fichiers du site courant, au minimum.

Selon Dr Web, 2 000 sites Web sont désormais touchés par Linux.Encoder.1. La semaine dernière, il n'était question que de quelques dizaines. Bien sûr cela ne signifie pas que 2 000 serveurs sont infectés.

En effet, si le serveur n'est pas bien configuré, Linux.Encoder.1 pourra crypter des sites voisins résidant sur le serveur.

Le cas classique se produit lorsque tous les fichiers de tous les sites appartiennent au même utilisateur et groupe (www-data:www-data) et que la directive PHP open_basedir est mal positionnée. Ce qui est très fréquent.

Un cas souvent rencontré également est la faute de configuration majeure consistant à donner aveuglément et sans restriction, ni mot de passe les droits sudo à www-data dans /etc.sudoers :

www-data ALL=NOPASSWD:ALL #JAMAIS CA !!

Ne riez pas ça s'est vu :-) Ce doit être des configurations de ce genre qui ont pu permettre à Linux.Encoder.1 de crypter des répertoires /etc sur des serveurs.

De bonnes précautions à prendre

Pour un minimum de sécurité, chaque site devrait appartenir à un utilisateur différent, et les scripts ne devraient pourvoir s'exécuter qu'avec les droits de cet utilisateur. Ceci peut très facilement s'obtenir avec le module Apache SuExec, ou avec suPHP.

Enfin PHP devrait être configuré de façon à ce que open_basedir soit également limité à la racine des fichiers de chacun des sites. (Et non un open_basedir pointant sur le répertoire racine de tous les hébergements)

Par ailleurs, en attendant que la faille Zero Day supposée de Magento soit corrigée, les administrateurs système pourront trouver pertinent de désactiver tous les modules qui permette d'uploader un fichier sur le serveur du site.