Http Parameter Contamination (more)
Continuing the study of the Http Parameter Contamination (HPC) attack , I carried out primitive fuzzing, including in environments that were not affected by Ivan Markovic in his original study. It should be noted right away that nothing fundamentally new was found. On the other hand, an interesting feature of the Python interpreter was revealed, as well as a received combat split for denial of service in relation to the Tomcat server :) But according to the latter, so far non disclosure.
The results are presented in the picture below.

* The character "\ 0" means that null-byte is correctly processed by the application.
The most interesting features are highlighted in dark red. Less interesting, but noteworthy, are highlighted in pale red. Consider the results in more detail.
The greatest value for the attacker is the feature of processing incoming data by an ASP web application. The fact is that an ASP application encounters the “%” character in the parameter name or in its value simply deletes it if it, in turn, does not form the “correct” character during URL decoding . This allows you to quite easily bypass the various security filters and Web Application Firewall that are used before the application processes the incoming data. Ivan Markovic in his study gives the following example of bypassing the Mod_Security rules when exploiting the Path traversal vulnerability:
More vital for the IIS platform is the use of the MSSQL DBMS and the appearance of vulnerabilities in an application such as SQL Injection. Similarly, using this method, you can take advantage of this vulnerability bypassing the corresponding Mod_Security rules:?
Id = 1; selec% t + @% @ version--
? Id = 1; selec% t + convert (int, (selec% t + table % _name + from (selec% t + row_number () + over + (order + by + table% _name) + as + rownu% m, table% _name + from + information_schema.tables) + as + t + where + t.rownu % m = 1)) -
...
Here it is worth making a reservation that we are only talking about bypassing the basic rules of Mod_Security (base rules). In the case of using advanced rules (optional and experimental), such feints no longer pass.
Another, no less useful feature of processing incoming data is found in the PHP interpreter. This is an implicit type conversion ( ? Param [] = 123 -> param = Array ), which everyone should have known for a long time and the ability to control the array $ _SERVER ["argv"] ( ? 1 + 2 ) with the value "register_argc_argv" set to "On". An attacker can use the first feature of PHP to bypass various restrictions (for example, when implicitly comparing variables), as well as to force an error message (to open the root of the web server). The second feature of PHP allows you to access the script through a web server and pass parameters to it that the script accepts from the command line.
A less interesting feature of PHP is the replacement of the characters "+", ".", "[", And "space" with a underscore ("_"). Why is this not so dangerous? The fact is that such PHP behavior is observed only in the names of the parameters passed to the web server, but not in their values. This greatly reduces the likelihood of using this feature in "wildlife."
And the last thing I wanted to pay attention to was the Python interpreter. During fuzzing, it was found that Python encountering characters from the range of% 80-% FF returns an error message (ala disclosure ... and blah blah):

(Appendix)
The scripts used below were used for testing.
PHP:
$ G = & $ _ GET;
foreach ($ G as $ k => $ v)
{
print $ k. "
?>
ASP:
<%
for each var in Request.QueryString
Response.Write (var & "=" & Request.QueryString (var))
next
%>
JAVA:
<%
java.util.Enumeration names = request.getParameterNames ();
while (names.hasMoreElements ()) {
String keyx = names.nextElement (). toString ();
out.println (keyx + "=" + request.getParameter (keyx)); }
%>
PERL:
use CGI;
my $ cgi = new CGI;
my @params = $ cgi-> param ();
print <
HTTP / 1.0 200 OK
Content-Type: text / html
ENDOFTEXT
foreach my $ parameter (sort @params) {
print $ parameter. "=". $ Cgi-> param ($ parameter);
}
PYTHON:
import cgi, os
print ('Status: 200 OK')
print ('Content-type: text / html; charset = utf-8;')
print ("")
query = os.environ.get ('QUERY_STRING ')
pairs = cgi.parse_qs (query)
for key, value in pairs.items ():
print (key, value)
The results are presented in the picture below.

* The character "\ 0" means that null-byte is correctly processed by the application.
The most interesting features are highlighted in dark red. Less interesting, but noteworthy, are highlighted in pale red. Consider the results in more detail.
The greatest value for the attacker is the feature of processing incoming data by an ASP web application. The fact is that an ASP application encounters the “%” character in the parameter name or in its value simply deletes it if it, in turn, does not form the “correct” character during URL decoding . This allows you to quite easily bypass the various security filters and Web Application Firewall that are used before the application processes the incoming data. Ivan Markovic in his study gives the following example of bypassing the Mod_Security rules when exploiting the Path traversal vulnerability:
192.168.2.105/test.asp?file=.%./bla.txtMore vital for the IIS platform is the use of the MSSQL DBMS and the appearance of vulnerabilities in an application such as SQL Injection. Similarly, using this method, you can take advantage of this vulnerability bypassing the corresponding Mod_Security rules:?
Id = 1; selec% t + @% @ version--
? Id = 1; selec% t + convert (int, (selec% t + table % _name + from (selec% t + row_number () + over + (order + by + table% _name) + as + rownu% m, table% _name + from + information_schema.tables) + as + t + where + t.rownu % m = 1)) -
...
Here it is worth making a reservation that we are only talking about bypassing the basic rules of Mod_Security (base rules). In the case of using advanced rules (optional and experimental), such feints no longer pass.
Another, no less useful feature of processing incoming data is found in the PHP interpreter. This is an implicit type conversion ( ? Param [] = 123 -> param = Array ), which everyone should have known for a long time and the ability to control the array $ _SERVER ["argv"] ( ? 1 + 2 ) with the value "register_argc_argv" set to "On". An attacker can use the first feature of PHP to bypass various restrictions (for example, when implicitly comparing variables), as well as to force an error message (to open the root of the web server). The second feature of PHP allows you to access the script through a web server and pass parameters to it that the script accepts from the command line.
A less interesting feature of PHP is the replacement of the characters "+", ".", "[", And "space" with a underscore ("_"). Why is this not so dangerous? The fact is that such PHP behavior is observed only in the names of the parameters passed to the web server, but not in their values. This greatly reduces the likelihood of using this feature in "wildlife."
And the last thing I wanted to pay attention to was the Python interpreter. During fuzzing, it was found that Python encountering characters from the range of% 80-% FF returns an error message (ala disclosure ... and blah blah):

(Appendix)
The scripts used below were used for testing.
PHP:
$ G = & $ _ GET;
foreach ($ G as $ k => $ v)
{
print $ k. "
?>
ASP:
<%
for each var in Request.QueryString
Response.Write (var & "=" & Request.QueryString (var))
next
%>
JAVA:
<%
java.util.Enumeration names = request.getParameterNames ();
while (names.hasMoreElements ()) {
String keyx = names.nextElement (). toString ();
out.println (keyx + "=" + request.getParameter (keyx)); }
%>
PERL:
use CGI;
my $ cgi = new CGI;
my @params = $ cgi-> param ();
print <
Content-Type: text / html
ENDOFTEXT
foreach my $ parameter (sort @params) {
print $ parameter. "=". $ Cgi-> param ($ parameter);
}
PYTHON:
import cgi, os
print ('Status: 200 OK')
print ('Content-type: text / html; charset = utf-8;')
print ("")
query = os.environ.get ('QUERY_STRING ')
pairs = cgi.parse_qs (query)
for key, value in pairs.items ():
print (key, value)