Submitted via IRC for SoyCow3196
No REST for the wicked: Ruby gem hacked to siphon passwords, secrets from web devs
An old version of a Ruby software package called rest-client that was modified and released about a week ago has been removed from the Ruby Gems repository – because it was found to be deliberately leaking victims' credentials to a remote server.
Jussi Koljonen, a developer with Visma in Helsinki, Finland, discovered the hacked code in rest-client v1.6.13, and opened an issue to discuss the matter on the GitHub repo for the software. The gem, originally intended to help Ruby developers send REST requests to their web apps, was altered to fetch malicious code from pastebin.com that steals usernames, passwords, and other secrets from the client's host machine.
According to Jan Dintel, a developer with Digidentity in The Hague, Netherlands, when the infected client is used to send a REST request to a non-localhost website, the malware siphons off the URL of that site along with environment variables that may include authentication tokens, API keys, and other secrets you really don't want in the wrong hands. These details can be reused by the malicious code's mastermind to hijack the victims' accounts.
It also allowed arbitrary Ruby code to run on the infected host, and overloaded the #authenticate method in the Identity class to obtain and leak the user's email address and password every time the function is called to log into a service.
The creator of the cracked gem, Matthew Manning, a software developer based in Atlanta, Georgia, promptly apologized, saying that his rubygems.org account had been compromised.
"I take responsibility for what happened here," he explained in a post on Hacker News. "My rubygems.org account was using an insecure, reused password that has leaked to the internet in other breaches. I made that account probably over 10 years ago, so it predated my use of password managers and I haven't used it much lately, so I didn't catch it in a 1Password audit or anything. Sometimes we miss things despite our best efforts. Rotate your passwords, kids."
[...] Since developer-focused attacks have become more common, software repositories like rubygems.org, npm, and PyPI have encouraged developers to use multifactor authentication to help defend their accounts.
(Score: 2, Insightful) by Anonymous Coward on Thursday August 22 2019, @06:21AM
I (begrudgingly) accept not foisting them on users, but devs in security critical situations? They can manage it, then it doesn't matter how idiotic the company is, it just /can't/ leak your private key.
(Score: 0) by Anonymous Coward on Thursday August 22 2019, @04:54PM (2 children)
TLDR; a universal packaging format/standard, but on top of distros' package managers instead of under them.
I haven't packaged anything yet (except simple stuff for myself) so, this may be impossible for some reason, but i would prefer that the gnu\linux ecosystem work together so that language package managers (and Snaps, Flatpak and Appimage) weren't necessary. Any useful innovations of these packaging formats like atomic upgrades and isolation could be added to the solution/idea i'm proposing. IOW, *all upstream packages* should be installed via distro repos, but we need a universal packaging format(for all upstream software) above them that all distros' package managers can read. Then, distros need to be all rolling release (with different "tracks" of varying stability as they see fit) (this should be happening right now due to market pressure, but instead of dealing with the problem, Canonical and others have deployed these hacks to work around their antiquated release model) and all distros auto-building all the upstream packages for their repos, doing whatever checks need to be done for their needs/standards. All packages for all distros should be reproducible if upstream and the distro followed the format. Upstream would cooperate if they could just have one simple format for packaging for all of Linox.
Is this stupid? Impossible? why?
(Score: 2) by barbara hudson on Thursday August 22 2019, @05:58PM (1 child)
So, Yet Another Package Format ... you do realize that's how we got into the current mess, right? Why not just statically compile everything and dump it into a tarball along with all necessary data and config files.
A malicious update elsewhere in the software ecosystem won't shaft you because your binary has its own copy of any libraries. It also means that you can substitute a library for a smaller one of your own creation that has limited functionality, making it easier to debug. One binary to checksum to see if anything's been altered. Continues to work even when shared libraries on the host system get broken. Will work on different distros that may not have copies of needed libraries. And since everything needed is available in one directory or immediate subdirectories, it's easy to run off portable media such as a USB key, as well as easy to share.
Disk space is dirt cheap. Attacks on shared libraries, and the symlinks to them, are easy.
And maybe it will encourage devs to not include everything but the kitchen sink when they see their statically compiled programs true size. I know, every program grows until it can do email, but still ... I don't need a browser that understands how to render a poop emoji, and I don't think the rest of the world really does either.
(Then again, I don't need a browser that renders graphics at all, but that's just me).
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 0) by Anonymous Coward on Thursday August 22 2019, @06:14PM
I expected the opposition to another format, which is why i quoted The Lord of the Rings, but you offered an alternative, so i appreciate that. Something to consider.