new vulnerability probe pattern

vulnerability probe of website

[revrob]

I have just had a series of these types of request - clearly a vulnerability probe looking for certain types of php page.

The format of the GET request seems to be designed to avoid any bot traps that I have set up in .htaccess using various RewriteRule statements.

This is the format of the latest attempt - the second of its type in the last week - but not one I've seen before - it is unedited - exactly as it appeared in the log:

"GET //newsletter/admin/index.php?_SERVER[ConfigFile]=../../../../../../../../../../../../../../../../../../../../../../../etc/passwd HTTP/1.1" 404 2321 www.mydomain.org.uk "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" "-"

My current Rewrite commands don't seem to catch these requests
- is it the double slash at the beginning that is the problem?

They are in this format:

RewriteRule ^/target.php /trap/trap.php [L]

Thanks in advance

[g1smd]

I block any request with .. in it. One of the very first lines in the .htaccess file does that.

[jdMorgan]

If your code goes in .htaccess, then the example rule won't function.

RewriteRule patterns in .htaccess should not start with a slash.

Also, escape any periods that you intend to match literally. Otherwise, they are taken to mean "match any single character" by the regular-expressions matching engine.

RewriteRule ^target\.php$ /trap/trap.php [L]
RewriteRule \.\./ - [F]

might work better.

Jim

[revrob]

Sorry my mistake - the rule I quoted was an experiment - the actual rule is in the format

RewriteRule ^target.php /trap/trap.php [L]

or

RewriteRule ^targetfolder/ /trap/trap.php [L]
for a whole folder/directory

and those definitely do work on ordinary GET requests when I test them with a browser.

Thanks for the one with double dots in, I've now included that.

[jdMorgan]

Note that your "target.php" rule is still missing the escaping on the literal period and the end-anchor.

Jim

[revrob]

Thanks - I've corrected those now. much appreciated.