Page 32 of 45
This article claims the software that runs the back end of either 35% or 80%-95% (depending on which part of the article you read) has been compromised, and that the adult industry is hushing this up. Like many of these sorts of stories, there’s no evidence that the bad guys have the personal information database. The vulnerability only means that they could have it.
Does anyone know about this?
Slashdot thread.
Ohio just completed a major study of voting machines. (Here’s the report, a gigantic pdf.) And, like the California study earlier this year, they found all sorts of problems:
While some tests to compromise voting systems took higher levels of sophistication, fairly simple techniques were often successfully deployed.
“To put it in every-day terms, the tools needed to compromise an accurate vote count could be as simple as tampering with the paper audit trail connector or using a magnet and a personal digital assistant,” Brunner said.
The New York Times writes:
“It was worse than I anticipated,” the official, Secretary of State Jennifer Brunner, said of the report. “I had hoped that perhaps one system would test superior to the others.”
At polling stations, teams working on the study were able to pick locks to access memory cards and use hand-held devices to plug false vote counts into machines. At boards of election, they were able to introduce malignant software into servers.
Note the lame defense from one voting machine manufacturer:
Chris Riggall, a Premier spokesman, said hardware and software problems had been corrected in his company’s new products, which will be available for installation in 2008.
“It is important to note,” he said, “that there has not been a single documented case of a successful attack against an electronic voting system, in Ohio or anywhere in the United States.”
I guess he didn’t read the part of the report that talked about how these attacks would be undetectable. Like this one:
They found that the ES&S tabulation system and the voting machine firmware were rife with basic buffer overflow vulnerabilities that would allow an attacker to easily take control of the systems and “exercise complete control over the results reported by the entire county election system.”
They also found serious security vulnerabilities involving the magnetically switched bidirectional infrared (IrDA) port on the front of the machines and the memory devices that are used to communicate with the machine through the port. With nothing more than a magnet and an infrared-enabled Palm Pilot or cell phone they could easily read and alter a memory device that is used to perform important functions on the ES&S iVotronic touch-screen machine—such as loading the ballot definition file and programming the machine to allow a voter to cast a ballot. They could also use a Palm Pilot to emulate the memory device and hack a voting machine through the infrared port (see the picture above right).
They found that a voter or poll worker with a Palm Pilot and no more than a minute’s access to a voting machine could surreptitiously re-calibrate the touch-screen so that it would prevent voters from voting for specific candidates or cause the machine to secretly record a voter’s vote for a different candidate than the one the voter chose. Access to the screen calibration function requires no password, and the attacker’s actions, the researchers say, would be indistinguishable from the normal behavior of a voter in front of a machine or of a pollworker starting up a machine in the morning.
Elsewhere in the country, Colorado has decertified most of its electronic voting machines:
The decertification decision, which cited problems with accuracy and security, affects electronic voting machines in Denver and five other counties. A number of electronic scanners used to count ballots were also decertified.
Coffman would not comment Monday on what his findings mean for past elections, despite his conclusion that some equipment had accuracy issues.
“I can only report,” he said. “The voters in those respective counties are going to have to interpret” the results.
Coffman announced in March that he had adopted new rules for testing electronic voting machines. He required the four systems used in Colorado to apply for recertification.
The systems are manufactured by Premier Election Solutions, formerly known as Diebold Election Systems; Hart InterCivic; Sequoia Voting Systems; and Election Systems and Software. Only Premier had all its equipment pass the recertification.
California is about to give up on electronic voting machines, too. This probably didn’t help:
More than a hundred computer chips containing voting machine software were lost or stolen during transit in California this week.
Microsoft has added the random-number generator Dual_EC-DRBG to Windows Vista, as part of SP1. Yes, this is the same RNG that could have an NSA backdoor.
It’s not enabled by default, and my advice is to never enable it. Ever.
EDITED TO ADD (12/18): I should make this clear that the algorithm is available as a program call. It is not something that the user can enable or disable.
For a while now, Heathrow Airport has had a unique setup for scanning shoes. Instead of taking your shoes off during the normal screening process, as you do in U.S. airports, you go through the metal detector with your shoes on. Then, later, there is a special shoe scanning X-ray machine. You take your shoes off, send them through the machine, and put them on at the other end.
It’s definitely faster, but it’s an easy system to defeat. The vulnerability is that no one verifies that the shoes you walked through the metal detector with are the same shoes you put on the scanning machine.
Here’s how the attack works. Assume that you have two pairs of shoes: a clean pair that passes all levels of screening, and a dangerous pair that doesn’t. (Ignore for a moment the ridiculousness of screening shoes in the first place, and assume that an X-ray machine can detect the dangerous pair.) Put the dangerous shoes on your feet and the clean shoes in your carry-on bag. Walk through the metal detector. Then, at the shoe X-ray machine, take the dangerous shoes off and put them in your bag, and take the clean shoes out of your bag and place them on the X-ray machine. You’ve now managed to get through security without having your shoes screened.
This works because the two security systems are decoupled. And the shoe screening machine is so crowded and chaotic, and so poorly manned, that no one notices the switch.
U.S. airports force people to put their shoes through the X-ray machine and walk through the metal detector shoeless, ensuring that all shoes get screened. That might be slower, but it works.
EDITED TO ADD (12/14): Heathrow Terminal 3, that is. The system wasn’t in place in Terminal 4, and I don’t know about Terminals 1 and 2.
Every year SANS publishes a list of the 20 most important vulnerabilities. It’s always a great list, and this year is no different:
The threat landscape is very dynamic, which in turn makes it necessary to adopt newer security measures. Just over the last year, the kinds of vulnerabilities that are being exploited are very different from the ones being exploited in the past. Here are some observations:
- Operating systems have fewer vulnerabilities that can lead to massive Internet worms. For instance, during 2002-2005, Microsoft Windows worms like Blaster, Nachi, Sasser and Zotob infected a large number of systems on the Internet. There have not been any new large-scale worms targeting Windows services since 2005. On the other hand, vulnerabilities found anti-virus, backup or other application software, can result in worms. Most notable was the worm exploiting the Symantec anti-virus buffer overflow flaw last year.
- We have seen significant growth in the number of client-side vulnerabilities, including vulnerabilities in browsers, in office software, in media players and in other desktop applications. These vulnerabilities are being discovered on multiple operating systems and are being massively exploited in the wild, often to drive recruitment for botnets.
- Users who are allowed by their employers to browse the Internet have become a source of major security risk for their organizations. A few years back securing servers and services was seen as the primary task for securing an organization. Today it is equally important, perhaps even more important, to prevent users having their computers compromised via malicious web pages or other client-targeting attacks.
- Web application vulnerabilities in open-source as well as custom-built applications account for almost half the total number of vulnerabilities being discovered in the past year. These vulnerabilities are being exploited widely to convert trusted web sites into malicious servers serving client-side exploits and phishing scams.
- The default configurations for many operating systems and services continue to be weak and continue to include default passwords. As a result, many systems have been compromised via dictionary and brute-force password guessing attacks in 2007!
- Attackers are finding more creative ways to obtain sensitive data from organizations. Therefore, it is now critical to check the nature of any data leaving an organization’s boundary.
Much, much more information at the link.
Dan Bernstein wrote an interesting paper on the security lessons he’s learned from qmail.
My views of security have become increasingly ruthless over the years. I see a huge amount of money and effort being invested in security, and I have become convinced that most of that money and effort is being wasted. Most “security” efforts are designed to stop yesterday’s attacks but fail completely to stop tomorrow’s attacks and are of no use in building invulnerable software. These efforts are a distraction from work that does have long-term value.
Very interesting stuff, some counter to conventional security wisdom.
I have become convinced that this “principle of least privilege” is fundamentally wrong. Minimizing privilege might reduce the damage done by some security holes but almost never fixes the holes. Minimizing privilege is not the same as minimizing the amount of trusted code, does not have the same benefits as minimizing the amount of trusted code, and does not move us any closer to a secure computer system.
Random numbers are critical for cryptography: for encryption keys, random authentication challenges, initialization vectors, nonces, key-agreement schemes, generating prime numbers and so on. Break the random-number generator, and most of the time you break the entire security system. Which is why you should worry about a new random-number standard that includes an algorithm that is slow, badly designed and just might contain a backdoor for the National Security Agency.
Generating random numbers isn’t easy, and researchers have discovered lots of problems and attacks over the years. A recent paper found a flaw in the Windows 2000 random-number generator. Another paper found flaws in the Linux random-number generator. Back in 1996, an early version of SSL was broken because of flaws in its random-number generator. With John Kelsey and Niels Ferguson in 1999, I co-authored Yarrow, a random-number generator based on our own cryptanalysis work. I improved this design four years later—and renamed it Fortuna—in the book Practical Cryptography, which I co-authored with Ferguson.
The U.S. government released a new official standard for random-number generators this year, and it will likely be followed by software and hardware developers around the world. Called NIST Special Publication 800-90 (.pdf), the 130-page document contains four different approved techniques, called DRBGs, or “Deterministic Random Bit Generators.” All four are based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves. It’s smart cryptographic design to use only a few well-trusted cryptographic primitives, so building a random-number generator out of existing parts is a good thing.
But one of those generators—the one based on elliptic curves—is not like the others. Called Dual_EC_DRBG, not only is it a mouthful to say, it’s also three orders of magnitude slower than its peers. It’s in the standard only because it’s been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute.
The NSA has always been intimately involved in U.S. cryptography standards—it is, after all, expert in making and breaking secret codes. So the agency’s participation in the NIST (the U.S. Commerce Department’s National Institute of Standards and Technology) standard is not sinister in itself. It’s only when you look under the hood at the NSA’s contribution that questions arise.
Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn’t large enough to make the algorithm unusable—and Appendix E of the NIST standard describes an optional work-around to avoid the issue—but it’s cause for concern. Cryptographers are a conservative bunch: We don’t like to use algorithms that have even a whiff of a problem.
But today there’s an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor.
This is how it works: There are a bunch of constants—fixed numbers—in the standard used to define the algorithm’s elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from.
What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG.
The researchers don’t know what the secret numbers are. But because of the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem.
Of course, we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG. We have no way of knowing whether an NSA employee working on his own came up with the constants—and has the secret numbers. We don’t know if someone from NIST, or someone in the ANSI working group, has them. Maybe nobody does.
We don’t know where the constants came from in the first place. We only know that whoever came up with them could have the key to this backdoor. And we know there’s no way for NIST—or anyone else—to prove otherwise.
This is scary stuff indeed.
Even if no one knows the secret numbers, the fact that the backdoor is present makes Dual_EC_DRBG very fragile. If someone were to solve just one instance of the algorithm’s elliptic-curve problem, he would effectively have the keys to the kingdom. He could then use it for whatever nefarious purpose he wanted. Or he could publish his result, and render every implementation of the random-number generator completely insecure.
It’s possible to implement Dual_EC_DRBG in such a way as to protect it against this backdoor, by generating new constants with another secure random-number generator and then publishing the seed. This method is even in the NIST document, in Appendix A. But the procedure is optional, and my guess is that most implementations of the Dual_EC_DRBG won’t bother.
If this story leaves you confused, join the club. I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.
In the meantime, both NIST and the NSA have some explaining to do.
This essay originally appeared on Wired.com.
This is so silly I wasn’t going to even bother blogging about it. But the sheer number of news stories has made me change my mind.
Basically, the Swiss company ID Quantique convinced the Swiss government to use quantum cryptography to protect vote transmissions during their October 21 election. It was a great publicity stunt, and the news articles were filled with hyperbole: how the “unbreakable” encryption will ensure the integrity of the election, how this will protect the election against hacking, and so on.
Complete idiocy. There are many serious security threats to voting systems, especially paperless touch-screen voting systems, but they’re not centered around the transmission of votes from the voting site to the central tabulating office. The software in the voting machines themselves is a much bigger threat, one that quantum cryptography doesn’t solve in the least.
Moving data from point A to point B securely is one of the easiest security problems we have. Conventional encryption works great. PGP, SSL, SSH could all be used to solve this problem, as could pretty much any good VPN software package; there’s no need to use quantum crypto for this at all. Software security, OS security, network security, and user security are much harder security problems; and quantum crypto doesn’t even begin to address them.
So, congratulations to ID Quantique for a nice publicity stunt. But did they actually increase the security of the Swiss election? Doubtful.
If I could only install one “offensive” extension, it would absolutely be Tamper Data. In the past, I used Paros Proxy and Burp Suite for intercepting requests and responses between my Web browser and the Web server. These tasks can now be done within Firefox via Tamper Data—without configuring the proxy settings.
If the Website you’re trying to break into requires a unique cookie, referrer, or user-agent, intercept the request with Tamper Data before it gets sent to the Web server. Then, add or modify the attributes you need and send it on. It’s even possible to modify the response from the Web server before the Web browser interprets it. It’s a very nice tool for anyone interested in Web application security.
Paros and Burp both have features not yet available in Tamper Data, such as site spidering and vulnerability scanning. Switching over to one of them as a proxy is much easier with SwitchProxy, which helps you quickly configure Firefox to use Paros and Proxy. It’s not a purely “offensive” extension, but SwitchProxy it makes the configuration of proxies for Firefox much quicker.
Okay, this xkcd cartoon is really funny.
Sidebar photo of Bruce Schneier by Joe MacInnis.