Le 13/01/2015 11:33, Pierre Schweitzer a écrit :

Bonjour,

N'oublions pas ces dames non plus ;-).

S'ils visent Drupal notamment, quelqu'un a-t-il un retour d'expérience sur le vecteur utilisé pour l'attaque ? Une CVE ? Autre ?

Bonne journée,

Bonjour, On a vu passer celle là : https://www.drupal.org/SA-CORE-2013-003 Cordialement, Eric ROLLAND AS42929 - RE515-RIPE ------------------------------------------------------------------------ *Artefact communication interactive* | Bat. Artechnopole - 3 rue des Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33 SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z | TVA Intracom FR87444110936 | ORG-ARTE2-RIPE - PGPKEY-32DDEF07 Info réseau : @AS42929 <https://twitter.com/AS42929> - NOC Artewan <https://noc.artewan.net/> *artefact *Communication Interactive www.artefact.fr <http://www.artefact.fr> *artewan* Opérateur de réseaux et de services www.artewan.fr <http://www.artewan.fr> *arteone* Datacenter, Informatique & Services IT www.arteone.fr <http://www.arteone.fr>

Le 13/01/2015 13:46, Simon Morvan a écrit :

Il y a eu bien plus violent cette année : https://www.drupal.org/SA-CORE-2014-005

-- Simon

Bonjour, D'après Zataz, ils vont la sortir du chapeau le 15/01. Cordialement, Eric ROLLAND AS42929 - RE515-RIPE ------------------------------------------------------------------------ *Artefact communication interactive* | Bat. Artechnopole - 3 rue des Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33 SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z | TVA Intracom FR87444110936 | ORG-ARTE2-RIPE - PGPKEY-32DDEF07 Info réseau : @AS42929 <https://twitter.com/AS42929> - NOC Artewan <https://noc.artewan.net/> *artefact *Communication Interactive www.artefact.fr <http://www.artefact.fr> *artewan* Opérateur de réseaux et de services www.artewan.fr <http://www.artewan.fr> *arteone* Datacenter, Informatique & Services IT www.arteone.fr <http://www.arteone.fr>

Le 13/01/2015 14:21, Manu a écrit :

C'est pas la méthode qui est innovante à mon sens, mais plutôt l'ampleur, le nombre de script kiddies des 4 coins du globes qui décident de s'attaquer à des sites français :-)

Bonjour, On a aussi vu un autre serveur d'une agence web dont le drupal était corrompu depuis le 21/12, mais pas encore défacer. Pour la failleutilisée, on sait pas encore.Je pense que peut-etre qu'ils attendent pour activer les trucs qu'ils ont sous le coude... Mais est ce que ZATAZ à raison sur la date, je ne sais pas... Cordialement, Eric ROLLAND AS42929 - RE515-RIPE ------------------------------------------------------------------------ *Artefact communication interactive* | Bat. Artechnopole - 3 rue des Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33 SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z | TVA Intracom FR87444110936 | ORG-ARTE2-RIPE - PGPKEY-32DDEF07 Info réseau : @AS42929 <https://twitter.com/AS42929> - NOC Artewan <https://noc.artewan.net/> *artefact *Communication Interactive www.artefact.fr <http://www.artefact.fr> *artewan* Opérateur de réseaux et de services www.artewan.fr <http://www.artewan.fr> *arteone* Datacenter, Informatique & Services IT www.arteone.fr <http://www.arteone.fr>

On 13/01/2015 15:40, Séb wrote:

On a aussi vu un autre serveur d'une agence web dont le drupal était corrompu depuis le 21/12, mais pas encore défacer. La première vague d'exploitation de cette faille était surtout orientée pour envoyer du spam.

+

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.