Injection is a high-category vulnerability in web applications. Attackers and security auditors alike always try to find the kind of vulnerabilities which allow them to perform a command execution. There are a number of vulnerabilities in the category of command execution, and one of them is Server Side Includes (SSI) Injection. So, this article is completely based on SSI Injection and for is noobs.

What is Server Side Includes?

Server side includes is highly useful feature for web applications. This feature helps you to add dynamically generated content to an existing page without updating the whole page. Suppose you need to update a small part of a web page almost every minute, without updating the whole page. So, this feature must be supported from the web server and enabled as well.

SSI Injection

We are going to exploit this functionality by injecting our mean code. First, it’s a server side exploit because an attacker sends some malicious code into a Web application which is executed by the Web server. An SSI injection attack exploits a web application by using arbitrary codes remotely. Use the below command to check whether the site is vulnerable to SSI injection or not:

<!–#echo var=”DATE_LOCAL” –>

The above command returns the current date and time.

Next, find sites which are vulnerable to SSI injection. For this, Google dorks will always be a better option:

Inurl:bin/cklb

There are number of results (sites) provide by Google. Open the sites and inject into the input fields such as search, login/password, etc. Please note that this is totally illegal to do without permission of the website owner. So, I am use vulnerable labs to perform this attack. Below is a picture of two input fields:

The above two fields are a functionality of IP lookup. Enter your name and press the Lookup button, but instead of name, enter some server side include scripts which are shown in the further response to your page.

Above I enter ” <!–#echo var=”DATE_LOCAL” –> ” script in the first field to check whether the site is vulnerable to SSI injection or not, and in the second field I enter whatever I wish.

I run bWAPP vulnerable web application to demonstrate this problem. Above the SSI script runs and responds with current date and time. For further exploitation, I show only commands, not POC for that.

After the above observation, the next script is to check whether command execution is possible or not. If you want to check the current user on the server, use this <!–#exec cmd==”whoami” –>. It shows the details of the user running on the server. The next step is to upload a web shell.

I used a Linux-based vulnerable app to perform this attack and it’s helpful to understand this concept.

Conclusion

Nowadays every Web server has a default configuration that allows SSI but not the exec feature. Upgrade the Web server or make sure your server is properly configured.

References:

https://www.owasp.org/index.php/Server-Side_Includes_(SSI)_Injection

https://www.owasp.org/index.php/Testing_for_SSI_Injection_(OWASP-DV-009)