Courtesy Klint Finley, Wired.co.uk
When NSA whistle-blower Edward Snowden first emailed Glenn Greenwald, he insisted on using email encryption software called PGP for all communications. But this month, we learned that Snowden used another technology to keep his communications out of the NSA’s prying eyes. It’s called Tails. And naturally, nobody knows exactly who created it.
Tails is a kind of computer-in-a-box. You install it on a DVD or USB drive, boot up the computer from the drive and, voila, you’re pretty close to anonymous on the internet. At its heart, Tails is a version of the Linux operating system optimized for anonymity. It comes with several privacy and encryption tools, most notably Tor, an application that anonymizes a user’s internet traffic by routing it through a network of computers run by volunteers around the world.
Snowden, Greenwald and their collaborator, documentary film maker Laura Poitras, used it because, by design, Tails doesn’t store any data locally. This makes it virtually immune to malicious software, and prevents someone from performing effective forensics on the computer after the fact. That protects both the journalists, and often more importantly, their sources.
"The installation and verification has a learning curve to make sure it is installed correctly," Poitras told Wired by e-mail. "But once the set up is done, I think it is very easy to use."
An operating system for anonymity
Originally developed as a research project by the U.S. Naval Research Laboratory, Tor has been used by a wide range of people who care about online anonymity: everyone from Silk Road drug dealers, to activists, whistleblowers, stalking victims and people who simply like their online privacy.
Tails makes it much easier to use Tor and other privacy tools. Once you boot into Tails — which requires no special setup — Tor runs automatically. When you’re done using it, you can boot back into your PC’s normal operating system, and no history from your Tails session will remain.
The developers of Tails are, appropriately, anonymous. All of Wired’s questions were collectively –and anonymously — answered by the group’s members via email.
They’re protecting their identities, in part, to help protect the code from government interference. "The NSA has been pressuring free software projects and developers in various ways," the group says, referring to a conference last year at which Linux creator Linus Torvalds implied that the NSA had asked him place a backdoor in the operating system.
But the Tails team is also trying to strike a blow against the widespread erosion of online privacy. "The masters of today’s Internet, namely the marketing giants like Google, Facebook, and Yahoo, and the spying agencies, really want our lives to be more and more transparent online, and this is only for their own benefit," the group says. "So trying to counterbalance this tendency seems like a logical position for people developing an operating system that defends privacy and anonymity online."
But since we don’t know who wrote Tails, how do we now it isn’t some government plot designed to snare activists or criminals? A couple of ways, actually. One of the Snowden leaks show the NSA complaining about Tails in a Power Point Slide; if it’s bad for the NSA, it’s safe to say it’s good for privacy. And all of the Tails code is open source, so it can be inspected by anyone worried about foul play. "Some of us simply believe that our work, what we do, and how we do it, should be enough to trust Tails, without the need of us using our legal names," the group says.
According to the group, Tails began five years ago. "At that time some of us were already Tor enthusiasts and had been involved in free software communities for years," they says. "But we felt that something was missing to the panorama: a toolbox that would bring all the essential privacy enhancing technologies together and made them ready to use and accessible to a larger public."
The developers initially called their project Amnesia and based it on an existing operating system called Incognito. Soon the Amnesia and Incognito projects merged into Tails, which stands for The Amnesic Incognito Live System.
And while the core Tails group focuses on developing the operating system for laptops and desktop computers, a separate group is making a mobile version that can run on Android and Ubuntu tablets, provided the user has root access to the device.
Know your limitations
In addition to Tor, Tails includes privacy tools like PGP, the password management system KeePassX, and the chat encryption plugin Off-the-Record. But Tails doesn’t just bundle a bunch of off the shelf tools into a single package. Many of the applications have been modified to improve the privacy of its users.
But no operating system or privacy tool can guarantee complete protection in all situations.
Although Tails includes productivity applications like OpenOffice, GIMP and Audacity, it doesn’t make a great everyday operating system. That’s because over the course of day-to-day use, you’re likely to use one service or another that could be linked with your identity, blowing your cover entirely. Instead, Tails should only be used for the specific activities that need to be kept anonymous, and nothing else.
The developers list several other security warnings in the site documentation.
Of course the group is constantly working to fix security issues, and they’re always looking for volunteers to help with the project. They’ve also applied for a grant from the Knight Foundation, and are collecting donations via the Freedom of the Press Foundation, the group that first disclosed Tails’ role in the Snowden story.
That money could go a long way toward helping journalists — and others — stay away from the snoops. Reporters, after all, aren’t always the most tech-savvy people. As Washington Post reporter Barton Gellman told the Freedom of the Press Foundation, "Tails puts the essential tools in one place, with a design that makes it hard to screw them up. I could not have talked to Edward Snowden without this kind of protection. I wish I’d had it years ago."
Courtesy Ars Technica
A little more than a year ago, details emerged about an effort by some members of the hacktivist group Anonymous to build a new weapon to replace their aging denial-of-service arsenal. The new weapon would use the Internet’s Domain Name Service as a force-multiplier to bring the servers of those who offended the group to their metaphorical knees. Around the same time, an alleged plan for an Anonymous operation, "Operation Global Blackout" (later dismissed by some security experts and Anonymous members as a "massive troll"), sought to use the DNS service against the very core of the Internet itself in protest against the Stop Online Piracy Act.
This week, an attack using the technique proposed for use in that attack tool and operation—both of which failed to materialize—was at the heart of an ongoing denial-of-service assault on Spamhaus, the anti-spam clearing house organization. And while it hasn’t brought the Internet itself down, it has caused major slowdowns in the Internet’s core networks.
DNS Amplification (or DNS Reflection) remains possible after years of security expert warnings. Its power is a testament to how hard it is to get organizations to make simple changes that would prevent even recognized threats. Some network providers have made tweaks that prevent botnets or "volunteer" systems within their networks to stage such attacks. But thanks to public cloud services, "bulletproof" hosting services, and other services that allow attackers to spawn and then reap hundreds of attacking systems, DNS amplification attacks can still be launched at the whim of a deep-pocketed attacker—like, for example, the cyber-criminals running the spam networks that Spamhaus tries to shut down.
The Domain Name Service is the Internet’s directory assistance line. It allows computers to get the numerical Internet Protocol (IP) address for a remote server or other network-attached device based on its human-readable host and domain name. DNS is organized in a hierarchy; each top-level domain name (such as .com, .edu, .gov, .net, and so on) has a "root" DNS server keeping a list of each of the "authoritative" DNS servers for each domain registered with them. If you’ve ever bought a domain through a domain registrar, you’ve created (either directly or indirectly) an authoritative DNS address for that domain by selecting the primary and secondary DNS servers that go with it.
When you type "arstechnica.com" into your browser’s address bar and hit the return key, your browser checks with a DNS resolver—your personal Internet 411 service— to determine where to send the Web request. For some requests, the resolver may be on your PC. (For example, this happens if you’ve requested a host name that’s in a local "hosts" table for servers within your network, or one that’s stored in your computer’s local cache of DNS addresses you’ve already looked up.) But if it’s the first time you’ve tried to connect to a computer by its host and domain name, the resolver for the request is probably running on the DNS server configured for your network—within your corporate network, at an Internet provider, or through a public DNS service such as Google’s Public DNS.
There are two ways for a resolver to get the authoritative IP address for a domain name that isn’t in its cache: an iterative request and a recursive request. In an iterative request, the resolver pings the top-level domain’s DNS servers for the authoritative DNS for the destination domain, then it sends a DNS request for the full hostname to that authoritative server. If the computer that the request is seeking is in a subdomain or "zone" within a larger domain—such as http://www.subdomain.domain.com—it may tell the resolver to go ask that zone’s DNS server. The resolver "iterates" the request down through the hierarchy of DNS servers until it gets an answer.
But on some networks, the DNS resolver closest to the requesting application doesn’t handle all that work. Instead, it sends a "recursive" request to the next DNS server up and lets that server handle all of the walking through the DNS hierarchy for it. Once all the data is collected from the root, domain, and subdomain DNS servers for the requested address, the resolver then pumps the answer back to its client.
How DNS queries are supposed to work—when they’re not being used as weapons.
To save time, DNS requests don’t use the "three-way handshake" of the Transmission Control Protocol (TCP) to make all these queries. Instead, DNS typically uses the User Datagram Protocol (UDP)—a "connectionless" protocol that lets the server fire and forget requests.
Pump up the volume
That makes the sending of requests and responses quicker—but it also opens up a door to abuse of DNS that DNS amplification uses to wreak havoc on a target. All the attacker has to do is find a DNS server open to requests from any client and send it requests forged as being from the target of the attack. And there are millions of them.
The "amplification" in DNS amplification attacks comes from the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the attackers’ victim.
DNS amplification attacks wouldn’t be nearly as amplified if it weren’t for the "open" DNS servers they use to fuel the attacks. These servers have been configured (or misconfigured) to answer queries from addresses outside of their network. The volume of traffic that can be generated by such open DNS servers is huge. Last year, Ars reported on a paper presented by Randal Vaughan of Baylor University and Israeli security consultant Gadi Evron at the 2006 DefCon security conference. The authors documented a series of DNS amplification attacks in late 2005 and early 2006 that generated massive traffic loads for the routers of their victims. In one case, the traffic was "as high as 10Gbps and used as many as 140,000 exploited name servers," Vaughan and Evron reported. "A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60."
But even if you can’t find an open DNS server to blast recursive responses from, you can still depend on the heart of the Internet for a respectable hail of packet projectiles. A "root hint" request—sending a request for name servers for the "." domain—results in a response 20 times larger than the packet the request came in. That’s in part thanks to DNS-SEC, the standard adopted to make it harder to spoof DNS responses, since now the response includes certificate data from the responding server.
A comparison of a "root hint" query and the response delivered by the DNS server. Not all data shown.
In the case of the attack on Spamhaus, the organization was able to turn to the content delivery network CloudFlare for help. CloudFlare hid Spamhaus behind its CDN, which uses the Anycast feature of the Border Gateway Protocol to cause packets destined for the antispam provider’s site to be routed to the closest CloudFlare point of presence. This spread out the volume of the attack. And CloudFlare was able to then shut off amplified attacks aimed at Spamhaus with routing filters that blocked aggregated DNS responses matching the pattern of the attack.
But that traffic still had to get to Cloudflare before it could be blocked. And that resulted in a traffic jam in the core of the Internet, slowing connections for the Internet as a whole.
No fix on the horizon
The simplest way to prevent DNS amplification and reflection attacks would be to prevent forged DNS requests from being sent along in the first place. But that "simple" fix isn’t exactly easy—or at least easy to get everyone who needs to participate to do.
There’s been a proposal on the books to fix the problem for nearly 13 years—the Internet Engineering Task Force’s BCP 38, an approach to "ingress filtering" of packets. First pitched in
2000 1998 as part of RFC 2267 , the proposal has gone nowhere. And while the problem would be greatly reduced if zone and domain DNS servers simply were configured not to return recursive or even "root hint" responses received from outside their own networks, that would require action by the owners of the network. It’s an action that doesn’t have a direct monetary or security benefit to them associated with it.
ISPs generally do "egress filtering"—they check outbound traffic to make sure it’s coming from IP addresses within their network. This prevents them from filling up their peering connections with bad traffic. But "ingress" filtering would check to make sure that requests coming in through a router were coming from the proper direction based on their advertised IP source.
Another possible solution that would eliminate the problem entirely is to make DNS use TCP for everything—reducing the risk of forged packets. DNS already uses TCP for tasks like zone transfers. But that would require a change to DNS itself, so it’s unlikely that would ever happen, considering that you can’t even convince people to properly configure their DNS servers to begin with.
Maybe the attack on Spamhaus will change that, and core network providers will move to do more to filter DNS traffic that doesn’t seem to match up with known DNS servers. Maybe just maybe, BCP 38 will get some traction. And
Courtesy Mother Jones
If you’re a hacker living in your mom’s basement causing trouble for a world power, can NATO call in an air strike to put a stop to your cybermischief?
That was one question raised this month with the release of the Tallinn Manual on the International Law Applicable to Cyber Warfare, a NATO-commissioned handbook that could be the first step toward codifying the rules under which NATO members will wage cyberwarfare in future conflicts. The project had the input of the International Committee of the Red Cross and US Cyber Command.
The Tallinn Manual is not NATO doctrine; it is the result of a three-year project funded by the NATO Cooperative Cyber Defence Centre of Excellence and conducted by 20 legal experts working in a private capacity. The document could very well influence future rules of engagement for NATO and governments around the world. But for now, it’s a scholarly endeavor; a follow-up three-year project, which digs even deeper into questions pertaining to cyberoperations and state responses, is in the works.
When details of the manual were first reported in the Guardian last week, the rule was widely interpreted as NATO declaring war on hackers and civilian hacktivists. But in terms of wartime precedent, there’s nothing unique about NATO’s "Rule 29"; civilians who directly participate in hostilities have long been deemed legitimate battlefield targets. So of course the same principle would apply to a hacker in an armed conflict, if the hacker’s actions rose to the level of violence. "If someone is causing planes to crash [in a war] using a computer, it’s not really all that different if they’re using a computer rather than some other tool," Julian Sanchez, a Cato Institute research fellow specializing in technology and civil liberties issues, says. "So, sure; go after Alan Cumming," referring to the actor’s character Boris Grishenko, a backstabbing and chauvinist computer programmer targeted by James Bond and the CIA in Goldeneye.
Despite the fairly mundane nature of the rule, Michael Schmitt, chairman of the international law department at the US Naval War College and director of the project that produced the Tallinn Manual, has been flooded with questions about whether NATO is now allowed to send drones to take out Anonymous hackers who they find annoying. "Frankly, I was surprised that part even caught anyone’s attention," Schmitt tells me. "It’s been generating a lot of blowback. But I can assure you NATO is not going to launch jets to hunt down Anonymous members tomorrow. An unexceptional statement has been taken out of context in rather dramatic ways."
Many of these rules would come in handy in a wartime scenario in which Live Free or Die Hard is happening in real life.
The main reason your average hacker doesn’t need to worry about getting blown up by NATO anytime soon is because the Tallinn Manual (which, again, is not official NATO doctrine) is relevant only to (a) an armed conflict or declared war between two states or (b) a civil war within a state. Rule 29 from the 282-page manual (which you can read here for free) addresses a scenario in which a civilian hacker starts working with one side of a conflict to, for instance, execute operations via cyberspace that would hack into enemy intelligence networks, disable command and control electronics, hinder combat capabilities, or harm or kill civilians. This establishes a high bar for what a hacker has to do to trigger an armed response from NATO commanders. And despite much recent hype about cyberwarfare from state actors (China, North Korea, Iran, Israel, etc.) and the growing costs of cybercrime, much of this NATO-commissioned handbook focuses on the abstract, simply because the realm of modern cyberwarfare is relatively new and has yet to be deeply explored. Many of these rules would come in handy in a wartime scenario in which Live Free or Die Hard is happening in real life.
"Cyberwarfare in the future will become a prominent part of the battlefield when prominent countries come to blows," says Martin Libicki, an expert in cyberwar and senior management scientist at the RAND Corporation. "But for now, at least, you don’t just automatically send your drone in after hackers. That’s not the way it works. The worst people like Anonymous are doing nowadays is weapons of mass annoyance."
There’s a real-world test case for this. In the summer of 2011, individuals identifying themselves as Anonymous claimed to have hacked NATO’s website, perhaps as indirect reprisal for the FBI’s arrest of over a dozen alleged hackers. Under current NATO structure, as well as recommendations made in the Tallinn Manual, such a breach would absolutely not warrant violent retribution. "Can you imagine Luxembourg, Estonia, the United States, France, and Spain, getting together and agreeing through the process that NATO demands, and going to the North Atlantic Council, and deciding to drop a bomb on some ordinary hacker?" Schmitt says, with a hint of irritation. "Are you kidding me?"
However, this is where the hypotheticals get a bit muddled. Suppose a civilian hacker who has taken sides in an armed conflict is waging cyberwar remotely from a neutral country. Suppose a terrorist used his or her MacBook Pro to sabotage a major city’s traffic lights in a time of peace, resulting in mass carnage? When discussing such hypotheticals, experts often point to analogous situations such as the bin Laden raid or modern drone warfare. But this is still all uncharted territory. "The real problem here is not whether the basic rules of war should apply when cyberspace is involved; the real problem here is that the rules of war have, for the most part, a long traditional of being defined through kinetic warfare and physical conflict," Sanchez says. "But we’ve found that in some cases when we’ve tried to apply the laws and rules of war to cyberspace, that translation is not always so obvious."
But as for the conspiracy theories sprouting up regarding the recently published Tallinn Manual, the situation isn’t murky. "If somebody defaces my or NATO’s desktop, that’s hardly direct participation in armed conflict, and NATO would not be allowed to resort to armed force," Schmitt says. "It would make great TV, though—pure Hollywood."
NATO did not respond to requests for comment, which I can only assume indicates they have already sent a drone to vaporize my laptop.