Introduction
In this video walk-through, we covered Linux Privilege Escalation through navigating through configuration and history files. This was part of Linux PrivEsc Room.
If a user accidentally types their password on the command line instead of into a password prompt, it may get recorded in a history file.
Config files often contain passwords in plaintext or other reversible formats.
Abusing Older Bash Versions
First, I take a look at a program with the SUID bit set, called suid_environment2
. This program is designed to be more secure than its predecessor because it uses absolute paths for the commands it runs, which prevents simple environment variable manipulation.
However, I notice that the system is running an old version of Bash (4.1.5). Versions of Bash older than 4.2 have a neat little vulnerability: you can create and export shell functions that will override system commands.
Here’s how I exploit it:
- The
suid_environment2
program calls theservice
command. - I create my own shell function, also named
service
. - Inside my function, I simply tell it to spawn a new Bash shell with root privileges (
/bin/bash -p
). - I then
export
this function. Now, whenever any program (including our SUID executable) tries to runservice
, it will run my malicious function instead. - I run
/usr/local/bin/suid_environment2
, and just like that, I get a root shell!
Snooping Through History Files
This one is a classic for a reason. Sometimes, users (even admins!) get careless and type passwords directly into the command line instead of into a secure prompt. These commands often get saved in history files.
I demonstrate how to search for hidden history files (like ~/.bash_history
or other files with “history” in the name) to find these little golden nuggets. In my example, I find a MySQL command with a plaintext password right there for the taking. With that password, I can easily switch to the root user.
Checking Configuration Files
Developers and system admins are often in a hurry, and sometimes they leave sensitive information, like passwords, in plaintext within configuration files. I always make it a point to check common configuration files for web servers, databases, or even VPNs.
In my example, I find a VPN configuration file (myvpn.openvpn
). Inside, it references another file, pass.txt
, which, you guessed it, contains the user’s credentials in plain text.
Stealing SSH Keys
Another prime target for any penetration tester is SSH keys. If you can find the private SSH key of a privileged user, you can often just log in as them, no password required.
I show how to look for the hidden .ssh
directory in a user’s home folder. Inside, I find a private key file named root_key
. I copy the contents of this key, save it to a file on my own machine, set the correct permissions (chmod 600
), and then use it to SSH into the target machine as the root user.
To prevent this kind of attack, I explain that it’s crucial to set strict permissions on the .ssh
directory and the private key files. It’s also a very good practice to disable root login via SSH entirely in the sshd_config
file.
Technical Commands
Here’s a list of the commands I used throughout this demonstration:
ls -la /usr/local/bin
strings /usr/local/bin/suid_environment
strings /usr/local/bin/suid_environment2
/bin/bash --version
function service { /bin/bash -p; }
export -f /sbin/service
/usr/local/bin/suid_environment2
id
exit
cat ~/.bash_history
su root
ls -la /home/user
cat /home/user/myvpn.openvpn
cat /home/user/pass.txt
ls -la
cd .ssh
cat root_key
nano id_rsa
chmod 600 id_rsa
ssh -i id_rsa root@<IP_ADDRESS>
TryHackMe Room Answers
What is the full mysql command the user executed?
What file did you find the root user’s credentials in?