NODE 920a30b2CERT advisory
"Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>Fri, 4 Feb 94 10:29:52 PST
[Some items of interest to C-punks include CERT's advocacy of stopping
cleartext transmission of password (no shit sherlock), and their proposed
solutions, including the use of one-time passwords which I had queried about
on this list a few months back. Of course they don't mention any sort of
real encryption, let alone PGP. How hard would it be to build in PGP
security to the transmission layer of something like FTP? Seems like a
fairly simple problem, given that any site which supports anonymous FTP can
publish a public key. Even if we assume that encryption would slow down the
file transmission too much, we could still use it for the
login/authentication part of the session... --AW]
Begin forwarded message:
From: CERT Advisory <cert-advisory-request@cert.org>
Date: Thu, 3 Feb 94 21:14:40 EST
To: cert-advisory@cert.org
Subject: CERT Advisory - Ongoing Network Monitoring Attacks
Organization: Computer Emergency Response Team : 412-268-7090
=============================================================================
CA-94:01 CERT Advisory
February 3, 1994
Ongoing Network Monitoring Attacks
-----------------------------------------------------------------------------
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
advisories, which are available anonymous FTP from
info.cert.org).
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 info.cert.org in the
/pub/tools/cpm directory or on ftp.uu.net in the
/pub/security/cpm 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 C 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. CERT has collected some
information on relevant technologies. This information is
included as Appendix B in this advisory. Note: These
solutions will not protect against transient or remote access
transmission of clear-text passwords through the network.
Until everyone connected to your network is using the above
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. See
Appendix A of this advisory for help with recovery.
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
Coordination Center or your representative in Forum of Incident
Response and Security Teams (FIRST).
Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous
FTP from info.cert.org.
---------------------------------------------------------------------------
Appendix A:
RECOVERING FROM A UNIX ROOT COMPROMISE
A. Immediate recovery technique
1) Disconnect from the network or operate the system in
single- user mode during the recovery. This will keep users
and intruders from accessing the system.
2) Verify system binaries and configuration files against the
vendor's media (do not rely on timestamp information to
provide an indication of modification). Do not trust any
verification tool such as cmp(1) located on the compromised
system as it, too, may have been modified by the intruder.
In addition, do not trust the results of the standard UNIX
sum(1) program as we have seen intruders modify system
files in such a way that the checksums remain the same.
Replace any modified files from the vendor's media, not
from backups.
-- or --
Reload your system from the vendor's media.
3) Search the system for new or modified setuid root files.
find / -user root -perm -4000 -print
If you are using NFS or AFS file systems, use ncheck to
search the local file systems.
ncheck -s /dev/sd0a
4) Change the password on all accounts.
5) Don't trust your backups for reloading any file used by
root. You do not want to re-introduce files altered by an
intruder.
B. Improving the security of your system
1) CERT Security Checklist
Using the checklist will help you identify security
weaknesses or modifications to your systems. The CERT
Security Checklist is based on information gained from
computer security incidents reported to CERT. It is
available via anonymous FTP from info.cert.org in the file
pub/tech_tips/security_info.
2) Security Tools
Use security tools such as COPS and Tripwire to check for
security configuration weaknesses and for modifications
made by intruders. We suggest storing these security
tools, their configuration files, and databases offline or
encrypted. TCP daemon wrapper programs provide additional
logging and access control. These tools are available via
anonymous FTP from info.cert.org in the pub/tools
directory.
3) CERT Advisories
Review past CERT advisories (both vendor-specific and
generic) and install all appropriate patches or workarounds
as described in the advisories. CERT advisories and other
security-related information are available via anonymous
FTP from info.cert.org in the pub/cert_advisories
directory.
To join the CERT Advisory mailing list, send a request to:
cert-advisory-request@cert.org
Please include contact information, including a telephone number.
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Copyright (c) Carnegie Mellon University 1994
---------------------------------------------------------------------------
Appendix B:
ONE-TIME PASSWORDS
Given today's networked environments, CERT recommends that sites
concerned about the security and integrity of their systems and
networks consider moving away from standard, reusable passwords. CERT
has seen many incidents involving Trojan network programs (e.g.,
telnet and rlogin) and network packet sniffing programs. These
programs capture clear-text hostname, account name, password triplets.
Intruders can use the captured information for subsequent access to
those hosts and accounts. This is possible because 1) the password is
used over and over (hence the term "reusable"), and 2) the password
passes across the network in clear text.
Several authentication techniques have been developed that address
this problem. Among these techniques are challenge-response
technologies that provide passwords that are only used once (commonly
called one-time passwords). This document provides a list of sources
for products that provide this capability. The decision to use a
product is the responsibility of each organization, and each
organization should perform its own evaluation and selection.
I. Public Domain packages
S/KEY(TM)
The S/KEY package is publicly available (no fee) via
anonymous FTP from:
thumper.bellcore.com /pub/nmh directory
There are three subdirectories:
skey UNIX code and documents on S/KEY.
Includes the change needed to login,
and stand-alone commands (such as "key"),
that computes the one-time password for
the user, given the secret password and
the S/KEY command.
dos DOS or DOS/WINDOWS S/KEY programs. Includes
DOS version of "key" and "termkey" which is
a TSR program.
mac One-time password calculation utility for
the Mac.
II. Commercial Products
Secure Net Key (SNK) (Do-it-yourself project)
Digital Pathways, Inc.
201 Ravendale Dr.
Mountainview, Ca. 94043-5216
USA
Phone: 415-964-0707
Fax: (415) 961-7487
Products:
handheld authentication calculators (SNK004)
serial line auth interruptors (guardian)
Note: Secure Net Key (SNK) is des-based, and therefore restricted
from US export.
Secure ID (complete turnkey systems)
Security Dynamics
One Alewife Center
Cambridge, MA 02140-2312
USA
Phone: 617-547-7820
Fax: (617) 354-8836
Products:
SecurID changing number authentication card
ACE server software
SecureID is time-synchronized using a 'proprietary' number
generation algorithm
WatchWord and WatchWord II
Racal-Guardata
480 Spring Park Place
Herndon, VA 22070
703-471-0892
1-800-521-6261 ext 217
Products:
Watchword authentication calculator
Encrypting modems
Alpha-numeric keypad, digital signature capability
SafeWord
Enigma Logic, Inc.
2151 Salvio #301
Concord, CA 94520
510-827-5707
Fax: (510)827-2593
Products:
DES Silver card authentication calculator
SafeWord Multisync card authentication calculator
Available for UNIX, VMS, MVS, MS-DOS, Tandum, Stratus, as well as
other OS versions. Supports one-time passwords and super
smartcards from several vendors.
---------------------------------------------------------------------------
Appendix C:
cpm 1.0 README FILE
cpm - check for network interfaces in promiscuous mode.
Copyright (c) Carnegie Mellon University 1994
Thursday Feb 3 1994
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
This program is free software; you can distribute it and/or modify
it as long as you retain the Carnegie Mellon copyright statement.
It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z.
This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED
WARRANTY of merchantability or fitness for a particular purpose.
This package contains:
README
MANIFEST
cpm.1
cpm.c
To create cpm under SunOS, type:
% cc -Bstatic -o cpm cpm.c
On machines that support dynamic loading, such as Sun's, CERT recommends
that programs be statically linked so that this feature is disabled.
CERT recommends that after you install cpm in your favorite directory,
you take measures to ensure the integrity of the program by noting
the size and checksums of the source code and resulting binary.
The following is an example of the output of cpm and its exit status.
Running cpm on a machine where both the le0 and le2 interfaces are
in promiscuous mode, under csh(1):
% cpm
le0
le2
% echo $status
2
%
Running cpm on a machine where no interfaces are in promiscuous
mode, under csh(1):
% cpm
% echo $status
0
%
NODE 1ed7cc64Re: CERT advisory
Marc W. Mengel <mengel@dcdmwm.fnal.gov>Fri, 4 Feb 94 15:29:56 PST
In <9402041825.AA27913@media.mit.edu> you write:
[Some items of interest to C-punks include CERT's advocacy of stopping
cleartext transmission of password (no shit sherlock), and their proposed
solutions, including the use of one-time passwords which I had queried about
on this list a few months back. Of course they don't mention any sort of
real encryption, let alone PGP. How hard would it be to build in PGP
security to the transmission layer of something like FTP? Seems like a
fairly simple problem, given that any site which supports anonymous FTP can
publish a public key. Even if we assume that encryption would slow down the
file transmission too much, we could still use it for the
login/authentication part of the session... --AW]
Since the command channel is flat ascii, one could extend the protocol
with a pgp-password command, which would send the password encrypted in the
server's public key. Similarly one could use the sort of convention that
the wu-ftpd does to request encrypted files... simply request file.pgp,
just like you request file.z, file.gz, etc.
Of course, there really *ought* to be an RFC for it, but I'm thinking
something like a command
666 PGPL
-----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----
which would send an encrypted login and password.
The other piece to hack up would be the ftp client, it would have to
ask for your login/password on the ftp server host, then crank that
through pgp, and send an ELOGIN command down the socket -- no problem.
The big issue, in my mind, is how the ftpd is going to get the key
to unlock the *system's* private key... Do you compile it into the
code? Should ftpd ask for it when it comes up?
Marc
NODE c3a6d5e7Re: CERT advisory
Brad Huntting <huntting@glarp.com>Fri, 4 Feb 94 16:19:57 PST
> Since the command channel is flat ascii, one could extend the protocol
> with a pgp-password command, which would send the password encrypted in the
> server's public key. Similarly one could use the sort of convention that
> the wu-ftpd does to request encrypted files... simply request file.pgp,
> just like you request file.z, file.gz, etc.
There is an Internet draft (draft-ietf-cat-ftpsec-03.txt) on ftp
encription and authentication extensions. I dont recall if it
includes a public key method, but if not it would probably be easy
to incorporate.
brad
NODE 728812acCERT advisory
hughes@ah.com (Eric Hughes)Fri, 4 Feb 94 16:59:57 PST
>The big issue, in my mind, is how the ftpd is going to get the key
>to unlock the *system's* private key... Do you compile it into the
>code? Should ftpd ask for it when it comes up?
Since active interception is not nearly so easy as passive listening,
it would be appropriate to use a Diffie-Hellman key exchange in this
situation. This protocol has no persistent private keys, so the issue
of keeping a private key around securely is not an issue.
Eric
NODE ddbb76edRe: CERT advisory
rcain@netcom.com (Robert Cain)Sat, 5 Feb 94 11:45:41 PST
Eric Hughes sez:
>
> Since active interception is not nearly so easy as passive listening,
This isn't true of anything but the aether itself or a point to point
wire with integrity. In any switched or networked system with routing,
active interception is trivial. That is why D-H has a lower level
of applicability than generally considered.
> it would be appropriate to use a Diffie-Hellman key exchange in this
> situation. This protocol has no persistent private keys, so the issue
> of keeping a private key around securely is not an issue.
Yes, the one time key usage is an important factor in the D-H.
Nothing can be determined from one session that will help in
breaking another.
Peace,
Bob
--
Bob Cain rcain@netcom.com 408-354-8021
"I used to be different. But now I'm the same."
--------------PGP 1.0 or 2.0 public key available on request.------------------
NODE 78c30c93CERT advisory
hughes@ah.com (Eric Hughes)Sat, 5 Feb 94 19:45:49 PST
>> Since active interception is not nearly so easy as passive listening,
>This isn't true of anything but the aether itself or a point to point
>wire with integrity. In any switched or networked system with routing,
>active interception is trivial.
Possible? Yes.
Trivial? Bullshit.
It's all economics, and the resources required to intercept packets
and spoof protocols is significantly greater than that merely to watch
packets go by. There are many fewer people with these greater
resources, which include access to routers.
Both active and passive attacks are possible in a packet forwarding
system. Merely because both are possible does not mean that they are
the same.
D-H is not a panacea, but its use for password transmission would
completely solve the Ethernet sniffing problem. That alone indicates
that active and passive attacks are different in nature and in the
defences appropriate.
D-H doesn't require any prearranged keying material, which is its
primary advantage against passive attacks. Since distribution and
storage of keying material is an as-yet pragmatically unsolved
problem, it is unwise to insist upon prearranged keys when a partial
solution, D-H, is available immediately.
Eric
NODE 9de5f43dRe: CERT advisory
rcain@netcom.com (Robert Cain)Tue, 8 Feb 94 15:47:03 PST
Eric Hughes sez:
>
> Since distribution and
> storage of keying material is an as-yet pragmatically unsolved
> problem, it is unwise to insist upon prearranged keys when a partial
> solution, D-H, is available immediately.
I (and some others with credentials) think I have solved it. I wish
I could be more specific and will be as soon as I can with the idea under
some form of protection. As soon as I file, cypherpunks will be the
first to get the details. I am not no much trying to be a tease as to
tease out any possible solutions to this that I may not be aware of.
sci.crypt is not the place for unsubstantiated claims and I hope for
a bit more tolerance here. We are on the same side, I just wish to
profit from it so I can bankroll a few backlogged ideas. Bootstraping
is a bitch. :-)
Peace,
Bob
--
Bob Cain rcain@netcom.com 408-354-8021
"I used to be different. But now I'm the same."
--------------PGP 1.0 or 2.0 public key available on request.------------------
NODE 0cf425f4CERT advisory
"Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>Fri, 4 Feb 94 21:35:20 PST
My instant opinion is that the private key for a site/machine has to be held
by that site/machine's administrator. Therefore, the ftpd would need to get
the private key entered at startup time.
--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard
Media Lab - Advanced Human Interface Group wex@media.mit.edu
Voice: 617-258-9168 Page: 617-945-1842 an53607@anon.penet.fi
All the world's a stage and most of us are desperately unrehearsed.