Hack-a-Vote Project: Findings from COMP 527 on Computer Systems Security - Prof. Dan S. Wa, Study Guides, Projects, Research of Computer Science

Download Hack-a-Vote Project: Findings from COMP 527 on Computer Systems Security - Prof. Dan S. Wa and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Hack-a-Vote Project, Phase 3

Computer Systems Security

COMP 527

Prof Dan Wallach

Brandon Caesar

Yan-jun Sun

October 7, 2005

What hacks did it find?

FindBugs Although we maximized the detection settings in FindBugs, the results were not very helpful. Only one of the warnings provided a clue about one of our hacks, but we have 9 hacks in total. The warning was “Calls to some system calls like exit() (in ConsoleGUI.java)”

h e a d e r L a b e l. addMouseListener (new MouseAdapter ( ) { public void mouseClicked ( MouseEvent e ) { i f ( e. g e t C l i c k C o u n t ( ) == 3 ){ System. e x i t ( 0 ) ; } } } ) ;

We could replace the call to System.exit() with a different bit of malicious code (maybe something involving buffer allocation) to make the hacks detection harder.

Fortify While Fortify was unable to pinpoint our hacks as bugs, it was able to provide hints towards discovering two of them. For instance, one of our hacks attached an extra event handler to the ConsoleGUI that would allow someone to execute code simply by clicking three times on one of the gui’s labels. In our implementation we simply called System.exit() when the event handler was called. Fortify did not flag the event handler itself, but it pointed out that calling System.exit() is bad style for J2EE/web applications. In this case Fortify manages to inadvertantly direct an auditor to this hack. Of course, if we did something other than calling System.exit() it may not have been as useful. Fortify also cited numerous coding style issues with one other hack. We had a hack that would spawn threads that opened client ports to the voting server and repeatedly sent data, in hopes of causing denial of service. Fortify didn’t question the purpose of the code, but it did complain about using threads, opening ports directly instead of using an established protocol (ssh, soap, etc...), a possible null pointer reference, and the fact the data stream and socket objects could potentially never be closed. All of those issues would seem to give credence to Fortify’s usefulness, but all of those issues (excpet thread use) were also cited elsewhere in ’legal’ places in the code. Which isn’t a big suprise, since we copied the code for opening a client port directly from the original code. None of the issues that Fortify raised actually exposed the hacks as hacks. In fact the tool seems to have more use as a coding style enforcer.

What other potential exploits did it find?

FindBugs

1. NULL pointer exception warning (in BallotControl.java)

S t r i n g v a l i d a t e d = s i n. r e a d L i n e ( ) ;

applications. Being biased in this way means that calls to System.exit() and any other system-wide affecting calls are heavily discouraged, although when running a single java application on a desktop, calls to System.exit() are quite common. I suppose this bias wouldn’t be too bad from the perspective of a hack-a-vote auditor, since half of the program is the administration server and one of the primary actions of the program involves communicating over a remote connection.

How could an automated tool do better?

Only one out of our nine hacks can be found from the output of the above tools. To enhance those detection tools, we propose to provide more knowledge about the auditing target of the detection software.

1. Provide precise information about the resources required by the target program For instance, in the voting system, we know that there is going to be only one TCP port,1776, in use by the server and only one TCP port in use at each terminal at any given time. Also, there should be only one thread (except for the GUI’s). Therefore, any attempt to open an additional port or thread should be flagged.
2. Estimate resource bound To prevent a hacker from consuming excessive resources in the system (threads, memory alloca- tion in heaps), we can give an estimated bound to the detection program. Then we can use the bound as a trigger for a warning.
3. Incorporate a spell checker to find mispelled variable names Many of our hacks depended on using variable names for hacked fields and methods that were nearly identical to the original and only slightly mispelled. The software could check all non- keyword and uncommented words for spelling errors, using a user defined dictionary. This would be extremely helpful if the target program has set guidelines and specifications for varible names.
4. Flag loosely scoped variables Most of our hacks exploited the fact that most of the variables used in the program were declared as package public. We also took advantage of the fact that many of the constants were not declared as final. It would be trivial to implement a routine that flags loosely scoped variables and recommends that they be scoped as narrowly as possible (or even change them automatically).

For some of the hacks we implemented, we could not figure out a way to help the automated tool. The hacks include:

1. Event handler overwritten For a system with many event handlers, the large number of warnings produced would hide the hack. We need a way to tell malicious handlers from good handlers.
2. Malicious behavior under some specific conditions Some of our hacked code will not take effect until certain conditions are meet. For example, the malicious code is only called when the program has been running for over 24 hours, or there are more than 2 terminals (three or more different IP addresses are detected) involved. There

are no fixed rules for the conditions, which depends on the application. Therefore, it’s hard to devise an algorithm to use in the automated tools.

It is important to note, however, that the additions we have proposed are specific to our hacks and may be completely useless in finding others. The main idea here is that a better automated tool would be heavily extensible. The user should be able to specify what to look for, where to look for it, and how to look for it. That way the tool could do clever things like flag a mispelled variable name as suspicious or monitor memory usage and complain if there are any sudden spikes.