Pentesting a Linux server

What's going on guys, c'est Zack et bienvenue dans cette nouvelle leçon dans laquelle on va réaliser un cas pratique de test d'intrusion sur un serveur Linux.

As we explained in the previous lesson, this will help you acquire experience in real conditions.

In the field of pentest, the technologies to audit are very varied: mobile penetration testing, web applications, malware analysis, reverse engineering, infrastructure and operating system pentest, etc.

Today, we are going to study a Linux operating system, also integrating the analysis of its web application.

As for Linux, the only prerequisites are knowing how to use the basic commands of Linux and mastering the fundamental concepts of IT security.

If you are starting on Linux, I refer you to my complete course on Kali Linux available on Udemy.

We will see the case of a Windows system in the next lesson.

For this challenge on TryHackMe, we are going to use the room called "Basic Penetration Testing".

This room also includes a demonstration by John Hammond who explains his resolution, but we are going to do it together.

I click on the green "Start Machine" button and I first make sure that I am well connected to the VPN network by pinging the address `10.10.10.10`.

The ping responds, the connection is therefore active.

On TryHackMe, I have several challenge tabs open, because I train daily on the platform to perfect my pentester skills.

In this lab, we are going to cover several techniques: password brute forcing, hash cracking, port and service enumeration, as well as a Linux system enumeration.

The goal is to learn as many concepts as possible.

This challenge was created by Josiah Pearce and was initially available on VulnHub.

The first task consists of deploying the machine and connecting to the VPN, which is already done.

The next step is to identify the services exposed by the machine.

The target IP address is displayed on the challenge page (in my case, I have a premium account so the machine is reserved for two hours, compared to one hour for the free plan).

If you do not have a local attack machine, you can launch the Attack Box of TryHackMe.

To enumerate the active services on the target, we will use Nmap.

We launch a full aggressive scan with the command `sudo nmap -A -Pn <IP_cible>`.

In a real pentest, we generally avoid using the aggressive parameter `-A` because it generates significant network traffic and gets spotted immediately by intrusion detection systems (IDS/IPS).

We add `-Pn` to skip the discovery ping (ICMP) in case the target's firewall blocks it.

While the scan runs, we verify our connectivity.

Also think of keeping your tools updated on Kali Linux by regularly running a `sudo apt update && sudo apt upgrade`.

The next question of the challenge asks us for the name of a hidden directory on the web server.

There is therefore an active HTTP server.

By opening the IP address in our browser, we land on a web page under maintenance.

By displaying the page source code ("View page source"), we spot an interesting comment: "Check our dev_note section if you need to know what to work on".

This tells us the existence of a development note.

The Nmap scan ends.

It reveals several open ports to us: port 22 (SSH running OpenSSH 7.2p2 on Ubuntu), port 80 (Apache httpd 2.4.18), ports 139 and 445 (Samba/NetBIOS on Linux/Ubuntu), port 8009 (AJP13) and port 8080 (HTTP Apache Tomcat 9.0.7).

The OS detection confirms that the target is a 64-bit Linux machine.

The SMB protocol analysis shows that message signing is enabled but not required, which constitutes a classic configuration weakness.

For port 8080, if we open it in our browser (`http://<IP_cible>:8080`), we land indeed on the default Apache Tomcat version 9.0.7 interface.

To answer the question concerning the hidden directory on the web server (on port 80), we are going to perform a directory brute forcing with a fuzzing tool.

Instead of DirBuster, Gobuster or dirb, I use Feroxbuster, which is much faster and more efficient.

I launch the command: `feroxbuster -u http://<IP_cible> -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -k`.

The `-k` option allows ignoring SSL/TLS certificate errors.

Feroxbuster starts fuzzing and quickly discovers a directory named `/development/`.

By navigating to `http://<IP_cible>/development/`, we access the folder.

It contains two files: `dev.txt` and `j.txt`.

In `dev.txt`, we can read a note from a developer indicating that they tested the Struts technology (version 2.5.12) and configured the Apache server and SMB sharing, specifying that they will add content later.

In `j.txt`, a user writes that they audited the `/etc/shadow` file (which contains password hashes under Linux) to ensure the strength of users' passwords, and that they succeeded in cracking one of the hashes very easily.

They ask their colleague to change their password as soon as possible to comply with the company's security policy.

At this stage, we do not have precise usernames yet.

The challenge then asks us to do brute forcing to find a set of credentials.

For this, we must continue our enumeration.

A good practice consists of searching for known vulnerabilities (the "low-hanging fruits") associated with the service versions that we identified.

We can use the `searchsploit` tool which queries locally the Exploit-DB exploit database.

If we type `searchsploit openssh 7.2p2`, we see several vulnerabilities, including a username enumeration flaw and denial of service (DoS) vulnerabilities.

Remember that in professional pentest, the exploitation of denial of service flaws is prohibited because it disrupts the client's activity, but it should be mentioned in the report.

We do the same for Apache 2.4.18.

We are now going to audit the SMB protocol.

This is a very interesting historical protocol in security because it regularly contains weaknesses.

We use the `enum4linux` tool with the command `enum4linux -a <IP_cible>`.

This tool will enumerate Samba shares, workgroups, security policies, and user accounts.

The analysis reveals the existence of open shares, in particular a share named `Anonymous` accessible without authentication, as well as the default share `IPC$`.

We also discover the password policy (minimum length of 5 characters).

Especially, `enum4linux` succeeds in enumerating local users via SID queries and identifies two accounts: "Kay" and "Jan".

We now have our two target users.

The question "What is the username?" corresponds to one of these two accounts.

After testing Kay, it is indeed the user "Jan" who is validated.

We must now find his password by brute force.

To attack the SSH service on port 22, we will use the `hydra` tool (we could also use Patator, or Burp Suite if it were a web interface).

The command is as follows: `hydra -l jan -P /usr/share/wordlists/rockyou.txt <IP_cible> ssh`.

If you need help configuring other protocols with Hydra (such as FTP, RDP or POP3), you can consult the "Hydra Cheat Sheet" available on GitHub which lists typical commands.

After a few minutes of brute-forcing with the `rockyou.txt` dictionary, Hydra finds Jan's password: "armando".

We can now validate this step on TryHackMe.

The next question asks us what service we used to connect, the answer is "SSH".

We connect via SSH on the target machine with the command `ssh jan@<IP_cible>` and the password "armando".

We validate the host key and here we are connected with a shell on the machine whose host name is "basic2".

The `whoami` command confirms that we are connected under the identity of Jan.

We must now enumerate the system to find a privilege escalation vector.

The first step consists of listing the other users of the machine by consulting the `/etc/passwd` file via the command `cat /etc/passwd`.

We find the classic system users there, as well as the "Kay" account, which confirms our SMB discoveries.

While exploring the system, we go to the `/home` folder.

We find Jan's directory and Kay's directory there.

In Kay's folder (`/home/kay`), there is a file named `pass.bak` (a classic extension for password backups).

However, by checking its permissions with `ls -la pass.bak`, we find that this file belongs exclusively to Kay and that we do not have read rights as Jan ("Permission denied").

It is the same thing for his history file `.bash_history`.

On the other hand, by analyzing his hidden SSH folder (`/home/kay/.ssh`), we find that we have read rights on the files it contains.

If we do a `ls -la`, we discover Kay's SSH private key (`id_rsa`), as well as the `authorized_keys` file.

This is a critical configuration error: the private key of a user is readable by another user.

We are going to retrieve this private key `id_rsa` to connect via SSH under the identity of Kay.

To copy this file to our local Kali Linux attack machine, we can use the `scp` (Secure Copy) utility.

In the terminal of the victim machine, we launch: `scp id_rsa userX@<IP_Kali>:/home/userX/`.

We accept the connection and fill in the password of our Kali machine.

The file `id_rsa` is indeed transferred.

On our local Kali, we modify the permissions of the key so that it is secure: `chmod 600 id_rsa`.

We then attempt to connect under the identity of Kay with the command `ssh -i id_rsa kay@<IP_cible>`.

However, the private key is protected by an encryption key (passphrase).

We must therefore crack this passphrase.

To do this, we will first convert the SSH key into a format understandable by John the Ripper using the utility script `ssh2john` (or `ssh2john.py`): `/usr/share/john/ssh2john.py id_rsa > rsa.hash`.

We obtain the hash file `rsa.hash`.

We then launch John the Ripper with the `rockyou.txt` dictionary to crack this hash: `john --wordlist=/usr/share/wordlists/rockyou.txt rsa.hash`.

In a few seconds, John the Ripper discovers the passphrase of the private key: "beeswax".

We relaunch our SSH connection: `ssh -i id_rsa kay@<IP_cible>` and enter the passphrase "beeswax".

The connection succeeds and we are connected as Kay.

The `whoami` command confirms our new identity.

Now, we can read the backup file `/home/kay/pass.bak` which was previously forbidden to us.

We discover Kay's password there.

This allows us to answer the last question and finish this challenge.

In a real case of penetration testing, we would push the attack until obtaining root privileges (the Linux supreme administrator), for example by checking sudo rights (`sudo -l`), searching for SUID files, or testing if the user reuses their passwords.

This challenge clearly shows the key steps of a security audit under Linux.

I hope you enjoyed this demonstration.

Do not hesitate to practice on TryHackMe on topics like pivoting or privilege escalation.

If you have any questions, ask them in the comments.

We'll meet in the next course!