<p>Original release date: April 26, 2000<br>
  Last revised: April 26, 2000<br>
  Source: CERT/CC</p>
<p>A complete revision history is at the end of this file. </p>

<h3>Systems Affected</h3>
<ul>
  <li> Systems running various vulnerable versions of BIND (including on machines 
    where the system administrator does not realize a DNS server is running)</li>
</ul>
<h2>Overview</h2>
<p>This CERT Advisory addresses continuing compromises of machines running the 
  Domain Name System (DNS) server software that is part of BIND (&quot;named&quot;), 
  including compromises of machines that are not being used as DNS Servers. The 
  Advisory also reports that a significant number of <a
  href="#delegation">delegated</a> DNS servers in the in-addr.arpa tree are running 
  outdated versions of DNS software, and urges system and network administrators 
  to ensure that they are up-to-date with DNS security patches and workarounds.</p>
<HR WIDTH="100%">
<p>The CERT Coordination Center has received reports of continuing activity indicating 
  that intruders are targeting machines running vulnerable versions of "named" 
  . We continue to receive regular, daily reports that sites running unpatched, 
  vulnerable versions of "named" have been compromised. CERT Advisory CA-99-14 
  &quot;Multiple Vulnerabilities in BIND&quot; describes the BIND NXT record privileged 
  compromise vulnerability that is being exploited. We encourage you to review 
  this advisory and to apply the appropriate patches if you have not done so already. 
  The advisory is available at </p>
<blockquote> 
  <p> <a href="http://www.cert.org/advisories/CA-99-14-bind.html"> http://www.cert.org/advisories/CA-99-14-bind.html</a> 
  </p>
</blockquote>
<p>Some sites with compromised systems have found one of the following empty directories 
  on systems where the NXT record vulnerability was successfully exploited: </p>
<blockquote>
  <p>/var/named/ADMROCKS<br>
    /var/named/O</p>
</blockquote>
<p>Other artifacts that are commonly found include </p>
<ul>
  <li>inetd started with an intruder-supplied configuration file in /tmp that 
    provides a backdoor into the system</li>
  <li>modified /etc/inittab and/or system startup files to load intruder processes 
    at boot time</li>
  <li>Trojan horse versions of sshd and /bin/login designed to provide a backdoor 
    into a compromised system</li>
  <li>complete rootkits that include Trojan horse replacements for system binaries, 
    sniffers, denial-of-service tools, vulnerability scanners, exploits, etc.</li>
  <li>newer versions of BIND</li>
</ul>
<p>Compromised systems are commonly used to search for and attack other potentially 
  vulnerable systems.</p>
<p>In many of the reports of DNS server compromises, compromised machines running 
  DNS server software were not being used as DNS servers. The DNS server software 
  was running because it was installed by default (unknowingly in many cases) 
  when the machines were configured. This software was not up to date with security 
  patches and workarounds; and since the system administrators were not planning 
  to have the machines operate as DNS servers, they did not ensure the software 
  was up to date, or simply disable the DNS server software on the machine. We 
  encourage system and network administrators to disable DNS server software, 
  and other services, on machines where the services are not needed. </p>
<p>We have also received information from Bill Manning of the USC/ISI concerning 
  DNS servers running vulnerable versions of domain name server software. Since 
  1997, Bill Manning sweeps the inverse tree (in-addr.arpa) on a quarterly basis 
  to verify the accuracy of delegations within that hierarchy. Using the first 
  quarter survey results, he compiled a list of what version of DNS server software 
  the servers were running. Of the responding DNS servers that are <a href="#delegation">delegated</a> 
  DNS servers for the in-addr.arpa zone, more than 50% of these DNS servers were 
  running older, vulnerable versions of BIND (any vulnerabilities, not just the 
  NXT vulnerability). This is significant because the compromise of DNS servers 
  that are delegated DNS servers can have impact on the security of other organizations 
  in addition to the organization operating the DNS server.</p>
<p>A copy of the survey results are available at </p>
<blockquote> 
  <p><a href="http://www.isi.edu/%7Ebmanning/in-addr-audit.html">http://www.isi.edu/~bmanning/in-addr-audit.html</a></p>
</blockquote>
<p>Based on the number 
  of older versions being run, and the rate of compromises, we believe the number 
  of DNS servers running older, vulnerable versions of BIND have not significantly 
  decreased since the survey was published.</p>
<p>We encourage DNS server operators to ensure that their DNS server software 
  is up to date with the most recent versions of the DNS server software and that 
  all security patches and workarounds have been applied. </p>
<h2>Glossary</h2>
<p><a name="delegation"></a><b>delegated DNS server:</b> a delegated DNS is a 
  DNS server that is assigned responsibility for responding to requests for a 
  portion of the DNS hierarchy. For more information on delegation, see the section 
  on delegation in <i>DNS and BIND</i> third edition, by Paul Albitz and Cricket 
  Liu, O'Reilly and Associates, 1998.</p>
<p>&nbsp;</p>
<p><b>Advisory Author:</b> <a href="mailto:cert@cert.org?subject=CA-2000-03%20Feedback">Jeffrey 
  J. Carpenter</a></p>
<hr>
<p>The CERT Coordination Center thanks Bill Manning, USC/ISI, for providing information 
  used in this CERT Advisory. </p>
<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>


<p>Copyright 2000 Carnegie Mellon University.</p>
<p>Revision History</p>
<p>April 26, 2000: Initial release.</p>