{"id":595,"date":"2009-01-30T18:29:02","date_gmt":"2009-01-31T02:29:02","guid":{"rendered":"http:\/\/cubist.cs.washington.edu\/Security\/?p=595"},"modified":"2009-01-30T18:30:11","modified_gmt":"2009-01-31T02:30:11","slug":"security-review-network-solutions%e2%80%99-worldnic-domain-name-hosting-service","status":"publish","type":"post","link":"https:\/\/secblog.cs.washington.edu\/Security\/2009\/01\/30\/security-review-network-solutions%e2%80%99-worldnic-domain-name-hosting-service\/","title":{"rendered":"Security Review: Network Solutions\u2019 Worldnic Domain Name Hosting Service"},"content":{"rendered":"<p>Network Solutions runs one of the largest domain registrars and DNS hosting providers in the world. It currently hosts more than 7.5 million domain names, including many of the most popular web sites on the Internet.  The domain name servers hosted at Worldnic translate URLs into IP addresses, so if these servers are not operational, an otherwise functioning web site is effectively down.<\/p>\n<p>With billions of dollars being shifted from retail to e-commerce every year, web site up-time has become mission-critical to many companies. Any sort of web site failure for even extremely small periods of time can directly affect a 21st century company&#8217;s bottom line. Network Solutions has the very important task of serving as the gateway between customers&#8217; web browsers and companies&#8217; web sites. As the man in the middle, they are a very clear target for attackers. A malicious user has a clear path to disrupt service without ever having to attack a customer or the company itself. This scenario makes top-level security imperative to Network Solutions and Worldnic. A single successful attack could disrupt millions of transactions across millions of web sites.<\/p>\n<p><!--more--><\/p>\n<p><strong>Assets\/Security Goals<\/strong><\/p>\n<p>In the case of Worldnic, the security goals are more directly quantifiable than the assets. The company provides a service, and its assets are the ability to provide that service at all times and to provide that service accurately.<\/p>\n<ul>\n<li>The primary security goal of \tWorldnic is to keep attackers from disrupting their service. As \tmentioned in the summary, companies depend on a level of &#8216;9&#8217;s of \tup-time (e.g., 99.999%) for their websites. Even if these companies&#8217; \twebsites are functional this percentage of the time, Worldnic is \tresponsible for providing at least this level of name-resolution \tservice. To the user, down time due to name-resolution failure is no \tdifferent than down time due to bugs or other functionality errors.<\/li>\n<li>A close second security goal is to \tmaintain the integrity of the name resolution database. The \tpair-wise relationship of domain names and IP addresses is not \tsecret and is not a direct asset to \tprotect. The integrity of this mapping, however, is a serious asset, \tand protecting it is a huge security goal. If some of these mappings \twere changed, a legitimate domain name could be mapped to an evil \twebsite that attacked visitors.<\/li>\n<li>A major asset that lies in the \thands of Worldinc is their customers&#8217; good names. Companies spend \tmillions of dollars in marketing and branding. They also spend a \tlarge amount of time and energy protecting their names in the form \tof trademarks and copyrights. If Worldinc was compromised and a \tcompanies&#8217; URL was mapped to an evil website that attacked users \tor slandered users or slandered other companies or was otherwise \toffensive or objectionable, it is often impossible to disassociate \tthis to consumers, even after the problem has been resolved. Often \ttimes no amount of explanation is good enough if a customer was \tthoroughly put off, and incidents to this extent could cost the \tvictim company a customer for life.<\/li>\n<\/ul>\n<p><strong>Potential Adversaries\/Threats<\/strong><\/p>\n<p>Most of the potential threats involve disabling Worldnic&#8217;s service or altering it somehow. Threats involving the theft of information are much less of a concern in this business model.<\/p>\n<ul>\n<li>A potential adversary could be a \trival company. In the cutthroat world of business it is not \tunthinkable for a rogue company to try to sabotage another. The \tthreats these adversaries pose include disabling the DNS service for \ta particular company or group of companies, or changing their \ttranslations to route to websites that harm the victim companies \timage or reputation.<\/li>\n<li>Another potential adversary could \tbe a computer hacker seeking fame or some other personal \tsatisfaction. Because of the widespread impact a successful attack \twould have across the internet, there is a lot of motivation to \tattack this service. The threat these adversaries pose are service \tdisruption or changing translations to websites with malicious code.<\/li>\n<li>A third potential adversary could \tbe an attacker looking to steal money or personal information. This \ttype of attacker would not pose the threat of disrupting service, \tbut would be focusing on changing domain name resolutions to point \tto web sites under their control. From here they could use phishing \ttechniques to steal unsuspecting users&#8217; passwords or private \tinformation, or to lure them into paying for items sold off of the \treal websites.<\/li>\n<\/ul>\n<p><strong>Potential Weaknesses<\/strong><\/p>\n<ul>There are already several known \tattacks against DNS servers.<\/p>\n<li>The \tDNS cache poisoning attack proposed by security researcher Dan \tKaminsky.  Kaminsky&#8217;s DNS poisoning attack on DNS servers that \tinvolves sending specially crafted packets to DNS servers to trick \tthem into improperly changing the name-to-IP binding discussed \tabove, violating the fundamental trust and purpose of the domain \tname system. This attack can take place in as little as 10 seconds. \tServers that have a patch applied to combat the problem fare better, \t but are still susceptible to a high-bandwidth attack, failing in as \tlittle as 10 hours.<\/li>\n<li>A \tDistributed Denial-of-Service (DDoS) attack to prevent domain names \tfrom resolving for most legitimate users, as took place recently \tagainst Network Solutions. Modern widely-distributed malware (such \tas the Storm bot net) can easily mount crippling attacks against the \tDNS infrastructure of a particular company, effectively bringing \tdown the web sites of their customers.<\/li>\n<li>A \tcombination of modern MD5-collisions and DNS cache  poisoning \texploits could even be used to transparently hijack an entire \tSSL-secured site, such as an online banking site or e-commerce site. \tBy faking a certificate authority through an MD5 collision attack \tand changing the DNS entries, users could believe everything on &#8220;on \tthe level&#8221; when visiting their online bank, even if each user was \tcareful to check certificates and other indications of security. \tQuite simply, a combined attack like this could be indistinguishable \tfrom the real site, expect that passwords and account information \twould be stolen.<\/li>\n<\/ul>\n<p><strong>Potential Defenses<\/strong><\/p>\n<p>There are already several proposed defenses for protecting against DNS cache poisoning attacks. Protecting against denial-of-service attacks may be more difficult, however, because it is hard to tell legitimate queries from queries that are part of an attack, and denying legitimate queries is just as bad as failing due to being swamped by an attacker.<\/p>\n<ul>\n<li>To \tprotect against DNS poisoning, DNS servers can apply a patch that \trandomizes the ports they use, making attacking the server much more \tdifficult. However, servers are still vulnerable to a motivated \tattacker in as little as a matter of hours, so attacks must be \trecognized early and shut down using other methods to prevent \tpoisoning.<\/li>\n<li>Clients \tand servers could switch to the DNSSEC protocol. However, DNSSEC has \tbeen around for a while and has not seen widespread adoption due to \tbackwards-comparability issues, issues of compatibility between a \tlarge and diverse set of distributed clients and servers (including \tmany operating systems and DNS server implementations).<\/li>\n<li>A \tnew domain name resolution protocol could be developed from the \tground up with a focus on security and usability. However, based on \tthe lackluster adoption of IPv6 and DNSSEC, it may take a major \tsecurity incident to sufficiently motivate enough parties on the \tInternet to achieve the critical mass necessary to the transition to \tanother system.<\/li>\n<\/ul>\n<p><strong>Risks<\/strong><\/p>\n<ul>\n<li>Brand \tname degradation via denial of service attacks<\/li>\n<li>Uptime \ttargets for mission-critical services missed by no fault of the \tservice provider<\/li>\n<li>Sophisticated \tphishing attacks using DNS cache poisoning and MD5 collisions<\/li>\n<li>A \tfundamental building block of the Internet is fundamentally flawed \tand susceptible to a variety of attacks<\/li>\n<\/ul>\n<p><strong>Conclusion<\/strong><\/p>\n<p>DNS cache poisoning attacks and Distributed Denial-of-Service attacks against DNS servers such as Network Solutions&#8217; WorldNic pose some fairly major security vulnerabilities, but so far little has been done to address these issues. Fortunately, there have not yet been widespread attacks against the Internet&#8217;s DNS infrastructure; nevertheless, the risk remains and as time goes on and attacks become more sophisticated, the chances of an attack will only increase.<\/p>\n<p>A collaboration with Vince Zanella<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Network Solutions runs one of the largest domain registrars and DNS hosting providers in the world. It currently hosts more than 7.5 million domain names, including many of the most popular web sites on the Internet. The domain name servers &hellip; <a href=\"https:\/\/secblog.cs.washington.edu\/Security\/2009\/01\/30\/security-review-network-solutions%e2%80%99-worldnic-domain-name-hosting-service\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":66,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,5],"tags":[],"class_list":["post-595","post","type-post","status-publish","format-standard","hentry","category-availability","category-security-reviews"],"_links":{"self":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/595","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/users\/66"}],"replies":[{"embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/comments?post=595"}],"version-history":[{"count":3,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/595\/revisions"}],"predecessor-version":[{"id":598,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/posts\/595\/revisions\/598"}],"wp:attachment":[{"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/media?parent=595"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/categories?post=595"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secblog.cs.washington.edu\/Security\/wp-json\/wp\/v2\/tags?post=595"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}