The Domain Name System (DNS) plays a critical role in the Internet infrastructure. Most applications rely on a proper working DNS in order to perform their functions as needed. Historically, sites either manage
To read the second part of this series, DNS in the cloud: Building a secure DNS architecture, click here.
In the cloud, the management of DNS will fall to the cloud service provider (CSP). This article, which is the first part in a two-part series, examines DNS in the cloud and attempts to explain the various attack vectors into this service. The second part discusses attack mitigation and provides guidance for cloud consumers on what they should demand from cloud providers.
In the context of the three cloud service models (IaaS, PaaS and SaaS), DNS can be considered an IaaS service. The IaaS cloud environment, as defined by the National Institute of Standards and Technology (NIST), relies on virtual machines. In their 2011 paper, “Understanding cloud computing vulnerabilities,” Grobauer, Walloshek and Stocker, published by IEEE, observed that resource pooling and sharing of infrastructure components such as DNS and DHCP, along with general IP protocol vulnerabilities, could actually enable cross-tenant attacks in IaaS. Let’s examine some of these DNS attack vectors.
DNS attack vectors in the cloud
Server modification can be defined as any attack that involves changing the data on either the Authoritative Nameserver (ANS) or the Caching Nameserver (CNS). Server modification of ANS data results in the client request traversing the Internet, or simply an area outside the trusted network, avoiding request redirection and receiving erroneous information upon reaching the destination server. CNS data modification results in the client receiving bad data from a trusted server.
Cache poisoning attacks rely on modifying the data that is stored on the CNS. By modifying the cache data, the attacker can guarantee all requests originating at a site get directed to an erroneous site. Modifying the cached data requires the attacker to either attack the host directly, or to capture the correct response as it returns and insert the rogue response. In the cloud, the cache can reside on either a central server that provides DNS information to all tenants or in each virtual environment.
A look at the Kaminsky cache poisoning bug illustrates the method of capturing the returned response and replacing the response with a bogus value. The bug discovered by researcher Dan Kaminsky would cause even greater problems if a cloud provider’s DNS server were vulnerable to this attack. Instead of a single server for an organization becoming corrupted, an entire farm of DNS servers or all the tenants that rely on the CSP’s CNS will receive false lookup information. In a cloud with 20 organizations supported using the CSP’s CNS, all 20 organizations would operate on forged DNS data. DNS has become a high-profile target; DNS servers residing in the cloud represent an even more attractive target.
One way to prevent cache poisoning attacks in the CNS relies on implementation of (DNS Security Extensions (DNSSEC). DNSSEC allows the zone owner to digitally sign the zone information for the ANS. The CNS can enable DNSSEC validation of responses from signed DNS zones. Unfortunately, DNSSEC implementation is not as widespread as it should be; nor is DNSSEC implementation a trivial task.
IaaS servers are attractive targets
The resource sharing that takes place in the IaaS cloud resides in either a small management area or a standard management path for DNS service configuration data. Virtualization’s role in making the environment smaller creates a greater opportunity for exploitation should attacks be successful. Considering the various components and operations involved, there are several different attack vectors that can be exploited when attempting to compromise DNS in the cloud. The data-at-rest targets include the cached data and the zone data. The data-in-transit attacks would involve request hijacking and redirection. Additionally, denial-of-service (DoS) attacks can simply make a site appear to be unreachable without ever having to take down an actual server.
When a single server is attacked, a serious trust failure results, however, when directed at a group of servers this can be devastating. Backbone DNS servers are attractive because of the number of Internet queries they resolve. CSP servers will be attractive for the exact same reason. IaaS places many DNS servers in a central location, and with virtualization, numerous virtual DNS servers can be housed on a single physical server.
The central DNS server for all organizations provides a high value target for attackers. The central DNS server architecture will likely consist of more than one host that is load balanced for requests. In order to achieve management efficiency, the zone files will need to be centrally located. If an attacker gets to the zone files for one organization, he or she will be able to access the other organizations housed in the cloud.
If an IaaS DNS recursive resolver is attacked, the attacker can modify the named configuration file to turn off the “DNSSEC-aware” flag to disable DNSSEC checking on responses. If the attacker gains access to the ANS, the attacker can modify records to replace legitimate IP addresses with bogus or “pharmed” IP addresses.
Furthermore, DNSSEC, which is historically protected against data modification, may or may not help. If the zones are DNSSEC signed and the keys are housed on the server(s) that contain the zone files, the attacker can regenerate the new keys, update, sign and publish the new zone information, thus providing a false level of assurance to recipients that perform DNSSEC checking. While this requires a significant effort, the payoff is well worth the time investment.
One overlooked concern with DNS in the cloud is the use of DNS tunnels. DNS tunnels can be created by using the DNS TCP channel in order to set up a SOCKS proxy for communication between sites. Tenants in the cloud can set up these tunnels in order to create cross-tenant paths. These paths can introduce an un-watched channel into the private virtual environments.
Attacks against the server host operating system can be devastating in the cloud. If a single server houses as few as 50 domains in the virtual environment, an attacker can ascertain the “physical” IP address, then launch a DoS attack. If the attacker is closer to the wire, a layer 2 attack directed at the MAC address can result in all of the virtual servers becoming unavailable. In DoS attack scenarios, this number seems small; however, many users feel the impact of a DoS attack against a single infrastructure component, such as a router or DNS server.
About the author:
Char Sample has close to 20 years of experience in Internet security, and she has been involved with integrating various security technologies in both the public and private sectors. She is a doctoral candidate at Capitol College, where her dissertation topic deals with the use of cultural markers in attack attribution.
This was first published in July 2012