Was jquery.com compromised? | Hacker News Reader

Was jquery.com compromised?

blog.jquery.com

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.

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?

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.

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

Huh! That looks awesome. :)

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

To be clear, I was totally making up this proposal; I wasn't aware that there was a spec. Nothing should be read into the fact that I used "hash" and they use "integrity".

why does the "integrity" attribute use this strange fake-URL?

ni:///

why 3 slashes? any clue?

Could be

  ni:
  //
  <empty field>
  /

file:: URIs can have it, too (http://superuser.com/questions/352133/what-is-the-reason-tha...)

They cite RFC6920 [1], which uses the "host" portion of the URL as an optional "authority" field.

[1] http://tools.ietf.org/html/rfc6920#section-3

Because the ni scheme is separate from this proposal and it supports having a server there if you retrieve named information from somewhere else (implementation defined i think).

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.

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.

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.

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

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

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

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.

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

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.

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

To be specific, if you can create an arbitrary primage for sha256, you could pwn all digital signatures that sign a sha256 of the message. So in particular, you'd own all TLS connections and certs that use sha256.

(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/#...

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

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.

Good point. I was taking the parent's post literally, where jquery.com was used.

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

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

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.

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

"They", who, jquery.com?

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

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

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

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.

yes and yes

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

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

Did webdevelopers think otherwise any time?

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

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.

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

And certainly not load it over http.

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

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

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.

No, you can't, because the latter could have dropper the former.

You mass inject with a low impact exploit and any high profile targets you stumble upon can be dropped a high impact rootkit.

You must be very, very sure before you decide you only got hit by a script kiddie attack.

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.

How do you "tell" there was something on kernel level without offline forensics (which means the machine is put of the grid anyways)?

A compromised Kernel can lie to you about everything, including the malware.

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.

Strange, it doesn't happen for me.

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

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

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

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

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

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?

Reply on news.ycombinator.com