Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Security Software

jQuery.com Compromised To Serve Malware 103

Posted by timothy from the send-you-this-query-to-have-your-advice dept.
An anonymous reader writes jQuery.com, the official website of the popular cross-platform JavaScript library of the same name, had been compromised and had been redirecting visitors to a website hosting the RIG exploit kit and, ultimately, delivering information-stealing malware. While any website compromise is dangerous for users, this one is particularly disconcerting because of the demographic of its users, says James Pleger, Director of Research at RiskIQ.
This discussion has been archived. No new comments can be posted.

jQuery.com Compromised To Serve Malware More

jQuery.com Compromised To Serve Malware

Comments Filter:

  • They will never learn (Score:5, Interesting)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday September 23, 2014 @12:03PM (#47974521) Homepage Journal

    People get upset when you call them incompetent for sourcing stuff out to foreign CDNs, but stuff like this happens all the time. It's not safe to pull stuff in from other sites for reasons which are obvious to anyone competent.

    • Re:They will never learn (Score:5, Informative)

      by _xeno_ ( 155264 ) on Tuesday September 23, 2014 @12:16PM (#47974645) Homepage Journal

      According to the article, the library itself wasn't affected.

      Plus most people don't use jQuery.com as a CDN. Instead jQuery recommends you use Google's CDN if you want to use a CDN for jQuery.

      Of course, this is still bad - I visit jQuery.com fairly frequently to check the documentation. The article doesn't say what was required for the malware to run so I have no idea if I was vulnerable to it or not, but if it was dropped on all pages and not just the home page, I definitely could have been hit by it.

      • Re: They will never learn (Score:1)

        by Anonymous Coward

        Wrong. You're supposed to use code.jquery.com, which is hosted by (wait for it) jQuery. You know, the people who were compromised.

        There's apparently no sign the jQuery CDN was hacked (jQuery.com is a different server), but it's not a good sign if you use the CDN you're supposed to use, the theory being browsers only need to cache the single code.jquery.com copy of the library instead of one per site.

        But, you know, go ahead and spread false information. It's Slashdot, after all.

        • Re: (Score:1)

          by Anonymous Coward
          For many years code.jquery.com actually to Google itself [jquery.com]. It wasn't until about a year ago that they got support from a different CDN to host it from code.jquery.com directly again. They still list alternative CDNs on their instructions, and say you can use which ever works best as long as you don't mind alternatives being possibly a couple days out of date on updates.
      • It was a drive-by download - no action required on your part to get popped.

      • Re: (Score:2)

        by CODiNE ( 27417 )

        Have you ever said "I don't run a virus scanner and I've never gotten a virus"?

      • Re: (Score:3)

        by tlhIngan ( 30335 )

        Plus most people don't use jQuery.com as a CDN. Instead jQuery recommends you use Google's CDN if you want to use a CDN for jQuery.

        While the recommendation may be there, I can tell you that is NOT the case. Far too often if you use NoScript, "jquery.com" is listed right there as a necessary script for the website to work.

        • Re: (Score:2)

          by TWX ( 665546 )
          Yep. I HATE cross-site scripting. Unfortunately everyone under the sun has gone to it in the last few years even when it doesn't seem to serve any purpose, even for advertising revenue.

          • Re:They will never learn (Score:4, Informative)

            by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Tuesday September 23, 2014 @06:12PM (#47978661) Homepage Journal
            The purpose for parking JavaScript on a CDN is so that your visitors are likely to already have it in their cache. A million sites referring to the same URL is far more resource friendly than 10,000 sites hosting their own copy.

            • The purpose for parking JavaScript on a CDN is so that your visitors are likely to already have it in their cache.

              If you're dumping so much JS on your users that this matters, you're doing it wrong. If your users visit your site so infrequently that your site doesn't stay cached, then it probably doesn't matter anyway.

              • But if you and I are using the same library, why make the visitor fetch and store it twice? That's a slower startup for both of our sites. Multiplied across hundreds of thousands of jQuery-using instances, it adds up.

                The fastest GET is the GET which need not be made.

                • But if you and I are using the same library, why make the visitor fetch and store it twice?

                  Because of things like this. Sure, the library was allegedly not compromised, but that's this time.

                • Re: (Score:2)

                  by sjames ( 1099 )

                  Because I feel at least some sense of responsibility for not infecting people who visit my site but I have no idea how well you or some other party have secured their sites.

    • Re:They will never learn (Score:5, Informative)

      by Dracos ( 107777 ) on Tuesday September 23, 2014 @12:20PM (#47974689)

      You're speaking of the wrong "they". jQuery.com runs WordPress: that's the incompetence. If I had a nickel for every WP-based exploit or compromise, I'd have about $50, and I'm pretty sure this is another one.

    • Re:They will never learn (Score:4, Insightful)

      by pooh666 ( 624584 ) on Tuesday September 23, 2014 @12:47PM (#47975013)
      What makes YOUR site so safe?

      • There's only one of it?

      • Re: (Score:1)

        by Anonymous Coward

        By offloading resources resources to an external site you introduce an additional point of failure. If that site goes down or becomes compromised, your site does as well. However, if your site goes down or gets compromised, it's already down/compromised, so it doesn't matter that the external resource is also there.

      • The exact moment when your site is safe is when you think it is safe.

        Because at the point where you think it is safe, is the point where you have stopped trying to improve security and that is when problems can happen.

        • So... it's safe when you think it's safe, and when you think it's safe, it's not safe? So when it's safe, it's not safe?

      • Re: (Score:1)

        by Anonymous Coward

        What makes YOUR site so safe?

        Nobody uses it.

      • My site is not particularly safe. I'm using specious hosting and the most I do is occasionally log in and run updates.

        However, my site is safer than my site plus some other sites, too.

        • Re: (Score:3)

          by lennier ( 44736 )

          My site is not particularly safe. I'm using specious hosting

          That's nothing, I've implemented an entire fallacious reasoner on a casuistic cloud architecture using sophistic inferencing. I'm pretty confident in the results I'm getting.

      • What makes YOUR site so safe?

        I used FrontPage to create it, and host it on MySpace.

    • Re: (Score:2)

      by Alrescha ( 50745 )

      My firewall is whitelist-based. This means if a site uses stuff hosted off-site (jquery, googleapis) it probably isn't going to load. The net affect is that while I can browse such storefronts, I have to do work to buy from them. So I buy elsewhere. They might learn, eventually.

      A.

      • Re: (Score:2)

        by TWX ( 665546 )
        They won't learn. There have always been individuals that have gone against the grain or against the easiest path. You happen to be among them right now, and that element is small enough that it doesn't really pose a problem for everyone else.

      • My firewall is whitelist-based. This means if a site uses stuff hosted off-site (jquery, googleapis) it probably isn't going to load. The net affect is that while I can browse such storefronts, I have to do work to buy from them. So I buy elsewhere. They might learn, eventually.

        They won't notice or care. Why would they? You aren't doing anything to trip any kinds of alarms or alerts with them.

        If you want them to do something, call their help desk and act like an incompetent computer user. "My kids set up this newfangled computer and I can't buy from you..." If enough people did that it might make a blip on their stats that "JavaScript All The Things!" menatlity will cost them in support calls and possibly lost business.

    • I disagree with your basic premise, that things are secure, or insecure. Everything is a tradeoff. Using a foreign CDN is a tradeoff of trusting a third party to be secure vs doing it yourself. Just because you do it yourself doesn't mean it's "more secure", it's just more in your control, which can be good or bad.

      We make this tradeoff all the time. Have you ever used 3rd party software on your website? Well then you're making a tradeoff as well.

      You're right to be suspcious of trusting a 3rd party, but

    • Re: (Score:2)

      by chrish ( 4714 )

      Pulling bits from a foreign CDN also leaks information via the referrer headers, which might be something you need to worry about if you're using it for internal projects.

    • Re: (Score:2)

      by unimacs ( 597299 )
      What? People don't like to be called incompetent ? Who knew ? ;)

      The chance of an average American being in a car accident in the next 5 years is 1 in 4. 37,000 people die each year in car accidents and over 2 million are injured. Yet most of us still drive even though a lot of us have alternatives. Having your site compromised is bad but for most of us it's a lot better than being dead. My point is that life is full of risks and trade offs.

      Using a CDN like googleapis to host some of your content can

  • wow.... (Score:5, Funny)

    by gandhi_2 ( 1108023 ) on Tuesday September 23, 2014 @12:12PM (#47974589) Homepage

    did I just hear some relevent news on slashdot before i saw it on twitter?

    today is a bright, shiney day!

  • The key piece of info that you need to know (Score:5, Informative)

    by Fnord666 ( 889225 ) on Tuesday September 23, 2014 @12:13PM (#47974601) Journal
    The key piece of info that you need to know is this:

    The only good news in all of this is that there is no indication that the jQuery library was affected.

  • Thats not good. (Score:2, Interesting)

    by stewsters ( 1406737 )
    This is going to be a large one. Many small to medium websites use their cdn for hosting JQuery rather than pulling it down and hosting it themselves. Kinda feel a little better about hosting it myself now.

    • Re:Thats not good. (Score:4, Interesting)

      by Jason Levine ( 196982 ) on Tuesday September 23, 2014 @12:30PM (#47974821) Homepage

      Except they've said that the library wasn't affected. So it would just be people who went to the jQuery website... like I did a couple of days ago. :-O

      • Re: (Score:2)

        by _xeno_ ( 155264 )

        It would be nice if the article mentioned what browsers/plugins were vulnerable, wouldn't it? (And does this cover api.jquery.com or just the home page?) Although it wouldn't surprise me that they just don't know yet since jQuery is still investigating.

        I'm pretty sure I'm up to date with everything, but...

        • Exactly. I visited api.jquery.com with Google Chrome. Am I safe because I used Chrome or because I didn't go to www.jquery.com? Or am I still potentially infected? Was the infection only on September 18th (removed that day) or did it linger for a few days after this? (When I went there on September 19th, could I have been infected?) Details would be very helpful.

        • Re: (Score:1)

          by mi ( 197448 )

          I'm quite comfortable, that the browser I compiled myself — with customized optimization flags — running on a similarly custom-compiled operating system is secure. And, yes, the Java I use is also custom-compiled.

          Not saying, everyone else "deserve", what they are getting, but the Internet would be a finer place, if they all dropped-off for a while.

      • The good news is that admins are more likely to run flash block or equivalent settings, and jquery.com isn't one of those evil sites that requires flash.

        Now if we could just get Google to fully commit to a flash-free world...

    • Re: (Score:2)

      by pooh666 ( 624584 )
      yep, and the low visibility of your one single site means that any exploit on your version of jquery will be much more likely to go unnoticed. Not to mention the not RTFA part about it not affecting hosted versions.

  • More reason for Requestpolicy (Score:3)

    by TheCarp ( 96830 ) <sjc.carpanet@net> on Tuesday September 23, 2014 @12:20PM (#47974701) Homepage

    This is exactly the sort of reason I run requestpolicy, and jquery is always one of the ones I hate seeing because I know what it means to allow so many sites to talk to load code the same one, so it only ever gets a temporary exception, same for googleapis.

  • Always assumed it was ... (Score:3)

    by gstoddart ( 321705 ) on Tuesday September 23, 2014 @12:25PM (#47974755) Homepage

    I have always treated it like it's an external 3rd party, not the web site I'm visiting, and therefore not an entity I trust.

    I've always viewed jquery as about as trusted as doubleclick or scorecardresearch. I don't know or care what you do, I didn't visit your site.

    But then, I've learned not to trust the web in general.

    With so many sites using this, dumping malware into it means you can get a whole lot of sites easily ... making this a fairly obvious target.

  • You mean... jQuery?

    (for the record I use it where appropriate, but it's also way over/misused)

  • Did a little research on the Rig exploit, and I've come away a bit confused: if I hit the exploited site while using a Mac, could the Mac be infected, and if so how could I tell - and how could I remove it if so? Thanks in advance.

    • I was looking into it also as I went to the jQuery.com site a day after the exploit was detected. (It was detected on September 18th. I visited the site on September 19th.) Apparently, the RIG exploit uses IE, Java, Flash and/or Silverlight. I'm not sure if my loading of the site in Google Chrome means that I'm safe or that I could still be infected.

  • Browser sniffer par excellence.

    • Yeah it's kinda crap in some ways. It sure is a nicer/cleaner/more readable/less-typing syntax though. Kinda like Groovy v Java.

    • Re: (Score:2)

      by PPH ( 736903 )

      It's a fscking bottleneck. Too many times, an otherwise useful page stalls trying to load something from jquery.com.

  • The attack should be a concern because jquery.com visitors are devs and sysadmins. But I understand RIG is a Windows malware. Who trust Windows enough to use the same machine surf the web and to store precious keys?

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close