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

161–170 of 179 posts

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

#161

Post by baobun »

colonwqbang wrote: post #90
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.

Or more realistically, accessed the accounts via IAM token and/or service account.

Something they also failed to consider, reading between the lines.

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

#162

Post by [deleted] »

dragonwriter wrote: post #155
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…

> Having AWS root account access doesn’t give you any ability to SSH to or otherwise access running instances. It does if access credentials to those instances are stored in any AWS service in the account (such as in Secrets Manager).

[deleted]

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

#163

Post by florkbork »

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.

I hate to ask; but

- Account created 14 hours ago.

- Posts article crammed full of accusations

- Has a strong well formed opinion about "it's a crime", but didn't? read the content where the subject of the accusations has.... Already disclosed they had access in both private and public.

My account is also very new, because I have opted to discard my previous ones. I have used it to comment predominantly on this topic, as I sympathise with the maintainers.

So in the interests of making a similar disclosure is there any chance you are affiliated with RubyCentral through a business relationship with them, their legal counsel, a marketing or PR agency or anything of that nature?

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

#164

Post by neverrroot »

fareesh wrote: post #153

I've read both sides of the story and it does not make sense why he would change the root password and not communicate this with RubyCentral or make any attempt to contact them about the change. That in itself suggests malice.

This, cutting through the noise, this is it.

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

#165

Post by sylens »

ctoth wrote: post #82
placardloop wrote: post #75

Earlier quoted context omitted.

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…

Even without data events, there are clues you could infer from management events that somebody is going through buckets. ListBuckets and GetBucketLocation are management events and are seen often by someone enumerating buckets to exfil data from. The fact that this actor was someone very familiar with the account might make this a moot point though as they would know exactly which bucket to go to and what region its in.

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

#166

Post by LamaOfRuin »

tptacek wrote: post #128
LamaOfRuin wrote: post #51

Earlier quoted context omitted.

If Andre doing that was criminal, it seems quite possible that their original takeover of the github organization was also criminal? I have been waiting to hear if there would be any civil action on it since it's not at all clear they had any rights to do most of what they did.

No, that's not at all clear. Ruby Central owns the AWS account for which Arko is (pretty clearly) being accused of changing the AWS root account password after having his access revoked. I don't think for a second Arko will be charged, but there isn't a "nuh-uh, you did this gross thing in our open source community" defense for 18 USC 1030.

I didn't say it was clear, and I never said there was a defense. I implied that the wronged party in one case might want to be careful about raising the specter of liability or criminality.

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

#167

Post by tptacek »

JoshTriplett wrote: post #160
JoshTriplett wrote: post #107

Earlier quoted context omitted.

The other other subtext is that this sure is an effective distraction from their governance problems, and muddies the waters. Given the utter lack of trust I have for anything the Ruby Central folks say at this point, given the amount of spin and misinformation they've spread already, my default assumption is that this is an excuse to malign someone who may well have had legitimate access, in the process of claiming…

Update: https://andre.arko.net/2025/10/09/the-rubygems-security-inci... is pretty much exactly the kind of thing I expected here. Person with legitimate access doing their job, organization flailing around in the process of kicking people out that should never have been kicked out in the first place.

He changed the AWS root account password; RC implies they had to go through a reset flow to recover the account. This apparently went on for more than a week. I don't know how to reconcile what Arko is claiming with what RC is claiming.

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

#168

Post by [deleted] »

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…

[deleted]

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

#169

Post by jeffwask »

colonwqbang wrote: post #90
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.

No matter how you slice it this is miserable root password security. Why do maintainers need root access? No one in my org has root access but me and all those creds are tied to hardware MFA locked in my MDF.
Post reply on HN