Slashdot Mirror

← Back to Stories (view on slashdot.org)

Zero-Day In Popular jQuery Plugin Actively Exploited For At Least Three Years (zdnet.com)

Posted by BeauHD on from the flying-under-the-radar dept.

Slashdot reader generic shares a report from ZDNet: For at least three years, hackers have abused a zero-day in one of the most popular jQuery plugins to plant web shells and take over vulnerable web servers, ZDNet has learned. The vulnerability impacts the jQuery File Upload plugin authored by prodigious German developer Sebastian Tschan, most commonly known as Blueimp. The plugin is the second most starred jQuery project on GitHub, after the jQuery framework itself. It is immensely popular, has been forked over 7,800 times, and has been integrated into hundreds, if not thousands, of other projects, such as CMSs, CRMs, Intranet solutions, WordPress plugins, Drupal add-ons, Joomla components, and so on.

Earlier this year, Larry Cashdollar, a security researcher for Akamai's SIRT (Security Intelligence Response Team), has discovered a vulnerability in the plugin's source code that handles file uploads to PHP servers. Cashdollar says that attackers can abuse this vulnerability to upload malicious files on servers, such as backdoors and web shells. The Akamai researcher says the vulnerability has been exploited in the wild. "I've seen stuff as far back as 2016," the researcher told ZDNet in an interview. The vulnerability was one of the worst kept secrets of the hacker scene and appears to have been actively exploited, even before 2016. Cashdollar found several YouTube videos containing tutorials on how one could exploit the jQuery File Upload plugin vulnerability to take over servers. One of three YouTube videos Cashdollar shared with ZDNet is dated August 2015. Thankfully, the CVE-2018-9206 identifier was pushed earlier this month to address this issue. "All jQuery File Upload versions before 9.22.1 are vulnerable," reports ZDNet. "Since the vulnerability affected the code for handling file uploads for PHP apps, other server-side implementations should be considered safe."

44 comments

  1. Dang IT by Anonymous Coward · · Score: 2, Funny

    them

    haz

    finally

    founded

    it...

    1. Re:Dang IT by arglebargle_xiv · · Score: 1

      prodigious German developer Sebastian Tschan

      Not to be confused with prodigious German action-film actor Jackie Tschan.

  2. How can this be? by Anonymous Coward · · Score: 0, Troll

    Open Source cannot have security flaws in it, unlike proprietary software. After all, millions of eyes are looking over it, and with that number, one would expect it to be flawless.

    1. Re:How can this be? by Anonymous Coward · · Score: 0

      Just
      like
      someone
      would
      expect
      that
      a million monkeys
      with
      typewriters
      would
      be
      able
      to
      write
      the works of shakespeare.

      That is how.

      But maybe you prefer to believe the earth if flart?

    2. Re: How can this be? by Anonymous Coward · · Score: 0

      Everything is flat. The 3rd dimension is just am illusion.

  3. This is why by phantomfive · · Score: 1

    This is why "keeping your patches up to date" is not enough. The problem is not enough focus on security by developers.

    --
    "First they came for the slanderers and i said nothing."
    1. Re:This is why by Anonymous Coward · · Score: 0

      You cant spends 25 hours daily checking security... you may as well turn it off.

    2. Re:This is why by Opportunist · · Score: 1, Flamebait

      The problem is that javascript is mostly developed by people who have no fucking clue what they're doing. Most of them come from webdesign and when they found out that there's not even a market for a fraction of them, they muscled into the server world.

      And now we have this pile of pus on the backend, too.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    3. Re:This is why by Anonymous Coward · · Score: 0

      I always make sure my patches have the latest date set, and are synchronised to my local atomic clock or GPS

      That should be enough.

      right ?
      Right?
      Right ?!?

    4. Re: This is why by phantomfive · · Score: 1

      Your words are harsh and insulting but I don't say inappropriate.

      --
      "First they came for the slanderers and i said nothing."
    5. Re: This is why by Anonymous Coward · · Score: 0

      I do turn off javascript.

    6. Re: This is why by Anonymous Coward · · Score: 0

      Partly true. JavaScript just will not die, true.

      In the case of this exploit, this is just people being sloppy, start to finish, and those g-d hackers exploiting our laziness. GitHub has made many very lazy. Testing is a lost art, sad.

    7. Re: This is why by Anonymous Coward · · Score: 0

      The pope is not above physics.

    8. Re:This is why by phantomfive · · Score: 2

      You cant spends 25 hours daily checking security... you may as well turn it off.

      This is the attitude that really messes things up. "We can't be perfect.....why bother?"

      The proper security attitude should be, "Maybe we can't be perfect......but we can be pretty good." And sometimes you can be perfect (like you can perfectly avoid SQL injection attacks. That is something that can be done).

      --
      "First they came for the slanderers and i said nothing."
    9. Re:This is why by Anonymous Coward · · Score: 0

      The problem is not enough focus on security by developers.

      Yes, but whose fault is that? They who pay the salaries call the shots and that's not usually the developers themselves.

    10. Re:This is why by squiggleslash · · Score: 1

      Is it? Because I can't make head or tail of the summary. It's saying that malicious Javascript can compromise a PHP server. Does this plug-in include a server side component?

      Because the only way I can see that you can blame this plugin for compromising servers is if it does, and if that's the case then the actual exploit is PHP, not Javascript. If not, then WTF?

      --
      You are not alone. This is not normal. None of this is normal.
    11. Re:This is why by AC-x · · Score: 3, Informative

      Yeah the issue is in a PHP script that comes with a popular jQuery plugin to handle the server side part of the file upload system it provides. I think the PHP script in question was written by the same guy as wrote the jQuery plugin, hence the "Javascript developers are crap" parent comment I guess.

    12. Re:This is why by jon3k · · Score: 1

      The scary part is this wasn't some random web designer. This was a "prodigious German developer Sebastian Tschan".

      Just imagine what those webdesigners are building ... shudders.

    13. Re: This is why by c6gunner · · Score: 1

      Wtf? And someone (or rather several someones) thought that "Zero-Day In Popular jQuery Plugin" was a good headline for a story about a crappy PHP script?

      This place is really falling apart.

    14. Re: This is why by Anonymous Coward · · Score: 0

      Technically it is related to it.
      Actually, to be really accurate, a jQuery package or toolkit, or similar term.
      It is still part of the plugins use-case, you could roll your own server-side script, but let's face it, jQuery was set up for retards, most wouldn't.

  4. Good eye. by Anonymous Coward · · Score: 1

    discovered a vulnerability in the plugin's source code that handles file uploads to PHP servers.

  5. Not quite as bad as it sounds by Gavagai80 · · Score: 4, Informative

    The vulnerability is in their PHP code, which is basically sample code. Most projects using the uploader write their own PHP handler for their own specific upload purposes. Only a project that just wants to generically accept all files would consider using their sample PHP code. Verified that my PHP scripts aren't affected despite using the blueimp uploader.

    --
    This space intentionally left blank
    1. Re:Not quite as bad as it sounds by 93+Escort+Wagon · · Score: 1

      The vulnerability is in their PHP code, ...

      You need say no more.

      --
      #DeleteChrome
    2. Re:Not quite as bad as it sounds by Anonymous Coward · · Score: 0

      Wow. and here I thought all that shitty c and c++ was so easy to 0day after owning hundreds of thousands of systems exploiting services running such languages. This must prove definitively that PHP is on the same shitty security level as c, c++ and java.

      Thanks for the insight

    3. Re:Not quite as bad as it sounds by Anonymous Coward · · Score: 5, Informative

      From my understanding, the plugin is very generic, and accepts all files, including PHP scripts and .htaccess files. The idea being that the website developer is supposed to do his own filtering. Of course, some developers will use it blindly and leave this kind of generic file uploader publicly accessible.

      Depending on how the code was documented, this is not directly the fault of the plugin developer. 'Seems way overblown in itself. But there sure could be high-profile problematic uses.

    4. Re:Not quite as bad as it sounds by gweihir · · Score: 1

      Unfortunately, a lot of incompetent coders (and there are a lot of them, not only because this is PHP) do use sample code frequently. I agree that for a competent coder, the whole thing is probably a non-issue, but that is not the reality of things.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:Not quite as bad as it sounds by Hognoxious · · Score: 1

      You could make it so the types of files (though how it identifies them is another question) is opt-in. IOW it accepts nothing out of the box.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  6. Yawn. by Narcocide · · Score: 1

    Not actually surprised, jquery sucks.

    1. Re:Yawn. by Anonymous Coward · · Score: 0

      Even more not actually surprised, javascript sucks.

    2. Re:Yawn. by Anonymous Coward · · Score: 0

      Even more more not actually surprised, web development sucks

  7. Dum*ss' here's a big fsck you by bigmacx · · Score: 1

    Unforgivable. A lot of people let this go on for a long time. Sounds truly idiotic

  8. People still use Jquery? by Anonymous Coward · · Score: 0

    native java commands and html5 have replaces a lot of the need.
    using a package like that is risking things.

    1. Re:People still use Jquery? by Anonymous Coward · · Score: 0

      Java? What the fuck are you smoking?

      numbnuts

  9. Wait, is that his real last name? by Anonymous Coward · · Score: 0

    > Larry Cashdollar

    Seriously?

    1. Re:Wait, is that his real last name? by Anonymous Coward · · Score: 0

      Yes, it's his real name. Everyone asks that.

    2. Re:Wait, is that his real last name? by Anonymous Coward · · Score: 0

      > Larry Cashdollar

      Seriously?

      Must be a Jew.

      Do you know why Jews have big noses? Because air is free.

    3. Re: Wait, is that his real last name? by Anonymous Coward · · Score: 0

      No way he is Jewish have you seen his twitter avatar. He is kinda hot.

  10. Apache developers are to blame by dmpot · · Score: 2

    Accordingly to the article: "Starting with this version [version 2.3.9], the Apache HTTPD server got an option that would allow server owners to ignore custom security settings made to individual folders via .htaccess files. This setting was made for security reasons, was enabled by default, and remained so for all subsequent Apache HTTPD server releases."

    I wonder how many other plugins are silently broken due to this change.

  11. If it's been used for three years ... by Qbertino · · Score: 1

    ... it's not zero-day.

    It's a critical bug that has gone largely undiscovered. Which is surprising, given the installbase of it's host-code. The hacker probably was careful not to exploit it to openly.

    --
    We suffer more in our imagination than in reality. - Seneca
    1. Re:If it's been used for three years ... by Anonymous Coward · · Score: 0

      Actually that's the definition of a zero-day. A vulnerability exploited in the wild without the vendor or users being aware of it. Emphasis on "exploited."

    2. Re:If it's been used for three years ... by Anonymous Coward · · Score: 0

      Actually that's the definition of a zero-day. A vulnerability exploited in the wild without the vendor or users being aware of it. Emphasis on "exploited."

      Maybe it should be called a -1,000 day or minus however many days, to show how long it's been exploited.

  12. Larry Cashdollar is old school by Anonymous Coward · · Score: 0

    Wasn't he down with the Money Crew back in the day?

  13. Author of jQuery File Upload here by blueimp · · Score: 1

    I've wrote a comment with some background information on Hacker News: https://news.ycombinator.com/i...

    Copying the content here for ease-of-use:

    The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component.

    To give you some context on how this could happen:

    • As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file
    • Over time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production
    • I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured.
    • Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQu...
    • The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it
    • The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQu...

    Looking back, there are a couple of things that I should have done differently:

    • Move out the server-side components into separate repositories
    • Inform users better about file upload security - see https://github.com/blueimp/jQu...
    • Never assume people actually read information about security
    • Never rely on .htaccess for security configurations in Apache
    • Make sure that published code is secure in all default configurations
    • Never allow all file types for upload by default, even if it is secure in your configuration
    • Recommend users to not upload files in the same root as their executable web application
    • Always follow security best practices, even if it makes setup for users more difficult

    I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other.

    Bonus info:

    1. Re:Author of jQuery File Upload here by q4Fry · · Score: 1

      +1 Informative