

Was jquery.com compromised? - getdavidhiggins
http://blog.jquery.com/2014/09/23/was-jquery-com-compromised/

======
jlebar
IMO this highlights the need for hash-verified script tags:

    
    
      <script src="https://jquery.com/whatever.js" hash="sha256,deadbeef...">
    

The browser would refuse to load the script if its hash didn't match.

This would be far safer than what we currently do.

It would also allow the browser to more aggressively cache scripts -- if it
already has a script in the cache from another URI whose hash matches, e.g.
because someone else included jquery from Google's CDN, it can substitute it
in.

This has an easy legacy story, too; old browsers will just ignore the "hash"
tag and behave as they currently do.

~~~
huskyr
For the most-common use case (people using code.jquery.com/jquery.js), this
won't work. That URL always links to the latest version, which updates with
every new release, hence invalidating the hash (and the developer's website).

You could argue that a well-educated developer should know that and only use
this for tagged releases though.

~~~
_ikke_
If the jquery version changed, their site could break anyway due to changes in
how the library worked.

~~~
huskyr
_Could_ , yes. But in practice this happens very rarely. Breaking the site
because a new version is released with an old hash _will_ happen.

~~~
aaronm67
Very rarely being every single release? You should not be using a changing
library in any production code, you're just asking for problems.

If all you're using jQuery for is a document.querySelectorAll polyfill + the
most primitive event handling, you're _possibly_ safe, as those don't change
terribly often...but at that point, you should probably be using a different
library or a custom build of jQuery.

~~~
joshuacc
Unfortunately, it's the people least qualified to assess the safety of using
an always-changing version who are most likely to do so.

------
deweller
So let's say that the jquery.com server was not compromised... What else could
have caused RiskIQ to see the injected script tag at the end of the body
element?

Could there have been an injection at the ISP? Was it a DNS heist? Or another
BGP compromise?

I must admit I'm quite intrigued and looking forward to seeing what the
investigation uncovers.

~~~
davidu
We (OpenDNS) saw traffic to those domains spike during that time. We're
investigating.

[https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-0...](https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-09-23_20-32-51.png?dl=0)

~~~
deweller
This implies that the script tag injection was indeed served to a wide
audience. Although I guess there is no way to know that these requests came
from the jquery.com site.

~~~
davidu
yes and yes

------
deweller
Update [9/24]:

[https://twitter.com/jquery/status/514811609752289281](https://twitter.com/jquery/status/514811609752289281)

"We have detected a new compromise of [http://jquery.com](http://jquery.com)
and are taking action to mitigate the attack. Updates to follow."

------
blueskin_
Interesting. Yet another way loading all these libraries from third party
sites is a terrible idea for both security and privacy.

~~~
antocv
Did webdevelopers think otherwise any time?

Serves them right, noone should be using CDNs for code.

~~~
twelve40
Fair enough, but what about stuff like google analytics or other legit third-
party scripts, or ads god forbid? Seems like the problem of pulling third-
party code may be bigger than laziness.

~~~
antocv
Dont use google analytics or ads, dont rat out your neighbours to Stassi -
modern form, dont snitch out your users habit to private nsa.

------
korzun
> Immediately re-image system

Yeah, no thanks. This is a mostly detectable payload and you can figure out if
you are infected or not (using their own links).

Without any evidence this is a case of fear mongering.

~~~
Argorak
"mostly". It's not unusual to deliver an easy to detect and obvious malware
and your real payload to catch those convinced that they got it all.

This is the reason why being equipped for automatic reimaging of a server and
quick rotation of keys and passwords should be standard practice nowadays.

~~~
korzun
I'm talking about the end-user. From server perspective, I would argue that it
depends on the impact.

With a proper setup you should be able to tell if you are dealing with
something on the kernel level .vs typical script kiddie style attack.

Reloading server with 1000's customers is not that simple.

~~~
Drakim
You have now revealed that if somebody were to get access to one of your
servers, they just need to drop some script kiddie trash at the very front,
and then put their heavy stuff deep into the system.

You'll clean up the script kiddie trash, and call it a day.

------
andrewd18
At the moment jquery.com loads with the following content:

    
    
      <body>I'm looking for a new job, I'm so sorry for this experiment with iframe, no one was injured, all files was permanently deleted. Greetz: Umputun, Bobuk, Gray, Ksenks @ radio-t.com My PGP public key is:
        <key>
      </body>
    

I think it's safe to say they've been hacked.

~~~
christina_b
Strange, it doesn't happen for me.

------
quarterto
Normally I hate glib citations of Betteridge's law[0], but in this case they
really ought to unequivocally state right in the headline "No, jquery.com was
not compromised". Anything else seems like they're hiding something.

[0]:
[https://news.ycombinator.com/item?id=5742893](https://news.ycombinator.com/item?id=5742893)

ninja edit: qwertial aphasia

~~~
annnnd
To be fair, nobody can say they weren't compromised. At best they can say "we
did our best and couldn't find any traces of compromise".

------
smaili
Did anyone actually click the link? To be honest I'm a bit reluctant to.

------
aroch
1) Don't link to sites that you think may have been compromised. It's poor
form...

2) Yes

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

[https://news.ycombinator.com/item?id=8356062](https://news.ycombinator.com/item?id=8356062)

~~~
cleverjake
Quite a silly response, considering the content and how easy it is to view
just the text

Earlier today, RiskIQ published a blog post stating that the jQuery.com web
servers were compromised and serving the RIG exploit kit for a short period of
time on the afternoon of September 18th. Our internal investigation into our
servers and logs have not yet found the RIG exploit kit or evidence that there
was in fact a compromise.

RiskIQ was able to make contact with the jQuery Infrastructure team on
September 18th, at which point with members of the RiskIQ team tried to find
evidence of compromise. So far the investigation has been unable to reproduce
or confirm that our servers were compromised. We have not been notified by any
other security firm or users of jquery.com confirming a compromise. Normally,
when we have issues with jQuery infrastructure, we hear reports within minutes
on Twitter, via IRC, etc.

At no time have the hosted jQuery libraries been compromised.

Currently the only potential system compromised is the web software or server
that runs jquery.com. We have asked RiskIQ to help us look through our server
logs and systems to help identify when and how a compromise happened. Please
check this blog post for updates on the situation.

Even though we don’t have immediate evidence of compromise, we have taken the
proper precautions to ensure our servers are secure and clean. If you happened
to visit any of the our sites on September 18th and are afraid of your system
being compromised you can follow the advice RiskIQ recommends:

Immediately re-image system Reset passwords for user accounts that have been
used on the system See if any suspicious activity has originated from the
offending system

