November 24, 2024

Electronic Voting Researcher Arrested Over Anonymous Source

Updates: 8/28 Alex Halderman: Indian E-Voting Researcher Freed After Seven Days in Police Custody
8/26 Alex Halderman: Indian E-Voting Researcher Remains in Police Custody
8/24 Ed Felten: It’s Time for India to Face its E-Voting Problem
8/22 Rop Gonggrijp: Hari is in jail 🙁

About four months ago, Ed Felten blogged about a research paper in which Hari Prasad, Rop Gonggrijp, and I detailed serious security flaws in India’s electronic voting machines. Indian election authorities have repeatedly claimed that the machines are “tamperproof,” but we demonstrated important vulnerabilities by studying a machine provided by an anonymous source.

The story took a disturbing turn a little over 24 hours ago, when my coauthor Hari Prasad was arrested by Indian authorities demanding to know the identity of that source.

At 5:30 Saturday morning, about ten police officers arrived at Hari’s home in Hyderabad. They questioned him about where he got the machine we studied, and at around 8 a.m. they placed him under arrest and proceeded to drive him to Mumbai, a 14 hour journey.

The police did not state a specific charge at the time of the arrest, but it appears to be a politically motivated attempt to uncover our anonymous source. The arresting officers told Hari that they were under “pressure [from] the top,” and that he would be left alone if he would reveal the source’s identity.

Hari was allowed to use his cell phone for a time, and I spoke with him as he was being driven by the police to Mumbai:

The Backstory

India uses paperless electronic voting machines nationwide, and the Election Commission of India, the country’s highest election authority, has often stated that the machines are “perfect” and “fully tamper-proof.” Despite widespread reports of election irregularities and suspicions of electronic fraud, the Election Commission has never permitted security researchers to complete an independent evaluation nor allowed the public to learn crucial technical details of the machines’ inner workings. Hari and others in India repeatedly offered to collaborate with the Election Commission to better understand the security of the machines, but they were not permitted to complete a serious review.

Then, in February of this year, an anonymous source approached Hari and offered a machine for him to study. This source requested anonymity, and we have honored this request. We have every reason to believe that the source had lawful access to the machine and made it available for scientific study as a matter of conscience, out of concern over potential security problems.

Later in February, Rop Gonggrijp and I joined Hari in Hyderabad and conducted a detailed security review of the machine. We discovered that, far from being tamperproof, it suffers from a number of weaknesses. There are many ways that dishonest election insiders or other criminals with physical access could tamper with the machines to change election results. We illustrated two ways that this could happen by constructing working demonstration attacks and detailed these findings in a research paper, Security Analysis of India’s Electronic Voting Machines. The paper recently completed peer review and will appear at the ACM Computer and Communications Security conference in October.

Our work has produced a hot debate in India. Many commentators have called for the machines to be scrapped, and 16 political parties representing almost half of the Indian parliament have expressed serious concerns about the use of electronic voting.

Earlier this month at EVT/WOTE, the leading international workshop for electronic voting research, two representatives from the Election Commission of India joined in a panel discussion with Narasimha Rao, a prominent Indian electronic voting critic, and me. (I will blog more about the panel in coming days.) After listening to the two sides argue over the security of India’s voting machines, 28 leading experts in attendance signed a letter to the Election Commission stating that “India’s [electronic voting machines] do not today provide security, verifiability, or transparency adequate for confidence in election results.”

Nevertheless, the Election Commission continues to deny that there is a security problem. Just a few days ago, Chief Election Commissioner S.Y. Quraishi told reporters that the machines “are practically totally tamper proof.”

Effects of the Arrest

This brings us to today’s arrest. Hari is spending Saturday night in a jail cell, and he told me he expects to be interrogated by the authorities in the morning. Hari has retained a lawyer, who will be flying to Mumbai in the next few hours and who hopes to be able to obtain bail within days. Hari seemed composed when I spoke to him, but he expressed great concern for his wife and children, as well as for the effect his arrest might have on other researchers who might consider studying electronic voting in India.

If any good has come from this, it’s that there has been an outpouring of support for Hari. He has received positive messages from people all over India.

Unfortunately, the entire issue distracts from the primary problem: India’s electronic voting machines have fundamental security flaws, and do not provide the transparency necessary for voters to have confidence in elections. To fix these problems, the Election Commission will need help from India’s technical community. Arresting and interrogating a key member of that community is enormously counterproductive.


Professor J. Alex Halderman is a computer scientist at the University of Michigan.

The Future of DRE Voting Machines

Last week at the EVT/WOTE workshop, Ari Feldman and I unveiled a new research project that we feel represents the future of DRE voting machines. DRE (direct-recording electronic) voting machines are ones where voters cast their ballots by pressing buttons or using a touch screen, and the primary record of the votes is stored in a computer memory. Numerous scientific studies have demonstrated that such machines can be reprogrammed to steal votes, so when we got our hands on a DRE called the Sequoia AVC Edge, we decided to do something different: we reprogrammed it to run Pac-Man.

As more states move away from using insecure DREs, there’s a risk that thousands of these machines will clog our landfills. Fortunately, our results show that they can be productively repurposed. We believe that in the not-so-distant future, recycled DREs will provide countless hours of entertainment in the basements of the nation’s nerds.

To see how we did it, visit our Pac-Man on the AVC Edge voting machine site.

A Major Internet Milestone: DNSSEC and SSL

On July 15th, a small but significant internet event occurred. On that day, years of planning culminated in the deployment of a cryptographic signature on the root DNS zone. To simplify greatly, this means that internet users will soon be able to have a much higher degree of trust in the hierarchical Domain Name System by utilizing the powers of recursion and cryptography. When a user’s computer is told that the IP address for “gmail.com” is 72.14.204.19, the user can be sure that this answer is true. This is important if you are someone such as a Chinese dissident who wants to reliably and securely reach gmail.com in order to communicate with your peers. The rollout of this throughout all domains, DNS resolvers, and client applications will take a little while, but the basic infrastructure is now in place.

This mitigates a certain class of vulnerabilities that web users used to face. Although it forecloses attacks at the domain name-to-IP address stage of requesting a web page, it does not necessarily foreclose attacks at other stages. For instance, an attacker that gets between you and the server you are trying to reach can simply claim that he is the server at 72.14.204.19. Our traditional way of protecting against this style of attack has been to rely on Certificate Authorities — trusted third-parties who certify digital key-pairs only for the true owners of a given domain name. Thus, even if an attacker tries to execute one of these “man-in-the-middle” attacks, he won’t possess the secret portion of the digital key-pair that is required to prove that his communications come from the true gmail.com. Your browser checks for a certified corresponding public key in the process of setting up a secure SSL/TLS connection to https://gmail.com.

Unfortunately, there are several technical, operational, and jurisdictional shortcomings of the Certificate Authority model. As I discussed in an earlier post, many of these problems are not present in the hierarchical and delegated model of DNS. However, DNS does not inherently provide the ability to store domain name-to-key-pair information. But could it? At one of the recent DNSSEC deployment ceremonies, Vint Cerf noted:

More has happened here today than meets the eye. An infrastructure has been created for a hierarchical security system, which can be purposed and re-purposed in a number of different ways. And so I would predict that although we started out putting this system together to assure that the domain name lookups return valid internet addresses, that in the long run this hierarchical structure of trust will be applied to a number of other functions that require strong authentication. And so you will have seen a new major milestone in the internet story.

I believe that storing SSL/TLS keys in DNSSEC-secured DNS records will be the first significant “other function” that will emerge. An alternative to Certificate Authorities for domain-to-key mapping is sorely needed. There are two major practical hurdles to getting there: 1) We must define a standard for placing keys in DNS and 2) We must secure the “last mile” from the service provder’s DNS resolver to the end-user’s computer.

The first hurdle involves the type of standard-setting that the internet community is quite familiar with. On a technical level, it means that we need to collectively decide what these DNS records look like. The second hurdle involves building more functionality into end users’ software so that it can do cryptographic validation of DNS results rather than blindly trusting its upstream DNS resolver. There may be temporary ways to do this within web browser code, but ultimately it will probably have to be built into what is called the “stub resolver” — a local service running on your computer that usually just asks for the results from the upstream resolver.

It is important to note that none of his makes Certificate Authorities obsolete. Although the DNS-based approach replaces the most basic type of SSL certificates, the Certificate Authorities will continue to be the only entities that can offer validation of real-world identity of site owners. The DNS-based approach and basic “domain validated” Certificate Authority certificates both verify only that whoever controls the domain name is the entity that your computer is communicating with, without saying who that is. In recent years, “Extended Validation” certificates (the ones that make your browser bar glow green) have begun to be offered by all major certificate authorities. These certificates require more rigorous validation of the identity of the owner, so that for example you know that the person who controls bankofamerica.com is really Bank of America Corporation.

At this year’s Black Hat and Defcon, Dan Kaminsky demonstrated some new software he is releasing that could make deploying DNSSEC more easy in general, and that could also address the two main hurdles to placing keys in DNS. He readily admits that his particular implementation is not perfect, and has encouraged critiques and changes. [Update: His slides are available here.]

Hopefully, with the input of the many smart folks in the security, internet standards, and software development communities, we will see a production-quality DNSSEC-secured solution to domain-to-key authentication in the near future.

The Stock-market Flash Crash: Attack, Bug, or Gamesmanship?

Andrew wrote last week about the stock market’s May 6 “flash crash”, and whether it might have been caused by a denial-of-service attack. He points to a detailed analysis by nanex.com that unpacks what happened and postulates a DoS attack as a likely cause. The nanex analysis is interesting and suggestive, but I see the situation as more complicated and even more interesting.

Before diving in, two important caveats: First, I don’t have access to raw data about what happened in the market that day, so I will accept the facts as posited by nanex. If nanex’s description is wrong or incomplete, my analysis won’t be right. Second, I am not a lawyer and am not making any claims about what is lawful or unlawful. With that out of the way …

Here’s a short version of what happened, based on the nanex data:
(1) Some market participants sent a large number of quote requests to the New York Stock Exchange (NYSE) computers.
(2) The NYSE normally puts outgoing price quotes into a queue before they are sent out. Because of the high rate of requests, this queue backed up, so that some quotes took a (relatively) long time to be sent out.
(3) A quote lists a price and a time. The NYSE determined the price at the time the quote was put into the queue, and timestamped each quote at the time it left the queue. When the queues backed up, these quotes would be “stale”, in the sense that they had an old, no-longer-accurate price — but their timestamps made them look like up-to-date quotes.
(4) These anomalous quotes confused other market participants, who falsely concluded that a stock’s price on the NYSE differed from its price on other exchanges. This misinformation destabilized the market.
(5) The faster a stock’s price changed, the more out-of-kilter the NYSE quotes would be. So instability bred more instability, and the market dropped precipitously.

The first thing to notice here is that (assuming nanex has the facts right) there appears to have been a bug in the NYSE’s system. If a quote goes out with price P and time T, recipients will assume that the price was P at time T. But the NYSE system apparently generated the price at one time (on entry to the queue) and the timestamp at another time (on exit from the queue). This is wrong: the timestamp should have been generated at the same time as the price.

But notice that this kind of bug won’t cause much trouble under normal conditions, when the queue is short so that the timestamp discrepancy is small. The problem might not have be noticed in normal operation, and might not be caught in testing, unless the testing procedure takes pains to create a long queue and to check for the consistency of timestamps with prices. This looks like the kind of bug that developers dread, where the problem only manifests under unusual conditions, when the system is under a certain kind of strain. This kind of bug is an accident waiting to happen.

To see how the accident might develop and be exploited, let’s consider the behavior of three imaginary people, Alice, Bob, and Claire.

Alice knows the NYSE has this timestamping bug. She knows that if the bug triggers and the NYSE starts issuing dodgy quotes, she can make a lot of money by exploiting the fact that she is the only market participant who has an accurate view of reality. Exploiting the others’ ignorance of real market conditions—and making a ton of money—is just a matter of technique.

Alice acts to exploit her knowledge, deliberately triggering the NYSE bug by flooding the NYSE with quote requests. The nanex analysis implies that this is probably what happened on May 6. Alice’s behavior is ethically questionable, if not illegal. But, the nanex analysis notwithstanding, deliberate triggering of the bug is not the only possibility.

Bob also knows about the bug, but he doesn’t go as far as Alice. Bob programs his systems to exploit the error condition if it happens, but he does nothing to cause the condition. He just waits. If the error condition happens naturally, he will exploit it, but he’ll take care not to cause it himself. This is ethically superior to a deliberate attack (and might be more defensible legally).

(Exercise for readers: Is it ethical for Bob to deliberately refrain from reporting the bug?)

Claire doesn’t know that the NYSE has a bug, but she is a very careful programmer, so she writes code that watches other systems for anomalous behavior and ignores systems that seem to be misbehaving. When the flash crash occurs, Claire’s code detects the dodgy NYSE quotes and ignores them. Claire makes a lot of money, because she is one of the few market participants who are not fooled by the bad quotes. Claire is ethically blameless — her virtuous programming was rewarded. But Claire’s trading behavior might look a lot like Alice’s and Bob’s, so an investigator might suspect Claire of unethical or illegal behavior.

Notice that even if there are no Alices or Bobs, but only virtuous Claires, the market might still have a flash crash and people might make a lot of money from it, even in the absence of a denial-of-service attack or indeed of any unethical behavior. The flood of quote requests that trigged the queue backup might have been caused by another bug somewhere, or by an unforeseen interaction between different systems. Only careful investigation will be able to untangle the causes and figure out who is to blame.

If the nanex analysis is at all correct, it has sobering implications. Financial markets are complex, and when we inject complex, buggy software into them, problems are likely to result. The May flash crash won’t be the last time a financial market gyrates due to software problems.

School's Laptop Spying Software Exploitable from Anywhere

This post is by Jay Novak, Jon Stribley, and J. Alex Halderman.

Absolute Manage is a remote administration program that allows sysadmins to supervise and maintain client computers over the Internet. It has been in the news since early February, when Lower Merion School District in Pennsylvania was alleged to be using it to spy on students at home via their laptop webcams. The story took a new twist last Thursday, when Threat Level reported that researchers at Leviathan Security Group had discovered serious vulnerabilities in the program. These problems let attackers carry out a number of exploits, including installing malware or running other arbitrary code on the students’ laptops. The major limitation in the reported attacks is that the bad guy needs to be on the same local network as the victim, and the program’s developers, Absolute Software, says it’s a largely theoretical threat.

Unfortunately, the security problems are worse than has been reported so far, and are far from theoretical. In fact, any machine with a public IP address running Absolute Manage can be taken over by attackers anywhere on the Internet. Such an attacker can command the machine to run arbitrary code, steal data, or take photographs using the computer’s camera.

We have been investigating Absolute Manage for several months, hoping to gain a better understanding of the security measures it employs to protect users. We are disclosing this information now because, following the Threat Level post, we believe it’s only a matter of time until real attackers discover it. Users need to be aware of the vulnerabilities and take proper measures to protect themselves.

Broken Cryptography

The security issues revolve around the way Absolute Manage encrypts commands sent to the clients. The software has two parts: the Absolute Manage Agent, which runs on client machines, and the Absolute Manage Server, which tracks clients under its supervision and sends commands to perform remote operations like installing new software. The clients and server exchange messages using a TCP-based protocol. Clients continuously listen for messages containing instructions from the server, and they also periodically send “heartbeat” messages to the server to deliver status updates and pull down any queued commands.

The programs compress and encrypt each message before transmitting it. They use an encryption algorithm called Blowfish, which is a credible, if outmoded, choice. The problem is how the keys are managed. Strong encryption protocols like SSL negotiate a new secret key for each communication session, but Absolute Manage uses the same hard coded key every time, in every client. Blowfish can use variable-sized keys from 1-56 bytes, and the programmers decided to use secret textual phrases for the keys. We know what the keys are. We won’t publish them here, but they were easy to figure out by inspecting the program files.

Using hard coded keys neutralizes the benefits of cryptography. Since the same, easy-to-discover key is used in every client, it’s straightforward for an attacker to unwrap the encrypted messages, modify them, or encrypt messages of his own. This problem is very similar to the broken cryptography in Diebold voting machines that Ari, Alex, and Ed discovered years ago. Diebold also used a simple fixed key, which allowed an attacker with access to one machine to learn the key and attack all the other machines.

The broken cryptography in Absolute Manage enables a variety of attacks. For instance, an attacker can eavesdrop on a command sent from the server and rewrite it to issue a new command that installs and executes malicious code. Or, he can act as a man-in-the-middle between the client and server and insert evil commands in response to a client heartbeat message. An attacker could easily do these by sniffing wireless LAN traffic, as in school and office environments where Absolute Manage is often deployed. These seem to be the attacks referred to in the Threat Level post.

Exploitable from Anywhere

The limitation of these attacks is that the bad guy usually needs to be on the same physical network as the victim. However, we discovered that potentially more dangerous attacks are possible. In these attacks, a bad guy anywhere on the Internet can exploit any Absolute Manage client with a publicly reachable IP address.

Here’s an example of a message from the server to the client, with the encryption and compression removed. The client tries to authenticate the command using a parameter called the SeedValue. This value is provided by the server when a client initially attempts to contact it after booting. After that, the client requires the SeedValue to be the same in subsequent commands. The client basically ignores all of the other parameters that look like they would be hard to guess, so the SeedValue is the only thing that makes it difficult for the attacker to generate his own command messages from whole cloth.

In our example message, the SeedValue is:

D969E2CD0CB67F4063F45CEAC7D145B12D76A969306AE0CE

It turns out that it is encrypted using a second hard-coded textual phrase. Decrypting it yields the following bytes:

00 00 00 00 e0 03 10 03 40 03 00 00 31 00 34 00 37 00 35 00 00 00 00 00 00

The length is misleading; the value is actually just a 16-bit unicode encoding of a 7-digit number, 1401475. This is the server’s “serial number,” which was provided by Absolute Software along with the product activation key when we purchased our license.

Thus, an attacker who wants to send arbitrary commands to Absolute Manage clients just needs to figure out the server’s serial number. One way he can do that is to guess it. The attacker could try contacting the client with different values until one of them turns out to be correct. If all serial numbers are 7 digits (like ours) or less, and there is no pattern to there assignment, then an attacker can guess among 10 million possibilities. If there is a pattern (the likely case) then the attacker’s job may be much easier. Our tests show that we can make more than 330 guesses/second over a fast network link, so even assuming no pattern an attacker could expect to succeed after about four hours of guessing. Each server uses the same serial number for all its clients, so after the attacker guesses it for one client, he can compromise all the server’s other clients without any additional guesswork.

Brute forcing the server’s serial number is one method attackers can use, but there is a much more efficient attack for targeting a large set of clients: the server will tell the correct SeedValue to any client that asks. If the attacker knows the IP address of the server a client is trying to contact, he can just impersonate a freshly-booted client and ask the server to send him the correct SeedValue. The server will respond with all the information the attacker needs to impersonate the server.

A bad guy could extend this method to target all Absolute Manage clients in one attack. He could scan the entire Internet address space to discover all hosts running Absolute Manage Server and build a list of active SeedValues. (Servers generally run on public IP addresses so that they can receive status updates from clients that are away from the local network.) Such a scan would take only a few days. The attacker could then do a second Internet-wide scan to discover Absolute Manage Clients. For each of them, he would need only a few seconds to try all the active SeedValues from his list and determine the correct one. This attack could be exploited to quickly install and run malicious code on all computers running the Absolute Manage client on publicly accessible IP addresses.

Defenses and Lessons

In the short term, users can protect themselves by uninstalling the Absolute Manage client. This might be difficult on machines with privileges locked down, so system administrators will need to help.

(Attempts to work around the problem, such as firewalling the server so it can’t be found by an Internet scan, may backfire. If the server is unreachable from outside the firewall, clients that are rebooted away from the local network will be unable to obtain a SeedValue. In this situation, the clients insecurely default to accepting arbitrary commands without even the protection of a SeedValue.)

In the long term, the solution is for Absolute Manage to adopt serious cryptographic authentication. Absolute Software says they will do this in the next version later this summer–let’s hope they get it right next time.

Remote administration products like Absolute Manage carry large risks because they intentionally create a mechanism for a remote third party to take control of the machine. This can be powerful in the right hands but devastating if exploited by attackers. There will always be a risk of abuse by authorized parties, as alleged in the students’ lawsuit against Lower Merion School District, but correctly designed technology should at least prevent unauthorized third-party attacks by making sure only authorized parties can issue commands. This requires getting authentication right–exactly what Absolute Manage failed to do.

Because of these dangers, remote administration software should be designed defensively, minimizing the risk even if the authentication fails. For example, it could only allow installation of signed binaries, or it could give users prominent notification before actions are taken so that attacks can be more easily detected.

The blatant vulnerabilities in Absolute Manage suggest that this kind of remote administration software requires greater security scrutiny. We will further discuss the problems and the lessons they carry in a forthcoming paper.