what is this?

[pghcollectibles]

has anybody else seen this?

vsDragonRootPa

a google search shows my site as being indexed with that and lists my site as the second one but obviously my script did not allow whatever attack was being tried. how did it get indexed then?

i cannot find any info on it but the duudle site looks suspicious

[shadmego]

If you can read through this translation (http://translate.google.com/translate?prev=hp&hl=en&js=n&u=http%3A%2F%2Fwww.oscommerce-fr.info%2Fforum%2Flofiversion%2Findex.php%2Ft49988 .html&sl=fr&tl=en&history_state0=) you might understand a bit more about what it is. Apparently, it's a type of attack scan. The post above mentioned blocking the IP addresses associated with the log entry via .htaccess. I don't know much else as there doesn't seem to be much into on that string ...

I will keep looking as I have time ...

~regards

[pghcollectibles]

not only have i been blocking ips (shame on people who would even try things like that);) but thats what proxys are for (any way i can test to see if they are coming from a proxy and block them that way too?)

i have redirected some other stuff so the spiders and bots may decide not to index it any more.

this is the basic stuff:

<Files error_log>
order allow,deny
deny from all
</Files>
<Files *.inc>
order allow,deny
deny from all
</Files>
<Files ss_filelist.txt>
order allow,deny
deny from all
</Files>

order allow,deny

deny from xx.xx.xx.xx
# there are quite a few of these of course
# and there is no need to post them here i guess

allow from all

ErrorDocument 404 /error.php?e=404
ErrorDocument 403 /error.php?e=403

RewriteEngine On

RedirectMatch 301 ^/downloads/(.*)$ http://reference.pghcollectibles.com/$1
# Block the devil girl bot
RewriteCond %{HTTP_USER_AGENT} .*Toata.* [OR]
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to look for stuff they dont need to be
RewriteCond %{QUERY_STRING} .*vsDragonRootPa.* [NC,OR]
RewriteCond %{QUERY_STRING} .*public\_includes.* [NC,OR]
RewriteCond %{QUERY_STRING} .*http.* [NC,OR]
RewriteCond %{QUERY_STRING} .*www.* [NC,OR]
RewriteCond %{REQUEST_URI} .*\/\/.* [NC,OR]
RewriteCond %{QUERY_STRING} .*pub\_blocks.* [NC]
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
RewriteRule ^.*msgimport.*$ /error.php?e=403 [F,L]
im sure it could be written better, but as i see something, i take care of it

oh and i already read that (thanks) it wasnt informative for me though (i always have the latest versions and my tracking system blows oscommerce "who_visits.php" out of the water)

[pghcollectibles]

google is the greatest. i searched for the file activecontent.php which the exploit was attempting to find. i couldnt find anything that wasnt bad urls like in my first post. then i found the magical google code search (http://www.google.com/codesearch/advanced_code_search)

so here is the google search (http://www.google.com/codesearch/p?hl=en#NXHSsHIPX28/pbd_2_6_0/software_upload/root_includes/root_modules/activecontent_admin.php&q=activecontent.php) it shows the entire directory structure and code for the CMS

when i searched for Blue Dragon CMS there were 139,000 hits
here (http://secunia.com/advisories/product/9942/) and here (http://www.securityfocus.com/bid/17977/info) are a couple of the security alerts mentioning the vulnerability

it says there are no patches yet (i could fix them, they pull in the http vars in the main index page and the "bad page" only has this:

include($vsDragonRootPath."public_includes/pub_moddata/activefile.".$phpExt);i dont see how that is an exploit

anyways... if you happen to use this Polish born CMS... take precautions!!!