[mod: Just to show you that people DO get bitten after a bugwarning has
gone out on linux-security..... -- REW]
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
Has anyone been hit with the Bind Inverse Query Buffer Overrun on
their Linux servers? We have had 3 servers attacked using this
expoit and all of the machines had several binaries replaced with
trojan programs. Below is the cert advisory for the exploit; but
if anyone needs details under Linux of what happens and how to fix/
protect your servers, mail me.
CERT* Advisory CA-98.05
Original issue date: April 08, 1998
Topic: Multiple Vulnerabilities in BIND
1. Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases
2. Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases
3. Denial-of-Service Vulnerability in BIND 8 Releases
- ----------------------------------------------------------------------------
I. Description
This advisory describes three distinct problems in BIND. Topic 1 describes
a vulnerability that may allow a remote intruder to gain root access on
your name server or to disrupt normal operation of your name server.
Topics
2 and 3 deal with vulnerabilities that can allow an intruder to disrupt
your name server. Detailed descriptions of each problem and its solutions
are included in the individual sections on each topic.
II. Impact
Topic 1: A remote intruder can gain root-level access to your name server.
Topics 2 and 3: A remote intruder is able to disrupt normal operation of
your name server.
III. Solution
All three problems can be fixed by upgrading to the latest version of
BIND, which may be available from your vendor (see Appendix A of this
advisory). Questions about the availability of patches from your vendor
should be directed to your vendor.
Additionally, the Internet Software Consortium will announce new
publicly available versions of BIND very soon on the BIND WWW page
(http://www.isc.org/bind.html) and on the USENET newsgroup
comp.protocols.dns.bind.
Additionally, patches are provided for Topics 1 and 3, along with steps
to take until you can apply the patch or upgrade to the latest version of
BIND.
*************************************************************************
Topic 1: Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases
*************************************************************************
1.A. Description
BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2
do not properly bounds check a memory copy when responding to an inverse
query request. An improperly or maliciously formatted inverse query on a
TCP stream can crash the server or allow an attacker to gain root
privileges.
1.B. Determining if your system is vulnerable
The inverse query feature is disabled by default, so only the systems
that have been explicitly configured to allow it are vulnerable.
BIND 8
Look at the "options" block in the configuration file
(typically
/etc/named.conf). If there is a "fake-iquery yes;" line, then
the
server is vulnerable.
BIND 4.9
Look at the "options" lines in the configuration file
(typically
/etc/named.boot). If there is a line containing "fake-iquery",
then
the server is vulnerable.
In addition, unlike BIND 8, inverse query support can be enabled when
the server is compiled. Examine conf/options.h in the source. If the
line #defining INVQ is not commented out, then the server is
vulnerable.
1.C. What To Do
To address this problem, you can disable inverse queries, upgrade to BIND
8.1.2 when it becomes available, or apply the patch provided below. We
urge you to disable inverse queries until you can take one of the other
steps.
Disabling inverse queries
-------------------------
BIND 8
Disable inverse queries by editing named.conf so that either there
is no "fake-iquery" entry in the "options" block or
the entry is
"fake-iquery no;"
BIND 4.9
Disable inverse queries by editing named.boot, removing any
"fake-iquery" entries on "options" lines. Look at
conf/options.h
in the source. If INVQ has been defined, comment it out and then
rebuild and reinstall the server.
Note: Disabling inverse query support can break ancient versions of
nslookup. If nslookup fails, replace it with a version from any
BIND 4.9 or BIND 8 distribution.
Fixing the Inverse Query Code
-----------------------------
BIND 8
Upgrade to BIND 8.1.2 when it becomes available
or apply the patch at this URL:
ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-98.05_Topic.1_BIND
8_patch.txt
This file is not PGP signed. It has the following MD5 checksum:
MD5 (CA-98.05_Topic.1_BIND8_patch.txt) =
12fc9d395ff987b1aad17a882ccd7840
BIND 4.9
Upgrade to BIND 4.9.7 when it becomes available
or apply the patch at this URL:
ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-98.05_Topic.1_BIND4
.9_patch.txt
This file is not PGP signed. It has the following MD5 checksum:
MD5 (CA-98.05_Topic.1_BIND4.9_patch.txt) =
32da0db1c27e4d484e6fcb7901267c2f
Notes:
(1) We are asking sites to retrieve the patches via FTP rather
than including them in the advisory since our experience is
that some mail handling systems translate tabs into spaces.
This prevents the patch(1) program from working properly.
(2) We have not PGP signed the files since our experience is that
some implementations of PGP during the extraction process
will strip spaces from some lines containing whitespace only.
This may prevent the patch(1) program from working properly.
**************************************************************************
Topic 2: Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases
**************************************************************************
2.A. Description
BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2
do not properly bounds check many memory references in the server and the
resolver. An improperly or maliciously formatted DNS message can cause
the server to read from invalid memory locations, yielding garbage record
data or crashing the server. Many DNS utilities that process DNS messages
(e.g., dig, nslookup) also fail to do proper bounds checking.
2.B. Determining if your system is vulnerable
Any system running BIND 4.9 prior to 4.9.7 or BIND 8 prior to 8.1.2 is
vulnerable.
2.C. What To Do
There are no workarounds for these problems.
BIND 8
Upgrade to BIND 8.1.2 when it becomes available.
BIND 4.9
Upgrade to BIND 4.9.7 when it becomes available.
**************************************************************************
Topic 3: Denial-of-Service Vulnerability in BIND 8 Releases
**************************************************************************
3.A. Description
Assume that the following self-referential resource record is in the
cache on a name server:
foo.example. IN A CNAME foo.example.
The actual domain name used does not matter; the important thing is
that the target of the CNAME is the same name. The record could be in
the cache either because the server was authoritative for it or
because the server is recursive and someone asked for it. Once this
record is in the cache, issuing a zone transfer request using its name
(e.g., "dig @my_nameserver foo.example. axfr") will cause the
server
to abort().
Most sites will not contain such a record in their configuration
files. However, it is possible for an attacker to engineer such a
record into the cache of a vulnerable nameserver and thus cause a
denial of service.
3.B. Determining if your system is vulnerable
If the BIND 8 server is not recursive and does not fetch glue, then
the problem can be exploited only if the self-referential resource
record is in a zone for which the server is authoritative.
If the global zone transfer ACL in the options block has been set to
deny access and has no self-referential CNAMEs in its authoritative
zones, then the server is not vulnerable.
Otherwise, the server is vulnerable. The nameserver is recursive by
default, fetches glue by default, and the default global transfer ACL
allows all hosts; so many BIND 8 servers will be vulnerable to this
problem.
(Note: the in.named(8) man page mentions that sending a SIGINT to the
in.named process will dump the current data base and cache to, by
default, /var/tmp/named_dump.db. Some sites may find this useful in
looking for self-referential CNAMEs. Please see the in.named(8) man
page for further details.)
3.C. What To Do
To address this problem, you can apply the workaround described below,
upgrade to BIND 8.1.2, or apply the patch provided at the end of this
section. Until you can upgrade or apply the patch, we urge you to use the
workaround.
Workaround
----------
First set the global zone transfer ACL to deny access to all hosts by
adding the following line to the "options" block:
allow-transfer { none; };
Next, explicitly authorize zone transfers for each authoritative zone.
For example, if the server was authoritative for "example",
adding
allow-transfer { any; };
to the "zone" statement for "example" would allow
anyone to transfer
"example".
None of the domains for which the server is authoritative should have
self-referential CNAMEs.
Fixing the Problem
------------------
Upgrade to BIND 8.1.2 when it becomes available or apply the patch at
the following URL to the BIND 8.1.1 source:
ftp://ftp.cert.org/pub/cert_advisories/Patches/CA-98.05_Topic.3_BIND8.1.
1_patch.txt
This file is not PGP signed. It has the following MD5 checksum:
MD5 (CA-98.05_Topic.3_BIND8.1.1_patch.txt) =
33f9dc2eaf221dd48553f490259c2a8b
Notes:
(1) We are asking sites to retrieve the patches via FTP rather
than including them in the advisory since our experience is
that some mail handling systems translate tabs into spaces.
This prevents the patch(1) program from working properly.
(2) We have not PGP signed the files since our experience is that
some implementations of PGP during the extraction process
will strip spaces from some lines containing whitespace only.
This may prevent the patch(1) program from working properly.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Appendix A - Vendor Information
Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor''s name, the CERT/CC did not hear from
that
vendor. Please contact the vendor directly.
Berkeley Software Design, Inc. (BSDI)
- -------------------------------------
1. BSD/OS 3.0/3.1 AS SHIPPED is not vulnerable.
Sites wishing to enable fake-iquery can install mod
M310-025, available at http://www.bsdi.com
2. BSDI will issue a 3.1 mod when a fix is available.
3. BSD/OS is not vulnerable, since we ship bind 4.9.6
Digital Equipment Corporation
- -----------------------------
Digital is investigating this problem.
FreeBSD, Inc.
- -------------
We ship with INVQ not defined. This makes us resistent against the first
vulnerability. This is true for all release after 2.2.0 (2.1.* releases
are vulnerable but should be upgraded anyway). As we do not yet ship
BIND 8, we are also not vulnerable to the 3rd vulnerability.
We advise everyone to upgrade to BIND 4.9.7.
Hewlett-Packard Company
- -----------------------
HP is Vulnerable. Patches in process. Watch for the release of the
associated HP Security Bulletin.
Hewlett Packard''s HP-UX patches/Security Bulletins/Security patches
are
available via email and/or WWW (via the browser of your choice) on
HP''s
Electronic Support Center (ESC).
---------------------------------------------------------------------
To subscribe to automatically receive future NEW HP Security Bulletins from
the HP ESC Digest service via electronic mail, do the following:
1) From your Web browser, access the URL:
http://us-support.external.hp.com (US,Canada,Asia-Pacific, and
Latin-America)
http://europe-support.external.hp.com (Europe)
Login with your user ID and password, or register for one (remember to save
the User ID assigned to you, and your password). Once you are on the Main
Menu, Click on the Technical Knowledge Database, and it will connect to a HP
Search Technical Knowledge DB page. Near the bottom is a hyperlink to our
Security Bulletin archive. Once in the archive there is another link to our
current security patch matrix. Updated daily, this matrix is categorized by
platform/OS release, and by bulletin topic.
To subscribe to receive future Security Bulletins be email, look for the
subscription section on the Technical Knowledge Database page.
IBM Corporation
- ---------------
The version of bind shipped with AIX is vulnerable and the following
APARs will be available soon:
AIX 4.1.x: IX76958 (fix for Topic 1 only)
AIX 4.2.x: IX76959 (fix for Topic 1 only)
AIX 4.3.x: IX76960 (fix for Topic 1 and 3 only)
AIX 4.3.x: IX76962 (fix for Topic 1, 2, and 3. This is bind 8.1.2.)
Until the official fixes are available, a temporary patch can be found
at:
ftp://aix.software.ibm.com/aix/efixes/security
File sum md5
===================================================================
named.415.tar.Z 64980 157 0e795380b84bf29385d2d946d10406cb
named.421.tar.Z 44963 157 15a9a006abf4a9d0a0d3210f16d619e5
named4.430.tar.Z 48236 115 8377b14f74e207707154a9677906f20a
named8.430.tar.Z 51175 160 e2db14b7055a7424078456bfbfd9bf2d
Detached PGP signatures are also available with a ".asc"
extension.
IBM and AIX are registered trademarks of International Business Machines
Corporation.
NEC Corporation
==============
Topic1 - Some systems are vulnerable. Patches will be available
soon, especially for UX/4800 R11.x and R13.x.
Topic2 - Some systems are vulnerable. Patches will be available
soon after the release of bind-4.9.7, especially for
UX/4800 R11.x and R13.x.
Topic3 - We do not ship BIND 8 with our products so we are not
vulnerable to this problem.
Patches will be available from ftp://ftp.meshnet.or.jp/pub/48pub/security.
The NetBSD Project
- ------------------
The first problem can be fixed in NetBSD 1.3, 1.3.1, and -current prior
to 19980408 with the supplied BIND 4.9.6 patch. A patch will be made
available for the second problem shortly (alternatively, upgrading to
BIND 4.9.7 or 8.1.2 when available will also solve this problem.) NetBSD
is not affected by the third problem.
Red Hat Software, Inc.
- ----------------------
Red Hat fixes will be available at:
Red Hat 5.0
-------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/bind-4.9.6-7.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/bind-4.9.6-7.alpha.rpm
Red Hat 4.2
-------------
i386:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/bind-4.9.6-1.1.i386.rpm
alpha:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/bind-4.9.6-1.1.alpha.rpm
SPARC:
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/bind-4.9.6-1.1.sparc.rpm
The Santa Cruz Operation, Inc.
- ------------------------------
The following SCO products are vulnerable:
- SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4
- SCO OpenServer 5.0 (also SCO Internet FastStart)
- SCO UnixWare 2.1
- SCO UnixWare 7
SCO CMW+ 3.0 is not vulnerable as BIND/named is not supported on
CMW+ platforms.
Binary versions of BIND 4.9.7 will be available shortly from the
SCO ftp site:
ftp://ftp.sco.com/SSE/sse012.ltr - cover letter
ftp://ftp.sco.com/SSE/sse012.tar.Z - replacement binaries
The fix includes binaries for the following SCO operating systems:
- SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4
- SCO OpenServer 5.0
- SCO UnixWare 2.1
- SCO UnixWare 7
For the latest security bulletins and patches for SCO products,
please refer to http://www.sco.com/security/ .
Silicon Graphics, Inc.
- ----------------------
At this time, Silicon Graphics does not have any public information for
the DNS issue. Silicon Graphics is in communication with CERT and other
external parties and is actively investigating this issue. Additional
information, is expected shortly.
When more Silicon Graphics information (including patch information) is
available for release, that information will be released via the SGI
security mailing list, wiretap.
For subscribing to the wiretap mailing list and other SGI security
related information, please refer to the Silicon Graphics Security
Headquarters website located at:
http://www.sgi.com/Support/security
Sun Microsystems, Inc.
- ----------------------
Topic 1: Patches will be produced for Solaris 5.3, 5.4, 5.5, 5.5.1
and 5.6.
Topic 2: Patches will be produced for Solaris 5.3, 5.4, 5.5, 5.5.1
and 5.6.
Topic 3: Bug fix will be integrated in the upcoming release of
Solaris.
- ----------------------------------------------------------------------------
The CERT Coordination Center thanks Bob Halley and Paul Vixie of Vixie
Enterprises, who provided most of the text of this advisory.
Reminder:
The Internet Software Consortium will announce new publicly available
versions of BIND on the BIND WWW page (http://www.isc.org/bind.html) and
on the USENET newsgroup comp.protocols.dns.bind.
- ----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (FIRST). See http://www.first.org/team-info/.
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact
the CERT staff for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
CERT Contact Information
- ------------------------
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST
(GMT-5)/EDT(GMT-4), and are on call for
emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to cert@cert.org with
"copyright" in the subject line.
* CERT is registered U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.05.bind_problems
http://www.cert.org/pub/alerts.html
- --
Peter Kelly
Email: pkelly@ETS.net - pkelly@fcp.oypi.com - pw.kelly@utoronto.ca
PGP Public key: http://www.ets.net/pkelly/pgp.html
Key fingerprint: F3 FA 53 4E AC A9 DB 6F 0A C1 1B AB 40 49 74 15
- --
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQCVAwUBNWFngu+BUx34mQ15AQE5LwP/eqAwuIPDwpFiP3nrlTwR5jhdWusHaFY8
T9YlF/YfVLmNOJnLbgA8M6YfLmcxLNdwKEhdT+kb96G+Mi8Vf0mb78yrLU0RtpgO
jWqctctjE6xvNNapAHW1E4UyiffqQ4zvu3tLrOQ33AscxXWLJ7lFW0ohByRtUOtQ
y2QTnkhE6m4=l0cY
-----END PGP SIGNATURE-----
Peter Kelly wrote:> [mod: Just to show you that people DO get bitten after a bugwarning has > gone out on linux-security..... -- REW] > > -----BEGIN PGP SIGNED MESSAGE----- > > Content-Type: text/plain; charset=us-ascii > > Has anyone been hit with the Bind Inverse Query Buffer Overrun on > their Linux servers? We have had 3 servers attacked using this > expoit and all of the machines had several binaries replaced with > trojan programs. Below is the cert advisory for the exploit; but > if anyone needs details under Linux of what happens and how to fix/ > protect your servers, mail me.I was bitten, looks like the same one too. It was a non-critical machine that was hit running un-fixed BIND''s for playing with. 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? -- Leigh
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" fromvarious>systems which no longer seem to have this. This file contained an archiveof>the trojan''s that were inserted into the compromised system - does anybodyknow>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
A recent CERT advisory said the sort of things we expect ps, pstree, netstat, ls, etc omit interesting information that you might not want to reveal. bind xterm backdoor. It has not happened to me so I do not know myself. Last time I recompiled everything from known clean source and it was *not fun*. I checked for hidden processes and stuff like that using echo * instead of ls (which is one of the most likely things to be trojanised). My ps tester should detect simple ps trojans and tell you about them, avoiding logs on the local machine. The subject looks inoccuous enough if the attacker sees it. The message content is explicit. The program will also tell you about what IP address the attacker was connected from in many cases and boot the attacker off the system (the program does not use netstat, so backdoor netstat is useless; it avoids hostnames and teels you the IP numbers and time). If the attacker is silly enough to use telnet or similar you will know the source. The process name in all versions of ps, pstree, etc is httpd. The advanatge over MD5 sums is the identification of evil processes and the genertaion of lots of perminent information from /proc. There is also an unreleased scanner that uses kill with signal 0 and compares with /proc for those that hack /proc, in addition to the normal /proc vs ps, checking. It is a simple trap and *not* a replacement for regular tripwire scans (alert attackers can easily kill it before it gets them). You can get the source by annoymous ftp from mars.astra.co.uk in the /pub/word2x directory. The code in the arhive called check-ps. Np bianries are avialable and you should compile it yourself for obviuos security reasons anyway. -- Duncan (-: "software industry, the: unique industry where selling substandard goods is legal and you can charge extra for fixing the problems."
Leigh Porter
1998-May-22 13:05 UTC
Re: [linux-security] Re: Re: Bind Overrun Bug and Linux
Duncan Simpson wrote:> A recent CERT advisory said the sort of things we expect > > ps, pstree, netstat, ls, etc omit interesting information that you might not > want to reveal. > bind xterm backdoor. > > It has not happened to me so I do not know myself. Last time I recompiled > everything from known clean source and it was *not fun*. I checked for hidden > processes and stuff like that using echo * instead of ls (which is one of the > most likely things to be trojanised).I keep a secret store of such handy things as ls, ps etc on all my systems and every night I have a process check the md5sum of every config/binary/lib on the box and report any problems to me. No it''s not fun :) -- Leigh Porter
On Tue, 19 May 1998, Leigh Porter wrote:> 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?Check the Linux RootKit ... (LRK).. Typically LRK to use config-files.. (and typically LRK-users to place files in /dev.. find /dev -type f | grep -v MAKEDEV.. examine results) ps ls top netstat ifconfig linsniff login I think those are the ones included in LRK..
Wietse Venema
1998-May-22 17:41 UTC
Re: [linux-security] Re: Re: Re: Bind Overrun Bug and Linux
Leigh Porter:> I keep a secret store of such handy things as ls, ps etc on all my systems and > every > night I have a process check the md5sum of every config/binary/lib on the box > and report any problems to me. > > No it''s not fun :)Beware, the kernel open() routine does not necessarily give you the same file as the kernel exec() routine. Your checksum does not necessarily apply to the file being executed. Wietse
Nelson Murilo
1998-May-24 21:35 UTC
Re: [linux-security] Re: Re: Re: Bind Overrun Bug and Linux
True, many ''script kids'' use rootkit''s default configurations. Usually admins don''t have time for examine many types of rootkits and variations, for this case one year ago I write one script for detect rootkits in linux and freebsd. Actualy this tools detect 4 types of rootkits in linux, 2 in freebsd and have fast updating. The official url is: ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz One variation for Demonkit (by daemon9|route) ftp://ftp.pangeia.com.br/pub/seg/pac/chkdemonkit.tar.gz Regards, -- N e l s o n M u r i l o Pangeia Informatica - Provedor de solucoes Internet. http://www.pangeia.com.br }On Sat, 23 May 1998, Shaun wrote: }}This is all LRK actually contains, from it''s readme: }}chfn: local backdoor }}chsh: local backdoor }}inetd: remote backdoor }}login: remote backdoor }}ls/du: hide files }}ifconfig: hide sniffing }}netstat: hide connections }}ps/top: hide processes }}passwd: localhost backdoor }}rshd: remote backdoor }}syslogd: hide log strings }}tcpd: avoid denials }}It also includes linsniff, and a few other log cleaner programs. }[...] }}Don''t be scared of ''configure rootkit ; make install'' kiddies, these are }}the people like ''The Analyzer'' that get caught up on becoming well known }}in the hacker community, but have no real skills. }} }}Be scared of the people that you do not see on your system, or find }}evidence of them being their, but you just know they are. } } } } }