Ask a Question, Get an Answer; How insecure can that be? (Part 2)
In Part 1 of this post we walked through the basic process your computer or mobile device utilizes to translate “www” addresses into Internet Protocol (IP) addresses for communications over the Internet through the use of the domain name system (DNS). We posed the question, for a transaction seemingly as simple as asking a question and obtaining an answer, how insecure could it be? We highlighted a few of the ways the integrity of the DNS data could be compromised:
• Your device could be misconfigured and attempt to contact an attacker’s local DNS server.
• The local DNS server could be misconfigured or hacked rendering it unable to process queries, rendering name translation unavailable and thus the Internet unavailable.
• An Internet DNS server could be misconfigured or hacked, leaving it in a state of providing incorrect answers, possibly misdirecting device connections or rendering Internet connections unavailable.
• An imposter Internet DNS server could falsify and answer and redirect your device to an attacker website. And the local DNS server could provide this cached falsified answer to other devices that attempt to connect.
We also broached the topic of a malware-infested device leveraging DNS for nefarious purposes, but we’ll discuss this vector in Part 3.
As for these vulnerabilities on legitimate queries, let’s examine each of these and highlight strategies to mitigate them. The first vulnerability relates to improper device configuration. Devices, particularly mobile devices, generally rely on another Internet standard mechanism, DHCP (dynamic host configuration protocol) to obtain not only an IP address for use on the network to which they are connecting (enterprise, home, wifi, etc.) but additional parameters including which local DNS server to query.
As long as the administrator of the network to which you are connecting is trustworthy, getting repointed to an imposter DNS server should be relative low risk. However, even with trustworthy networks, errors in configuration of the DHCP server could result in DNS responsiveness issues resulting in network unavailability more so than malicious activity through redirection. But malicious activity know as pharming is a known form of attack where your device installs a virus or Trojan which manipulates your DNS server settings, thereby directing queries to the attacker’s DNS servers. Anti-virus software on devices should help prevent such forms of malicious attack. You can check your DNS server settings within your device’s settings for the network to which you are connected or by typing ipconfig with a command line window on Microsoft Windows.
If you utilize a service provider’s DNS service, you should statically configure your DNS server IP addresses in accordance with instructions from your provider. When connecting through a virtual private network (VPN), e.g., to your enterprise network via a public wifi services, make sure your DNS server settings map to your enterprise DNS servers, not that of the local network to which you are connected.
Mitigating the second vulnerability, local DNS server misconfiguration, requires application of server hardware, operating system and application controls to minimize hacking vulnerabilities. This includes applying patches for operating system, kernel, and DNS application software as well as any other software running on your local DNS servers. This should be standard practice across all of your network and computing infrastructure as should denial of service mitigation approaches such as packet rate limiting.
Protection against misconfiguration requires disciplined configuration checking such as through the use of an IP address management (IPAM) system like IPControl™ from BT Diamond IP. This system greatly reduces the probability of configuration errors. Applying access controls on which users can access the servers and which systems (e.g., IPAM systems, DHCP servers) can update the DNS configuration will also reduce exposure to illicit update attempts.
The third vulnerability relates to security practices of those operating DNS servers on the Internet used to refer and resolve DNS queries for devices. This is where you have little to no control, though the root servers and most top level domain administrators exercise stringent security practices. For your own namespace, if you desire to register your domain name within a given top level domain (e.g., .bank, .diamonds, .pub, etc.), review the domain operator’s security policies to confirm a reasonable approach to mitigating attacks on their DNS servers on which you rely to accurately point to your DNS servers. Otherwise, if there are domains you don’t trust or are known malware domains that you don’t want your network users asking about, you may block them by configuring your recursive servers as DNS firewalls. We’ll discuss DNS firewalls more in Part 3.
The fourth vulnerability entails an attacker providing a seemingly valid answer to a query from your local recursive DNS server prior to the receipt of a valid legitimate answer. In this scenario, the recursive server applies a set of match criteria on the answer to map it to the original query based on parameter settings in the DNS response. If everything checks out, the recursive server will respond to the querying device and cache the answer to provide to others asking the same question. Due to the potential impact on multiple users by virtue of the caching of this data, this form of attack is known as cache poisoning. Most DNS server vendors have implemented basic steps to hinder cache poisoning, such as randomization of DNS parameters, but DNS security extensions (DNSSEC) provides the most effective protection against cache poisoning.
DNSSEC enables the signing of DNS data by the answering DNS server. This enables the recursive server to validate the signatures to confirm that the DNS data indeed originated with the domain operator in question and that the data was not manipulated en route to the recursive server. Should an attacker provide a falsified answer including all matching parameters, DNSSEC validation will disqualify the answer as invalid, even if the attacker signed the answer, unless the attacker stole the private keys of the corresponding domain owner. This risk is non-zero but should be very small, assuming domain signers secure their private keys.
IT security is a complex discipline and requires a multi-faceted approach involving defenses at the network, software, hardware, and user level. Securing DNS likewise requires application of this disciplined approach. Securing your DNS infrastructure will provide your users confidence in network and DNS availability, integrity and security. But even with a secure DNS infrastructure, if an attacker infiltrates user devices with malware to gain a foothold within your network perimeter, the core function of DNS can be put to use by attackers to conduct illicit activity within your network. We’ll discuss how to protect your DNS and your network from such attacks in Part 3 of this post.
• Your device could be misconfigured and attempt to contact an attacker’s local DNS server.
• The local DNS server could be misconfigured or hacked rendering it unable to process queries, rendering name translation unavailable and thus the Internet unavailable.
• An Internet DNS server could be misconfigured or hacked, leaving it in a state of providing incorrect answers, possibly misdirecting device connections or rendering Internet connections unavailable.
• An imposter Internet DNS server could falsify and answer and redirect your device to an attacker website. And the local DNS server could provide this cached falsified answer to other devices that attempt to connect.
We also broached the topic of a malware-infested device leveraging DNS for nefarious purposes, but we’ll discuss this vector in Part 3.
As for these vulnerabilities on legitimate queries, let’s examine each of these and highlight strategies to mitigate them. The first vulnerability relates to improper device configuration. Devices, particularly mobile devices, generally rely on another Internet standard mechanism, DHCP (dynamic host configuration protocol) to obtain not only an IP address for use on the network to which they are connecting (enterprise, home, wifi, etc.) but additional parameters including which local DNS server to query.
As long as the administrator of the network to which you are connecting is trustworthy, getting repointed to an imposter DNS server should be relative low risk. However, even with trustworthy networks, errors in configuration of the DHCP server could result in DNS responsiveness issues resulting in network unavailability more so than malicious activity through redirection. But malicious activity know as pharming is a known form of attack where your device installs a virus or Trojan which manipulates your DNS server settings, thereby directing queries to the attacker’s DNS servers. Anti-virus software on devices should help prevent such forms of malicious attack. You can check your DNS server settings within your device’s settings for the network to which you are connected or by typing ipconfig with a command line window on Microsoft Windows.
If you utilize a service provider’s DNS service, you should statically configure your DNS server IP addresses in accordance with instructions from your provider. When connecting through a virtual private network (VPN), e.g., to your enterprise network via a public wifi services, make sure your DNS server settings map to your enterprise DNS servers, not that of the local network to which you are connected.
Mitigating the second vulnerability, local DNS server misconfiguration, requires application of server hardware, operating system and application controls to minimize hacking vulnerabilities. This includes applying patches for operating system, kernel, and DNS application software as well as any other software running on your local DNS servers. This should be standard practice across all of your network and computing infrastructure as should denial of service mitigation approaches such as packet rate limiting.
Protection against misconfiguration requires disciplined configuration checking such as through the use of an IP address management (IPAM) system like IPControl™ from BT Diamond IP. This system greatly reduces the probability of configuration errors. Applying access controls on which users can access the servers and which systems (e.g., IPAM systems, DHCP servers) can update the DNS configuration will also reduce exposure to illicit update attempts.
The third vulnerability relates to security practices of those operating DNS servers on the Internet used to refer and resolve DNS queries for devices. This is where you have little to no control, though the root servers and most top level domain administrators exercise stringent security practices. For your own namespace, if you desire to register your domain name within a given top level domain (e.g., .bank, .diamonds, .pub, etc.), review the domain operator’s security policies to confirm a reasonable approach to mitigating attacks on their DNS servers on which you rely to accurately point to your DNS servers. Otherwise, if there are domains you don’t trust or are known malware domains that you don’t want your network users asking about, you may block them by configuring your recursive servers as DNS firewalls. We’ll discuss DNS firewalls more in Part 3.
The fourth vulnerability entails an attacker providing a seemingly valid answer to a query from your local recursive DNS server prior to the receipt of a valid legitimate answer. In this scenario, the recursive server applies a set of match criteria on the answer to map it to the original query based on parameter settings in the DNS response. If everything checks out, the recursive server will respond to the querying device and cache the answer to provide to others asking the same question. Due to the potential impact on multiple users by virtue of the caching of this data, this form of attack is known as cache poisoning. Most DNS server vendors have implemented basic steps to hinder cache poisoning, such as randomization of DNS parameters, but DNS security extensions (DNSSEC) provides the most effective protection against cache poisoning.
DNSSEC enables the signing of DNS data by the answering DNS server. This enables the recursive server to validate the signatures to confirm that the DNS data indeed originated with the domain operator in question and that the data was not manipulated en route to the recursive server. Should an attacker provide a falsified answer including all matching parameters, DNSSEC validation will disqualify the answer as invalid, even if the attacker signed the answer, unless the attacker stole the private keys of the corresponding domain owner. This risk is non-zero but should be very small, assuming domain signers secure their private keys.
IT security is a complex discipline and requires a multi-faceted approach involving defenses at the network, software, hardware, and user level. Securing DNS likewise requires application of this disciplined approach. Securing your DNS infrastructure will provide your users confidence in network and DNS availability, integrity and security. But even with a secure DNS infrastructure, if an attacker infiltrates user devices with malware to gain a foothold within your network perimeter, the core function of DNS can be put to use by attackers to conduct illicit activity within your network. We’ll discuss how to protect your DNS and your network from such attacks in Part 3 of this post.
Comments
Post a Comment