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

41–50 of 179 posts

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

#41

Post by yargzeblog »

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.

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

#43

Post by dismalaf »

mikey_p wrote: post #40
terracatta wrote: post #3

That email screenshot is pretty bad for Arko. It clearly shows intent to sell PII data to a third party during a time when Ruby Central had diminished funds and needed help affording basic services. What the fuck.

Why do they need money? What happened to their funding?

It was after a big sponsor pulled out and presumably before Shopify stepped in...

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

#44

Post by ctoth »

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.

So you would expect people to accept that the entire root chain of custody for the Ruby supply chain is attested by ... A guy saying he didn't do anything bad? I have a cool cryptocurrency you might wanna check out that I definitely don't have a backdoor to!

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

#46

Post by jnewland »

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 control.

> 2. Ruby Central failed to rotate the AWS root account credentials (password and MFA) after the departure of personnel with access to the shared vault.

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

#47

Post by akerl_ »

zrail wrote: post #32
nerdjon wrote: post #26

Earlier quoted context omitted.

To me that sounds like security by obscurity not actual security. If you have the ability to go through the reset flow than then why is that much different than the username and password being available to a limited sets of users. That would not have prevented this from happening if the determination was made that all 3 of these users need the ability to possibly get into root. As far as having an IAM user, I fail to…

Resetting the root password requires proving access to the email address associated with the root account. It also leaves a massive papertrail.

By "massive papertrail" do you mean "a pair of emails to the associated address"?

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

#49

Post by ctoth »

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…

Thinking about this a bit more... it sure is interesting that around the time of a competing project launch that something just happens which might reasonably completely compromise trust in the previous incumbent, isn't it? Odd!

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

#50

Post by akerl_ »

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…

Given the context of the post, it seems like "Enabled AWS CloudTrail, GuardDuty, and DataDog alerting" means "enabled alerts via CloudTrail, GuardDuty, and Datadog", not "enabled Cloudtrail logging". Otherwise the comment about reviewing Cloudtrail wouldn't make sense.
Post reply on HN