Scobot Hack
Jeff Liebermann
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://www.sco.com/security/secfdbk.html
I think they'll be suitably entertained. I forgot the security team
secret email address. Also see:
http://www.sco.com/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
je...@comix.santa-cruz.ca.us je...@cruzio.com
Geoff Bleau
The sysadmin noticed a strange login at 19:32 - and killed that user
( new user - not added locally )
Also found a file called scobot.tar - that contained some tcl scripts
and
what appears to be a replacement for ' vi '.
/etc/shadow had also been modified.
After removing all these - someone got back in at 20:49 and put the
scobot.tar
files in a different directory.
I plan on restoring from a 2 week old backup tomorrow - and then
changing
all passwords while in single-user mode.
In the meantime - is there a quick way to keep this guy off the system
?? - 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 ?? )
Thanks,
--
" Bigamy is having one wife too many.
Monogamy is the same "
Geoff Bleau geo...@bellsouth.net
Bill Vermillion
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>On Thu, 23 Mar 2000 00:22:04 -0500, Geoff Bleau <geo...@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
Jeff Liebermann
wrote:
>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.
I was thinking more in terms of the "typical" breakin technique and finding
to where the output is being emailed. Backdated email files also tend to
break things. However, it is possible.
>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.
Good point. Using the date as a discovery method is fairly easy to
digusise. Same with editing /etc/wtmp and sulog. However, my limited
experience shows a much cruder level of sophistication and covering ones
trail. It may not find the problems, but it sure doesn't hurt to look. One
thing for sure; restoring a 2 week only backup is no guarantee of success.
>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.
Why so fancy? I usually use "..." as a filename and few people ever notice.
>Providing the cracker didn't modify these hide something.
Even SCO doesn't understand the custom+ database VTCL infested data
structure. Oh-oh. The hack was done in TCL.
>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.
Yep. Also, one has to be careful that no SUID or GUID programs were left
hanging around in the data directories.
>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.
Paranoia as a way of life? No thanks. The real problem is that 90% of all
the security breaches that I've had to deal with were either inside jobs, or
lousy account/password administration. It's a rare day when I see an
outside hacker or script kiddie successfully make themselves at home on a
customers system. However, stolen customer lists and financials, from
inside the firewall are all too common. Firewalls do nothing when the
attack comes from inside the firewall or from a valid user account.
The first step to solving any problem is to assign the blame. If the hacker
left some kind of trojan horse or backdoor scripting tool, then he's afraid
that he might not get back in again by the same method. That points to a
former employee with carnal knowledge of the system or professional hacker
that has a reason to break in. If the original root password was obtained
"legally", then it could be the service company with lousy internal
security, or some vertical market software company that uses the same
password on all their customers systems (I've seen this all too often).
Once the door is open, the only people that care enough to break in and stay
in are those with a vested interest in the company (employees, former
employees, customers, etc). Most script kiddies don't stick around, will
just make a mess, and leave.
Drivel: When was the last time you changed all the root level passwords on
your machines? OK, I'll confess. About 3 years ago, after the last
breakin. I'll probably change them again after the next breakin. Do like I
say, not like I do.
Bill Vermillion
Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>On Thu, 23 Mar 2000 13:02:07 GMT, bi...@wjv.com.REMOVEME (Bill
>Vermillion) wrote:
>>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.
>I was thinking more in terms of the "typical" breakin technique and
>finding to where the output is being emailed. Backdated email files
>also tend to break things. However, it is possible.
I'd agree that the 'typical' break-in wouldn't be going to the
extremes I listed.
>>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.
>Why so fancy? I usually use "..." as a filename and few people ever
>notice.
Two files one a . the other .. aren't as conspicuous as three.
>>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.
>Yep. Also, one has to be careful that no SUID or GUID programs were
>left hanging around in the data directories.
I'd guess if something were really carefully planned the only
things in a data area with execute permissions should be
directories. If the applications know the file names they are
looking for you could get by with having directories being execute
only with no read permission on the directory.
[For those fairly new to *ix - read permissions on a directory
permit you to list the contents. A directory with d--x--x--x (aka
chmod 111) will permit you to access the contentss if you know the
names. Works differently than read permission on files]
That gets into the security through obscurity mode.
>>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.
>Paranoia as a way of life? No thanks. The real problem is that 90%
>of all the security breaches that I've had to deal with were either
>inside jobs, or lousy account/password administration.
As the last line above says 'how much they think they have to
lose'. Most of the systems I work on have really low security -
and many have no outside access. I can recall two in the past 10+
years that have been at the extreme opposite. Paranoia was almost
too mild a word.
>It's a rare day when I see an outside hacker or script kiddie
>successfully make themselves at home on a customers system.
>However, stolen customer lists and financials, from inside the
>firewall are all too common. Firewalls do nothing when the attack
>comes from inside the firewall or from a valid user account.
Yup. I had one truly paranoid client - and given the competitive
industry he worked in - I didn't blame him. Two people knew the
system password. The client and myself. His typing was so slow
that no one could be in the room when he entered the password for
the system to start the backups. His wife had worked there part
time and when she left all the password were changed again.
>... , or some vertical market software company that uses the same
>password on all their customers systems (I've seen this all too often).
Yup.
>Drivel: When was the last time you changed all the root level
>passwords on your machines? OK, I'll confess. About 3 years ago,
>after the last breakin. I'll probably change them again after the
>next breakin. Do like I say, not like I do.
Same thing here.
But did I mention on this list that about two weeks ago I telneted
to a system - and I didn't even get a login prompt. I was in the
root directory as root. They'd let their previous admin go and
the old *ix system had been replaced by a Linux system run by
someone who was probably just learning. Argh!