Le chiavi di accesso ai servizi di intelligenza artificiale rubate a Railway hanno generato una spesa non autorizzata stimata in 740.000 dollari, secondo l'indagine pubblicata dalla piattaforma il 10 novembre. Railway afferma che si farà carico degli addebiti che i fornitori non rimborseranno, anche se le condizioni variano da un servizio all'altro.
L'intrusione ha interessato l'infrastruttura che Railway utilizza per compilare applicazioni e archiviare i segreti dei clienti, come chiavi API e credenziali di database. L'azienda stima che l'aggressore sia riuscito a decrittare le variabili d'ambiente di un massimo dell'1,85 % degli spazi di lavoro: circa 100.000. Questa cifra è un limite massimo, non il numero di clienti per i quali è stato confermato il furto di informazioni.
L'attacco è iniziato il 20 ottobre e l'intruso è stato espulso dai sistemi di Railway il giorno 21, secondo il rapporto aggiornato. L'azienda non ha stabilito chi gestisse l'aggressore né come abbia calcolato la spesa totale di 740.000 dollari. Sostiene tuttavia che le ricerche dell'intruso fossero mirate specificamente alle credenziali dei fornitori di IA e che il consumo fraudolento comprendesse attività che andavano dalle richieste degli agenti di programmazione a compiti legati all'addestramento di modelli.
Da una macchina di compilazione alle chiavi dei clienti
Railway ha rilevato attività anomala il 20 ottobre. Il primo accesso, tuttavia, era avvenuto prima: alle 07:28 UTC, l'aggressore ha sfruttato una vulnerabilità fino ad allora sconosciuta nell'infrastruttura di compilazione per evadere parzialmente l'isolamento del file system. È riuscito a leggere alcuni file della macchina virtuale host e a ottenere una credenziale utilizzata dai server di compilazione per inviare immagini e accedere a determinati sistemi interni.
La credenziale avrebbe dovuto servire a completare le attività di compilazione, ma il cluster interno di Temporal — il sistema che Railway utilizzava per organizzare parte di questi processi — l'ha accettata come credenziale di un client fidato. Tramite le sue API, l'intruso ha consultato una parte delle cronologie salvate di altri processi, che potevano contenere variabili e segreti forniti durante la compilazione.
Il rapporto di Railway registra la lettura di 353 cronologie di compilazione tra le 13:50 e le 15:30 UTC del 20 ottobre. Indica inoltre che l'aggressore è riuscito a ottenere una copia del monorepository interno dell'azienda: la base di codice comune utilizzata per distribuire molti dei suoi servizi. I registri non mostrano che abbia scaricato repository dei clienti.
Con il codice di Railway, l'aggressore ha cercato altre vie di accesso. Ha individuato una configurazione errata in un collegamento OIDC di uno degli ambienti cloud dell'azienda e, alle 03:26 UTC del 21 ottobre, l'ha sfruttata per ottenere una credenziale temporanea per quell'ambiente. In seguito ha ottenuto altre due credenziali interne: una consentiva di leggere le variabili cifrate in un database se utilizzata dalla rete interna; l'altra era una chiave SSH.
La chiave SSH ha consentito l'accesso a una macchina che eseguiva attività di orchestrazione per la flotta di Railway. Al suo interno si trovava una credenziale di durata maggiore, in grado di decrittare le variabili dei clienti e necessaria per avviare i loro carichi di lavoro. Tra le 04:07 e le 05:21 UTC, l'aggressore ha estratto dal database variabili cifrate; tra le 04:42 e le 05:14, e poi di nuovo tra le 06:36 e le 07:15, ne ha decrittate alcune tramite il servizio di gestione delle chiavi.
I registri del database mostrano che le query selezionavano variabili i cui nomi corrispondevano a espressioni fornite dall'aggressore. Railway afferma che queste ricerche davano priorità alle chiavi dei fornitori di IA e ai clienti con molte variabili archiviate. Ci sono state anche query corrispondenti a credenziali di servizi cloud, database e pagamenti, ma l'indagine non ha trovato prove di accesso ai database dei clienti.
Il rapporto preliminare, pubblicato il 22 ottobre, collocava la decrittazione dopo le 05:27 UTC. L'indagine successiva ha corretto la sequenza: Railway ha stabilito che era iniziata alle 04:42. Ha inoltre precisato che l'aggressore aveva cominciato a creare account di prova il 18 ottobre, anche se i primi tentativi non erano andati a buon fine.
Chiavi IA e token di 1.852 utenti
Railway stima che le variabili potenzialmente decrittate appartenessero a un massimo dell'1,85 % degli spazi di lavoro, circa 100.000. La cifra si basa sugli ambienti presenti nei suoi registri, non su variabili specifiche: per questo l'azienda la presenta come un possibile limite massimo. Sulla base delle proprie analisi forensi, ha inviato email ai clienti che riteneva maggiormente a rischio.
Tra i dati decrittati c'erano anche token di account collegati appartenenti a 1.852 utenti, inclusi token OAuth di GitHub e chiavi di agenti BYOK. Railway afferma di aver reimpostato tutti questi token e di aver avvisato ciascun utente. Non ha rilevato accessi ad account Railway effettuati con credenziali sottratte durante l'incidente.
L'azienda ha disattivato la credenziale che consentiva di decrittare le variabili. Secondo Railway, i dati che l'intruso potrebbe aver copiato in formato cifrato, senza decrittarli, non sono più recuperabili con quella credenziale. Inoltre, ha chiesto a diversi fornitori di revocare le chiavi potenzialmente esposte prima di poter determinare quali fossero state interessate. Per precauzione, ha condiviso con alcuni fornitori tutte le chiavi dei loro servizi che aveva archiviato, una misura che ha generato richieste di reimpostazione per oltre 100.000 utenti. Ricevere un avviso di revoca, quindi, non dimostra di per sé che una determinata chiave fosse esposta.
Railway ritiene che le credenziali rubate siano state destinate a servizi che rivendono o distribuiscono l'accesso ai modelli per utilizzarli nella distillazione. Gli esempi di uso fraudolento ricevuti dai clienti includono richieste di agenti di programmazione, valutazioni del comportamento degli agenti e verifiche di attività di addestramento e dei relativi sistemi di valutazione. L'azienda non ha scoperto se l'aggressore originale gestisse questi servizi o avesse ceduto le chiavi a terzi.
“This was not a single breach followed by a single fix. The attacker probed many potential routes, in parallel, with Railway similarly hardening the routes in parallel.”
— Railway
Railway descrive la risposta come una competizione sulla velocità degli agenti e, citando Wiz, afferma che l'aggressore ha utilizzato modelli di IA modificati per rimuoverne le restrizioni e un ambiente di esecuzione simile ad ARTEX. Non ha pubblicato indicatori di compromissione: ha dichiarato di condividerli privatamente e di prevedere di renderli pubblici quando le autorità lo consentiranno.
L'azienda inquadra l'incidente in una serie di attacchi contro piattaforme di sviluppo che archiviano chiavi IA. Nella sua analisi di “Black October”, Wiz ha elencato gli incidenti divulgati nel corso di ottobre da almeno nove piattaforme di sviluppo IA. BleepingComputer ha citato anche attacchi contro Northflank, OpenCode, Warp e Lightning AI. Railway ha collegato il proprio incidente ai casi segnalati tra il 6 e il 23 ottobre, ma ha precisato che non esiste una vulnerabilità o una dipendenza software comune che colleghi gli attacchi.
Chi gestisce le richieste di rimborso
Il costo finale per ciascun cliente dipende dal fornitore che ha elaborato il consumo. AWS Bedrock e Google Gemini applicano politiche di rimborso per frode e, secondo Railway, i loro team avevano già iniziato a elaborare i rimborsi. OpenAI e SpaceXSI esaminano le richieste caso per caso. Per OpenAI, il cliente deve presentare una richiesta e poi inviare il relativo numero di pratica al team di supporto di Railway; le richieste relative a SpaceXSI vanno presentate allo stesso team.
Quando Railway ha pubblicato il rapporto, le trattative con Anthropic erano ancora in corso; la piattaforma ha quindi dichiarato che nel frattempo avrebbe coperto gli addebiti relativi alle chiavi Anthropic interessate. OpenRouter mantiene nelle proprie condizioni una politica di non rimborso; Railway si è impegnata a sostenere tutti i costi di OpenRouter legati all'intrusione. L'azienda chiede agli utenti di segnalare gli addebiti non riconosciuti tramite il proprio modulo di reclamo e afferma di poter inoltrare le richieste ai fornitori.
L'impegno a coprire gli importi respinti dai fornitori contrasta con il messaggio iniziale inviato da Railway il 26 ottobre: allora aveva dichiarato di non poter rimborsare direttamente le spese effettuate con chiavi compromesse e aveva chiesto ai clienti di contattare prima i fornitori. L'azienda non ha pubblicato un limite per la copertura né una scadenza per presentare le richieste. Inoltre, non ha specificato se i clienti debbano pagare gli addebiti contestati mentre viene esaminato ciascun caso.
La cifra di 740.000 dollari è presentata come una stima dell'uso non autorizzato. Nel rapporto, Railway non ha spiegato quale metodo abbia utilizzato per calcolarla né quale periodo comprenda. La cifra si riferisce al consumo addebitato alle chiavi rubate, non a un importo di cui sia stato confermato il rimborso.
Compilazioni sospese e sistemi rafforzati
L'intrusione non ha spento le applicazioni già in funzione, ma Railway ha sospeso le nuove compilazioni in due occasioni: alle 17:03 UTC del 20 ottobre e alle 07:22 UTC del giorno successivo. L'interruzione ha interessato le nuove compilazioni e distribuzioni; durante la risposta si sono verificati anche periodi di indisponibilità del pannello, dell'API, dell'interfaccia a riga di comando e degli strumenti di supporto.
Railway ha disattivato le credenziali e le sessioni interne e ha ripristinato le compilazioni per tutti i piani il 22 ottobre alle 22:49 UTC, dopo aver rafforzato l'infrastruttura. L'azienda ha dichiarato di aver espulso completamente l'aggressore il 21 ottobre alle 09:24 UTC; il rapporto indica che dalle 09:25 non aveva più accesso ai dati dei clienti. Questi orari descrivono momenti distinti della risposta: l'espulsione e la successiva verifica dell'assenza di ulteriori accessi.
La piattaforma ha modificato anche il proprio sistema di compilazione. In precedenza, più compilazioni potevano essere eseguite in isolamento tra loro sulla stessa macchina virtuale. Il nuovo progetto assegna a ogni compilazione una macchina virtuale di breve durata, oltre a mantenere l'isolamento esistente, e limita la credenziale di ciascun processo al caricamento di un'immagine specifica. Railway afferma che il proprio team di hardening è riuscito a creare un secondo exploit modificando l'attacco originale meno di un'ora dopo l'applicazione della patch. Questo test ha accelerato la migrazione di tutti gli utenti al nuovo sistema.
Railway assicura di aver chiuso tutte le vulnerabilità sfruttate, ruotato le credenziali e ricostruito gli strumenti interni a partire da codice convalidato. Ha inoltre presentato una denuncia all'IC3 dell'FBI e collabora con una società specializzata in analisi forense; l'indagine è ancora in corso. L'azienda prevede di pubblicare gli indicatori di compromissione quando le forze dell'ordine lo autorizzeranno.
Railway consiglia ai clienti di revocare e sostituire le variabili sensibili archiviate prima del 21 ottobre. La procedura relativa agli addebiti non invalida una chiave: questa deve essere revocata o ruotata direttamente presso il fornitore che l'ha emessa. L'azienda consiglia inoltre di rimuovere l'accesso pubblico ai database e di esaminare i registri di audit di GitHub e dei registri di container, come Docker Hub.
Fonti: The Hacker News, BleepingComputer, Railway Blog, Railway Blog, TechCrunch, iTnews
