Results from the bug bounty programme, update 31 December 2021

For its e-voting solution, SwissPost is running a public bug bounty program. On 2 September 2021, we published the first results.

Since then the hunters submitted 18 reports:

• 2 reports concern cryptography related issues in the cryptographic protocol and its specification. We rewarded these reports with a payout of €7'750.-.
• 6 reports concern source-code issues. They highlighted meaningful improvements in the source code. We rewarded these reports with a total payout amount of €19'500.-.
• 2 reports concern infrastructure-related best practices. They do not directly lead to exploitable attacks but highlight some possible improvements in the configuration of the server infrastructure or the source code. We rewarded these reports with a total payout of €350.-.
• SwissPost and YwH did not accept 8 reports since they could not be reproduced or did not identify a vulnerability. Triaging reports are a standard process in bug bounty programs and took decisions together with our partner YesWeHack.

In total, SwissPost paid out since the last update €27'600.- to the bounty hunters who submitted the reports.

Cryptography related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-52	Insecure 'ReturnCodeGenerationInput' signature generation allows vote manipulation.	The signature fails to include the verification card set public key. This could in theory lead to a third party introducing voting cards which it controls and can hence submit votes, leading to an invalid election. We confirmed and disclosed this report publicly on Gitlab. Identified thanks to Ruben Santamarta (reversemode)	This issue has already been corrected in release 0.12.	Medium
#YWH-PGM2323-10	Authentication bugs possibly leading to manipulation that goes undetected by the voter but not by the system	It appears that many of the authentication checks in the system check that the input is signed but not who it is signed by. Since the adversary has valid signing keys it can then impersonate honest parties. This could allow the adversary to impersonate the one honest return code control component. Thomas Haines identified this problem and documented several recommendations in this paper. Thomas Haines, Vanessa Teague, and Olivier Pereira identified a related issue (already reported on our Gitlab repository). In that case, impersonating honest components could allow the adversary to change the public key used to encrypt votes allowing for attacks on individual verifiability.	This issue has been corrected in release 0.15.	High

Source-code related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-51	Lack of consistency check allows an adversary to forge the verificationCardId in SecureLog entries	A missing consistency check of the 'VerificationCardId' field in the 'ReturnCodeComputationDTO' and its encapsulated 'Vote' object allows a malicious voting server to insert bogus SecureLogs entries. This could lead to confusion if somebody would perform a deeper investigation of the SecureLogs or forensic analysis of the logs. Identified thanks to Ruben Santamarta (reversemode)	This issue has been corrected in release 0.13.	Low
#YWH-PGM2323-49	SDM - Insecure USB file handling during 'importOperation'	The communication between the online and the offline instances of the SDM is done by an import/export functionality using a USB stick. The SDM Backend implements an endpoint for the front-end to perform an 'Import' operation in order to copy files from the USB to the SDM directory. The vulnerability lies in the way this operation has been implemented, as there is no validation of the files that are copied, allowing to overwrite multiple files in the SDM directory. We confirmed and disclosed this report publicly on Gitlab. Identified thanks to Ruben Santamarta (reversemode)	This issue has been corrected in release 1.0.	High
#YWH-PGM2323-47	Improper parsing of the request body when validating signatures for secure requests.	The verification of the signature for 'secure' requests within the Voting Server contains a non-coherent parsing logic between the signature generator (RestClientInterceptor) the signature verificator (SignedRequestFilter) for the request body. Thus the possibility of the verification failing the validation of the signature. Identified thanks to Ruben Santamarta (reversemode)	This issue became obsolete with the voting server refactoring done in release 1.3.	Low
#YWH-PGM2323-46	Lack of anti-replay protection for Signed Requests.	Both the Voting Server and SDM implement a REST Client that allows to transparently add a cryptographically secure signature for certain requests. At the same time, that signature will be verified by a custom servlet filter before the request is dispatched to the 'secure' endpoint. This design is currently prone to certain attacks due to the lack of anti-replay protection for the signed requests. Identified thanks to Ruben Santamarta (reversemode)	This issue has been corrected in release 0.15.	Medium
#YWH-PGM2323-45	Uncaught exception in the Sanitize filter may prevent proper sanitization of a query string.	The API Gateway exposed endpoints are sanitized by a custom servlet filter ('SanitizerDataFilter') that wraps the original request to transparently sanitize the untrusted inputs in order to prevent XSS and similar attacks. Identified thanks to Ruben Santamarta (reversemode)	This unhandled exception does not lead to a vulnerability. But this exception will be handled correctly as a best quality code practice. This issue has been corrected in release 0.13.	Low
#YWH-PGM2323-44	Insecure deserialization of untrusted input may lead to RCE in the 'Vote Verification' microservice	The 'Vote Verification' microservice initiates a REST client instance to receive certain information from the 'Control Components' through the 'Orchestrator'. However, both the 'Vote Verification' and the 'Orchestrator' services belong to the 'Voting Server' party, which is considered untrustworthy, so according to the threat model defined by SwissPost, an adversary can intercept, drop, and inject messages at will on untrustworthy communication channels. Identified thanks to Ruben Santamarta (reversemode)	The code was in this case already under improvement before receiving the report and will not use the readObject method anymore. This issue has been corrected in release 0.13.	Medium

Infrastructure related issues

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-43	Server Security Misconfiguration	The dmarc policy is not properly enforced and allows a social engineering attack to be launched directly with the "evoting-community.post.ch" domain. Identified thanks to Giannino Cuignet (Zettersploit)	Issue is fixed.	Low
#YWH-PGM2323-41	Code injection through a malicious ballot configuration	Through an injection of a correctnessRule, both the encryptedCorrectnessRule and the decryptedCorrectnessRule could possibly be taken control of.	Issue is fixed.	Low