How to hack the upcoming Dutch elections and how hackers could’ve hacked 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 2009

The 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. RTL told me that voters use pencil and paper, and that votes are counted manually. However, for efficiency reasons the votes are then entered into a computer program by election officials.

Voting machines have continued to be used in the background since 2009

This 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 system

If 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-threats

The 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-names

The 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 server

While 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):

  1. Introducing a web server on a desktop in order to run a desktop-only application creates a significant attack surface for hackers.
  2. 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.
  3. The web server can possibly be accessed by others on the network if the host-based firewall is missing or misconfigured.
  4. 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 computer

To 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):

  1. Old computers that lack security updates can be used. This applies equally to computers without anti-virus scanners.
  2. Personal (BYOD) computers are not prohibited.
  3. 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:

  1. Possibly leaking HTTP referrer headers to other websites when the voting web portal contains links to other external sites.
  2. 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.
  3. 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 crypto

I 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 files

At 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 file

The 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 files

The 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:

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

Even if the cryptographic signing was implemented well, it all can be bypassed if malicious software is loaded on an USB stick (risk #14 high).

Instructor uses short password and auto-completes it

At 03:07 minutes the voting-software login screen shows:

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):

  1. When a hacker is able to copy the token he/she can bypass the login screen.
  2. As the web portal runs over an non-secured HTTP connection, this token can also leak to other websites.
  3. Also, the token will be saved in the browser history.

Running software under administrator privileges

I 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:

The software writes user files in its installation directory: C:\Program Files (x86)\OSV\

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-software

At 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 worse

After 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 vulnerabilities

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

  1. Internet connected computers.
  2. No IT security expert was consulted when building this software.
  3. It’s partly open source.
  4. About a cross-site scripting vulnerability I found.
  5. Logs are not collected on a central server and thus easy to tamper with.
  6. No intrusion detection systems are active.
  7. No experienced ethical hacker has reviewed the software.
  8. No security test reports are available.
  9. The integrity of the software is hard to validate, and even optional.
  10. 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.


Will 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.
High: The voting software stores voting results in an unencrypted XML file.
Medium: PDF file with SHA1 hash code is stored next to corresponding XML file it has to protect.
Medium: The voting software / instructor does not mention that PDF files should be printed, nor enforces you to manually delete generated PDF files.
Medium: The architect designed the system, but it seems that this person doesn’t review the generated (security) documentation about it.
High: Non encrypted USB sticks are used.
High: Custom USB sticks can be used and these sticks can be loaded with malicious software.
Medium: Web browser automatically completes user passwords on a shared computer.
Medium: Instructor uses three letter password.
Low: A non personal user account is used.
Medium: No password strength policy is in place.
Low: The Java session identifier is visible in the internet address.
Medium: Instructor uses Windows administrator account instead of low privileged account. The software allows this.
Medium: Software saves high integrity XML files into a public location on the computer.
High: No automatic SHA1 hash check is in place for XML files stored on the computer.
High: Voting results are sent via an unencrypted e-mail over the internet.
High: Most sensitive operations in voting software have least SHA1 protection.
Etc. etc.


Bron: Blog Sijmen Ruwhof