exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

S-94-02.asc

S-94-02.asc
Posted Jan 10, 2000

Subject Ongoing Network Monitoring Attacks Date 04-Feb-94

SHA-256 | dc74b72c271c407a9dacdb97c53a280b341e04a8241fb427d3029568454d9276

S-94-02.asc

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>> CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl. Links <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>> <<
>> CERT-NL also has stopped the CERT-CC-Mirror service. Due to this the <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the <<
>> complete CERT-CC advisory texts: http://www.cert.org <<
===============================================================================
===============================================================================
Security Advisory CERT-NL
===============================================================================
Author/Source : CERT-NL (Nico de Koo) Index : S-94-02
Distribution : World Page : 1
Classification: External Version: Final
Subject : Ongoing Network Monitoring Attacks Date : 04-Feb-94
===============================================================================

CERT-NL received information about Ongoing Network Monitoring Attacks.

All Internet connected systems may suffer damage from these attacks.

Systems running SunOS 4.x (Sun3 and Sun4) and Solbourne systems may carry
the hacked software.

We advise you to carefully read this advisory and take appropriate action.

We thank CERT/CC for providing this information.

=============================================================================

In the past week, CERT has observed a dramatic increase in reports of
intruders monitoring network traffic. Systems of some service
providers have been compromised, and all systems that offer remote
access through rlogin, telnet, and FTP are at risk. Intruders have
already captured access information for tens of thousands of systems
across the Internet.

The current attacks involve a network monitoring tool that uses the
promiscuous mode of a specific network interface, /dev/nit, to capture
host and user authentication information on all newly opened FTP,
telnet, and rlogin sessions.

In the short-term, CERT recommends that all users on sites that offer
remote access change passwords on any network-accessed account. In
addition, all sites having systems that support the /dev/nit interface
should disable this feature if it is not used and attempt to prevent
unauthorized access if the feature is necessary. A procedure for
accomplishing this is described in Section III.B.2 below. Systems
known to support the interface are SunOS 4.x (Sun3 and Sun4
architectures) and Solbourne systems; there may be others. Sun Solaris
systems do not support the /dev/nit interface. If you have a system
other than Sun or Solbourne, contact your vendor to find if this
interface is supported.

While the current attack is specific to /dev/nit, the short-term
workaround does not constitute a solution. The best long-term
solution currently available for this attack is to reduce or eliminate
the transmission of reusable passwords in clear-text over the network.


- -----------------------------------------------------------------------------

I. Description

Root-compromised systems that support a promiscuous network
interface are being used by intruders to collect host and user
authentication information visible on the network.

The intruders first penetrate a system and gain root access
through an unpatched vulnerability (solutions and workarounds for
these vulnerabilities have been described in previous CERT-NL
advisories, which are available anonymous FTP from
ftp.nic.surfnet.nl).

The intruders then run a network monitoring tool that captures up
to the first 128 keystrokes of all newly opened FTP, telnet, and
rlogin sessions visible within the compromised system's domain.
These keystrokes usually contain host, account, and password
information for user accounts on other systems; the intruders log
these for later retrieval. The intruders typically install
Trojan horse programs to support subsequent access to the
compromised system and to hide their network monitoring process.

II. Impact

All connected network sites that use the network to access remote
systems are at risk from this attack.

All user account and password information derived from FTP,
telnet, and rlogin sessions and passing through the same network
as the compromised host could be disclosed.


III. Approach

There are three steps in CERT's recommended approach to the
problem:

- Detect if the network monitoring tool is running on any of your
hosts that support a promiscuous network interface.

- Protect against this attack either by disabling the network
interface for those systems that do not use this feature or by
attempting to prevent unauthorized use of the feature on systems
where this interface is necessary.

- Scope the extent of the attack and recover in the event that
the network monitoring tool is discovered.


A. Detection

The network monitoring tool can be run under a variety of
process names and log to a variety of filenames. Thus, the
best method for detecting the tool is to look for 1) Trojan
horse programs commonly used in conjunction with this attack,
2) any suspect processes running on the system, and 3) the
unauthorized use of /dev/nit.

1) Trojan horse programs:

The intruders have been found to replace one or more of the
following programs with a Trojan horse version in conjunction
with this attack:

/usr/etc/in.telnetd
and /bin/login - Used to provide back-door access for the
intruders to retrieve information
/bin/ps - Used to disguise the network monitoring process

Because the intruders install Trojan horse variations of
standard UNIX commands, CERT recommends not using other
commands such as the standard UNIX sum(1) or cmp(1) commands
to locate the Trojan horse programs on the system until these
programs can be restored from distribution media, run from
read-only media (such as a mounted CD-ROM), or verified using
cryptographic checksum information.

In addition to the possibility of having the checksum
programs replaced by the intruders, the Trojan horse programs
mentioned above may have been engineered to produce the same
standard checksum and timestamp as the legitimate version.
Because of this, the standard UNIX sum(1) command and the
timestamps associated with the programs are not sufficient to
determine whether the programs have been replaced.

CERT recommends that you use both the /usr/5bin/sum and
/bin/sum commands to compare against the distribution media
and assure that the programs have not been replaced. The use
of cmp(1), MD5, Tripwire (only if the baseline checksums were
created on a distribution system), and other cryptographic
checksum tools are also sufficient to detect these Trojan
horse programs, provided these programs were not available
for modification by the intruder. If the distribution is
available on CD-ROM or other read-only device, it may be
possible to compare against these volumes or run programs off
these media.

2) Suspect processes:

Although the name of the network monitoring tool can vary
from attack to attack, it is possible to detect a suspect
process running as root using ps(1) or other process-listing
commands. Until the ps(1) command has been verified against
distribution media, it should not be relied upon--a Trojan
horse version is being used by the intruders to hide the
monitoring process. Some process names that have been
observed are sendmail, es, and in.netd. The arguments to the
process also provide an indication of where the log file is
located. If the "-F" flag is set on the process, the
filename following indicates the location of the log file
used for the collection of authentication information for
later retrieval by the intruders.

3) Unauthorized use of /dev/nit:

If the network monitoring tool is currently running on your
system, it is possible to detect this by checking for
unauthorized use of the /dev/nit interface. CERT has created
a minimal tool for this purpose. The source code for this
tool is available via anonymous FTP on ftp.nic.surfnet.nl in the
surfnet/net-security/tools directory as cpm.1.0.tar.Z.
The checksum information is:

Filename Standard UNIX Sum System V Sum
-------------- ----------------- ------------
cpm.1.0.tar.Z: 11097 6 24453 12

MD5 Checksum
MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155

This archive contains a readme file, also included as
Appendix A of this advisory, containing instructions on
installing and using this detection tool.

B. Prevention

There are two actions that are effective in preventing this
attack. A long-term solution requires eliminating
transmission of clear-text passwords on the network. For
this specific attack, however, a short-term workaround
exists. Both of these are described below.

1) Long-term prevention:

CERT recognizes that the only effective long-term solution to
prevent these attacks is by not transmitting reusable
clear-text passwords on the network.

Until everyone connected to your network is using the right
technologies, your policy should allow only authorized users
and programs access to promiscuous network interfaces. The
tool described in Section III.A.3 above may be helpful in
verifying this restricted access.

2) Short-term workaround:

Regardless of whether the network monitoring software is
detected on your system, CERT recommends that ALL SITES take
action to prevent unauthorized network monitoring on their
systems. You can do this either by removing the interface, if
it is not used on the system or by attempting to prevent the
misuse of this interface.

For systems other than Sun and Solbourne, contact your vendor
to find out if promiscuous mode network access is supported
and, if so, what is the recommended method to disable or
monitor this feature.

For SunOS 4.x and Solbourne systems, the promiscuous
interface to the network can be eliminated by removing the
/dev/nit capability from the kernel. The procedure for doing
so is outlined below (see your system manuals for more
details). Once the procedure is complete, you may remove the
device file /dev/nit since it is no longer functional.

Procedure for removing /dev/nit from the kernel:

1. Become root on the system.

2. Apply "method 1" as outlined in the System and Network
Administration manual, in the section, "Sun System
Administration Procedures," Chapter 9, "Reconfiguring the
System Kernel." Excerpts from the method are reproduced
below:

# cd /usr/kvm/sys/sun[3,3x,4,4c]/conf
# cp CONFIG_FILE SYS_NAME

[Note that at this step, you should replace the CONFIG_FILE
with your system specific configuration file if one exists.]

# chmod +w SYS_NAME
# vi SYS_NAME

#
# The following are for streams NIT support. NIT is used by
# etherfind, traffic, rarpd, and ndbootd. As a rule of thumb,
# NIT is almost always needed on a server and almost never
# needed on a diskless client.
#
pseudo-device snit # streams NIT
pseudo-device pf # packet filter
pseudo-device nbuf # NIT buffering module

[Comment out the preceding three lines; save and exit the
editor before proceeding.]

# config SYS_NAME
# cd ../SYS_NAME
# make

# mv /vmunix /vmunix.old
# cp vmunix /vmunix

# /etc/halt
> b

[This step will reboot the system with the new kernel.]

[NOTE that even after the new kernel is installed, you need
to take care to ensure that the previous vmunix.old , or
other kernel, is not used to reboot the system.]


C. Scope and recovery

If you detect the network monitoring software at your site,
CERT recommends following three steps to successfully
determine the scope of the problem and to recover from this
attack.

1. Restore the system that was subjected to the network
monitoring software.

The systems on which the network monitoring and/or Trojan
horse programs are found have been compromised at the root
level; your system configuration may have been altered.

2. Consider changing router, server, and privileged account
passwords due to the wide-spread nature of these attacks.

Since this threat involves monitoring remote connections,
take care to change these passwords using some mechanism
other than remote telnet, rlogin, or FTP access.

3. Urge users to change passwords on local and remote
accounts.

Users who access accounts using telnet, rlogin, or FTP either
to or from systems within the compromised domain should
change their passwords after the intruder's network monitor
has been disabled.

4. Notify remote sites connected from or through the local
domain of the network compromise.

Encourage the remote sites to check their systems for
unauthorized activity. Be aware that if your site routes
network traffic between external domains, both of these
domains may have been compromised by the network monitoring
software.


- ---------------------------------------------------------------------------
The CERT Coordination Center thanks the members of the FIRST community
as well as the many technical experts around the Internet who
participated in creating this advisory. Special thanks to Eugene
Spafford of Purdue University for his contributions.
- ---------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT-NL
or your local site security contact.
(FIRST).

==============================================================================
CERT-NL is the Computer Emergency Response Team, located in The
Netherlands. CERT-NL is a Full Member of the Forum of Incident Response
and Security Teams (FIRST). The constituency of CERT-NL are the SURFnet
connected institutions.

Past CERT-NL Security Bulletins and other CERT-NL related material can
be found on the anonymous FTP server of SURFnet bv:
"ftp.nic.surfnet.nl" [192.87.46.3], in the directory
"surfnet/net-security/cert-nl/docs/bulletin". This information is also
available using email. Send an email saying "help" to
"mailserv@nic.surfnet.nl".

In case of computer or network security problems please contact CERT-NL
or the CERT of your own constituency. Please be aware of the fact that
we are one (when DST is in effect two) hour(s) ahead of Universal Time
Coordinated (i.e. UTC+0100 (UTC+0200)).
Email: cert-nl@surfnet.nl
Phone: +31 30 310290
Fax: +31 30 340903
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands
A 7 * 24 hours phone number is available to SURFnet SSC's and FIRST
members on request.
==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS
Phone: +31 302 305 305 BUSINESS HOURS ONLY
Fax: +31 302 305 329 BUSINESS HOURS ONLY
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands

NOODGEVALLEN: 06 22 92 35 64 ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64 ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6WDjSYjBqwfc9jEQKplgCggvjMbzOVcNQTsPQOmrGsYeQ6utMAn1ZB
mcDrO3/YKc9E6pNaOu+CM5yv
=c9V9
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close