You might wonder what this blog post is about. Well, let us tell you a story about how we found a critical vulnerability in the Dutch Electoral Council (Kiesraad) development infrastructure…
Maarten Boone, our dear colleague, was having a quiet dinner with his cats in his apartment on a drizzly Tuesday in July.
He was pondering about a significant Coordinated Vulnerability Disclosure (CVD) he had just submitted to a major medical company together with the Zerocopter team. And he felt pumped about it but also a bit lost, as it had taken up a lot of his time and now… nothing. Finished. Done.
Thinking about what to do next, his mind drifted towards an old project he had previously looked at – the OSV2020 software, which facilitates Dutch elections and is provided by the Electoral Council (Kiesraad). He had thought about creating a new tool, so he could test his ideas on this project and see if it worked. And maybe even find some more issues to report to them.
While still enjoying his dinner, Maarten downloaded their publicly available OSV2020 software. He looked at the installer and noticed that it was primarily built in Java. So he grabbed a tool: https://github.com/ststeiger/procyon, and started decompiling the OSV2020 software. It appeared that they were using an open-source installer called Izpack, which can be found here: http://izpack.org/downloads/.
How does it work? What is the process for building it? What does the final build look like? Well, drumroll….If you are using a tool, make sure to check out the documentation. You really should do that because, in this case, the final build included some artifacts in the form of Java serialized objects that just shouldn’t have been there. Wow!
*Yoda voice* – “So deserialize the objects we should, yes?” Well, no, you can read a lot with just a hex-editor. But Maarten is Maarten, so he quickly wrote a tool that can deserialize Java objects into JSON. And you know what? Since you are reading this, you can have it too! Sharing is caring → https://github.com/Zerocopter/J2J
So, the tool is built, we run it on the artifacts and now, what do we see? Well [redacted]:
"keystore.storepass": "Je************der",
"confluence.password": "#H************5Z",
"PROGRAM_DATA": "ProgramData",
"was.app.name": "VApp-U",
"wvp.datasource.jndi.name": "java:/electWvpDatabase",
"DEPLOYMENTS_FOLDER": "deployments",
"JAVA_LIB_FOLDER": "lib",
"H2_DB_DIR_NAME": "database",
"KEYSTORE_PASSWORD": "id**********LEn",
"izpack-release.version": "5.1.3",
"share.intern.password": "QM**********pW",
"osv.tld.name": "osv2020.nl",
And on, and on, and on……
Nice. All the credentials and a lot of interesting information gave him full access to the deploy environment of the software builders. All of the above took less than an hour.
The reporting of this finding also went blazingly fast, thanks to the CISO of the Dutch Electoral Council. The pickup speed and mitigation was a smooth and superfast process, as communicating with them was a breeze! Maarten was taken through the whole CVD process on their end and updated continuously. For him, it was one of the best CVD processes ever, and the way the Electoral Council dealt with it should serve as an example for many other companies and government organizations.
For the overview, here is the exact timeline of this process:
Jun 28, 2023, 17:50: Dinner
Jun 28, 2023, 17:54: Downloading OSV2020-PP
Jun 28, 2023, 18:33: Valid credentials found
Jun 28, 2023, 18:53: First contact with the CISO to share preliminary findings
Jun 29, 2023, 12:32: Detailed mail send to the CISO with all findings
Jun 29, 2023, 16:47: Confirmation mail from the CISO that everything is received in order.
Jun 30, 2023, 14:56: Received an email from the CISO with additional questions after they had contact with the software vendor
Jun 30, 2023, 15:20: Response send
Jul 7, 2023, 15:36: Got a very detailed update mail from the CISO explaining everything they had discussed with the vendor as well as an update on what they are working on.
Aug 7, 2023, 13:00: In-person meeting with the CISO at the Electoral Council (Kiesraad) building in The Hague
Please note that in the Netherlands we, as hackers, are not afraid to do this as we are protected by the Dutch CVD guideline, which you can find here.
So now you know what the title means. It’s important to remember that you are not done when you press build and deploy. Security mistakes can happen at any stage of your development process, and it’s a good thing to let hackers check it regularly.
A pentest alone is just not enough. You should aim to have a variety of hackers, each with their unique skills, review your work, either through a Coordinated Vulnerability Disclosure (CVD) program or a Bug Bounty program, if that fits better. They will find stuff you will want to know about. Even while they are having dinner!
