image

Kamervragen over drown-lek in gemeentewebsites

vrijdag 11 maart 2016, 09:59 door Redactie, 23 reacties

PvdA en VVD hebben Kamervragen aan minister Plasterk van Binnenlandse Zaken gesteld naar aanleiding van het drown-lek dat in verschillende gemeentewebsites is aangetroffen. Via drown kan een aanvaller versleutelde verbindingen kraken en zo toegang tot vertrouwelijke gegevens krijgen.

De drown-aanval maakt gebruik van het oude sslv2-protocol dat veel servers nog steeds ondersteunen, maar niet gebruiken voor het opzetten van een versleutelde verbinding. Daarvoor wordt tegenwoordig het tls-protocol gebruikt. Een aanvaller kan tls-verbindingen echter ontsleutelen door probes naar een server te sturen die sslv2 ondersteunt en dezelfde privésleutel gebruikt.

Uit gegevens van Qualys SSL Labs, een website waar de configuratie van webservers die ssl gebruiken kan worden gecontroleerd, blijkt dat er tientallen gemeentewebsites kwetsbaar zijn. RTL testte 175 gemeentewebsites via SSL Labs. Bij 33 websites werd de drown-kwetsbaarheid aangetroffen. Verder bleek dat bij 51 websites de beveiliging niet up-to-date is of dat ze gedeeltelijk voor drown kwetsbaar zijn. Het gaat dan bijvoorbeeld om de webmail van medewerkers of een bepaald onderdeel van de website.

VVD-Kamerleden Veldman en De Caluwé en PvdA-Kamerlid Oosenbrug (PvdA) willen van Plasterk weten welke stappen hij tot nu toe heeft ondernomen om het probleem op te lossen. Ook vragen ze welke maatregelen de minister neemt om de gemeenten ertoe te bewegen maatregelen te treffen om de beveiliging van persoonsgegevens op orde te brengen. Daarnaast moet Plasterk ook laten weten welke rol hij denkt te kunnen spelen om de omgang met privacy door gemeenten te verbeteren.

De Kamerleden vinden dat de Autoriteit Persoonsgegevens de beveiliging van persoonsgegevens bij gemeenten tot hoogste prioriteit moet benoemen en daarnaar moet handelen en willen weten of Plasterk het hiermee eens is. Ook willen de Kamerleden de mening van de minister weten over het niet meer ondersteunen van oudere ssl-technologieën op gemeentewebsites. Verder vragen ze hoe de problemen met de veiligheid van de persoonsgegevens moeten worden gezien in het licht van de afspraak uit het regeerakkoord dat uiterlijk in 2017 bedrijven en burgers zaken met de overheid digitaal kunnen afhandelen. De Kamervragen (pdf) moeten binnen 3 weken zijn beantwoord.

Reacties (23)
11-03-2016, 10:15 door Ron625 - Bijgewerkt: 11-03-2016, 10:16
Er zijn (bijna) geen gemeenten, die zelf de website hosten, deze zijn ondergebracht bij een hosting bedrijf.
Zeg tegen het hosting bedrijf, dat ze 24 uur de tijd hebben om de server goed te configureren, zo niet is het contract per onmiddellijk vervallen wegens wanprestatie, waarbij de kosten voor de overstap voor rekening komen van de nalatige hoster.

In hoeverre dit juridisch mogelijk is, kan ik niet beoordelen.

Verder dient iedere overheidswebsite te voldoen aan de webstandaard-versie-2 en moeten ze ook voldoen aan de W3C standaard.
In de verplichte regels staat ook, dat gebrek aan kennis, gebrek aan tijd en gebrek aan geld, geen geldig excuus zijn, om niet aan de regels te voldoen.
Minder dan de helft voldoet hier aan!
11-03-2016, 10:32 door Anoniem
Ja leuk om de hosting bedrijf 24 uur te geven. Doen ze dat niet, stappen ze over naar de volgende hosting bedrijf die het OOK niet in orde heeft. De meeste hosting bedrijven hebben geen idee wat alle opties zijn met betrekking tot de SSL/TLS configuratie. Zo blijf je bezig.
11-03-2016, 10:34 door Anoniem
Deze is mooi:

Zeg tegen het hosting bedrijf, dat ze 24 uur de tijd hebben om de server goed te configureren, zo niet is het contract per onmiddellijk vervallen wegens wanprestatie, waarbij de kosten voor de overstap voor rekening komen van de nalatige hoster.

In hoeverre dit juridisch mogelijk is, kan ik niet beoordelen.

Ik zou eerst maar zorgen dat je weet waarmee je dreigt..afgezien van het feit dat ik het treurig vind dat blijkbaar er nog zo veel directadmin/howtoforge kneusjes rond lopen die geen kaas hebben gegeten van security.
11-03-2016, 10:50 door Erik van Straten
https://www.ssllabs.com/ssltest/ kan -helaas- uitsluitend https verbindingen testen. Als deze site aangeeft dat een website nog SSLv2 ondersteunt, is de site duidelijk lek.

Echter: als alles daar okay lijkt, is dat geen garantie dat https verbindingen met die website niet alsnog via het DROWN lek kunnen worden aangevallen!

Indien namelijk diezelfde server, en mogelijk zelfs een geheel andere server, hetzelfde certificaat (en dus de bijbehorende private key) gebruikt voor een willekeurig protocol (https, SMTPS, POP3s, IMAPs etc) dat nog wel SSLv2 ondersteunt, kan een MitM aanvaller ook die primaire, volgens SSLLabs veilige verbinding, kraken.

Vooral dit maakt DROWN zo gevaarlijk: je bent niet klaar met een SSLLabs testje.

Denk ook aan alle test-websites en mailservers!
11-03-2016, 10:53 door Anoniem
Ook willen de Kamerleden de mening van de minister weten over het niet meer ondersteunen van oudere ssl-technologieën op gemeentewebsites. Verder vragen ze hoe de problemen met de veiligheid van de persoonsgegevens moeten worden gezien in het licht van de afspraak uit het regeerakkoord dat uiterlijk in 2017 bedrijven en burgers zaken met de overheid digitaal kunnen "OF MOETEN" afhandelen.
En dit is nu waar ik niet gelukkig van wordt, je kunt zelf alles op orde hebben maar je bent zo afhankelijk van derden.
En internet is niet veilig en mischien wordt het dat ook nooit, er zijn zaken die je gewoon aan de balie moet afhandelen.
Geef fraudeurs geen kans en gebruik je verstand.
11-03-2016, 11:24 door Anoniem
Door Erik van Straten: https://www.ssllabs.com/ssltest/ kan -helaas- uitsluitend https verbindingen testen. Als deze site aangeeft dat een website nog SSLv2 ondersteunt, is de site duidelijk lek.

Echter: als alles daar okay lijkt, is dat geen garantie dat https verbindingen met die website niet alsnog via het DROWN lek kunnen worden aangevallen!

Indien namelijk diezelfde server, en mogelijk zelfs een geheel andere server, hetzelfde certificaat (en dus de bijbehorende private key) gebruikt voor een willekeurig protocol (https, SMTPS, POP3s, IMAPs etc) dat nog wel SSLv2 ondersteunt, kan een MitM aanvaller ook die primaire, volgens SSLLabs veilige verbinding, kraken.

Vooral dit maakt DROWN zo gevaarlijk: je bent niet klaar met een SSLLabs testje.

Denk ook aan alle test-websites en mailservers!
Bedankt voor die bijdrage. Kun je als eindgebruiker;
- iets doen in de praktijk,
- om DROWN te mitigeren,
- dat niet (veel te) omslachtig is?
11-03-2016, 11:52 door Ron625
Door Anoniem: Ja leuk om de hosting bedrijf 24 uur te geven.
Ze hebben toch al ruim een week de tijd gehad?
Dit soort dingen mogen ze niet laten wachten, daar moet gelijk op ingesprongen worden.
11-03-2016, 12:42 door Anoniem
Door Ron625:
Door Anoniem: Ja leuk om de hosting bedrijf 24 uur te geven.
Ze hebben toch al ruim een week de tijd gehad?
Dit soort dingen mogen ze niet laten wachten, daar moet gelijk op ingesprongen worden.

In deze wereld geldt: Pas als het kalf verdronken is, dempt men de put. Pas als men geconfronteerd wordt met gegevens die daadwerkelijk gelekt zijn, is er sprake van een serieus lek: Geen gegevens betekent geen urgentie in welke vorm dan ook. Technisch bewijs wordt niet begrepen en is in principe niet interessant. Kost ook geld, en is lastig en zo; who cares ?
11-03-2016, 12:44 door Anoniem
Neem dan meteen een verbod op flash content en trackers mee...
Hee security.nl, dit is ook voor jullie een topic!
11-03-2016, 12:57 door Anoniem
Door Ron625:
Door Anoniem: Ja leuk om de hosting bedrijf 24 uur te geven.
Ze hebben toch al ruim een week de tijd gehad?
Dit soort dingen mogen ze niet laten wachten, daar moet gelijk op ingesprongen worden.

DROWN is meer hype dan echt risico.

Daar kamervragen over stellen demonstreert (helaas) dat de portefeuille ICT/security door fracties aan de kneusjes gegeven wordt.
11-03-2016, 13:18 door Anoniem
Door Erik van Straten: https://www.ssllabs.com/ssltest/ kan -helaas- uitsluitend https verbindingen testen. Als deze site aangeeft dat een website nog SSLv2 ondersteunt, is de site duidelijk lek.

Echter: als alles daar okay lijkt, is dat geen garantie dat https verbindingen met die website niet alsnog via het DROWN lek kunnen worden aangevallen!

Indien namelijk diezelfde server, en mogelijk zelfs een geheel andere server, hetzelfde certificaat (en dus de bijbehorende private key) gebruikt voor een willekeurig protocol (https, SMTPS, POP3s, IMAPs etc) dat nog wel SSLv2 ondersteunt, kan een MitM aanvaller ook die primaire, volgens SSLLabs veilige verbinding, kraken.

Vooral dit maakt DROWN zo gevaarlijk: je bent niet klaar met een SSLLabs testje.

Niet helemaal waar: Qualis kijkt of hetzelfde certificaat elders (onveilig) wordt gebruikt en geeft een F rating wanneer dit het geval is. Gegevens komen uit een database die Censys bijhoudt. Zie voor details: https://blog.qualys.com/securitylabs/2016/03/04/ssl-labs-drown-test-implementation-details
11-03-2016, 13:38 door ph-cofi
De snelheid van verwerken van veiligheidsupdates zou onderwerp moeten zijn van de dienstverlenings-overeenkomsten tussen gemeenten en hun providers. Als dat is vastgelegd, dan mag de gemeente zich eventueel uiten in termen als "wanprestatie", anders heeft de gemeente geen stok om mee te slaan. Hoe zou het zijn gesteld met dergelijke overeenkomsten?

De landelijke overheid zou eisen mogen stellen aan de overeenkomsten of zelfs standaard aan-de-eisen-voldoende leverancierssamenwerkingen hebben ingericht voor de gemeenten. Als het op orde is, hoeft geen 2e kamer lid zich meer zorgen te maken over of updates verspreid worden volgens een afgesproken schema. Hoeveel verantwoordelijkheid zou de overheidsinstelling Informatie Beveiligingsdienst Gemeenten (IBD) hebben op dit gebied? Zou elke gemeente voor zich het wiel moeten uitvinden of krijgen ze hulp van boven?
11-03-2016, 13:47 door Anoniem
Door Ron625:
Door Anoniem: Ja leuk om de hosting bedrijf 24 uur te geven.
Ze hebben toch al ruim een week de tijd gehad?
Dit soort dingen mogen ze niet laten wachten, daar moet gelijk op ingesprongen worden.

Bedoeld wordt dat je eist dat de site 24 uur per dag en 7 dagen per week in de lucht moet zijn.

Ik ben hier ook eens tegen zo'n contract aangelopen. Wat bleek: de provider hield zich er zo goed aan dat ook de maandelijkse restart voor Windows updates niet werd uitgevoerd. Dat zorgde namelijk voor hoge boetes vanwege het niet beschikbaar zijn.

Peter
11-03-2016, 16:58 door Anoniem
Gemeenten hebben lang niet altijd meer zelf de expertise in huis en zijn afhankelijk van hun hostingpartij. Gelukkig zijn er ook gemeenten die een eigen vrijwillig klokkeluider hebben die de gemeentewebsite controleert na meldingen van securitythreaths. Waar (bijna) nooit aan wordt gedacht is het gegeven dat afsprakenformulieren op gemeentewebsites bij hosters keurig netjes onder Https beveiligd kunnen worden ingevuld en vervolgens automatisch vanaf de hoster als bijlage in een plain e-mail naar de gemeente worden verstuurd.
11-03-2016, 17:04 door Erik van Straten
11-03-2016, 13:18 door Anoniem:
Door Erik van Straten:[...]
Vooral dit maakt DROWN zo gevaarlijk: je bent niet klaar met een SSLLabs testje.

Niet helemaal waar: Qualis kijkt of hetzelfde certificaat elders (onveilig) wordt gebruikt en geeft een F rating wanneer dit het geval is. Gegevens komen uit een database die Censys bijhoudt. Zie voor details: https://blog.qualys.com/securitylabs/2016/03/04/ssl-labs-drown-test-implementation-details
Ah, dat wist ik nog niet, hartstikke bedankt voor die link! (https://drownattack.com/#faq-ssllabs klopt dus gelukkig niet meer voor 100%). Ook heel goed van Qualys dat ze dit zo snel hebben opgepakt, en heel handig is natuurlijk dat Censys deze certificaatinformatie beschikbaar stelt (waarbij ik wel hoop dat hun database voldoende up-to-date is).

11-03-2016, 11:24 door Anoniem: Bedankt voor die bijdrage. Kun je als eindgebruiker;
- iets doen in de praktijk,
- om DROWN te mitigeren,
- dat niet (veel te) omslachtig is?
Nee, uit https://drownattack.com/#faq-update (onderstrepen door mij toegevoegd):
Do I need to update my browser?

No. There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack.
11-03-2016, 17:29 door Anoniem
Door Erik van Straten:
11-03-2016, 11:24 door Anoniem: Bedankt voor die bijdrage. Kun je als eindgebruiker;
- iets doen in de praktijk,
- om DROWN te mitigeren,
- dat niet (veel te) omslachtig is?
Nee, uit https://drownattack.com/#faq-update (onderstrepen door mij toegevoegd):
Do I need to update my browser?

No. There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack.
Hartelijk dank voor het antwoord.
Maar ik wordt er niet vrolijk van :(
12-03-2016, 08:15 door Anoniem
Door Anoniem:
Door Erik van Straten:
11-03-2016, 11:24 door Anoniem: Bedankt voor die bijdrage. Kun je als eindgebruiker;
- iets doen in de praktijk,
- om DROWN te mitigeren,
- dat niet (veel te) omslachtig is?
Nee, uit https://drownattack.com/#faq-update (onderstrepen door mij toegevoegd):
Do I need to update my browser?

No. There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack.
Hartelijk dank voor het antwoord.
Maar ik wordt er niet vrolijk van :(
Nogmaals hartelijk bedankt Erik, voor het duidelijke antwoord.
Ik stel het erg op prijs dat je je kennis, ervaring, tijd en inzet gebruikt om ons (of op z'n minst ondergetekende) te informeren. Vooral dat laatste heb ik gisteren niet genoeg benadrukt, mijns inziens.

Sec gezien, kun je nu dus eigenlijk niet meer gebruik maken van een online-dienst, zonder een (makkelijk te voorkomen & reeds bekend) risico te lopen.

Als ik het goed begrijp, kan DROWN worden gebruikt voor iedere verbinding. Dus ook mail / updaters / skype / etc / etc / etc, buiten de browser om.
Al zou je een browser-plugin hebben, die alle certificaten binnen het gehele domein voor je napluist bij iedere verbinding, dan nog loop je het risico dat je AV-pakket niet helemaal jofel is. Afgezien van de privacy-implicaties bij dergelijke controle.

Of begrijp ik het verkeerd?
12-03-2016, 16:43 door Anoniem
Door Ron625:
Door Anoniem: Ja leuk om de hosting bedrijf 24 uur te geven.
Ze hebben toch al ruim een week de tijd gehad?
Dit soort dingen mogen ze niet laten wachten, daar moet gelijk op ingesprongen worden.
En waarom zou dat moeten voor een kwetsbaarheid waarbij de crimineel eerst man in the middle moet zijn en daarna nog eens 500 eur per bezoeker moet uitgeven om de zwakke beveiliging te doorbreken in de hoop dat er iets meer waardevols tussen de gegevens zit.
12-03-2016, 17:01 door Anoniem
Door Anoniem:
Door Anoniem:
Door Erik van Straten:
11-03-2016, 11:24 door Anoniem: Bedankt voor die bijdrage. Kun je als eindgebruiker;
- iets doen in de praktijk,
- om DROWN te mitigeren,
- dat niet (veel te) omslachtig is?
Nee, uit https://drownattack.com/#faq-update (onderstrepen door mij toegevoegd):
Do I need to update my browser?

No. There is nothing practical that web browsers or other client software can do to prevent DROWN. Only server operators are able to take action to protect against the attack.
Hartelijk dank voor het antwoord.
Maar ik wordt er niet vrolijk van :(
Nogmaals hartelijk bedankt Erik, voor het duidelijke antwoord.
Ik stel het erg op prijs dat je je kennis, ervaring, tijd en inzet gebruikt om ons (of op z'n minst ondergetekende) te informeren. Vooral dat laatste heb ik gisteren niet genoeg benadrukt, mijns inziens.

Sec gezien, kun je nu dus eigenlijk niet meer gebruik maken van een online-dienst, zonder een (makkelijk te voorkomen & reeds bekend) risico te lopen.

Als ik het goed begrijp, kan DROWN worden gebruikt voor iedere verbinding. Dus ook mail / updaters / skype / etc / etc / etc, buiten de browser om.
Al zou je een browser-plugin hebben, die alle certificaten binnen het gehele domein voor je napluist bij iedere verbinding, dan nog loop je het risico dat je AV-pakket niet helemaal jofel is. Afgezien van de privacy-implicaties bij dergelijke controle.

Of begrijp ik het verkeerd?

Ja, je begrijpt het verkeerd.
DROWN is m.i. een nogal beperkt risico.

DROWN gaat over het met enige kans op succes _afluisteren_ (dus niet manipuleren, versturen van andere data ) van verbindingen.
Je zorgen over niet jofele (= gemanipuleerde) AV updates zijn dus niet van toepassing

Heel kort samengevat :

Als een verbinding met SSLv2 beveiligd wordt, kan een aanvaller die werk doet een kans van 1/1000 bereiken om een afgeluisterde verbinding die met het betreffende SSLv2 certificaat versleuteld werd te lezen.

Als hetzelfde certificaat gebruikt werd op meerdere servers (mail, web, etc) kan de aanval op één server leiden tot het (met kans 1/1000) afluisteren van _een_ sessie met een andere server.

De aanvaller kan dus niet _kiezen_ welke sessie hij wil afluisteren, alleen een gemiddelde kans bereiken.
De aanval "kost" het opzetten van orde 10,000 ssl sessies en een dagje rekenen .

Er is dus nodig :

1 - aanvaller die op een plek zit om sessies te kunnen afluisteren
2 - een server die SSLv2 gebruikt , en waarvan het certificaat (de key) gebruikt wordt voor die afgeluisterde sessies.
3 - die SSLv2 server moet ~10,000 sessie onderhandelingen toestaan (zonder IDS alarm e.d.)
4 - dan kan de aanvaller met een dag stevig rekenen ca 1 op de 1000 afgeluisterde sessies ontsleutelen.

Vervelend, moet niet, maar voor dit probleem vind ik de aandacht nogal overtrokken.
13-03-2016, 01:24 door SecurityNL
is het misschien zelf de gemeente heeft de aanval gedaan!
13-03-2016, 20:55 door Anoniem
Helaas.....

Kijk als voorbeeld naar de website van RTL.nl:

Protocols
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No

SSLv2 wordt dus niet ondersteund. Echter de site is WEL kwetsbaar voor de DROWN attack.

Experimental: This server is vulnerable to the DROWN attack. Grade set to F.

Achtergrond: Indien een oudere versie van OpenSSL wordt gebruikt, dan kan, ondanks dat de server goed ik geconfigureerd, toch het gebruik van SSLv2 worden afgedwongen. Hiermee kan de private key worden achterhaald (binnen 1 minuut met een standaard PC). Deze private key kan dan worden gebruikt om via (b.v.) TLSv1.2 een verbinding op te bouwen waardoor de verbinding dus gecomprommiteerd is.
14-03-2016, 01:20 door Anoniem
Hallo, laten we de zaak wel een beetje relativeren alstublieft. Niet iedereen heeft 400 dollar aan middelen klaar liggen om een sleutel te kunnen kraken via de DROWn exploit. Dat brengt het gelijk dan weer terug in de juiste proporties en bij de echte initiële geïnteresseerden. Zo krijgt men de cirkel weer rond.
Het blijft wel een gevaarlijk lek en men is er ook niet als de kippen bij om het te patchen. Van alle cloudservers en cloud app diensten is nog maar iets meer als vijf procent onkwetsbaar voor DROWn, bij Heartbleed was even later al 97 procent aan kwetsbaarheid bij de cloudboys verholpen. Ik vermoed dat DROWn nu wel tot `aanval van de vorige week´ is uitverkozen, maar al lang in het geniep is mis-/ of gebruikt. Alles zit vol met gaten en kwetsbaarheden, vergeleken hiermee is gatenkaas nog heilig. De discussie achteraf is meer voor de buehne en voor de niet-techies om wat over te praten te hebben, dunkt mij.
Het zet niet echt zoden aan de dijk!
15-03-2016, 09:57 door Anoniem
Wat een paniek weer. Er komt weer een vulnerability in het nieuws en we springen er boven op.
Wat te denken van alle andere vulnerabilities die nog niet gepatched zijn ?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.