There were a few people who wanted me to summarize because they had seen the same problem.
One person suggested I send the problem to CERT, I did and eventually got a response.
My original post to cert:
The folowing is a message that I sent to the sun managers list server.
One of the people suggested I send it to you. I'm using a Sun SPARCstation IPC
running Solaris 2.1. I do not have a '/.rhosts' or '/etc/hosts.equiv' file.
I am the only user on the workstation.
----------------included message--------------------------------
I'm sitting here at my terminal when suddenly my cpu usage sky-rockets and these
messages spew onto my console window:
Sep 8 15:59:54 mslab2.med.utah.edu ftpd[1070]: getpeername (in.ftpd): Transport endpoint is not connected
...
Sep 8 16:05:33 mslab2.med.utah.edu ftpd[1149]: getpeername (in.ftpd): Transport endpoint is not connected
pid's from 1070 to 1149. What's going on? Is a hacker out there with a program
that gives random password to an ftp session?
I disabled ftp in /etc/inet.conf just in case. Should I worry? Is this a
Solaris 2.1 bug?
Cert responded with what they thought to be a solution. I am still not convinced that
what they said applies to my station. The reason I'm not convinced is because this machine
is the workstation on my desk that has only my account and the usual system accounts (root,
daemon, ....). Nobody should be trying to ftp to this workstation. Cert's explanation
assumes that a valid user was trying to ftp. I'm the only valid user and I was not trying
to ftp.
Thanks to:
Andrew Benson (drew@mtu.edu)
kubipdal@uts.uni-c.dk (Peter Dalg}rd)
poland@cam8.gsfc.nasa.gov (Jim Poland)
musac@chaos.eng.wayne.edu (Carlo Musante )
Mark Zajicek <mtz@cert.org>
-Jack Jones
jack@mslab2.med.utah.edu
######################################################################################################
>From kubipdal@uts.uni-c.dk Thu Sep 9 09:26 MDT 1993
Date: Thu, 9 Sep 93 17:27 CET
From: kubipdal@uts.uni-c.dk (Peter Dalg}rd)
To: jack@mslab2.med.utah.edu
Subject: Re: HELP! Do I have an intruder?
Weird! Same thing happened to a Sparc Classic over here in
Denmark. I'd better check out the time of the event. (This is not
my regular system, just for reading news).
Peter Dalgaard
######################################################################################################
>From poland@cam8.gsfc.nasa.gov Fri Sep 10 07:32 MDT 1993
Date: Fri, 10 Sep 93 09:33:33 EDT
From: poland@cam8.gsfc.nasa.gov (Jim Poland)
To: jack@mslab2.med.utah.edu
Subject: Re: HELP! Do I have an intruder?
Please summarize. I've seen the same thing, especially after hours and
weekends. Thanks.
######################################################################################################
>From drew@mtu.edu Thu Sep 9 07:10 MDT 1993
From: Andrew Benson <drew@mtu.edu>
Subject: Re: HELP! Do I have an intruder?
To: jack@mslab2.med.utah.edu
Date: Thu, 9 Sep 93 9:11:56 EDT
I'm not SURE, but I think maybe somebody ran in.ftpd from the command line.
Try it yourself and see if that shows up.
Dunno if it's a cracker.
-- Andrew Benson (drew@mtu.edu) Michigan Technological University Systems Administrator Department of Mining Engineering ACS Consultant Computing Technology Services ######################################################################################################>From musac@chaos.eng.wayne.edu Fri Sep 10 17:06 MDT 1993 Date: Fri, 10 Sep 93 19:08:14 EDT From: musac@chaos.eng.wayne.edu (Carlo Musante ) To: jack@mslab2.med.utah.edu Subject: Re: HELP! Do I have an intruder?
Maybe its not ftp they are using but tftp. If tftp is active someone can get your passwd file as well (or at least try to).
There is a group called CERT (Computer Emergency Response Team) which deals with this stuff. I am including one of their previous advisories. Their address and other info is at the end of the advisory.
=========================================================================== CA-92:14 CERT Advisory June 22, 1992 Altered System Binaries Incident
---------------------------------------------------------------------------
The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information regarding a series of significant intrusion incidents on the Internet. Systems administrators should be aware that many systems on the Internet have been compromised due to this activity. To identify whether your systems have been affected by the activity we recommend that all system administrators check for the signs of intrusion detailed in this advisory.
This advisory describes the activities that have been identified as part of this particular incident. This does not address the possibility that systems may have been compromised due to other, unrelated intrusion activity.
---------------------------------------------------------------------------
I. Description
The intruders gain initial access to a host by discovering a password for a user account on the system, exploiting a "+" in the "/etc/hosts.equiv" file, or any ".rhosts" files on the system. The intruder then connects to the system using rsh and attempts to become root on the compromised system. An alias of "decode" may used to gain root privileges.
II. Impact Having gained root access on a system, the intruders may make unauthorized changes to system binaries that can capture account information for both local and remote systems. In addition, the intruder adds "+ +" to any ".rhosts" files to which the intruder has access.
III. Solution
A. Check your systems for signs of intrusion due to this incident.
1. Check the login, telnet, and uucpd binaries (for example, "/bin/login", "/usr/ucb/telnet", and "/usr/etc/in.uucpd" on Sun systems) against copies from distribution media. Note that a check for creation or modification times and sizes is not sufficient to assure that the files have not been modified. The CERT/CC suggests that you compare the output of the "sum(1)" or "cmp(1)" command on both the distribution and installed versions of the binaries.
2. If the check from (A.1) indicates that your binaries have been modified, check for the presence of a password log file. Since the name of the logfile is often changed, the name of the file should be obtained using the "strings(1)" command on the Trojan login, uucpd, or telnet binary. Examples of filenames used on other systems are:
"/usr/spool/. " (dot space) "/var/spool/secretmail/.l" "/var/spool/secretmail/.log" "/var/spool/secretmail/.tty" "/var/spool/secretmail/.lock" "/usr/tmp/.log" "/usr/spool/uucp/.sys" "/usr/spool/uucppublic/.hushlogin" "/usr/uucp/.sys" "/mnt2/lost+found/.tmp/.log" "/usr/spool/mqueue/.AFG001"
Verify that the contents of files found using the "strings(1)" command do not contain valid username/password combinations.
3. Check for the presence of "+" in the "/etc/hosts.equiv" file.
NOTE that Sun Microsystems installs the SunOS operating system with a default "+" in the /etc/hosts.equiv file for easy network access. This should be removed unless required in your operating environment and protected by a firewall network configuration. Leaving the "+" intact will allow any non-root user on the Internet to login to the system without a password.
4. Check the home directory for each entry in the "/etc/passwd" file for the presence of a ".rhosts" file containing "+ +" (plus space plus).
5. Assure that your "/etc/fstab", "/etc/inetd.conf", and "/etc/exports" files have not been modified.
B. Take the following steps to secure your systems.
1. Save copies of the identified files to removable media and remove any password log files as found in (A.2) above.
2. Replace any modified binaries with copies from distribution media.
3. Remove the "+" entry from the "/etc/hosts.equiv" file and the "+ +" (plus space plus) entry from any ".rhosts" files.
4. Change ownership of the "/etc" directory to userid "root" if it is owned by "bin" (as distributed by Sun). 5. Change every password on the system and assure that the new passwords are robust using a package such as Crack or Cops (available via anonymous ftp from cert.org).
6. Inspect and restore any changes made to your "/etc/fstab", "/etc/exports", or "/etc/inetd.conf" files. If any modifications are found in these files, you will need to unmount file systems and restart daemons once the files have been restored. Alternatively the system could be rebooted. 7. Remove the "decode" alias from your global mail aliases file ("/etc/aliases" on Sun systems, "/usr/lib/aliases" on other UNIX systems). ---------------------------------------------------------------------------
If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams).
Internet E-mail: cert@cert.org Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours.
Computer Emergency Response Team/Coordination Center (CERT/CC) 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 cert.org (192.88.209.5).
=============================================================================== Carlo Musante Wayne State University Network Hardware Manager Engineering Electronics Shop Phone# (313) 577-0106 5050 Anthony Wayne Drive Fax# (313) 577-3881 Detroit, MI 48202 U.S.A. Internet: carlo@chaos.eng.wayne.edu =============================================================================== ######################################################################################################
>From mtz@cert.org Wed Sep 22 12:12 MDT 1993 To: jack@mslab2.med.utah.edu (Jack Jones) Cc: cert@cert.org, jack@medstat.med.utah.edu Subject: Re: Possible intruder? Date: Wed, 22 Sep 93 14:15:05 EDT From: Mark Zajicek <mtz@cert.org>
Jack,
A belated thank you for your message (of Sep 10) to the CERT Coordination Center, regarding the suspicious "getpeername" messages that you discovered in the console window on your SPARC:
> The folowing is a message that I sent to the sun managers list server. > One of the people suggested I send it to you. I'm using a Sun > SPARCstation IPC > running Solaris 2.1. I do not have a '/.rhosts' or '/etc/hosts.equiv' file. > I am the only user on the workstation. > > ----------------included message-------------------------------- > I'm sitting here at my terminal when suddenly my cpu usage sky-rockets and these > messages spew onto my console window: > > Sep 8 15:59:54 mslab2.med.utah.edu ftpd[1070]: getpeername (in.ftpd): Transport endpoint is not connected > ... > Sep 8 16:05:33 mslab2.med.utah.edu ftpd[1149]: getpeername (in.ftpd): Transport endpoint is not connected > > pid's from 1070 to 1149. What's going on? Is a hacker out there with a program > that gives random password to an ftp session? > > I disabled ftp in /etc/inet.conf just in case. Should I worry? Is this a > Solaris 2.1 bug?
I passed your message to some of the folks in our technical development group here at CERT-- it took a while to do some checking into the specific system calls... but their answer, in a nutshell, is that no, this does not appear to be an intruder attack.
The explanation given me was that it seems that whatever was causing your CPU usage to skyrocket may have also caused a significant delay in the in.ftpd program to issue the "getpeername" system call, to get the name of the [attempted] connecting host-- by the time your system tried to respond, the remote host may have aborted and tried to re-establish a connection (which may explain the multiple in.ftpd processes logged). However, since getpeername is called at the beginning of the program, it seems unlikely that any information could have been obtained from the failed FTP connections, leading us to suspect that this was not part of an automated FTP attack.
Sorry for the delay in responding-- hope things have been quiet on your system since then.
While I have your attention, please feel free to refer to our "CERT Generic Security Information" document (also called our "security checklist"), which may be useful to you in checking your system for common vulnerabilities that are often exploited by intruders. The checklist is available via anonymous FTP from "cert.org" (192.88.209.5), in "/pub/tech_tips/security_info".
Past CERT advisories and other security-related information (such as some of the packages mentioned in section D of our checklist) are also available via anonymous FTP from "cert.org". (Please feel free to browse through the information in our FTP "/pub" directory and pick up anything else of interest.)
Thanks again for bringing this to our attention. If there is anything we can do to help you in the future, please let us know.
Mark T. Zajicek Technical Coordinator
CERT Coordination Center | Internet E-mail: cert@cert.org Software Engineering Institute | Telephone: 1-412-268-7090 24-hour hotline Carnegie Mellon University | Answered by CERT, 8:30-17:00 EDT (GMT-4) Pittsburgh, PA 15213-3890 | On call for emergencies, 24 hours/day.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:18 CDT