7 ms·
jQuery.com Malware Attack Puts Privileged Enterprise IT Accounts at Risk
- __david__ 12y agoI can't help but think this was a huge missed opportunity for the attackers. Instead of hosting malware on the site, they could have infected just the hosted jquery and attacked a ton of sites all at once.
- sudhirj 12y agoI doubt the CDN or the downloads are hosted on the same infrastructure, but they certainly could have pointed all links to slightly fishier versions.
- dccoolgai 12y agoIt's very sobering to think of all the havoc that would cause. Is it still best practice to call your jq up from the jquery cdn?
- Igglyboo 12y agoNot sure about the jQuery CDN but where I work it's best practice to serve it from Google's CDN. Probably should rethink that.
- tripzilch 12y agoReading this news, I was wondering, whether from a security POV, including jQuery from Google's CDN rather than jQuery's own would be better. My reasoning was that Google is bigger, therefore probably has better security. They also need very similar technology for securing the AdSense includes. Finally, if someone manages to compromise Google, there might be bigger problems than hosting a malware-d jQuery (although that would be pretty big). It's not a very convincing reason, risk-wise, IMO. I'm assuming that jQuery should be pretty on top of the security of their CDN. Also that proposed new hash/integrity attribute for the SCRIPT tag seems way more promising.
- josephlord 12y agoYou do however leak information to Google about your customers browsing behaviour. If you are using Google Analytics you obviously do that to an even greater degree anyway so there is no further harm for most users but it is more likely to be blocked by me and I always block Google Analytics.
- deleted 12y ago[deleted]
- hk__2 12y agoDirect link: http://www.riskiq.com/resources/blog/jquerycom-malware-attack-puts-privileged-enterprise-it-accounts-risk#.VCF33EtRmns http://www.riskiq.com/resources/blog/jquerycom-malware-attac...
- ChrisArchitect 12y agonowhere does it say that the CDN hosted libraries code.jquery.com were affected. So who cares.
- emodendroket 12y agoAnyone who checked the jQuery docs while compromised, I suppose.
- nkozyra 12y agoThis is a weird response. How many people Google a jquery function every day? How many of those people were compromised (~6% conversion)? How many machines were compromised and how many man hours will it take it re-secure? In other words, plenty of people should care. You could argue that a modified version of jquery/jquery.min on CDNs would be more devastating, but both are bad news.
- xenophonf 12y agoSpeaking as someone who whitelisted "jquery.com" in NoScript and RequestPolicy, I care. The various CDN-hosted libraries are very convenient, but to me they seem somewhat risky single points of failure. It's certainly possible that an attacker could parlay their access to the main JQuery web site into access to the the JQuery CDN (e.g., an admin uses the same password in both places). We're fortunate that (probably, hopefully) didn't happen in this case.
- deleted 12y ago[deleted]
- Xeoncross 12y agothere's a jquery plugin for that
- deweller 12y agoHere are the details on the RIG exploit pack served to users who visited jquery.com during the time in question (September 18th). Exploits: Java – CVE-2012-0507, CVE-2013-2465 IE 7/8/9 – CVE-2013-2551 IE 10 – CVE-2013-0322 Flash – CVE-2013-0634 Silverlight – CVE-2013-0074 Source: http://www.kahusecurity.com/2014/rig-exploit-pack/ http://www.kahusecurity.com/2014/rig-exploit-pack/
- Someone1234 12y agoThis is why everyone should have "Click To Play" turned on for all browser plugins. It would have stopped the Java, Flash, and Silverlight drive-by attacks even if you had a vulnerable version installed. The IE/browser based exploits can only be mitigated by keeping up to date or utilising something like EMET (although I don't really expect everyone to be running EMET). PS - CVE-2013-0322 doesn't look like an IE10 issue.
- emodendroket 12y agoIs this page suggesting you have to say yes to the UAC prompt for it to work, or is that noise from failed attempts?
- deanclatworthy 12y agoSo how does one tell if they have been compromised by the exploit pack?
- jimrandomh 12y agoAs others have observed, if the attackers had wanted, they could have modified the hosted jQuery scripts and used them to attack other web sites. They don't seem to have done so, but this highlights how the practice of including scripts hosted by other parties is a security problem for the Internet as a whole. But there's an easy way to fix it. Browsers should support a hash attribute for <script> tags, so instead of <script src="https://code.jquery.com/jquery-2.1.1.min.js"> sites could instead say <script src="https://code.jquery.com/jquery-2.1.1.min.js" hash="sha256:874706b2b1311a0719b5267f7d1cf803057e367e94ae1ff7bf78c5450d30f5d4"> This would also significantly reduce the risks from use of http instead of https, and from weaknesses in https itself.
- teraflop 12y agoThis was suggested on the WHATWG mailing list last December, but AFAIK no action has been taken yet: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-December/211148.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-Dec...
- krapp 12y agoI really like this idea. Is this something browser plugins would be able to do?
- jimrandomh 12y agoI don't think a plugin could do it, but it's back- and forward-compatible enough that it makes sense to just go ahead and add it to a browser without waiting for standardization.
- aikah 12y agoI guess, but it would have to download the script before hand,check the hash,then append the script somewhere. I dont see any other technique."document.write" is only efficient while the page itself is loading. It's an interesting problem nevertheless, and could be extended to any link or src attributes in tags. In case the hash and the file dont match,the browser wouldnt load that file.
- 12y ago
- PythonicAlpha 12y agoCan anybody tell, if users with Linux systems can be affected? It seems, that primary Windows PCs are targeted, but since also a Flash exploit is targeted, that also existed on Linux, it is not clear to me, if a Linux system could be infected. I don't know, if I visited the site at this specific date, but I am rather sure, that if I was, I used a Linux system.
- dubcanada 12y agoIt downloads a .exe apparently so no.
- phazmatis 12y agoWhen a non-technical website is hacked, I expect a dumb press release like this. But when an attack targets the tech industry, I expect a deeper level of coverage. What malware is served? Does it work on OS X or linux?
- kevinSuttle 12y agoThey even had a blog post about why you shouldn't link to the latest CDN version. http://blog.jquery.com/2014/07/03/dont-use-jquery-latest-js/ http://blog.jquery.com/2014/07/03/dont-use-jquery-latest-js/
- giancarlostoro 12y agoThis never happens when I use vanilla.js
- getdavidhiggins 12y agoSeems legit: http://s.higg.im/image/0m2g2o1F2W1D http://s.higg.im/image/0m2g2o1F2W1D
- barsonme 12y agoI can't even get the malware site to load anymore... also, nice way to redirect people to your website ;)
- RedWolves 12y agoSpeaking on behalf of the jQuery Foundation, we have currently not found evidence of a compromise. Read more info at our blog http://blog.jquery.com/2014/09/23/was-jquery-com-compromised/ http://blog.jquery.com/2014/09/23/was-jquery-com-compromised...