Has Redhat patched DNS vulnerability?

From: dougga (admin@ravennasprings.com)
Date: 06/23/02


From: dougga <admin@ravennasprings.com>
Date: Sat, 22 Jun 2002 22:17:35 GMT

I'm running a DNS server locally and have seen many 'Format Errors' in the
DNS traffic. I'm wondering if the vulnerabilities described in the CERT
incident note (below) has been patched by RedHat in their updates. Does
anyone know?

THanks

~D

Post Scriptus: I'm running Redhat 7.3 with the latest kernel and all
official patches.
______________________________________________________

                      CERTŪ Incident Note IN-2001-03

                      The CERT Coordination Center publishes incident
                      notes to provide information about incidents to the
                      Internet community.

                      Exploitation of BIND Vulnerabilities

                      Date: Friday, March 30, 2001

                      On January 29, 2001 the CERT/CC published CERT
                      Advisory CA-2001-02 detailing multiple
                      vulnerabilities in multiple versions of ISC BIND
                      nameserver software. Two of the vulnerabilities
                      described in the advisory are now actively being
                      exploited by the intruder community to compromise
                      systems. In particular, these vulnerabilities are
                      being exploited:

                             VU#325431 - Queries to ISC BIND servers may
                             disclose environment variables VU#196945 -
                             ISC BIND 8 contains buffer overflow in
                             transaction signature (TSIG) handling code

                      Multiple exploits exist for multiple operating
                      system platforms, and we have seen several versions
                      of packaged kits containing exploits used by
                      intruders to automate the process of scanning for
                      and compromising vulnerable systems. At least one
                      known toolkit employs worm-like techniques designed
                      to cause the attack cycle to self-initiate on a
                      compromised host, which can result in the attack
                      propagating across multiple hosts and networks
                      without intruder interaction. To date, reports to
                      the CERT/CC indicate that successful exploitation
                      has involved hosts running Linux.

                      Attack Profile

                      In exploitations seen by the CERT/CC, the two
                      vulnerabilities in ISC BIND are used in conjunction
                      with each other during a single attack to compromise
                      a target host.

                      The exploits we have seen have the following traffic
                      pattern:

                        attacker:port -> victim:53 TCP SYN
                        victim:53 -> attacker:port TCP SYN ACK
                        attacker:port -> victim:53 TCP ACK (TCP session
                        established) attacker:port -> victim:53 UDP DNS
                        inverse query request

                      The exploit opens a TCP connection to port 53 on the
                      victim host and then sends a specially formed DNS
                      inverse query packet to the target via UDP. The
                      inverse query packet is an exploit of the BIND
                      information leak vulnerability ( VU#325431)
                      described in CERT Advisory CA-2001-02. The
                      nameserver response may vary depending on the
                      configuration of the nameserver and the influence of
                      access control mechanisms. In most cases, we have
                      seen a response in a single UDP packet back to the
                      source indicating a format error in the inverse
                      query.

                        victim:53 -> attacker:port UDP DNS inverse query
                        format error

                      The goal of exploiting the information leak
                      vulnerability is to gain information to enable an
                      exploit attempt against the BIND TSIG vulnerability
                      ( VU#196945) described in CERT Advisory CA-2001-02.

                      If the information returned in the inverse query
                      response packet indicates that the target DNS server
                      is not vulnerable to the TSIG exploit, the exploit
                      process closes the TCP connection and exits.
                      However, if the information yielded from the
                      information leak exploit indicates a vulnerable
                      BIND, the exploit process proceeds with the TSIG
                      exploit. The traffic pattern looks like this:

                        attacker:port -> victim:53 UDP (shellcode)
                        victim:53 -> attacker:port UDP DNS format error
                        attacker:port -> victim:53 TCP (payload)

                      In exploits we have seen, the shellcode is sent by
                      the exploit using UDP, causing /bin/sh to be
                      attached to the existing socket connection on port
                      53/tcp. Then, the exploit sends shell commands on
                      53/tcp for execution on the compromised host as the
                      user running the nameserver process.

                      Examples of two specific toolkits employing this
                      type of exploit are discussed below. Note, intruder
                      toolkits often change over time, so exact
                      composition and attack sequences may vary from these
                      descriptions.

                      'erkms' toolkit

                      A small number of incidents reported to the CERT/CC
                      since mid February of 2001 have involved the use of
                      a toolkit called 'erkms'. However, the incidents
                      have in total involved more than 10,000 hosts.

                      The attack portion of 'erkms' uses the following
                      tools:

                       MD5 checksum Filename
                       Filesize
                       -------------------------------------------------------
                       5899fa53c027aa2813c6adcaaf096a25 l
                       17203 ccccd7adba38b2f3ed777a398624097e m.c
                             234 40323dbe7d19e41303088f49ce6a4edd m.o
                                5535 7df70d9e426aaaeeadfb24c066d5445f
                       rscan 39621
                       3c856a7f1cfd6d22cbc32a8ccf0a796a r
                        75

                             'r' is a shell script that calls 'rscan' to
                             scan a /8 network block for TCP port 53. For
                             a victim host listening on TCP port 53 with
                             no influence from packet filtering, the
                             traffic pattern is:

                                 attacker:port -> victim:53 TCP SYN
                                 victim:53 -> attacker:port TCP SYN ACK
                                 attacker:port -> victim:53 TCP RST

                             For hosts responding on 53/tcp, 'rscan'
                             executes 'm.o', which in turn executes the
                             exploit code 'l' against the victim host (see
                             "Attack Profile" above).

                      The payload of the exploit code uses the rcp(1)
                      program to retrieve additional tools from a remote
                      distribution point. The additional tools are
                      installed on the compromised host. The tools
                      installed and used include:

                       MD5 checksum Filename
                       Filesize
                       -------------------------------------------------------
                       ffe6f1055d4bca4fb56a1124bf293c95 a
                       448 4a2149387c8b538d5b0ff65f85e08dcc net4
                        337920 60959ee2254105bfc55a2740dc1bdaab bj
                            212244 0f81ae0bcb1111f586d673a5818a8ce0 btm.c
                                  7513 007c4e98ad2ec4c26d30247e5399360a
                       btm.h 2258
                       fcc8ae5a47dcb55e27a7ca37fe7745ef fix
                       17653 f227d09f1697ebb268d36e83f54db55a go
                            1024 f2f8b75aafb1b6314b93b7a0a18fac2a ls
                               36952 662c04f1e5af11fc38a82b736644b591
                       named 579660
                       a8a65bd376f38ce3f99bed64956bdf09 netstat
                       32800 6dcd03966a893e2d38e833727cbcc35a tcpd
                           14224

                             'net4' is a trinoo distributed denial of
                             service agent, which is discussed in CERT
                             Incident Note IN-99-07. It is installed and
                             executed as '/usr/sbin/init' and a crontab
                             entry is added to restart the process. The
                             following system files are replaced with
                             intruder supplied versions:
                                   /bin/login (from 'bj') - allows
                                   backdoor connections
                                   /usr/sbin/in.telnetd (via 'btm') -
                                   allows backdoor connections
                                   /usr/sbin/in.ftpd (via 'btm') - allows
                                   backdoor connections /bin/ls (from
                                   'ls')
                                   /usr/sbin/tcpd (from 'tcpd')
                                   /bin/netstat (from 'netstat')
                                   /usr/sbin/named (from 'named')
                                   /usr/sbin/in.smb (from
                                   '/usr/sbin/in.telnetd') /etc/inetd.conf
                                   and /etc/services are both modified to
                                   cause inetd to spawn /usr/bin/in.smb
                                   for connections to TCP port 54321. The
                                   bogus service name used is 'smbd2'.
                             Trojan horse configuration information is
                             written to '/dev/hdbb' and '/dev/ptyq'.

                      '1i0n' worm

                      A growing number of incidents reported to the
                      CERT/CC since mid February of 2001 have involved the
                      use of a toolkit called '1i0n', or 'lion'. Multiple
                      versions of '1i0n' are known to exist, but in all
                      versions we have seen the same attack profile
                      described above used to exploit vulnerabilities in
                      victim hosts.

                      All known versions of '1i0n' seem to perform the
                      following similar actions via automated scripts to
                      locate and attack victim hosts.

                             A program named 'randb' is executed to select
                             a random /16 network block. 'pscan' is
                             executed to scan for TCP port 53 across the
                             random network block. The traffic pattern of
                             the scan differs from that of the 'rscan'
                             tool from 'erkms' in that a full 3-way TCP
                             handshake is completed and the connection is
                             properly terminated. For a victim host
                             listening on TCP port 53 with no influence
                             from packet filtering, the traffic pattern
                             is:

                                 attacker:port -> victim:53 TCP SYN
                                 victim:53 -> attacker:port TCP SYN ACK
                                 attacker:port -> victim:53 TCP ACK
                                 attacker:port -> victim:53 TCP FIN ACK
                                 victim:53 -> attacker:port TCP ACK
                                 victim:53 -> attacker:port TCP FIN ACK
                                 attacker:port -> victim:53 TCP ACK
                               
                               
                             For each host responding on 53/tcp, the
                             exploit code 'bind' is executed against the
                             victim host (see "Attack Profile" above).

                      The attack cycle continues through the entire /16
                      network block, at which point a new /16 network
                      block is randomly selected and the attack cycle
                      begins again.

                      The payload of the exploit code retrieves a copy of
                      the '1i0n' toolkit and installs it on the
                      compromised victim host. At that point, a new attack
                      cycle is initiated on the victim host without any
                      intruder intervention. The source of the '1i0n'
                      toolkit installed on a compromised host and the
                      composition of that toolkit may vary significantly
                      between versions. Some examples of what we have seen
                      include:

                             sensitive system information, including
                             copies of the /etc/passwd and /etc/shadow
                             files, sent via email to a remote address
                             system binaries replaced with intruder
                             supplied versions to hide intruder processes
                             and network connections, and to provide
                             backdoor privileged access system
                             configuration files altered
                             system logging facilities may be disabled and
                             log files may be destroyed installation of
                             distributed denial of service tools such as
                             Tribe Flood Network (e.g., tfn)

                      More information about '1i0n' has been published by
                      The SANS Institute.

                             http://www.sans.org/y2k/lion.htm

                      Impact

                      Intruders are using automated and self-replicating
                      toolkits to exploit known vulnerabilities in ISC
                      BIND. Exploit code is in wide public circulation.

                      Systems running vulnerable versions of ISC BIND are
                      at risk for being compromised on a widespread basis.
                      Compromised hosts are at high risk for being used to
                      attack other Internet sites, having system binaries
                      and configuration files altered, and having
                      sensitive information exposed to external parties.

                      Solution

                      The CERT/CC encourages all Internet sites to review
                      CERT Advisory CA-2001-02 and insure workarounds or
                      patches have been applied on all affected hosts on
                      your network.

                      As a good security practice, access to nameservers
                      on TCP port 53 should be restricted to trusted
                      sources only using nameserver configuration options,
                      host-based access control lists, and/or
                      network-based access control through packet
                      filtering.

                      If you believe a host under your control has been
                      compromised, you may wish to refer to

                             Steps for Recovering From a Root Compromise

                      Author(s): Kevin Houle, George Weaver, Ian Finlay



Relevant Pages

  • Has Redhat patched DNS vulnerability?
    ... I'm wondering if the vulnerabilities described in the CERT ... incident note has been patched by RedHat in their updates. ... I'm running Redhat 7.3 with the latest kernel and all ... official patches. ...
    (comp.os.linux.security)
  • Re: The Register: OpenVMS among most-secure of operating systems
    ... >> for them or patches for cert advisories (if you understand ... I apply the vendor-supplied patches after I test ... > anything that has been patched for security reasons must mean that any ...
    (comp.os.vms)
  • Re: Bind 8 bug experience
    ... > But I see the patches were made October 30. ... In fact I believe ISC have been sitting on this for almost a month. ... Members of BIND Forum were notified last week, ... We all have our little complaints about CERT now and then, ...
    (Bugtraq)
  • Re: Daylight Saving Time patches for RH 7.1/7.3
    ... to update the OS and they are running RedHat 7.1 and 7.3. ... in daylight saving time this year. ... Redhat no longer provides support that I have found and I am ... If you can't get any patches for that, ...
    (linux.redhat)
  • Re: Telnet buffer overflow
    ... I think that this came out last month and affected almost all telnets. ... that everybody put out patches for it, so I would check Sun's patches, and for ... general info on it Bugtraq or CERT. ... HTH ...
    (comp.security.unix)