
jQuery.com Malware Attack Puts Privileged Enterprise IT Accounts at Risk - dmritard96
http://www.riskiq.com/resources/blog/jquerycom-malware-attack-puts-privileged-enterprise-it-accounts-risk
======
jimrandomh
As 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.

~~~
thirsteh
And what happens when it's patched to fix a real issue? Your site will just
break.

Just don't trust so many third parties with your site's security: Host jQuery
(and other things) yourself.

~~~
Drakim
Nah, the new version is hosted at a new url.

Even if we ignore the hash suggestion, you don't want to have some dev on the
other side of the planet suddenly update one of your libraries on your live
website.

That should never be a thing in the first place, so it won't be a problem.

------
deweller
Here 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
This 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.

------
__david__
I 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.

~~~
dccoolgai
It'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
Not 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
Reading 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
You 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.

------
RedWolves
Speaking 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/)

------
deanclatworthy
So how does one tell if they have been compromised by the exploit pack?

------
PythonicAlpha
Can 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
It downloads a .exe apparently so no.

------
kevinSuttle
They 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/)

------
phazmatis
When 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?

------
getdavidhiggins
Seems legit:
[http://s.higg.im/image/0m2g2o1F2W1D](http://s.higg.im/image/0m2g2o1F2W1D)

~~~
barsonme
I can't even get the malware site to load anymore... also, nice way to
redirect people to your website ;)

------
giancarlostoro
This never happens when I use vanilla.js

------
hk__2
Direct link: [http://www.riskiq.com/resources/blog/jquerycom-malware-
attac...](http://www.riskiq.com/resources/blog/jquerycom-malware-attack-puts-
privileged-enterprise-it-accounts-risk#.VCF33EtRmns)

------
Xeoncross
there's a jquery plugin for that

------
ChrisArchitect
nowhere does it say that the CDN hosted libraries code.jquery.com were
affected. So who cares.

~~~
xenophonf
Speaking 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.

