Consultant's Security and Telecommunications Test Report

Dominion Democracy Suite ImageCast Remote 5.10 RAVBMS Security and Telecommunications Report DOM-19003-RSECTR-01 Vendor Name Dominion Voting Systems Vendor System Democracy Suite ImageCast Remote 5.10 Prepared by: 4720 Independence St. Wheat Ridge, CO 80033 303-422-1566 www.SLICompliance.com Accredited by the Election Assistance Commission (EAC) for Selected Voting System Test Methods or Services Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Copyright 2019 by SLI ComplianceSM, a Division of Gaming Laboratories International, LLC Revision History Date Releas Author Revision Summary e August 8, 2019 1.0 J. Peterson, M. Santos Initial Release August 13, 2019 1.1 J. Peterson Updated for CA comments August 22, 2019 2.0 M. Santos Updated for CA comments August 23, 2019 3.0 M. Santos Updated for CA comments November 9,2019 4.0 J. Peterson Updated to reflect updated documentation November 12, 2019 5.0 M. Santos Updated for CA comments November 19, 2019 6.0 J. Peterson Updated to reflect updated documentation November 26, 2019 7.0 J. Peterson Updated to reflect update documentation Disclaimer The information reported herein must not be used by the client to claim product certification, approval, or endorsement by NVLAP, NIST, or any agency of the Federal Government. Trademarks • SLI is a registered trademark of SLI Compliance. • All products and company names are used for identification purposes only and may be trademarks of their respective owners. California Certification Page 2 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report TABLE OF CONTENTS INTRODUCTION ................................................................................................................................. 4 PHASE I – DOCUMENTATION REVIEW ........................................................................................... 4 5.5 VOTE SECRECY ON DRE AND EBM SYSTEMS ............................................................................... 5 6.1.2 DATA TRANSMISSIONS ............................................................................................................... 5 6.2 DESIGN, CONSTRUCTION, AND MAINTENANCE REQUIREMENTS ....................................................... 6 6.2.1 CONFIRMATION ......................................................................................................................... 6 7.1.1 ELEMENTS OF SECURITY OUTSIDE MANUFACTURERS CONTROL .................................................. 6 7.2 ACCESS CONTROL ........................................................................................................................ 7 7.2.1 GENERAL ACCESS CONTROL ..................................................................................................... 7 7.2.2 ACCESS CONTROL IDENTIFICATION ............................................................................................ 8 PERTINENT EXCERPT(S) FROM: 7.4.5 SOFTWARE REFERENCE INFORMATION ....................................... 8 PERTINENT EXCERPT(S) FROM: 7.4.6 SOFTWARE SETUP VALIDATION .................................................. 9 7.8 TESTING – SECURITY ................................................................................................................... 9 PHASE II – FUNCTIONAL SECURITY TESTING ............................................................................ 10 5.5 VOTE SECRECY ON DRE AND EBM SYSTEMS ............................................................................. 10 7.2.1 GENERAL ACCESS CONTROL ................................................................................................... 11 7.2.2 ACCESS CONTROL IDENTIFICATION .......................................................................................... 11 PERTINENT EXCERPT(S) FROM: 7.2.4 ACCESS CONTROL AUTHORIZATION .......................................... 12 PERTINENT EXCERPT(S) FROM: 7.4.5 SOFTWARE REFERENCE INFORMATION ..................................... 12 PERTINENT EXCERPT(S) FROM: 7.4.6 SOFTWARE SETUP VALIDATION ................................................ 12 7.6 TELECOMMUNICATIONS AND DATA TRANSMISSION ....................................................................... 13 7.8 TESTING – SECURITY ................................................................................................................. 13 PERTINENT EXCERPT(S) FROM: 7.8.1 ACCESS CONTROL ................................................................... 14 7.8.2 DATA INTERCEPTION AND DISRUPTION ..................................................................................... 15 PHASE III – TELECOMMUNICATIONS AND DATA TRANSMISSION TESTING.......................... 15 6.1.2 DATA TRANSMISSION ............................................................................................................... 16 6.2 DESIGN, CONSTRUCTION, AND MAINTENANCE REQUIREMENTS ..................................................... 16 6.2.1 CONFIRMATION ....................................................................................................................... 17 POTENTIAL VULNERABILITIES ..................................................................................................... 17 7.8 TESTING – SECURITY ................................................................................................................. 18 SUMMARY ........................................................................................................................................ 20 California Certification Page 3 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report INTRODUCTION The California Voting Systems Standards (CVSS) were written in such a way to be applicable to a wide variety of voting technology. Therefore, the relevant portions of the CVSS are reviewed as the relate to the Remote Accessible Vote By Mail System (RAVBMS) for the purposes of this report. The use of “voting system” shall apply to the RAVBM system. This report outlines the testing SLI Compliance (SLI) followed when performing Security and Telecommunications Testing on the Dominion Democracy Suite ImageCast Remote 5.10 (RAVBMS) (DS ICR 5.10 RAVBMS) against the California Voting System Standards (CVSS). The DS ICR 5.10 RAVBMS enables the voter to mark their ballot using a secure web-based interface, and generate and download a PDF representation of choice selections. Voters then print that ballot, and then return it to their election official. Phase I – Documentation Review During Phase I testing of the DS ICR 5.10 RAVBMS documentation was reviewed to verify and validate the following requirements: • Top-level system design and architecture • System documentation and procedures During Phase I testing, documentation was reviewed to verify and validate in accordance with the following California Voting System Standards (CVSS) requirements: • 5.5 Vote Secrecy on Direct Recording Electronic (DRE) and Electronic Ballot Marking (EBM) Systems • 6.1.2 Data Transmissions • 6.2 Design, Construction, and Maintenance Requirements • 6.2.1 Confirmation • 7.1.1 Elements of Security outside Manufacturers Control • 7.2 Access control • 7.2.1 General Access Control • 7.2.2 Access Control Identification • 7.4.5 Software Reference Information California Certification Page 4 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report • 7.4.6 Software Setup Validation • 7.8 Testing – Security See the applicable section below for more details on these requirements and the review results. 5.5 Vote Secrecy on DRE and EBM Systems All DRE and EBM systems shall ensure vote secrecy by: a. Immediately after the ballot is recorded to persistent electronic storage or printed, erasing the selections from the device’s display, working memory, and all other storage, including all forms of temporary storage b. Immediately after the voter chooses to cancel his or her ballot, erasing the selections from the display and all other storage, including buffers and other temporary storage Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. 6.1.2 Data Transmissions These requirements apply to the use of telecommunications to transmit data for the preparation of the system for an election, the execution of an election, and the preservation of the system data and audit trails during and following an election. While this section does not assume a specific model of voting system operations and does not assume a specific model for the use of telecommunications to support such operations, it does address the following types of data, where applicable: Voter Authentication: Coded information that confirms the identity of a voter for security purposes for a system that transmits votes individually Ballot Definition: Information that describes to a voting machine the content and appearance of the ballots to be used in an election Vote Count: Information representing the tabulation of votes at any level within the control of the jurisdiction, such as the polling place, precinct or central count List of Voters: A listing of the individual voters who have cast ballots in a specific election Additional data transmissions used to operate a voting system in the conduct of an election, but not explicitly listed above, are also subject to the requirements of this section. California Certification Page 5 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. 6.2 Design, Construction, and Maintenance Requirements Design, construction, and maintenance requirements for telecommunications represent the operational capability of both system hardware and software. These capabilities shall be considered basic to all data transmissions. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. 6.2.1 Confirmation Confirmation occurs when the system notifies the user of the successful or unsuccessful completion of the data transmission, where successful completion is defined as accurate receipt of the transmitted data. To provide confirmation, the telecommunications components of a voting system shall notify the user of the successful or unsuccessful completion of the data transmission. In the event of unsuccessful transmission the user shall be notified of the action to be taken. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. 7.1.1 Elements of Security outside Manufacturers Control The requirements of this section apply to the capabilities of a voting system that must be provided by the manufacturer. However, an effective security program requires well defined security practices by the purchasing jurisdiction and the personnel managing and operating the system. These practices include: • Administrative and management controls for the voting system and election management, including access controls • Internal security procedures • Adherence to, and enforcement of, operational procedures (e.g., effective password management) • Security of physical facilities • Organizational responsibilities and personnel screening Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. California Certification Page 6 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report 7.2 Access control Access controls are procedures and system capabilities that detect or limit access to system components in order to guard against loss of system integrity, availability, confidentiality, and accountability. Access controls provide reasonable assurance that system resources such as data files, application programs, and computer-related facilities and equipment are protected against unauthorized operation, modification, disclosure, loss or impairment. Unauthorized operations include modification of compiled or interpreted code, run-time alteration of flow control logic or of data, and abstraction of raw or processed voting data in any form other than a standard output report by an authorized operator. Access controls may include physical controls, such as keeping computers in locked rooms to limit physical access, and technical controls, such as security software programs designed to prevent or detect unauthorized access to sensitive files. The access controls described in this section are limited to those controls required to be provided by system manufacturers. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. 7.2.1 General Access Control General requirements address the high-level functionality of a voting system. These are the fundamental access control requirements upon which other requirements in this section are based. a. Voting system equipment shall provide access control mechanisms designed to permit authorized access to the voting system and to prevent unauthorized access to the voting system. i. Access control mechanisms on the EMS shall be capable of identifying and authenticating individuals permitted to perform operations on the EMS. b. Voting system equipment shall provide controls that permit or deny access to the device’s software and files. c. The default access control permissions shall implement the minimum permissions needed for each role or group identified by a device. d. The voting device shall prevent a lower-privileged process from modifying a higher-privileged process. e. An administrator of voting system equipment shall authorize privileged operations. California Certification Page 7 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report f. Voting system equipment shall prevent modification to or tampering with software or firmware through any means other than the documented procedure for software upgrades. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. 7.2.2 Access Control Identification Identification requirements provide controls for accountability when operating and administering a voting system. a. The voting system shall identify users and processes to which access is granted and the specific functions and data to which each entity holds authorized access. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. Pertinent Excerpt(s) from: 7.4.5 Software Reference Information a. The manufacturer shall provide the NSRL, any California certified escrow facility, pursuant to Title 2, Division 7, Chapter 6 of the California Code of Regulation, and the Office of the Secretary of State with a copy of the software installation disk, including the executable binary images of all third party software. Further, the manufacturer shall deposit the source code, tools, and documentation, to allow the complete and successful compilation of a system in its production/operation environment. i. The manufacturer shall document that the process used to verify the software distributed on unalterable storage media is the certified software by using the reference information provided by the NSRL or other designated repository before installing the software. c. The manufacturers shall document to whom they provide voting system software. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. California Certification Page 8 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Pertinent Excerpt(s) from: 7.4.6 Software Setup Validation g. Setup validation methods shall verify the contents of all system storage locations (e.g., system registers, variables, files, etc.) containing election specific information (e.g., ballot style, candidate registers, measure registers, etc.). Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. It should be noted that after the initial connection with the RAVBMS server to acquire the ballot, the client-side Ballot is generated in the voter’s ballot and further connectivity with the RAVBMS sever is severed. 7.8 Testing – Security The S-ATA shall design and perform test procedures that test the security capabilities of the voting system against the requirements. These procedures shall focus on the ability of the system to detect, prevent, log, and recover from the broad range of security risks identified. These procedures shall also examine system capabilities and safeguards claimed by the manufacturer in the TDP to go beyond these risks. The range of risks tested is determined by the design of the system and potential exposure to risk. Regardless of system design and risk profile, all systems shall be tested for effective access control and physical data security. The S-ATA may meet these testing requirements by confirming proper implementation of proven commercial security software. In this case, the manufacturer must provide the published standards and methods used by the U.S. Government to test and accept this software, or it may provide references to free, publicly available publications of these standards and methods, such as government web sites. At its discretion, the S-ATA may conduct or simulate attacks on the system to confirm the effectiveness of the system's security capabilities. Results: Review of the Technical Data Package (TDP) validated that the requirement was satisfactorily covered. California Certification Page 9 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Phase II – Functional Security Testing Phase II testing included: • Testing of relevant software and operating system configuration for pertinent vulnerabilities • Testing of hardware, including examination of unused hardware ports and security measures applied to those ports During Phase II, tests were exercised in order to verify and validate functional security in accordance with the following CVSS requirements: • 5.5 Vote Secrecy on DRE and EBM Systems • 7.2.1 General Access Control • 7.2.2 Access Control Identification • 7.2.4 Access Control Authorization • 7.4.5 Software Reference Information • 7.4.6 Software Setup Validation • 7.6 Telecommunications and Data Transmission • 7.8 Testing – Security • 7.8.1 Access Control • 7.8.2 Data Interception and Disruption See the applicable section below for more details on these requirements and the review results. An issue log of any errors, anomalies, or omissions encountered during Phase II testing was maintained. 5.5 Vote Secrecy on DRE and EBM Systems All DRE and EBM systems shall ensure vote secrecy by: a. Immediately after the ballot is recorded to persistent electronic storage or printed, erasing the selections from the device’s display, working memory, and all other storage, including all forms of temporary storage b. Immediately after the voter chooses to cancel his or her ballot, erasing the selections from the display and all other storage, including buffers and other temporary storage Testing performed: Testing was performed to verify how the system handled a ballot being printed and the browser closed, as well as when the ballot is closed California Certification Page 10 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report prior to being printed. Attempts were made to resume a ballot, as well as to determine if any ballot information resided in history or cache. Verified that no traces of marked ballot information existed in browser history or cache. 7.2.1 General Access Control General requirements address the high-level functionality of a voting system. These are the fundamental access control requirements upon which other requirements in this section are based. a. Voting system equipment shall provide access control mechanisms designed to permit authorized access to the voting system and to prevent unauthorized access to the voting system. Testing performed: The DS ICR 5.10 RAVBMS uses an N-tier architecture that consists of separate client applications, application server components, database components, and a central document repository. Authentication included methods for both the voter facing application as well as the administrative application. Security was tested on the architecture pieces, client application, and administrative application, which were accessible remotely. 7.2.2 Access Control Identification Identification requirements provide controls for accountability when operating and administering a voting system. a. The voting system shall identify users and processes to which access is granted and the specific functions and data to which each entity holds authorized access. Testing performed: The DS ICR 5.10 RAVBMS uses a client server system to authenticate registered voters and serve up the correct ballot for a particular voter using predefined ballot rules and voters that can be imported by the jurisdiction. Role based access controls are in place for administrative login purposes. California Certification Page 11 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Pertinent Excerpt(s) from: 7.2.4 Access Control Authorization c. Voting systems shall explicitly deny subject’s access based on access control lists or policies. Testing performed: All access to the DS ICR 5.10 RAVBMS is controlled by Voter ID number and an associated pin number which is created during registration. All administrative access is controlled by username/password combinations and there is a role-based administrative access in place. The ability to assign voters to different electoral groups/electoral districts gives the ability to assign ballots to voters in accordance with specific rules. Pertinent Excerpt(s) from: 7.4.5 Software Reference Information b. The voting system equipment shall be designed to allow the voting system administrator to verify that the software is the certified software by comparing it to reference information produced by the NSRL or other designated repository. Testing performed: The DS 5.10 RAVBMS does not have a built-in hash verification method for the system to verify that the source code is not running modified code. There is however a documented manual verification method for validation of the appropriate files. Testing was unable to successfully modify the server code to verify if a protection method was in place and viable. Pertinent Excerpt(s) from: 7.4.6 Software Setup Validation c. Setup validation methods shall include a software verification method that ensures that the voting system software has not been modified illegitimately. i. The voting systems shall include any supporting software and hardware necessary to conduct the software verification method. ii. The manufacturer shall document the process used to conduct the software verification method. iii. The software verification method shall not modify the voting system software on the voting system. Testing performed: The DS 5.10 RAVBMS does not have a built-in hash verification method for the system to verify that the source code is not running California Certification Page 12 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report modified code. There is a documented manual verification method for validation of the appropriate files. Testing was unable to successfully modify the server code to verify if a protection method was in place and viable. 7.6 Telecommunications and Data Transmission There are four areas that must be addressed by telecommunications and data transmission security capabilities: access control, data integrity, detection and prevention of data interception, and protection against external threats. Testing performed: Tests were performed to verify that the system utilizes electrical or optical transmission, and that the ballot is sent via SSL and no receipt is utilized to verify. The client generates a blank ballot which does not contain voting selections. Once the blank ballot is delivered, and until the ballot package is saved, there are no external communications between the voter and the ballot delivery system; all interactions remain local to the voter’s environment. The ballot functionality is dynamically generated from the initial client server connection and all ballots are issued and selections made on the voters’ local computer. This system gives the voter the ability to save and or print a ballot package that can be then mailed in or taken to a polling place. 7.8 Testing – Security The state-approved testing agency (S-ATA) shall design and perform test procedures that test the security capabilities of the voting system against the requirements. These procedures shall focus on the ability of the system to detect, prevent, log, and recover from the broad range of security risks identified. These procedures shall also examine system capabilities and safeguards claimed by the manufacturer in the TDP to go beyond these risks. The range of risks tested is determined by the design of the system and potential exposure to risk. Regardless of system design and risk profile, all systems shall be tested for effective access control and physical data security. The S-ATA may meet these testing requirements by confirming proper implementation of proven commercial security software. In this case, the manufacturer must provide the published standards and methods used by the U.S. Government to test and accept this software, or it may provide references to free, publicly available publications of these standards and methods, such as government web sites. At its discretion, the S-ATA may conduct or simulate attacks on the system to confirm the effectiveness of the system's security capabilities. California Certification Page 13 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Testing performed: Confirmed that the DS ICR 5.10 RAVBMS does not have, nor require, internet access once the ballot has been downloaded. There are no external connections from the ballot to any outside server or service. With the exception of printing or saving the ballot package there are no external calls to or from the ballot. Pertinent Excerpt(s) from: 7.8.1 Access Control For those access control features built in as components of the voting system, the S-ATA shall design tests to confirm that these security elements work as specified. Specific activities to be conducted by the S-ATA shall include: b. Specific tests designed by the S-ATA to verify the correct operation of all documented access control procedures and capabilities, including tests designed to circumvent controls provided by the manufacturer. These tests shall include: i. Performing the activities that the jurisdiction will perform in specific accordance with the manufacturer’s access control policy and procedures to create a secure system, including procedures for software and firmware installation ii. Performing tests intended to bypass or otherwise defeat the resulting security environment. These tests shall include simulation of attempts to physically destroy components of the voting system in order to validate the correct operation of system redundancy and backup capabilities This review applies to the full scope of system functionality. It includes functionality for defining the ballot and other pre-voting functions, as well as functions for casting and storing votes, vote canvassing, vote reporting, and maintenance of the system’s audit trail. Testing performed: Testing was performed to confirm that DS ICR 5.10 RAVBMS access control was maintained. Attempted XSS attacks, SQL injection attacks, directory listings/scans; attempted to pull directory file lists; scanned for default http login pages; scanned for robots_txt file; and pulled SSL certificate information. A full WMAP web vulnerability scan was performed. Burp Suite was utilized to fully scan, spider, and intercept both the voter-facing application and the administrative application. A full scan was completed utilizing the Nikto Web application scanner A full application scan was completed utilizing the “whatweb” Web application scanner California Certification Page 14 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report A Nessus vulnerability scan of the system was also performed. Review of the requirement validated that the requirement was satisfactorily covered. 7.8.2 Data Interception and Disruption For systems that use telecommunications, as provided for in section 6 of the Standards and consistent with California law, to transmit official voting data, the S- ATA shall review, and conduct tests of, the data interception and prevention safeguards specified by the manufacturer in its TDP. The S-ATA shall evaluate safeguards provided by the manufacturer to ensure their proper operation, including the proper response to the detection of efforts to monitor data or otherwise compromise the system. Testing performed: Verified that this system does not utilize telecommunications for the transmission of official voting data, only for delivery of a blank ballot that does not contain voter data or choice selections. Phase III – Telecommunications and Data Transmission Testing Phase III consisted of the testing of system communications, including encryption of data, as well as protocols and procedures for access authorization. During Phase III, tests were exercised in order to verify and validate telecommunications and data transmission in accordance with the following CVSS requirements: • 6.1.2 Data Transmission • 6.2 Design, Construction, and Maintenance Requirements • 6.2.1 Confirmation See the applicable section below for more details on these requirements and the review results. An issue log of any errors, anomalies, or omissions encountered during Phase III testing was maintained. California Certification Page 15 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report 6.1.2 Data Transmission These requirements apply to the use of telecommunications to transmit data for the preparation of the system for an election, the execution of an election, and the preservation of the system data and audit trails during and following an election. While this section does not assume a specific model of voting system operations and does not assume a specific model for the use of telecommunications to support such operations, it does address the following types of data, where applicable: Voter Authentication: Coded information that confirms the identity of a voter for security purposes for a system that transmits votes individually Ballot Definition: Information that describes to a voting machine the content and appearance of the ballots to be used in an election Vote Count: Information representing the tabulation of votes at any level within the control of the jurisdiction, such as the polling place, precinct or central count List of Voters: A listing of the individual voters who have cast ballots in a specific election Additional data transmissions used to operate a voting system in the conduct of an election, but not explicitly listed above, are also subject to the requirements of this section. Testing performed: Web vulnerability scans were performed on the DS ICR 5.10 RAVBMS web server to determine if there were any basic web server vulnerabilities in the initial serving of the in-browser application that houses the DS ICR 5.10 RAVBMS ballot. After the interactive ballot application was launched, connectivity to and from the ballot was confirmed to be nonexistent, with the exception of calls to the local system for print or save functionality. 6.2 Design, Construction, and Maintenance Requirements Design, construction, and maintenance requirements for telecommunications represent the operational capability of both system hardware and software. These capabilities shall be considered basic to all data transmissions. Testing performed: Verified that the DS ICR 5.10 RAVBMS consists of a generated ballot which is typically used for absentee and mail in ballot marking. The DS ICR 5.10 RAVBMS does not utilize specific telecommunications channels once the ballot has been downloaded and opened on the voter’s machine. California Certification Page 16 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report 6.2.1 Confirmation Confirmation occurs when the system notifies the user of the successful or unsuccessful completion of the data transmission, where successful completion is defined as accurate receipt of the transmitted data. To provide confirmation, the telecommunications components of a voting system shall notify the user of the successful or unsuccessful completion of the data transmission. In the event of unsuccessful transmission the user shall be notified of the action to be taken. Testing performed: Testing verified that the DS ICR 5.10 RAVBMS ballot marking system only allows the voter to mark and confirm marked ballots prior to printing and/or saving out a Ballot Package There are no live connections from the application to a remote server after the voter receives the generated ballot. All selections are cleared after the browser has been closed. This requirement was determined to be not applicable. Potential Vulnerabilities For any potential vulnerabilities discovered, SLI was tasked with identifying the particular standards applicable to each vulnerability. To the extent possible, reported vulnerabilities include an indication of whether the exploitation of the vulnerability would require access by a: • Voter: Usually has low knowledge of the voting machine design and configuration. Some may have more advanced knowledge. May carry out attacks designed by others. They have access to the machine(s) for less than an hour. • Poll worker: Usually has low knowledge of the voting machine design and configuration. Some may have more advanced knowledge. May carry out attacks designed by others. They have access to the machine(s) for up to one week, but all physical security has been put into place before the machines are received. • Elections official insider: Wide range of knowledge of the voting machine design and configuration. May have unrestricted access to the machine for long periods of time. Their designated activities include: Set up and pre-election procedures; o Election operation; o Post-election processing of results; and o California Certification Page 17 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Archiving and storage operations. o • Vendor insider: Great knowledge of the voting machine design and configuration. They have unlimited access to the machine before it is delivered to the purchaser and, thereafter, may have unrestricted access when performing warranty and maintenance service, and when providing election administration services. SLI will not verify or demonstrate exploitability of the vulnerability but the report of the vulnerability will identify factors involved in the exploitation. Any vulnerability theories developed by the security team shall, to the extent possible, be referred to the Secretary of State staff. 7.8 Testing – Security Target: https://ravbm.uocava.com (Voter facing application) • Open redirection (DOM-based) DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way. DOM-based open redirection arises when a script writes controllable data into the target of a redirection in an unsafe way. An attacker may be able to use the vulnerability to construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain. Note: If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the JavaScript: pseudo- protocol to execute arbitrary script code when the URL is processed by the browser. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation. Target: https://admin.uocava.com (Administrative portal) California Certification Page 18 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Issue Background Server-side code injection vulnerabilities arise when an application incorporates user-controllable data into a string that is dynamically evaluated by a code interpreter. If the user data is not strictly validated, an attacker can use crafted input to modify the code to be executed; and inject arbitrary code that will be executed by the server. Server-side code injection vulnerabilities are usually very serious and lead to complete compromise of the application's data and functionality, and often of the server that is hosting the application. It may also be possible to use the server as a platform for further attacks against other systems. • Potential instance of JavaScript code injection A Status check parameter appears to be vulnerable to server-side JavaScript code injection attacks. The submitted value appears to be placed into a dynamically evaluated JavaScript statement, within a single-quoted context. • Potential instance of Cross-site scripting (reflected) The name of an arbitrarily supplied URL parameter is copied into the HTML document as plain text between tags. The payload was submitted in the name of an arbitrarily supplied URL parameter. This input was echoed in the application's response. This behavior demonstrates that it is possible to inject new HTML tags and attributes into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript, but this was not successful. The application attempts to block certain characters that are often used in XSS attacks, but this can be circumvented by applying superfluous URL- encoding to the required characters - for example, by submitting %253c instead of the < character. The application appears to be blocking the usual proof-of-concept test string used by Burp Suite, so an alternate test string was used. • Potential instances of Open Redirection (DOM-Based) Issue Background DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way. DOM-based open redirection arises when a script writes controllable data into the target of a redirection in an unsafe way. An attacker may be able to California Certification Page 19 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report use the vulnerability to construct a URL that, if visited by another application user, will cause a redirection to an arbitrary external domain. This behavior can be leveraged to facilitate phishing attacks against users of the application. The ability to use an authentic application URL, targeting the correct domain and with a valid SSL certificate (if SSL is used), lends credibility to the phishing attack because many users, even if they verify these features, will not notice the subsequent redirection to a different domain. Note: If an attacker is able to control the start of the string that is passed to the redirection API, then it may be possible to escalate this vulnerability into a JavaScript injection attack, by using a URL with the JavaScript; pseudo- protocol to execute arbitrary script code when the URL is processed by the browser. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation. Summary The DS ICR 5.10 RAVBMS is an application that allows voters to access ballots remotely as controlled by the jurisdiction. The ballot, once generated and accessed, is self-contained within the individual voter’s browser. This means that once the initial server call for the application is processed, the entire application runs in the current browser session. Since the application doesn’t utilize incoming or outgoing connections once the ballot is loaded, this reduces the possibility of interception or manipulation through network attack vectors. Delivery of jurisdiction ballots over a public telecommunication medium poses a risk of server-side compromise. To help mitigate this, the vendor provided high level documentation about the processes/procedures and security to mitigate these risks, including, but not limited to: • Secure hosting • Physical security of hosting sites • Network security • Inventory and configuration management • Access control • Monitoring and logging California Certification Page 20 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01 Dominion Democracy Suite 5.10 RAVBMS California Certification Security & Telecomm Test Report Security testing of the server-side hosting security included web application scanning, utilizing Burp Suite, and Nessus vulnerability scanning. The scanning turned up a small selection of high, medium, and low vulnerabilities that have minimal impact on the overall security of the applications being tested. None of the vulnerabilities discovered were successfully exploited. Voter privacy is ensured by removing client-side storage of marked selections in browser history. This allows the voter to verify and save a ballot package for printing for use in a currently setup vote by mail voting program. The ability to tamper with the client-side application is always present because there are no server-side verifications or validations in place after the ballot has been generated. This risk is mitigated because the voter can proof and confirm ballot selections within the DS ICR 5.10 RAVBMS interactive ballot prior to saving and/or printing the ballot. As directed by the California Secretary of State, this security testing report does not include any recommendation as to whether or not the system should be approved. End of RAVBMS Security and Telecommunications Test Report California Certification Page 21 of 21 Security & Telecommunications Test Report v7.0 Report Number DOM-19003-RSECTR-01