Finding vulnerabilities in Swiss Post's future e-voting system

Finding vulnerabilities in Swiss Post's future e-voting system - Part 2

Earlier this year I published the Part I of this series of blog posts on vulnerabilities in Swiss Post's future e-voting system. That publication comprehensively explains the context, methodology and attack surface for the Swiss Post e-voting system, so it is highly recommended to go through it before reading this post, if you're really interested in getting the whole picture.

This second round of bugs (reported during December '21 and January '22 ) includes multiple cryptographic vulnerabilities and a deserialization issue.

For me, the most interesting issue is '#YWH-PGM2323-65', not only because it would have prevented ballot boxes from being decrypted during the tally phase, but also due to the potential design weaknesses that I'm coming across as a result of its analysis.

Let's briefly discuss the reported issues before going into detail:

ID	Title	Reward (€)	Attack Surface Areas*	CVSS
#YWH-PGM2323-53	Multiple unchecked length values during SafeStreamDeserialization may crash Control Components	3500	3 & 4	5.4 - Medium CVSS:3.0/AV:A/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H
#YWH-PGM2323-64	Verifier does not properly verify the signature of NodeContributions	5000	2 & 3	5.1 - Medium CVSS:3.0/AV:A/AC:H/PR:H/UI:R/S:C/C:N/I:H/A:N
#YWH-PGM2323-65	Generation of 'Choice Return Codes encryption' Public Key and 'Election' Public Key may be influenced by a malicious voting server.	4500	3	5.4 - Medium CVSS:3.0/AV:A/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H
#YWH-PGM2323-{59,60,61}	Multiple improper signature verification issues.	N/A (Duplicated)	2 & 3 & 4	7.3 - High CVSS:3.0/AV:A/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H

* The 'attack surface areas' column refers to the top 5 priorities previously elaborated on 'Finding vulnerabilities in Swiss Post's future e-voting system - Part I '.

1. Multiple unchecked length values during SafeStreamDeserialization may crash Control Components

As it was explained in the Part I, the orchestrator service, part of the untrusted Voting Server, communicates with the Control Components using AMQP messages through a RabbitMQ cluster.

The control components implement a specific deserialization logic for some of those messages. A lack of proper length validation during the deserialization of potentially attacker-controlled messages can force an out of memory error, thus crashing the affected component

2. 'Verifier' does not properly verify the signature of NodeContributions

This vulnerability targets the Verifier, a component that is not a priority yet as it is still missing part of its functionality, but nonetheless a key component intended to facilitate auditors (including 3rd parties) the task of validating an election event.

When checking the Node Contributions resulting from the 'GenEncLongCodeShares', the verifier uses data, coming from the Control Components, that has not been yet verified in order to set up the own verification logic, which usually is a bad thing to do. Additionally, it does not properly verify the consistency of these contributions, however consistence checks are still being developed so that may be considered a known-issue.

3. Generation of 'Choice Return Codes encryption' Public Key and 'Election' Public Key may be influenced by a malicious voting server.

This vulnerability involves a malicious voting server (note that the system specification considers the voting server untrustworthy and potentially compromised) providing a specific combination of Control Components public keys to the SDM, so that when 'Choice Return Codes' and the 'Election' Public Keys are generated, they will not comply with the actual contributions from the four different Control Components.

When targeting the 'Election' Public key (EL_pk), this attack would have prevented the ballot boxes from being decrypted during the tally phase, which renders the election event basically useless as votes cannot be decrypted.

If we were talking about a regular election, this issue would be similar to be directly voting into a paper shredding machine.

To be honest, I don't completely agree with the assessment Swiss Post has performed on this vulnerability due to the following reasons:

- Swiss Post narrows down the impact of this vulnerability to the availability of the system, while I consider there is also an impact on its integrity.

- They didn't consider this attack may qualify for the 'Vote Corruption' domain-specific scenario, because it targets all votes instead of individual votes, which, from my perspective, may be questionable at least.

- They acknowledge that the mitigation adduced for this attack, which is the ability of the cantons to decrypt 'test ballot boxes' using the same cryptographic materials than in the real election event (so they would see votes are not being decrypted), is not currently part of the system specification, neither had been documented anywhere when the attack was reported. In addition to this, I think that ability presents a high risk attack vector but as that functionality has not been formally described nor implemented, so far there is little to add.

- Swiss Post states that attacks against availability do not violate their security objectives, which is a concern. Actually they acknowledge the system design and specification are vulnerable by default to this kind of attack: for instance, if a malicious Control Component destroys (3 of 4 Control Components are assumed to be malicious) its election private key.

Just to put things into context, Ransomware is essentially an attack against availability. I see a troubled future for e-voting if the election results depend on whether the election authorities are willing to pay in order to receive the keys that would allow to decrypt votes.

4. Multiple improper signature verification issues.

The signature validation for payloads sent back and forth between the SDM and Control Components (through the Voting Server's Orchestrator) was broken due to an improper validation of the certificate chain. Basically, the signature validation algorithm was just checking whether the payload was properly signed, but not who really signed it. As there were different certificate chains hanging from the same Platform Root CA, untrustworthy components would be able to leverage their intermediate certificates to impersonate others.

My reports were accepted but discarded as 'Duplicated'. It turned out these, and similar, issues had been previously uncovered by Thomas Haines, Vanessa Tiague and Oliver Pereira: the experts who have reported most of the serious cryptographic vulnerabilities in the system.

Although there is a little difference: in Thomas' paper he mentions a malicious Control Component is required to perform this kind of attack but I found a malicious Voting Server is enough, due to the Voting Server's 'Election Information 100' certificate chain.

Vulnerabilities

#YWH-PGM2323-53 - Multiple unchecked length values during SafeStreamDeserialization may crash Control Components

Description

The Orchestrator service, part of the untrusted Voting Server, communicates with the Control Components using AMQP messages through a RabbitMQ cluster.

The control components implement specific deserialization logic for some of those messages. A lack of proper length validation during the deserialization of potentially attacker-controlled messages can force an out of memory error, thus crashing the affected component.

Technical Details

The 'unpackArrayHeader()' (or similar unpack* functions) is used multiple times without enforcing any bounds checking (see lines 156, 101, 115, 129, 100 in the following files). As a result, an overly large signed integer value is used to initialize lists and allocate arrays, which may result in a 'java.lang.OutOfMemoryError: Java heap space' error, thus crashing the affecting component.

(Version: 0.12.0.0)

File: e-voting-master/domain/src/main/java/ch/post/it/evoting/domain/returncodes/KeyCreationDTO.java

144:    @Override
145:    public void deserialize(MessageUnpacker unpacker) throws SafeStreamDeserializationException {
146:        try {
147:            setCorrelationId(UUID.fromString(StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker)));
148:            this.requestId = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
149:            this.signature = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
150:            this.resourceId = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
151:            this.encryptionParameters = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
152:            this.electionEventId = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
153:            this.from = StreamSerializableUtil.retrieveDateValueWithNullCheck(unpacker);
154:            this.to = StreamSerializableUtil.retrieveDateValueWithNullCheck(unpacker);
155:            if (!unpacker.tryUnpackNil()) {
156:                int listSize = unpacker.unpackArrayHeader();
157:                this.publicKeys = new ArrayList<>(listSize);
158:                for (int i = 0; i < listSize; i++) {
159:                    CCPublicKey key = new CCPublicKey();
160:                    key.deserialize(unpacker);
161:                    publicKeys.add(key);
162:                }
163:            } else {
164:                publicKeys = null;
165:            }
166:        } catch (IOException e) {
167:            throw new SafeStreamDeserializationException(e);
168:        }
169:    }

File: e-voting-master/domain/src/main/java/ch/post/it/evoting/domain/returncodes/ChoiceCodesVerificationDecryptResPayload.java

096:    public void deserialize(MessageUnpacker unpacker) throws SafeStreamDeserializationException {
097:        try {
098:            if (unpacker.tryUnpackNil()) {
099:                decryptContributionResult = null;
100:            } else {
101:                int listSize = unpacker.unpackArrayHeader();
102:                decryptContributionResult = new ArrayList<>(listSize);
103:                for (int i = 0; i < listSize; i++) {
104:                    decryptContributionResult.add(StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker));
105:                }
106:            }
107:            exponentiationProofJson = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
108:            publicKeyJson = StreamSerializableUtil.retrieveStringValueWithNullCheck(unpacker);
109:            if (unpacker.tryUnpackNil()) {
110:                this.signature = null;
111:            } else {
112:                int arraySize = unpacker.unpackArrayHeader();
113:                X509Certificate[] certs = new X509Certificate[arraySize];

File: e-voting-master/domain/src/main/java/ch/post/it/evoting/domain/returncodes/ReturnCodesExponentiationResponsePayload.java

110:    public void deserialize(MessageUnpacker unpacker) throws SafeStreamDeserializationException {
111:        try {
112:            if (unpacker.tryUnpackNil()) {
113:                pccOrCkToLongReturnCodeShare = null;
114:            } else {
115:                int mapSize = unpacker.unpackMapHeader();
116:                pccOrCkToLongReturnCodeShare = new LinkedHashMap<>(mapSize);
117:                for (int i = 0; i < mapSize; i++) {
118:                    BigInteger key = retrieveBigIntegerValueWithNullCheck(unpacker);
119:                    BigInteger value = retrieveBigIntegerValueWithNullCheck(unpacker);
120:                    pccOrCkToLongReturnCodeShare.put(key, value);
121:                }
122:            }
123:            exponentiationProofJson = retrieveStringValueWithNullCheck(unpacker);
124:            voterChoiceReturnCodeGenerationPublicKeyJson = retrieveStringValueWithNullCheck(unpacker);
125:            voterVoteCastReturnCodeGenerationPublicKeyJson = retrieveStringValueWithNullCheck(unpacker);
126:            if (unpacker.tryUnpackNil()) {
127:                this.signature = null;
128:            } else {
129:                int arraySize = unpacker.unpackArrayHeader();
130:                X509Certificate[] certs = new X509Certificate[arraySize];

File: e-voting-master/domain/src/main/java/ch/post/it/evoting/domain/returncodes/ReturnCodesInput.java

095:    public void deserialize(MessageUnpacker unpacker) throws SafeStreamDeserializationException {
096:        try {
097:            if (unpacker.tryUnpackNil()) {
098:                this.returnCodesInputElements = null;
099:            } else {
100:                int listSize = unpacker.unpackArrayHeader();
101:                returnCodesInputElements = new ArrayList<>(listSize);
102:                for (int i = 0; i < listSize; i++) {
103:                    returnCodesInputElements.add(StreamSerializableUtil.retrieveBigIntegerValueWithNullCheck(unpacker));
104:                }
105:            }

The deserialization of the received messages relies on the open-source 'msgpack' code, the {unpack*Header} functions end up invoking 'getInt', so there is no safeguard either at that component level.

https://github.com/msgpack/msgpack-java/blob/651a2a02fd5f269d91183cf70e162dea7a5d9caa/msgpack-core/src/main/java/org/msgpack/core/buffer/MessageBuffer.java#L459

 public int getInt(int index)
    {
        // Reading little-endian value
        int i = unsafe.getInt(base, address + index);
        // Reversing the endian
        return Integer.reverseBytes(i);
    }

The RabbitMQ message size limit mitigation is also out of the scope of this issue. We're not sending an overly large RabbitMQ message, we are sending a especially crafted serialized message, that once deserialized by MessagePack provides the large integer values that are consumed by the e-voting code but the actual RabbitMQ message may be just several KBs.

#YWH-PGM2323-64 - Verifier does not properly verify the signature of NodeContributions

Description

The verifier is using potentially malicious data to dynamically adjust the values that will determine whether a successful verification has been performed.

Technical Details

(v 0.12.3)

At line 165 the NodeContributions are persisted by the SDM, once they have been collected from the Orchestrator.

File: e-voting-master/secure-data-manager/secure-data-manager-backend/services/src/main/java/ch/post/it/evoting/sdm/application/service/VotingCardSetService.java

133:    /**
134:     * Download the computed values for a votingCardSet
135:     *
136:     * @throws InvalidStatusTransitionException if the original status does not allow the download
137:     */
138:    public void download(String votingCardSetId, String electionEventId)
139:            throws ResourceNotFoundException, InvalidStatusTransitionException, IOException {
140: 
141:        if (!idleStatusService.getIdLock(votingCardSetId)) {
142:            return;
143:        }
144: 
145:        try {
146:            Status fromStatus = Status.COMPUTED;
147:            Status toStatus = Status.VCS_DOWNLOADED;
148: 
149:            checkVotingCardSetStatusTransition(electionEventId, votingCardSetId, fromStatus, toStatus);
150: 
151:            JsonObject votingCardSetJson = votingCardSetRepository.getVotingCardSetJson(electionEventId, votingCardSetId);
152:            String verificationCardSetId = getVerificationCardSetId(votingCardSetJson);
153: 
154:            deleteNodeContributions(electionEventId, verificationCardSetId);
155: 
156:            int chunkCount;
157:            try {
158:                chunkCount = returnCodeGenerationRequestPayloadRepository.getCount(electionEventId, verificationCardSetId);
159:            } catch (PayloadStorageException e) {
160:                throw new IllegalStateException("Failed to get the chunk count.", e);
161:            }
162: 
163:            for (int i = 0; i < chunkCount; i++) {
164:                try (InputStream contributions = votingCardSetChoiceCodesService.download(electionEventId, verificationCardSetId, i)) {
165:                    writeNodeContributions(electionEventId, verificationCardSetId, i, contributions);
166:                }
167:            }
168: 
169:            configurationEntityStatusService.update(toStatus.name(), votingCardSetId, votingCardSetRepository);
170: 
171:        } finally {
172:            idleStatusService.freeIdLock(votingCardSetId);
173:        }
174: 
175:    }

During verification, the persisted Node contributions are then loaded, deserialized and verified. However, at line 190 we can see that the verifier use 'payload.getNodeId()', a value belonging to a payload for which its signature has not been yet validated, to choose the CCN CA that will be used to validate the certificate chain of the signature. This can be used by an attacker to trick the verifier into using a certificate chain, which may belong to a malicious Control Component, to validate a tampered contribution of the honest Control Component.

File: verifier-master/verifier-block1/src/main/java/ch/post/it/evoting/verifier/block/block1/verifications/CheckSigNodeContributions.java

172:    // Data class that represent node contributions signature to verify
173:    static class NodeOutputSignature {
174:        private final byte[] signature;
175:        private final byte[] payloadHash;
176:        private final X509Certificate signingCertificate;
177:        private final List<X509Certificate> intermediateCertificates;
178:        private final X509Certificate rootCertificate;
179: 
180:        // Massage the data to get it into the expected format for the verification algorithm
181:        NodeOutputSignature(final ReturnCodeGenerationResponsePayload payload, final NodeCertificates nodeCertificates, HashService hashService,
182:                CertificateLoader certificateLoader) {
183:            // Signature
184:            this.signature = payload.getSignature().getSignatureContents();
185:            this.payloadHash = hashService.recursiveHash(payload);
186: 
187:            // Certificates chain
188:            this.signingCertificate = payload.getSignature().getCertificateChain()[0];
189:            final List<Path> filteredCertificates = nodeCertificates.nodeCertificatesPaths.stream()
190:                    .filter(ccPath -> ccPath.getFileName().toString().equals("cc" + payload.getNodeId() + "_CA.pem"))
191:                    .collect(Collectors.toList());
192:            this.intermediateCertificates = Collections.singletonList(certificateLoader.loadCertificate(filteredCertificates.get(0)));
193:            this.rootCertificate = nodeCertificates.rootCertificate;
194:        }
195:    }

The verifier should limit the use of potentially attacker-controlled data while performing the different verifications. Before verification, the data to be validated should not be part of the values involved in the own validation. Otherwise, there is a risk to validate data that may have been tampered in the component that persisted that data, thus populating any potential issue abused in a component providing inputs to the verifier into the own verifier.

In this specific case, if we are expecting to verify contributions from 4 nodes, for which their CCN CA are known, the verifier should check whether the node Id n (without using the nodeId from the not yet verified payload) is actually using the CCN CA n, but also that all the contributions come from four different nodes, and that the same node Id has not been used to sign another node's contribution.

#YWH-PGM2323-65 - Generation of 'Choice Return Codes encryption' Public Key and 'Election' Public Key may be influenced by a malicious voting server

Description

EL_pk and pk_CCRare generated by combining the public key contributions of the CCM and CCR nodes. These contributions are collected from the Control Components by the Voting Server and sent to the Setup Component, as can be seen in the 'System Specification' document.

These public keys are individually signed by the corresponding CCR/CCM Signing certificate, which later on are verified by the Setup Component before combining them to generate the final public keys. However, the Setup Component does not validate the number of public keys that have been received from the Voting Server matches the amount of public keys defined in the protocol specification. Thus, a malicious voting server can just return to the Setup Component an arbitrary number of properly signed public keys, that will be validated by the Setup Component and then combined.

As a result, this combination of an arbitrary number of public keys can be abused to maliciously influence the resulting EL_pk and pk_CCR keys, in such a way that it may compromise the ability to decrypt all votes in an election event.

It's important to note that this attack does not rely on being able to bypass the implemented signature logic, but it is based on the ability to increase the number of valid public keys that are used during the generation of EL_pk and pk_CCR

Technical Details

The following Runnable lambda 'serializePublicKey' triggers the logic that generates the EL_pk