Yahoo is asking for one of it's own pages, on my site and this seems like some kind of corruption.
The only other reason I could think they might do that would be to search for scraper/mirror sites that are making illegal use of Yahoo's content via 302 redirects. However, a Google inurl: search on a couple of the partial URL strings finds them all to be only at Yahoo; no evident problem with scraper sites. Besides, their normal Slurp crawler would run across those in the normal course of events, anyway, so they'd have no need to actively search for them.
I had 2 escalation notices and then a customer support survey request...At first it seems Y support were onto something but now silence... Definitely something not right here.
Yahoo must get many questions a day about, "Why is Slurp doing [whatever]?", so it seems a bit unusual to me that you got a response at all other than something like "please read our FAQ", and even more unusual that it was escalated. Sudden silence after an initial willingness to be communicative is a fairly typical response of a big company that has found a real problem. Even if you have usefully alerted them to something they need to fix, it would be atypical for them to openly confirm it to you or solicit your further input to help them fix it. More likely, you would just eventually see the errors stop, which is possibly one reason not to block the requests for the time being.
-----
I can think offhand of two different types of exploit trawling. One makes sense, and the other doesn't.
In order to commence a brute force password attack against a login page, you'd need to first find a login page, so it can make sense to crawl sites looking for login pages. But that would only be in preparation for a brute force attack, which will require many requests. And it's not really an exploit against an application vulnerability. [The protection against it is simply to use long random passwords.]
The other type of trawling would be to find vulnerable versions of vulnerable web applications, but I've found such trawling, without an attached payload, to be extremely rare. Given the choice between a) sending out a million requests to websites in order to find the vulnerable ones, and then following up, and b) sending out a million requests WITH the exploit payload, option b) is at least twice as efficient. It will succeed immediately against any vulnerable site, and will simply have no effect against the nonvulnerable ones. Unlike a password attack, an application exploit requires hardly any expenditure of effort. The payload is a single line of code, usually in the query string, usually referencing an outside malicious code-cache site, from where it gets a possibly complex script that carries out the full exploit. All automated, no human effort.
My logs show thousands of exploit attempts launched against web applications that I don't use. The hackers don't care if you use the app or not. Sending the payload outright instead of probe-then-exploit is a time saver.
-----
As an additional precaution, you might check Google Webmaster Tools to ensure that Googlebot is not also under the impression that these URLs might be valid for your site. If Googlebot thinks they might be valid, that would be cause for concern.
-----
I'm basically not convinced that there is any exploit activity going on here, except for the JavaScript attack that looks like a cross-site scripting attack of some sort.
But I am convinced that the fact these requests are coming from Yahoo is weird and possibly indicative of a Yahoo configuration problem, provided you can rule out the possibility that Yahoo might be getting these URLs from some strange source and is simply crawling them in the ordinary course of following links.
Besides, what is the point in a link like that being crawled?
Yes, exactly. Yahoo's crawling those links couldn't help any hacker.
-----
JavaScript injection --
This could have been the intention of the alpha zero victor exploit. But again it is not configured correctly. If the intention is to fill log files up with links to rogue sites then surely the referring url should be targetted and not the GET / url.
Actually, the intent of that wouldn't be to fill the log with links (such as "log spamming", trying to generate backlinks to their site in website logs that the webmasters have made publicly viewable).
Rather, the intent would be to attack the webmaster's browser when the webmaster looks at his/her visitor reports. If a web page has a JavaScript script in it, then when the page loads, the JavaScript runs. The malicious GET request is a way to get their JavaScript embedded in the web page that you look at when you view your visitor reports. You open Webalizer or AWStats, or whatever, and as soon as the page loads, containing the listing of their GET request, the JavaScript runs, fetches its content from alpha zero victor, and bam! your browser is under attack. One of the pieces of the attack is a password-stealer. So if the attack succeeds at infecting your PC, they could potentially obtain your website FTP password.
But it's a low probability attack: a) you must have JavaScript enabled (when viewing your website logs, you probably do), b) The JavaScript itself must be well formed, and, although not an expert at XSS, I'm not sure that that JS is. c) You must be viewing your report on a web page such as Webalizer produces, d) that log application must *fail* to convert characters such as < and > to their HTML entities. Most major log viewers are properly configured to use HTML entities. e) Your browser must be vulnerable to the exploit that is launched against it. f) Your PC must be unpatched and vulnerable to the exploit that is launched against *it*. g) You must not be running real-time antivirus software.
I get other malicious requests that appear to have a similar intent, except that instead of JS, there is PHP code embedded in the referer string, presumably in hopes that the log report page is generated using PHP and that their PHP code snippet will therefore run.
-----
I hope others will report if they are seeing similar strange requests. I definitely have not seen any unusual requests from Yahoo.
Even if you are getting requests for /admin/ or /login/ pages, you are well protected provided that a) your application, whatever it is, is up to date and fully patched so it doesn't have known vulnerabilities, and b) you use long random passwords that would take years, decades, or millenia to crack. In other words, just because you're attacked doesn't mean you're hacked. You definitely will be attacked.
