Re: Break-in attempt from 203.197.38.247

[M ixter <mixter () 2XS CO IL>]

On Tue, 22 Aug 2000, Cronje Schalk wrote:

> This morning we discovered a possible break-in attempt. The alert came
> from continous retries on the pop3 and telnet ports. POP3 was
> accidentely was left open although no pop3 service nor mail service is
> installed.
>
> > From /var/log/secure:
> --------------------
> Aug 22 01:09:34 jupiter ipop3d[3954]: connect from 203.197.38.247
> Aug 22 01:09:34 jupiter ipop3d[3954]: error: cannot execute
> /usr/sbin/ipop3d: No such file or directory
Check your logs, the original attack must have occured before this...
The intruder damaged your system and deleted files before, including ipop3d.
That particular IP is from the Indian ISP VSNL...

> > From /var/log/messages:
> -----------------------
> Aug 22 01:09:43 jupiter telnetd[3957]: ttloop:  peer died: Invalid or
> incomplete multibyte or wide character
>
> What is really strange is a replacement of certain files
>
> ?---------  14559 root     46449    4294967295 Mar 27 21:57 bashrc
> ?---------  14559 root     46449    4294967295 Mar 27 21:57 info-dir
> ?---------  14138 root     8567     4294967295 May 13  1999 named.boot
> ?---------  14694 root     2584     4294967295 Jul  7 18:49 rpc
> ?---------  14441 root     12171    4294967295 Aug 17 17:02 shells
> ?---------  14099 root     8165     4294967295 Aug 21 15:28 termcap
The dates look pretty arbitrary... but possibly the attacker copied the
timestamp with touch -r <other file> <file>
File size 4294967295 sounds familiar, that is -1 cast to unsigned, meaning the
attacker might have just truncate()'d the files to a length of -1, named.boot
and rpc, possibly to prevent bind and rpc from working to prevent other people
getting access to the machine? But generally it makes very little sense
(which is pretty stupid, a file system 'bug' exists that makes this possible,
 they are not really that big and most programs will have problems accessing
 them. I remember this was discussed on bugtraq some time ago)

> No binaries have been replaced. At this point I am somewhat confused. I
> cannot determine if this was an attempted of a successfull break-in. On
> thger otehr hand it can simply be a damaged filesystem. Can anyone shed
> some light on this?
I think you should consider it a successful breakin, due to the nature of the
things happening (daemon binaries disappeared, and some of the modified files
were somehow relevant to security). Also, if you still have your full logs,
check the entries before the first error due to a removed server executable.