Re: tracking down unidentified users

From: Alan Hadsell (ahadsell@MtDiablo.com)
Date: 11/21/02 

From: Alan Hadsell <ahadsell@MtDiablo.com>
Date: Thu, 21 Nov 2002 02:00:20 GMT

dan sawyer <dansawyer@earthlink.net> writes:

> I have discovered reminants of an attack that apparently took place
> over a year ago. That attack left 4 users in /etc/passwd and
> /etc/shadow. The names are selector1, semaca, tmp, and an altered
> operator profile.
>
> lastlog indicates these runs are activated the first time after a boot
> when I activate a user as 'root'. I can find no strings relating to
> those names anywhere in the /etc dir.

What do you mean by "activate a user as 'root'?" Are you referring to
logging in as root?

I have seen your posts about this issue in several forums. It appears
that you have a basic confusion between "users" and "jobs" or "runs".

I gather that what you mean is that some process owned by these users
runs whenever you "activate a user as 'root'". The most likely reason
for that is that root's login script is starting the jobs that you
see.

One thing you might consider is finding all files and directories
owned by these users and/or their groups. If there are executable
files owned by these users that have the suid bit set, they will cause
the system to "log in as" that ID when started. From there, they
could launch other processes under that ID.

> What is unique about root from a script and start process then other
> users?

The main thing that's unique about root from that perspective is that
the "init" processes are all started as root, and so unless they take
steps to ensure otherwise, all other processes they start are also run
as root. Of course, root has many other unique aspects, mostly having
to do with privileges it has that other users do not.

As others have done, I urge you not to put the system in question on
the Internet until you have done a reformat and reinstallation of your
operating system to eliminate these issues. You can't ever be sure
that you have fixed them until you do. 

-- 
Alan Hadsell
If something's already broken, does it really matter how many pieces it's in?
--James Bottomley on lkml

Relevant Pages

  • Re: Hacked, now trying to disinfect
    ... In addition to disabling root login I also have enabled tcpwrappers on ... accounts first, and then do a determined attack on root. ... After failure to attack root the typical attack goes after usual system ... If the sshd provides a method to determine when an invalid username is ...
    (comp.os.linux.networking)
  • Re: Sudo tricks
    ... like path attack as example or clean exec? ... installing a root kit on monitored system will yell alarms. ... in the example given by the author we compromise the user A which have ... execute commands in the context of a user B which can execute commands ...
    (Bugtraq)
  • Re: [OT] Rootkit queston
    ... In particular, do not run inetd. ... You can check for a common 'root attack', if you have inetd, ... > have a LKM rootkit installed, but the website told me that it's possible ...
    (Linux-Kernel)
  • Re: [Full-disclosure] Symlink vulnerabilities
    ... You can make it bypass Aslr? ... stable enough root shell. ... His attack is against the stub, which is a bourne shell script. ... Now root executes it, and gives him a root shell. ...
    (Full-Disclosure)
  • Re: Hacked, now trying to disinfect
    ... In addition to disabling root login I also have enabled tcpwrappers on ... accounts first, and then do a determined attack on root. ... their username, it is not very hard to find the usernames. ...
    (comp.os.linux.networking)