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

Rubygems.org AWS Root Access Event – September 2025

rubycentral.org

Post reply on HN
Print view View original

111–120 of 179 posts

Re: Rubygems.org AWS Root Access Event – September 2025

#111

Post by tptacek »

phoronixrly wrote: post #102
tptacek wrote: post #98

Earlier quoted context omitted.

Isn't the subtext of this post pretty clearly that the unauthorized actor was Andre Arko, who had until days prior all the same access to RubyGems.org already? The impression I have reading this is that they're going out of their way to make it clear they believe it was him, but aren't naming him because doing so would be accusing him of a criminal act.

The other subtext is that they literally have no idea how to run rubygems securely... And what to do in case of a security incident...

I'm addressing the question of whether we all had better assume all the RubyGems published after this incident were compromised, and my response is "that is probably not rational since the actor in this scenario had all this access legitimately just days beforehand". The rest, I don't care.

Re: Rubygems.org AWS Root Access Event – September 2025

#112

Post by ctoth »

tptacek wrote: post #98
ctoth wrote: post #38

AWS account root access on a language package registry for 11 days. Not EC2 root - AWS account root. Complete control over IAM, S3, CloudTrail, every-damn-thing. They're claiming "no evidence of compromise" based on CloudTrail logs that AWS root could have deleted or modified. They even admit they "Enabled AWS CloudTrail" after regaining control - meaning CloudTrail wasn't running during the compromise window. You ca…

Isn't the subtext of this post pretty clearly that the unauthorized actor was Andre Arko, who had until days prior all the same access to RubyGems.org already? The impression I have reading this is that they're going out of their way to make it clear they believe it was him, but aren't naming him because doing so would be accusing him of a criminal act.

Let's say that they are 100% correct, we parse the subtext as text, it was totally him.

We still do not know the critical details of how (and when) he stored the root password he copied out of their password manager (encrypted in his own password manager? on his pwned laptop? in dropbox? we'll never know!) therefore the whole chain of custody is still broken.

Re: Rubygems.org AWS Root Access Event – September 2025

#113

Post by skywhopper »

The most notable thing about this post is the great lengths to which they are willing to go to detail every step of this process, something they never came close to doing in the fallout from the original stripping of rights from the longtime volunteers.

Re: Rubygems.org AWS Root Access Event – September 2025

#114

Post by knert »

placardloop wrote: post #110
ctoth wrote: post #82

Earlier quoted context omitted.

CloudTrail's 90-day immutable Event History only logs management events (IAM changes, instance launches, bucket creation). It does NOT log: * S3 object reads/writes (GetObject, PutObject) - these are "data events" requiring explicit configuration[0] * SSH/RDP to EC2 instances - CloudTrail only captures AWS API calls, not OS-level activity[1] With root access for 11 days, someone could modify gem files in S3, backdoor…

SSH is totally irrelevant here. Having AWS root account access doesn’t give you any ability to SSH to or otherwise access running instances. You could access data on those instances by cloning the EBS volumes or modifying build pipelines or changing network access or similar, but these would all show up in CloudTrail even without data events enabled. For S3 objects, you don’t necessarily need data events to identify…

I’m not sure this is true. The EC2 web console terminal drops me right into root on any of my instances.

Re: Rubygems.org AWS Root Access Event – September 2025

#115

Post by phoronixrly »

tptacek wrote: post #111
phoronixrly wrote: post #102

Earlier quoted context omitted.

The other subtext is that they literally have no idea how to run rubygems securely... And what to do in case of a security incident...

I'm addressing the question of whether we all had better assume all the RubyGems published after this incident were compromised, and my response is "that is probably not rational since the actor in this scenario had all this access legitimately just days beforehand". The rest, I don't care.

Look, it's enough to know that Rubygems did not require 2FA before August 2022. There were gems with millions of downloads with owners without 2FA on their accounts. I think your initial assumption is pretty safe even without the ongoing fiasco.

Re: Rubygems.org AWS Root Access Event – September 2025

#116

Post by andrewmcwatters »

RhythmFox wrote: post #103
andrewmcwatters wrote: post #97

Earlier quoted context omitted.

I think the point being that whatever was going on with access controls here was blatant gross negligence, because what is this guy doing with access who doesn't literally own the organization or the intellectual property? Set that aside, which obviously stinks, but then why is said obviously incompetent organization sharing confidential corporate emails with the public, saying this guy proposing a corporate data acc…

If only the Ruby ecosystem was really run by children, that sounds way more for than whatever this is. Joking aside though I think you are very right to question the professionalism behind this post. The narrative spin here is so toxic to good faith arguments around how we could change the 'supply chain' of Gems for the better. Wasn't that what this was all about Ruby Central? Can we get an update on that instead of…

Apparently the guy isn't even just a former admin, he actually seems to be a pivotal person around the whole formation of the RubyGems ecosystem, which is even weirder.

This isn't some random consultant who happened upon an admin position.

Re: Rubygems.org AWS Root Access Event – September 2025

#117

Post by placardloop »

knert wrote: post #114
placardloop wrote: post #110

Earlier quoted context omitted.

SSH is totally irrelevant here. Having AWS root account access doesn’t give you any ability to SSH to or otherwise access running instances. You could access data on those instances by cloning the EBS volumes or modifying build pipelines or changing network access or similar, but these would all show up in CloudTrail even without data events enabled. For S3 objects, you don’t necessarily need data events to identify…

I’m not sure this is true. The EC2 web console terminal drops me right into root on any of my instances.

Ahh you’re right, there are some that just initiate a connection via something like Session Manager, but those connections where AWS initiates the connection for you are logged in CloudTrail, even without data events, and root doesn’t give you any ability to directly SSH into an instance outside of those methods (you cannot, for example, use root to find out what the private keys are for logging into an instance) so we’re back to the fact that any such access would be auditable.

Re: Rubygems.org AWS Root Access Event – September 2025

#118

Post by zrail »

0cf8612b2e1e wrote: post #85
frenchtoast8 wrote: post #70

Earlier quoted context omitted.

I believe this is a scenario where AWS recommends multiple accounts. 1. Create another "management" AWS account, and make your other AWS account a child to that. 2. Ensure no one ever logs in to the "management" account, as there shouldn't be any business purpose in doing so. For example, you should require a hardware key to log in. 3. Configure the "management" account to force children account to enable AWS Config,…

2) Surely, someone needs access to the account. How do you prevent those with access from using it? Security feels like turtles all the way down where you ultimately have to trust a few people to do the right thing.

The only reason someone would need access to the management account would be maintaining child accounts and IAM roles or reviewing logs, none of which should need root.

Re: Rubygems.org AWS Root Access Event – September 2025

#120

Post by SAI_Peregrinus »

yargzeblog wrote: post #41
ctoth wrote: post #38

AWS account root access on a language package registry for 11 days. Not EC2 root - AWS account root. Complete control over IAM, S3, CloudTrail, every-damn-thing. They're claiming "no evidence of compromise" based on CloudTrail logs that AWS root could have deleted or modified. They even admit they "Enabled AWS CloudTrail" after regaining control - meaning CloudTrail wasn't running during the compromise window. You ca…

IMO the only way to avoid doing a total rebuild is to have Andre Arko: 1. Admit that he was the unauthorized actor (which means he's probably admitting to a crime?) 2. Have him attest he didn't exfil or modify the integrity of service while committing a crime. If I was Ruby Central I would give clemency on #1 in exchange for #2 and I think #2 helps Andre Arko.

Ruby Central isn't capable of giving clemency. They could refuse to testify in any prosecution, but they don't get to pick whether a relevant attorney general or district attorney decides to prosecute.
Post reply on HN