How to hack the upcoming Dutch elections – and how hackers could have hacked all Dutch elections since 2009

As everybody has read in the newspapers, the recent American elections involved multiple and severe hacking attacks. Tens of thousands of confidential and private emails from Hillary Clinton and the Democratic National Committee (DNC) were leaked via WikiLeaks. It is thought by many that this helped Trump to win the election.

Journalists from Dutch TV station RTL contacted me last week and wanted to know whether the Dutch elections could be hacked. They had been tipped off that the current Dutch electoral software used weak cryptography in certain parts of its system (SHA1).

I was stunned and couldn’t believe what I had just heard. Are we still relying on computers for our voting process?

Voting machines banned in 2009The Dutch government banned electronic voting for cyber security reasons on June 4th, 2009. We returned to using red pencil and paper and have done so ever since. This video demonstrates the manual vote counting process in The Netherlands that is active since 2009:

Seems pretty solid right with all the visible paper? Hold on! RTL told me that voters use pencil and paper, and that votes are counted manually. However, for efficiency reasons the vote totals are then, for each city, entered into a computer program by election officials.

Voting machines have continued to be used in the background since 2009This computer program generates multiple files containing the voting total entered by the election official from each district. The data is put on a USB-stick and transferred to a higher district, and so on. In the end the central Electoral Council gets all votes combined in a digital file.

Critical weakness in voting systemIf nobody questions the (digital) results of the election, no final paper audit is performed to see if the analog and digital vote count is the same.

I immediately realized that this optional final paper audit forms a critical weakness in our current voting system (risk #1 critical). It means that our pencil-and-paper voting is basically security theater in its current implementation. Because when analog voting results are inserted into computers, which subsequently calculate the results, we are still, effectively, using electronic voting.

I was both amazed and frightened by this fact.

Anyone with a certain level of IT-security knowledge will tell you that a computer cannot be trusted. Whatever steps you take to secure a computer, it will always be possible to hack it. And against state-sponsored hackers you have almost zero chance. To put it bluntly: you can’t protect a computer system against experienced and well-funded state-employed hackers.

Electoral Council unaware of current cyber threatsThe Dutch Electoral Council is massively unaware of possible cyber threats and simply states their software is secure and everything is under control.

I became curious about this software which (since 2009) has quietly decided who gets to run my country.

First start: YouTube
The Dutch Electoral Council made several YouTube-instruction videos on using their software. I thought this would make a good start for my investigation. In one video an instructor from the Electoral Council explains how to perform an election recount with their software:

Instructor leaks internal network share-namesThe beginning of the video is rather boring but it becomes interesting at 01:19 minutes. The instructor has opened Windows Explorer and as many as eight internal network shares (from an internal server called Amsterdam) are shortly visible:

The set-up of internal networks is considered confidential technical information. Unfortunately, the instructor remains unaware of this leak (risk #2 very low). I get the feeling that this introduction into our voting system is getting interesting!

Desktop voting-software uses web serverWhile the instruction video continues I noticed the voting-software initial installs a web server on the user’s computer. Users have to open a web browser before they can use the voting-software. From a security standpoint it is a very bad idea to use a web server and browser for an ordinary desktop application (risk #3 medium):

Introducing a web server on a desktop in order to run a desktop-only application creates a significant attack surface for hackers.

The voting-software does not use the internet to communicate data. Also, all voting-software can be used offline. So there is absolutely no need to start opening TCP ports on a computer.

The web server can possibly be accessed by others on the network if the host-based firewall is missing or misconfigured.

If the router supports United Plug and Play (UPnP) this can cause the voting web server to be directly reachable from the internet. And really, that is the last thing you want!

In conclusion: a very odd and insecure digital architecture was chosen for the voting software.

Voting software can be installed on any computerTo go even further, the voting software-application can be installed on any computer. The Dutch Electoral Council has not set up any security baseline for this (risk #4 high):

Old computers that lack security updates can be used. This applies equally to computers without anti-virus scanners.

Personal (BYOD) computers are not prohibited.

Windows XP computers are supported according to the system requirements of the software. All Chrome and Firefox versions also, even those with missing security patches.

If you want to create a high security level then please use only properly secured computers without internet/network connection (air-gapped).

The system requirements document for the software state that WiFi should be turned off on the computer, but nowhere it’s mentioned that the internet cable should be unplugged from the computer. This omission made me giggle, but when reality kicked back in, I was shocked.

Unsecured HTTP connection used
The browser for the election software connects to a local host via an unsecured HTTP connection (risk #5 medium). Since the browser-traffic doesn’t leave the computer it is not an immediate threat. Even so, this introduces various security risks, such as:

Possibly leaking HTTP referrer headers to other websites when the voting web portal contains links to other external sites.

Creating a cyber attack surface between web browser and server. This can be intercepted and altered by other malicious software which could already be active on the computer on which the software is installed.

If an HTTPS connection is active, the web browser activates several additional security measures such as tightening web page cache settings.

In conclusion: even HTTP traffic that only travels on a local host should be secured with HTTPS.

Instruction manual doesn’t enforce hash check and bad cryptoI am now two-and-a-half minutes into the instruction video (02:41) when I see the following screen:

The instructor remains quiet and quickly clicks the ‘yes’ button to proceed to the next screen. Hey, hold on – what did I see there? I rewind the video and see a very important security question being asked by the voting-software in which the user has to manually compare a 40 character code to see if the election has been tampered with. Yet the instructor does not mention this important security check at all (risk #6 high). Worse, the voting-software doesn’t even force the user to enter the hash code (risk #7 high). Shockingly they seem to use the insecure, old and deprecated SHA1 hash algorithm RTL told me already about (risk#8 high).

Usage of SHA1 seems to be only a small problem in comparison about what comes next.

Hash codes sent together with data filesAt 02:52 into the instruction video I see the following screen:

The PDF files contain the SHA1 hash code which protects the XML files. The XML files contain important data from the election. It’s of utmost importance that the XML files are of high integrity because these can contain voting totals on election day. To protect the integrity of the XML files, a SHA1 hash code is generated so the XML file can later be checked on generating this same SHA1 code. Manipulating the XML file by hacking, results in the generation of a completely different SHA1 code.

Creation process of PDF and XML fileThe moment the voting software generates XML files containing the voting totals, an accompanying PDF file is created with a specific SHA1 code (this PDF file is probably created for print use). The (paper) printed SHA1 code cannot be remotely changed by hackers.

These files are subsequently copied onto an USB stick. This USB stick is then physically transferred to a higher election district. This higher district collects all the USB sticks from the lower election districts and loads all the XML files into the voting-software.

Unprotected XML filesThe XML file generated by the voting-software is not encrypted. Basically anybody can change the contents during transit (risk #9 high).

Generated PDFs should be deleted after printing
The user of the voting-software should print the PDF files, then immediately delete them. Unfortunately the video-instructor did not find it necessary to do so, and even leaves them sitting next to the XML files (risk #10 medium). The computer system does not mention this step nor enforces you to delete the PDF files (risk #11 medium). Printing the PDF files is optional so might not be done. Instead, users can open the PDF files on the USB stick while importing the XML files on to the next computer. After all, who wants to handle paper prints if there is a digital option?

When explaining the SHA1 check, the instructor even shows how you can validate the SHA1 hash by showing the PDF file in a PDF reader:

I think the instructor doesn’t know that the architect of the OSV software probably wants users that they print the PDF file. The architect designed the system, but it seems that this person doesn’t review the generated (YouTube) documentation about it (risk #12 medium).

Transferring the XML file from one vote-counting computer to the next raises a critical cyber security risk as it is almost certain that non-encrypted USB sticks are being used (risk #13 high). These USB sticks carry non-encrypted XML files and the only protection lies in the apparent security of the SHA1 code. But that code is also transferred via a PDF file on to the USB stick.

The fact that USB sticks are used in the process is a serious shortcoming in the security of the voting-software as you should never insert an unknown USB stick into your computer. Doing so can result in your computer getting hacked via:

Malicious software on the USB stick that is automatically executed by the computer (via AutoRun technology).

The instructor types ‘OSV’ and hits the TAB key. His web browser then auto-completes the password (risk #15 medium), yet the instructor does not notice this and manually enters his three letter password (risk #16 medium). This is funny, I bet his password is also ‘OSV’ …

Apparently a non-personal account is being used (risk # 17 low) and the computer-system allows weak passwords to be configured (risk #18 medium).

The USB stick is very vulnerable to manipulation during the time it travels all those kilometers to a higher election district.

Secret identification code put into address bar
After having passed the login screen the instructor hovers over a link in the web portal and Internet Explorer shows its internet address:

Look closely and you’ll notice the Java session identifier is visible in the internet address (risk #19 low). This is an important token that should only be stored safely in a well protected cookie (that is, with HttpOnly, Secure and SameSite options set):

When a hacker is able to copy the token he/she can bypass the login screen.

As the web portal runs over an non-secured HTTP connection, this token can also leak to other websites.

Also, the token will be saved in the browser history.

Running software under administrator privilegesI am now at 03:44 minutes into this epic instruction video and I notice that the instructor seems to be running Windows via an administrator account:

This is possible only if the instructor has administrative rights on Windows (risk #20 medium). It is really not a good idea to run a daily task with high-privilege access. The instructor should instead have used a low privileged account to run this software.

The makers of this voting-software don’t seem to be familiar with the concept of user isolation or hardening. Thus the voting-software saves user files by default into the normally restricted C:/Program Files/ directory (risk #21 medium).

Malware can easily tamper with votes
The instruction video is now at 04:08 minutes and shows a generated XML file. The instructor again has to import the file via the user interface:

Since the file has just been generated on the very same computer no automatic SHA1 hash check is in place (risk #22 high).

The computer running the vote-counting software can easily be infected with malware during daily use while browsing the internet or reading mail. If indeed the computer contains malware which specifically targets the election, then it only has to change the XML file in the C:\Program Files (x86)\OSV\ directory. Because the XML file is not encrypted, no automatic hash check is in place. Changing the XML files is extremely easy to do once a hacker has managed to gain remote access to the computer.

XML files are being mailed during use of voting-softwareAt 04:45 minutes into the instruction video the voting-software tells the user to mail XML files with voting-results to the central electoral council:

E-mail is not encrypted and therefore a very insecure medium (risk #23 high). What were these software developers even thinking? Doesn’t security matter? How can you send voting results via unsecured e-mail? It is unbelievably easy to intercept and alter e-mail messages.

No printing instructions for PDF file
After finishing this five minute YouTube instruction video, I start the second one:

This two-minute video gives instructions on finalizing vote counting totals. It instructs on how to generate PDF and XML files with vote totals. The instructor mentions that you should save the PDF and XML file on an USB stick and transfer it to the next computer; but printing the PDF file is never mentioned once. Apparently this is how our vote-counting process is performed!

Implemented crypto system is getting worseAfter finishing the second instruction video I start the third one. It’s about configuring the election data. Here you first have to understand that the electoral council has implemented additional security measures in the original specification, and then, this specification was realized by a German software development company.

When importing an XML file from another computer, the user is normally shown a 40 character SHA1 code in the web portal. Below to this code you see a ‘next’ button. Only if the user finds it necessary to do so, does he/she compares the SHA1 code in the web portal with the SHA1 code in the PDF file (which in turn is on the USB stick).

Because configuring election data requires additional security, the German developer came up with a solution that the user has to enter the first four characters of the SHA1 code that’s visible in the PDF-file into the web portal. Meanwhile the 36 remaining characters remain visible on the screen:

The instructor explains how to use this screen

“[…] You will be prompted to enter the hash code from the uploaded candidate list. This hash code can be found on the website of the Kiesraad (electoral college), or possibly in the file [..] that is located in the same folder where you found the candidate file. […]”

Both screen and instructions limit the strength of the SHA1 key to 2^16 combinations. That’s just 65,536 possibilities and delivers almost zero cryptographic strength (risk #24 high). A normal SHA1 key provides 160 bits strength and that’s 2^160 possibilities – a vastly larger number. This means the additional security requirements caused exactly the opposite: almost no security at all! And, unfortunately, this additional requirement is in place in many more XML import routines.

Additional vulnerabilitiesI can go on and on listing additional insecurities in this voting system, such as:

Internet connected computers.

No IT security expert was consulted when building this software.

It’s partly open source.

About a cross-site scripting vulnerability I found.

Logs are not collected on a central server and thus easy to tamper with.

No intrusion detection systems are active.

No experienced ethical hacker has reviewed the software.

No security test reports are available.

The integrity of the software is hard to validate, and even optional.

Etc.

To save time, I hope I made my point already and thus will not write about further vulnerabilities in this horribly insecure voting software.

Nowhere in the hundreds of pages of documentation I read about the software, mention the fact that a hacker might tamper with the election results. It seems the Election Council and the hired software development company simply forgot about the hacker threat. This is almost unbelievable, but then again: my security research proves it’s very easy for just one person to manipulate the election results on so many levels.

ConclusionWill we ever learn that our important voting process simply cannot be trusted when critical elements are outsourced to software? Our Dutch democracy has been in the hands of very badly protected software since 2009. We’ve run already ten elections with it and in March 2017 we’ll use it again if nothing changes.

I could already find security holes by doing nothing more than watching a few YouTube instruction videos and reading some system documentation. And this only took me one evening to do so (!).

If I can find these security holes this easily, others can as well. This means no proper IT security specialist was consulted for the development of the voting-software. Instead, some incompetent German software development company was hired to build the digital voting system and no proper oversight was conducted by our Electoral Council. Apparently nobody thought about hiring an ethical hacker or security specialist to see if the system could be hacked. This is pure madness and far beyond what I had ever expected to find.

I hope that with this publication we will finally realize that voting should never be fully performed digitally since software can so easily be manipulated. Pencil-and-paper voting should be the only option. Furthermore, strict audits should be enforced, six-eyes procedures deployed as standard, with regular and obligatory consultations of senior IT security specialists and cryptography experts.

In conclusion, it is not hard to make the voting-process secure. But only the right experts should be involved.

An in-depth forensic research should be conducted to check if our elections have been manipulated since 2009. I hope our Electoral Council keeps logs so that investigators can review these. This probably won’t be the case since almost all the log files are stored on the individual desktop computers of all the people using the voting-software. Thus, unfortunately, we may never know if our elections have been hacked in the past.

I truly hope that from this moment on the Dutch government will take election security way more seriously. Because the status quo is totally unacceptable!

Overview of all identified risk

Critical: Optional final paper audit.

Very low: Eight internal network shares (from an internal server called Amsterdam) are visible in a YouTube video

Medium: The voting-software initial installs a web server on the user’s computer. Users have to open a web browser before they can use the voting-software.

High: The voting software-application can be installed on any computer.

Medium: The browser for the election software connects to a local host via an unsecured HTTP connection.

High: Instructor skips important SHA1 check in YouTube video.

High: Voting software allows skipping SHA1 check.

High: The insecure, old and deprecated SHA1 hash algorithm is used everywhere in the software.

Update January 30, 2017: RTL News TV broadcast
I’ve worked together with the RTL News research redaction when writing this story. They contacted additional security experts, such as Rop Gonggrijp, Ger Schinkel and Herbert Bos who validated my research. RTL News went live with the story on Dutch TV:

Update January 31, 2017: NOS TV broadcast
NOS about the story and a reaction from the responsible minister:

Update January 31, 2017: Election Council ignores security vulnerabilities for years
It appears that six years ago, university student Maarten Engberts already found out that this voting software was insecure. He confronted the Election Council in 2011, but they ignored all his findings.

Update February 1, 2017: Dutch minister responds
Two days after publication of this article, the responsible Dutch minister Ronald Plasterk ordered the dismission of electronic vote count machines in the upcoming election in March 2017.

Update February 3, 2017: USA Today made an overview
After publication of this article, a lot has happened. The USA Today may a quick overview:

Update February 4, 2017: Overview of Tv coverage
Someone combined Tv coverage of the last few days about this research. Includes reactions from Alexander Pechtold (D66), Sybrand Buma (CDA) and Ronald Plasterk (VVD):

Update March 2, 2017: Fox-IT confirms my research
The Electoral Council hired the well respected Dutch cyber security firm Fox-IT to investigate the security of the current election process. In their detailed analysis (PDF 90 pages, recommended read), Fox-IT confirms almost all my findings.

Update March 3, 2017: AFP video interview
Journalists from AFP took the following video interview, and released it in raw stock material on GettyImages for others to take over:

Update March 9, 2017: Vlog from Michael Hilberer about German election security
The vulnerable vote count software in The Netherlands is made by a German company. That same company used a modified version of the Dutch software for use in German elections. More about it in the vlog from Michael Hilberer:

46 Responses to How to hack the upcoming Dutch elections – and how hackers could have hacked all Dutch elections since 2009

As mentioned in the blog post: Ondersteunende Software Verkiezingen (OSV) is partially (or even mostly?) open source software. Its source code can be downloaded from the website of the Electoral Council (kiesraad.nl). Anyone with an eye for software engineering can see that the source code is too disorganised to be auditable and that the tests are woefully incomplete. I doubt the Electoral Council performed a software audit of any sort.

In Germany the same OSV software is used. Germany only uses the software for quickly couting all the votes, but will also perform a separate final paper based audit. So, critical finding #1 (optional paper audit) can not be applied to Germany, and thus that makes the situation in Germany much less dangerous.

Since our government has no clue on Information Security hwatsoever (as we can see in numerous other systems and handling of personal information by various governmental institutions) I am actually hardly surprised.
I would even go as far as that the PDF mentioned above is probably put on the same USB stick with the voting data, making it almost childs’ play to rig the Dutch elections.

“Tens of thousands of confidential and private emails from Hillary Clinton and the Democratic National Committee (DNC) were leaked via WikiLeaks. It is thought by many that this helped Trump to win the election.”

I stopped reading there. Trump did not win because the DNC was hacked. But because their candidate was incompetent, he campaigned properly and the DNC is a mess. The emails never received mainstream coverage. Can you please refrain from insinuations without proof?

Thank you. Can you describe the audits used in the Netherlands? That’s the main protection we have.

As you note, computers can’t be trusted, and the cleanest argument for that that I’ve seen in the election world is the paper on “Software Independence” (Wack and Rivest): http://vote.nist.gov/SI-in-voting.pdf
So we should make sure that the systems and procedures used in elections produce evidence suitable for efficient auditing, as discussed in “Evidence-Based Elections ” by Stark and Wagner:http://statistics.berkeley.edu/~stark/Preprints/evidenceVote12.pdf
It references the state-of-the-art techniques for the sorts of Risk-Limiting Audits that we have used in Colorado and California.

I wonder how you could leverage UPnP to open up the port to a remote host. If you have control over the computer hosting this software it is not necessary and otherwise the default Firewall settings should prevent any incoming connections. Is it possible to request a port to be opened for another host, say if you have access to another PC in the subnet but not the computer running the software itself?

If a router supports UPnP, then a computer on the local network can ask the router to automatically open up a port in the NAT firewall on the router. When I installed the OSV software in a virtual machine, the Windows Firewall asked me if I wanted to make the port available on the internal network. That’s not a good thing.

First the article says that you use USB then you mention E-mail.
So what is it?

> This computer program generates multiple files containing the voting total entered by the election official from each district.
So you enter like “party A: 50 votes, party B: 60 votes”?
But what exactly do you mean with paper trail or paper audit?
That it will be written down and sent via snailmail to the next higher gov level? Can also be tampered with.

I’m curious why you list “It’s partly open source” as an additional vulnerability. I have the opinion that software like this should be fully open source so that any citizen can audit the software that is used to count their vote. Of course, there are no guarantees that the software running at election time will be built from the same source as the one that’s public but that’s a very different problem. In the end, I fully agree that we should keep any software away from our election, just curious why you consider being open source an additional vulnerability.

If some part of the software can’t be checked, that results in a certain level of uncertainty. That uncertainty creates less trust in the software and thus increases the security risk as certain parts can’t be audited and scanned for vulnerabilities.

The Electoral Council still hasn’t answered many questions about the security of their, and the software your company wrote. They even can’t defend themselves against critics and prove otherwise. So that means my research is still standing strong so far. Just saying that I’m wrong and then give no evidence to support that claim doesn’t work.

I’ve read the Fox-IT report and if *all* Fox-IT recommendations are followed, then it will be hard to tamper with the election results, as paper is effectively in the lead. I hope, but doubt that all recommendations will be followed. To be continued! ;-)

Thank you for this report. You can add the site http://www.spiegel.de to the list of those that are linking to this article.
Although most of the article appears to be accurate, you should fix the statement that encryption protects data from being tampered with. Encryption only protects confidentiality; the integrity (or authenticity) of the data can only be protected using MACs or digital signatures, respectively.
Keep up the good work!