Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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/
share|improve this question
    
looks like google-soup. but why is it appended to urls? –  that guy from over there Sep 12 '13 at 21:29
add comment

2 Answers

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. ;)

share|improve this answer
    
thanx, the encoding-hint was very usefull. the requests are blocked from our WAFs anyway (thats why i was able to investigate that issue). the UA-Blacklist is interesting too; will check it against our list of known-bad UAs (mostly exploit-scanners) –  that guy from over there Sep 15 '13 at 13:24
add comment

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.