TrustedSec - 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. Many years ago, *nix systems were much more commonplace, but now they tend to be found mostly in larger organizations, government networks, healthcare facilities, universities, and CTF competitions. In most networks, when you do encounter *nix systems, they are relatively few in number when compared to the numbers of Microsoft Windows based systems. Common uses of *nix systems tend to be development systems, database systems, embedded devices (firewalls, web cameras, etc.), and web services such as jBoss, Tomcat, or Jenkins, whereas Microsoft Windows is much more commonly found running on end user workstations, email systems, and, of course, domain controllers.
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!
- G0tmi1k’s ‘Basic Linux Privilege Escalation’ Article:
- IppSec YouTube videos:
- Null Byte YouTube video discussing Linux Exploit Suggester 2:
- Details and exploit for Dirty Sock exploit
- Details and exploits for DirtyCow exploit
For additional practice in attacking *nix systems, consider:
- HackTheBox.eu
- VulnHub
- Metasploitable
The post So, You Got Access to a *nix system… Now What? appeared first on TrustedSec.
from TrustedSec https://www.trustedsec.com/blog/so-you-got-access-to-a-nix-system-now-what/
Comments
Post a Comment