Has Redhat patched DNS vulnerability?
From: dougga (admin@ravennasprings.com)Date: 06/23/02
- Next message: Kasper Dupont: "Re: OpenSSH, privilage separation"
- Previous message: RainbowHat: "Re: double the buffer? - buffer overflows"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
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
- Next message: Kasper Dupont: "Re: OpenSSH, privilage separation"
- Previous message: RainbowHat: "Re: double the buffer? - buffer overflows"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
