Backdoor Code Found In 11 Ruby Libraries

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.

Attribution

[thermopile]

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

Re:Attribution

[h33t l4x0r]

Some anonymous user? You'll learn more by tracking the crypto.

Re:Attribution

[Solandri]

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

[K. S. Kyosuke]

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.

It's turtles all the way down!

[Way Smarter Than You]

Sorry but someone had to say it!

Re:

[gitano_dbs]

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

They compromised one maintainers account.

Re:

[invictusvoyd]

And the maintainer has no clue of commits from his account?

Re:Attribution

[OrangeTide]

Who obsessively checks their own ancient commit history?

Re:

[Darinbob]

Well, why would anyone use a library that ships as source code and NOT read the source? And the issue was found by maintainers, which is even weirder that there are maintainers who aren't reviewing any and all commits. You would hope that anything like this would have been found within a few days at the worst, and hopefully within hours.

Re:

[Njovich]

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

Re: Number of Ruby Projects

[Zero__Kelvin]

Redmine is implemented in Ruby so anyone who says you can't develop stellar software with it is a moron. Every language has been used to create a lot of shit software. Only an ignoramus blames the language for the stupidity of man.

Re:

[weilawei]

Then there's Brainfuck, which has only been used to create shit software.

Re:

[Darinbob]

Also split Ruby apart from Ruby On Rails, these are different things. Ruby the language is a very good language.

Hipster Programmers

[johnsie]

That will teach all those hipsters who use ruby. Hopefully Node JS will next. Fucking neckbeards.

Re:

[Morrighu]

You forgot the man buns.

Re:

[Viol8]

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

Re:Hipster Programmers

[DarkOx]

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

Eveb worse in web deve;lopment

[Viol8]

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:

[AHuxley]

The climate change with the extra energy use every time cryptocurrency mining starts.

Re:

[pr0fessor]

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

already happened...

Whaddaya mean "only"

[Kokuyo]

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?

Re:

[grep -v '.*' *]

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

Re:Whaddaya mean "only"

[tepples]

That was left-pad in March 2016, where the maintainer of a package called "left-pad" and another package called "kik" took down his package because lawyers for the operator of the Kik instant messaging service claimed trademark infringement on "kik". Previous coverage: "How One Dev Broke Node and Thousands of Projects In 11 Lines of JavaScript" [slashdot.org]

Re:

[h33t l4x0r]

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.

Re:

[steveb3210]

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

"abuse"

[Kunedog]

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.

Wonder Who the ~4000 Were Who Got Them

[Morrighu]

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?

Re:

[iggymanz]

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.

article conflates libraries and gems

[iggymanz]

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

Supply Chain Issue on Rails

[Frank Rietta]

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.

I'm shocked

[Drunkulus]

Shocked, I tell you.

Find and Hire the Best App Developers

[JulsYa]

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]