jQuery.com Malware Attack Puts Privileged Enterprise IT Accounts at Risk(riskiq.com)
riskiq.com
jQuery.com Malware Attack Puts Privileged Enterprise IT Accounts at Risk
http://www.riskiq.com/resources/blog/jquerycom-malware-attack-puts-privileged-enterprise-it-accounts-risk
52 comments
The other benefit to this is that the browser can be confident that it's cached copy matches the requested file and we can now cache files that come from different hosts.
Example: User has jquery cached from googles CDN, jquery will not be loaded from microsofts cdn because it has the same hash.
Example: User has jquery cached from googles CDN, jquery will not be loaded from microsofts cdn because it has the same hash.
This proposal already exists:
Subresource Integrity
http://www.w3.org/TR/SRI/
http://www.chromestatus.com/features/6183089948590080 http://status.modern.ie/subresourceintegrity
http://www.chromestatus.com/features/6183089948590080 http://status.modern.ie/subresourceintegrity
I have a few issues with this proposal e.g.
> 3.2.1 Agility: the user agent will choose the strongest hash function in the list
Aside from the fact this contradicts the next section (Priority), it also would discourage browser vendors from adding better (slower) hashing functions as then they would be "forced" to utilise them.
Instead the standard should be: The "the fastest hash function which the browser finds secure." So if SHA-256 and SHA-512 were available, it would use SHA-256 until it was found insecure, then the browser would use SHA-512.
> Validation using unsupported hash functions always fails (see the “Does resource match metadataList” algorithm below). Authors are therefore encouraged to use strong hash functions, and to begin migrating to stronger hash functions as they become available.
No. Just no. If Chrome was the first to market with e.g. SHA-9999, I'd be unable to utilise that until literally every single browser on the market supported it (as it was fail by default).
Imagine if this standard existed in the IE6 days, today if you tried to use SHA-512 (which, let's assume, IE6 didn't support) the resources would fail to load every time (and you'd wind up having half a dozen different hashes just to hit something that was supported).
It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Fail by default isn't even the HTML way. Ignore by default is.
> 3.2.1 Agility: the user agent will choose the strongest hash function in the list
Aside from the fact this contradicts the next section (Priority), it also would discourage browser vendors from adding better (slower) hashing functions as then they would be "forced" to utilise them.
Instead the standard should be: The "the fastest hash function which the browser finds secure." So if SHA-256 and SHA-512 were available, it would use SHA-256 until it was found insecure, then the browser would use SHA-512.
> Validation using unsupported hash functions always fails (see the “Does resource match metadataList” algorithm below). Authors are therefore encouraged to use strong hash functions, and to begin migrating to stronger hash functions as they become available.
No. Just no. If Chrome was the first to market with e.g. SHA-9999, I'd be unable to utilise that until literally every single browser on the market supported it (as it was fail by default).
Imagine if this standard existed in the IE6 days, today if you tried to use SHA-512 (which, let's assume, IE6 didn't support) the resources would fail to load every time (and you'd wind up having half a dozen different hashes just to hit something that was supported).
It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Fail by default isn't even the HTML way. Ignore by default is.
> It should just ignore unknown hash functions, not fail. If the integrity attribute only had one hash function and it was unsupported then the entire attribute should be discarded.
Your proposal would make the hash attribute advisory. If I put a hash attribute on there, should I be able to count on it, and know that browsers won't load unless they can verify it? Or is it just advisory, and browsers may choose to ignore it, and I can't actually count on browsers only loading if hash matches?
Of course, I guess the fact that older browsers will always exist that ignore it (and that all browsers are essentially untrusted software, as far as the developer is concerned) may point to "you'd best consider it advisory only" anyway, I suppose.
Your proposal would make the hash attribute advisory. If I put a hash attribute on there, should I be able to count on it, and know that browsers won't load unless they can verify it? Or is it just advisory, and browsers may choose to ignore it, and I can't actually count on browsers only loading if hash matches?
Of course, I guess the fact that older browsers will always exist that ignore it (and that all browsers are essentially untrusted software, as far as the developer is concerned) may point to "you'd best consider it advisory only" anyway, I suppose.
Even without considering older browsers, the hash will be deliberately ignored by some clients for things like NoScript surrogates. Every tag and attribute is just advisory to the client; the client can always do what the user wants instead of what the server wants.
… and the Blink team landed it today shortly after your comment:
https://codereview.chromium.org/566083003/
The tests show how simple the code is:
https://codereview.chromium.org/566083003/patch/120001/13000...
https://codereview.chromium.org/566083003/
The tests show how simple the code is:
https://codereview.chromium.org/566083003/patch/120001/13000...
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.
Just don't trust so many third parties with your site's security: Host jQuery (and other things) yourself.
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.
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.
>And what happens when it's patched to fix a real issue? Your site will just break.
No, they will release a new version with a new URL.
No, they will release a new version with a new URL.
Then you update the version number and the hash, just like you have to update the version number today already :)
The URL will change along with the version and hash number, unless you're using jquery-latest.min.js which is a bad idea in general and wouldn't make sense to use with the hash attribute anyways.
This 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-Dec...
Yep, a lot of people have come up with this idea independently (I'm one of them). It's pretty obvious, after all.
But I don't think it will ever get much traction. Believe it or not, it's too far beyond the organizational and technical capacities of the people behind too many sites. The benefit, aside from slightly improved caching, will be minimal.
And if you're careful and meticulous you aren't doing braindead things like hotlinking javascript in the first place.
But I don't think it will ever get much traction. Believe it or not, it's too far beyond the organizational and technical capacities of the people behind too many sites. The benefit, aside from slightly improved caching, will be minimal.
And if you're careful and meticulous you aren't doing braindead things like hotlinking javascript in the first place.
Thomas chiming in from cdnjs.com here.
We are responsible for quite a lot of copy and paste script includes these days and could potentially push people in this direction.
If anyone is serious about investigating hash'ed includes shoot me an email with your thoughts, my email can be found on my HN profile.
We are responsible for quite a lot of copy and paste script includes these days and could potentially push people in this direction.
If anyone is serious about investigating hash'ed includes shoot me an email with your thoughts, my email can be found on my HN profile.
The thing which will give it traction[1] is performance: if a browser starts letting you host locally but say “Yes, this is the same jQuery you have in your cache” that'll be a big win for a number of sites, particularly on mobile where it could reduce expensive network traffic and reduce cache duplication.
http://www.w3.org/TR/SRI/
http://www.w3.org/TR/SRI/
You assume that such people wouldn't just copy/paste a code fragment. If that code fragment happened to already come with a hash/CRC, they likely won't remove it.
I really like this idea. Is this something browser plugins would be able to do?
I 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.
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.
I 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.
realistically you would want to use a merkle tree to hash the source, to make it more secure against a chosen plaintext collision, but aside from that this'd be a great addition.
No secure hash function has collisions, so it's not necessary.
Every hash function has collisions. It's just nearly impossible to find them if the hash function is secure.
... and it's impossible to know for sure that a hash is secure against collisions. For example, MD5 was the standard for hashing for quite some time but is considered broken today due to attacks that have since been discovered. By implementing the hashing using merkle trees, you increase the avalanche effect relative to the data, making it much harder to force a collision.
Obviously any compression function has collisions - this is a mathematical fact. What I mean with "no secure hash function has collisions" is that if you are using a secure hash function you shouldn't need extra defenses against collisions attacks as the "secure" in "secure hash function" implies those attacks are infeasible.
IBM also has a patent pending on this.
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/
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/
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.
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.
Is this page suggesting you have to say yes to the UAC prompt for it to work, or is that noise from failed attempts?
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.
I doubt the CDN or the downloads are hosted on the same infrastructure, but they certainly could have pointed all links to slightly fishier versions.
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?
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.
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.
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.
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.
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...
So how does one tell if they have been compromised by the exploit pack?
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.
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.
It downloads a .exe apparently so no.
[deleted]
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/
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?
Seems legit: http://s.higg.im/image/0m2g2o1F2W1D
I can't even get the malware site to load anymore... also, nice way to redirect people to your website ;)
[deleted]
This never happens when I use vanilla.js
there's a jquery plugin for that
nowhere does it say that the CDN hosted libraries code.jquery.com were affected. So who cares.
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.
This 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.
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.
Anyone who checked the jQuery docs while compromised, I suppose.
But there's an easy way to fix it. Browsers should support a hash attribute for <script> tags, so instead of
sites could instead say
This would also significantly reduce the risks from use of http instead of https, and from weaknesses in https itself.