[plug] Am I Being Hacked?

[Christian]

On Tue, May 09, 2000 at 10:39:15AM +0800, Earnshaw, Mike wrote:
> Noticed this in the log today ....
> =====start===== 
> Security Violations
> =-=-=-=-=-=-=-=-=-=
> May  8 17:49:59 usswa login[14597]: FAILED LOGIN 1 FROM (null) FOR
> z.a^Z?toE~o^Pm%?^A^Ga^GLC, User not known to the underlying authentication
> module
 <snipped>
> =====end=====
> bit concerned and I dont know what it means. I have also been getting alot
> of attempts to establish connections on weird ports like 3 (Compression
> Process??) and some higher undocumented ones.

The first thing I would ask is, which log did you find it in?  Did you
add the header "Security Violations" or is that part of some log? (I've
never seen it before -- is it part of some special security report email
that gets sent to the admin on some distribution?)  It's really hard to
say without being familiar with the system in general, however, I think
there is certainly an issue here (security or otherwise) that you should
be concerned about.

Looking at the log output you're obviously running a PAM system,
however, I've never really used PAM (Debian includes it but not enabled
by default and I've never felt the added functionality has warranted the
added risk.)  The fact that login is reporting that the login attempt is
from "(null)" is really odd -- if it were a network access attempt then
I would expect to see the address of the host there while a console
login would obviously give the terminal line.  Since it gives neither
then that suggests either there is some situation where PAM/login does not
report  the source of the authentication attempt or that an attacker has
somehow subverted the login operation to hide that information.  Perhaps
someone more familiar with PAM can suggest a scenario for the former
case.  The gibberish login has as a username suggests either some at
least partially successful attack or a malfunction of the login process
(very likely due to PAM).  Try logging in normally (don't use ssh to do
this) and checking the output in the logs -- if it logs everything correctly 
then the attack-based scenario seems the most likely.

> Whilst our LRP seems to be stopping these I am a bit concerned. Should I
> start looking for other things on my system that may indicate a successful
> attack. I am really green in relation to security and I guess since I know
> so little, I know there are lots of people who could easily fool me.

What's "LRP"?  I'm interested because you seem to think that any
penetration attempt is being actively stopped while I would suggest that
either the penetration attempt (if it be such) is failing on its own
merits or is succeeding with the above side-effect.

Since, without investigating further, I don't really know what's going
on myself it's hard to give advice, however, my suggestions are:

1.  Install some sort of lightweight network intrustion detection
system.  I recommend something like ippl (IP Protocols Logger) -- this
is developed by someone in the Debian project but there is probably an
RPM available.  It will log most valid TCP connection attempts, all UDP
and ICMP packets (you can set rules excluding the logging of certain
types of packets so that "allowed" packets don't clog up your logs).
Monitor these logs on a regular basis.

2.  Get someone to do a portscan of you (I'm happy to oblige -- contact
me off list) and see what ports if any are open and shouldn't be.  I
suspect that your machine is probably in it's default insecure state.

3.  Compare MD5 (or better) hashes of important system files (/bin/login
would be the first one I would check out!) with that of a copy you
*know* to be secure (preferably the one on the original CD but you may
have to unpack the package somewhere temporarily to do this).  It may
also be interesting to check the inode change times to see if/when the
system files were last changed -- if you notice that several of the
system files were updated recently while others all have the same time
corresponding to when they were installed then it seems likely that some
of them were replaced.  To check the MD5 hashes use, for example:

stallman:~$ md5sum /bin/login
e7b854e938e8bec6e9b3866f31b08a20  /bin/login

diffie:~$ md5sum /bin/login
e7b854e938e8bec6e9b3866f31b08a20  /bin/login

To check the ctimes use something like "ls --full-time --time=ctime -l".

It's really hard to say what the problem might be but I if I had to
guess then I might suggest that you have been broken into and the
attacker has installed a pre-packaged root kit designed to let them back
in.  They've installed a modified /bin/login program, however, the
program doesn't play 100% happily with your system hence you're getting
that sort of funny output.  I've definitely seen that sort of thing
before although I've never seen the exact output you describe.

Hope this helps and sorry I can't be more specific.

Regards,

Christian.