I manage a secured PHP/MySQL web app with extensive jQuery use. Today, a strange error popped up in our app's logs:
JS Error: Error loading script:
https://d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js
We are not using Amazon's Cloudfront CDN in our app. When I go to the URL that failed to load, these are the only contents:
if(typeof _GPL.ri=='function'&&!_GPL.isIE6){_GPL.ri('_GPL_r')}_GPL.rl=true;
The user's user agent string is:
Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Please note: I am not the user who triggered this error. It was one of our thousands of users who triggered it. I do not have control over the client machine.
Does anyone know what's going on here? Is this some sort of XSS attack?
** Update **
It appears I'm not the only one who has discovered this anomaly on their website. I found this report of the same exact behavior, which seems to indicate the code is harmless, but still no answers as to where it came from.
In addition, I found this pastebin with similar code, that appears to be some sort of advertising script. Again, not terribly helpful.
** Update 2 **
More context: The webapp uses several third party jQuery plugins but no third party analytics of any kind. All scripts are hosted on our own server, and an audit of all our code provides no matches for "cloudfront".
This app has been in production for about 4 years, and this is the first and only instance of any activity like this. It has not happened before or since, so I doubt I'll be able to reproduce it.
What I'm interested in is if this is some sort of attack. If it is, I want to know how to plug the hole it's trying to exploit if it's not plugged already.
I found an iFrame as well in my drupal 7 website. It was loaded into the site by enabling the module of sharaholic.
Disclaimer: I'm not a security analyst/expert, your issue simply sparked my interest ;)
Warning: While I share the initial conclusion that the code itself is probably harmless, the underlying technology can most certainly be (ab)used for malicious intents as well, so please take care when investigating this yourself.
Analysis
You already found the relevant evidence yourself - searching further I found another pastebin drop, which is more readable, so I'm using this for the explanation (though at first sight the other one would allow this as well after formatting).
The snippet features JavaScript fragments with the following major functionality:
Line 13 initializes the variable
_GPL
with all sorts of items for later use, e.g. various constants`, helper functions, browser compatibility stuff and actual payloads, for example:Line20 defines an empty
basdeCDN
, line 21 defines afCDN
, which happens to be the one in question (d15gt9gwxw5wu0.cloudfront.net)line 261 defines a function
removeScripts(),
which in turn usesfindScript()
from line 266, further accompanied byinsertJS()
on line 277 - their respective intend is obviousline 270 defines function
loadDomainRules()
, which seems to be the one generating the URL you have found in your logs - see appendix below for the code snippetr.js
being a JavaScript file serving custom JavaScript specifically assembled/generated for the domain at handline 100 defines a function
loadGeo()
, which references some kind of an ad server indeed (ads2srv.com) - see appendix below for the code snippetline 368 finally defines a function
i()
, which provides the most definite clues regarding the likely origin of all this, namely the notion of some Yontoo Client and Yontoo API - see appendix below for the code snippetCorollary
What's it all about?
The extracted clues Yontoo Client and Yontoo API easily lead to Yontoo, an Application Platform that allows you to control the websites you visit everyday, i.e. it sounds like a commercialized version of Userscripts.org, see What is a Yontoo App?:
Now, looking at the current listings in their App Market easily demonstrates, why this might be used for
questionablenontransparent advertizing as well for example, all the trust signs and seals in their footer notwithstanding.How did it end up in your logs?
Another quote provides more insight into the functionality and how it might have yielded the issue you've encountered:
So somebody apparently has visited your site and created some custom domain rules for it by means of the Yontoo client (if it actually allows this for end users) or one of the available apps (the snippet used for analysis references the Drop Down Deals app in line 379 for example), which triggered the creation of
d15gt9gwxw5wu0.cloudfront.net/js/_MY_WEB_APP_DOMAIN_/r.js
to store these rules for reuse on next site visit in turn.Due to some security flaw somewhere (see conclusion below) this URL or a respective JavaScript snippet must have been injected into JavaScript code of your application (e.g. by means of Cross-site scripting (XSS) indeed), and triggered the log entry error at some point in turn.
Conclusion
As mentioned upfront already, I share the initial conclusion that the code itself is probably harmless, although the underlying technology can most certainly be (ab)used for malicious intents as well due to its very nature of mocking with client side JavaScript, i.e. a user allows code from a 3rd party service to interact with sites (and especially data) he uses and trusts every day - your case is the apparent evidence for something gone wrong already in this regard.
I haven't investigated the security architecture (if any) of Yontoo, but wasn't able to find any information regarding this important topic immediately on their website either (e.g. in their Support section), which is pretty much unacceptable for a technology like this IMHO, all the trust signs and seals in their footer notwithstanding.
On the other hand, users do install 3rd party scripts from e.g. Userscripts.org all the time of course, not the least for fine tuning the user experience on Stack Exchange as well ;)
Please make your own judgment accordingly!
Appendix
Below you can find the code snippets referenced in the analysis (I've been unable to inline them within the lists without breaking the layout or syntax highlighting):
loadDomainRules()
loadGeo()
i()