Entries Tagged "DNS"

Page 3 of 4

Kahn, Diffie, Clark, and Me at Bletchley Park

Saturday, I visited Bletchley Park to speak at the Annual ACCU Security Fundraising Conference. They had a stellar line of speakers this year, and I was pleased to be a part of the day.

Talk #1: “The Art of Forensic Warfare,” Andy Clark. Riffing on Sun Tzu’s The Art of War, Clark discussed the war—the back and forth—between cyber attackers and cyber forensics. This isn’t to say that we’re at war, but today’s attacker tactics are increasingly sophisticated and warlike. Additionally, the pace is greater, the scale of impact is greater, and the subjects of attack are broader. To defend ourselves, we need to be equally sophisticated and—possibly—more warlike.

Clark drew parallels from some of the chapters of Sun Tzu’s book combined with examples of the work at Bletchley Park. Laying plans: when faced with an attacker—especially one of unknown capabilities, tactics, and motives—it’s important to both plan ahead and plan for the unexpected. Attack by stratagem: increasingly, attackers are employing complex and long-term strategies; defenders need to do the same. Energy: attacks increasingly start off simple and get more complex over time; while it’s easier to defect primary attacks, secondary techniques tend to be more subtle and harder to detect. Terrain: modern attacks take place across a very broad range of terrain, including hardware, OSs, networks, communication protocols, and applications. The business environment under attack is another example of terrain, equally complex. The use of spies: not only human spies, but also keyloggers and other embedded eavesdropping malware. There’s a great World War II double-agent story about Eddie Chapman, codenamed ZIGZAG.

Talk #2: “How the Allies Suppressed the Second Greatest Secret of World War II,” David Kahn. This talk is from Kahn’s article of the same name, published in the Oct 2010 issue of The Journal of Military History. The greatest secret of World War II was the atom bomb; the second greatest secret was that the Allies were reading the German codes. But while there was a lot of public information in the years after World War II about Japanese codebreaking and its value, there was almost nothing about German codebreaking. Kahn discussed how this information was suppressed, and how historians writing World War II histories never figured it out. No one imagined as large and complex an operation as Bletchley Park; it was the first time in history that something like this had ever happened. Most of Kahn’s time was spent in a very interesting Q&A about the history of Bletchley Park and World War II codebreaking.

Talk #3: “DNSSec, A System for Improving Security of the Internet Domain Name System,” Whitfield Diffie. Whit talked about three watersheds in modern communications security. The first was the invention of the radio. Pre-radio, the most common communications security device was the code book. This was no longer enough when radio caused the amount of communications to explode. In response, inventors took the research in Vigenère ciphers and automated them. This automation led to an explosion of designs and an enormous increase in complexity—and the rise of modern cryptography.

The second watershed was shared computing. Before the 1960s, the security of computers was the physical security of computer rooms. Timesharing changed that. The result was computer security, a much harder problem than cryptography. Computer security is primarily the problem of writing good code. But writing good code is hard and expensive, so functional computer security is primarily the problem of dealing with code that isn’t good. Networking—and the Internet—isn’t just an expansion of computing capacity. The real difference is how cheap it is to set up communications connections. Setting up these connections requires naming: both IP addresses and domain names. Security, of course, is essential for this all to work; DNSSec is a critical part of that.

The third watershed is cloud computing, or whatever you want to call the general trend of outsourcing computation. Google is a good example. Every organization uses Google search all the time, which probably makes it the most valuable intelligence stream on the planet. How can you protect yourself? You can’t, just as you can’t whenever you hand over your data for storage or processing—you just have to trust your outsourcer. There are two solutions. The first is legal: an enforceable contract that protects you and your data. The second is technical, but mostly theoretical: homomorphic encryption that allows you to outsource computation of data without having to trust that outsourcer.

Diffie’s final point is that we’re entering an era of unprecedented surveillance possibilities. It doesn’t matter if people encrypt their communications, or if they encrypt their data in storage. As long as they have to give their data to other people for processing, it will be possible to eavesdrop on. Of course the methods will change, but the result will be an enormous trove of information about everybody.

Talk #4: “Reconceptualizing Security,” me. It was similar to this essay and this video.

Posted on November 9, 2010 at 6:01 AMView Comments

DNSSEC Root Key Split Among Seven People

The DNSSEC root key has been divided among seven people:

Part of ICANN’s security scheme is the Domain Name System Security, a security protocol that ensures Web sites are registered and “signed” (this is the security measure built into the Web that ensures when you go to a URL you arrive at a real site and not an identical pirate site). Most major servers are a part of DNSSEC, as it’s known, and during a major international attack, the system might sever connections between important servers to contain the damage.

A minimum of five of the seven keyholders—one each from Britain, the U.S., Burkina Faso, Trinidad and Tobago, Canada, China, and the Czech Republic—would have to converge at a U.S. base with their keys to restart the system and connect everything once again.

That’s a secret sharing scheme they’re using, most likely Shamir’s Secret Sharing.
We know the names of some of them.

Paul Kane—who lives in the Bradford-on-Avon area—has been chosen to look after one of seven keys, which will ‘restart the world wide web’ in the event of a catastrophic event.

Dan Kaminsky is another.

I don’t know how they picked those countries.

Posted on July 28, 2010 at 11:12 AMView Comments

The Techniques for Distributing Child Porn

Fascinating history of an illegal industry:

Today’s schemes are technologically very demanding and extremely complex. It starts with the renting of computer servers in several countries. First the Carders are active to obtain the credit cards and client identities wrongfully. These data are then passed to the falsifiers who manufacture wonderful official documents so that they can be used to identify oneself. These identities and credit card infos are then sold as credit card kits to operators. There is still an alternative where no credit card is needed: in the U.S. one can buy so-called Visa or MasterCard gift cards. However, these with a certain amount of money charged Visa or MasterCard cards usually only usable in the U.S.. Since this anonymous gift cards to buy, these are used to over the Internet with fake identities to pay. Using a false identity and well-functioning credit card servers are then rented and domains purchased as an existing, unsuspecting person. Most of the time an ID is required and in that case they will simply send a forged document. There is yet another alternative: a payment system called WebMoney (webmoney.ru) that is in Eastern Europe as widespread as PayPal in Western Europe. Again, accounts are opened with false identities. Then the business is very simple in Eastern Europe: one buys domains and rents servers via WebMoney and uses it to pay.

As soon as the server is available, a qualified server admin connects to it via a chain of servers in various countries with the help of SSH on the new server. Today complete partitions are encrypted with TrueCrypt and all of the operating system logs are turned off. Because people consider the servers in Germany very reliable, fast and inexpensive, these are usually configured as HIDDEN CONTENT SERVERS. In other words, all the illegal files such as pictures, videos, etc. are uploaded on these servers – naturally via various proxies (and since you are still wondering what these proxies can be – I’ll explain that later). These servers are using firewalls, completely sealed and made inaccessible except by a few servers all over the world – so-called PROXY SERVERs or FORWARD SERVERs. If the server is shut down or Someone logs in from the console, the TrueCrypt partition is unmounted. Just as was done on the content servers, logs are turned off and TrueCrypt is installed on the so-called proxy servers or forward servers. The Russians have developed very clever software that can be used as a proxy server (in addition to the possibilities of SSL tunneling and IP Forwarding). These proxy servers accept incoming connections from the retail customers and route them to the content Servers in Germany – COMPLETELY ANONYMOUSLY AND UNIDENTIFIABLY. The communication link can even be configured to be encrypted. Result: the server in Germany ATTRACTS NO ATTENTION AND STAYS COMPLETELY ANONYMOUS because its IP is not used by anyone except for the proxy server that uses it to route the traffic back and forth through a tunnel – using similar technology as is used with large enterprise VPNs. I stress that these proxy servers are everywhere in the world and only consume a lot of traffic, have no special demands, and above all are completely empty.

Networks of servers around the world are also used at the DNS level. The DNS has many special features: the refresh times have a TTL (Time To Live) of approximately 10 minutes, the entries usually have multiple IP entries in the round robin procedure at each request and rotate the visitor to any of the forward proxy servers. But what is special are the different zones of the DNS linked with extensive GeoIP databases … Way, there are pedophiles in authorities and hosting providers, allowing the Russian server administrators access to valuable information about IP blocks etc. that can be used in conjuction with the DNA. Each one who has little technical knowledge will understabd the importance and implications of this… But what I have to report to you is much more significant than this, and maybe they will finally understand to what extent the public is cheated by the greedy politicians who CANNOT DO ANYTHING against child pornography but use it as a means to justify total monitoring.

Posted on March 11, 2009 at 5:49 AMView Comments

The DNS Vulnerability

Despite the best efforts of the security community, the details of a critical internet vulnerability discovered by Dan Kaminsky about six months ago have leaked. Hackers are racing to produce exploit code, and network operators who haven’t already patched the hole are scrambling to catch up. The whole mess is a good illustration of the problems with researching and disclosing flaws like this.

The details of the vulnerability aren’t important, but basically it’s a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com—there’s no way for you to tell the difference—and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here’s the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There’s a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability—but not the details—and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn’t important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I’m kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What’s the moral here? It’s easy to condemn Kaminsky: If he had shut up about the problem, we wouldn’t be in this mess. But that’s just wrong. Kaminsky found the vulnerability by accident. There’s no reason to believe he was the first one to find it, and it’s ridiculous to believe he would be the last. Don’t shoot the messenger. The problem is with the DNS protocol; it’s insecure.

The real lesson is that the patch treadmill doesn’t work, and it hasn’t for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won’t prevent every vulnerability, but it’s much more secure—and cheaper—than the patch treadmill we’re all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It’s not that he discovers all possible attacks before the bad guys do; it’s more that he anticipates potential types of attacks, and defends against them even if he doesn’t know their details. I see this all the time in good cryptographic designs. It’s over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky’s vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That’s exactly the work-around being rolled out now following Kaminsky’s discovery. Bernstein didn’t discover Kaminsky’s attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn’t need to be patched; it’s already immune to Kaminsky’s attack.

That’s what a good design looks like. It’s not just secure against known attacks; it’s also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards … everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

This essay previously appeared on Wired.com.

EDITED TO ADD (8/7): Seems like the flaw is much worse than we thought.

EDITED TO ADD (8/13): Someone else discovered the vulnerability first.

Posted on July 29, 2008 at 6:01 AMView Comments

Hacking ISP Error Pages

This is a big deal:

At issue is a growing trend in which ISPs subvert the Domain Name System, or DNS, which translates website names into numeric addresses.

When users visit a website like Wired.com, the DNS system maps the domain name into an IP address such as 72.246.49.48. But if a particular site does not exist, the DNS server tells the browser that there’s no such listing and a simple error message should be displayed.

But starting in August 2006, Earthlink instead intercepts that Non-Existent Domain (NXDOMAIN) response and sends the IP address of ad-partner Barefruit’s server as the answer. When the browser visits that page, the user sees a list of suggestions for what site the user might have actually wanted, along with a search box and Yahoo ads.

The rub comes when a user is asking for a nonexistent subdomain of a real website, such as http://webmale.google.com, where the subdomain webmale doesn’t exist (unlike, say, mail in mail.google.com). In this case, the Earthlink/Barefruit ads appear in the browser, while the title bar suggests that it’s the official Google site.

As a result, all those subdomains are only as secure as Barefruit’s servers, which turned out to be not very secure at all. Barefruit neglected basic web programming techniques, making its servers vulnerable to a malicious JavaScript attack. That meant hackers could have crafted special links to unused subdomains of legitimate websites that, when visited, would serve any content the attacker wanted.

The hacker could, for example, send spam e-mails to Earthlink subscribers with a link to a webpage on money.paypal.com. Visiting that link would take the victim to the hacker’s site, and it would look as though they were on a real PayPal page.

Kaminsky demonstrated the vulnerability by finding a way to insert a YouTube video from 80s pop star Rick Astley into Facebook and PayPal domains. But a black hat hacker could instead embed a password-stealing Trojan. The attack might also allow hackers to pretend to be a logged-in user, or to send e-mails and add friends to a Facebook account.

Earthlink isn’t alone in substituting ad pages for error messages, according to Kaminsky, who has seen similar behavior from other major ISPs including Verizon, Time Warner, Comcast and Qwest.

Another article.

Posted on April 24, 2008 at 6:43 AMView Comments

Security by Letterhead

This otherwise amusing story has some serious lessons:

John: Yes, I’m calling to find out why request number 48931258 to transfer somedomain.com was rejected.

ISP: Oh, it was rejected because the request wasn’t submitted on company letterhead.

John: Oh… sure… but… uh, just so we’re on the same page, can you define exactly what you mean by ‘company letterhead?’

ISP: Well, you know, it has the company’s logo, maybe a phone number and web site address… that sort of thing. I mean, your fax looks like it could’ve been typed by anyone!

John: So you know what my company letterhead looks like?

ISP: Ye… no. Not specifically. But, like, we’d know it if we saw it.

John: And what if we don’t have letterhead? What if we’re a startup? What if we’re redesigning our logo?

ISP: Well, you’d have to speak to customer—John (clicking and typing): I could probably just pick out a semi-professional-looking MS Word template and paste my request in that and resubmit it, right?

ISP: Look, our policy—John: Oh, it’s ok, I just sent the request back in on letterhead.

Ha ha. The idiot ISP guy doesn’t realize how easy it for anyone with a word processor and a laser printer to fake a letterhead. But what this story really shows is how hard it is for people to change their security intuition. Security-by-letterhead was fairly robust when printing was hard, and faking a letterhead was real work. Today it’s easy, but people—especially people who grew up under the older paradigm—don’t act as if it is. They would if they thought about it, but most of the time our security runs on intuition and not on explicit thought.

This kind of thing bites us all the time. Mother’s maiden name is no longer a good password. An impressive-looking storefront on the Internet is not the same as an impressive-looking storefront in the real world. The headers on an e-mail are not a good authenticator of its origin. It’s an effect of technology moving faster than our ability to develop a good intuition about that technology.

And, as technology changes ever increasingly faster, this will only get worse.

Posted on October 30, 2007 at 6:33 AMView Comments

The Storm Worm

The Storm worm first appeared at the beginning of the year, hiding in e-mail attachments with the subject line: “230 dead as storm batters Europe.” Those who opened the attachment became infected, their computers joining an ever-growing botnet.

Although it’s most commonly called a worm, Storm is really more: a worm, a Trojan horse and a bot all rolled into one. It’s also the most successful example we have of a new breed of worm, and I’ve seen estimates that between 1 million and 50 million computers have been infected worldwide.

Old style worms—Sasser, Slammer, Nimda—were written by hackers looking for fame. They spread as quickly as possible (Slammer infected 75,000 computers in 10 minutes) and garnered a lot of notice in the process. The onslaught made it easier for security experts to detect the attack, but required a quick response by antivirus companies, sysadmins and users hoping to contain it. Think of this type of worm as an infectious disease that shows immediate symptoms.

Worms like Storm are written by hackers looking for profit, and they’re different. These worms spread more subtly, without making noise. Symptoms don’t appear immediately, and an infected computer can sit dormant for a long time. If it were a disease, it would be more like syphilis, whose symptoms may be mild or disappear altogether, but which will eventually come back years later and eat your brain.

Storm represents the future of malware. Let’s look at its behavior:

  1. Storm is patient. A worm that attacks all the time is much easier to detect; a worm that attacks and then shuts off for a while hides much more easily.
  2. Storm is designed like an ant colony, with separation of duties. Only a small fraction of infected hosts spread the worm. A much smaller fraction are C2: command-and-control servers. The rest stand by to receive orders. By only allowing a small number of hosts to propagate the virus and act as command-and-control servers, Storm is resilient against attack. Even if those hosts shut down, the network remains largely intact, and other hosts can take over those duties.
  3. Storm doesn’t cause any damage, or noticeable performance impact, to the hosts. Like a parasite, it needs its host to be intact and healthy for its own survival. This makes it harder to detect, because users and network administrators won’t notice any abnormal behavior most of the time.
  4. Rather than having all hosts communicate to a central server or set of servers, Storm uses a peer-to-peer network for C2. This makes the Storm botnet much harder to disable. The most common way to disable a botnet is to shut down the centralized control point. Storm doesn’t have a centralized control point, and thus can’t be shut down that way.

    This technique has other advantages, too. Companies that monitor net activity can detect traffic anomalies with a centralized C2 point, but distributed C2 doesn’t show up as a spike. Communications are much harder to detect.

    One standard method of tracking root C2 servers is to put an infected host through a memory debugger and figure out where its orders are coming from. This won’t work with Storm: An infected host may only know about a small fraction of infected hosts—25-30 at a time—and those hosts are an unknown number of hops away from the primary C2 servers.

    And even if a C2 node is taken down, the system doesn’t suffer. Like a hydra with many heads, Storm’s C2 structure is distributed.

  5. Not only are the C2 servers distributed, but they also hide behind a constantly changing DNS technique called “fast flux.” So even if a compromised host is isolated and debugged, and a C2 server identified through the cloud, by that time it may no longer be active.
  6. Storm’s payload—the code it uses to spread—morphs every 30 minutes or so, making typical AV (antivirus) and IDS techniques less effective.
  7. Storm’s delivery mechanism also changes regularly. Storm started out as PDF spam, then its programmers started using e-cards and YouTube invites—anything to entice users to click on a phony link. Storm also started posting blog-comment spam, again trying to trick viewers into clicking infected links. While these sorts of things are pretty standard worm tactics, it does highlight how Storm is constantly shifting at all levels.
  8. The Storm e-mail also changes all the time, leveraging social engineering techniques. There are always new subject lines and new enticing text: “A killer at 11, he’s free at 21 and …,” “football tracking program” on NFL opening weekend, and major storm and hurricane warnings. Storm’s programmers are very good at preying on human nature.
  9. Last month, Storm began attacking anti-spam sites focused on identifying it—spamhaus.org, 419eater and so on—and the personal website of Joe Stewart, who published an analysis of Storm. I am reminded of a basic theory of war: Take out your enemy’s reconnaissance. Or a basic theory of urban gangs and some governments: Make sure others know not to mess with you.

Not that we really have any idea how to mess with Storm. Storm has been around for almost a year, and the antivirus companies are pretty much powerless to do anything about it. Inoculating infected machines individually is simply not going to work, and I can’t imagine forcing ISPs to quarantine infected hosts. A quarantine wouldn’t work in any case: Storm’s creators could easily design another worm—and we know that users can’t keep themselves from clicking on enticing attachments and links.

Redesigning the Microsoft Windows operating system would work, but that’s ridiculous to even suggest. Creating a counterworm would make a great piece of fiction, but it’s a really bad idea in real life. We simply don’t know how to stop Storm, except to find the people controlling it and arrest them.

Unfortunately we have no idea who controls Storm, although there’s some speculation that they’re Russian. The programmers are obviously very skilled, and they’re continuing to work on their creation.

Oddly enough, Storm isn’t doing much, so far, except gathering strength. Aside from continuing to infect other Windows machines and attacking particular sites that are attacking it, Storm has only been implicated in some pump-and-dump stock scams. There are rumors that Storm is leased out to other criminal groups. Other than that, nothing.

Personally, I’m worried about what Storm’s creators are planning for Phase II.

This essay originally appeared on Wired.com.

EDITED TO ADD (10/17): Storm is being partitioned, presumably so parts can be sold off. If that’s true, we should expect more malicious activitity out of Storm in the future; anyone buying a botnet will want to use it.

Slashdot thread on Storm.

EDITEDT TO ADD (10/22): Here’s research that suggests Storm is shinking.

EDITED T OADD (10/24): Another article about Storm striking back at security researchers.

Posted on October 4, 2007 at 6:00 AMView Comments

Dept of Homeland Security Wants DNSSEC Keys

This is a big deal:

The shortcomings of the present DNS have been known for years but difficulties in devising a system that offers backward compatability while scaling to millions of nodes on the net have slowed down the implementation of its successor, Domain Name System Security Extensions (DNSSEC). DNSSEC ensures that domain name requests are digitally signed and authenticated, a defence against forged DNS data, a product of attacks such as DNS cache poisoning used to trick surfers into visiting bogus websites that pose as the real thing.

Obtaining the master key for the DNS root zone would give US authorities the ability to track DNS Security Extensions (DNSSec) “all the way back to the servers that represent the name system’s root zone on the internet”.

Access to the “key-signing key” would give US authorities a supervisory role over DNS lookups, vital for functions ranging from email delivery to surfing the net. At a recent ICANN meeting in Lisbon, Bernard Turcotte, president of the Canadian Internet Registration Authority, said managers of country registries were concerned about the proposal to allow the US to control the master keys, giving it privileged control of internet resources, Heise reports.

Another news report.

Posted on April 9, 2007 at 9:45 AMView Comments

Drive-By Pharming

Sid Stamm, Zulfikar Ramzan, and Markus Jakobsson have developed a clever, and potentially devastating, attack against home routers.

First, the attacker creates a web page containing a simple piece of malicious JavaScript code. When the page is viewed, the code makes a login attempt into the user’s home broadband router, and then attempts to change its DNS server settings to point to an attacker-controlled DNS server. Once the user’s machine receives the updated DNS settings from the router (after the machine is rebooted) future DNS requests are made to and resolved by the attacker’s DNS server.

And then the attacker basically owns the victim’s web connection.

The main condition for the attack to be successful is that the attacker can guess the router password. This is surprisingly easy, since home routers come with a default password that is uniform and often never changed.

They’ve written proof of concept code that can successfully carry out the steps of the attack on Linksys, D-Link, and NETGEAR home routers. If users change their home broadband router passwords to something difficult to guess, they are safe from this attack.

Additional details (as well as a nifty flash animation illustrating it) can be found here. There’s also a paper on the attack. And there’s a Slashdot thread.

Cisco says that 77 of its routers are vulnerable.

Note that the attack does not require the user to download any malicious software; simply viewing a web page with the malicious JavaScript code is enough.

Posted on February 22, 2007 at 12:40 PMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.