Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 39, views: 28.615 •

De hacker die in 2011 de systemen van de voormalige certificaatverstrekker Diginotar wist binnen te dringen, gebruikte vermoedelijk een gat in de cms-software DotNetNuke. De website van Diginotar draaide op een sterk verouderde versie van DotNetNuke.

Dat meldt Nu.nl op basis van een onderzoeksrapport van ITsec, een beveiligingsbedrijf dat door Diginotar werd ingeschakeld om te achterhalen hoe de vermoedelijk Iraanse hacker binnen wist te dringen en vervolgens vervalste certificaten kon genereren. De onderzoekers van ITsec concludeerden dat de aanvaller vermoedelijk gebruik heeft gemaakt van een gat in DotNetNuke, een content management systeem waarop de website van Diginotar draaide. Het cms zou sinds 2008 niet meer zijn bijgewerkt, waardoor er zeker 30 patches niet waren uitgevoerd en de website een makkelijke prooi was voor aanvallers.

Nadat de hacker toegang had tot de webserver van Diginotar zou hij ongemerkt malware hebben gebruikt om wachtwoorden te verzamelen. De hacker wist uiteindelijk enkele beheerdersaccounts in handen te krijgen, mede omdat de systeembeheerders voor relatief zwakke Windows-wachtwoorden hadden gekozen. De vermeende hacker publiceerde onder andere het wachtwoord 'Pr0d@dm1n’. De hacker zou uiteindelijk toegang hebben verkregen tot twee systemen waarmee certificaten aangemaakt konden worden.

Diginotar slaagde er aanvankelijk in om de inbraak op zijn kritieke systemen een maand stil te houden. Een Iraanse internetgebruiker kwam er echter achter dat er gerommeld was met enkele ssl-certificaten. Hierdoor zou de Iraanse overheid enige tijd in staat zijn geweest om onder andere versleuteld dataverkeer van Gmail-gebruikers af te tappen. Nadat de inbraak bij Diginotar bekend werd, ging het snel bergafwaarts met de certificaatverstrekker; in september vorig jaar werd het bedrijf failliet verklaard.

Gerelateerde content

Alle gerelateerde content (32)

Reacties (39)

Zowel het niet patchen als het gebruik van (zeer) zwakke wachtwoorden is bij elk bedrijf al een forse blunder, waar toch serieuze consequenties aan zouden moeten hangen. Maar bij een bedrijf dat certificaten uitdeelt is dat al helemaal onvergeeflijk. Daar zou je toch iets andere eisen aan mogen stellen dan aan een doorsnee bedrijf.

Ook dat de malware niet opgemerkt is bij controles is op zijn minst opvallend te noemen. Werd er sowieso wel een virusscanner gebruikt? Het ging immers om al tijden bekende malware die de lokale SAM-database onder handen nam. Vrij basic allemaal...

Al met al komt de handelswijze van Diginotar, of iig haar IT-afdeling, toch wel enigszins amateuristisch over allemaal...

[Reactie gewijzigd door wildhagen op 18 november 2012 16:02]

En die beheerders zijn nu ergens anders in dienst?
Misschien. Maar staat waarschijnlijk niet zo goed op je CV, als je bij diginotar hebt gewerkt. En dat verzwijgen is ook geen goed idee. Ik zou gewoon met de billen bloot gaan en je best doen om ergens aan de bak te gaan. Ik neem aan dat een bedrijf ook wel begrijpt dat dit niet alleen te wijten is aan alle medewerkers van Diginotar...
Ze hebben er in ieder geval hopenlijk wat van opgestoken en zullen denk ik na zo een onderzoek dit nooit meer laten gebeuren.
Denk niet dat diginotar maar 1 beheerder in dienst had.. dus ik vermoed dat daar wel omheen valt te praten.

Het staat op zich wel spectaculair op je CV hebt staan dat je beheerder was bij een club met miljoenen omzet, die failliet is gegaan door wanbeheer !

..of je de vacature daarmee binnensleept betwijfel ik :+

[Reactie gewijzigd door sarcast op 18 november 2012 16:43]

Denk niet dat diginotar maar 1 beheerder in dienst had.. dus ik vermoed dat daar wel omheen valt te praten.
Soms is het verbazingwekkend wat bedrijven allemaal doen met 1 admin. Veel bedrijven zijn van het "If it ain't broke, don't fix it principe" en moeten eerst eens zwaar tegen de lamp lopen voor ze beseffen dat de IT afdeling toch wel belangrijk is.

Ik ken een bedrijfje met een vrij complexe structuur dat alles met 1 admin deed. Die mocht ook de IT van de klanten beheren. Nu zijn ze met twee, maar dat is mijn ogen nog steeds onvoeldende om op de hoogte te blijvan security problemen op elk niveau, firewall, webservers, etc. Disaster recovery is ook enorm belangrijk, net als het testen van de normale backups.

De vraag is dus of diginotar heeft zitten besparen op zijn IT afdeling of dat ze admins in dienst hadden die er de kantjes afliepen. In dat geval ligt de verantwoordelijkheid bij het hoofd van de IT afdeling.
Het heeft niets met de beheerders te maken. Management beslist de regels tot patchen. Beheerders voeren alleen het changemanagement uit.
De directie van een dergelijk bedrijf zou nooit meer aan de bak mogen komen. Landen als iraan nemen het niet al te nauw als het op mensenrechten aan komt. De mensen waarvan het e-mail verkeer is onderschept hebben/hadden dan ook te verzen voor de gevolgen.
Jouw stelling dat een beheerder iemand die is alleen zaken uitvoert welke er aan hem opgedragen wordt is naar mijn mening niet juist. Natuurlijk zijn er 1e en 2e lijns mensen die domweg alleen maar opgedragen taken uitvoeren maar een echte Systeem beheerder is er om er voor te zorgen dat dit soort dingen in de gaten worden gehouden, worden aangekaart en opgelost. Als je denkt dat de directie zich bezig moet houden met patch mgmt dan begrijp je volgens mij weinig van een organisatie. Een directie kan bijv. wel een security officer aanstellen die audits of controles uitvoert. Maar nogmaals, als beheerder hoor je dit soort dingen ook in de gaten te houden, pro-actief te handelen en een change in te dienen of dit te adresseren bij het management zodat er wat aan gedaan wordt.
Ik denk dat jullie beiden een beetje gelijk hebben.
Ik geloof niet dat de stelling van erwinb is dat een beheerder alleen zaken uitvoert welke aan hem opgedragen wordt, maar wel dat Management uiteindelijk alles beslist. Ik heb genoeg IT bedrijven gezien waar er inderdaad door de beheerders bepaalde zaken gesignaleerd worden, maar dat Management -meestal vanwege budgettaire redenen- toch iets anders beslist.
Bovendien kom ik ook vaak beheerders tegen die graag de zaak willen verbeteren, maar geen tijd krijgen om iets anders te doen dan brandjes blussen.
Gezien het overhied was, vermoed ik dat het hele beheer uitbesteed was aan een van de grotere beheer clubs van nederland.
Het was geen overheid, de overheid was alleen één van hun klanten.
Ja, en ze hadden ook nog allerlei commerciële klanten. Wat is je punt?
Bovendien staat DigiD los van Diginotar.
Niet helemaal dus, xkcd geeft een voorbeeld: http://xkcd.com/936/
En toch gaat het stripje van XKCD niet helemaal op als wetenschap, maar inderdaad je zou je nog verbazen hoesnel een dictionary brute-force attack gaat op zo'n relatief kort wachtwoord.

[Reactie gewijzigd door GewoonWatSpulle op 18 november 2012 17:21]

En daarom dien je na 3 foute wachtwoorden het account (tijdelijk) te blokkeren :)
Brute forcen (waaronder een dictionary attack ook valt) doe je dan normaal gesproken ook niet via een normale (user) interface maar op password hashes of iets dergelijks.
Zelfs als ze een super goed bedacht paswoord hadden gekozen, waren ze er volgens mij aan voor de moeite omdat er malware werd ingeschakeld.
Voor zover uit het rapport op te maken is, is het enige doel van die malware geweest om passwords te pakken te krijgen. Er is immers een file met password-hashes gevonden.

Als ze éénmaal die passwords hadden, stond zowat het hele network voor ze open. Hetzelfde local administrator password werd immers op bijna alle servers gebruikt.... ook al een flinke blunder overigens, op elke server dient het local admin account een ander password te hebben...
Er is ook gewoon nog het 'point of no return'.

Als een hacker binnen je netwerk actief is en elke mogelijkheid aangrijpt om zich verder te verspreiden heb je een serieus probleem. Doordat je hacker weet welke beveiligsmiddelen je hebt aanstaan kun je daar weer omheen werken.

Stel je hebt virusscanner 'X'. Als hacker installeer je dan gewoon een server met die virusscanner en gaat opzoek naar de beste malware die niet gedetecteerd wordt. Zo kun je een vroege detectie voorkomen, helemaal als je de updates goed bijhoud weet je sneller dan de systeembeheerder of jouw malware problemen gaat geven.

Daarnaast werkt eigenlijk systeembeheer altijd met een (netwerk)directory waar vanuit bestanden worden gehaald (updates/installaties/,,,). Zet je daar je 'payload' ergens bij en ook op systemen waarvan je het wachtwoord (nog) niet hebt staat je malware.

Vergeet niet dat Diginotar niet door 'een rondzwervend virus' is geraakt, maar bewust en langdurig onder vuur heeft gelegen. Ik ken maar weinig organisaties die daar tegen bestand zijn.
Akkoord maar we hebben het hier over een bedrijf wat nota bene internetbeveiliging als core business heeft! Mensen die zich hiervoor laten betalen, als full-time job.. Dan is het toch veelzeggend als je 30 patches achterloopt?
Daarom is role based beheer zo gek nog niet. Dan kan een wachtwoord van 1 admin nog niet voldoende zijn om door het hele netwerk te gaan. Hoewel ik vaak zie dat beheerders werkzaamheden uitvoeren met het "Administrator" account.

Er zijn verschillende scenario's te bedenken maar je moet beheer functioneel scheiden. Want waarom heeft een content beheerder admin priveleges nodig, waarom heeft een DBA root/admin priveleges nodig en waarom heeft een systeembeheerder toegang nodig tot databases, content en netwerk componenten.

Bij kleine organisaties liggen veel rollen bij een paar personen maar bij grotere o0rganisaties is dat zeer goed te scheiden. Daarnaast kan je je infrastructuur ook nog opdelen in verschillende lagen, op netwerk niveau kan je gaan tieren maar ook op applicatie niveau.

En het excuus "omdat het makkelijk" is om overal admin toegang te hebben is het meest domme wat je kan hebben. Als IT beheer makkelijk zou zijn, zou iedereen het kunnen. IT is voor het gemak van de gebruikers niet voor de beheerders.

Daarnaast is het vreemd dat blijkbaar beheer en gebruik niet gescheiden waren. Blijkbaar hadden de accounts van de website gewoon admin rechten binnen het netwerk. Volgens mij is het goed gebruik dat iedere beheerder twee persoonlijke accounts heeft, 1 voor normaal office werk, en een beheer account met de daar aan gekoppelde rollen.
Uhm zwak is het wel: Dit is een wachtwoord uit een bekend wachtwoord woordenboek voor hackers. Een Bruteforcedictionary-attack met de 3 bekendste woordenboeken zou deze dus met gemak hacken.

Ik gok dat je met een beetje botnet van 100 pc's binnen ongeveer 3 dagen binnen bent (wel afhankelijk van de beveiliging)

Zeker als cerificaat verstrekker en beveiliger hadden ze dit gewoon moeten weten (sterker nog een beetje security speciaalist heeft dit woordenboek op school gehad, en waarschijnlijk ook uit zijn hoofd moeten leren--> zo was hij waarschijnlijk ook aan dit wachtwoord gekomen ;) )
Wat mij verbaasd is dat in het artikel wordt 'geklaagd' over een 2008 geupdate CMS en dat men daardoor is binnen gekomen. Nou weet ik niet hoe het zit bij IIS of windows server, maar bij een secure OS, als je het CMS kraakt, kraak je een web applicatie. Dus worst case scenario, heb je toegang tot dingen waar de webserver toegang tot heeft. Aangezien je webserver un-privilidged draait heb je dus ook zo goed als nergens toe gang tot.

Apache op linux achtigen, draait als user apache. De user apache mag buiten de websites eigenlijk helemaal niets. Dus hoe in hemelsnaam, krijgt een dotnetnuke toegang tot lokal admin? Ik mag er vanuit gaan dat ze local admin rechten 'gekraakt' hadden en vervolgens daarmee malware geinstalleerd om de wachtwoorden daadwerkelijk te verkrijgen?

Ik weet ook dat er genoeg mensen geloven dat Windows veilig genoeg is voor een web-facing server, maar als je der mate 'belangrijk' iets doet, vind ik dat toch slordig. Slordig beheer houd overigens nix tegen, dat is wel weer duidelijk.
Als je hetzelfde wachtwoord gebruikt voor het bijhouden van de content van de webserver als de admin account op die server heeft, ben je zwaar het haasje. Ongeacht welke privileges je webserver dan heeft. Het kan ook zijn dat ze een privilege-escalation bug hebben gebruikt toen ze met de rechten van de webserver konden werken.

Bovendien, de webserver kan meestal gewoon bij bestanden met een lees-permissie voor "overig", dus xx4 in linux termen. Als je dan niet iets als SELinux hebt draaien, kan de webserver dus ook het wachtwoordbestand uitlezen. De aanvaller kan dan vervolgens een offline aanval doen tegen die bestand en wachtwoorden achterhalen. Die wachtwoorden werden blijkbaar hergebruikt over verschillende werkstations/servers, dus dan gaat het hard.

Op dit item kan niet meer gereageerd worden.