Was jquery.com compromised?

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

by getdavidhiggins • 12 years ago

115 55 12 years ago

blog.jquery.com

aroch• 12 years ago

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

https://news.ycombinator.com/item?id=8356062

cleverjake• 12 years ago

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

0x0• 12 years ago

Are there any consequences for the hosting AS? Would they know who registered the domains and hosted the kit? If not, why are they still getting peers?

deweller3• 12 years ago

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.

UnoriginalGuy• 12 years ago

They do run adverts from http://adzerk.com. Maybe it was them?

bagels• 12 years ago

"They", who, jquery.com?

kevjiang• 12 years ago

Were any HNers ever able to reproduce what RiskIQ reported? Namely seeing jquery.com include the script from the malicious jquery-cdn[.]com domain?

davidu2• 12 years ago

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

https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-0...

deweller3• 12 years ago

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.

smaili• 12 years ago

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

korzun2• 12 years ago

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.

Argorak2• 12 years ago

"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.

korzun2• 12 years ago

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.

jlebar5• 12 years ago

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.

Kortaggio• 12 years ago

Given the number of websites that rely on jQuery and other hosted JavaScript libraries, I can't believe there isn't yet a well-publicized way of verifying external scripts before loading them. If someone managed to compromise a jQuery CDN, we're looking at a Heartbleed-level vulnerability in terms of scale and impact.

I've never seen the hash attr before. Is this an experimental feature that is already available on live browsers, or only a proposal?

ryan-c• 12 years ago

It's a proposal.

I made this thing: https://github.com/ryancdotorg/VerifyJS

but it requires CORS headers from the CDN and isn't well tested.

nthitz• 12 years ago

Looks like it was committed to Chromium today https://codereview.chromium.org/566083003/ as per this spec http://www.w3.org/TR/SRI/

jlebar5• 12 years ago

Huh! That looks awesome. :)

rudilee• 12 years ago

and instead of 'hash' it use 'integrity' attribute

chc• 12 years ago

The existence of a hash attribute wouldn't do anything at all for the supposed compromise in question, so I don't understand how a possibly nonexistent breach is supposed to highlight a feature that wouldn't help to prevent this or similar breaches in the future.

jlebar5• 12 years ago

The issue is that, if jquery.org can plausibly be hacked, then jquery's CDN can presumably also plausibly be hacked. This would allow an attacker to serve whatever she wanted to any page which used this CDN, even pages protected with TLS.

huskyr2• 12 years ago

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.

DougBTX• 12 years ago

That file is probably going to stay at v1.11.1 forever now: http://blog.jquery.com/2014/07/03/dont-use-jquery-latest-js/

(The blog post talks about /jquery-latest.js, but I'd imagine the same goes for all the version-number-free urls.)

_ikke_• 12 years ago

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

annnnd2• 12 years ago

Aggressive caching might not be such a good idea - if someone figured out how to create a collision, he could replace all those ga.js / jquery.js / ... calls with his own scripts. The attacker doesn't even have to be "man in the middle", he just needs to get victims to his site.

edandersen• 12 years ago

If someone could create a SHA256 collision just for that, we'd have bigger problems.

dchest• 12 years ago

(Note: technically, this is not a collision attack: if you goal is to find a second input which results in the same hash for the given input, this is called a second-preimage attack. A collision attack is the one when you can create two inputs which result in the same hash. For example, even though collision resistance of MD5 is broken, AFAIK, there's no second-preimage attacks known for it, so even if this integrity checking used MD5, you probably wouldn't be able to create evil.js such that md5(evil.js) == md5(jquery.js) if you didn't control the contents of jquery.js.)

In the standard draft, there's a discussion of caching risks: https://w3c.github.io/webappsec/specs/subresourceintegrity/#...

Skywing2• 12 years ago

If somebody has the ability to change the script file, what's to stop them from changing that hash, too?

adamtj• 12 years ago

For jquery, the page is often on your server and the script is on a CDN. The worry is that if an attacker compromises the jquery source on the CDN, they can exploit thousands or millions of sites on as many different servers. If each of those servers were serving pages with hashes, the modified jquery on the CDN would be rejected.

14113• 12 years ago

It's a solution for loading scripts from third party servers (e.g. jQuery), not from servers you control.

vlunkr• 12 years ago

At no time have the hosted jQuery libraries been compromised.

The problem isn't with the CDN. It was supposedly on jquery.com, so you would have had to visit that url directly.

That said, I don't disagree with the hash ID in case something there was a problem with the CDN.

blueskin_• 12 years ago

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

antocv2• 12 years ago

Did webdevelopers think otherwise any time?

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

twelve40• 12 years ago

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.

noselasd• 12 years ago

And certainly not load it over http.

quarterto• 12 years ago

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

ninja edit: qwertial aphasia

annnnd2• 12 years ago

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".

andrewd18• 12 years ago

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• 12 years ago

Strange, it doesn't happen for me.

deweller3• 12 years ago

Update [9/24]:

https://twitter.com/jquery/status/514811609752289281

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

Was jquery.com compromised?

Related Stories