Results from the bug bounty programme, update 31 December 2023

For its e-voting solution, SwissPost is running a public bug bounty program. On the 22 September 2023 we made the last update. Since then, the hunters submitted 14 reports:

• 1 reports concern cryptography-related issues in the cryptographic protocol and its specification.
• 7 reports concern source-code issues. They highlighted meaningful improvements in the source code.
• 3 reports were accepted as informative for their insightful contributions, focusing on minor configuration aspects of the infrastructure. However, we will not elaborate on these in this GitLab ticket due to their limited scope.

SwissPost and YwH did not accept 2 reports since they could not be reproduced or did not identify a vulnerability and 1 reports are still under review. Triaging reports is a standard process in bug bounty programs, and we took decisions together with our partner YesWeHack.

In total, SwissPost paid out since the last update €16’100 EUR.- rewards to the hunters who submitted the reports.

Cryptography-related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-192	Ambiguity in verifying the Election Encryption Parameters	Generally, the generation of encryption parameters should offer limited degrees of freedom to ensure robustness. The ideal scenario is for the seed to be deterministic, adhering to a transparent and straightforward approach, commonly referred to as a "nothing-up-my-sleeves" value. Even if an adversary had the freedom to pick the seed value, generating parameters with a trapdoor would still be impossible due to the preimage resistance of the used hash function. However, limiting such freedoms is best practice. Both the e-voting system and the verifier should therefore restrict seed value options. The current specification indicates that the seed should correspond to the election event name. One option might be to utilize the contestIdentification originating from the eCH files for this purpose. However, this value is often preset by an upstream system, making it less than ideal for use as the election event's seed. Instead, cantons typically manually define the name of election event, adhering to a specific naming scheme. The system specification should elucidate this aspect in greater detail, outlining the prescribed method for deriving the election event name and the verifier should make it easier for auditors to manually check the seed value. Identified thanks to Reverse Mode	This was resolved in release 1.4. See changelog of the system specification 1.4 and changelog of the verifier specification 1.5.	Low

Source-code-related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-176	MITM using paper channel / letter	The hunter highlighted an attack in which a malicious actors intercepts paper letters, employs a razor blade to stealthily open envelopes, learns all voting codes, and alters the code sheets and voting instructions. This attack compromises both verifiability and voting secrecy. Nonetheless, this type of attack is not in scope of the Federal Chancellery's trust model, which assumes that the communication channel between the printing component and the voter to be trustworthy. The report suggests various interesting countermeasures, including the use of tamper-evident envelopes and letter tracking, to mitigate the risk of such attacks or to enhance the probability of detecting them.	Even though the report corresponds to a recognized and acknowledged risk scenario of a paper-based return code scheme, we accept the report because of its numerous recommendations for best practices.	Low
#YWH-PGM2323-177	Voter Secrecy Screen Capture	The hunter showcased an attack method in which an attacker manipulates the voting client to capture and transmit screenshots of the voting interface to the attacker, thus breaching voting secrecy. The attack falls outside the Federal Chancellery's trust model, which assumes a trustworthy voting client for maintaining voting secrecy. Despite this, the report presents several noteworthy recommendations that merit serious consideration. Identified thanks to Andreas Kuster	Even though the report corresponds to a recognized and acknowledged risk scenario of a voting scheme where options are input in a plaintext format, we accept the report because of its numerous recommendations for best practices.	Low
#YWH-PGM2323-178	MITM via Spoofing	The hunter demonstrates an attack consisting of a malicious, spoofing website, running as an intermediary. On the frontend, it serves the webpage which resembles the functionality of the actual voting website expected by the voter. On the backend, it runs the actual voting session in a browser-automated web browser instance. This ensures that the actual voting session cannot be distinguished from a valid user voting session. The attack falls outside the Federal Chancellery’s threat model, since the attacker cannot undetectably alter a vote. Individual verifiability allows a voter to identify any malicious attempt to modify their vote by verifying that the return code shown on the voting client matches the return code on the printed code sheet. The Swiss Post Voting System incorporates defenses against such attacks, including HSTS preloading and the option to verify the website's certificate fingerprint. Nevertheless, under specific scenarios, a voter might still be deceived into visiting a spoofed website. A vigilant voter can identify an attempt to alter their vote by checking the return codes. However, a malicious website may attempt to confuse the voter and prevent the voter from verifying the return codes. The report contains suggestions for additional mechanisms to prevent the risk of a spoofed website such as designated domains or certificate pinning. Identified thanks to Andreas Kuster.	Even though the report corresponds to a recognized and acknowledged risk scenario of a return code scheme already mitigated through individual verifiability mechanisms, we accept the report because of its numerous recommendations for best practices.	Low
#YWH-PGM2323-179	MITM Browser	Similarly to the above report, the hunter demonstrated a social engineering attack where the attacker tries to trick the voter into deviating from the intended voting procedure. The hunter's comprehensive blog post on the finding garnered significant attention within the information security community. Subsequently, a different expert - in the field – reversemode – published his thoughts in a separate blog post, contributing further to the discussion. The attack requires the voter to install a malicious browser plugin that alters the voting interface. The voter is asked to enter the return codes instead of verifying them. The plugin then proceeds to change the selections of the vote and tries to confuse the voter by showing him instructions not to verify the return codes. Again, the attack can be prevented by individual verifiability allowing voters to confirm the integrity of their vote by cross-checking the return code visible on the voting interface with the one on their printed code sheet. The report underscores certain inadequacies in the instructions regarding the voting process provided on the printed code sheets and proposes a range of improvements. Identified thanks to Andreas Kuster.	Even though the report corresponds to a recognized and acknowledged risk scenario of a return code scheme already mitigated through individual verifiability mechanisms, we accept the report because of its numerous recommendations for best practices, especially the consideration in designing the code sheets for voters.	Low
#YWH-PGM2323-191	unsafe-inline directive on the e-voting community site	The hunter alleges that one of our e-voting community information’s website makes use of the unsafe-inline security directive, thereby permitting the execution of inline scripts and styles as well as JavaScript event handlers such as onclick, or javascript URLS via the javascript: pseudo-protocol. Identified thanks to NoMemoryLeak.	This is a best practice to add conservative CSP Headers to protect those vulnerabilities, therefore we accept this report as best practice.	Low
#YWH-PGM2323-195	[Verifier] Inconsistent handling of write-in truncation	The hunter identified a discrepancy in processing write-in entries within the e-voting system and its verifier. While the system limits write-in contents to 500 characters to maintain XML validity under the eCH-standard, the verifier does not implement a similar truncation. This mismatch raises the possibility of the verifier rejecting XML files as invalid due to excessive write-in lengths. Nonetheless, the issue is non-exploitable, as encoding a write-in exceeding 500 characters in a 3072-bit ElGamal ciphertext is unfeasible. Despite this, it is advisable for both the e-voting system and the verifier to adopt a more uniform approach in handling write-ins. Identified thanks to Reverse Mode	This has been resolved with Release 1.4.	Low
#YWH-PGM2323-196	Insufficient documentation of Write-In encoding	The hunter pointed out an inconsistency in the Swiss Post Voting System's documentation: it does not specify the role and validation rules for the separator character “#” in write-in fields. However, the voter portal employs this character to encode write-ins, a practice not mentioned in the system specification. Although this discrepancy does not pose a security risk, aligning the implementation with the specification is very important to the auditability of the system. Identified thanks to Reverse Mode	This has been resolved with Release 1.4.	Medium