71–80 of 113 posts
Seems rather similar to the strong_password case from a month back: https://news.ycombinator.com/item?id=20377136 . I wonder if anyone has checked basic things like scanning all of rubygems for "pastebin" or "eval( * http * )".
I'm wondering why wouldn't RubyGems implement some basic form of malware detection? This type of code shouldn't be too hard to classify.
I'm an author of gems with a total of more than 4 million downloads. I just setup 2fa now after seeing this.
I actually ended up going further and removing me as author from gems I don't actually maintain anymore, which brings down my exposure considerably. It's actually not as easy as it could be to remove yourself as an author from a gem (have to do it via command line).
Hey since this is blown up I just want to address it directly. I take responsibility for what happened here. 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 mis…
Hey since this is blown up I just want to address it directly. I take responsibility for what happened here. 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 mis…
Hey since this is blown up I just want to address it directly. I take responsibility for what happened here. 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 mis…
Wow, that's a pretty well executed and possibly targeted attack then. It blows my mind how easy it can be to perform a high impact attack by abusing popular libraries. Hopefully this was caught before it got into production in high profile implementations.
1) Find high-value target libraries
2) Grab the usernames of accounts with push access
3) Check those against password dumps
I feel really stupid about this, but like I said it was an oversight. I apologize and will try to do better.
Earlier quoted context omitted.
It's also likely it was done by an intelligence agency.
Not really. The attacker seemed to target bitcoin once again... surprising this shit is still profitable, though.
If the cost of the attack is as near to zero as makes no odds, any income is profit, whether it comes from being able to compromise bitcoin related accounts elsewhere, getting a miner to run on 00s of servers and/or 000s of clients, or getting other details to use in a "send me bitcoint and I will/won't X" blackmail. And if there is no income from the attack, the cost of trying is near zero.
Earlier quoted context omitted.
Wow, that's a pretty well executed and possibly targeted attack then. It blows my mind how easy it can be to perform a high impact attack by abusing popular libraries. Hopefully this was caught before it got into production in high profile implementations.
Yeah I'm assuming the methodology is: 1) Find high-value target libraries 2) Grab the usernames of accounts with push access 3) Check those against password dumps I feel really stupid about this, but like I said it was an oversight. I apologize and will try to do better.
Earlier quoted context omitted.
Wow, that's a pretty well executed and possibly targeted attack then. It blows my mind how easy it can be to perform a high impact attack by abusing popular libraries. Hopefully this was caught before it got into production in high profile implementations.
Yeah I'm assuming the methodology is: 1) Find high-value target libraries 2) Grab the usernames of accounts with push access 3) Check those against password dumps I feel really stupid about this, but like I said it was an oversight. I apologize and will try to do better.
The larger question is about if gem/npm/cargo-style package managers are such a terrific idea in the long run. The security implications are pretty serious.
Earlier quoted context omitted.
Seems like a pointless, false sense of security. What about all the attacks where the malicious actor is someone with publish rights, like friendly package takeover? Your proposal makes that even more effective since now the attacker gets a nice "published with mfa" badge.
It would have prevented this attack, so I'm not sure how its pointless. Obviously it doesn't fix everything. MFA is MFA. I don't know why anyone would take it as a guarantee that some third-party has audited all the code.
Earlier quoted context omitted.
I don't think nightly builds are the same thing as releases - you can have CI publish a build but to create a versioned public release it should require manual auth.
That's a view of course (although in the case of gVisor they don't actually do versioned build just nightlies) but here's a question. As a consumer of software libraries, have you ever looked into the security practices of the library author before choosing whether to use it or not?