eJPT - 3.1 System or Host Based Attacks (II)

Exploiting Linux Vulnerabilities
We have covered some of the notes for this section previously, including CVE-2014-6271 - Vulnerability Assessment Page.
FTP
The first step as normal is to run a Nmap scan. In this case, we are running ProFTPD. You can check if anonymous login is enabled or not using the Nmap script ftp-anon
. In this case, we will performing a brute-force with Hydra. Note that you can also use Searchsploit to find exploits for the specific version of ProFTPD.
View some of the notes for this section here - Enumeration Page.
SSH
Note that if key-based authentication has been setup, we cannot really exploit SSH as we will need the private key. However if, as it is in some cases, it can been setup with username and password authentication, then we can brute-force those credentials and exploit it. We will exploit it in the same way we did for FTP. To connect via SSH:
ssh username@target_ip
View some of the notes for this section here - Enumeration Page.
SAMBA
This is essentially the Linux implementation of SMB. We can exploit it in a similar way to how we exploited it with Windows. However, in this case, we will be brute-forcing credentials and then gain access. Similar process to FTP here as well. Once we have obtained credentials, we can use a tool called smpmap
to view the shares.
smbmap -u username -p password -H target_ip
To list and access these shares, we can use a tool called smbclient
.
smbclient -L target_ip -U username
smbclient //target_ip/share_name -U username
We could also use the enum4linux
tool to enumerate information.
enum4linux -a target_ip
enum4linux -a -u username -p password target_ip
View some of the notes for this section here - System or Host Based Attacks (I) Page.
Linux Privilege Escalation
Linux Kernel
Kernel exploits on Linux will typically target vulnerabilities in the Linux kernel to execute arbitrary code in order to run privileged system commands to obtain a system shell. This process will differ based on the kernel version and distribution being targeted and the kernel exploit being used.
Privilege escalation on Linux systems will typically follow the following methodology:
Identify kernel vulnerabilities
Downloading, compiling and transferring kernel exploits onto the target system
We will be using the tool Linux-Exploit-Suggester. it is designed to assist in detecting security deficiencies for the given Linux kernel version. It assesses the exposure of the given kernel on every publicly known Linux kernel exploit. It can be found on GitHub here. Again, note that kernel exploit can cause crashes and data loss. You will also need to have already obtained access to the target system as you have to transfer the exploit suggester to the target system.
Once you have run it on the target system, keep a note of the kernel version, the architecture, the distribution and the distribution version. In this case, we'll be looking at the dirtycow exploit with the CVE code of CVE-2016-5195. Head over to the exploit database website and have a look at how to compile and run the exploit code.
Cron Jobs
Linux implements task scheduling through a utility called Cron. Cron is a time-based service that runs applications, scripts and other commands repeatedly on a specified schedule. An application or script that has been configured to be run repeatedly with Cron is known as a Cron job. It can be used to automate or repeat a wide variety of functions on a system, from daily backups to system upgrades and patches.
The crontab file is a configuration file that is used by the Cron utility to store and track Cron jobs that have been created. Cron jobs can also be run as any user on the system, but we will be targeting Cron jobs that have been configured to run as the 'root' user.
This is primarily because any script or command that is run by a Cron job will run as the root user and will consequently provide us with root access. In order to elevate our privileges, we will need to find and identify Cron jobs that have been scheduled by the root user or the files being processed by the Cron job.
There are multiple vulnerabilities or misconfigurations with Cron jobs and in this case, we'll be looking at if there is a shell script being run in a Cron job. We can check what permissions are on that shell script and exploit it by adding in our own commands.
In this case, we are already given access to the target system as a user with low privileges. We are not in the sudo group either. To find out the Cron jobs that have been set by the 'root' user, we know that there is a file on the home directory that is owned by the 'root' user. We can use the grep tool to look for whenever the file path to that file is ran.
grep -rnw /usr -e "/home/student/message"
We can see that the file is available in the Temp directory and we can read the contents of it. To check if we have permissions to edit or execute the shell file that the file is being called in.
ls -al /usr/local/share/copy.sh
Since all users do have edit and execute permissions, we will try to add ourselves to the administrators group so that we can gain 'root' privileges.
printf '#!/bin/bash\necho "student ALL=NOPASSWD:ALL" >> /etc/sudoers' > /usr/local/share/copy.sh
sudo su
And now, we have elevated our privileges to the root user.
SUID Binaries
In addition to the main 3 file access permissions (read, write and execute). Linux also provides users with specialized permissions that can be utilized in specific situations. One of these access permissions is SUID (Set Owner User ID) permission. When applied, this permission provides users with the ability to execute a script or binary with the permissions of the file owner as opposed to the user that is running the script or binary.
SUID permissions are typically used to provide unprivileged users with the ability to run specific scripts or binaries with 'root' permissions. It is to be noted that the provision of elevated privileges is limited to the execution of the script and doesn't translate to the elevation of privileges. However, if it's not configured properly, then unprivileged users can exploit those misconfigurations or vulnerabilities within the binary or script to obtain an elevated session.
This is the functionality that we will be attempting to exploit in order to elevate our privileges. The success of our attack will depend on the following factors:
Owner of the SUID binary - given that we are attempting to elevate our privileges, we will only be exploiting SUID binaries that are owned by the 'root' user or other privileged users
Access permissions - we will require executable permissions in order to execute the SUID binary
In this case, we are already given access to the target system as a user with low privileges. We are not in the sudo group either. There is a binary called welcome in which it has the x permission which allows us to execute the file. It also has the s permission which is the SUID permission.
We can type strings and then the file to look at the binary file closely. It executes an external binary called greetings. So if we can edit or change the file greetings to run what we want, we can elevate our privileges.
rm greetings
cp /bin/bash greetings
Since it will run the greetings binary again, it will run a bash session which will elevate our privileges to the 'root' user. Another attack vector is to find missing shared objects which are being called upon by the SUID binary and then creating your own shared object.
Linux Credential Dumping
Unlike Windows, we cannot really use hashed passwords for authentication. We can only use these hashes for cracking, which we will explore later.
Linux has multi-user support, and therefore, multiple users can access the system simultaneously. This can be seen as an advantage and disadvantage in that multiple accounts offer multiple access vectors for attackers, and therefore increase the overall risk of the server.
All the information for all account on Linux is stored is the passwd
file location in :/etc/passwd
. We cannot view the passwords for the users because the passwd
file is encrypted and readable by any user on the system.
All the encrypted passwords for the users are stored in the shadow file, which can be found in the following directory :/etc/shadow
. The shadow file can only be accessed and read by the root account, this is a very important security feature as it prevents other accounts on the system from accessing the hashed passwords.
The passwd file gives us information in regards to the hashing algorithm that is being used and the password hash. This is very helpful as we are able to determine the type of the hashing algorithm that is being used and its strength. We can determine this by looking at the number after the username encapsulated by the dollar symbol.
$1 - uses the MD5 hashing algorithm
$2 - uses the Blowfish hashing algorithm
$5 - uses the SHA-256 hashing algorithm
$6 - uses the SHA-512 hashing algorithm
In this case, we need to exploit the target first, so we can run an Nmap scan. We can see that its running ProFTPD on port 21. We can now use Searchsploit to find an exploit. In this case, there is a Metasploit module available to use.
We now have a shell session. So we can run /bin/bash -i
. We can then elevate it to a meterpreter session by putting into the background and running the following command.
sessions -u (session_id)
Since we have 'root' access, we can open the shadow file. We can also search for the Linux hashdump
module on Metasploit.
That’s it for this section. Next one up is the CTF or skill check that iNE has put up.
— Hmad
Subscribe to my newsletter
Read articles from Hmad directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Hmad
Hmad
I'm a cybersecurity enthusiast with a growing focus on offensive security. Currently studying for the eJPT & ICCA, building hands-on projects like Infiltr8, and sharing everything I learn through blog posts and labs.