Font Size Change

HOMEIT SecurityMeasures for Information Security VulnerabilitiesIPA/ISEC:Vulnerabilities:Second Security Alert for DNS Server Vulnerability

PRINT PAGE

IT Security

IPA/ISEC:Vulnerabilities:Second Security Alert for DNS Server Vulnerability

- DNS Server/Website Administrators: Apply the security patch and Revise settings immediately! –

December 19, 2008
>> JAPANESE

Information-technology Promotion Agency, Japan (IPA, Chairman Koji Nishigaki) has reissued a security alert due to the continual flow of reports concerning the DNS cache-poisoning vulnerability and the possibility that many DNS servers may contain a vulnerability of replying to outside queries by default.
IPA urges the application of the security patch to the DNS servers and server setting changes.

Not limited to business-use and home-use, internet connections always require a DNS (Domain Name System)(*1) server. In most cases, the DNS server is set up in some type of segmented system and controls all of the DNS queries to the outside entities. Problems occur when the DNS server has the vulnerability and allows false information from the outside entities to poison its information, leading to, for example, redirection to malicious websites and sending e-mail messages to malicious websites.

In July, 2008, the countermeasure information for the DNS Cache Poisoning Vulnerability was made public by the DNS server vendors(*2). When the attacking code that exploited this vulnerability was disclosed, IPA issued an emergency notification to website administrators on July 24, 2008(*3). Also, since there was a sharp increase in reports that suggested the DNS servers in operation might not have actually had the countermeasure implemented(*4), a security alert was issued on September 18, 2008(*5).

Following the publication of the security alert, reports still continued to be received concerning a wide range of DNS cache servers, including those of government agencies, local public entities and private enterprises. Furthermore, many of the DNS cache servers could have a vulnerability of replying to outside entities by default. IPA hereby reissues a security alert to website and DNS server administrators.

Website administrators should conduct a vulnerability assessment on the DNS server being used or inquire the DNS server administrator concerning the vulnerability countermeasure status. In the event that the countermeasure has not been implemented for this vulnerability, it is necessary to prompt the application of the countermeasure.

1. Countermeasure application status
of the reported DNS cache poisoning vulnerability

Figure 1 shows the number of reports concerning the DNS cache poisoning vulnerability and the countermeasure application status as of December 18, 2008. The number of reports through the end of November was a total of 666 cases. Between September and November, an average of 219 cases per month was reported. The average number of reports concerning website vulnerabilities lies in the range of 50~80 per month, emphasizing the exceptionality of the DNS cache-poisoning vulnerability reports received.

As for the current countermeasure application status, for example, of the 273 reports received in September, the DNS server administrator finished implementing the countermeasure for 66 cases, leaving 207 cases unresolved. Also, of the 213 reports received in October, 29 cases were resolved but 184 remain untreated. Though there are many who are in the midst of applying the countermeasure, there is a necessity for DNS server administrators to apply the DNS server patch and to change server settings immediately.

Figure 1: Cache-poisoning Vulnerability Report Count and Countermeasure Application Status

2. The threat of the DNS cache poisoning vulnerability

The DNS server has a mechanism that temporarily saves (caches) IP addresses retrieved, and the DNS cache server is responsible for this role.

As Figure 2 shows, when the DNS cache poisoning vulnerability is present in the DNS cache server and a malicious attack exploiting the vulnerability is executed, the internet user will become unable to connect to the proper IP address for the host name. As a result, a fake webpage could be displayed, providing an opportunity for password and credit card information to be stolen.

Also, there is a possibility that e-mail messages may be sent to fake addresses, resulting in the interception of messages or the falsification of documents.

These threats, in the event that they actually occur, have the characteristic of being extremely difficult to discern; due to the fact that, to the user, the operation is no different in comparison to the system operating in nominal conditions.

Figure 2.  Example of  DNS Cache-poisoning Threats

3. The threat of the vulnerability
of replying to queries from outside the system

The vulnerability, in which the DNS cache server responds to queries from outside of the system, is often internalized in DNS servers with the DNS cache poisoning vulnerability. Since around the year 2005, large-scale denial of service attacks exploiting this vulnerability, called the DNS amp attack(*6), have been observed(*7).

The DNS amp attack is a kind of DDoS (Distributed Denial of Service) attack and launched in combination with bots. Bots by themselves retain the capacity to send a large amount of data, but as Figure 3 shows, by exploiting the DNS cache server as a stepping stone, the data sent from the bots to the target is amplified dozens of times - resulting in the denial of service.

The DNS amp attack is done by sending DNS queries from a forged source to a DNS cache server with improper settings.

In order to prevent the DNS server from being used as a stepping stone in the attacks, it is necessary for the DNS cache server administrators to properly establish the range of service provided, and set to respond only to those whom should be receiving service.

Figure 3.  Attack exploiting improper DNS server settings

4. Investigation and countermeasure methods
for systems affected by the vulnerability

4.1 Systems Affected

Refer to the “Affected Products” section of the vulnerability countermeasure information database (JVN iPedia) advisory, “DNS Cache Poisoning Vulnerability in Multiple DNS Products”, at the following URL:
http://jvndb.jvn.jp/ja/contents/2008/JVNDB-2008-001495.html (in Japanese)

4.2 How to check for the vulnerability

Refer to the “3. How to check for the vulnerability” section of the “Security Alert for DNS Cache Poisoning Vulnerability” at the following URL:
http://www.ipa.go.jp/security/english/vuln/200809_DNS_en.html

4.3 Countermeasure methods for the vulnerability

(1) DNS cache poisoning vulnerability countermeasure

Refer to the “Countermeasure” section of the emergency notification for the “DNS Cache-Poisoning Vulnerability in Multiple DNS Products” at the following URL and apply the patch, while also revising the current settings.
http://www.ipa.go.jp/security/ciadr/vul/20080724-dns.html (in Japanese)

(2) DNS server security countermeasure

Depending on its function, the DNS server could be either a DNS content server or a DNS cache server. In some cases, one DNS server has both functions. As a security measure, it is necessity to configure these servers properly.

For instance, as Figure 4 shows, allow the client to refer to the internal DNS cache server only, and configure the internal DNS cache server to send repetitive queries to the external DNS content server when it cannot resolve the name. Also, place the external DNS content server in the DMZ(*8) and configure it so it does not respond to recursive queries.

Especially, some DNS server software, such as BIND and the Windows DNS service, function as cache servers when started, and they may be exploited as stepping stones for the attack because most initial settings do not limit recursive queries. To prevent attacks, it is necessary to configure the DNS content server not to accept recursive queries.

Also, it is necessary for the DNS servers used as cache servers to be configured to limit the acceptance range of recursive queries to internal users only, or to set the same type of limitations on the network level.

Figure 4.  Security Measures for DNS Servers

Footnote

(*1)A mechanism that transforms an IP address, a set of numbers that represents the location of a computer on the network of networks, into a human-friendly domain name such as www.ipa.go.jp.

(*2)Refer to the following advisory in JVN iPedia:
DNS Cache Poisoning Vulnerability in Multiple DNS Products
http://jvndb.jvn.jp/ja/contents/2008/JVNDB-2008-001495.html (in Japanese)

(*3)DNS Cache Poisoning Vulnerability in Multiple DNS Products
http://www.ipa.go.jp/security/ciadr/vul/20080724-dns.html (in Japanese)

(*4)Under the national software vulnerability reporting scheme pursuant to a METI Directive, IPA has been collecting and analyzing reports on vulnerabilities and JPCERT/CC has been coordinating the response with relevant players such as product vendors since July 2007.

(*5)Security Alert for DNS Cache Poisoning Vulnerability
http://www.ipa.go.jp/security/english/vuln/200809_DNS_en.html

(*6)A kind of DoS (Denial of Service) attack and exploits DNS cache servers with improper settings as stepping stone. Combined with bots, it is used in DDoS (Distributed Denial of Service) attacks.

(*7)JPCERT/CC: Distributed Denial of Service Attacks using Recursive DNS Queries
https://www.jpcert.or.jp/at/2006/at060004.txt (in Japanese)

JPRS: Distributed Denial of Service Attacks using Recursive DNS Queries
http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html (in Japanese)

Metropolitan Police Department: Distributed Denial of Service Attacks using Recursive DNS Queries
http://www.cyberpolice.go.jp/detect/pdf/20060711_DNS-DDoS.pdf (in Japanese)

(*8)Demilitarized Zone: An externally-exposed segment of an internet-connected network that is separated from both the outside network (the Internet) and inside network (the intranet) by firewalls. By placing the servers that need to connect the outside network in the DMZ, unauthorized access from the outside network is expected to be prevented by the firewalls.

Contact

IT Security Center,
Information-technology Promotion Agency, Japan (ISEC/IPA)
E-mail: