Unix administration - Non-root account break-in cleanup?

This is Interesting: Free IT Magazines  
Home > Archive > Unix administration > November 2004 > Non-root account break-in cleanup?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Non-root account break-in cleanup?
sinister

2004-10-31, 5:49 pm

I'm using SunOs 5.9 (Sparc).

Based on entries in /var/adm/wtmpx (examined with last -a), it looks like my
non-root account may be compromised.

Aside from changing my password and being on the lookout for missing files
and strange files, is there any clean-up one needs to do if a non-root
account has been breached? Are there any telltale signs that would show
whether my account was indeed breached? (Most of the stuff I've seen in
cyberspace is for the case of root being hacked.)

TIA,

S


Michael Vilain

2004-10-31, 5:49 pm

In article <9s9hd.2393$KL4.410@trnddc07>,
"sinister" <sinister@nospam.invalid> wrote:

> I'm using SunOs 5.9 (Sparc).
>
> Based on entries in /var/adm/wtmpx (examined with last -a), it looks like my
> non-root account may be compromised.
>
> Aside from changing my password and being on the lookout for missing files
> and strange files, is there any clean-up one needs to do if a non-root
> account has been breached? Are there any telltale signs that would show
> whether my account was indeed breached? (Most of the stuff I've seen in
> cyberspace is for the case of root being hacked.)
>
> TIA,
>
> S


Such forensics may be useful to determine the nature of the attack, but
as far as I'm concerned, you have a compromised, untrusted system. I'd
reinstall from Solaris distribution and restore user data from backups,
just to be sure.

After the fact, on another system, you can poke through the disk image
and see what checksums don't match in various things. Sun publishes a
MD5 fingerprint database just for this purpose.

--
DeeDee, don't press that button! DeeDee! NO! Dee...



sinister

2004-10-31, 5:49 pm


<Michael Vilain <vilain@spamcop.net>> wrote in message
news:vilain-B1EC5D.13122231102004@news.giganews.com...
> In article <9s9hd.2393$KL4.410@trnddc07>,
> "sinister" <sinister@nospam.invalid> wrote:
>
>
> Such forensics may be useful to determine the nature of the attack, but
> as far as I'm concerned, you have a compromised, untrusted system. I'd
> reinstall from Solaris distribution and restore user data from backups,
> just to be sure.


That's probably what *should* be done, but most of the sysadmin is being
done by someone filling in on a temporary basis, so there's a good chance
this won't get done.

> After the fact, on another system, you can poke through the disk image
> and see what checksums don't match in various things. Sun publishes a
> MD5 fingerprint database just for this purpose.


Right; I used that to check the binaries that chkrootkit uses.

> --
> DeeDee, don't press that button! DeeDee! NO! Dee...
>
>
>



Laurenz Albe

2004-11-02, 7:48 am

In comp.unix.admin sinister <sinister@nospam.invalid> wrote:
> Aside from changing my password and being on the lookout for missing files
> and strange files, is there any clean-up one needs to do if a non-root
> account has been breached?


These are just a few things that come to mind, certainly not complete.

- Check .hosts for new entries.
- Look for setuid executables.
- Look at the user's crontab file.

It were best to check all files that the user owns, but usually the most
sensitive ones are the dot files in the user's home directory.

Yours,
Laurenz Albe
sinister

2004-11-02, 7:48 am


"Laurenz Albe" <albe@culturallNOSPAM.com> wrote in message
news:cm7lk3$60a$2@at-vie-newsmaster01.nextra.at...
> In comp.unix.admin sinister <sinister@nospam.invalid> wrote:
>
> These are just a few things that come to mind, certainly not complete.
>
> - Check .hosts for new entries.
> - Look for setuid executables.
> - Look at the user's crontab file.
>
> It were best to check all files that the user owns, but usually the most
> sensitive ones are the dot files in the user's home directory.
>
> Yours,
> Laurenz Albe


Laurenz,

Thanks for your input. Those make sense.


Stachu 'Dozzie' K.

2004-11-02, 7:48 am

Zawartość nagłówka ["Followup-To:" comp.security.unix.]
On 2004-11-02, Laurenz Albe wrote:
> In comp.unix.admin sinister <sinister@nospam.invalid> wrote:
>
> These are just a few things that come to mind, certainly not complete.
>
> - Check .hosts for new entries.
> - Look for setuid executables.
> - Look at the user's crontab file.


I'd like to add some more places to check:
- .ssh/authorized_keys (or similar, depending on SSH or whatever
configuration)
- all processes, especially those listening on TCP/UDP sockets and
screen(1) sessions
- user's atd(8) spool
- CGI scripts in the public_html directory
- .procmailrc
- .forward (probably can't be a backdoor, but it's worth checking)
- shell configuration (.profile, .bash_profile, .zshrc or whatever)

--
Stanislaw Klekot
Gandalf Parker

2004-11-06, 5:50 pm

"sinister" <sinister@nospam.invalid> wrote in
news:9s9hd.2393$KL4.410@trnddc07:

> I'm using SunOs 5.9 (Sparc).
>
> Based on entries in /var/adm/wtmpx (examined with last -a), it looks
> like my non-root account may be compromised.
>
> Aside from changing my password and being on the lookout for missing
> files and strange files, is there any clean-up one needs to do if a
> non-root account has been breached? Are there any telltale signs that
> would show whether my account was indeed breached? (Most of the stuff
> I've seen in cyberspace is for the case of root being hacked.)


Get and run chkrootkit. That covers most of what I would tell you to
check.

Other than that.. make sure that no new CGI's have been added to that
accounts web directory. Examine the shell login files carefully. Same
with any program config files that are in that directory.

A particular trick for a non-root account which the root person might use
is to add scripts to the ~/bin or somewhere else in that users path.
Something you might quickly jump to root or su to use. Such as..
making a script named tcpdump which uses the root access to create a
backdoor and then calls the real tcpdump by direct path.

do a "find ." or something along that line to show you any strange
directories that have been added such as things using 3 dots or multiple
hard spaces

Im not big on the "black plague response" answers such as destroy the box
and start over. But if there isnt much in that accounts directory you
might consider just deleting it and making it again

Gandalf Parker
-- the music should always change when..
Someone in a horror movie says "We should be safe here"
Someone driving says "Ive never had an accident"
Some computer user says "My machine is secure"
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com