Railway Preliminary Report: Oct 21st Security Incident

3 points by insom


insom

Did customer applications go down? No - running services stayed online throughout the incident. New builds and deployments were paused during triage to mitigate possible attack vectors. The first system we brought online was the ability to disable existing deployments.

I think this is pretty disingenuous!

Applications stayed up (compromised) or people rotated keys (in which case the applications broke). It doesn't seem like "up, but compromised" is something to boast about.

martinald

So it appears that the attacker had access to railway systems for at least 36 hours. Even worse they reenabled the platform after thinking they had the all clear, and didn't communicate this for a long, long time (seems pretty bad to me to reenabled builds and not say you've had a security incident on the first problem?).

Even worse they don't know how many secrets were accessed because of insufficient logging, AND it appears all secrets were decrypted with what looks like secret(s) in their CI environment (which would say to me there was no specific hardware only key - especially given the lack of logging).

Not sure what's worse. The defective secret encryption/logging or the lack of transparency. I believe they only came clean about the attack when people on twitter started complaining their API keys that were only on railway were getting drained.

gerikson

Original disclosure covered here: https://lobste.rs/s/wi4nnl/railway_security_disclosure_wednesday

brad

Early investigations tell us this attack was attempting to obtain AI provider API keys to perform distillation attacks.

Initial evidence leads us to believe that the malicious actor had access to abliterated models and substantial compute resources

I'm not understanding what the implied goal was here. They had liberated models and were trying distill frontier models?