Hart Verity Voting 3.0 Voting System Software Testing Report

Software Testing Verity Voting System 3.0 Report Date: 2018-09-07 Version: 2.0 Status: FINAL Classification: Public atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 Tel: +1 512 615 7300 Fax: +1 512 615 7301 www.atsec.com Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 1 of 29 Revision history Version Change date Author(s) Changes to previous version 1.0 2018-07-09 Ryan Hill Initial draft 1.1 2018-07-27 Ryan Hill Second draft 2.0 2018-09-07 Ryan Hill Updated based on customer feedback. Trademarks atsec and the atsec logo are registered trademarks of atsec information security corporation. Verity is a trademark of Hart InterCivic, Inc. FCMG and the FCMG Logo are registered trademarks of the Freeman, Craft, McGregor Group. Microsoft, Windows, .NET, and SQL Server are registered trademarks of Microsoft Corporation. MITRE is a registered trademark of The MITRE Corporation. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 2 of 29 Table of Contents 1 Executive Summary ....................................................................................................... 5 2 Introduction .................................................................................................................... 6 2.1 Scope and Basis ................................................................................................... 6 2.2 Inputs .................................................................................................................... 7 2.3 Threat Model ........................................................................................................ 7 2.4 Methodology ......................................................................................................... 8 2.4.1 Potential vulnerabilities .............................................................................. 10 2.4.2 Code quality ............................................................................................... 10 2.4.3 Design ....................................................................................................... 10 2.4.4 Cryptography ............................................................................................. 11 2.4.5 Back doors ................................................................................................. 11 2.4.6 Measurement of findings ........................................................................... 11 2.4.7 Depth of analysis ....................................................................................... 12 3 Description of the Verity Voting System ....................................................................... 13 3.1 Voting System Functions .................................................................................... 13 3.2 Physical Components ......................................................................................... 13 3.3 Logical Components ........................................................................................... 14 3.4 Interfaces ............................................................................................................ 14 3.4.1 Network interfaces ..................................................................................... 14 3.4.2 Peripheral devices ..................................................................................... 15 3.4.3 Files ........................................................................................................... 15 3.4.4 Databases ................................................................................................. 16 4 Findings ....................................................................................................................... 17 4.1 Public Vulnerability Search ................................................................................. 17 4.2 Static Code Analysis & Documentation Review .................................................. 19 Glossary ......................................................................................................................... 24 References ..................................................................................................................... 26 Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 3 of 29 List of Tables Table 1: Device/Area Media ........................................................................................... 15 Table 6: Potential Vulnerabilities Identified ..................................................................... 19 Table 7: Summary of issues discovered during the static code analysis ........................ 23 Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 4 of 29 1 Executive Summary This report was prepared by atsec information security corporation to review aspects of the security and integrity of the Verity Voting System v. 3.0. atsec is an independent, third-party company providing information-security assurance related services. This report identifies security weaknesses and vulnerabilities found through static code review and by searches of public vulnerability sources. The search focused particularly on those that could be exploited to alter vote recording, vote results, critical election data such as audit logs, or to conduct a denial of service attack on the voting system. It should be noted that the public vulnerability search is most likely to identify vulnerabilities that have been reported in commonly used commercial off the shelf system components. The static code analysis revealed 10 issues, the public vulnerability search identified 9 vulnerabilities that could potentially be used for an attack on the voting system. Of the 10 issues found by static code analysis, 5 were assessed to be of medium severity and 5 were assessed to be of low severity. At a high level, weaknesses and vulnerabilities were identified that can be attributed to difficulties resulting from an aging and repeatedly modified system. These include the following. Use of old 3rd party code containing publicly known vulnerabilities Instances of incorrect error or exception handling Use of outdated crypto algorithms and key lengths which become more susceptible to attack over time Hard coded passwords and unenforced password complexity rules Poor password storage methods Inclusion of code that is no longer used Possibly weak or duplicated initialization vectors SQL query best practices are not followed Instances of poor audit logging Inconsistent design such as varying requirements for password strength In addition, numerous less severe but still noteworthy vulnerabilities were found related to code quality and non-conformance to the California Voting System Standards. See section 4 for all findings. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 5 of 29 2 Introduction This report was prepared by atsec information security corporation to review aspects of the security and integrity of the Verity Voting System v3.0. It has been prepared in support of a contract awarded to Freeman, Craft, McGregor Group, Inc. This project has a goal to provide voting system test support services to assist the California Secretary of State (SOS) with the evaluation of the Verity Voting System v3.0 for its suitability for use in the State of California in accordance with Elections Code sections 19001 et seq. The source code review was performed by the following atsec information security corporation consultants. Fiona Pattinson (Project Manager) King Ables (Lead Reviewer) Jason Gorgeoulis (Reviewer) Demetrius Kellum (Reviewer) Sean Lewis (Reviewer) Dick Sikkema (Reviewer) Ryan Hill (Documentation Specialist) This document identifies the security vulnerabilities found through static code review and by searches of public vulnerability sources that could be exploited to alter vote recording, vote results, critical election data, such as audit logs, or to conduct a denial of service attack on the voting system. 2.1 Scope and Basis The Verity Voting System (EVS) v3.0 (hereafter referred to as the “voting system” or simply as the “system”) is a paper-based voting system made up of software, hardware, device, and peripheral components. The system has the following software components: Verity Data—Ballot design software Verity Build—Election definition and media creation/ballot printing software Verity Central—Central ballot scanning and adjudication software Verity Count—Ballot tabulation and reporting software The system can be set up to support one or more of the following hardware components: Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 6 of 29 Verity Print—On-demand ballot printing device Verity Touch Writer—Accessible ballot marking device Verity Reader—Optional ballot verification device Verity Scan—Ballot scanning device Verity vDrive—Specially formatted USB media used for data transfers Verity Access—Accessibility device providing additional input options Verity Key—USB security key atsec performed the source code review on the basis of an Agreement between Freeman, Craft, McGregor Group Inc., with the State of California, which states that the source code review includes examining the system in a manner that will provide the California Secretary of State with a basis for evaluating the extent to which the source code meets applicable standards. The threat model included in the Agreement is reproduced below and defines the threat parameters for the scope of this examination. 2.2 Inputs The reviewers were provided with a Technical Data Package (TDP) including the source code and a set of documents that support the findings in this report. These documents were examined during the source code review to better understand the voting system and identify discrepancies between the documentation and the source code. These documents are listed in the References section. 2.3 Threat Model This assessment is centered on the threat model given in the Request for Quotation (RFQ). The system is expected to counter the following attacks. Alter vote recording Alter vote results Alter critical election data, such as audit logs Conduct a denial of service attack on the voting system To the extent possible, vulnerabilities found have been reported with an indication of whether the exploitation of the vulnerability would require access by any of the following. 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. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 7 of 29 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: o Set up and pre-election procedures o Election operation o Post-election processing of results o Archiving and storage operations Vendor insider: Has 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. The atsec team did not attempt to demonstrate exploitability of identified potential vulnerabilities. However, identified potential vulnerabilities were described along with the anticipated factors necessary to mount an attack. 2.4 Methodology The atsec team was tasked with the Source Code review which included but was not limited to the following aspects. Evaluation of potential vulnerabilities and related issues (code quality and standards compliance), considering that an exploitable issue in a component that is not in itself security relevant could be used to subvert more critical data. This is an issue whenever the architecture of the system does not provide strong separation of the components. Adherence to other applicable coding format conventions and standards including best practices for the coding language used, and any IEEE, NIST, ISO or NSA standards or guidelines which the Contractor find reasonably applicable. Analysis of the program logic and branching structure. Search for exposures to commonly exploited vulnerabilities, such as buffer overflows, integer overflow, inappropriate casting or arithmetic. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 8 of 29 Evaluation of the use and correct implementation of cryptography and key management. Analysis of error and exception handling. Evaluation of the likelihood of security failures being detected. o Are audit mechanisms reliable and tamper resistant? o Is data that might be subject to tampering properly validated and authenticated? Evaluation of the risk that a user can escalate his or her capabilities beyond those authorized. Evaluation of whether the design and implementation follow sound, generally accepted engineering practices. Is code defensively written to protect against: o Bad data; o Errors in other modules; o Changes in environment; o User errors; and o Other adverse conditions. Evaluation of whether the system is designed in a way that allows meaningful analysis, including: o Is the architecture and code amenable to an external review (such as this one)? o Could code analysis tools be usefully applied? o Is the code complexity at a level that it obfuscates its logic? Search for embedded, exploitable code (such as “Easter eggs”) that can be triggered to affect the system. Search for dynamic memory access features which would permit the replacement of certificated executable code or control data or insertion of exploitable code or data. Search for use of runtime scripts, instructions, or other control data that can affect the operation of security relevant functions or the integrity of the data. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 9 of 29 2.4.1 Potential vulnerabilities The reviewers used the following public repositories to identify vulnerabilities that may affect the system. MITRE Common Vulnerability and Exposures (CVEs) NIST NVD using Common Platform Enumeration (CPE) tool COTS component support sites (e.g., HP, JRSoftware, NHibernate) Although this list may not have entries for the voting system itself, constituent software and commercial off-the-shelf (COTS) components that the voting system integrates may contain vulnerabilities. The review team identified such components that the system relies upon and conducted searches for these products as well. 2.4.2 Code quality While performing the examination of the code for other activities, the reviewers identified and recorded areas within the code base that demonstrate poor code quality. Although poor code quality does not necessarily identify vulnerabilities, it does provide an indication that vulnerabilities may exist. The following coding standards were used during this analysis. California Voting System Standards, October 2014 The reviewers also compared the code against the Verity Coding Standards that was found in the TDP. The team also performed numerous informal static analysis activities on the source code to gather code quality data using customized command scripts. 2.4.3 Design The source code review team used the technical data package, source code, and any material provided or otherwise publicly available to construct an understanding of the architecture and design of the voting system. This understanding included discovering the external interfaces and their security mechanisms and controls, particularly as much information as possible was gathered to support conclusions regarding the ability for a threat agent to tamper with or circumvent security controls. Interfaces represent the primary attack surface of the voting system. Interfaces can include web-based interfaces, native graphic user interfaces, command line interfaces, or technical interfaces that are not designed for direct user interaction (e.g., database connections). Each of these interfaces was examined to identify the security controls that counter the threats. Secure interfaces also depend on filtering out poorly structured or corrupt data. The review team specifically checked for input validation mechanisms and determined if related attacks, such as command injection are possible. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 10 of 29 2.4.4 Cryptography While cryptography is often the most difficult security mechanism to break directly, misuse of cryptographic primitives can render that protection weak or non-existent. The review team identified where cryptography is used throughout the source code and determined if its use is appropriate for the given purpose. For example, using a cryptographic hash function to protect passwords is appropriate while using an encryption algorithm with a hard-coded key is not. 2.4.5 Back doors Those with access to the voting system during development and having malicious intent can place back doors into the source code so that they could gain unauthorized access to the voting system during operation. Back doors are extremely hard to find because a seasoned programmer can obfuscate code to look benign. The review team marked areas of vulnerabilities as identified by command line searches, as described in section 4.5, for further scrutiny. For example, a particular area of code with poor code quality and access to sensitive information such as authentication credentials might be a good place to hide a back door. The reviewers gave such areas extra scrutiny by considering insider threats in addition to unintentional implementation flaws. 2.4.6 Measurement of findings A summary of findings is listed in section 4. Each finding contains the following information. A description of the vulnerability or weakness An assessment of what threats are involved in the possible exploitation of the vulnerability or weakness A categorization of the findings, which can be: o A weakness in the source code. Weaknesses are issues identified in the source code that are not directly exploitable but may indicate the existence of exploitable vulnerabilities within the source code. o A non-conformity in the code quality standards. Non-conformities do not necessarily imply weaknesses, though the rationale for the requirement is often based on preventing weaknesses. o A potential vulnerability in the source code. The reviewers consider potential vulnerabilities to likely be exploitable. o A vulnerability in the source code. The reviewers have either shown or have referenced other parties who have asserted the vulnerability to be exploitable. A severity level of the findings, which can be either: Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 11 of 29 o A low severity finding. Low severity implies either the impact to the product is low or already mitigated by the system, or the difficulty in exploitation would likely require unrestricted access to the systems, expert knowledge of the system, or would require cost prohibitive resources. o A medium severity finding. Medium severity implies either the impact of exploitation to the product would be significant, or the difficulty in exploitation would likely require extended access to the systems, informed knowledge of the system, or would require significant resources. o A high severity finding. High severity implies either the impact of exploitation to the product would result in complete compromise of security, or the difficulty in exploitation would likely require little to no access or knowledge of the systems or little to no resources. 2.4.7 Depth of analysis Because of the complexity and volume of the material to be reviewed, limited time available and broad scope (assessment of documents and quality of the code, along with source code review), the team concentrated on surveying a breadth of categories of vulnerabilities that they could identify, and only reviewed in depth enough samples of each of the categories to determine how that vulnerability was being handled. For all the categories, no attempt was made to enumerate how many instances existed. Other source code review projects would be likely to find more instances, but those findings should be within the listed categories. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 12 of 29 3 Description of the Verity Voting System The Verity Voting System is a suite of software, hardware, device and peripheral components for conducting and reporting elections. 3.1 Voting System Functions The Verity Voting System provides a number of high-level functions necessary to conduct an election. These activities include the following. Ballot data creation Election definition and ballot production Device configuration Polling-place-based ballot printing Polling place Ballot Marking Device Polling place ballot review Polling place digital scanning for paper ballots High-speed, large-volume ballot scanning Ballot Adjudication Counting of votes/tabulation Consolidation and reporting of results and audit logs Audits and recounts 3.2 Physical Components Several components are used in conducting an election with Verity. Some are specialized hardware components built or assembled by Verity, others are COTS products used to run Verity. The following are the specialized hardware components. Verity Print—An on-demand device for printing and issuing blank paper ballots to voters. The voter completes their ballot and casts it using either Verity Scan or by putting it in a ballot box to be scanned centrally. Verity Touch Writer—An accessible device for marking digital ballots using a touch screen. After confirming their selections the vote prints the ballot on the attached printer and casts it. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 13 of 29 Verity Reader—A device for optionally verifying a ballot. A voter can insert their marked paper ballot to verify how it will be counted and hear audio read-back of their choices. It does not store or tabulate votes. Verity Scan—A polling-place-based digital device for scanning and casting either hand-marked or printed ballots. The voter can check and correct the ballot before casting and the scanned ballot is depositing into a secure ballot box for storage. Verity vDrive—A specially formatted USB media used to transfer the election ballot styles to voting devices, to transfer cast vote records to Verity Count for tabulation, and to collect and transfer audit logs. Verity Access—An accessibility device attached to each Verity Touch Writer and Verity Reader device to provide the reader with additional input options including a scrolling wheel and select button, headphones, and a connection that may be used with tactile buttons or sip-and-puff devices. Verity Key—A USB device for Verity’s two-factor authentication process. Critical operations require the Verity Key to be inserted and a passcode to be entered. 3.3 Logical Components Verity Data—Ballot design software for entering, importing, and managing election data, jurisdiction data and translations as well as recording and importing audio. It also allows users to choose ballot templates, view ballot previews and lock the election data so that it can be opened in Verity Build. Verity Build—Election definition, media creation, and ballot printing software for opening elections, proofing data, configuring device settings, printing ballots and writing vDrives and Verity Keys. It also performs the final steps to prepare ballots for elections. Verity Central—Central ballot scanning and adjudication software for scanning and reviewing ballots, resolving write-in votes and voter intent issues, and writing cast vote records to vDrive for tabulation in Verity Count. Verity Count—Ballot tabulation and reporting software for reading vDrives, tabulating ballots, resolving write-in votes, printing reports, and exporting election results. 3.4 Interfaces The voting system moves data between external interfaces and internal components in a variety of ways: peripheral devices, files, and databases. This section will discuss these interfaces in more detail. 3.4.1 Network interfaces The logical components located at the Data/Build (can be one machine), Central, and Count sites will use Ethernet for network connectivity. Hart will provide the hardware necessary to instantiate a closed network at each individual location. The use of non- hardwired connectivity will not be permitted and such functionality has been disabled (e.g., wireless, Bluetooth). Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 14 of 29 The communication channels to other IT entities will be protected using TLS over TCP/IP. 3.4.2 Peripheral devices Data is moved between logical components using different media. Depending on the purpose of the data, the appropriate transport mechanism is chosen. Data will either be transported as a digital file or physically printed material. Table 1 summarizes the appropriate export media for each device or area. Component Export mechanism Verity Data and Verity Build (these are on Verity vDrive (election definitions) the same system) Verity Keys (voting equipment programming) Pre-voting paper ballots Verity Print Pre-voting ballots Verity Central Verity vDrive (Cast Vote Records) Verity Touch Writer Voter marked ballots (digital form) Verity vDrive (audit logs) Verity Scan Verity vDrive (Cast Vote Records and audit logs) Table 1: Device/Area Media 3.4.3 Files Many file types are used by various components of the voting system and are transferred by a variety of interfaces and media. The following types of data are stored in the voting system. Election data and configuration files Media files (e.g., audio) OS/WES7 configuration files Device configuration files Election results files Cast Vote Record (CVR) data files Audit logs Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 15 of 29 Extensible Markup Language (XML) PMQ files Signature files 3.4.4 Databases The Verity voting system uses two different Microsoft SQLServer databases: SQLServer 2012 and SQLServer Compact. Microsoft SQLServer 2012 was stated as the version used. However, it is unclear which version of SQLServer Compact is used. The following applications that will have access to the Microsoft SQLServer 2012 database. Verity Build Verity Central Verity Count User Management Election Manager Verity Device databases are created using Microsoft SQLServer Compact. These devices include the following. Verity Scan Verity Touch Writer Verity Reader Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 16 of 29 4 Findings 4.1 Public Vulnerability Search Table 6 lists the publicly known vulnerabilities identified that could potentially impact the voting system. Name (Vulnerable Description Additional information component) CVE-2016-2243 (HP Local users can cause the https://support.hp.com/us- Z240 Workstation) system to fail to recover the en/document/c05012469 BIOS. https://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE- 2016-2243 Meltdown/Spectre The computer system is https://support.hp.com/us- (HP Z240 susceptible to the en/document/c05869091 Workstation) Meltdown/Spectre malware. Outdated version The software version being https://support.microsoft.com/en- (SQLServer 2012) used (11.0.2100) is out us/help/321185/how-to-determine- dated. There have been the-version-edition-and-update- numerous Service Packs level-of-sql-server-an and Security updates since this release. The reviewer suggests updating to address any discovered (and potentially undiscovered) vulnerabilities. The latest service pack is Service Pack 4. SP1 installation Certain updates related to https://support.microsoft.com/en- failure (Windows SP1 may fail when updating us/help/3189682/serviceability- Embedded System the OS. update-for-windows-embedded- 7) Some updates that could standard-7-sp1-posready-7-a fail are: KB2949927: Availability of SHA-2 Hashing Algorithm for Windows 7 and Windows Server 2008 R2 KB3033929: Security Update for Windows 7 for x64-based Systems Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 17 of 29 Name (Vulnerable Description Additional information component) KB3110329: Security Update for Windows 7 The reviewer is providing this information to ensure the developer is aware of this situation and develop an appropriate mitigation strategy. Meltdown (Windows The operating system used https://news.softpedia.com/news/ Embedded System is susceptible to the microsoft-re-issues-kb4056894- 7) Meltdown malware. kb4056892-meltdown-spectre-for- some-amd-chips-519350.shtml Meltdown patch (KB4056894): https://www.catalog.update.micros oft.com/Search.aspx?q=4056894 Bugs (NHiberate) The reviewer was unable to https://github.com/nhibernate/nhib determine the version of ernate- NHibernate the system is core/issues?q=is%3Aopen+is%3A using. The link provided will issue+label%3A%22t%3A+Bug% list bugs found in all 22 versions of the software. The reviewer suggests the developer look at the list and find bugs against the version of NHiberate being used. Bugs (Fluent The reviewer was unable to https://github.com/FluentNHiberna NHibernate) determine the version of te/fluent- Fluent NHibernate the nhibernate/issues?q=is%3Aopen+ system is using. The link is%3Aissue+label%3Abug provided will list bugs found in all versions of the software. The reviewer suggests the developer look at the list and find bugs against the version of Fluent NHiberate being used. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 18 of 29 Name (Vulnerable Description Additional information component) DLL Hijacking The software is susceptible https://packetstormsecurity.com/fil (InnoSetup/Inno to including a Trojan horse es/134694/jrsoft-dllhijack.txt Script Setup) DLL that is located in an http://cve.mitre.org/cgi- untrusted path on the bin/cvename.cgi?name=CVE- system. 2010-4833 http://jrsoftware.org/files/is5- whatsnew.htm http://news.jrsoftware.org/news/in nosetup/msg103180.html http://news.jrsoftware.org/news/in nosetup/msg103182.html Malformed Windows The reviewer noticed how http://cve.mitre.org/cgi- binary not protected the developer has bin/cvename.cgi?name=CVE- (McAfee Application whitelisted what files should 2014-9920 Control for Devices) run on the system. The https://kc.mcafee.com/corporate/in following CVE is something dex?page=content&id=SB10077 to be aware of in the event a file is added that the program may think is non- executable. Table 2: Potential Vulnerabilities Identified 4.2 Static Code Analysis & Documentation Review Table 7 summarizes the findings that arose from the source code review team's assessment of the voting system. Potential exploitation of a weakness or vulnerability and type of attacker is noted where applicable. Description Assessment Categorization Usage of SHA-1 to The use of SHA-1 for signature Type: potential sign data and sign generation is generally disallowed by vulnerability and hash. Weakness of NIST (except where specifically non-conformity SHA-1 could allow for allowed in NIST protocol-specific (FIPS) corruption of data. guidance); however, its use for digital Severity: low signature verification is allowed for legacy use (i.e., the verification of already-generated digital signatures). Note: NIST still does allow testing of SHA-1 although NIST have requested federal agencies to stop using SHA-1. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 19 of 29 Description Assessment Categorization NIST have provided guidance on mitigating the risk of using SHA-1 in SP800-131a. Microsoft SQL Server Not having the latest version of the Type: potential 2012 (MSSQL) is not software leaves the system open to vulnerability patched. undiscovered and unpatched Severity: medium vulnerabilities. The version of MSSQL installed is 11.0.2100. There have been numerous Service Packs and Security updates since this release. In order to address any discovered (and potentially undiscovered) vulnerabilities, updating to the latest Service Pack is recommended (Service Pack 4). The ability to write The code has access to the system Type: potential directly to memory is a memory. Malicious code could be vulnerability potential vulnerability. interjected and executed. Severity: low Although compliant The algorithm used to determine if a Type: potential with CVSS 7.2.3 h) user’s password is strong enough is vulnerability requirements, not using best practices. The Severity: low password complexity algorithm does not enforce the use of rules do not follow best lower case lettering. This will allow a practices. The weaker password, by default. password complexity Also, the minimum length acceptable criteria allow for a is too small. Current practice for reduced strength secure password length is 12 to 15 password. If the characters. system becomes compromised, this will allow a threat agent to determine a user’s password more quickly. Password information The password field is being stored in Type: potential is not being stored the String class. vulnerability using an Severity: medium The All-in-one Code Framework appropriate/suitable Coding Standards states that MSDN class. Password provides guidelines for using the .NET Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 20 of 29 Description Assessment Categorization information is being framework. stored in an unsecure Since passwords are sensitive part of memory while information, a different class more being used. Code suitable to this type of information could be interjected, should be used, such as the using other parts of the SecureString class. code base, to access this sensitive From the Microsoft MSDN site: information. When created properly, a SecureString instance provides more data protection than a String. When creating a string from a character-at-a-time source, String creates multiple intermediate in memory, whereas SecureString creates just a single instance. Garbage collection of String objects is non-deterministic. In addition, because its memory is not pinned, the garbage collector will make additional copies of String values when moving and compacting memory. In contrast, the memory allocated to a SecureString object is pinned, and that memory can be freed by calling the Dispose method. Usage of authorization There is use of AuthorizationException Type: vulnerability check for a plugin in the modules. A catch of the Severity: medium could allow exception was detected but it did not unauthorized use of handle the exception. the plugin and manipulation by an unauthorized user. The SQL query strings SQL statements are being constructed Type: vulnerability are being constructed using ‘+’ or append method on a Severity: medium in a way that is class. vulnerable to SQL Best practice (OWASP) is to use injection attacks. parameterized queries for constructing SQL statements. CVSS 5.2.8 Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 21 of 29 Description Assessment Categorization Unable to determine The security policy was unable to be Type: potential security policy fully understood based on the PDFs vulnerability regarding configuration from the technical document package. Severity: low file access and modification. There are instances There are instances where Type: non- where exception/error exception/error handling doesn’t follow conformity, handling doesn’t follow a consistent implementation. potential a consistent Additionally, these instances do not vulnerability implementation. follow the guidelines described in the Severity: low Verity Logging Technical CVSS 5.2.5 Requirements Document (section 5.3: Events that must be logged). For example, there are catch blocks that do not write to any log files, there are instances where exceptions are caught and assigned to variables where nothing is done with that variable, and there are empty catch blocks. Product is no longer Product documentation states all Type: non- FIPS 140-2 certified or cryptographic modules used are FIPS conformity, conformant as claimed. 140-2 validated. potential Currently Non- vulnerability The FIPS 140-2 certificates listed in approved algorithms “Verity Operational Environment Severity: medium may contain 4005515 C00.pdf,” Appendix A, exploitable (#1319,#1326,#1327,#1328,#1329,#1 weaknesses and any 330,#1331) are all now on the CMVP data protected by historical list. encryption may be at Each historical certificate carries the risk. following disclaimer: CVSS 7.5.4 a) iii) "Historical - The referenced cryptographic module should not be included by Federal Agencies in new procurements. Agencies may make a risk determination on whether to continue using this module based on their own assessment of where and how it is used." FIPS requirements have changed since 2011 when these certificates were issued. Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 22 of 29 Description Assessment Categorization Technically, all modules used have been validated as conformant in 2011, but now the certifications have expired. Note: CVSS is not clear in regard to if historical FIPS 140-2 certifications are allowed. Table 3: Summary of issues discovered during the static code analysis Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 23 of 29 Glossary AES Advanced Encryption Standard API Application Programming Interface CAPI Crypto API CBC Cipher Block Chaining CMVP Cryptographic Module Validation Program COTS Commercial Off-The-Shelf CPE Common Platform Enumeration CRC Cyclic Redundancy Check CTR Counter CVE Common Vulnerability and Exposures CVR Cast Vote Record CWE Common Weakness Enumeration TDES Triple-Data Encryption Standard EC Elliptic Curve ECDSA Elliptic Curve Digital Signature Algorithm EDM Election Data Manager ELS Event Log Service EMS Election Management System EQC Election Qualification Code ERM Election Reporting Manager EVS Verity Voting System FIPS Federal Information Processing Standard HMAC Hash Message Authentication Code HTTP Hyper Text Transfer Protocol Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 24 of 29 HTTPS Hyper Text Transfer Protocol Secure IP Internet Protocol IV Initialization Vector KDF Key Derivation Function LAN Local Area Network OS Operating System PBKDF Password-Based Key Derivation Function PC Personal Computer PKI Public Key Infrastructure PRF Pseudo-Random Function PRNG Pseudorandom Number Generator RCV Ranked Choice Voting RMS Removable Media Service RNG Random Number Generator RSA Rivest-Shamir-Adleman SHA Secure Hash Algorithm SHS Secure Hash Standards SOS Secretary of State TCP Transmission Control Protocol TDP Technical Data Package TRD Technical Requirements Document USB Universal Serial Bus VAT Voter Assist Terminal XML Extensible Markup Language Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 25 of 29 References Documentation provided for the source code review included Verity EVS product documentation and other publicly available standards documents. The atsec source code review team also consulted other publicly available documents listed in the last group. Verity Documents PC Application Framework UI Design Document, Version 5 Print Design Reader Design Release Notes Verity Voting 3.0.0, Version A.00, Published 09-08-2016 Scan Design Touch Writer Design Verity 3.0 Desktop Database Schema Verity 3.0 Device Database Schema Verity Airgap Interface Technical Reference, Version A.02, Published 2014 Verity API Specification, Version A.03, Published 09-06-2017 Verity Base Station Microcontroller, Version A.01, Published 05-26-2015 Verity Build 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Build TRD, Version A.10, Published 10-14-2015 Verity Build User Interface Design Document, Version 11 Verity California Use Procedures, Verity Voting 3.0, Published 2017 Verity Central 3.0 Modification TRD, Version A.01, Published 07-18-2017 Verity Central TRD, Version A.07, Published 10-22-2015 Verity Central User Interface Specification, Version 8 Verity Coding Standard, Version A.15, Published 03-30-2018 Verity Count 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Count TRD, Version A.10, Published 11-02-2015 Verity Count User Interface Specification, Version 9 Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 26 of 29 Verity Data 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Data TRD, Version A.06 Verity Desktop User Interface Design Document, Version 3 Verity Device Suite 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Device Suite TRD, Version A.09, Published 11-03-2015 Verity Election Definition Data TRD, Version A.01, Published 10-14-2015 Verity Election Management TRD, Version A.06, Published 10-21-2015 Verity Election Management User Interface Design Document, Version 1 Verity Key Design Technical Document, Version A.01, Published 05-26-2015 Verity Logging 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Logging Design Technical Document, Version 1.03, Published 05-26-2015 Verity Logging TRD, Version A.04, Published 10-21-2015 Verity Print TRD, Version 6, Published 11-03-2015 Verity Reader TRD, Version A.01, Published 09-01-2017 Verity Risk and Threat Assessment, Version B.00, Published 02-14-2017 Verity Scan 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Scan TRD, Version A.07, Published 10-27-2015 Verity Security Requirements Document, Version A.07, Published 10-28-2015 Verity Shared Device User Interface Design Document, 7 Version Verity Software Architecture & Design, Version C.00, 02-14-2017 Verity System Design Verity Electronics Specification, Version A.13, Published 05-01- 2017 Verity Touch Writer 3.0 Modification TRD, Version A.01, Published 09-01-2017 Verity Touch Writer TRD, Version A.09, Published 11-03-2015 Verity Touch Writer User Interface Design Document, Version 12 Verity User Management 3.0 Modification, Version A.01, Published 09-01-2017 Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 27 of 29 Verity User Management TRD, Version A.01, Published 10-21-15 Verity User Management User Interface Design Document, Version 2 Verity Voting 3.0 System Limits, Version C.00, Published 08-30-2017 Verity Voting Verity Operational Environment, Version C.00, Published 09-11-2017 Public Documents All-In-One Code Framework Coding Standards, Published 2014 California Voting System Standards, Published October 2014 National Institute of Standards and Technology, Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program, January 2016, http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf National Institute of Standards and Technology, FIPS 140-2 Security Requirements for Cryptographic Modules, May 2001, http://csrc.nist.gov/publications/fips/fips140- 2/fips1402.pdf National Institute of Standards and Technology, FIPS 140-2 Annex A: Approved Security Functions, December 2002, http://csrc.nist.gov/publications/fips/fips140- 2/fips1402annexa.pdf National Institute of Standards and Technology, FIPS 180-4 Secure Hash Standard (SHS), March 2012, http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf National Institute of Standards and Technology, FIPS 186-4 Digital Signature Standard (DSS), July 2013, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186- 4.pdf National Institute of Standards and Technology, FIPS 197 Advanced Encryption Standard, November 2001, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf National Institute of Standards and Technology, FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC), July 2008, http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf National Institute of Standards and Technology, NIST Special Publication 800-57, Recommendation for Key Management—Part 1: General (Revised), January 2016, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf National Institute of Standards and Technology, NIST Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June, 2015, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 28 of 29 National Institute of Standards and Technology, NIST Special Publication 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, November, 2015, https://csrc.nist.gov/publications/detail/sp/800- 131a/rev-1/final OWASP, Open Web Application Security Project, The OWASP SQL and database Scripting Technology Knowledge Base, https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet Last update: 2018-09-07 Classification: Public Status: FINAL Version: 2.0 ©2018 atsec information security corporation Page 29 of 29