Bonjour a tous;
Petit retour d'exp. inline.
Eric ROLLAND - Wed, 14 Jan 2015 :
Le 13/01/2015 14:11, Eric ROLLAND a écrit :
Il y a eu bien plus violent cette année : https://www.drupal.org/SA-CORE-2014-005
Cette faille a ete corrigee "rapidement" chez nous; pour autant sur ~ 80% des drupaux concernes, un compte admin avait ete cree avec le nom 'us2_admin'; il semble qu'un (ensemble de)? bot(s) soit rapidement passe un peu par tout, au vu de l'ampleur des resultats retournes par google par exemple:
https://www.google.fr/search?q=us2_admin
En consequence, ca peut etre interessant de regarder si un tel compte existe ;)
La vague d'exploitation recente de CMS pourtant a jour n'a *pas* exploite ces comptes-ci pour autant.
Concernant les sites d'administrations territoriales concernes par les attaques recentes, j'ai vu "seulement" deux modus operandi.
Le premier est trivial, site wordpress (typiquement) utilisant des plugins vulnerables, exploitation directe, en general suivi d'un ecrasement de l'index.php.
Le second un peu plus "evolue", et concerne generalement des drupal a jour: * Tentative d'attaque frontale sur les drupals via SA-CORE-2014-005 (patched, donc fail). * Les attaquants recuperent une liste de VHosts definis sur le serveur qui heberge la cible (google donne ca aisement) * Les attaquants essayent un set de failles connues (comprendre "aucune faille non-documentee n'a ete exploitee dans les cas que j'ai pu avoir sous les yeux") jusqu'a exploiter un des autres sites. * Les attaquants finissent par exploiter un autre site: * Si pas d'isolation, trivial, on upload un petit shell .php[2] sur le site exploite (qui n'est pas la cible) et on lit la conf DB de la cible, on recupere un user/pw/nom de base, et on utilise un autre shell php[3] pour faire l'UPDATE ... set password=... where uid=... qui change le PW admin. * Si isolation type "1 uid par vhost" en suexec/fcgi, un shell PHP n'aurait pas les droits en lecture sur le fichier de conf DB de la vraie cible; on cree donc via PHP un symlink[1] vers / dans le docroot du site exploite, et avec un simple GET on recuper le fichier de conf DB de la cible; puis shell PHP pour changer le MdP admin comme au-dessus. * L'attaquant se logue simplement en admin avec le mot de passe qu'il a lui meme definit et poste son contenu.
Cette approche-ci est "interessante": dans un contexte "d'isolation" typique ("a la mano" ou bundle genre ispconfig et consorts) les logs du vhost compromis montrent juste une IP qui se log en admin, des la premiere tentative, et fait sa petite affaire. Sur un drupal a jour, ca fait un drole d'effet, et ca rappelle fortement la faille < 7.34, donc je comprend qu'on puisse crier au 0day; concernant des Drupal je n'ai remonte "que" deux cas, mais avec chaque fois une explication bien plus terre a terre.
Notes/remarques:
[1] (cf. "indishell") -- A moins d'avoir interdit au serveur web de suivre les symlinks (a condition que les applis ne reposent pas sur le postulat contraire, ce qui est le cas chez certaines helas...), l'UID qui fait tourner les workers du serveur web est generalement membre de chaque groupe d'isolation pour pouvoir lire les statiques, ce qui fait que ce contournement par symlinks reste efficace; une autre solution serait d'avoir tous les .php en 600
[2] + [3] On retrouve toujours les memes shells en l'occurence "xpl.php" et "db2.php".
Par ailleurs, bien que les outils soient les memes, ce qui pourrait laisser penser a un assaillant unique et commun, on a par exemple dans un cas "en direct" une IP source d'un FAI Algerien, dans d'autres cas un assaillant qui a masque son IP derriere un serveur compromis.