Verrou-anti P2P : les risques autour de JBoss pointés au SSTIC
JBoss démâte
Hasard du calendrier : alors qu’Orange dévoilait une solution de sécurisation anti-P2P basée, côté serveur, sur JBoss, au même moment se tenait le SSTIC, fameux symposium sur la sécurité des technologies de l’information et des communications. Plusieurs intervenants y dévoilent leurs travaux, leurs synthèses de recherche en la matière. Un rendez-vous de qualité auquel participe Orange notamment via les comités organisateurs.
Parmi les différents sujets, on peut ainsi noter les travaux de Renaud Dubourguais Ingénieur diplômé de l'INSA de Rouen qui travaille pour HSC. Son étude a justement porté sur la plateforme JBoss Application Serveur (JBoss AS), celle-là même qu’on découvrira une semaine plus tard en liaison avec le fameux Contrôle de Téléchargement.
L'ennemi Admin/Admin
Ainsi, l’auteur indique : « Là où le problème des comptes par défaut a été corrigé pour Tomcat dans les versions récentes, pour JBoss les interfaces d'administration ne sont même pas protégées par défaut. Lorsqu'elles le sont, le compte trivial admin/admin est créé pour peu que les administrateurs n'aient pas pensé à le modifier. » Le chercheur ne devait pas se douter que 2 jours plus plus tard, ses prédictions se vérifiaient grandeur nature. Car ce fut exactement le cas pour la partie serveur du Contrôle du Téléchargement : d'après les témoignages de plusieurs internautes (voir également sur TheInternets) qui se sont penchés dessus, le couple admin/admin avait bien été laissé par défaut sur le serveur du verrou anti-P2P.
Dans les documents présentant ses recherches dans l'écosystème JBoss, le chercheur souligne alors un train de risques importants : « Un attaquant ayant accès à l'une de ces interfaces peut récupérer de nombreuses informations concernant le serveur, modifier la configuration « à chaud » voir même déployer ses propres applications web sur le serveur (webshells) lui permettant d'asservir totalement le serveur (y compris le système d'exploitation) à ses besoins. Une fois cet objectif atteint, libre à l'attaquant de rebondir sur d'autres systèmes... »
On le comprend : autant attaques « qui peuvent se révéler désastreuses pour une entreprise (vol de données clients, compromission d'une multitude d'équipements via le JBoss, rebond sur un système étranger mettant en cause la responsabilité de l'entreprise...) » Prédictions là encore validées : hier, un post dans la liste full disclosure répertoriait d’importantes failles dans le Centre de téléchargement conduisant à l'élévation de privilège d'un utilisateur sans droit, et d'autres attaques d'importance sur la partie serveur. Et le billet sur cette fameuse liste promet encore d'autres découvertes ces prochains jours...
On pourra lire l’intégralité des travaux de Renaud Dubourguais sur ce lien (avec les slides sur ce lien).
Parmi les différents sujets, on peut ainsi noter les travaux de Renaud Dubourguais Ingénieur diplômé de l'INSA de Rouen qui travaille pour HSC. Son étude a justement porté sur la plateforme JBoss Application Serveur (JBoss AS), celle-là même qu’on découvrira une semaine plus tard en liaison avec le fameux Contrôle de Téléchargement.
L'ennemi Admin/Admin
Ainsi, l’auteur indique : « Là où le problème des comptes par défaut a été corrigé pour Tomcat dans les versions récentes, pour JBoss les interfaces d'administration ne sont même pas protégées par défaut. Lorsqu'elles le sont, le compte trivial admin/admin est créé pour peu que les administrateurs n'aient pas pensé à le modifier. » Le chercheur ne devait pas se douter que 2 jours plus plus tard, ses prédictions se vérifiaient grandeur nature. Car ce fut exactement le cas pour la partie serveur du Contrôle du Téléchargement : d'après les témoignages de plusieurs internautes (voir également sur TheInternets) qui se sont penchés dessus, le couple admin/admin avait bien été laissé par défaut sur le serveur du verrou anti-P2P.
Dans les documents présentant ses recherches dans l'écosystème JBoss, le chercheur souligne alors un train de risques importants : « Un attaquant ayant accès à l'une de ces interfaces peut récupérer de nombreuses informations concernant le serveur, modifier la configuration « à chaud » voir même déployer ses propres applications web sur le serveur (webshells) lui permettant d'asservir totalement le serveur (y compris le système d'exploitation) à ses besoins. Une fois cet objectif atteint, libre à l'attaquant de rebondir sur d'autres systèmes... »
On le comprend : autant attaques « qui peuvent se révéler désastreuses pour une entreprise (vol de données clients, compromission d'une multitude d'équipements via le JBoss, rebond sur un système étranger mettant en cause la responsabilité de l'entreprise...) » Prédictions là encore validées : hier, un post dans la liste full disclosure répertoriait d’importantes failles dans le Centre de téléchargement conduisant à l'élévation de privilège d'un utilisateur sans droit, et d'autres attaques d'importance sur la partie serveur. Et le billet sur cette fameuse liste promet encore d'autres découvertes ces prochains jours...
On pourra lire l’intégralité des travaux de Renaud Dubourguais sur ce lien (avec les slides sur ce lien).
Marc Rees
le 16 juin 2010 à 17:10
(19 756
lectures)
Actualités et brèves relatives
- 15 / 06 / 2010 : Full Disclosure : le logiciel anti P2P d’Orange souffrirait d'une ...
- 15 / 06 / 2010 : Verrou Orange : une anticipation d'Hadopi sans lien avec Hadopi
- 15 / 06 / 2010 : Orange présente son verrou anti-P2P comme un antivirus
- 15 / 06 / 2010 : Orange se dit victime d’un piratage, cache le lien vers son verrou ...
- 14 / 06 / 2010 : Hadopi et le verrou Orange, tout était déjà écrit voilà deux ans
- 14 / 06 / 2010 : Hadopi : le verrou Orange déjà déverrouillé
- 14 / 06 / 2010 : Le verrou Orange-Hadopi accusé de négligence caractérisée
- 11 / 06 / 2010 : Hadopi : le logiciel de sécurisation version Orange bloque le P2P
