Railway, piattaforma cloud usata dagli sviluppatori per pubblicare applicazioni, ha diffuso il 10 novembre il report completo sull’attacco a Railway subito tra il 20 e il 21 ottobre. Un aggressore ha concatenato più falle nell’infrastruttura, ha ottenuto il codice sorgente interno e ha decifrato parte delle variabili d’ambiente dei clienti: al massimo l’1,85% dei workspace, circa 100.000, secondo l’azienda. L’obiettivo principale, conclude l’indagine, erano le chiavi di accesso ai fornitori di intelligenza artificiale.
Come si è svolto l’attacco a Railway
Secondo la ricostruzione dell’azienda, l’attaccante ha sfruttato una vulnerabilità fino ad allora sconosciuta nel sistema di build, che allora eseguiva più build sulla stessa macchina virtuale, per uscire parzialmente dall’isolamento e leggere alcuni file del server. Così ha ottenuto una credenziale interna pensata solo per completare le build. Il servizio interno che gestisce le build, basato su Temporal, la accettava però come client fidato: l’aggressore ha potuto leggere la cronologia di 353 build, con le relative variabili, e scaricare una copia del monorepo aziendale.
Con il codice in mano ha cercato nuove strade e ne ha trovata una in una configurazione OIDC errata in un ambiente cloud. Da lì ha recuperato credenziali interne, si è collegato via SSH a una macchina di orchestrazione e ha usato una credenziale di lunga durata per interrogare il database delle variabili cifrate e decifrarne una parte tramite il servizio di gestione delle chiavi. Railway lo ha espulso definitivamente il 21 ottobre alle 9:24 UTC (le 11:24 ora italiana). Le prime registrazioni di account fittizi risalgono già al 18 ottobre.
Cosa è stato esposto
I log mostrano che l’aggressore cercava soprattutto variabili con i nomi delle chiavi dei provider di AI, privilegiando i clienti con molte variabili; una query riguardava anche credenziali di servizi cloud, database e pagamenti, ma secondo Railway non ci sono indizi di accessi ai database dei clienti. La cifra di 100.000 workspace è un tetto massimo, perché i log identificano gli ambienti e non le singole variabili. Sono stati decifrati anche token collegati agli account di 1.852 utenti, tra cui token OAuth di GitHub e chiavi di agenti AI: l’azienda li ha reimpostati e ha avvisato gli interessati.
L’uso illecito delle chiavi rubate è stimato in circa 740.000 dollari. Railway lavora con i fornitori per i rimborsi e ha dichiarato che coprirà con fondi propri gli addebiti che non verranno rimborsati. L’azienda ritiene che le credenziali siano state rivendute a servizi che rivendono l’accesso ai modelli e inserisce l’episodio in una serie di attacchi contro piattaforme che custodiscono chiavi AI, citando casi analoghi dichiarati da OpenCode, Warp e Fireworks AI. Sul tema avevamo già raccontato il data breach di WorkOS con un framework IA autonomo e quello di Chainalysis, colpita con tecniche agentiche.
Le contromisure annunciate
Durante l’incidente Railway ha sospeso due volte le build, ha chiesto a GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Google, Stripe e altri fornitori di revocare le chiavi potenzialmente esposte, ha ruotato le credenziali interne creando una nuova infrastruttura di certificati e ha invalidato tutte le sessioni e i token degli utenti. Le build sono state ripristinate per tutti i piani entro la sera del 22 ottobre su una nuova infrastruttura che isola ogni build in una macchina virtuale dedicata. Le applicazioni già in esecuzione, precisa l’azienda, non hanno subito interruzioni.
Cosa devono fare sviluppatori e aziende
- Chi usa Railway dovrebbe ruotare tutte le variabili d’ambiente, comprese chiavi API e credenziali dei registri privati, come raccomandato dall’azienda, e controllare i log dei servizi collegati.
- Verificare sulle console dei provider di AI eventuali consumi anomali e impostare limiti di spesa e avvisi.
- Usare chiavi diverse per ogni ambiente e progetto, con i permessi minimi necessari, così da limitare i danni in caso di furto.
- Rivedere le configurazioni OIDC e le relazioni di fiducia della propria pipeline CI/CD: nel caso Railway è stato un errore di configurazione ad aprire la seconda via d’accesso.
Fonti: Railway, incident report, Railway, security disclosure, BleepingComputer.
