August 24, 2016

J. Alex Halderman

I'm an assistant professor of electrical engineering and computer science at the University of Michigan. My research spans applied computer security and tech-centric public policy. Topics that interest me include software security, data privacy, electronic voting, censorship resistance, digital rights management, and cybercrime, as well as technological aspects of intellectual property law and government regulation.


Let’s Encrypt: Bringing HTTPS to Every Web Site

HTTPS, the cryptographic protocol used to secure web traffic as it travels across the Internet, has been in the news a lot recently. We’ve heard about security problems like Goto Fail, Heartbleed, and POODLE — vulnerabilities in the protocol itself or in specific implementations — that resulted in major security headaches. Yet the single biggest problem with HTTPS is that not enough sites use it. More than half of popular sites — and a much larger fraction of sites overall — still use old-fashioned HTTP, which provides no cryptographic protection whatsoever. As a result, these sites and their users are vulnerable to eavesdropping and manipulation by a range of threat vectors, from compromised WiFi access points to state-level mass surveillance. When deployed correctly, HTTPS defends against all these attacks.

Why don’t more sites use HTTPS? The major obstacle is that it’s too difficult for web sites to set up and maintain. Switching to HTTPS involves purchasing a digital certificate (a cryptographic statement that your domain name belongs to you) from a “certificate authority,” an identity-checking organization that users’ browsers are programmed to trust. This process involves a long series of manual steps, as well as fees that range from tens to hundreds of dollars a year. Site operators must also navigate a complicated process to generate crypto keys, validate the site’s identity, retrieve a certificate, and configure their server to use it. These steps, which have to be repeated every year or so when the certificate expires, are also prone to human error, with the result that a substantial fraction of all HTTPS sites have configuration problems that jeopardize their security.

For the past two years, I’ve been working with a talented group of people to do something about these problems. My student James Kasten and I joined forces with Peter Eckersley and Seth Schoen from EFF and Eric Rescorla, Josh Aas, and Richard Barnes from Mozilla. Our goal is to remove the barriers to deploying HTTPS and see an encrypted web completely replace unencrypted HTTP.

Today, we’re announcing Let’s Encrypt, a new certificate authority we’re creating that will begin operation in Summer 2015. What makes Let’s Encrypt different is that it takes the pain out of switching to HTTPS. Web site operators simply install a small piece of software that takes care of the entire process. This software interacts with Let’s Encrypt to validate the server’s identity, obtain a certificate, securely configure the server to use HTTPS, and automatically renew the certificate when necessary. With Let’s Encrypt, one click or one command is all it will take for a site to deploy HTTPS.
[Read more…]


Anticensorship in the Internet's Infrastructure

I’m pleased to announce a research result that Eric Wustrow, Scott Wolchok, Ian Goldberg, and I have been working on for the past 18 months: Telex, a new approach to circumventing state-level Internet censorship. Telex is markedly different from past anticensorship efforts, and we believe it has the potential to shift the balance of power in the censorship arms race.

What makes Telex different from previous approaches:

  • Telex operates in the network infrastructure — at any ISP between the censor’s network and non-blocked portions of the Internet — rather than at network end points. This approach, which we call “end-to-middle” proxying, can make the system robust against countermeasures (such as blocking) by the censor.
  • Telex focuses on avoiding detection by the censor. That is, it allows a user to circumvent a censor without alerting the censor to the act of circumvention. It complements anonymizing services like Tor (which focus on hiding with whom the user is attempting to communicate instead of that that the user is attempting to have an anonymous conversation) rather than replacing them.
  • Telex employs a form of deep-packet inspection — a technology sometimes used to censor communication — and repurposes it to circumvent censorship.
  • Other systems require distributing secrets, such as encryption keys or IP addresses, to individual users. If the censor discovers these secrets, it can block the system. With Telex, there are no secrets that need to be communicated to users in advance, only the publicly available client software.
  • Telex can provide a state-level response to state-level censorship. We envision that friendly countries would create incentives for ISPs to deploy Telex.

For more information, keep reading, or visit the Telex website.

The Problem

Government Internet censors generally use firewalls in their network to block traffic bound for certain destinations, or containing particular content. For Telex, we assume that the censor government desires generally to allow Internet access (for economic or political reasons) while still preventing access to specifically blacklisted content and sites. That means Telex doesn’t help in cases where a government pulls the plug on the Internet entirely. We further assume that the censor allows access to at least some secure HTTPS websites. This is a safe assumption, since blocking all HTTPS traffic would cut off practically every site that uses password logins.

<!– –>

Many anticensorship systems work by making an encrypted connection (called a “tunnel”) from the user’s computer to a trusted proxy server located outside the censor’s network. This server relays requests to censored websites and returns the responses to the user over the encrypted tunnel. This approach leads to a cat-and-mouse game, where the censor attempts to discover and block the proxy servers. Users need to learn the address and login information for a proxy server somehow, and it’s very difficult to broadcast this information to a large number of users without the censor also learning it.

How Telex Works

Telex turns this approach on its head to create what is essentially a proxy server without an IP address. In fact, users don’t need to know any secrets to connect. The user installs a Telex client app (perhaps by downloading it from an intermittently available website or by making a copy from a friend). When the user wants to visit a blacklisted site, the client establishes an encrypted HTTPS connection to a non-blacklisted web server outside the censor’s network, which could be a normal site that the user regularly visits. Since the connection looks normal, the censor allows it, but this connection is only a decoy.

The client secretly marks the connection as a Telex request by inserting a cryptographic tag into the headers. We construct this tag using a mechanism called public-key steganography. This means anyone can tag a connection using only publicly available information, but only the Telex service (using a private key) can recognize that a connection has been tagged.

As the connection travels over the Internet en route to the non-blacklisted site, it passes through routers at various ISPs in the core of the network. We envision that some of these ISPs would deploy equipment we call Telex stations. These devices hold a private key that lets them recognize tagged connections from Telex clients and decrypt these HTTPS connections. The stations then divert the connections to anti­censorship services, such as proxy servers or Tor entry points, which clients can use to access blocked sites. This creates an encrypted tunnel between the Telex user and Telex station at the ISP, redirecting connections to any site on the Internet.

<!– –>

Telex doesn’t require active participation from the censored websites, or from the non-censored sites that serve as the apparent connection destinations. However, it does rely on ISPs to deploy Telex stations on network paths between the censor’s network and many popular Internet destinations. Widespread ISP deployment might require incentives from governments.

Development so Far

At this point, Telex is a concept rather than a production system. It’s far from ready for real users, but we have developed proof-of-concept software for researchers to experiment with. So far, there’s only one Telex station, on a mock ISP that we’re operating in our lab. Nevertheless, we have been using Telex for our daily web browsing for the past four months, and we’re pleased with the performance and stability. We’ve even tested it using a client in Beijing and streamed HD YouTube videos, in spite of YouTube being censored there.

Telex illustrates how it is possible to shift the balance of power in the censorship arms race, by thinking big about the problem. We hope our work will inspire discussion and further research about the future of anticensorship technology.

You can find more information and prototype software at the Telex website, or read our technical paper, which will appear at Usenix Security 2011 in August.


Hacking the D.C. Internet Voting Pilot

Editor’s Note: On November 1, 2012, Alex Halderman and several other experts participated in a live streaming symposium on the state of electronic voting in Election 2012: E-Voting: Risk and Opportunity (archived video now available). The event was hosted by the Center for Information Technology Policy at Princeton.

The current U.S. e-voting system is a patchwork of locally implemented technologies and procedures — with varying degrees of reliability, usability, and security. Different groups have advocated for improved systems, better standards, and new approaches like internet-based voting. Panelists will discuss these issues and more, with a keynote by Professor Ron Rivest, one of the pioneers of modern cryptography.

[Update (6/2012): We’ve published a detailed technical paper about the D.C. hack.]

The District of Columbia is conducting a pilot project to allow overseas and military voters to download and return absentee ballots over the Internet. Before opening the system to real voters, D.C. has been holding a test period in which they’ve invited the public to evaluate the system’s security and usability.

This is exactly the kind of open, public testing that many of us in the e-voting security community — including me — have been encouraging vendors and municipalities to conduct. So I was glad to participate, even though the test was launched with only three days’ notice. I assembled a team from the University of Michigan, including my PhD students, Eric Wustrow and Scott Wolchok, and Dawn Isabel, a member of the University of Michigan technical staff.

Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters’ secret ballots. In this post, I’ll describe what we did, how we did it, and what it means for Internet voting.

D.C.’s pilot system

The D.C. system is built around an open source server-side application developed in partnership with the TrustTheVote project. Under the hood, it looks like a typical web application. It’s written using the popular Ruby on Rails framework and runs on top of the Apache web server and MySQL database.

Absentee overseas voters receive a physical letter in the mail instructing them to visit a D.C. web site,, and log in with a unique 16-character PIN. The system gives voters two options: they can download a PDF ballot and return it by mail, or they can download a PDF ballot, fill it out electronically, and then upload the completed ballot as a PDF file to the server. The server encrypts uploaded ballots and saves them in encrypted form, and, after the election, officials transfer them to a non-networked PC, where they decrypt and print them. The printed ballots are counted using the same procedures used for mail-in paper ballots.

A small vulnerability, big consequences

We found a vulnerability in the way the system processes uploaded ballots. We confirmed the problem using our own test installation of the web application, and found that we could gain the same access privileges as the server application program itself, including read and write access to the encrypted ballots and database.

The problem, which geeks classify as a “shell-injection vulnerability,” has to do with the ballot upload procedure. When a voter follows the instructions and uploads a completed ballot as a PDF file, the server saves it as a temporary file and encrypts it using a command-line tool called GnuPG. Internally, the server executes the command gpg with the name of this temporary file as a parameter: gpg […] /tmp/stream,28957,0.pdf.

We realized that although the server replaces the filename with an automatically generated name (“stream,28957,0” in this example), it keeps whatever file extension the voter provided. Instead of a file ending in “.pdf,” we could upload a file with a name that ended in almost any string we wanted, and this string would become part of the command the server executed. By formatting the string in a particular way, we could cause the server to execute commands on our behalf. For example, the filename “ballot.$(sleep 10)pdf” would cause the server to pause for ten seconds (executing the “sleep 10” command) before responding. In effect, this vulnerability allowed us to remotely log in to the server as a privileged user.

Our demonstration attacks

D.C. launched the public testbed server on Tuesday, September 28. On Wednesday afternoon, we began to exploit the problem we found to demonstrate a number of attacks:

  • We collected crucial secret data stored on the server, including the database username and password as well as the public key used to encrypt the ballots.
  • We modified all the ballots that had already been cast to contain write-in votes for candidates we selected. (Although the system encrypts voted ballots, we simply discarded the encrypted files and replaced them with different ones that we encrypted using the same key.) We also rigged the system to replace future votes in the same way.
  • We installed a back door that let us view any ballots that voters cast after our attack. This modification recorded the votes, in unencrypted form, together with the names of the voters who cast them, violating ballot secrecy.
  • To show that we had control of the server, we left a “calling card” on the system’s confirmation screen, which voters see after voting. After 15 seconds, the page plays the University of Michigan fight song. Here’s a demonstration.

Stealthiness wasn’t our main objective, and our demonstration had a much greater footprint inside the system than a real attack would need. Nevertheless, we did not immediately announce what we had done, because we wanted to give the administrators an opportunity to exercise their intrusion detection and recovery processes — an essential part of any online voting system. Our attack remained active for two business days, until Friday afternoon, when D.C. officials took down the testbed server after several testers pointed out the fight song.

Based on this experience and other results from the public tests, the D.C. Board of Elections and Ethics has announced that they will not proceed with a live deployment of electronic ballot return at this time, though they plan to continue to develop the system. Voters will still be able to download and print ballots to return by mail, which seems a lot less risky.

D.C. officials brought the testbed server back up today (Tuesday) with the electronic ballot return mechanism disabled. The public test period will continue until Friday, October 8.

What this means for Internet voting

The specific vulnerability that we exploited is simple to fix, but it will be vastly more difficult to make the system secure. We’ve found a number of other problems in the system, and everything we’ve seen suggests that the design is brittle: one small mistake can completely compromise its security. I described above how a small error in file-extension handling left the system open to exploitation. If this particular problem had not existed, I’m confident that we would have found another way to attack the system.

None of this will come as a surprise to Internet security experts, who are familiar with the many kinds of attacks that major web sites suffer from on a daily basis. It may someday be possible to build a secure method for submitting ballots over the Internet, but in the meantime, such systems should be presumed to be vulnerable based on the limitations of today’s security technology.

We plan to write more about the problems we found and their implications for Internet voting in a forthcoming paper.

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


Indian E-Voting Researcher Freed After Seven Days in Police Custody

FLASH: 4:47 a.m. EDT August 28 — Indian e-voting researcher Hari Prasad was released on bail an hour ago, after seven days in police custody. Magistrate D. H. Sharma reportedly praised Hari and made strong comments against the police, saying Hari has done service to his country. Full post later today.


Update: Indian E-Voting Researcher Remains in Police Custody

Update: 8/28 Indian E-Voting Researcher Freed After Seven Days in Police Custody

In case you’re just tuning in, e-voting researcher Hari Prasad, with whom I coauthored a paper exposing serious flaws in India’s electronic voting machines (EVMs), was arrested Saturday morning at his home in Hyderabad. The arresting officers told him they were acting under “pressure [from] the top,” and demanded that he disclose the identity of the anonymous source who provided the voting machine that we studied. Since then, Hari has been held in custody by the Mumbai police and repeatedly questioned.

Recent Developments

There have several developments in Hari’s case since my last post.

On Sunday, about 28 hours after his arrest, Hari appeared before a magistrate in Mumbai and was formally charged for the first time. The officers who arrested him had not stated a specific charge, but they had told him he would be left alone if he would reveal the identity of the source who provided us the machine . Hari has not named the source, and the authorities are now alleging that he took the machine from the government’s warehouse himself.

Specifically, he was charged under Section 454 of the Indian Penal Code (“lurking house-trespass or house-breaking in order to commit [an] offence punishable with imprisonment”), Section 457 (“lurking house trespass or house-breaking by night in order to commit an offence punishable with imprisonment”) and Section 380 (“theft in [a] dwelling house”).

These charges are without merit. Hari has never denied having been in possession of a machine—we even held it up for a photograph to accompany our paper—but the police have offered no evidence whatsoever that Hari ever trespassed in a government warehouse, much less stole a voting machine or anything else from one.

As I have previously stated, Hari obtained access to the machine from a source who approached him earlier this year. 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.

At Sunday’s hearing, Hari was remanded in police custody until today, when he appeared again before a magistrate and requested bail on medical grounds. (He is reported to be suffering from breathing problems.) The court refused to entertain the bail request and instead granted a police request that Hari remain in custody. The next hearing is scheduled for Saturday, at which time Hari can again seek bail.

One positive development is that Hari’s legal team now includes Mahesh Jethmalani and his father, Ram Jethmalani. I am told they are among the most sought after defense lawyers in India.

Keeping Sight of the Facts

Hari’s arrest has provoked explosive debate in India, not only about the arrest’s apparent political motives, but also about much broader questions our study raised over the security and transparency of India’s voting system. In the midst of this emotionally charged debate, I think it would be helpful to reiterate what our study does and does not reveal.

What the study I coauthored with Hari Prasad shows is essentially two things:

First, far from being “tamperproof,” India’s EVMs are vulnerable to most of the same security problems as the paper ballots they replaced—including an electronic form of booth capturing. Any time during or after the election, dishonest election insiders or other criminals with physical access to the machines can alter the votes stored inside.

Second, unlike the old paper ballot boxes, the EVMs can be tampered with long before elections take place to cause fraudulent results in the future. In other words, a dishonest insider or other criminal could manipulate an EVM today and have it steal votes months or years from now. You can’t do that with a ballot box.

What our study doesn’t show is that any election has ever been stolen by tampering with EVMs. Today’s EVMs are susceptible to tampering, and such tampering has the potential to change results in national elections, but our study does not even attempt to show that any past election result is invalid. Nobody can reasonably claim, based solely on the results we’ve presented, that an election now settled should be overturned.

Now that we know that EVMs have these vulnerabilities, it’s time for the Election Commission of India to stop pretending that the machines used today are perfect, and start working with India’s academic and technical communities to create a voting system that is worthy of voters’ trust.


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: (Video on YouTube)

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.


School's Laptop Spying Software Exploitable from Anywhere

This post is by , , 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:


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.


Amazon’s MP3 Store Wisely Forgoes Watermarks

Last week launched a DRM-free music store. It sells tracks from two major labels and many independents in the unprotected MP3 file format. In addition to being DRM-free, Amazon’s songs are not individually watermarked. This is an important step forward for the music industry.

Some content companies see individualized watermarks as a consumer-friendly alternative to DRM. Instead of locking down files with restrictive technology, individualized watermarking places information in them that identifies the purchasers, who could conceivably face legal action if the files were publicly shared. Apple individually watermarks DRM-free tracks sold on iTunes, but every customer who purchases a particular track from Amazon receives the exact same file. The company has stated as much, and colleagues and I confirmed this by buying a small number of files with different Amazon accounts and verifying that they were bit-for-bit identical. (As Wired reports, some files on Amazon’s store have been watermarked by the record labels, but each copy sold contains the same mark. The labels could use these marks to determine that a pirated track originated from Amazon, but they can’t trace a file to a particular user.)

Individualized watermarks give purchasers an incentive not to share the files they buy, or so the theory goes, but, like DRM, even if watermarking does reduce copyright infringement, that doesn’t necessarily mean it makes business sense. Watermarks create legal risks even for customers who don’t engage in file sharing, because the files might still become publicly available due to software misconfigurations or other security breaches. These risks add to the effective cost of buying music for legitimate purchasers, who will buy less as a result.

The difference in risk between a customer who chooses to share purchased files and one who does not is ultimately determined by computer security issues that are outside the content industry’s control. Aside from users who are caught red-handed sharing the files, who can be sued even without watermarks, infringers and noninfringers will share a multitude of plausible defenses. Their songs might have been copied by spyware. (If watermarking becomes widespread, spyware authors will probably target watermarked files, uploading them to peer to peer networks without users’ knowledge.) They might have been leaked from a discarded hard drive or backup tape, or recovered from a stolen laptop or iPod. The industry will need to fight such claims in order to bring suit against actual infringers, leaving noninfringers to worry that they could face the same fate regardless of their good intentions.

With individualized watermarking, there’s no knob that the content industry can set that varies the disincentive for sharing purchased files independently of the disincentive for purchasing them at all. Inevitably, legitimate customers will be scared away. This makes individualized watermarking a blunt antipiracy tool and a bad bet for the content industry. Amazon was wise not to use it.


AACS Updated, Broken Again

[Other posts in this series]

We predicted in past posts that AACS, the encryption system intended to protect HD-DVD and Blu-ray movies, would suffer a gradual meltdown from its inability to respond quickly enough to attacks. Like most DRM, AACS depends on the secrecy of encryption keys built into hardware and software players. An attacker who discovers a player’s keys can defeat the protection on any disc that works with that player. AACS was designed with a defense against such attacks: after a player has been compromised, producers can alter new discs so that they no longer work with the compromised player’s keys. Whether this defense (which we call “key blacklisting”) will do much to stop copying depends how much time elapses before each leaked key is blacklisted.

Next week marks three months after the first compromised player key appeared on the Internet (and more than five months after cracks for individual discs began to appear). Discs slated for release on Tuesday will be the first to contain an update to AACS that blacklists the leaked keys.

What took so long? One limitation comes from the licensing agreement signed with player manufacturers, which requires that they receive ninety days’ notice before their keys are blacklisted, so that they have enough time to update their products.

Customers who obtained the new discs a few days early confirmed that the previously leaked keys no longer worked. It seemed as if AACS had recovered from the attacks just as its designers intended.

However, a new twist came yesterday, when SlySoft, an Antigua-based company that sells software to defeat various forms of copy protection, updated its AnyDVD product to allow it to copy the new AACS discs. Apparently, SlySoft had extracted a key from a different player and had kept the attack a secret. They waited until all the other compromised keys were blacklisted before switching to the new one.

The AACS Licensing Authority will be able to figure out which player SlySoft cracked by examining the program, and they will eventually blacklist this new key as well. However, all discs on store shelves will remain copyable for months, since disc producers must wait another ninety days before making the change.

To be successful in the long run, AACS needs to outpace such attacks. Its backers might be able to accelerate the blacklisting cycle somewhat by revising their agreements with player manufacturers, but the logistics of mastering discs and shipping them to market mean the shortest practical turnaround time will be at least several weeks. Attackers don’t even have to wait this long before they start to crack another player. Like Slysoft, they can extract keys from several players and keep some of them secret until all publicly known keys are blacklisted. Then they can release the other keys one at a time to buy additional time.

All of this is yet more bad news for AACS.