previously we covered blind or s command
injections where the command was getting executed
on the target server but we were not getting the result of the command execution
in the response.
Therefore we use commands that will delay the execution of the application
to verify that the target application is vulnerable to a command injection.
Now in some cases you might encounter blind or s command injection
where the command is going to be executed on the target application
but it's going to be executed in a new thread.
So you can imagine the yellow line in here is
the main application and once you inject a command into it
it's going to be executed in a new thread.
Therefore if you use a command to delay the execution of the application
similar to what we did in here when we use the sleep command
that command is going to be executed in the new
thread and it's going to sleep for 10 seconds.
But the Web application is going to continue running
without any delays.
And therefore even though your command is getting executed
you'll have no way of validating that because there
is nothing for you to observe to tell you
that your command got executed in the background.
Let me show you a quick example of this.
The vulnerable feature is the submit feedback. So I'm going to go directly to it
and we're just gonna submit some dummy data
and in a real life scenario you want to send it,
observe the result and then intercept it but you already know
the sequence now so I'm not going to keep doing it.
I'm just gonna turn on my interceptor and I'm gonna send it.
We have the request in here
and I'm actually just going to right click and send it to the repeater.
So I can continuously modify the request in here and analyze
the response and try to discover vulnerabilities based on that.
Also as mentioned,
you want to test every single value that is being sent after the equal
sign but I know already the vulnerable parameter right here is the email.
So we're gonna test it similar to how we tested the previous vulnerability.
So we did or or we put the command which was sleep for 10 seconds and we did or at the end.
So in a normal scenario I would try with calm at first
I would try normal commands and see if I get the response
but I already know that I will get nothing in the response
and I already know that this works from the previous example.
That's why we're going straight away with this
because we're covering a completely different point.
So I'm going to click send
and as you can see I got the result instantly.
Unlike what happened in the previous example
where the application slept for 10 seconds.
And that is because as I mentioned earlier
this application is continuing to run in the main thread and the command
that I'm injecting the sleep for 10 is being executed in the background
and therefore there is no clues for me in here to tell me that my command got executed.
Therefore to get around this,
you're going to have to use a command such as the pink or the ns.
Look up command
to cause the target web application
to send a request to another server that you control.
And then by observing the logs on the server that you control on the cloud,
you'll be able to see that the target web application
has made a request to the server that you specified
indicating that it executed the command that you injected.
You could create your own hosting on the cloud and I
cover how to do that in my cloud course for free.
And you'll be able to test for such vulnerabilities.
So you'll just have to inject the ping command to
whatever address that you're going to have for your server.
But because this is a lab that is available for everybody on the internet,
it's a little bit more restrictive.
So the people that created this lab can figure
that especially to only work with Burp suite.
So in a real life scenario,
you should be able to use your own server and
just run the ping command to your own server.
But because this is a lab that is made by the people that created Burp suite,
it's restricted to only work with Burp suite.
So I have the pro version and I'm going to use the
collaborator feature of Burp so you can get that by clicking on burp
and click on Burp collaborator client.
This feature allows you to generate a domain name. So if I click on copy to clipboard
I'm gonna get a domain name
that I can make requests to and I'll be able to see the results easily in here.
So instead of having to create your own server
on the internet and manually looking at the logs
I can simply click on copy to clipboard.
It's gonna create a domain name for me that is
available to anybody that is connected to the internet.
And let me show you quickly if I open up a web browser
and paste the link from my clipboard,
you'll see that the request is going to be valid
and you're just going to get a unique token.
And if I go back to Burp
you'll see that it's telling us
that somebody which is myself has made a request to my burb collaborator link.
So if I actually click on the request as well I can see
that there was a DNS look up. So somebody pasted this link in their U. R. L. Bar.
I can see the I. P. That generated that request and I can say the date and time.
So I'm going to clear all of the results in here.
I'm gonna do command a to select them right click and clear
and I'm gonna pace the exact same link
in my injection in here. So instead of doing sleep I'm going to do an N. S.
Look up.
So this is a command that can be used to map a domain name to its I. P.
And the way you use it is you type the command name
followed by the domain name that you want to query and the domain
name is going to be the domain name of your own server
or in my case is the domain name of my burp collaborator.
So I'm doing Ns look up the domain name of my burb collaborator right here.
If this target web application is vulnerable to an
Os command execution vulnerability is going to perform the Ns
look up to this particular domain name and therefore I
should see the result in here in my collaborator.
So I'm going to click on sand
and we're gonna go back to my collaborator.
I'm going to click on paul now to refresh the results
and perfect as you can see we have DNS requests being made
to my collaborator domain.
It's given me the I. P. That made these requests.
So this is the I. P. Of the server that is hosting the target application
and this will serve as proof that the target web application is vulnerable to
a command execution vulnerability because we managed
to get it to execute the Ns look
up command and we have a proof of that command being executed because the web
server did actually send the request to the server that is controlled by us.
And we can see that we received the request in here.
So again, in the bug bounty scenario,
this is more than enough to display that the
target web server is vulnerable in a pen test,
you can inject commands in here that will send
you a reverse connection to your own computer and
from there you'll be able to interactively control the
target web server and possibly compromise the whole network.
And I do cover all of that in my website hacking course,
but it's not really relevant when it comes to bug bounties because what
you have in here is enough to prove that the target is vulnerable.