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.

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

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)