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.
--
ewx.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
