News Group Posts

security break in

Once breached, you can't be sure of anything. Any restore of data has to be done from other boot media and the system should have been fully powered off long enough for memory to decay.

As even some BIOSes can be compromised now, who knows if even even that is safe?

From: Jeff Liebermann <jeffl@comix.santa-cruz.ca.us>
Newsgroups: comp.unix.sco.misc
Subject: Re: Scobot Hack
Date: Wed, 22 Mar 2000 22:37:55 -0800
Message-ID: <recjdsk2vilp0urrt5odlv1d1qseaf93e7@4ax.com> 
References: <38D9A9FC.C7D65550@bellsouth.net> 

On Thu, 23 Mar 2000 00:22:04 -0500, Geoff Bleau <geoffb@bellsouth.net>
wrote:

>/etc/shadow had also been modified.

If he can do that, he has the root password.

>I plan on restoring from a 2 week old backup tomorrow - and then
>changing
>all passwords while in single-user mode.

What do you mean plan?  You have a problem right now that will only
get worse if you leave it alone.  Fix it now.

How do you know that the 2 week backup is any good?  If your hacker
was on the system back then, and nobody noticed, then you're wasting
your time.  I wouldn't do it.

BTW, thanks for not bothering to disclose the version of whatever SCO
product you're using.  I'll assume 3.2v5.0.5 with all the latest
updates.

>In the meantime - is there a quick way to keep this guy off the system

Ummm, pull the plug?  Disconnect from the rest of the network?

>?? - I am
>hesitant to change passwords now - as it looks like one of the functions
>of the
>tcl scripts is to re-direct or duplicate info to a 'log' file ( for
>possible mailing ?? )

Lousy logic.  He has the root password.  He problaby has a mechanism
(trap door, SUID script, SGID scrip or rootshell) for changing the
password again.  The only way you're going to keep him off the system
long enough to clean up the mess is to change ALL the passwords, and
clean out his junk.
  
1.  Pull the plug from the network, modem server, terminal server,
etc.
2.  Clean out /tmp /usr/tmp and any other world writeable directories.
3.  Change the root password.  Also change the passwords for mmdf,
news, admin, backup, and any other administrative accounts with live
logins.
4.  Then run:
        find / \( -mtime -1 -type f \) -exec ls -adl {} \;
This will find any files that have been modified today.  Slog through
the list.  If my *GUESS* is right, password changes and root logins
are being logged to a file or sent via email and this will show the
file.
5.  If your unspecified version of SCO Unix happens to be 3.2v5.0.x,
run:
        custom -v strict
and all the corrupted, tweaked, or missing files will be checked.
This may take a long time depending upon machine speed.
6.  Look for any SUID scripts and binaries that don't belong.
        find \(-perm -4000 -perm -2000 \) -exec ls -adl {} \;
(I didn't have a system handy to test the above command).
7.  Check /etc/passwd, /etc/shadow, /etc/group, /tcb/files/auth/..
for any surplus users.
8.  Run:
        pwck
        grpck
        /tcb/bin/authck -a -v
        /tcb/bin/integrity -v
and fix whatever it finds.
9.  Check the mail queues for any outgoing email full of passwords.
        /usr/spool/mail
        /usr/spool/mmdf/lock/home/*
10. Install ssh (secure shell) and use it when playing root.
11. Paste a copy of the scobot script into:
        http://stage.sco.com/support/security/secfdbk.html
I think they'll be suitably entertained.  I forgot the security team
secret email address.  Also see:
        http://stage.sco.com/support/security/

Depending upon the size of the system and your experience level, you
may find it easier to slog through the various directories and look
for extra programs, trojan horses, and software bombs.  However,
methinks that saving the *DATA* to tape, blasting the whole mess,
installing your unspecified version of SCO Unix from scratch,
restoring the data, and fixing anything the was forgotten, will need
to be performed.  I should also point out that 99% of all the root
level security breaches I've found were done from inside the firewall.

Good luck.


-- 
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl   WB6SSY
jeffl@comix.santa-cruz.ca.us   jeffl@cruzio.com

From - Thu Mar 23 08:33:55 2000
Newsgroups: comp.unix.sco.misc
From: bill@wjv.com.REMOVEME (Bill Vermillion)
Subject: Re: Scobot Hack
Message-ID: <FrvLJJ.p63@wjv.com.REMOVEME> 
Date: Thu, 23 Mar 2000 13:02:07 GMT

In article <recjdsk2vilp0urrt5odlv1d1qseaf93e7@4ax.com>,
Jeff Liebermann  <jeffl@comix.santa-cruz.ca.us> wrote:
>On Thu, 23 Mar 2000 00:22:04 -0500, Geoff Bleau <geoffb@bellsouth.net>
>wrote:

>>/etc/shadow had also been modified.


>If he can do that, he has the root password.

>>I plan on restoring from a 2 week old backup tomorrow - and then
>>changing all passwords while in single-user mode.

>>?? - I am hesitant to change passwords now - as it looks like one
>>of the functions of the tcl scripts is to re-direct or duplicate
>>info to a 'log' file ( for possible mailing ?? )

>Lousy logic.  He has the root password.  He problaby has a mechanism
>(trap door, SUID script, SGID scrip or rootshell) for changing the
>password again.  The only way you're going to keep him off the system
>long enough to clean up the mess is to change ALL the passwords, and
>clean out his junk.

There is the possibility that what Geoff found was left there to
throw someone off-guard.  You find the file - and say "Ah ha! I've
found him".  When in reality there is something lurking deep inside
where no-one would think of looking, but the script was placed
there as a decoy to make a person think they had found the culprit.

>1. Pull the plug from the network, modem server, terminal server,
>etc.

>2.  Clean out /tmp /usr/tmp and any other world writeable directories.

>3.  Change the root password.  Also change the passwords for mmdf,
>news, admin, backup, and any other administrative accounts with live
>logins.

>4.  Then run:
>    find / \( -mtime -1 -type f \) -exec ls -adl {} \;

>This will find any files that have been modified today.  Slog through
>the list.  If my *GUESS* is right, password changes and root logins
>are being logged to a file or sent via email and this will show the
>file.

This pre-supposes the cracker didn't set the clock back on the
system so that any files that he really needed to break in at a
future date could have time stamps that looked close to the
original install date while he was on the system.  You are also
assuming that if he has some hidden scripts that store changed
password data for exampe, that they don't change the time stamp on
the file immediately after they are written. If all you look for is
the standard displayed date as show in ls -lat then it might be
missed.

The systems are more robust now but in the day of Xenix you could
easily hide directory entries so that a casaul observer would not
see them.  It was relatively easy then to place non-printable
characters in a file name.

If I don't remember this correctly (it's been a very long time)
forgive me - but consider this.

Make a file whose name is contains a reverse line feed, two dots,
two backspaces and two dots. What you will see on a list IF you add
the -a option is the standard . for this directory, while the ..
will be just a bit brighter on the screen and it is being displayed
on top of .. . An unobservant user might not notice that.

An expert cracker will know what to hide, remove, modify, etc., to
cover their tracks.  The "Cukoo's Egg" by Clifford Stahl - a few
years ago - shows just how easy something could slip by.  (I was
prowling through my piles of books recently and came across cone
called Computer Crime - printed in the early '80s along with the
original paper on the disection of the internet worm of '86 that
Spafford sent out from Purdue.  Intrusion has been around for a very
long time.  But as with anything as the safeguards become strongs
the hackers become more wily.

>5.  If your unspecified version of SCO Unix happens to be 3.2v5.0.x,
>run:
>    custom -v strict
>and all the corrupted, tweaked, or missing files will be checked.
>This may take a long time depending upon machine speed.

Providing the cracker didn't modify these hide something. 

>However, methinks that saving the *DATA* to tape, blasting the
>whole mess, installing your unspecified version of SCO Unix from
>scratch, restoring the data, and fixing anything the was forgotten,
>will need to be performed.

That's really the only secure way.  There is really is no way to
know what might have been changed unless you start with a fresh
known distribution.   That's even noted in the SCO C level
security.  Once the system security is relaxed it can never be made
secure again without a complete re-install.

Trust no one.  Read the "Art of War" - and be prepared.  How far
someone goes in protection really depends on how much they think
they have to lose.


-- 
Bill Vermillion   bv @ wjv.com 

Comments?

More Articles by Tony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.