Slashdot Mirror

America's Department of Homeland Security issued a new warning this week. An anonymous reader quotes IT World: Companies that use security products to inspect HTTPS traffic might inadvertently make their users' encrypted connections less secure and expose them to man-in-the-middle attacks, the U.S. Computer Emergency Readiness Team warns. US-CERT, a division of the Department of Homeland Security, published an advisory after a recent survey showed that HTTPS inspection products don't mirror the security attributes of the original connections between clients and servers. "All systems behind a hypertext transfer protocol secure (HTTPS) interception product are potentially affected," US-CERT said in its alert.
Slashdot reader msm1267 quotes Threatpost: HTTPS inspection boxes sit between clients and servers, decrypting and inspecting encrypted traffic before re-encrypting it and forwarding it to the destination server... The client cannot verify how the inspection tool is validating certificates, or whether there is an attacker positioned between the proxy and the target server.

Trailrunner7 writes: In the days and weeks following the public disclosure of the OpenSSL Heartbleed vulnerability in April, security researchers and others wondered aloud whether there were some organizations – perhaps the NSA – that had known about the bug for some time and had been using it for targeted attacks. A definitive answer to that question may never come, but traffic data collected by researchers on several large networks shows no large-scale exploit attempts in the months leading up to the public disclosure.

"For all four networks, over these time periods our detector found no evidence of any exploit attempt up through April 7, 2014. This provides strong evidence that at least for those time periods, no attacker with prior knowledge of Heartbleed conducted widespread scanning looking for vulnerable servers. Such scanning however could have occurred during other time periods." That result also doesn't rule out the possibility that an attacker or attackers may have been doing targeted reconnaissance on specific servers or networks. The researchers also conducted similar monitoring of the four networks, and noticed that the first attempted exploits occurred within 24 hours of the OpenSSL disclosure.

An anonymous reader notes coverage of research from the University of Michigan into the ease with which attackers can hack traffic lights. From the article: As is typical in large urban areas, the traffic lights in the subject city are networked in a tree-type topology, allowing them to pass information to and receive instruction from a central management point. The network is IP-based, with all the nodes (intersections and management computers) on a single subnet. In order to save on installation costs and increase flexibility, the traffic light system uses wireless radios rather than dedicated physical networking links for its communication infrastructure—and that’s the hole the research team exploited. ... The 5.8GHz network has no password and uses no encryption; with a proper radio in hand, joining is trivial. ... The research team quickly discovered that the debug port was open on the live controllers and could directly "read and write arbitrary memory locations, kill tasks, and even reboot the device (PDF)." Debug access to the system also let the researchers look at how the controller communicates to its attached devices—the traffic lights and intersection cameras. They quickly discovered that the control system’s communication was totally non-obfuscated and easy to understand—and easy to subvert.

A few countries, like Estonia, have gone for internet-based voting in national elections in a big way, and many others (like Ireland and Canada) have experimented with it. For Americans, with a presidential election approaching later this year, it's a timely issue: already, some states have come to allow at least certain forms of voting by internet. Proponents say online elections have compelling upsides, chief among them ease of participation. People who might not otherwise vote — in particular military personnel stationed abroad, but many others besides — are more and more reached by internet access. Online voting offers a way to keep the electoral process open to them. With online voting, too, there's no worry about conventional absentee ballots being lost or delayed in the postal system, either before reaching the voter or on the way back to be counted. The downsides, though, are daunting. According to RSA panelists David Jefferson and J. Alex Halderman, in fact, they're overwhelming. Speaking Thursday afternoon, the two laid out their case against e-voting.

(Read more for more, and look for a video interview with Halderman soon).

Jefferson and Halderman have impressive credentials as analysts and critics of internet voting. Jefferson, a computer scientist at Lawrence Livermore National Laboratory, is chairman of the board of the Verified Voting Foundation, an NGO focused on promoting election integrity, and coauthor of a report that spurred the Department of Defense to withdraw for further consideration its then-plan for online voting, called SERVE, in 2004. Halderman takes a different, hands-on approach, demonstrating (along with his grad students at the University of Michigan) just how polling-station election machines and online voting system can be compromised. "I've probably hacked into and otherwise found vulnerabilities in more polling places than anyone else," he says.

Jefferson and Halderman are careful to define the key element of elections they're trying to expose as unfixably broken: namely, the delivery of completed ballots over the internet, whether that means a web app, email or some other conduit, without a voter-verified paper audit trail. Some kinds of election technology can move from the voting booth to the online world with less risk to the integrity of the election itself — for instance, distribution of blank ballots, or even online voter registration. "This isn't about keeping score of primaries, or gathering information about candidates, but actually voting," said Jefferson. The risk of hacked elections isn't just the possibility of political rivals trying to out-do each other, he said; ultimately, vulnerable election systems compromise national security and ballot secrecy. Even a few hundred votes may suffice to swing a House or Senate race, and that can have cascading consequences for control of elected bodies themselves. "Wherever there's a concentration of votes sufficient to swing a major election, there's a national security concern."

Why assume that election systems can be manipulated? And since paper ballots are not immune to questionable or downright fraudulent counts, why call out the electronic version in particular? In part, he says, because the structure of an electronic voting system is inherently complex, and because it's difficult if not impossible to roll back results if a compromise is suspected. Unlike paper ballots (and in the absence of a paper audit trail backing an electronic voting system), online vote gathering offers no good way to re-count. Jefferson laid out four major and overlapping areas of likely attacks on internet voting systems, any one of which could taint the results of an election.

First, individual voting jurisdictions are vulnerable to attack. (In the U.S., for federal elections, that essentially means counties, totaling more than 7000.) Even in local races, there can be billions of dollars at stake in high-population counties like Cook County or L.A. County. Vendors, both their networks and their source code, are also at risk. Assuming that even best efforts can keep the source code behind the handful of election-system vendors safe is a sucker's bet, Jefferson says. Even large companies with enormous security resources have been hacked, with source code a prime target, as happened to Google and 25 other firms in 2010 in a breach attributed to Chinese operatives. "Who knows if those [online voting software] vendors have already been penetrated? You wouldn't have any idea," said Jefferson.

Even if both local voting authorities and e-voting software vendors were themselves able to deflect all attacks, voters using an online voting system on their home or office PCs would still be at the mercy of the weakest link of the chain — the security of the machines available to them. Targeted malware could be used to present a different set of on-screen options to a voter than it actually sends back to the election counters. Because one of the protections of a secret ballot is to make available to voters proof that they voted but not how they voted, individuals who intended to selected candidate A would have no reason to know their vote was cast for candidate B instead. Malware could also simply vote without user interaction. It may not be election related, but a large fraction of PCs are already infected with some kind of malware, showing how big a problem this could be.

Finally, pure network attacks (or even errors) could disrupt the integrity of an election; exactly that kind of attack brought much of Estonia's online traffic to a halt in May 2007; lucky for Estonians that was not during an election, because Estonia is one of the few countries that has fully adopted online voting. Perhaps more chilling is the brief re-routing in April 2010 of 15 percent of the world's internet traffic through China.

Insecurity on the internet is itself a long-standing problem, so why the fuss? Unlike financial crime, such as credit card fraud, election fraud is hard to detect, and even harder to correct for, in large part because ballot secrecy is key to fair elections.

Voting is different. "Superficially, you'd think the transactions are very similar [to financial transactions], but underneath, all the issues are completely different. The privacy requirements are completely different, for example," says Jefferson. To prevent coerced voting, or simple vote selling, "You're allowed to tell anyone how you voted all you want, but you're not allowed to have proof of how you voted." Rolling back results to investigate suspected breaches is impossible, Jefferson says, without exposing the actual votes of individuals, at the very least to election officials.

Investigating financial crime online is the opposite; there, figuring out exactly who did what and when is the whole point, and the evidence is easy to find: if banking credentials are stolen, he said, "some account will go to zero." But in the case of elections, it's more likely that "the wrong people take office, and life goes on, and it's just never discovered."

And while no election fraud has yet been attributed to it, the trend is growing to institute the version of online voting that Jefferson calls "the worst idea ever" — voting by email. 33 states have modded their voting systems to accept in some cases PDFs of scanned ballots through ordinary e-mail to be entered by election workers. The numbers may be small (typically, this form of voting is limited to overseas voters, and in some cases voters are asked to acknowledge that their vote cannot be kept secret), but this allowance means that "e-mail voting is very widespread in the United States."

While Jefferson works through Verified Voting to influence policy makers to lay out the case against online voting, J. Alex Halderman, in his role as an assistant professor at the University of Michigan, turns theory into reality: he and his students break election systems (devices as well as software) in the U.S. and abroad to show just how easily a malicious attacker could do the same. He offered as an example of several of the ways electronic voting can fail his successful attack on an internet voting plan (see this earlier Slashdot story) that was to have been implemented in 2010 in the District of Columbia. The District had, with Federal grant money, designed an online voting system and already put it nearly into production, and had mailed PINs and voter ID numbers to voters in anticipation.

To D.C.'s credit, Halderman says, the election officials at least asked first for advice from security experts around the country, and invited them to test it in advance of using the system in an actual election, though mere days before the system was to have gone live. "It's not every day you're invited to hack into government computers without the threat of jail hanging over your head," says Halderman, who was attracted to the challenge of investigating the system itself, as well as curiosity about how the D.C. officials would respond to a system compromise.

Though Halderman says the Ruby on Rails-based system was written in "generally clean code," his team discovered a shell injection vulnerability which gave them access to the D.C. system (see his full paper as a PDF for the details), and immediately set about playing.

Web apps tend to be brittle, says Halderman, and D.C.'s was no exception. "App frameworks are written in ways that allow small mistakes to have big consequences," especially when vulnerabilities are often widely disseminated soon after discovery, and not always by white hat hackers like him.

"The first thing we did was steal all the important stuff," he says — credentials, keys, and more. Simply snooping on the data wasn't enough to fully demonstrate the problems in the system, though; the team replaced the information on all of the ballots as well, replacing the actual candidates with ones of their choice, offering up options like Hall 9000, and Bender for school board, and forced client machines to play the University of Michigan's fight song, before erasing the logs that would have allowed their intrusion to be properly analyzed by the system's administrators.

Their attack also led them to gain full access to a terminal server on the same network, and after they'd hacked into this ("using the default password from the owner's manual," Halderman notes) they noticed there was evidence in the logs of other attacks. In particular, some of the attacks appearing to originate in Iran and in China. While Halderman doubts these represent an attack specifically on the DC system voting system, the evidence of such attacks is "an illustration of how vulnerable things are."

Halderman acknowledges that voting in person, especially by electronic means, is far from foolproof, but he joins Jefferson in saying that online voting is categorically worse, and suggests that everyone who takes an interest in security or the mechanics of democratic elections raise the issues of privacy and security. His conclusion and advice for election officials in the U.S.: Voting online is a bad idea, and it simply can't be fixed in the foreseeable future. All the security problems of e-voting machines at polling stations apply directly to internet voting, too, which means that anyone on Earth can attack an online election.

"If my vote is insecure, everyone else who lives under that same government is harmed by that."

mr crypto writes with this quote from El Reg: "In 2010 the Washington DC election board announced it had set up an e-voting system for absentee ballots and was planning to use it in an election. However, to test the system, it invited the security community and members of the public to try and hack it three weeks before the election. 'It was too good an opportunity to pass up,' explained Professor Alex Halderman from the University of Michigan. 'How often do you get the chance to hack a government network without the possibility of going to jail?' With the help of two graduate students, Halderman started to examine the software. Despite it being a relatively clean Ruby on Rails build, they spotted a shell injection vulnerability within a few hours. They figured out a way of writing output to the images directory (PDF) on the compromised server, and of encrypting traffic so that the front-end intrusion detection system couldn't spot them. The team also managed to guess the login details for the terminal server used by the voting system. ... The team altered all the ballots on the system to vote for none of the nominated candidates. They then wrote in names of fictional IT systems as candidates, including Skynet and (Halderman's personal favorite) Bender for head of the DC school board."

Slashdot regular contributor Bennett Haselton wrote in this week to say that "The proposed "Telex" anti-censorship system could technically work, but unless I'm missing something, it would more cost-effective to spend the same resources on fighting censorship using existing technologies." His essay on the subject follows.

Professor Alex Halderman published a paper in July describing a new anti-censorship system called Telex, whereby users in censored countries could request banned websites by sending an encrypted request to an SSL-enabled website (i.e., a Web address beginning with https://) outside of their country -- even if the owner of the SSL-enabled website is not participating in the scheme. Since encrypted communications usually contain some random variation, that random variation can be used to embed hidden messages, which can then be decoded by any third-party observer who intercepts the communication and knows how to decode the hidden message. The third-party observer still cannot decode the original encrypted communication between the end user and the SSL-enabled website -- SSL is designed to be unbreakable by all but the intended recipient -- but the observer can decode the "side message" that was designed to be intercepted in transit. So a Telex-enabled router, in the process of passing the communication along, would notice the hidden request for a banned website, and pass the requested content back to the original user.

By analogy, suppose Mrs. Smith wants to send a letter to a friend. Mrs. Smith knows the letter will be sealed, and supposedly unopenable by the postman. But Mrs. Smith also has many choices of colored envelopes to use, and she has agreed with the postman on a color-coded system -- red for "Meet me tonight at the Motel 6", blue for "Not tonight, he suspects something" -- that the postman can "decode" when he picks up the envelope for delivery. The choice of envelope color is the "random variation" inherent in the sending of the message, which the message sender can use to send a "side message" to anyone who passes it along and who knows the system. The postman -- who is analogous to the Telex-enabled router -- has no access to the original sealed message inside the envelope, but he understands the side message just fine. (A Telex user may have no control over what routers their messages pass through, though, so they simply have to hope that there are enough Telex-enabled routers on the Internet that one of them will pick up the message and decode it. Imagine many different amorous mail carriers in the Postal Service, and any one of them who finds the colored envelope will be happy to show up at the appointed time, if Mrs. Smith is not picky.)

The novel feature of Telex is that it would not require the cooperation of the owner of the SSL-enabled website in order to work. You could send an encrypted communication to any website -- https://www.paypal.com/ for example -- and any Telex-enabled routers along the pathway traveled by the connection, would be able to decode the embedded message hidden in the randomness of the encryption. By contrast, for a user to make use of a typical proxy website like Vtunnel, the owner of the Vtunnel website has to set up the site as a proxy; this means the supply of such sites is limited to those websites whose owners have installed proxy software, and the censors have a greater chance of finding and blocking them all. Telex, on the other hand, would continue to work as long as the user in the censored country was able to access any SSL-enabled website, as long as their request happened to pass through a Telex-enabled router.

So far, so good. But this would presumably require an investment of at least several million dollars by any major backbone provider who wanted to try it, by re-configuring their major routers to speak the Telex protocol, and then potentially hundreds of millions of dollars for a sustained long-term effort. (As Halderman says, "We like to envision this technology as a possible government-level response to government-level censorship.") So here's my question: If any backbone provider (or government entity) wanted to go to that trouble to support the cause of fighting Internet censorship, why wouldn't it be much more straightforward for them to just set up proxy websites themselves?

Professor Halderman didn't respond to my inquiry on that point. The Telex FAQ notes that censorious governments can easily block new proxy sites once they find out about them. But in many censored countries, most proxy sites are not blocked, either because the government isn't trying, or they can't keep up. In China, hardly any proxy sites are blocked at all, as the government seems to put more of their resources into suppressing local dissent directly. Meanwhile in Iran, the censors do put more resources into actually blocking proxy sites -- but because Iran is on the U.S. State Department's embargo list, Iranian censors can't buy Internet censoring software from U.S. companies, so they have to find and block the sites themselves. As a result, newly released proxy sites often stay unblocked longer in Iran than they do in other Middle Eastern countries that use U.S.-made blocking software. Meanwhile, Saudi Arabia, for whatever reason, doesn't seem to block proxy sites at all for the time being. (Saudi Arabia is a strange outlier, since most conservative Islamic countries that filter the Web, also block proxy sites as well. It's not clear why Saudi Arabia doesn't.) So if a government or a philanthropist wants to help the cause of fighting censorship, just set up some proxy sites and pay to keep them running -- and you'll be helping the residents of all of those countries right away, for starters. This is in fact what Voice of America (through their various proxy programs) and the founders of UltraSurf (a privately funded network of anti-censorship servers) have been doing all along.

Even in the case of countries like U.A.E. and Yemen that are reasonably quick at finding and blocking proxy sites (as a result of using Western-made blocking software), the most cost-effective way to help these users is probably to set up more proxy sites, hosted at different locations and with perhaps with legitimate-looking "decoy" content, so that U.S. censorware companies can't keep up. My experience has been that the more money you spend (using unique IP addresses, buying .com domains instead of cheap .info ones, and setting up lots of proxies so that each one is sent to only a subset of your target audience), the longer the proxy sites last. You can also use proxy-like services (such as Tor, Hotspot Shield and UltraSurf) to route traffic through dedicated servers, to circumvent censorship in a way that is more transparent and convenient to the end user.

In short, existing proxy sites (and proxy-like services) do the job pretty well for many censored countries, and a massive cash expenditure on setting up more proxies (equivalent to the cost of setting up the Telex system) would probably be enough to demolish all other national filtering schemes completely. The software and tools to run proxy sites have already been tried and tested; all it takes to run them is money. Telex, by contrast, would require backbone providers to alter the architecture of their systems -- which means large-scale testing, isolation of any problems that arise, and countless other potential headaches. And that's not even counting the fact that censorious countries might detect which backbone providers are using Telex, and block all traffic from their countries to any sites hosted on those networks.

So I think Telex is a brilliant technical achievement, and I'd be happy if it got deployed, but I'd be scratching my head as to why the backbone providers (or the government, or whoever sponsored the effort) decided to kill a gnat with a flamethrower. I deal in flyswatters for a living, and they get the job done.