Solaris installpatch says "basename not found"

Or more specifically it says
./installpatch[199]: basename:  not found

the version of solaris is SonOS Release 5.5.1
the machine is a Sparc2
the patch is to fix a hole before I boot the little hackers off the machine.


LVL 2
GP1628Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

tfewsterCommented:
Can't test it at the moment, but is [199] the line number in the installpatch script? Alternatively,  grep basename installpatch should find the line. You could then try running the command on that line manually.

If Unix can't find the 'basename'command, someone has seriously screwed up your path and/or standard commands [Unless installpatch uses an absolute pathname or resets the standard paths].

Hope this helps
0
GP1628Author Commented:
hmmm good thought.
But no, I just did a
head -200 installpatch

and none of the lines at the end used basename.
I suppose I could try and figure out what each of the basename commands is trying to get and edit the lines to an exact path.

I will probably try that if no one comes up with anything.

Gandalf
0
tfewsterCommented:
If installpatch calls or dots in other shell scripts that could confuse the line numbering and makes it more difficult to trace which line is failing.

My second point was that installpatch is not finding the 'basename' command. I expect it would normally be in /usr/bin (or there may be a link in /usr/bin to where it really is). Try 'which basename' find out where it is & make sure installpatch can pick it up.

Please, somebody else answer Gandalf's question, quickly... I'm trying to debug a script I can't see on a system that may have been hacked, just from memory of Solaris =:O
0
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

GP1628Author Commented:
wow, sounds rough.

OK I found it. I knew that the little hackers had trashed /bin/sh (strange thing to do, seems a sloppy way of keeping root from logging in)

I had checked installpatch and saw that it was ksh so I figured I was safe. Didnt realize that basename was a /bin/sh script.  :)

So far all of these have been fine by just chnging sh to ksh. I have to remember to change them back later.

Thanks.
Gandalf
0
tfewsterCommented:
Nice one - Now you just have to figure out how to give yourself the points :)

Maybe I should ask you a Q about stopping hackers...
0
GP1628Author Commented:
wow, sounds rough.

OK I found it. I knew that the little hackers had trashed /bin/sh (strange thing to do, seems a sloppy way of keeping root from logging in)

I had checked installpatch and saw that it was ksh so I figured I was safe. Didnt realize that basename was a /bin/sh script.  :)

So far all of these have been fine by just chnging sh to ksh. I have to remember to change them back later.

Thanks.
Gandalf
0
GP1628Author Commented:
oops didnt mean to do that.

> Nice one - Now you just have to figure out how to > give yourself the points :)
> Maybe I should ask you a Q about stopping > hackers...

I was wondering that myself. Not so much the points but to kill the thread. It will only let me post a comment, ot an answer to myself. :)

Gandalf
0
tfewsterCommented:
I think you can delete a Q if no-one has proposed an answer, or get Customer Services to do it for you.

Alternatively, you could accept one of my comments as an answer :)

Best wishes anyway
Tim
0
samriCommented:
GP1628,
   I think, it you are sure that the machine is hacked, and you wouldn't sure that is damaged, you got to sit back and evaluate, is it worth to dig into the problem, examining each and every possibilities of the damage done.  Or you could back up all of the things that you want to save (data), and reinstall from scratch.
   The bad thing about reinstalling is that, you will miss the fun, and experience in getting to know how the hacker gets into your machine.

Just my $0.01 comments,

Samri
0
tfewsterCommented:
How are you getting on against the little #@ckers?
0
GP1628Author Commented:
Nahh Im having fun with them.
I trace them back to their own machine, log in there, and download files. This one came off of a windows machine. I downloaded win.ini, system.ini, some intresting logs of IRC conversations where they traded sites like they were trading cards, and finally a list which seems to be a list of their shell sites.
Im scanning them now for some RL names and info I can use.

This isnt the best crew Ive snooped on. The last bunch was much better at hiding themselves in the machine but they did finally cut a deal of "we will stay out of yours if you stop logging into ours"

Right now I have mass patches running on the machines in that network. Then I will use the logins and passwords tht they created to get back into the box and remove them from it.

gandalf@community.net
0
tfewsterCommented:
Uhh..Nice to see you giving them some of their own medicine, but remind me NEVER to upset you.
0
jlevieCommented:
Re; having found that /bin/sh was trashed and GP1628's comments about the points... You're probably not as hosed out regarding basename as you'd think. Link or copy /sbin/sh to /bin/sh. Solaris keeps a staticly linked copy for root's use so you can have a shell in single user mode when there are problems with using dynamic libraries. Which in turn is a good thing to remember when comtemplating a change in root's shell... Thus avoiding one of the prime causes of the "Dreaded root shell disease".

Maybe I should get the points now...
0
GP1628Author Commented:
oh sorry. in reading back I see that I didnt mention. That was what I did. link the /sbin/sh to the bin/sh that everything was looking for. Saved me alot of work. THe patches all installed nicely.

Now Im just debating whether to boot the little #*@&ers now or continue messing with them and gathering data.

Gandalf
0
tfewsterCommented:
Have you read "The Cuckoos egg" by Clifford Stoll (ISBN 0 330 31742 3)? Your experience sounds very similar. Basically, he found & tracked down some hackers and eventually got them prosecuted. The problem was the time it took to collect evidence & get action from the authorities - probably why most people don't bother, so the #@ckers get away with it.

Alternatively, look at The Avengers handbook http://www.ekran.no/html/revenge for some ideas on messing with deserving peoples minds >:->
0
GP1628Author Commented:
Well its been informative as long as they are on a machine that isnt mission critical anyway. Whats fun is using their own tools, like a sniffer the last group left, against them.

Apparently the game goes like this. They break in and look for something they can use. Then they install programs overwriting ps, ls, netstat, login, passwd, find, etc. They are designed to not show their special logins logging in, not show certain processes being run, and not allow you to change their stuff.

If you run shadow passwd files then
grep -v :x: /etc/passwd
tail /etc/shadow

any unix system
find /dev/* | grep -i asci
ls -blart /etc
ls  -blart /usr/bin    (or where those commands are)

if you find anything interesting, ask me about it.
gandalf@community.net
0
GP1628Author Commented:
Well its been informative as long as they are on a machine that isnt mission critical anyway. Whats fun is using their own tools, like a sniffer the last group left, against them.

Apparently the game goes like this. They break in and look for something they can use. Then they install programs overwriting ps, ls, netstat, login, passwd, find, etc. They are designed to not show their special logins logging in, not show certain processes being run, and not allow you to change their stuff.

If you run shadow passwd files then
grep -v :x: /etc/passwd
tail /etc/shadow

any unix system
find /dev/* | grep -i asci
ls -blart /etc
ls  -blart /usr/bin    (or where those commands are)

if you find anything interesting, ask me about it.
gandalf@community.net
0
tfewsterCommented:
Nothing interesting on any of the machines I look after (lots of su's & mistyped root passwords, but that's mostly me), but I'll drop you a line pointing you to an EE question if I need help against the bad guys.

See you around,
Tim@tfewster.free-online.co.uk



0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.