Here’s the report: https://ccc.de/system/uploads/230/original/PC-Wahl_Bericht_C…
It’s truly disastrous. Some of the findings:
– The automated software updates have no signature and are downloaded insecurely over HTTP
– The webserver the updates are downloaded from is hosted using a shared hosting package at 1&1, on a host with >5000 other customers (implying an easy takeover using local privilege escalation)
– The reason they know this? They found multiple PHP scripts vulnerable to arbitrary read and write vulnerabilities, so they got full RCE on the server.
– FTP access credentials for the website were contained in a public ZIP file (named test.zip)
– Vote results are transmitted using either insecure FTP whose credentials weren’t rotated for years or an equally insecure XML protocol. No signatures in sight.
– Said insecure XML protocol is a government standard
They also took a look at one of the local government’s infrastructure:
– test/test were valid VPN credentials
– FTP credentials were publicly downloadable with R/W access to vote results
– Vote result encryption was reversible thanks to a hardcoded symmetric key
The report goes on to detail even more trivial security issues, including home-grown “encryption” algorithms worse than what you’d find in a beginner CTF challenge.
None of the steps taken in response addressed the fundamental, obvious security policy issues. Even their band-aid fixes were broken. For example, they started signing their binaries, but forgot to check the signature.
Given the lack of any security awareness whatsoever, even if they properly sign their binaries, their build server is probably easy to compromise.
RCE demo: https://vimeo.com/232581770
Have a look at the site in question: https://www.wahlinfo.de/
The local government they worked with responded by enforcing verification and transmission of the results using an independent channel.
