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

81–90 of 179 posts

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

#81

Post by busterarm »

Mystery-Machine wrote: post #73
busterarm wrote: post #27

Props to Ruby Central for taking all of the smears and reputational damage on the chin silently while they mitigated an actual security incident, made absolutely sure and wrote up a proper post-mortem. All of that in line with their original statement that their actions taken were in the interest of security/integrity of their platform. If there's any evidence that you need to know who the proper stewards of Ruby's g…

An entity that promised security had a security incident due of their incompetence to properly secure their production environment root access?

If somebody is going to abuse their accidentally-retained access after being removed from my organization, than the incompetence was in having that person in my organization in the first place. It turns out they were perfectly justified in removing him!

First of all, it's criminal, and second of all, it absolutely lights a torch to any credibility they have. I expect people don't want to become unhireable.

I've had access/credentials to organizations that I've left and never abused them even once.

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

#82

Post by ctoth »

placardloop wrote: post #75
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…

CloudTrail logs for the last 90 days are enabled by default, cannot be turned off, and are immutable, even by root. If you view this “event” as starting when Arko was supposed to have their access terminated, that’s within the 90 day window and you can indeed trust the logs from that period.

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 packages, SSH into build servers - none of it would appear in the logs they reviewed. Correct?

[0] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/l...

[1] https://repost.aws/questions/QUVsPRWwclS0KbWOYXvSla3w/cloud-...

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

#83

Post by coredog64 »

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…

Not going to bother reading the article, but will chime in here that the recommendation from AWS is to have a separate security account within your organization that only holds your CloudTrail logs. This does potentially double your cost, as you only get one CloudTrail for free, and it's very useful to have an in-account trail for debugging purposes.

Organizations are also useful because you can attach SCPs to your accounts that deny broad classes of activities even to the root user.

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

#84

Post by xaxaxa123 »

busterarm wrote: post #79
xaxaxa123 wrote: post #68

Earlier quoted context omitted.

odd timing for such an incident..

Not really. Someone abusing their access after being removed is exactly when such events occur. Your post suggests conspiratorial thinking when there shouldn't be.

my post suggests critical thinking when there should be..your post is just defamatory. all of this looks like a "problem, action, solution" scheme. what was the takeover then, a honest and transparent move by RC? you must be kidding. looked pretty much conspiratorial.

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

#85

Post by 0cf8612b2e1e »

frenchtoast8 wrote: post #70
shevy-java wrote: post #55

Earlier quoted context omitted.

You are actually right, I didn't think of this before. How can they ensure that nobody else did any tampering? It seems RubyCentral did not think this through completely.

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.

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

#86

Post by ameliaquining »

dismalaf wrote: post #20

Lol and in previous posts everyone was acting like Arko is above board... I brought up multiple times that his actions were suspicious, was downvoted. Now proof of that plus an email trying to low-key extort RubyCentral into allowing him to sell user data...

It's not extortion, because refusing his offer would have left them no worse off than if he hadn't gotten involved in the first place. You can still object on other grounds, of course.

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

#87

Post by ctoth »

arianvanp wrote: post #65
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…

You can't enable or disable AWS Cloud Trail as far I know? You can enable the persistent storage of trails. But you can always access 90 days of events regardless of that being enabled

Only management events, see https://news.ycombinator.com/item?id=45532772

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

#89

Post by phoronixrly »

Imustaskforhelp wrote: post #30
phoronixrly wrote: post #14

So we have DHH with his unhinged posts on one side, and Arko wanting to sell PII on the other. Great! I think we need an f-droid-like project for Rubygems that builds the gems from source, and takes care of signing, and is backed by a non-profit that is independent from Rails/Shopify

Yes! Not even sure why you are being downvoted, this is such a great idea actually. F-droid has been so professional and they are just so professional There was this developer (axet) who recently accused f-droid of somehow convincing the users "maliciously" that the funds are going to the the creator and f-droid when in reality it was going to f-droid and he name called them and what not.. Do you know what f-droid te…

> Not even sure why you are being downvoted, this is such a great idea actually.

Expressing negative opinions about DHH is not well-received here.

Oddly enough the Ruby community includes both the most thoughtful and gentle people and the biggest assholes I know... I refuse to believe the latter are not fringe.

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

#90

Post by colonwqbang »

jnewland wrote: post #46

This is a pretty hilarious and long-winded way to say "we have no idea how to lock someone out of a web service:" > 1. While Ruby Central correctly removed access to shared credentials through its enterprise password manager prior to the incident, our staff did not consider the possibility that this credential may have been copied or exfiltrated to other password managers outside of Ruby Central’s visibility or contr…

It didn't occur to them that he might have written the password down? That's wild.
Post reply on HN