11 ms·

Was jquery.com compromised?

aroch 12y 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-attack-puts-privileged-enterprise-it-accounts-risk http://www.riskiq.com/resources/blog/jquerycom-malware-attac... https://news.ycombinator.com/item?id=8356062 https://news.ycombinator.com/item?id=8356062
- cleverjake 12y 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 12y 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?
deweller 12y 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 12y ago
  They do run adverts from http://adzerk.com http://adzerk.com. Maybe it was them?
  - bagels 12y ago
    "They", who, jquery.com?
- kevjiang 12y 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?
- davidu 12y ago
  We (OpenDNS) saw traffic to those domains spike during that time. We're investigating. https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-09-23_20-32-51.png?dl=0 https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-0...
  - deweller 12y 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.
    - davidu 12y ago
      yes and yes
smaili 12y ago
Did anyone actually click the link? To be honest I'm a bit reluctant to.
jlebar 12y 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 12y 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 12y ago
    It's a proposal. I made this thing: https://github.com/ryancdotorg/VerifyJS https://github.com/ryancdotorg/VerifyJS but it requires CORS headers from the CDN and isn't well tested.
- nthitz 12y ago
  Looks like it was committed to Chromium today https://codereview.chromium.org/566083003/ https://codereview.chromium.org/566083003/ as per this spec http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
  - jlebar 12y ago
    Huh! That looks awesome. :)
  - rudilee 12y ago
    and instead of 'hash' it use 'integrity' attribute
korzun 12y 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.
- Argorak 12y 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.
  - korzun 12y 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.
    - xorcist 12y ago
      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.
    - Drakim 12y ago
      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.
    - Argorak 12y ago
      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.
blueskin_ 12y ago
Interesting. Yet another way loading all these libraries from third party sites is a terrible idea for both security and privacy.
- antocv 12y ago
  Did webdevelopers think otherwise any time? Serves them right, noone should be using CDNs for code.
  - noselasd 12y ago
    And certainly not load it over http.
  - twelve40 12y 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.
    - antocv 12y ago
      Dont use google analytics or ads, dont rat out your neighbours to Stassi - modern form, dont snitch out your users habit to private nsa.
quarterto 12y 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 https://news.ycombinator.com/item?id=5742893 ninja edit: qwertial aphasia
- annnnd 12y 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 12y 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 12y ago
  Strange, it doesn't happen for me.
deweller 12y ago
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."

aroch 12y 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-attack-puts-privileged-enterprise-it-accounts-risk http://www.riskiq.com/resources/blog/jquerycom-malware-attac... https://news.ycombinator.com/item?id=8356062 https://news.ycombinator.com/item?id=8356062

cleverjake 12y 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 12y 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?

deweller 12y 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 12y ago
They do run adverts from http://adzerk.com http://adzerk.com. Maybe it was them?
- bagels 12y ago
  "They", who, jquery.com?
kevjiang 12y 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?
davidu 12y ago
We (OpenDNS) saw traffic to those domains spike during that time. We're investigating. https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-09-23_20-32-51.png?dl=0 https://www.dropbox.com/s/tfqpau25ugixiy6/Investigate_2014-0...
- deweller 12y 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.
  - davidu 12y ago
    yes and yes

smaili 12y ago

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

jlebar 12y 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 12y 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 12y ago
  It's a proposal. I made this thing: https://github.com/ryancdotorg/VerifyJS https://github.com/ryancdotorg/VerifyJS but it requires CORS headers from the CDN and isn't well tested.
nthitz 12y ago
Looks like it was committed to Chromium today https://codereview.chromium.org/566083003/ https://codereview.chromium.org/566083003/ as per this spec http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- jlebar 12y ago
  Huh! That looks awesome. :)
- rudilee 12y ago
  and instead of 'hash' it use 'integrity' attribute

korzun 12y 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.

Argorak 12y 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.
- korzun 12y 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.
  - xorcist 12y ago
    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.
  - Drakim 12y ago
    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.
  - Argorak 12y ago
    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.

blueskin_ 12y ago

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

antocv 12y ago
Did webdevelopers think otherwise any time? Serves them right, noone should be using CDNs for code.
- noselasd 12y ago
  And certainly not load it over http.
- twelve40 12y 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.
  - antocv 12y ago
    Dont use google analytics or ads, dont rat out your neighbours to Stassi - modern form, dont snitch out your users habit to private nsa.

quarterto 12y 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 https://news.ycombinator.com/item?id=5742893 ninja edit: qwertial aphasia

annnnd 12y 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 12y 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 12y ago
Strange, it doesn't happen for me.

deweller 12y ago

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