Login  |  Register  |  Contact

Dns

Thursday, January 03, 2013

SSLpocalypse, part XXII

By Rich

For the short version, read Rob Graham at Errata Security.

Google detected someone attempting a man in the middle attack using a certificate issued in Turkey. TURKTRUST issued two subsidiary Certificate Authority certs which allowed whoever had them to sign any certificate they wanted, for any domain they wanted. Yes, this is how SSL works and it’s a big mess (I talked about it a little in 2011).

Google likely detected this using DNS Pinning. Every version of Chrome checks any Google certificate against a list of legitimate Google certificates, which they build into Chrome itself. If there’s a mismatch, Chrome detects and can report it.

Nice, eh? That’s why Rob says don’t mess with Google. You try to MitM any of their domains, and if any users run Chrome they are likely to find out. Everyone else (who can) should do this.

–Rich

Tuesday, December 08, 2009

DNS Resolvers and You

By David J. Meier

As you are already well aware (if not, see the announcement – we’ll wait), Google is now offering a free DNS resolver service. Before we get into the players, though, let’s first understand the reasons to use one of these free services.

You’re obviously reading this blog post, and to get here your computer or upstream DNS cache resolved securosis.com to 209.240.81.67 – as long as that works, what’s the big deal? Why change anything?

Most of you are probably reading this on a computer that dynamically obtains its IP address from the network you’re plugged into. It could be at work, home, or a Starbucks filled with entirely too much Christmas junk. Aside from assigning your own network address, whatever router you are connecting to also tells you where to look up addresses, so you can convert securosis.com to the actual IP address of the server. You never have to configuring your DNS resolver, but can rely on whatever the upstream router (or other DHCP server) tells you to use.

For the most part this is fine, but there’s nothing that says the DNS resolver has to be accurate, and if it’s hacked it could be malicious. It might also be slow, unreliable, or vulnerable to certain kinds of attacks. Some resolvers actively mess with your traffic, such as ISPs that return a search pages filled with advertisements whenever you type in a bad address, instead of the expected error.

If you’re on the road, your DNS resolver is normally assigned by whatever network you’re plugged into. At home, it’s your home router, which gets its upstream resolver from your ISP. At work, it’s… work. Work networks are generally safe, but aside from the reliability issues we know that home ISPs and public networks are prime targets for DNS attacks. Thus there are security, reliability, performance, and even privacy advantages to using a trustworthy service.

Each of the more notable free providers cites its own advantages, along the lines of:

  • Cache/speed – In this case a large cache should equate to a fast lookup. Since DNS is hierarchical in naturem if the immediate cache you’re asking to resolve a name already has the record you want, there is less wait to get the answer back. Maintaining the relevance and accuracy of this cache is part of what separates a good fast DNS service from, say, the not-very-well-maintained-DNS-service-from-your-ISP. Believe it or not, but depending on your ISP, a faster resolver might noticeably speed up your web browsing.
  • Anycast/efficiency – This gets down into the network architecture weeds, but at a high level it means that when I am in Minnesota, traffic I send to a certain special IP address may end up at a server in Chicago, while traffic from Oregon to that same address may go to a server in California instead. Anycast is often used in DNS to provide faster lookups based on geolocation, user density, or any other metrics the network engineers choose, to improve speed and efficiency.
  • Security – Since DNS is susceptible to many different attacks, it’s a common attack vector for things like create a denial-of-service on a domain name, or poisoning DNS results so users of a service (domain name) are redirected to a malicious site instead. There are many attacks, but the point is that if a vendor focuses on DNS as a service, they have probably invested more time and effort into protecting it than an ISP who regards DNS as simply a minor cost of doing business.

These are just a few reasons you might want to switch to a dedicated DNS resolver. While there are a bunch of them out there, here are three major services, each offering something slightly different:

  • OpenDNS: One of the most full featured DNS resolution services, OpenDNS offers multiple plans to suit your needs – basic is free. The thing that sets OpenDNS apart from the others is their dashboard, from which you can change how the service responds to your networks. This adds flexibility, with the ability to enable and disable features such as content filtering, phishing/botnet/malware protection, reporting, logging, and personalized shortcuts. This enables DNS to serve as a security feature, as the resolver can redirect you someplace safe if you enter the wrong address; you can also filter content in different categories. The one thing that OpenDNS often gets a bad rap for, however, is DNS redirection on non-existent domains. Like many ISPs, OpenDNS treats every failed lookup as an opportunity to redirect you to a search page with advertisements. Since many other applications (Twitter clients, Skype, VPN, online gaming, etc…) use DNS, if you are using OpenDNS with the standard configuration you could potentially leak login credentials to the network, as a bad request will fail to get back a standard NXDOMAIN response. This can result in sending authentication credentials to OpenDNS, as your confused client software sees the response as a successful NOERROR and proceeds, rather than aborting as it would if it got back the ‘proper’ NXDOMAIN. You can disable this behavior, but doing so forfeits some of the advertised features that rely on it. OpenDNS is a great option for home users who want all the free security protection they can get, as well as for organizations interested in outsourcing DNS security and gaining a level of control and insight that might otherwise be available only through on-site hardware. Until your kid figures out how to set up their own DNS, you can use it to keep them from visiting porn sites. Not that your kid would ever do that.
  • DNSResolvers: A simple no-frills DNS resolution service. All they do is resolve addresses – no filtering, redirection, or other games. This straight up DNS resolution service also won’t filter for security (phishing/botnet/malware). DNSResolvers is a great fast service for people who want well-maintained resolvers and are handling security themselves. DNSResolvers effectively serves as an ad demonstrating the competence and usefulness of parent company easyDNS), by providing a great free DNS service, which encourages some users to consider easyDNS’ billable DNS services. (Full disclosure: we pay for some of easyDNS’s commercial services).
  • Google Public DNS: Almost functionally identical to DNSResolvers, Google’s standards-compliant DNS resolution service offers no blocking, filtering, or redirection. They emphasize their active resolver cache, which helps with request lookup speeds; this may be an advantage in comparison to with DNSResolvers. Your mileage may vary, however, depending on your own location and ISP.

Not surprisingly, all the people I randomly talked to about Google DNS had the same initial reactions: “Google already has enough of my information.” and “Yeah, right! Like they’re not going to correlate it to other services I use.” None of those people had actually read the privacy statement which is short and to the point. As of this writing, Google keeps DNS information private, and does not correlate it with your other Google activities.

So why is this something that Google feels is worth the time and expense? The trivial answer is monetary. But most services Google offers are visual, at some level, and thus advertising makes sense. However with DNS and Google’s stance (remember they promise not going to meddle, and to remain standards compliant) they’re not in a position to provide anything visually. This probably means Google is trying to position itself for something which might allow them to create a revenue stream: DNSSEC. It may be a stretch now, but depending on how DNSSEC plays out, there could be opportunity for providing secure DNS services which could very well roll back into something like Google Apps – think key management, generation, and rotation services. This also gives them an incredible source of information – every single website anyone using the service is visiting. Even without any identifying information, such data is incredibly useful – especially combined with all their advertising and indexing data. Ka-ching.

Back to our main point, though: external DNS resolvers and you. The first three bullets above are generally sufficient reason not to use your ISP’s DNS service, but add to that the fact that most ISPs today are trying to monetize your typos when typing domain names (Comcast, for example, has a service called “Domain Helper” in which they oh-so-helpfully enrolled their all subscribers in last August). Additionally, ISP resolvers are generally behind the curve on security updates compared to dedicated services. This really became apparent when Dan Kaminsky was exposing serious DNS flaws. DNS is an essential component of Internet service, and a good place to improve security through separation of duties – in addition to the potential performance benefits. Personally I feel it’s a good thing that Google is starting to play in this space, as it raises the bar for their competitors, and draws more attention to the possibilities.

Changing your service is easy. On your computer or home router, in your network configuration there’s a setting for DNS. Each DNS resolver service provide two IP addresses (primary and secondary) and you can simply enter these manually. Any computer behind a home router uses the DNS resolvers it specifies, unless you manually override them on the computer. Don’t forget that if you have a laptop, even if you set a new DNS resolver on your home router, you will also want to set it directly on the laptop for when you connect to other networks.

Better security, speed, and reliability. What more could you ask for?

–David J. Meier

Thursday, September 24, 2009

Stupid FUD: Weird Nominum Interview

By Rich

We see a lot of FUD on a daily basis here in the security industry, and it’s rarely worth blogging about. But for whatever reason this one managed to get under my skin.

Nominum is a commercial DNS vendor that normally targets large enterprises and ISPs. Their DNS server software includes more features than the usual BIND installation, and was originally designed to run in high-assurance environments. From what I know, it’s a decent product. But that doesn’t excuse the stupid statements from one of their executives in this interview that’s been all over the interwebs the past couple days:

Q: In the announcement for Nominum’s new Skye cloud DNS services, you say Skye ‘closes a key weakness in the internet’. What is that weakness?

A: Freeware legacy DNS is the internet’s dirty little secret – and it’s not even little, it’s probably a big secret. Because if you think of all the places outside of where Nominum is today – whether it’s the majority of enterprise accounts or some of the smaller ISPs – they all have essentially been running freeware up until now. Given all the nasty things that have happened this year, freeware is a recipe for problems, and it’s just going to get worse.

Q: Are you talking about open-source software?

A: Correct. So, whether it’s Eircom in Ireland or a Brazilian ISP that was attacked earlier this year, all of them were using some variant of freeware. Freeware is not akin to malware, but is opening up those customers to problems.

By virtue of something being open source, it has to be open to everybody to look into. I can’t keep secrets in there. But if I have a commercial-grade software product, then all of that is closed off, and so things are not visible to the hacker.

Nominum software was written 100 percent from the ground up, and by having software with source code that is not open for everybody to look at, it is inherently more secure.

I would respond to them by saying, just look at the facts over the past six months, at the number of vulnerabilities announced and the number of patches that had to made to Bind and freeware products. And Nominum has not had a single known vulnerability in its software.

The word “bullsh**” comes to mind. Rather than going on a rant, I’ll merely include a couple of interesting reference points:

  • Screenshot of a cross-site scripting vulnerability on the Nominum customer portal.
  • Link to a security advisory in 2008. Gee, I guess it’s older than 6 months, but feel free to look at the record of DJBDNS, which wasn’t vulnerable to the DNS vuln.
  • As for closed source commercial code having fewer vulnerabilities than open source, I refer you to everything from the recent SMB2 vulnerability, to pretty much every proprietary platform vs. FOSS in history. There are no statistics to support his position. Okay, maybe if you set the scale for 2 weeks. That might work, “over the past 2 weeks we have had far fewer vulnerabilities than any open source DNS implementation”.

Their product and service are probably good (once they fix that XSS, and any others that are lurking), but what a load of garbage in that interview…

–Rich

Monday, November 24, 2008

Politics And Protocols

By Rich

Catching up from last week I saw this article in Techworld (from NetworkWorld) about an IETF meeting to discuss the impact of Dan Kaminsky’s DNS exploit and potential strategies for hardening DNS.

The election season may be over, but it’s good to see politics still hard at work:

One option is for the IETF to do nothing about the Kaminsky bug. Some participants at the DNS Extensions working group meeting this week referred to all of the proposals as a “hack” and argued against spending time developing one of them into a standard because it could delay DNSSEC deployment. Other participants said it was irresponsible for the IETF to do nothing about the Kaminsky bug because large sections of the DNS will never deploy DNSSEC. “We can do the hack and it might work in the short term, but when DNSSEC gets widely used, we’ll still be stuck with the hack,” said IETF participant Scott Rose, a DNSSEC expert with the US National Institute for Standards and Technology (NIST).

Look, any change to DNS is huge and likely ugly, but it’s disappointing that there seems to be a large contingent that wants to use this situation to push the DNSSEC agenda without exploring other options. DNSSEC is massive, complex, ugly, and prone to its own failures. You can read more about DNSSEC problems at this older series over at Matasano (Part 1, Part 2, site currently experiencing some problems, should be back soon).

The end of the article does offer some hope:

The co-chairs of the DNS Extensions working group said they hope to make a decision on whether to change the DNS protocols in light of the Kaminsky bug before the group’s next meeting in March. ” We want to avoid creating a long-term problem that is caused by a hasty decision,” Sullivan said. “There are big reasons to be careful here. The DNS is a really old protocol and it is fundamental to the Internet. We’re not talking about patching software. We’re talking about patching a protocol. We want to make sure that whatever we do doesn’t break the Internet.”

Good- at least the chairs understand that rushing headlong into DNSSEC may not be the answer. We might end up there anyway, but let’s make damn sure it’s the right thing to do first.

–Rich

Wednesday, November 12, 2008

1 In 4 DNS Servers Still Vulnerable? More Like 4 in 4

By Rich

I was reading this article over at NetworkWorld today on a study by a commercial DNS vendor that concluded 1 in 4 DNS servers is still vulnerable to the big Kaminsky vulnerability.

The problem is, the number is more like 4 in 4.

The new attack method that Dan discovered is only slowed by the updates everyone installed, it isn’t stopped. Now instead of taking seconds to minutes to compromise a DNS server, it can take hours.

Thus if you don’t put compensating security in place, and you’re a target worth hitting, the attacker will still succeed.

This is a case where IDS is your friend- you need to be watching for DNS traffic floods that will indicate you are under attack. There are also commercial DNS solutions you can use with active protections, but for some weird reason I hate the idea of paying for something that’s free, reliable, and widely available.

On that note, I’m going to go listen to my XM Radio. The irony is not lost on me.

–Rich

Wednesday, July 30, 2008

Security Researchers Discover ... 5 Stages of Disclosure Grief

By Adrian Lane

Denial: “Dan may be smart, but Tom Ptacek states the obvious that this isn’t a new threat. Maybe a new spin on an old flaw.”

Anger: “Dan didn’t find shit. He read RFC3383 …” and “Dan has brought NOTHING new to the table. Simply made a name for himself by regurgitating the same old problems.”

Bargaining: “… the sky was already falling before Dan opened his mouth, …”, and “This is just another reason why we need DNSSEC”, and “What Should Dan Have Done?”

Depression: “What can we say right now? Dan has the goods.”

Acceptance: “Dan Kaminsky Disqualified from Most Overhyped Bug Pwnie” and “This is absolutely one of the most exceptional research projects I’ve seen. Dan’s reputation will emerge more than intact …”

DNS Vulnerability: Very interesting. Blog Discourse on DNS Vulnerability: Absolutely mesmerizing. Dan Kaminsky finds a DNS flaw, and half the security research community grieves.

–Adrian Lane

Tuesday, July 22, 2008

Pure Genius

By Rich

There is nothing else to say.

(Hoff claims he wrote it in 8 minutes).

–Rich

Wednesday, July 09, 2008

More On The DNS Vulnerability

By Rich

Okay- it’s been a crazy 36 hours since Dan Kaminsky released his information on the massive multivendor patch and DNS issue. I want to give a little background on how I’ve been involved (for full disclosure) as well as some additional aspects of this. If you hate long stories, the short version is he just walked me through the details, this is a very big deal, and you need to patch immediately.

Dan contacted me about a week or so ago to help get the word out to the CIO-level audience. As an analyst, that’s a group I have more access to. I was involved with the initial press conference and analyst briefings, and helped write the executive overview to put the issue in non-geek terms.

At the time he just gave me the information that was later made public. I’ve known Dan for a few years now and trust him, so I didn’t push as deeply as I would with someone I don’t have that relationship with. Thus, as the comments and other blogs dropped into a maelstrom of discontent, I didn’t have anything significant to add.

Dan realized he underestimated the response of the security community and decided to let me, Ptacek, Dino, and someone else I won’t mention into the fold.

Here’s the deal- Dan has the goods. More goods than I expected. Dino and Ptacek agree. Tom just issued a public retraction/apology. This is absolutely one of the most exceptional research projects I’ve seen. Dan’s reputation will emerge more than intact, although he will still have some black eyes for not disclosing until Black Hat.

Here’s what you need to know:

  1. You must patch your name servers as soon as possible. This is real, it’s probably not what you’re thinking. It’s a really good exploit (which is bad news for us).
  2. Ignore the “Important” rating from Microsoft, and other non-critical ratings. You have to keep in mind that for many of those organizations nothing short of remote code execution without authentication will result in a critical rating. That’s how the systems are built.
  3. Dan screwed up some of his handling of this, and I’m part of that screwup since I set my cynical analyst hat aside and ran totally on trust and reputation. Now that I know more, I stand behind my reaction and statements, but that’s a bad habit for me to get into.
  4. This still isn’t the end of the world, but it’s serious enough you should break your patch cycle (if you have one) on name servers to get them fixed. Then start rolling out to the rest of your infrastructure.
  5. CERT is updating their advisory on an ongoing basis. It’s located here.

Next time something like this happens I’ll push for full details sooner, but Dan is justified in limiting exposure of this. His Black Hat talk will absolutely rock this year.

–Rich

Tuesday, July 08, 2008

Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released

By Rich

Today, CERT is issuing an advisory for a massive multivendor patch to resolve a major issue in DNS that could allow attackers to easily compromise any name server (it also affects clients). Dan Kaminsky discovered the flaw early this year and has been working with a large group of vendors on a coordinated patch.

The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not immediately reveal the vulnerability and reverse engineering isn’t directly possible.

Dan asked for some assistance in getting the word out and was kind enough to sit down with me for an interview. We discuss the importance of DNS, why this issue is such a problem, how he discovered it, and how such a large group of vendors was able to come together, decide on a fix, keep it secret, and all issue on the same day.

Dan, and the vendors, did an amazing job with this one. We’ve also attached the official CERT release and an Executive Overview document discussing the issue.

Executive Overview (pdf)

CERT Advisory (link)

Update: Dan just released a “DNS Checker” on his site Doxpara.com to see if you are vulnerable to the issue. Network Security Podcast, Episode 111, July 8, 2008

And here’s the text of the Executive Overview:

Fixes Released for Massive Internet Security Issue

On July 8th, technology vendors from across the industry will simultaneously release patches for their products to close a major vulnerability in the underpinnings of the Internet. While most home users will be automatically updated, it’s important for all businesses to immediately update their networks. This is the largest synchronized security update in the history of the Internet, and is the result of hard work and dedication across dozens of organizations.

Earlier this year, professional security research Dan Kaminsky discovered a major issue in how Internet addresses are managed (Domain Name System, or DNS). This issue was in the design of DNS and not limited to any single product. DNS is used by every computer on the Internet to know where to find other computers. Using this issue, an attacker could easily take over portions of the Internet and redirect users to arbitrary, and malicious, locations. For example, an attacker could target an Internet Service Provider (ISP), replacing the entire web – all search engines, social networks, banks, and other sites – with their own malicious content. Against corporate environments, an attacker could disrupt or monitor operations by rerouting network traffic traffic, capturing emails and other sensitive business data. Mr. Kaminsky immediately reported the issue to major authorities, including the United States Computer Emergency Response Team (part of the Department of Homeland Security), and began working on a coordinated fix. Engineers from major technology vendors around the world converged on the Microsoft campus in March to coordinate their response. All of the vendors began repairing their products and agreed that a synchronized release, on a single day, would minimize the risk that malicious individuals could figure out the vulnerability before all vendors were able to offer secure versions of their products. The vulnerability is a complex issue, and there is no evidence to suggest that anyone with malicious intent knows how it works.

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses. Unfortunately, due to the scope of this update it’s highly likely that the vulnerability will become public within weeks of the coordinated release. As such, all individuals and organizations should apply the patches offered by their vendors as rapidly as possible.

Since not every system can be patched automatically, and to provide security vendors and other organizations with the knowledge they need to detect and prevent attacks on systems that haven’t been updated, Mr. Kaminsky will publish the details of the vulnerability at a security conference on August 6th. It is expected by this point the details of the vulnerability will be independently discovered, potentially by malicious individuals, and it’s important to make the specific details public for our collective defense. We hope that by delaying full disclosure, organizations will have time to protect their most important systems, including testing and change management for the updates. Mr. Kaminsky has also developed a tool to help people determine if they are at risk from “upstream” name servers, such as their Internet Service Provider, and will be making this publicly available.

Home users with their systems set to automatically update will be protected without any additional action. Vendor patches for software implementing DNS are being issued from major software manufacturers, but some extremely out of date systems may need to updated to current versions before the patches are applied. Executives need to work with their information technology teams to ensure the problem is promptly addressed.

There is absolutely no reason to panic; there is no evidence of current malicious activity using this flaw, but it is important everyone follow their vendor’s guidelines to protect themselves and their organizations.

–Rich