Download Hack-A-Vote: Exploiting Election Security Flaws and more Study notes Computer Science in PDF only on Docsity!
Hack-A-Vote: Part
Corey Shaw & Derek Sessions
Motivation
Our changes are party-agnostic and thus we can sell our security flaws to whomever we choose, or even sell it to everyone who is interested. The exploits that we have added allow for ballot-box stuffing, DOS attacks on election machines, and can remove voter anonymity. Thus, any party can use these hacks to affect an election. All the hacks do, however, require an operative to implement them. The operatives have little work to do and should be able to accomplish their tasks with little to no risk. We intend to sell our security flaws using craigslist.
The requirement to have an operative present to affect the election was a conscious decision. We felt that automatic hacks would appear obvious both within the code and from black-box testing, making it not a feasible solution to our task (as we would rather be at a beach on a tropical island than a jail.) We also avoided the addition of if statements and its ilk, as we felt that those would be the most obvious hacks and would be flagged for scrutiny.
In addition to our exploits, we have added additional try-catch blocks to the program that do not report error, and have removed error reporting from some try-catch blocks to help create confusion and potentially cover our tracks. We feel that these are not worth talking about further since they are minor changes and poll workers are perfect, so it should never come up.
Implementation
Password hash security flaw:
Effect: The hash of the password entered is checked against the .properties file, which contains the correct hash. However, there is nothing stopping the .properties file from being modified by a user with malicious intent. This effectively changes the password and would allow unauthorized users to take control of the machine, or remove the hash to prevent election works ending the election and retrieving the results.
Details: We made the system seem more secure by removing the password from plaintext, and also tweaked it to have the password in a .properties file such that the vendor could change the password without rebuilding the program (a nice software engineering feature). However, we specifically did not protect the .properties file from being changed by an unauthorized party. Anyone who knows our hash function (which turns out to be Java’s String.hashCode) could replace the PWD line in the file with the hash of a password they know, and gain access to the machine.
The implementation is straightforward, and not meant to be hidden. The goal here was to look like we’re improving the security, while leaving a specific backdoor that we know how to exploit. The only way that the properties file would be able to be properly protected is if there was some sort of TPM chip, or the file was signed by the vendor.
Magic Pin:
Effect: The PIN ‘6231’ can always be used to cast a ballot. This would allow a malicious user to stuff the ballot box, provided he has the ability to reconcile the extra votes with the sign-in logs. (If not, the extra votes would at least cause confusion.) Even if the user is unable to reconcile the sign-in logs, it would cast doubt on the election. This could be teamed with one of the exploits that allows an operative to end the election early and overwrite all or some of the previously cast results.
Details: We hid the implementation in the IniFile class, though it actually affects how the Console app runs. In IniFile’s static initializer (which is hidden to the right of the file), Console’s vector which contains an array of valid pins is overridden by a subclass which always returns true on contains (6231). The magic PIN is not actually contained in the list, so it’s never removed, and does not show on the Console GUI. We didn’t change the BallotControl side at all, it still asks over the network if the PIN is okay, but our hack causes the Console to say it is when 6231 is entered. To allow this to function properly, we added a reference to IniFile to ConsoleGUI so that IniFile would be statically loaded and thus initialize the vector to our overloaded anonymous vector.
This flaw would allow a voter to vote as normal, and then enter the magic PIN and vote again (as many times as they wanted).
Premature election finish:
Effect: Any voter can end an election at will by pressing Alt+C. If the election is restarted by a poll worker on a machine, it will begin to overwrite previously cast ballots, helping to destroy the ‘paper’ trail. This will create doubt in the legitimacy of an election, and can be also used to help cover up use of some of the other available exploits.
Details: A JButton was added to the right panel of the main form, under the American flag and Hack-A-Vote mark. The button is sized to be (0,0) and has is mnemonically bound to c. These operations are accomplished within the BallotGUI constructor hidden amongst the initialization of a large number of GUI components. The action listener used is shared between it and the “End Election” button through a static field in the BallotControl class. This is done to avoid adding an anonymous inner class definition in BallotGUI, which contains very few pieces of code that match that style of formatting. Upon being called via Alt+C, it executes its attached action listener and ends the election. If the machine is restarted, the current results will be cleared
