Hillbilly StoryTime: So, You Got Access to A *NIX System… Now What?

Note to Reader: For simplicity, I will be referring to all Unix, Linux, and other Unix-like systems simply as *nix, unless a specific distinction needs to be made.

As a pentester, you will likely come across a *nix system at some point. If you are like many of the people I have worked with and encountered in the security industry, you are much more familiar with Microsoft Windows-based systems than *nix systems. This is completely fine. Most attackers focus largely on Windows-based systems due to the marketshare, end-user exploitability, and attack surface. Microsoft Windows in 2019 made up over 97% of the most attacked operating system in the ransomware category. In whole, *nix systems can make up a large percentage of the ecosystem of an enterprise (often not the largest), however is often less focused on from an attack surface perspective. In most networks, when you encounter *nix systems, they are typically less prominent than when compared to the numbers of Microsoft Windows based systems. Common uses of *nix systems tend to be development systems, mobile devices, database systems, embedded devices (firewalls, web cameras, etc.), web services such as jBoss, Tomcat, or Jenkins, and cloud infrastructure such as AWS. Whereas Microsoft Windows is much more commonly found running on end user workstations, email systems, and, of course, domain controllers (as well as other roles found in *nix).

While *nix systems are significantly different from Microsoft Windows systems, they do share some common categories of vulnerabilities, such as insecure network shares, vulnerable web services, user/system trusts, buffer overflows, and misconfigurations.

Once you identify a *nix system you wish to attack, you need to decide what approach you want to take. You do not always need to have a shell session on a *nix system, nor do you always need to be ‘root’. Sometimes, mounting exported NFS shares is enough for you to gain the information you need. A common misconfiguration on *nix systems is to export a network share without restricting it to certain IPs or users. As an attacker, you can identify any access restrictions on the target NFS shares by using the showmount command.

showmount -e 192.168.1.1
Export list for 192.168.1.1:
/secret 192.168.1.2
/home (everyone)

The above example shows that 192.168.1.1 is exporting/sharing two directories. One of them, ‘/secret’, is restricted such that it can only be mounted from 192.168.1.2, whereas the other, ‘/home’, can be mounted by ‘(everyone)’. In this scenario, I would mount the ‘/home’ share locally and then search through it and its subdirectories looking for interesting files. A couple of the files I may look for are SSH keys and .history or .bash_history files to see if they contained passwords. I have found entire database backup files stored in user home directories in the past, as well as documents containing lists of sensitive passwords for all kinds of internal systems. When I find an open NFS share, I always take the time to investigate it.

However, many times you will want shell access, so you will need to first find a way onto the target system. This could be as simple as connecting to the system via SSH or telnet with weak user passwords or possibly by exploiting known vulnerabilities/misconfigurations in network/web services. The most common access to a *nix system that I have encountered is via password brute-forcing/guessing, default/blank credentials for jBoss/Tomcat/Jenkins/etc., sniffing credentials from network traffic, and finally via remote service exploits.

Note to Reader: For the remainder of this article, we will assume you have obtained a shell session on a *nix system.

Once shell access to a *nix system has been obtained, the first item I usually address is whether I have a fully functional shell. You will usually be able to quickly identify if you have a limited shell (usually as a result of a web exploit, service command injection, or some other shell access which was not via SSH or telnet), as the lack of a prompt is a great indicator. To remedy this situation, my typical go-to solution is to spawn a new bash shell via python, assuming python is present on the system. Keep in mind that python may not be present, but python3 is, so adjust accordingly.

python -c 'import pty;pty.spawn("/bin/bash")'
user@192.168.1.1:/var/www/$

Unfortunately, this does not provide tab completion. If you are fine with that, then skip this section, otherwise, this is how to correct it. First, you will need to press Control-Z to send the shell to the background. Then type stty raw -echo. This is a command that is responsible for allowing our bash keyboard shortcuts to pass through to the remote shell. Now we need to get back to the remote shell, so type fg. This should bring the remote shell back from the background. Finally, type reset to reset the terminal.

stty raw -echo
fg
reset

In most cases, this should be fine. However, you may occasionally notice that the up arrow is not working or that you cannot clear the screen. To address these issues, type the following:

user@192.168.1.1:/var/www/$ export TERM=xterm
user@192.168.1.1:/var/www/$ export SHELL=bash

With that out of the way, you will now want to get a ‘lay of the land’. This includes identifying your access level, the OS version, which (if any) sensitive files you have access to, and seeing which LOLbins (Living off the Land) (https://gtfobins.github.io/) scripts and programs you can access.

uname -a – Current kernel version
env – Current environment variable
pwd – Current directory
whoami – Current user
history – Command history for current user
cat ~/.bash.history – Bash history
sudo –1 – Commands you can run as sudo
cat /etc/sudoers – Who is in sudoers file
cat /etc/passwd – Additional users
find / -perm /4000 -ls – Find accessible SETUID files

You can definitely do this by hand, manually typing each command and gathering the output, or you could use one of many enumeration tools that people have developed to assist. Here is a short list of some I use:

LinEnum (https://github.com/rebootuser/LinEnum)
LinuxPrivChecker (https://github.com/sleventyeleven/linuxprivchecker)
UnixPrivescCheck (https://github.com/pentestmonkey/unix-privesc-check)

At this point, you could attempt a privilege escalation attack to root or some other privileged user account. That said, I would suggest investigating the files available as the current user, as you do not always need to be root to gain access to the data you want.

If you find you do need access to root or some other privileged user account, you may be able to use the data gathered previously to elevate your access or you may wish to use a different known exploit such as DirtyCow or DirtySock. It is usually a quick process to determine which exploits will work by looking at the output of uname -a for the kernel/OS version and then searching Google or https://www.exploit-db.com/ for possible exploits. If you wish to approach it in a more scripted manner, you may wish to look at the Linux Exploit Suggester 2 script (https://github.com/jondonas/linux-exploit-suggester-2).

This article is in no way a complete how-to on *nix systems, but I hope it provided you with some basic level of insight into attacking *nix systems and some thoughts as to what tools/capabilities you have to work with.

In parting, here are some additional resources for you on attacking *nix systems. Enjoy!