Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Ruby Privacy Security Technology

Backdoor Code Found In 11 Ruby Libraries (zdnet.com) 36

Posted by BeauHD from the lost-and-found dept.
Maintainers of the RubyGems package repository have yanked 18 malicious versions of 11 Ruby libraries that contained a backdoor mechanism and were caught inserting code that launched hidden cryptocurrency mining operations inside other people's Ruby projects. ZDNet reports: The malicious code was first discovered yesterday inside four versions of rest-client, an extremely popular Ruby library. According to an analysis by Jan Dintel, a Dutch Ruby developer, the malicious code found in rest-client would collect and send the URL and environment variables of a compromised system to a remote server in Ukraine. "Depending on your set-up this can include credentials of services that you use e.g. database, payment service provider," Dintel said.

The code also contained a backdoor mechanism that allowed the attacker to send a cookie file back to a compromised project, and allow the attacker to execute malicious commands. A subsequent investigation by the RubyGems staff discovered that this mechanism was being abused to insert cryptocurrency mining code. RubyGems staff also uncovered similar code in 10 other projects. All the libraries, except rest-client, were created by taking another fully functional library, adding the malicious code, and then re-uploading it on RubyGems under a new name. All in all, all the 18 malicious library versions only managed to amass 3,584 downloads before being removed from RubyGems.
This discussion has been archived. No new comments can be posted.

Backdoor Code Found In 11 Ruby Libraries More

Backdoor Code Found In 11 Ruby Libraries

Comments Filter:

  • Attribution (Score:5, Insightful)

    by thermopile ( 571680 ) on Thursday August 22, 2019 @02:15AM (#59111542) Homepage
    If only there were a way to determine who made the commits to the code...

    • Re:Attribution (Score:4, Insightful)

      by h33t l4x0r ( 4107715 ) on Thursday August 22, 2019 @03:20AM (#59111592)
      Some anonymous user? You'll learn more by tracking the crypto.

      • Re:Attribution (Score:5, Interesting)

        by Solandri ( 704621 ) on Thursday August 22, 2019 @08:26AM (#59112112)
        There was a programming thought experiment [cmu.edu] back in the 1980s on how you could insert malicious code which was undetectable at the source code level. It came up in my Scheme course when the instructor said we basically don't know how to write a Scheme compiler. What we've done is back in the early days we wrote a rudimentary Lisp compiler in C. Once that was working, we used the cut-down version of Lisp to write a more complete Lisp compiler. That compiler was then used to compile future Lisp compilers, including the Scheme compiler. We don't know how to write a Scheme compiler in C - what we have is several generations of Lisp compilers making new Lisp compilers.

        In the same way, if you add a backdoor code to a codebase, people can find it and fix it. If you modify the compiler's codebase to add the backdoor to anything it compilers, that's a little harder to spot. But anyone perusing the compiler's source code could find it. On the other hand, if you modified the compiler's code to insert the backdoor, then used it to compile a new version of the compiler, and somehow made sure that that compiler binary was used to compile the next version of the compiler, then your malicious code wouldn't need to be in the source code. The compiler would insert it into anything it compiled. And any future version of the compiler compiled with that compiler would automatically have the backdoor inserted as well. Which would thus insure that all future compilers would also have the malicious routine in it, with nary a trace of it in the source code.

        Basically, there's no way to be sure any code is safe, unless you wrote and built everything from scratch. Including the original machine code used to build your first rudimentary compiler, which is then used to build future compilers.

        • Re:Attribution (Score:5, Interesting)

          by K. S. Kyosuke ( 729550 ) on Thursday August 22, 2019 @08:47AM (#59112176)

          We don't know how to write a Scheme compiler in C - what we have is several generations of Lisp compilers making new Lisp compilers.

          Fortunately, you can run a Scheme compiler written in Scheme in a Scheme interpreter written in C (or anything, really). It will be dog-ass slow but at least you should be able to compare the results with the one of running the Scheme compiler written in Scheme compiled using itself. One would think that this is a major benefit of fundamentally simple languages: a basic implementation of such a language you can use for validating programs will be rather simple as well.

        • Sorry but someone had to say it!

    • If only there were a way to determine who made the commits to the code...

      They compromised one maintainers account.

    • Re: (Score:3)

      by Njovich ( 553857 )

      You mean as in some sort of total information awareness sense where you have to supply DNA material before using the internet and all your data is logged? Most people don't do this stuff under their own name, mister thermopile(571680).

  • Hipster Programmers (Score:5, Funny)

    by johnsie ( 1158363 ) on Thursday August 22, 2019 @03:24AM (#59111596)
    That will teach all those hipsters who use ruby. Hopefully Node JS will next. Fucking neckbeards.

    • Re: (Score:3, Funny)

      by Morrighu ( 2737899 )
      You forgot the man buns.

      • Re: (Score:2)

        by Viol8 ( 599362 )

        And the "I'm such an individual" victorian style clothing worn by every other fucking hipster on the planet.

    • Re:Hipster Programmers (Score:5, Insightful)

      by DarkOx ( 621550 ) on Thursday August 22, 2019 @06:45AM (#59111910) Journal

      This has happened with node before href="https://www.bleepingcomputer.com/news/security/npm-pulls-malicious-package-that-stole-login-passwords/">. I don't have link handy but I am sure its either happened in pip/python or the malicious content is there and nobody has spotted it yet.

      I'd bet NuGet isn't far behind either. This isn't a ruby problem its an ecosystem problem. I am not trying to be some crank here that says reinvent every wheel yourself but once upon a time your project included three types of libraries. First, your language's standard library usually well controlled well vetted and fairly trust worthy. Those your primary platform vendor (who was mostly trust worthy shipped), similarly trust worthy and reasonably solid. Finally open source or COTS stuff you looked over and carefully evaluated if it met your needs and met your quality standards.

      Now days the process is:
      1) "search the web" pick the first hit seems to do what you want.
      2) Call gem/pip/nuget/npm; waste time on slack and miss the 15 dependencies that scrolled by and also got pulled into your project.
      3) Insert dubious code path into project, with no understanding of the performance, algorithms involved etc
      4) Maybe have a look at gem.lock at some point if you happen to remember.
      5) ???
      6) wait for someone from IT Security to tell you syck/nessus/checkmax/retire.js etc says there is an issue
      7) Realize the problem is with some N level dependancy you have no idea if you can safely change without a major code audit of all that trash you imported
      9) update the flagged library anyway and hope for the best; hey our tests ran so its okay...

      Its really a mess.This probably describes the process for better organizations and better projects too, I suspect the vast majority end at step 5

      • Hey, lets just get the browser to pull in completey unrevified code from 2 dozen random sites (with a similar number of sub dependencies) onto your machine and run it! What could possibly go wrong?

    • Re: (Score:1)

      by AHuxley ( 892839 )
      The climate change with the extra energy use every time cryptocurrency mining starts.

    • https://securityintelligence.c... [securityintelligence.com]

      already happened...

  • Whaddaya mean "only" (Score:4, Interesting)

    by Kokuyo ( 549451 ) on Thursday August 22, 2019 @03:30AM (#59111608) Journal

    Aren't these downloads indicative of 3500 compromised software projects? Wouldn't the amount of "infected" users be much higher if these libraries found their way into GA versions of these projects?

    • What was it that kinda melted the internet down a year or two ago? Someone has like strtrim() defined as a subroutine, the hosting site changed their legal document, and so he hid/deleted his function. And then half the internet couldn't function without it. (I presume new builds, but there was a large uproar over it. And it was a minimal function.) Why people couldn't write their own or why it wasn't in the standard library, I don't understand. It's not like it was a 4-D game rendering engine, it was
    • Nope. It's indicative of a lot of automated downloads and maybe a handful of actual real-world installs.
      And those guys can go fuck themselves for installing obscure retarded libraries.

    • Probably not, most projects use Bundler and install gems at install (akin to npm / package.json in nodejs)..

  • The code also contained a backdoor mechanism that allowed the attacker to send a cookie file back to a compromised project, and allow the attacker to execute malicious commands. A subsequent investigation by the RubyGems staff discovered that this mechanism was being abused to insert cryptocurrency mining code.

    If it's a backdoor mechanism then that's just simple use, not abuse.

  • The article says that the poisoned libraries were downloaded almost 4000 times. I wonder who's going to get pwned because their DevOps pushes this into production as part of a microservice?

    • DevOps here.

      very few, as "gems" are 3rd party crap. we don't use them. we don't need them. smart people would vet the code and not blindly use 3rd party crap.

      The whole gem system is cobbled together dangerous stuff, great for school projects or tinkering I suppose.

      the official ruby libraries you get when you install ruby are something else. Avoid gems if you can't read code.

  • Gems are a 3rd party pile of stuff, often low quality. It's like CPAN in perl.

    We don't even use gems with our ruby code at work.

    don't use random 3rd party crap in your wares.

    Looking at the list I'd expect only that primitive rest thing to be common

  • We definitely have an open source supply chain issue to address. Code signing is no panacea in an environment of community contributors. My co-worker Chris Choi just wrote on The Case for 2FA, Post Rest-client Gem CVE at https://rietta.com/blog/rest-c... [rietta.com]. It includes an interview with Matt Manning, whose Rubygems account was compromised and used to push the malicious code to rest-client. At this point, the best we can hope is to get the word out to other popular Gem maintainers.
  • Shocked, I tell you.
  • Hi! I agree the development of web/mobile applications is not an easy task. Some applications require a lot of effort on the part of the developer and a lot of time, so it's hard to find professionals. Evans Data Corporation estimates there are 23 million people working as desktop, web, and mobile app developers worldwide. If you pick one of them without putting too much thought into it, you’ll harm your business. An interesdting article provides a few tips on how to find app developers: https://yalan [yalantis.com]

Slashdot Top Deals

Your own mileage may vary.

Close