Welcome back.
Time to cover our first real vulnerability, even though HTML injection is considered, the bug command
injection is much, much more serious.
So what is command injection?
Well, we can define it like this command injection is a vulnerability that allows an attacker to execute
operating system commands on the server that is running the application.
Typically, once it's discovered, it allows the attacker to fully compromise the application and all
of its data, sometimes command rejection can be used to compromise other parts of the host's infrastructure,
and it can be used to pivot the attack to other systems within the organization.
So, yes, it can be really serious vulnerability.
It allows us to execute system commands on the server, which could also mean that we can see the files,
check out the passwords folder, delete files and perhaps even set a reverse shell connection.
But how exactly do we do that and when can we find this bug?
Let's check out an example.
In theory, say we have a simple Web application that lets people read different stories.
It gives you a list of stories that it has available and you type in which one you want to read.
Let's say that those stories are stored in text files on the server, once a client pipes in the name
of the story that they want to read, the server processes, the content of the stories, the text file,
and outputs it back to the Web page.
Now, this is a very simple example, but it will give us a good understanding on what exactly is command
injection.
And what we saw right here was a normal usage of this Web application.
But the problem can occur if the website processes the content of the story itself through its system
without the user input being filtered as to what characters and what comments can it receive.
Let me explain this a little bit better.
For example, let's say this application reads the content of the text file with the help of the cat
comment.
We type in the story name and it gets the story, reads the output and throws it back to the Web application
for us to read all of this is good.
But what happens if we enter this, for example?
Story one that the SEMICON who am I?
And here is where our Terminal Command's knowledge comes in play.
What we did right here is we simply typed this story that we want to read.
Then we used semicolon to add another command that the server should execute, which in our example
is who am I?
And by the way, semicolon can be used to separate multiple commands.
It's just one of the ways that you can separate multiple commands and execute them one by one.
So now the command that the server would process would no longer be just cat story 1.0, but it would
look something like this cat story one, the text.
And then after it executes that, it would execute who am I?
And if the website is vulnerable to command ejection and it doesn't filter our input, we will get an
output like this.
It would output a story.
And at the end we should also see the response of the Who am I command?
Which can be viewed or the account name that execute the command.
So in general, the process looks something like this.
We find a user input that could potentially get processed by the system.
We add normal input and concat additional command to it.
And if the input isn't filtered, it will process both of those commands and it will give us both of
these results.
Now, let's see how that looks like in practice.