What is this for a Request?

Question

i see the following request-string (see complete example below) with the same request_parameters, but differing values, hitting all our sites/wafs. the scheme is always the same:

&sa=...&ei=..&ved=..&usg=...

UAs are varying from Libwww-perl to (probably faked) legit ones.

sometimes an url-based exploit-attempt is found after this string, targetting timthump and joomla - vulns (none of these apps are existing on our systems)

these strings are appended to:

• urls like /contact/
• static-files
• existing request-parameters

sample:

&sa=U&ei=w0QtUoiKC4jukQWZjYGQDg&ved=0CMcBEBYwOTiQAw&usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/

Answer 1

It's hard to judge the source or the purpose of these requests based on information you provide, but one thing is rather clear: somebody was translating request URLs with the wrong function, using HTML encoding in place of what it should have been URL encoding of the query part of the requested URLs.

For example, the sample you provide should read as:

&sa=U&ei=w0QtUoiKC4jukQWZjYGQDg&ved=0CMcBEBYwOTiQAw&usg=AFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg/

If this was meant to be passed to another URL as a single variable, it would have to be translated using URL encoding, and it would look like this:

%26sa%3DU%26ei%3Dw0QtUoiKC4jukQWZjYGQDg%26ved%3D0CMcBEBYwOTiQAw%26usg%3DAFQjCNFRKoHdBKgBMHRgJFfxPXluxhkSRg%2F

As it was translated with HTML encoding instead, the & ampersand character (for example, there are other problems with it) denoting new URL parameter value will repeat in the HTML encoded string at wrong places, your web server has no way of knowing which parts are the URL query name and value parts in the format: &field=value once it URL decodes the requested resource location.

This, I imagine, translates in all kinds of illegal requests listed in your web server's access logs. I would advice simply blocking all such requests in your web server configuration, as there is no way they can be served proper response anyway. How you'll do that though, is entirely up to you and your needs. I personally deny access to any User Agent (UA) strings that I deem having no business accessing my server, including default UAs of many web framework libraries, among which the one you mention: Libwww-perl.

I'm on Apache, and using PerishablePress' 2010 User-Agent Blacklist for these tasks (among other custom blocks in web server config and other means of controlling access, of course). It's in my opinion a convenient enough collection of blacklisted UAs, and while there are newer ones published even on this same blog, I find the one from 2010 to work the best for my needs. Anyway, I thought you might find it useful, too. ;)

Answer 2

I have the same requests in my log. All those requests came from Kazakhstan. And all requests has no referrer, or refer the same page as request. Also, there is no requests for other static resources, like images, JS- or CSS-resources. As really paranoid, I think, that this work of some type of vulnerability scanner. Possible, it try to detect version of CMS, or searching for SQL/PHP-injections.

Answer 3

i found something and something more

to me it looks like this line should occure only in referer, never within the URL itself. my conclusion:

• obvious malicious
• creators of scripts fail to include this field in referer?
• cant be a wrong-doing crawler
• perhaps appended to make it look soemwhat "officialy" coming from google