[Cialug] Locking your keys in the car

[Josh More]

Basically, you're asking how to hack root on a box.  I'm not going to
tell anyone how to do this, but as many of us need to defend against it,
I will generally discuss how people hack root, and how to prevent them. 
As an admin, you WANT people to require physical access to modify
root-owned files.

In the Linux security model, you require level 0 privs (root) to modify
/etc/hosts.  While there are all sorts of hacks you can do to make this
harder, as the basic level, you have to convince the system that you
have that level to make that change.

So, the question becomes "how do you get level 0 privs?"

Several ways:

1) Login as root
2) Login as someone else and become root
3) Run a command as root
4) Exploit a flaw in the model and come in from the outside

What you did was to use #4.  Other ways to do this generally involve
physical access.  Most commonly is to simply use boot media to access
the files and make the change.  It's always easier to bypass a system
than trick a system into hacking itself, because really, most people who
make operating systems tend to be pretty smart.

Best way to defend against this is to set up a BIOS password and
encrypt your disks.  You can also physically lock the case, but do NOT
trust the flimsy locks that most x86 boxes have.  Remember, if someone
can buy a dremel, they can get your hard drive.  Best protection is to
encrypt the data.

Other methods:

1) To login as root, you need a username and password that match root. 
If you have access to /etc/shadow, you can simply try to hack the
encrypted password.  This is much harder if the system is using MD5 or
SHA to encrypt it.  Odds are, though, that you do not have access to
/etc/shadow.  You could get it by exploiting #4, but then you can just
hack it as you like.  To protect against this, make sure that files like
/etc/shadow and /etc/passwd are owned by and only modifiable by root. 
To be paranoid, use chattr +i on them, and make /etc/ a read-only file
system.

NOTE: some legacy *NIXs put the encrypted password in /etc/passwd for
all to see.  Best solution is to either implement shadow passwords (and
go to MD5/SHA while you're at it) or just migrate them over to a recent
Linux version.

2) Becoming root generally requires exploiting a hole in sudo or su. 
Depending on your system, /etc/sudoers may be readable (but hopefully
not modifiable) by you.  This might give you an idea as to which
commands you can run as root.  If one of those is a shell script that
you can edit, you are in.  If one of them is a script that you can
suspend or shell out from, life is also good.  However, if the sysadmin
is good at what they do, this shouldn't work.  To protect against this,
make sure that sudo and su are not installed.  If you must have them,
make sure that the sudo rules are written as specifically as possible. 
If you require extreme flexibility, write a secure perl wrapper and use
that to clean up the inputs before running complex commands as root.

NOTE: many editors allow you to shell out.  Never open a rule that
allows you to edit a file as root, as you are effectively giving an
attacker the rights to edit any file or (potentially) execute any
command.

3) Ah, the joys of suid.  See what is installed as suid on the system
with find and see if it is exploitable.  You can use the rpm or deb
databases to determine what versions are installed, and check the
security sites for vulnerabilities.  Then, you can run a command and
kill it to get a shell, or run a command with specific inputs to make it
do something odd.  Note that with network daemons, you can "run a
command" via the TCPIP interface to the system.

NOTE: You can also download rootkits and other hacker tools to do this.
 However, that is profoundly stupid, as there is no guarantee that such
tools will actually do what they say.  It is just as likely to give root
to a random person in Romania as you.  Worse, it could add a permanent
backdoor to your system that someone could exploit after you've fixed
the problem.

NOTE2: This is why I like systems like qmail.  Each daemon runs with
only the permissions needed.  Even if you manage to track the TCPIP API,
all you get are the same privs as a local user on the box.  You may be
able to muck up that service, but you probably can't get much outside of
that jail.  For systems that don't work this, look into use chroot to
jail specific dangerous daemons.

To defend against this, keep your system up to date and remove as many
suid applications as possible.  Legacy network services are particularly
dangerous.  In particular, rsh, sendmail (old), named (old), portmap,
etc are to be avoided.  Use a firewall or packet filter to limit the
traffic to known good ports and if you are lucky enough to have the
skills to filter by protocol, do it.  Also, tools like tripware are
excellent for making sure that your apps are really what you think they
are.  Also, AppArmor can prevent a daemon/app from doing things that the
kernel perceives as "non-standard".  It helps out a lot.

Lastly, if you suspect that someone did something bad, use chkrootkit
and rkhunter to find out what's going on.  However, as my rootkit note
implies, if you've got one, you can't trust the system even if you clean
it up.  Best to rebuild.

Play with fun toys:

http://www.chkrootkit.org/
http://www.rootkit.nl/

Hopefully, this did not answer your question, but in a satisfactory
manner.





 

-Josh More, RHCE, CISSP, NCLP, GIAC 
 morej at alliancetechnologies.net 
 515-245-7701



>>> "Nathan Stien" <nathanism at gmail.com> 11/28/07 4:30 PM >>> 
Hello Luggers,

I have an instance of Debian unstable that was working just fine until
I decided to play some russian roulette.  That is, I ran "apt-get -u
dist-upgrade" to get latest on everything.  And now find myself in an
interesting situation.  (Luckily it's just a testing sandbox in
vmware, and not at all mission critical.)

The machine has mysteriously lost the ability to resolve its own
hostname.  This is a problem because sudo for whatever reason needs to
resolve the hostname in order to let me do anything.  This machine has
an ubuntu-style setup with respect to sudo -- the root account is
locked.  I can't just "su root".

OK, I says to myself, I'll just add the hostname to /etc/hosts and
move on with life.

nathan at lildeb:~$ sudo vi /etc/hosts
sudo: unable to resolve host lildeb

Ohhhhh, yeeeaaahhh.  D'oh.

So I ended up doing a ctrl-alt-del to get it to reboot, then I hit 'e'
at the grub menu to edit the boot params to include "init=/bin/bash".
I did "init=/bin/bash" because Debian regular single user mode still
requires a root password, which does not exist.

Then booted and remounted the root as writable:

mount / -o remount,rw

Then did my vi /etc/hosts business.

Then put things back how I found them:

mount / -o remount,ro
sync
reboot

This all seems pretty terrible, hackish, and old-timey.  What more
elegant methods, if any, might I have used to fix this situation?
What if I had not been local and able to ctrl-alt-del?  Is there
something I might have done to avoid rebooting at all?  Is it just
unforgivably stupid to lock your root account?

- Nathan
_______________________________________________
Cialug mailing list
Cialug at cialug.org
http://cialug.org/mailman/listinfo/cialug