Från XSS till root på apache.org

För lite mer än en vecka sedan blev Apache.org hackade. Nu berättar de på sin blogg vad som hände i detalj. En cross-site scripting-bugg i ärendehanteringssystemet ledde slutligen till root-access och nedladdning av lösenordsdatabaserna.

OBS! Om du har ett konto på Apache:s JIRA, Bugzilla eller Confluence så bör du byta lösenord nu. Om du har haft samma lösenord på andra ställen så byt dem med.

1) XSS, en skakning på nedre däck

Attackerarna hade upptäckt en cross-site scripting-bugg (XSS) i ärendehanteringssystemet JIRA. Man får förmoda att det var en reflekterad XSS eftersom de lurade Apache-admins att klicka på en Tinyurl, en minifierad länk, för ett fejkat ärende:

"ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX"

Länken omvandlades till en reflekterad XSS som stal deras sessions-kaka, så kallad session hijacking.

2) Adminkonto till JIRA, ladda upp jsp-sidor som projektbilagor

Till slut så kom de förstås över ett adminkonto till Apache:s JIRA. Väl där så stängde de av notifieringarna för ett projekt och ändrade projektets uppladdningskatalog till en katalog som innehöll körbara jsp-sidor. Sen skapade de en massa ärenden till det projektet och bifogade bland annat en jsp som tillät access till filsystemet för att ladda ner alla home-kataloger och en jsp-bakdörr för inlogging med JIRA-applikationens rättigheter.

3) Byta ut en jar för att samla lösenord

I nästa steg lyckades attackerarna installera en ny jar för att samla in användaruppgifter. För att snabbt få in en stor uppsättning lösenord så skickade de ut password reset-mejl till Apache-teamet. Team-medlemmarna förmodade att det var en bugg i JIRA, loggade in med det temporära lösenordet och återställde sitt ursprungliga lösenord.

4) Root-login på servern

Minst ett av de insamlade JIRA-lösenorden var samma som till ett motsvarande användarkonto på själva servern -- ett konto med root-access. Nu hade attackerarna full tillgång till servern som körde JIRA, Bugzilla och Confluence.

5) Access till kod-repositories

Flera av användarna på den nu ägda servern hade chache:ade Subversion-lösenord. På det sättet kom attackerarna vidare till servern med källkods-repositories. Ungefär där, fyra dagar efter XSS-attacken fick Apache stopp på dem och kunde börja undersöka skadorna.

Tankar

Konfigurationen av de här systemen och servrarna låter inte ovanlig i mina öron. Inte heller känns det som att användarna som klickade på det där ärendet gjorde något särskilt konstigt. Samtidigt kan vi i efterhand konstatera att det blev ödesdigert.

Jag tycker man kan ta med sig tre saker:

• Lösenord som autentiseringsmekanism är för krångligt. Vi tenderar att återanvända våra lösenord vilket gör oss sårbara. Apache själva påpekar att deras användning av engångslösenord i andra system räddade dem från en ännu större katastrof.
• Länkminifiering har gjort det i princip omöjligt (iaf väldigt opraktiskt) att veta vart en länk tar en. Jag tycker det är läskigt. Twitter, de minifierade länkarnas himmelrike, har nyligen lanserat sin egen länkminifierare twt.tl som försöker detektera attacker.
• Ta cross-site scripting på allvar. Den ligger högt upp på OWASP Top 10 (pdf) av en anledning.