Page 44 of 45
The Australian bank Suncorp has just updated its terms and conditions for Internet banking. They have a maximum withdrawal limit, hint about a physical access token, and require customers to use the most vulnerability-laden browser:
“suitable software” means Internet Explorer 5.5 Service Pack 2 or above or Netscape Navigator 6.1 or above running on Windows 98/ME/NT/2000/XP with anti-virus software or other software approved by us.
SC Magazine is reporting on a virus that infects Lexus cars:
Lexus cars may be vulnerable to viruses that infect them via mobile phones. Landcruiser 100 models LX470 and LS430 have been discovered with infected operating systems that transfer within a range of 15 feet.
It seems that no one has done this yet, and the story is based on speculation that a cell phone can transfer a virus to the Lexus using Bluetooth. But it’s only a matter of time before something like this actually works.
One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext—and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.
It’s an amateur crypto mistake. The easy way to prevent this attack is to use a unique initialization vector (IV) in addition to the key whenever you encrypt a document.
Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. Hongjun Wu has details (link is a PDF).
In this report, we point out a serious security flaw in Microsoft Word and Excel. The stream cipher RC4 [9] with key length up to 128 bits is used in Microsoft Word and Excel to protect the documents. But when an encrypted document gets modified and saved, the initialization vector remains the same and thus the same keystream generated from RC4 is applied to encrypt the different versions of that document. The consequence is disastrous since a lot of information of the document could be recovered easily.
This isn’t new. Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products.
Matt Blaze has written an excellent paper: “Safecracking for the computer scientist.”
It has completely pissed off the locksmithing community.
There is a reasonable debate to be had about secrecy versus full disclosure, but a lot of these comments are just mean. Blaze is not being dishonest. His results are not trivial. I believe that the physical security community has a lot to learn from the computer security community, and that the computer security community has a lot to learn from the physical security community. Blaze’s work in physical security has important lessons for computer security—and, as it turns out, physical security—notwithstanding these people’s attempt to trivialize it in their efforts to attack him.
This organization wants to sell their tool to view passwords in textboxes “hidden” by asterisks on Windows. They claim it’s “a glaring security hole in Microsoft Windows” and a “grave security risk.” Their webpage is thick with FUD, and warns that criminals and terrorists can easily clean out your bank accounts because of this problem.
Of course the problem isn’t that users type passwords into their computers. The problem is that programs don’t store passwords securely. The problem is that programs pass passwords around in plaintext. The problem is that users choose lousy passwords, and then store them insecurely. The problem is that financial applications are still relying on passwords for security, rather than two-factor authentication.
But the “Internet Security Foundation” is trying to make as much noise as possible. They even have this nasty letter to Bill Gates that you can sign (36 people had signed, the last time I looked). I’m not sure what their angle is, but I don’t like it.
Google’s desktop search software is so good that it exposes vulnerabilities on your computer that you didn’t know about.
Last month, Google released a beta version of its desktop search software: Google Desktop Search. Install it on your Windows machine, and it creates a searchable index of your data files, including word processing files, spreadsheets, presentations, e-mail messages, cached Web pages and chat sessions. It’s a great idea. Windows’ searching capability has always been mediocre, and Google fixes the problem nicely.
There are some security issues, though. The problem is that GDS indexes and finds documents that you may prefer not be found. For example, GDS searches your browser’s cache. This allows it to find old Web pages you’ve visited, including online banking summaries, personal messages sent from Web e-mail programs and password-protected personal Web pages.
GDS can also retrieve encrypted files. No, it doesn’t break the encryption or save a copy of the key. However, it searches the Windows cache, which can bypass some encryption programs entirely. And if you install the program on a computer with multiple users, you can search documents and Web pages for all users.
GDS isn’t doing anything wrong; it’s indexing and searching documents just as it’s supposed to. The vulnerabilities are due to the design of Internet Explorer, Opera, Firefox, PGP and other programs.
First, Web browsers should not store SSL-encrypted pages or pages with personal e-mail. If they do store them, they should at least ask the user first.
Second, an encryption program that leaves copies of decrypted files in the cache is poorly designed. Those files are there whether or not GDS searches for them.
Third, GDS’ ability to search files and Web pages of multiple users on a computer received a lot of press when it was first discovered. This is a complete nonissue. You have to be an administrator on the machine to do this, which gives you access to everyone’s files anyway.
Some people blame Google for these problems and suggest, wrongly, that Google fix them. What if Google were to bow to public pressure and modify GDS to avoid showing confidential information? The underlying problems would remain: The private Web pages would still be in the browser’s cache; the encryption program would still be leaving copies of the plain-text files in the operating system’s cache; and the administrator could still eavesdrop on anyone’s computer to which he or she has access. The only thing that would have changed is that these vulnerabilities once again would be hidden from the average computer user.
In the end, this can only harm security.
GDS is very good at searching. It’s so good that it exposes vulnerabilities on your computer that you didn’t know about. And now that you know about them, pressure your software vendors to fix them. Don’t shoot the messenger.
This article originally appeared in eWeek.
In the aftermath of the U.S.’s 2004 election, electronic voting machines are again in the news. Computerized machines lost votes, subtracted votes instead of adding them, and doubled votes. Because many of these machines have no paper audit trails, a large number of votes will never be counted. And while it is unlikely that deliberate voting-machine fraud changed the result of the presidential election, the Internet is buzzing with rumors and allegations of fraud in a number of different jurisdictions and races. It is still too early to tell if any of these problems affected any individual elections. Over the next several weeks we’ll see whether any of the information crystallizes into something significant.
The U.S has been here before. After 2000, voting machine problems made international headlines. The government appropriated money to fix the problems nationwide. Unfortunately, electronic voting machines—although presented as the solution—have largely made the problem worse. This doesn’t mean that these machines should be abandoned, but they need to be designed to increase both their accuracy, and peoples’ trust in their accuracy. This is difficult, but not impossible.
Before I can discuss electronic voting machines, I need to explain why voting is so difficult. Basically, a voting system has four required characteristics:
Through the centuries, different technologies have done their best. Stones and pot shards dropped in Greek vases gave way to paper ballots dropped in sealed boxes. Mechanical voting booths, punch cards, and then optical scan machines replaced hand-counted ballots. New computerized voting machines promise even more efficiency, and Internet voting even more convenience.
But in the rush to improve speed and scalability, accuracy has been sacrificed. And to reiterate: accuracy is not how well the ballots are counted by, for example, a punch-card reader. It’s not how the tabulating machine deals with hanging chads, pregnant chads, or anything like that. Accuracy is how well the process translates voter intent into properly counted votes.
Technologies get in the way of accuracy by adding steps. Each additional step means more potential errors, simply because no technology is perfect. Consider an optical-scan voting system. The voter fills in ovals on a piece of paper, which is fed into an optical-scan reader. The reader senses the filled-in ovals and tabulates the votes. This system has several steps: voter to ballot to ovals to optical reader to vote tabulator to centralized total.
At each step, errors can occur. If the ballot is confusing, then some voters will fill in the wrong ovals. If a voter doesn’t fill them in properly, or if the reader is malfunctioning, then the sensor won’t sense the ovals properly. Mistakes in tabulation—either in the machine or when machine totals get aggregated into larger totals—also cause errors. A manual system—tallying the ballots by hand, and then doing it again to double-check—is more accurate simply because there are fewer steps.
The error rates in modern systems can be significant. Some voting technologies have a 5% error rate: one in twenty people who vote using the system don’t have their votes counted properly. This system works anyway because most of the time errors don’t matter. If you assume that the errors are uniformly distributed—in other words, that they affect each candidate with equal probability—then they won’t affect the final outcome except in very close races. So we’re willing to sacrifice accuracy to get a voting system that will more quickly handle large and complicated elections. In close races, errors can affect the outcome, and that’s the point of a recount. A recount is an alternate system of tabulating votes: one that is slower (because it’s manual), simpler (because it just focuses on one race), and therefore more accurate.
Note that this is only true if everyone votes using the same machines. If parts of town that tend to support candidate A use a voting system with a higher error rate than the voting system used in parts of town that tend to support candidate B, then the results will be skewed against candidate A. This is an important consideration in voting accuracy, although tangential to the topic of this essay.
With this background, the issue of computerized voting machines becomes clear. Actually, “computerized voting machines” is a bad choice of words. Many of today’s voting technologies involve computers. Computers tabulate both punch-card and optical-scan machines. The current debate centers around all-computer voting systems, primarily touch-screen systems, called Direct Record Electronic (DRE) machines. (The voting system used in India’s most recent election—a computer with a series of buttons—is subject to the same issues.) In these systems the voter is presented with a list of choices on a screen, perhaps multiple screens if there are multiple elections, and he indicates his choice by touching the screen. These machines are easy to use, produce final tallies immediately after the polls close, and can handle very complicated elections. They also can display instructions in different languages and allow for the blind or otherwise handicapped to vote without assistance.
They’re also more error-prone. The very same software that makes touch-screen voting systems so friendly also makes them inaccurate. And even worse, they’re inaccurate in precisely the worst possible way.
Bugs in software are commonplace, as any computer user knows. Computer programs regularly malfunction, sometimes in surprising and subtle ways. This is true for all software, including the software in computerized voting machines. For example:
In Fairfax County, VA, in 2003, a programming error in the electronic voting machines caused them to mysteriously subtract 100 votes from one particular candidates’ totals.
In San Bernardino County, CA in 2001, a programming error caused the computer to look for votes in the wrong portion of the ballot in 33 local elections, which meant that no votes registered on those ballots for that election. A recount was done by hand.
In Volusia County, FL in 2000, an electronic voting machine gave Al Gore a final vote count of negative 16,022 votes.
The 2003 election in Boone County, IA, had the electronic vote-counting equipment showing that more than 140,000 votes had been cast in the Nov. 4 municipal elections. The county has only 50,000 residents and less than half of them were eligible to vote in this election.
There are literally hundreds of similar stories.
What’s important about these problems is not that they resulted in a less accurate tally, but that the errors were not uniformly distributed; they affected one candidate more than the other. This means that you can’t assume that errors will cancel each other out and not affect the election; you have to assume that any error will skew the results significantly.
Another issue is that software can be hacked. That is, someone can deliberately introduce an error that modifies the result in favor of his preferred candidate. This has nothing to do with whether the voting machines are hooked up to the Internet on election day. The threat is that the computer code could be modified while it is being developed and tested, either by one of the programmers or a hacker who gains access to the voting machine company’s network. It’s much easier to surreptitiously modify a software system than a hardware system, and it’s much easier to make these modifications undetectable.
A third issue is that these problems can have further-reaching effects in software. A problem with a manual machine just affects that machine. A software problem, whether accidental or intentional, can affect many thousands of machines—and skew the results of an entire election.
Some have argued in favor of touch-screen voting systems, citing the millions of dollars that are handled every day by ATMs and other computerized financial systems. That argument ignores another vital characteristic of voting systems: anonymity. Computerized financial systems get most of their security from audit. If a problem is suspected, auditors can go back through the records of the system and figure out what happened. And if the problem turns out to be real, the transaction can be unwound and fixed. Because elections are anonymous, that kind of security just isn’t possible.
None of this means that we should abandon touch-screen voting; the benefits of DRE machines are too great to throw away. But it does mean that we need to recognize its limitations, and design systems that can be accurate despite them.
Computer security experts are unanimous on what to do. (Some voting experts disagree, but I think we’re all much better off listening to the computer security experts. The problems here are with the computer, not with the fact that the computer is being used in a voting application.) And they have two recommendations:
Computerized systems with these characteristics won’t be perfect—no piece of software is—but they’ll be much better than what we have now. We need to start treating voting software like we treat any other high-reliability system. The auditing that is conducted on slot machine software in the U.S. is significantly more meticulous than what is done to voting software. The development process for mission-critical airplane software makes voting software look like a slapdash affair. If we care about the integrity of our elections, this has to change.
Proponents of DREs often point to successful elections as “proof” that the systems work. That completely misses the point. The fear is that errors in the software—either accidental or deliberately introduced—can undetectably alter the final tallies. An election without any detected problems is no more a proof the system is reliable and secure than a night that no one broke into your house is proof that your door locks work. Maybe no one tried, or maybe someone tried and succeeded…and you don’t know it.
Even if we get the technology right, we still won’t be done. If the goal of a voting system is to accurately translate voter intent into a final tally, the voting machine is only one part of the overall system. In the 2004 U.S. election, problems with voter registration, untrained poll workers, ballot design, and procedures for handling problems resulted in far more votes not being counted than problems with the technology. But if we’re going to spend money on new voting technology, it makes sense to spend it on technology that makes the problem easier instead of harder.
This article originally appeared on openDemocracy.com.
Ampersand lives in Oregon, which does its voting entirely by mail. On Monday—the day a lot of Oregon voters got their ballots—someone knocked over Ampersand’s “No on 36” sign and stole his mailbox, presumably hoping to get his ballot and prevent him from voting “no” on Amendment 36. In fact, he’d happened to receive his ballot the previous Saturday, but it could easily have worked.
From “Alas A Blog”
On Monday, someone came into our yard, knocked over our “No on 36” sign, and stole our mailbox (with Monday’s mail inside it).
I doubt this was just random vandalism; Oregon mailed out voter ballots last week (Oregon does the vote entirely by mail), and a huge number of Oregonians got their ballots on Monday. So I think someone grabbed our mailbox and ran hoping that they’d get our ballots and thus keep us from voting against measure 36.
I doubt this was part of any widespread effort. Surely anyone doing it on a large scale would get tired of hauling off mailboxes, and just steal the mail inside. It’s also hard to avoid getting caught, since you have to steal the mail during the day—after it’s delivered but before the resident comes home to get it.
Still, it is interesting how the predictably timed mailing of ballots, and the prevalence of political lawn signs, enables a very narrowly targeted attack.
If you read Lexar’s documentation, their JumpDrive Secure product is secure. “If lost or stolen, you can rest assured that what you’ve saved there remains there with 256-bit AES encryption.” Sounds good, but security professionals are an untrusting sort. @Stake decided to check. They found that “the password can be observed in memory or read directly from the device, without evidence of tampering.” Even worse: the password “is stored in an XOR encrypted form and can be read directly from the device without any authentication.”
The moral of the story: don’t trust magic security words like “256-bit AES.” The devil is in the details, and it’s easy to screw up security.
Although screwing it up this badly is impressive.
If you read Lexar’s documentation, their JumpDrive Secure product is secure. “If lost or stolen, you can rest assured that what you’ve saved there remains there with 256-bit AES encryption.” Sounds good, but security professionals are an untrusting sort. @Stake decided to check. They found that “the password can be observed in memory or read directly from the device, without evidence of tampering.” Even worse: the password “is stored in an XOR encrypted form and can be read directly from the device without any authentication.”
The moral of the story: don’t trust magic security words like “256-bit AES.” The devil is in the details, and it’s easy to screw up security.
Although screwing it up this badly is impressive.
Sidebar photo of Bruce Schneier by Joe MacInnis.