[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [linux-security] Re: Bind Overrun Bug and Linux
- From: Lamar Owen <lamar owen wgcr org>
- To: linux-security redhat com
- Subject: Re: [linux-security] Re: Bind Overrun Bug and Linux
- Date: Thu, 21 May 1998 17:33:59 -0400
Leigh Porter Wrote
>Peter Kelly wrote:
>
>> [mod: Just to show you that people DO get bitten after a bugwarning has
>> gone out on linux-security..... -- REW]
I did not receive the warning on Linux-security or on linux-alerts. I found
the info in the RedHat errata. The info on the BIND-4.9.6 overrun is not
(as of yesterday) on the linux-security and linux-alert websites. However,
CERT maintains a mailing list -- I suggest everyone on this list also
subscribe to the CERT list.
>It seems that the purpotrator used ncftp to get a file called "hide" from
various
>systems which no longer seem to have this. This file contained an archive
of
>the trojan's that were inserted into the compromised system - does anybody
know
>what is in these trojans?
Excerpting the mail I received from CERT (which, incidentally, contained a
_wealth_ of information):
<---BEGIN EXCERPT from CERT/CC----->
It appears that the intruder is exploiting a vulnerability in the
domain name service to:
* telnet to a compromised host on port 666
* obtain an intruder tool archive named "hide" via ncftp
* unpack and install the contents of the "hide" archive
[...SNIP...]
The "hide" archive includes the following Trojan horse programs:
ifconfig, inetd, ls, named, netstat, ps, pstree, syslogd, tcpd, top
The Trojan horse "named" program appears to contain a backdoor that
will allow the intruder to open an xterm window from the compromised
host back to the intruder's system. If any of the other programs were
installed, they cannot be relied upon to provide accurate information
about processes, network connections, or files present on the system.
The archive also includes several other intruder tools and
configuration files including:
/dev/reset, /dev/pmcf1, /dev/pmcf2, /dev/pmcf3, /dev/pmcf4, fix
The /dev/reset program appears to be a sniffer program that captures
and logs cleartext passwords transmitted over the local area network.
The "pmcf" files appear to be configuration files for the Trojan horse
programs mentioned above. The "fix" program is run by the
installation script, and appears to install the Trojan horse programs.
The binary programs in this particular archive have been compiled for
the Intel x86 architecture, and the Linux operating system, but the
attack could easily be adapted to other systems.
[SNIP]
Suggestions for detecting this specific activity include:
* Compare the MD5 checksums for the files listed above with the MD5
checksums from versions that are known to be correct.
* Look for the sniffer program "/dev/reset", the "/dev/pmcf*"
configuration files and the sniffer output file, which appears to
be "/usr/lib/libsn.a".
* Check to see if your system log contains messages like:
May 1 11:28:49 <hostname> named[28464]: starting. named
LOCAL-980501.020913 Fri May 1 02:09:13 EDT 1998
^Iroot@<hostname>:/usr/lib/tntbot/bind/named
* Investigate any unexpected crashes or restarts of the named and
inetd daemons occurring recently, especially on April 27th, or May
1st 1998. The intruder's installation script kills these daemons
and then restarts them with the new Trojan horse versions. We
have received reports of this activity occurring on the two dates
mentioned, but unexpected restarts occurring at other times may
indicate a compromise as well.
* Examine core dumps from recently crashed DNS servers. Some of the
sites attacked have reported that their core files contain
portions of the exploit script used in this attack. Sites who
have reported such crashes appear to be running operating systems
other than Linux, and the intruder may not have finished
installing the Trojan horse programs.
* The .ncftp file in root's home directory may contain information
showing unexpected ftp file transfers.
<-----END EXCERPT------>
CERT found my site name in the ftp log of a compromised system about two
weeks after the compromise (not a bad response time, IMO). I had already
found and squashed the attack using info in the /var/log/messages file,
after my users started hollering about not being able to use "the
Internet" -- my nameserver completely crashed because of the attack.
NOTE: The file timestamps for the affected files are not changed from what
they should be. Using rpm --upgrade --force on the affected packages helped,
until I upgraded to RedHat 5 a few days later, at which point I installed
all relevant security patches (lesson learned).
Lamar Owen
WGCR Internet Radio
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]