De hacker die het probleem vond en meldde, ontdekte dat inloggegevens van de leverancier aanwezig waren in de broncode van de installatiesoftware. Daarmee kon hij inloggen op de infrastructuur van de leverancier, waaronder het deel van de infrastructuur waar de stemmentelsoftware was ondergebracht.

https://nos.nl/artikel/2490218-hacker-ontdekt-kwetsbaarheid-in-telsoftware-verkiezingen-minder-dan-uur-werk

Goed idee hoor, dat gebruik van computers bij het belangrijkste democratische proces dat we hebben ....

Dit waren geen kwetsbaarheden, dit waren features...

Details: https://www.zerocopter.com/blog-en/the-importance-of-post-build-audits-do-you-know-what-you-ship

Bron: https://www.nu.nl/tech/6280588/lek-in-optelsoftware-kon-pogingen-tot-manipulatie-opleveren-bij-verkiezingen.html

Tijdens het stemmen worden er geen computers gebruikt.

En dat alleen maar omdat een paar burgermeesters onderling een wedstrijdje hebben "wie is er het eerste klaar"

Gewoon een week uitrekken voor het stemmen tellen, dan hoeft dat ook niet meer midden in de nacht te gebeuren. Kunnen hertelling plaats vinden als de getallen tijdens tellen niet meer kloppen, en wordt alles in 1x bekend gemaakt.

Die ene week maakt in het geheel van kabinets vorming ook niet uit.

Het beveiligingsprobleem is waarschijnlijk nooit opgemerkt omdat bij eerdere beveiligingstests de installatiesoftware nooit is onderzocht.
Dat is toch wel heel bijzonder?!

Het is de module die de politiek partijen in staat stelt om de leden te registreren op een kieslijst. Die is openbaar te downloaden? Valt ook wat van te zeggen. Los van het feit dat het testproces van zulke software te wensen overlaat.

Tijdens het stem-proces


Wat doen de inloggegevens van de leverancier in een installer, of wordt er tijdens het installeren contact gemaakt met de server van de leverancier om te kijken of er ondertussen updates zijn uitgekomen.
En dan is de kiesraad nu al tevreden dat 'de leverancier' aangeeft dat ze het gepruts hebben verholpen!
Gepruts waarmee je door reverse enginering of simpelweg de installer in een debugger te openen om te zien wat tie doet en met die info zelf de connectie maken en daarmee nog meer info kan achterhalen om in het interne netwerk van de PRUTS-leverancier te komen en daar misschien zelf de OSV software van een (bv. FvD-)updatje te voorzien:

Dat je niet alle communicatie/gevolgen te horen krijgt, snap ik engzins wel,
maar alleen communiceren dat de beveiligingslekken door de pruts-leverancier zijn verholpen en het daar bij laten qua communicatie naar de burger, heeft toch wel een aardige wij-van-wc-eend-gehalte.
btw, Een installer om getalletjes bij elkaar op te tellen¿, dat zou toch in 1 executable te doen moeten zijn, dus zonder verdere afhankelijkheden van het OS, met een MD5/SHA checksum. Of haken ambtenaren dan af (zoals Rutte zou zeggen), "dat is te ingewikkeld, te complex".

Dat is toch wel heel bijzonder amateuristisch!

Waarom toch altijd maar weer aan dat dooie paard blijven trekken?

COMPUTERS EN HET VERKIEZINGSPROCES GAAN NIET SAMEN!!!!

https://www.security.nl/posting/41083/ 2013
https://www.security.nl/posting/18658/Kabinet+schaft+stemmen+met+computer+voorlopig+af 2008

Dan maar met de hand gaan optellen en delen?
https://nos.nl/artikel/2156116-kiesraad-moeten-we-met-rekenmachines-aan-de-slag

Al klopt dat natuurlijk ook niet met jouw opmerking. Een rekenmachine is ook een computer. Excel draait ook op een computer.

Peter

Maar wat dan wel?

Een telraam gebruiken?

Hoofdrekenen is ook niet meer vanzelfsprekend tegenwoordig.
En netjes leesbaar schrijven met de hand (om foutloos te kunnen optellen met pen en papier) wordt ook steeds moeilijker. (ty[en is makkelijker)

Inderdaad ja, het belang van een transparant en traceerbaar verkiezingsproces is vele malen belangrijker dan de snelheid van het verkrijgen van een uitslag. Maar dan komen de heren en dames bestuurders weer met argumenten als: "Niet meer van deze tijd", "enorme belasting van de gemeenteambtenaren", etc.

Verkiezingen zijn een fundamenteel onderdeel van onze democratische rechtstaat en dus veel te belangrijk om aan computers (en de prutsers die ze maken en programmeren) over te laten.

Ik vroeg me all af waar al die BBB stemmen plotseling vandaag kwamen

Vorige keer stemde dit botnet volledig ol FvD

Dat Hackdefense en de Kiesraad zijn volgens mij nog niet helemaal bij de les.

Allereerst zie ik in de werkinstructie voor de Kieslijst registratie software dat de boel per zip bestand wordt aangeleverd. Ik hoop sowieso per fysiek zijnde een read-only medium, dus niet per read-only usb of een ander software matig rewriteble op rd-only ingesteld medium of iets dergelijks, maar dat terzijde.
Ook al is dat lastig aangezien veel client computers wellicht geen plek meer hebben voor een disk medium en ze verdommen om een externe lezer te kopen.
Verder bevat Zip langstaand allerlei lekken en is het ook weer een extra schakel. Twee redenen om niet met zip, rar of wat dan ook te werken.

Ook valt me op dat de uitleg enkel Excel noemt.
Het noemt geen Libre/Openoffice terwijl de kiesraad/overheid website wel formulieren in bijvoorbeeld odt formaat aanlevert. Merk op dat Libre/Openoffice in elk geval server software bevat. Bij Microsoft Office weet ik het niet. En Google Docs en dergelijke werken indien via de browser in elk geval met client-software. Het belang van de meer mogelijkheden dan alleen Excel kom ik hieronder op terug bij server/client opmerkingen, voor zover dat al niet voor zich spreekt in relatie tot security van computers.

11. Overeenkomst van de ingeleverde documenten met het elektronisch bestand.
--------- Dat betekent om de 1 of andere onnodige reden dat er kennelijk ook elektronisch nog bestanden voor de registratie aangeleverd kunnen worden. Onnodig, want dat kan leiden tot verschillen en de papieren versie (Formulier H1) is leidend. Dus elektronisch aanleveren is extra werk. En kans op lekken.

Als u een waarschuwing over de verbinding krijgt - Als u een waarschuwing over de verbinding krijgt U kunt een waarschuwing krijgen over de verbinding als u een andere browser gebruikt of vanaf een ander systeem de webapplicatie benadert. U kunt deze waarschuwing negeren en het risico aanvaarden. Daarna zal het OSV2020-PP aanmeldscherm verschijnen.
--------- Er is dus duidelijk een onderkenning van risico, maar noem hier dan ten minste ook bij dat er extra gecontroleerd moet worden of de computer air-gapped is.

https://www.kiesraad.nl/binaries/kiesraad/documenten/formulieren/2023/8/24/stappenplan-osv2020-programma-politieke-partij-tweede-kamer-2023/Stappenplan_OSV2020-PP.pdf

https://www.kiesraad.nl/adviezen-en-publicaties/rapporten/2023/9/12/rapport-pentest-osv2020-tk-module-pp

Kijk je naar de pentest rapportage van de registratie software zelf valt het volgende bijvoorbeeld op.
1Ondanks het hierboven beschreven systeem en onze best mogelijke inschatting is het vaststellen van
zakelijke risico’s formeel geen onderdeel van ons onderzoek. We bevelen dan ook aan om uw eigen risico-
inschatting te maken voordat u prioriteiten bepaalt voor het oplossen van de door ons gedane bevindingen.
--------- Het zelf doen van een risico-inschatting door de opdrachtgever - de Kiesraad - is wel een hele belangrijke en logische aanbeveling. Risico's zijn immers altijd in the eye of the beholder en dus afhankelijk van je vertrekpunt en je afwegingen.
De uitleg voor lage en info risico vermeldingen is wel elegant en zegt ons dat HackDefense breder wil kijken en de lezer erop wijst dat de risico's anders kunnen zijn dan sec voor Hackdefense logisch kan zijn. Bijvoorbeeld doordat de Kiesraad of kiezers een andere voorgeschiedenis hebben en aan bepaalde zaken een ander belang hechten.
Maar de benadering van risico's door Hackdefense dat ze pas bij midden hoge risico's differentieren naar "er is een risico maar het is niet accuut" en niet ook nog eens naar "kleine kans maar grote impact is" uitsplitsen is voor iets als verkiezingproces wel relevant.
HackDefense gebruikt CVSS voor haar scoring maar hanteert zelf in haar definities opeens risico's voor scoring.
En welke van de https://www.first.org/cvss/v4.0/user-guide CVSS-B, CVSS-BE, CVSS-BT of CVSS-BTE gebruikte HackDefense?
En zegt ons ook dat een score met de uitgebreide scoring variant model dus niet precies hetzelfde is als een risico.
Dus hoe komt HackDefense van een score nou wel tot een risico? Dat laatste is impliceert kans x effect kwantificering.
Afgaande op zegt me dat lage scores eerder ongeadresseerd kunnen blijven dan hogere scores.
De CVSS refereert voor zover mij duidelijk is vooral naar de complexiteit en het risico-pad waarlangs het risico kan optreden.
Met de opmerking dat kleine kans-grote impact voor inschrijving van kieslijsten minder grote impact overall kan hebben voor het PROCES en vertrouwen / efficiency is wel te hopen dat HackDefense en Kiesraad voor gebruik van de optelsoftware er beter hebben uitgeplitst of dat de risico-definities alsnog met hoogste spoed verder uit te werken. Dan hebben we tenminste eenduidige gestructureerde vertrekpunt voor risico's naast de scoring. Bijvoorbeeld, wat doet het eventueel niet kunnen uitsluiten van rest-risico's voor de scoring?

Na de gedane pentesten in elk geval voor 1 augustus 2023 zijn er diverse software updates gekomen voor Mac OS, Safari, Firefox en tal van relevante software. Een her-test blijven doen t/m 9 oktober is wel enorm logisch. En dan nemen ze hopenlijk ook dat de telsoftware mee.

Ook is de pentest alleen op Windos 10 gelukt, op Windows 11 kregen ze het niet draaiende.
Was dus een vervolgtest voor nodig lijkt me. Is die ook gedaan?
Ten tweede zijn er voor Mac OS al minstens 3 versies leidend, macOS Monterey - macOS Ventura - Big Sur. HackDefense gebruikte maar 1 versie van MacOS bij het testen. Een misser wat mij betreft.
Zie https://support.apple.com/en-us/HT201222
En bovendien zie ik op pagina 26 van het rapport onder Installatie-bestanden geen .dmg bestandsnamen vermeld en ook geen mac-installer.sh. Tikkeltje verwarrend op z'n minst voor een "standaard" politieke partij gebruiker.
Onder Linux is onder Debian getest, het is minder waarschijnlijk dat er eventueel met Ubuntu, Mint of andere varianten wordt gewerkt bij gemeenten waar de registraties worden gedaan, maar de partijen zouden natuurlijk wel een Linux computer met iets anders dan Debian hebben kunnen gebruikt.

Onderzoeksvragen:
In hoeverre zijn de IT-componenten waarvan OSV2020 TK - Module PP gebruik-maakt (te weten: de applicatieserversoftware en databaseserver) gehardend conform Industry Best Practices? Deze module (OSV2020-PP) omvat geen applicatie- of database-servers, dus deze vraag is niet van toepassing op het onderzoeksobject.
--------- Je moet natuurlijk ook kijken naar de client-side software kant en niet enkel de server side van de software. Dat heeft lekken in tal van client-software natuurlijk ook wel geleerd. Dus de vraagstelling is in beginsel al te beperkt.
Maar, het antwoord dat HackDefense geeft spant wel de kroon.
Dat de module die software niet zelf omvat roept de vraag op waar de localhost dan op draait? Dus had Hackdefense gezien haar "Expertise" natuurlijk zelf iets over kwetsbaarheden van client side software moeten aanvullen.
En de OSV2020-PP software zelf is natuurlijk niet de enige plek die database of applicatieserver lekken kan hebben.
De beantwoording is dus veel te smal.
Kans is met Windows en Linux omgevingen dat de OSV2020 TK - Module PP ook in een omgeving draait met meer dan 1 applicatie of databaseserver. Ik ben geen software ontwikkelaar maar volgens mij zijn de instellingen voor browsers bij bijvoorbeeld chrome en firefox ook in applicatie server architectuur.
Daarnaast bevat Mac OS bij mijn weten standaard al Apache.
En dan kan er in geval van een Linux computer zeker nog tal van andere (kleine) server software draaien op de computer waar de module PP wordt gerund.
En als je het hebt over localhost waar naartoe moet worden genavigeerd, waar draait dat dan op?? Juist ja.
En "A.6 No Referrer Policy The web server does not define whether the browser may pass the page address
to subsequent pages." zegt ons ook dat de Module PP op web server software draait.
Dus waarom doet Hackdefense zich bij de beantwoording van de onderzoeksvraag zich er zo beperkt van af?
Zowel de uitgevoerde testen, de inrichting van de computer en applicatie als de algehele logica achter de onderzoeksvraag schreeuwen erom dat HackDefense het beter uitlegt en de hele lading dekt.
Dat mogen we van een professionele organisatie voor zoiets belangrijks bovendien ook wel verwachten.
We mogen hier meer verwachten dan een u vraagt wij draaien benadering en ook de contractering waarop basis HackDefense uberhaupt een partij is voor de Kiesraad is daar duidelijk over geweest.

A.1 No upload restriction
No upload restrictions apply when uploading a logo.
--------- Een plaatje met je logo kunnen oploaden is onnodige franje. En het ondermijnt het air-gapped principe.
Het introduceert namelijk dat je ergens het bedoelde type .svg, .jpg, .png of .jpeg. bestand ergens vandaan haalt.
Hetzij via email, een analoge beeld-scanner, AirDrop, Bluetooth verbinding of usb/sd-card, het is niet meer air-gapped.
En afhankelijk van de regiditeit van de inlees-code voor de logo's om ze in het formulier te plaatsen kan het ook nog eens tolerant zijn voor in het plaatjes-bestand ingebakken kwetsbaarheden. De zogenaamde embedded code.
Dus bij dit risico had HackDefense voor "less is more" moeten adviseren.

A.4 Hostname in cookie
The web application uses the hostname at the end in the value of the cookie.
Because the application runs on the system itself and a possible attacker can already request the hostname itself, this poses no risk.
--------- ze gaan hier dus ervan uit dat de applicatie altijd zelfstandig draait, maar die vlieger gaat zeker niet per se op. Denk alleen al aan de localhost voorwaarden en de verschillende software omgevingen waar al apache op draait of op kan draaien. en we weten dat de boel breder ontregeld kan raken. Betrekt daarbij dat de gebruiker wellicht via een besmetting of gat in beveiliging een logo heeft geimpoteerd en het is duidelijk dat we hier een combinatie van risico's te maken kunnen krijgen.
De risico toelichting illustreert dat ze de url verwijzing van het cookie konden aanpassen waardoor via een achterdeur een extra lek kan ontstaan.
Dit risico zou dus zeker niet op 0,0 hadden mogen worden ingeschat.

A.8 No lockout mechanism
--------- Dat moet natuurlijk van context worden voorzien.
Dat HackDefense wel erover vermeld dat het het risico mitigeert van een onbeheerde computer maar dat ze het risico ervan even verderop zelf op 0 inschaalt vraagt al om toelichting voor meelezers. Welke risico-analyse bril of uitleg heeft ze hiervoor gehanteerd?
De kans dat een computer voor de korte duur waarop de lijst registratie wordt opgesteld onbeheerd wordt gelaten is gewoon 0,0? Hoezo? Het is niet vanzelfsprekend nul.
De kans is aanwezig maar een eventueel gewijzigde inschrijving lijst tijdig wordt ontdekt?
Bij het inleveren door de hoofdverantwoordelijke en kandidaten in te leveren formulieren worden bepaalde dingen natuurlijk wel duidelijk maar het gebeurt soms wel eens dat iemand zelf niet door had dat een letter of hoofdletter of iets anders op ondersteunende documenten anders zijn dan op het hoofdformulier is ingevuld. Om dus maar aan te geven dat het niet allemaal vanzelfsprekend klopt.
Dus van deze check uitgaan is geen sluitende ondervanging voor de aanname dat het genoemde risico sowieso nul is.
Er blijft sowieso een rest-risico, bijvoorbeeld vanwege de mogelijkheid van zogenaamde no-click aanvallen.
En hoezo introduceert een wel aanwezig lock-out mechanisme niet ook juist nieuwe risico's? Dat is ook wel gebleken gezien trucs van malware om bij afwezigheid van een gebruiker even snel content of rechten op de computer te veranderen.