Putting It Together
This demonstration will walk through exploiting a remote target.
Some common enumeration steps
will be skipped to keep the length of this section to a minimum.
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.
The web application and its version
are located near at the bottom of the source code page.
Upon further investigation,
we can determine that it is a free web-based project management software.
With this new discovery, we’ll search Exploit DB for a remote exploit.
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.
Another method of getting an account password
would be to use a list generator on the website.
After a word list is generated,
we can try the list as-is or make changes to create more complex passwords.
We won’t demonstrate these steps as they are covered elsewhere in the course,
but using a dictionary attack on the login portal
along with the four discovered e-mails,
we can verify the 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.
With the exploit in our current working directory,
let’s execute it against the target path with the found credentials.
The exploit arguments were determined from reading the source code,
along with the usage section of the script.
Not all exploits have a usage section.
Unlike this exploit,
some exploits require changing variables within the source code before execution.
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.
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 netcat 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.
We find that nc is installed on the target machine.
New Caption
Let’s create a netcat listener on port 6666
and attempt to get a reverse shell from the target to our Kali machine.
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.
The reverse shell is executed through the webshell uploaded by our exploit.
Let’s switch to the netcat listener terminal session
to find out if a connection was established from the target.
The netcat reverse shell successfully connected to our Kali machine,
and we are currently the www-data user.
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.