Deze column bestaat uit twee delen. In het eerste deel doe ik een analyse van wat er nou precies voor zorgde dat de hele situatie bij DigiNotar zo ver heeft kunnen komen. In deel twee probeer ik structurele oplossingen aan te dragen om er voor te zorgen dat je als organisatie niet in een positie komt dat je met zulke grote escalaties te maken gaat krijgen.

Afgelopen week is het eindrapport over de hack op DigiNotar openbaar gemaakt. Wat hier uit duidelijk is geworden, is dat DigiNotar een aantal deuren wagenwijd open heeft gelaten. Ondanks allerlei maatregelen, is er toch iemand in staat is geweest om het allerbelangrijkste voor DigiNotar, het vertrouwen in hun dienst, kapot te maken. De ellende in Iran die hierdoor waarschijnlijk is ontstaan
is natuurlijk ook een gevolg hiervan, maar dat onderwerp is iets wat in deze column niet echt op z'n plaats is.

Het zal makkelijk zijn om open deuren in te trappen en achteraf te gaan zeggen wat DigiNotar allemaal fout heeft gedaan. Daarom wil ik ook vertellen wat je voor maatregelen kan nemen om te zorgen dat je niet in een vergelijkbare situatie komt. Je leert het meeste van je eigen fouten, maar andermans fouten kunnen gelukkig ook heel leerzaam zijn.

De voordeur
De voordeur stond open doordat een stukje software wat zich op twee webservers bevond niet bijgehouden was. Er was een versie geïnstalleerd waarvan algemeen bekend was dat er een lek in zat. Er waren updates voor uitgebracht, maar om onduidelijke redenen heeft DigiNotar verzuimd om die software te upgraden. Het gevolg was dat de hacker willekeurige commando's op de webservers uit kon voeren. Zoiets voorkom je door een goede lijst bij te houden met welke software je gebruikt, welke versie dat is en wanneer er voor het laatst naar gekeken is.

Afhankelijk van hoe belangrijk de gegevens of diensten zijn die samen hangen met deze systemen, bepaal je hoe vaak je moet gaan kijken of je wel up-to-date bent. Het is ook slim om voor deze controle af en toe een onafhankelijke partij in te schakelen, om te zorgen dat je zelf niet iets over het hoofd ziet.

De tussendeur
De tussendeur was een deur die er eigenlijk helemaal niet had moeten zijn. Vanaf de gehackte webserver kon de hacker een databaseserver benaderen die in een kantoornetwerk stond, door twee firewalls heen. Om onduidelijke redenen had men een poort open laten staan op beide firewalls tussen de webserver en het kantoornetwerk in. Misschien dat dit ooit een reden heeft gehad, dat is niet duidelijk geworden. Wat wel duidelijk was, is dat er meer dan 150 verbindingen tussen diverse netwerken binnen DigiNotar in firewalls werden toegestaan.

Het is daardoor aannemelijk dat niet bij iedere regel direct duidelijk is waarvoor hij moet blijven staan. Uit de rapportage blijkt dat ook Fox-IT geen inzicht heeft weten te krijgen in de exacte redenen en configuratie van de netwerken, dus klaarblijkelijk was er geen duidelijke documentatie voorhanden. Als die databaseserver in kwestie volledig goed ingericht was en niet met te veel rechten te benaderen was geweest, had waarschijnlijk bijna niemand van DigiNotar gehoord. De hacker wist echter vrij eenvoudig de databaseserver te hacken en had nu ineens een machine in het kantoornetwerk tot zijn beschikking.

Dit had voorkomen kunnen worden door helemaal geen doorgang in de firewall te zetten. Als de openingen in de firewall netjes gedocumenteerd zouden zijn en het netwerkontwerp meer rekening gehouden zou hebben met de beveiligingseisen in plaats van het sorteren van apparaten op functie en locatie, hadden er waarschijnlijk ook veel minder regels in de firewalls gestaan. Dat de databaseserver ook verder dichtgezet had kunnen worden is nogal voor de hand liggend.

De deur naar de kluis
De deur naar de kluis bestond bij DigiNotar uit een sluis met twee deuren, die alleen te betreden was met een speciaal pasjessysteem wat los gekoppeld was van de normale toegang tot de kantoren. Alleen een paar vertrouwde beheerders mochten in de kluis komen waar de feitelijke servers stonden waarop de certificaten beheerd werden. James Bond zou moeite hebben gehad om de ruimte in te komen, maar de hacker had dat allemaal niet nodig. Er lag namelijk een netwerkverbinding vanuit die ruimte naar een firewall. Die firewall stond open voor een verbinding naar dezelfde databaseserver die de hacker al gekraakt had.

De hacker kon daardoor met de tools die hij geïnstalleerd had rustig uitzoeken hoe bij DigiNotar het proces om certificaten aan te maken werkte. Hij had door de firewall heen toegang tot een werkstation in de kluis die weer verbonden was met de servers die certificaten aanmaakten. Dit werkstation en de servers wist hij te kraken doordat er authenticatietokens van beheerders op allerlei machines rond slingerden en deze certificaatservers dezelfde accounts gebruikten als de machines waar hij al op ingelogd was.

Toen kon hij eigenlijk alles wat hij wilde doen, op het stelen van de feitelijke sleutels na, omdat deze gelukkig in aparte hardware waren gezet die hij niet heeft weten te kraken. Daardoor moest hij bij DigiNotar op het netwerk blijven binnendringen om elk certificaat wat hij wilde genereren aan te maken en is hij uiteindelijk toch opgemerkt door personeel van DigiNotar.

De geldkisten
De geldkisten stonden gewoon open. De servers die alleen maar wat te doen hadden als er certificaten aangemaakt moesten worden, stonden 24/7 aan. De apparaten die de sleutels beheerden en alleen met een smartcard+pincode te ontsluiten waren, hadden de smartcards permanent in de gleuf zitten. Ondanks dat certificaten hooguit een keer per werkdag aangemaakt hoefden te worden en sommige servers regelmatig een week niet gebruikt werden, heeft de gemakzucht van een paar mensen het mogelijk gemaakt voor de hacker om op elk moment dat hij dat wilde certificaten aan te maken.

De servers stonden ook gewoon allemaal in hetzelfde netwerk en hadden dezelfde wachtwoorden, dus zodra de hacker toegang had tot één certificaatserver, kon hij zonder extra beveiliging gewoon bij de andere servers. Deze servers hadden niets met elkaar te maken, behalve dat ze dezelfde functie vervulden. Het spreekwoord is dat je niet al je eieren in één mandje moet doen. Dit is een schoolvoorbeeld waar deze uitspraak van toepassing is. Het gevolg was dat er niet alleen publieke certificaten van onder meer Google.com gehackt waren, maar dat ook PKIoverheid en nog een aantal andere certificaatservers te grazen zijn genomen.

De hele overheid heeft hier maandenlang grote problemen mee ondervonden, want de belastingdienst en vele andere overheidsorganisaties werden hierdoor gedwongen om al hun certificaten te vervangen. Dat was waarschijnlijk niet nodig geweest als DigiNotar aparte netwerken en accounts had gebruikt voor de verschillende certificaatservers. Dat laatste is natuurlijk nog steeds niet de beste oplossing, maar het had in ieder geval de schade beperkt. De echte oplossing zou zoals voorgeschreven zijn dat er geen enkele netwerkkoppeling was geweest. Certificaatservers voor CAs horen volgens de regels niet in netwerken opgenomen te zijn om te voorkomen dat ze via het netwerk te kraken zijn.

De nooduitgang
De hacker had van alles aan elkaar weten te knutselen om uiteindelijk naar binnen te komen, maar naar buiten toe was nog niet zo eenvoudig als sommige mensen denken. De hacker heeft waarschijnlijk twee methodes gebruikt om de valse certificaten en mogelijk nog andere informatie van de interne systemen van DigiNotar naar de buitenwereld te krijgen. De eerste was door een soort dropbox te bouwen op de externe webserver die hij had gehackt. Die was vanaf alle machines bij DigiNotar te benaderen, al dan niet door diverse VPN-tunnels heen die hij door de firewalls heen had weten op te bouwen.

Uit logbestand is gebleken dat hier de nodige hoeveelheid bestanden mee heen en weer gestuurd zijn. De andere is waarschijnlijk via e-mail geweest. Er waren te weinig logs om dat met zekerheid vast te stellen en uitgaande e-mail werd niet opgeslagen, dus er is niet met zekerheid te zeggen of hij daadwerkelijk mail gebruikt heeft om gegevens naar buiten te krijgen. Er was genoeg in logbestanden te vinden om te zien dat hij het in ieder geval geprobeerd heeft, maar helaas niet genoeg om te zien wat er verstuurd is en of dat ook gelukt is.

Het lekken van data naar buiten kan je voorkomen of in ieder geval bemoeilijken door je systeem niet alleen te beoordelen op de mogelijkheden om in te breken, maar ook te kijken wat er naar buiten mag en hoeveel je daarvan wilt loggen.

De bewakers
De bewakers hadden wekenlang niet in de gaten dat de hacker op hun systemen rondwaarde. De systemen stuurden hun logs niet naar centrale logservers en het alarmsysteem (IDS) stond buiten de firewall opgesteld en gaf zoveel meldingen dat niemand ze nog las. De hacker had hierdoor vrij spel om logbestanden op te schonen en op de servers rond te kijken zonder dat iemand hem een strobreed in de weg legde. Pas toen er een server stuk ging - vermoedelijk had de hacker iets gesloopt - kwamen de bewakers er achter dat de lijst met aangemaakte certificaten niet klopte met de administratie die ze gelukkig extern bewaarden en die nodig was om de installatie van de server te herstellen.

Ze hebben toen een intern incident-protocol opgestart. Dit protocol was helaas niet robuust genoeg om de situatie onder controle te krijgen. Zo werd er niet gezorgd dat de bewijslast die op dat moment aanwezig was veilig werd gesteld of om de mogelijk getroffen klanten op de hoogte te stellen. Er is alleen een beperkt onderzoek gedaan naar welke certificaten er mogelijk vervalst of onterecht uitgegeven waren en welke machines overduidelijk gehackt waren.

Er is een extern bedrijf ingeschakeld wat een zeer beperkte opdracht kreeg en alleen intern aan DigiNotar diende te rapporteren. Pas toen bleek dat de eerste maatregelen onvoldoende waren en de hack publiek bekend raakte doordat google.com op grote schaal werd afgevangen in Iran, is er een volledig onderzoek opgestart door de overheid. Bij dat onderzoek bleek dat de situatie in eerste instantie zwaar was onderschat en dat er op grote schaal gegevens misten die hadden kunnen helpen met het ontdekken van de hacker en het uitvoeren van het onderzoek.

Volgende week wil ik in deel twee ingaan waarom dit soort dingen fout gaan en wat je er aan kan doen om dat te voorkomen.

Homme Bitter is consultant bij Sogeti en speelt regelmatig mee met hackwedstrijden. Tevens is hij actief op het forum en het Certified Secure IRC-kanaal.