Uitspraak
RECHTBANK AMSTERDAM
1.De procedure
2.De feiten
Softwareen
IT Systemsals volgt zijn gedefinieerd:
escrow accountbij de notaris.
certificate service provider) zoals DigiNotar is een (rechts)persoon die zich bezighoudt met het leveren van digitale certificaten en diensten die daarmee verband houden.
public key infrastructure(ook: PKI). DigiNotar trad in 2004 toe tot PKIoverheid en sindsdien leverde het bedrijf ook PKIoverheid-certificaten. Dit zijn de certificaten bestemd voor het beschermen van het elektronisch gegevensverkeer met en tussen overheidsorganisaties. De Staat der Nederlanden staat voor de betrouwbaarheid van deze certificaten in.
- het internet;
- Net-DMZ-ext;
- Office-net;
- Secure-net.
fire walls. Het is (in beginsel) niet de bedoeling dat vanuit een (hiervoor weergegeven) “hoger” segment een “lager” segment kan worden bereikt. Dit betekent dat bijvoorbeeld iemand die toegang had tot het Net-DMZ-ext segment, geen toegang had tot het volgende segment, het
Office-net. Het Net-DMZ-ext segment was de
“demilitarized zone”(DMZ) van het DigiNotar netwerk. Dit segment stond in rechtstreekse verbinding met het internet en was de buffer tussen het internet en het interne netwerk van DigiNotar. In het Net-DMZ-ext segment waren verschillende servers actief, waaronder de DocProof servers. De servers in dit segment waren voor het grootste deel webservers. De IP-adressen die werden gebruikt in dit segment begonnen allemaal met 10.10.20.
Office-netbevonden zich workstations, database servers, een exchange server en fileservers voor de medewerkers. De IP-adressen gebruikt in het
Office-netbegonnen steeds met 172.17.20.
Secure-net. In dit segment bevonden zich de belangrijkste servers van het DigiNotar netwerk (de computers waarmee de certificaten worden gemaakt (Certificaten Authenticatie), de CA-servers). Dit
Secure-netmocht niet voor onbevoegden toegankelijk zijn. In het
Secure-netbegonnen alle IP-adressen met 172.18.20.
Office-net), DIGIWS146 (het BAPI workstation ) en WINSVR056 (Public-CA in het
Secure-net).
Director Business Development) en [naam 1] (na de overname als consultant), de volgende personen werkzaam:
hacker) via het internet door tot de computersystemen van DigiNotar. Via computersystemen (servers) van het bedrijf die in verbinding stonden met het internet verschafte de
hackerzich toegang tot afgeschermde gedeelten van het netwerk, het
Secure-net, waaronder ook verscheidene CA-servers waarop zich de processen voor certificaatdienstverlening plaatsvonden. De
hackerslaagde erin beheersrechten voor deze servers te verkrijgen en vervalste digitale certificaten te genereren. Nadat bij DigiNotar bekend was geworden dat een
hackerzich toegang had weten te verschaffen tot haar systemen, heeft zij een onderzoeksbureau, ITSec Security Services B.V. (hierna: IT-Sec), ingeschakeld.
hacker(‘the attacker’) plaatsvonden op 17 juni 2011. Verder heeft zij vastgesteld dat de oorzaak van de veiligheidsinbreuk het gevolg is van een kwetsbaarheid in het door DigiNotar gebruikte zogenaamde DotNetNuke systeem. In het IT-Sec rapport 2011 staat op pagina 1 vermeld:
escrowwordt gehouden in verband met eventuele schadeclaims als gevolg van garantieschendingen (op grond van artikel 9.4 van de SPA).
3.Het geschil
in conventie
althans Vasco veroordeelt tot het verrichten van alle uitvoeringshandelingen waardoor het in escrow gehouden bedrag voor de koopprijs wordt vrijgegeven aan Ratonigid c.s.,
4.De beoordeling
“has taken all reasonable steps and implemented all reasonable procedures tot safeguard its IT Systems and Software and prevent authorised access thereto.”). Volgens Vasco is dit niet het geval. Zij heeft daartoe in het bijzonder gewezen op de drie volgende veiligheidsgebreken waarvan de
hackergebruik heeft gemaakt:
DotNetNuke (versie 4.8.2.0)waarvan bekend was dat de beveiliging kwetsbaar was;
credentialsen wachtwoorden waren onversleuteld opgeslagen op WINSRV101;
Office-netals het
Secure-net.
DotNetNukewaren geïnstalleerd, dat deze versies kwetsbaarheden vertoonden en dat dit Ratonigid bekend was, wijst Vasco op het volgende.
hackergebruik heeft gemaakt van een bekende kwetsbaarheid van
DotNetNuke(Erratum [naam 8] rapport van 4 oktober 2013, p.2:
“On 17 June 2011 the intruder exploits a wellknown DotNetNuke vulnerability on the docproof webservers WINSVR118 and WINSVR119.”). De bevindingen van [naam 8] ten aanzien van WINSVR119 staan op pagina 78 en verder van haar rapport, waar het volgende wordt beschreven. Uit de logfiles van de server volgt dat de
hackerop 17 juni 2011vanaf 02:29:20 uur verschillende pogingen doet om toegang tot het systeem te verkrijgen. Waar zijn eerste pogingen falen, lukt het de
hackerom 02:33:17 uur om een bepaald programma op de server te uploaden (17.asp;.gif). Door vervolgens van dit programma gebruik te maken, krijgt de
hackerverder voet aan de grond. Het lukt de
hackerom een aantal standaard hackerbestanden te installeren ([naam 8] rapport, p. 80). Het gaat onder andere om AspxSpy:
"a webshell often used by intruders that provide numerous access functionalities on a compromised server". [naam 8] stelt verder vast dat de
hackerook gebruik heeft gemaakt van deze door hem geïnstalleerde bestanden.
hackerkunnen uploaden van het bestand 17.asp;.gif is volgens [naam 8] in de eerste plaats het gevolg van het benutten van een kwetsbaarheid van DotNetNuke die algemeen bekend was.
executable file, aldus een bestand dat een hacker in staat stelt opdrachten te geven die het gehackte systeem vervolgens uitvoert.
file upload vulnerability" genoemd) was al bekend vanaf 5 mei 2008.
“The attacker compromised a webserver of DigiNotar due to a security vulnerability that is present within the DotNetNuke software. DotNetNuke version 4.8.2.0 is installed on host winsvr119. This version is affected by a file upload vulnerability.”)
“The web servers in the outskirts of DigiNotar’s network (DMZ-ext-net) served as the first point of entry for the intruder. Both the Main-web and the Docproof2 web server were running an outdated version of DotNetNuke that suffered from known security vulnerabilities (…)”.)
DotNetNukewas bekend. Hiertoe wijst Vasco onder meer op het volgende. Op 21 mei 2008 heeft
DotNetNukezelf in een door haar gepubliceerde
“Security Notice”melding gemaakt van:
“a security vulnerability which allowed an unauthorized user to upload a file into DotNetNuke site”.Vervolgens heeft
DotNetNukeop 28 mei 2008 een nieuwe
general releasebeschikbaar gesteld, versie 4.8.3, waarbij
DotNetNukeopmerkte dat deze release
“fully addresses each of the reported items. You can get it now from the Downloads page on our site”.
“patchen”van haar systemen, dat wil zeggen het niet doorvoeren van beveiligingsupdates die door softwareleveranciers en op internet steeds worden gepubliceerd om ontwerpfouten te verbeteren. De aanbeveling van IT-Sec luidde steeds als volgt:
“Alle webservers, applicatieservers en andere voor de diensten van DigiNotar essentiële systemen dienen te allen tijde volledig gepatched te zijn en gepatched te blijven middels een adequaat patch-beleid”.In haar rapport van 2008 merkt ITsec op (p. 2) op:
"Van een aantal systemen is geconstateerd dat een groot aantal security patches ontbreken”. De aanbeveling luidt dat het patchbeleid van DigiNotar moet worden herzien en:
“Waarborg dat patches regelmatig en binnen een acceptabele periode worden doorgevoerd”.In 2006 had IT-Sec al opgemerkt dat de door haar onderzochte Windows systemen "
zeer onveilig zijn ingericht" en concludeert zij: "
het patch-level van de systemen is ver onder de maat". Van belang is op te merken dat het onderwerp van onderzoek toen onder meer het systeem 172.17.20.25 (va het
Office-net)betrof, een systeem dat blijkens de reconstructie van de hack op pagina 35 van het [naam 8] Rapport een cruciale rol in de hack vervulde.
“Patch management van DNN en alle andere servers verbeteren. Wekelijks patchen (Betekent achter de loadbalancer). Doen dus.”.
DotNetNukewaren geïnstalleerd. Zij betoogt evenwel dat haar systemen (voor zover nodig) desondanks waren voorzien van een
“state of the art”versie van
DotNetNuke. Naar de rechtbank begrijpt, komt haar betoog erop neer dat zij wel heeft gereageerd op aangeboden updates die door DotNetNuke (en IT-Sec) als “critical” werden bestempeld (en dan ook heeft ge-update), maar niet als het ging om updates waarvan het belang als “medium” of “low” werd bestempeld. Bovendien lijkt zij onderscheid te hebben gemaakt tussen servers in de verschillende segmenten (waarbij van belang was of een server wel of niet in contact stond met de buitenwereld). [naam 2] heeft op de comparitie op dit punt het volgende verklaard:
“De acceptatieomgeving die verbonden was met het internet, waar klanten daadwerkelijk toegang hadden, was netjes gepatcht”.Zo draaide in ieder geval op de publieke webserver WINSVR101 een recentere versie van DotNetNuke (versie 4.9.4.17). Volgens [naam 9],
lead developervan DocProof bij DigiNotar, draaide eind 2010 de “Acceptatieomgeving” (dat wil zeggen de servers waartoe de gebruikers toegang hadden) zelfs op versie 5.6.0 van DotNetNuke. Alleen bij versies 4.9.2 en “oudere” versies bestonden zwakheden. Dus was de webserver WINSVR101 niet kwetsbaar voor deze zwakheid en volgens [naam 8] was WINSVR101 de toegangspoort voor de
hackeren niet WINSVR118 en WINSVR119. WINSVR118 en WINSVR119 hadden geen functie ten behoeve van de buitenwereld; dit waren de DocProof servers. DocProof was een online archief om documenten op te slaan. Ratonigid erkent wel dat de DocProof servers zijn misbruikt door de
hacker, maar pas nadat de WINSVR101 van binnenuit konden worden bereikt. Ten slotte wijst Ratonigid erop dat de specifieke kwetsbaarheid in DotNetNuke die op de publieke website vermoedelijk de mogelijkheid heeft gegeven om in de buitenste laag van het systeem binnen te dringen, pas op 19 januari 2011 door DotNetNuke zelf aan de gebruikersgemeenschap bekend is gemaakt, waarbij tegelijkertijd een oplossing beschikbaar is gesteld, te weten de “critical” upgrade naar versie 5.6.1. Vasco heeft zelf nagelaten deze upgrade uit te voeren. Als Vasco deze upgrade wel had uitgevoerd, was de hack naar alle waarschijnlijkheid niet geslaagd. De upgrade waar [naam 4] het over heeft in zijn logboek, is de update naar 5.6.1 die pas op 19 januari 2011 (dus na de overname) was uitgekomen, aldus steeds Ratonigid.
hackergebruik heeft gemaakt van het feit dat een verouderde versie van DotNetNuke werd gebruikt worden hierna aan de orde komen bij de beoordeling of dit een garantieschending oplevert, die aan Ratonigid kan worden toegerekend en of die in causaal verband staat met de hack. Hier kan worden volstaan met de vaststelling dat tussen partijen niet in geschil is dat op (ten minste) twee servers, WINSVR118 en WINSVR119, een verouderde versie van DotNetNuke was geïnstalleerd en dat bij deze versie van DotNetNuke bekende kwetsbaarheden in de beveiliging bestonden.
credentialsonversleuteld waren opgeslagen op WINSVR101 heeft Vasco gewezen op het volgende. De wachtwoorden en
credentialswaren opgeslagen in
plain tekstbestanden (zij waren toegankelijk in bestanden (files) opgeslagen in de map web.config). In het IT-Sec rapport 2011 wordt de
“weak security of Windows password”al genoemd (zie hiervoor rov. 2.14). Ook Fox-IT heeft deze problematiek gesignaleerd. In het rapport van Fox-IT van 18 april 2012 (p. 51) staat vermeld:
Additionally, on the Main-web server a file was identified that contained a string with credentials to access the database on BAPI-db (…)
credentialsonversleuteld waren opgeslagen als in 2009 als een groot veiligheidsrisico werd gesignaleerd (IT-Sec rapport 2009, par. 3.5.1):
credentialseen risico opleverde, aldus steeds Vasco.
hackerheeft - zo volgt uit het [naam 8] rapport en uit het FOX-IT rapport - uitgebreide tools (
brute force) gebruikt om wachtwoorden te achterhalen. Voor zover al wachtwoorden en credentials onversleuteld waren opgeslagen, betwist Ratonigid dat dit op 10 januari 2011 het geval was. Na 10 januari 2011, diende de door Ratonigid ontwikkelde tool onder verantwoordelijkheid van Vasco te worden gebruikt, aldus Ratonigid.
credentialsonversleuteld waren opgeslagen. Dat dit het geval was, blijkt ook uit het incidenten logboek dat [naam 4] na de hack heeft bijgehouden. Op de tweede pagina van dit logboek staat (bij 26 juli 2011):
“(…) Afgesproken wordt de wachtwoorden voor toegang (plain in config files) alle te wijzigen.(…).”Dit wordt herhaald op zijn actielijst waar (pagina 6 van het logboek) als actie staat vermeld:
“(…) Data bases wachtwoorden in plaintext vervangen door encrypted. (…).”
“(…) AppMan was inderdaad al operationeel. In ieder geval de verschillende ‘batch’ applicaties (…) en een aantal webapplicaties (…)”.
credentialshad versleuteld en dat – kennelijk – onder het management van Vasco (opnieuw) wachtwoorden en
credentialsin
plain tekstzijn opgeslagen, wordt dit verweer dan ook als onvoldoende onderbouwd gepasseerd. Het verweer van Ratonigid dat uit de diverse rapporten volgt dat de
hackergebruik heeft gemaakt van speciale programma’s om de wachtwoorden en
credentialste achterhalen en kraken (en dat in die rapporten gesproken wordt van
brute force)en dat dit niet nodig was geweest als de wachtwoorden en
credentialsonversleuteld waren opgeslagen, doet aan dit alles niet af. Dit betekent immers niet dat – anders dan hiervoor is vastgesteld – de wachtwoorden en
credentialswél versleuteld waren opgeslagen.
Office-netals het
Secure-net,heeft Vasco gewezen op het volgende.
Secure-net -ten tijde van de hack ook in verbinding stond met het
Office-net([naam 8] rapport, p. 33:
“(…) Although the DigiWs146 was situated in the Secure-net, examination of this workstation showed that it also had an active network interface in the Office-net network segment during the time of the incident.(…)”). Dit volgt volgens [naam 8] uit een zogenaamde "pagefile.sys" (computergeheugen), waarin netwerkinformatie is aangetroffen. Uit het tweede blok op pagina 95 van het [naam 8] rapport volgt welke twee netwerkkaarten er blijkens het systeem waren:
Secure-net; alle systemen in
Secure-netbegonnen met 172.18.20 (zie hiervoor rov. 2.11). Dit betreft een insteekkaart. Kaart No.1, "KA", heeft als IP-adres: 172.17.20.59. Dat is een adres dat hoort bij het
Office-net(zie hiervoor onder 2.11). Deze kaart is de zogenaamde
"onboard"-netwerkkaart (dat wil zeggen: ingebouwd in de computer).
Secure-netonvoldoende was gescheiden van het
Office-netals een van de omstandigheden geïdentificeerd die ertoe hebben bijgedragen dat de hack kon plaatsvinden (rapport van de Onderzoeksraad, p. 39:
“(…) Ten derde waren de veiligheidskritische gedeelten van het bedrijfsnetwerk waarop de processen voor certificaatuitgifte zich afspeelden niet zodanig afgescheiden van de servers die in verbinding stonden met het internet dat een inbraak voorkomen kon worden. Het onderzoek heeft uitgewezen dat de inbreker erin slaagde verbindingen (zogenaamde tunnels) tussen de verschillende segmenten in het netwerk te leggen, omdat de centrale veiligheidsvoorziening in het netwerk (de interne firewall
) dataverkeer tussen deze segmenten toestond). (…)”)
Secure-neten het
Office-net.Dat blijkt uit e-mailcorrespondentie uit 2008 die [naam 8] heeft onderzocht. [naam 8] wijst in haar rapport (op pagina 184) op een e-mail van [naam 7] aan onder meer [naam 2] van 30 oktober 2008. Het onderwerp van deze e-mail is “BAPI aanbevelingen Versie 01”. Aan de e-mail is een bijlage gehecht genaamd “Verbetermogelijkheden BAPI tools” (Appendix 15 bij het [naam 8] rapport). In deze bijlage staat een analyse van [naam 7] van de BAPI infrastructuur en daarin geeft hij ook aanbevelingen ten aanzien van de locatie van de BAPI server in het netwerk van DigiNotar. Als bevinding 14 op pagina 7 van de bijlage staat vermeld:
“(…) Bapi draait in de kantoor SQL database omgeving. Er is een uitspraak nodig of BAPI daar zou moeten blijven of dat dit naar de secure omgeving zou moeten gaan. (…)”.Op dezelfde pagina staat als aanbeveling 16 vermeld:
“(…) Management moet uitspraken doen over de volgende issues:
“(…) Gisteren heeft het Audit Committee bij elkaar gezeten en heb ik [naam 2][[naam 2], rb]
gesproken over onder meer Bapi en uitwijk. (…) en wat eventueel aanvullend gedaan moet worden, zodat Bapi kan blijven draaien waar het nu draait (kantoor). E.e.a. ter voorkoming van hoge kosten. (…)”(Appendix 16 bij het [naam 8] rapport).
Office-neten het
Secure-net.(Appendix 18 bij het [naam 8] rapport).
Secure-netals het
Office-net, onder meer omdat de shortcuts waarnaar de handleiding verwijst allemaal zijn geïnstalleerd op de DIGIWS146 en [naam 8] heeft geconstateerd dat DIGIWS146 contact had en gegevens uitwisselde met de WINSVR056 (een server in de het
Secure-net). ([naam 8] rapport, p. 99-102:
“(…) A usermanual called ‘Handleiding Bapirun.doc’, created by DigiNotar, describing the workflow of generating new certificates, supports the finding of the dual network interface in the DigiWs146. The manual describes how employees are supposed to generate certificates using several applications on the DigiWs146. The manual describes how these applications need to be started in a specific order, and contains screenshots of shortcuts on the desktop to these applications. The screenshots show several shortcuts which names are prefixed with a number, specifying the order in which the shortcuts (thus, applications) need to be executed. Investigation of the DigiWs146 confirms that the desktop of “All Users” indeed contains these shortcuts.
Secure-netde benodigde certificaten konden worden gemaakt, maar de
firewall logop dit punt geen verkeer laat zien, de certificaatgeneratie dus op een andere wijze gestalte moet hebben gekregen:
“(…) Webservers zijn actief in het externe DMZ netwerksegment, database servers (waar de content huist) zijn actief in het interne DMZ netwerksegment. Hosts actief binnen een netwerksegment kunnen zonder restrictie met elkaar communiceren. Webservers kunnen dus zonder restricties onderling met elkaar communiceren en voor database-servers geldt dezelfde bevinding.
Office-neten het
Secure-net.Alle bevindingen van [naam 8] dateren van (ver) na de overname (op 10 januari 2011) en er kan dus slechts worden vastgesteld dat na die datum sprake was van twee IP-adressen. Dit zegt niets over de situatie ten tijde van de overname. De e-mailberichten uit 2008 heeft [naam 8] verkeerd geïnterpreteerd: deze gingen niet over een veilige configuratie van het BAPI-systeem, maar over het wel of niet verplaatsen van het BAPI-systeem ten behoeve van een eventuele uitwijkmogelijkheid en een verbetering van interne processen. In de e-mails wordt aan het management van DigiNotar alleen gevraagd om te bepalen waar de BAPI server moet komen, in het
Office-netof het
Secure-net. Uit de e-mailcorrespondentie kan niet de conclusie worden getrokken dat er een verbinding bestond tussen het
Office-neten het
Secure-net.In haar akte na comparitie heeft Ratonigid nog het volgende aangevoerd. De “Handleiding uitvoeren Bapirun” kan niet de conclusie rechtvaardigen dat sprake is geweest van een dubbele netwerkkaart. Het is verder op zich zelf juist dat het BAPI station (DIGIWS146) op het ene moment contact moest hebben met het segment waar de aanvragen binnenkwamen en een ander (kort) moment met het segment waar de certificaten werden vervaardigd om de aanvragen aan de CA-servers door te geven. [naam 8] gaat er echter ten onrechte vanuit dat dit door een dubbele netwerkkaart werd gerealiseerd. Dat is niet noodzakelijk. Alvorens de BAPI run te realiseren kan ook de netwerkkabel, die meestentijds verbinding maakt met het segment van de aanvragen, handmatig gewisseld worden om contact te maken met het segment van de CA-servers. Ook dan is er de mogelijkheid om zowel in het ene segment actief te zijn als in het andere segment, maar nooit tegelijkertijd. In die situatie, die zich heel goed zou hebben kunnen voorgedaan vóór 10 januari 2011, is er geen sprake van een dubbele netwerkkaart of een risicovolle verbinding, aldus steeds Ratonigid.
Secure-netals het
Office-net,had van Ratonigid – nu zij deze stelling betwist - mogen worden verwacht dat zij een gemotiveerde en gedocumenteerde verklaring had gegeven waarom daarvan geen sprake was. Daarvoor kan niet worden volstaan met het opwerpen van de enkele suggestie dat de bevindingen van [naam 8] ten aanzien van de dubbele netwerkkaarten niet zouden kunnen worden teruggeleid naar een datum voor 10 januari 2011 omdat DIGIWS146 na 10 januari 2011 nog is gebruikt. Ratonigid kan, vertegenwoordigd door de twee (voormalig) bestuurders van DigiNotar, ter verklaring van het feit dat de firewall log geen verkeer laat zien evenmin volstaan met de niet nader onderbouwde bewering dat de BAPI-run
mogelijkplaatsvond door een netwerkkabel handmatig te wisselen. Ratonigid moet in staat geacht worden te kunnen reproduceren op welke wijze de productie van certificaten daadwerkelijk voor 10 januari 2011 plaatsvond en hoe daarbij de verbinding tussen het
Office-neten het
Secure-nettot stand werd gebracht. Dit brengt mee dat het op haar weg had gelegen om tegenover de gemotiveerde bevindingen van Hoffman concreet toe te lichten dat en hoe daarbij geen gebruik werd gemaakt van een verbinding middels een tweede netwerkkaart in het werkstation DIGIWS146, zoals Vasco – ondersteund met stukken en rapporten van verschillende deskundigen – heeft geconcludeerd. Ratonigid heeft dit echter niet gedaan maar in plaats daarvan volstaan met het schetsen van een situatie “die zich heel goed zou hebben kunnen voorgedaan vóór 10 januari 2011”). Aldus heeft zij de stellingen van Vasco op dit punt onvoldoende gemotiveerd betwist, zodat de rechtbank als vaststaand zal aannemen dat het werkstation DIGIWS146 door middel van twee netwerkkaarten in verbinding stond met zowel het
Secure-netals het
Office-net.
Secure-netals het
Office-neteen schending oplevert van de garantie, leidt geen twijfel. Gelet op de hiervoor besproken risico’s die met deze dubbele verbinding gepaard gaan, kan een dergelijke verbinding niet worden aangemerkt als het nemen van alle redelijke stappen en het implementeren van alle redelijke procedures om toegang door onbevoegden te voorkomen, zoals de garantie vereist. Ook [naam 2] heeft zelf ter comparitie verklaard dat het niet de bedoeling was dat een werkstation contact kon maken met het
Office-neten het
Secure-neten dat het in dat kader niet toelaatbaar was, als er inderdaad twee netwerkkaarten in het werkstation zaten.
credentials. Ook in de eigen stellingen van Ratonigid ligt besloten dat dit geen veilige situatie was; zij heeft immers een module ontwikkeld om de paswoorden te versleutelen en het was de bedoeling deze op alle verbindingen te installeren, zoals [naam 2] op de comparitie heeft verklaard.
“critical”worden bestempeld, maar dat zij tevens de als “
medium”en
“low”gekarakteriseerde updates uitvoert. Ratonigid heeft onvoldoende toegelicht waarom zij kon volstaan met het doorvoeren van enkel de
“critical”updates en waarom de andere updates niet ook konden worden doorgevoerd. In dit verband wordt veel gewicht toegekend aan het feit dat DigiNotar een certificatiedienstverlener was zodat van haar, gelet op haar ondernemingsactiviteiten (beveiliging van internetverkeer) mocht worden verwacht dat zij wat betreft de beveiliging van haar eigen systemen de grootst mogelijke zorgvuldigheid zou betrachten en daartoe dus alle mogelijke maatregelen zou nemen.
credentialsen de kwetsbaarheden in de oudere versies van DotNetNuke. Ook volgt uit de door Vasco in het geding gebrachte e-mailcorrespondentie uit 2008 en de tekening van de infrastructuur van 22 maart 2009 (steeds als aangehecht aan het [naam 8] rapport) dat Ratonigid ervan op de hoogte was dat (in ieder geval op enig moment) het werkstation DIGIWS146 in verbinding heeft gestaan met zowel het
Office-netals het
Secure-net. Nu zij deze veiligheidsrisico’s heeft laten voortbestaan, kan niet worden gezegd dat zij alle redelijke stappen heeft gezet en alle redelijke procedures heeft geïmplementeerd om de systemen van DigiNotar te beveiligen ten einde een hack zoals zich in de zomer van 2011 heeft voorgedaan te voorkomen.
kon worden achterhaald.(…)”
credentialsals redenen waarom de hack kon slagen. In het IT-Sec rapport 2011 staat:
credentialsdoor de
hackerook daadwerkelijk zijn gebruikt. (zie hiervoor 4.6):
Additionally, on the Main-web server the file web.config was identified that contained a string with credentials to access the database on BAPI-db (…)
On 17 June 2011 the intruder exploits a wellknown DotNetNuke vulnerability on the docproof webservers WINSVR118 and WINSVR119."
, the intruder would not have been able to successfuly execute his attack, using the vulnerabilities and routes as he did”.
hackergebruik heeft gemaakt van een kwetsbaarheid die alleen door versie 5.6.1 kon worden verholpen. In de rapporten staat juist steeds dat het ging om een kwetsbaarheid die voorkwam in de versies ouder dan 4.8.3. DotNetNuke heeft hierover bovendien op 17 maart 2010 op haar website al informatie over bovendien zelf het volgende gepubliceerd.:
Please note, if you're running 4.8.3 or higher (…) this is not a concern from a DotNetNuke perspective. As 4.8.3 has been out for nearly 2 years (released May 23rd 2008), and we've had 20 releases since then we believe theres only a small amount of people on versionsthatold, but we thought it would be good to let people know just in case they are running very old versions.”
hackerwaarschijnlijk door het benutten van een kwetsbaarheid in DotNetNuke het bestand 17.1sp;.gif op WINSVR119 heeft kunnen uploaden (zie hiervoor rov. 4.4). Vervolgens heeft de
hacker, voor zover van belang, het bekende standaard
hackerbestand AspxSpy geïnstalleerd: “a webshell often used by intruders that provides numerous access functionalities on a compromised server” ([naam 8] rapport, p. 80).
hackermet het programma AspxSpy web.config kon doorzoeken. Op de WINSVR101 stonden 112 web.config bestanden, waaronder die met de
credentialsvan de servers in de DigiNotar. infrastructuur:
the intruder was able to manage the compromised servers. With the AspxSpy backdoor in place, the intruder was able to read files on the compromised server. The Aspx.Spy backdoor provides a functionality to search for interesting files like the “Web.config” files usually stored on the webserver containing sensitive information. In this file the credentials of the database users were stored. On the main DigiNotar web server (WINSVR101) 112 Web.config files (including backup files) were present containing database credentials for database servers throughout the DigiNotar network.”).
hackervolgens [naam 8] via WINSVR101 is binnengekomen, faalt omdat het feitelijk onjuist is. In het [naam 8] rapport staat immers (bijvoorbeeld) op pagina 21:
hackergebruik heeft gemaakt van de servers WINSVR118 en WINSV119 om verder door te dringen in het netwerk van DigiNotar door op WINSVR119 het bestand 17.1sp;.gif te installeren.
hackerspeciale programma’s heeft gebruikt om wachtwoorden te kraken (
“brute forcing”),de wachtwoorden kennelijk niet onversleuteld waren opgeslagen. Uit het rapport van [naam 8] blijkt immers, zoals hiervoor is overwogen, dat in ieder geval ook gebruik is gemaakt van de
credentialsdie waren opgeslagen in web.config bestanden.
hackervanaf 1 juli 2011 via het werkstation DIGIWS146 het
Secure-netheeft bereikt ([naam 8] rapport, p. 22:
“(…) we have established that the compromised BAPI-production workstation (DigiWs146) had a dual network interface both to Secure-net and Office-net. The intruder detected this flaw and exploited it starting from 1 July 2011.(…)”).
secure-netlijkt ook te volgen uit het rapport van Fox-IT, waarin staat:
“The separation of critical components was not functioning or was not in place. We have strong indications that the CA-servers, although physically very securely placed in a tempest proof environment, were accessible over the network from the management LAN.”
Nadat nadere informatie hierover was verkregen en ook met het bedrijf was gesproken is het Kabinet tot de conclusie gekomen dat de betrouwbaarheid van de certificaten en diensten van DigiNotar niet langer zonder meer gegarandeerd was en dat mitsdien het vertrouwen in het bedrijf DigiNotar moest worden opgezegd.(…)"
due diligence onderzoekuitsluitend documenten heeft onderzocht die aan haar ter beschikking zijn gesteld. Evenmin is in geschil dat zij voorafgaand aan de overname geen inzage heeft gehad in de rapporten van IT-Sec uit 2006, 2008 en 2009. Dat in een van de documenten die in het kader van de
due diligenceaan Vasco zijn verstrekt staat vermeld dat DigiNotar regelmatig de veiligheid van haar software en infrastructuur liet toetsen door IT-Sec, hoefde voor Vasco – gelet op de afgegeven garanties - geen reden te zijn om de rapporten van IT-Sec op te vragen. Zij mocht er vanuit gaan dat indien er rapporten waren die belangrijke informatie over (gebreken in ) de beveiliging van de software en de IT-systemen van DigiNotar bevatten, deze aan haar ter beschikking zouden zijn gesteld. Dit betekent ook dat in het midden kan blijven of de rapporten van IT-Sec aan PwC zijn verstrekt (zoals Ratonigid stelt en Vasco betwist).
- € 131,00 aan salaris advocaat,