Bind Shell and Reverse Shell with Xoda Vulnerability
All thanks to Pentester Academy. (Not a promotion)
All the information mentioned in this article are of my own and aren’t the related to my past or present employer.
World of Web Security is a dynamic and ever-changing. To keep up with it requires a lot of hard work.
Theory won’t help you much, unless you apply them in the real time scenarios.
To become skilled security professional from a script — kiddie; we need to understand the role of Bind Shell and Reverse Shell in pen testing.
In layman terms, both are just a remote connection established between attacker and victim.
Unless you’re familiar with Unix, you would also be wondering, “What’s shell?”.
In simple terms, a shell is a software that acts as an intermediary between user and the kernel. It provides the user an interface which provides access to the services of kernel.
(Pic Credit: irichmore)
In this case, binder shell is running on the victim’s machine. It opens up a port in the system for communication. The attacker connects with that port to hack into victim’s machine.
(Pic Credit: irichmore)
Reverse shell does the opposite. Here the port is open at attacker’s machine. And the victim connects to that open port.
XODA: Xoda targets the end-user allowing organizing of documents in a professional manner.
Perform a port scan with nmap.
We found two ports open port 80 and 3306. We will be focusing on port 80 only.
Browse http://ipaddress .
We can see web application XODA hosted on this IP on port 80.
Type msfconsole to open Metasploit.
Then you will be seeing the terminal like this.
Here we are trying to exploit XODA web application. So , we will search for the exploit available in the metasploit module.
Please note that the original name of the vulnerability is “XODA 0.4.5 Arbitrary PHP File Upload Vulnerability”.
Attackers can abuse the “upload” command in order to upload a malicious PHP file without any authentication, which results in arbitrary code execution.
We’ll use this exploit/unix/webapp/xoda_file_upload on the target.
Type “show options”. You’ll see the terminal like this below.
You’ll have to set the RHOSTS to victim IP address i.e. 188.8.131.52.
We have set TARGETURI to “/” as the Web application URI is without any module or you can set it by default like this.
Once you set up it, it will look like this. Duly note that, you have to set payload before you run it.
This is most important set of this exploit. Also, this is what we are trying to learn.
Once you type “show payloads” and enter. You’ll see a list of payloads.
Here you require only SL no.1 and SL no.2 for the way forward. For now, we will use only generic/shell_bind_tcp.
Again “Show Options” command.
Now you can see payload options too.
You can see now a command shell session is opened.
The response says it all. The remote shell is executing our command.
Type “ps -eaf”. Here ps is for processes. ps command is used to list the currently running processes and their PIDs along with some other information depends on different options.
If you look at the last snapshot , you’ll find the processes running on the victim’s machine(184.108.40.206) towards the attacker’s machine(220.127.116.11.).
To confirm the same, we will run netstat -tnp on attacker’s machine.
Now you can see the first process is running, clarifies the connection details.
The set-up will happen in the same way as bind shell. The differences, you will find about LHOST(below fig).
And the payload, we will use “generic/shell_reverse_tcp.” (below fig).
At the end, to be sure about your activity , you will have to run netstat -tnp on attacker’s machine. And you’ll find to and forth connections for this.
I am not explaining the reverse shell in detail because, it’s completely same process as bind shell. The difference is shown in above snapshot. Also, a little curiosity is left for your security mindset.
This article is dedicated to the people who lost their life in the Covid-19 pandemic.