Il codice generato dall'IA ha spedito i controlli ma ha saltato il controllo

      Un test di penetrazione presso una società di servizi finanziari che gestisce miliardi di dollari in asset dei clienti ha trovato un difetto critico nel codice generato dall'IA. La parte interessante è ciò che il codice ha fatto bene.

      Sygnia, la società di risposta agli incidenti, ha valutato un'applicazione di onboarding dei clienti costruita sostanzialmente con Claude. Gestiva identificazioni rilasciate dal governo, dati di verifica dell'identità, dettagli di pagamento e numeri di previdenza sociale.

      Il difetto ha permesso a un richiedente di accedere al record di un altro richiedente.

      Cosa si è rotto realmente

      L'applicazione ha risolto un problema reale. Le persone iniziano un'applicazione, se ne vanno e tornano prima di avere un account, quindi il sistema deve ripristinare i loro progressi senza una password.

      Claude ha prodotto un modello di accesso temporaneo per questo. Il difetto risiedeva nel modo in cui il modello decideva chi meritava un token.

      Il 💜 della tecnologia dell'UE

      Le ultime novità dalla scena tecnologica dell'UE, una storia dal nostro saggio fondatore Boris e alcune opere d'arte AI discutibili. È gratuito, ogni settimana, nella tua casella di posta. Iscriviti ora!

      Il possesso di un identificatore globale unico di un richiedente, o GUID, contava come prova sufficiente per emettere o ripristinare un token di accesso per quel richiedente.

      “In effetti, il GUID è diventato un segreto portatore,” ha scritto Sygnia nella sua ricerca.

      Un GUID identifica un record. Non prova che chiunque lo detenga controlli la sessione, il dispositivo, l'identità o il canale di contatto verificato ad esso associato.

      Chiunque avesse il GUID di un altro richiedente poteva accedere a nomi, dettagli di contatto, stato dell'applicazione, dettagli finanziari, dati di verifica dell'identità, informazioni di pagamento, numeri di previdenza sociale e record di co-richiedenti.

      I co-richiedenti meritano una pausa. Queste sono persone i cui dati erano nel sistema perché qualcun altro li ha nominati.

      I controlli c'erano tutti

      Ecco cosa rende insolita la scoperta, e non è la storia che la maggior parte dei fallimenti di codifica AI racconta.

      L'implementazione non mancava di sicurezza. Sygnia descrive un piano che copre token temporanei, scadenze, limitazione della velocità, registrazione delle audit, ripristino delle sessioni e rilevamento di attività sospette.

      Ognuno di questi è un vero controllo. Nessuno di essi risponde alla domanda a cui il sistema aveva realmente bisogno di rispondere.

      “Cosa deve essere dimostrato prima che il backend emetta o ripristini un token di accesso per un richiedente?” chiedono i ricercatori.

      La vulnerabilità esisteva prima dell'emissione, nel momento in cui il sistema decideva se il richiedente meritasse un token.

      “Il problema non era che il sistema mancasse di controlli di sicurezza,” ha scritto Sygnia. “Il problema era che i controlli erano avvolti attorno alla decisione di fiducia sbagliata.”

      Un token a vita breve causa comunque danni quando raggiunge la persona sbagliata. I registri di audit aiutano un'indagine successiva e non prevengono nulla.

      Perché gli scanner lo perdono

      Gli strumenti di test di sicurezza delle applicazioni statiche cercano schemi di codifica insicuri e flussi di dati non sicuri. Questo non era né l'uno né l'altro.

      Il difetto era architettonico. Viveva all'interno di un'assunzione sulla fiducia, scritta in codice che seguiva convenzioni di framework familiari e superava controlli di base.

      “Il codice funzionante non è lo stesso del codice sicuro,” ha detto Zach Mead, il tester di penetrazione di Sygnia che ha condotto la valutazione.

      “Il codice generato dall'IA può compilare, seguire convenzioni familiari e superare controlli di base, pur facendo assunzioni errate sui confini di fiducia, autorizzazione, stato, proprietà o integrazioni di terze parti,” ha detto.

      La sua istruzione ai team di sicurezza è diretta. Trattare l'output generato dall'IA come non attendibile fino a convalida.

      Un LLM ha trovato ciò che un LLM ha costruito

      Sygnia non ha catturato questo a mano. Ha eseguito un modello linguistico su porzioni del codice del cliente, cercando problemi di confine di fiducia e difetti nella logica aziendale.

      Il modello ha messo in evidenza direttamente il problema del token del richiedente.

      Il riassunto di Sygnia su questo è la linea più netta nella ricerca. Un difetto di architettura di sicurezza codificato in vibrazioni è stato identificato attraverso una revisione del codice codificata in vibrazioni.

      Taglia in entrambe le direzioni, e la società lo afferma. Se un difensore può chiedere a un modello dove mancano i confini di fiducia, così può chiunque detenga codice sorgente trapelato o note di implementazione rubate.

      Cisco ha puntato modelli a peso aperto sulla caccia ai bug per lo stesso motivo. Una capacità, due usi.

      Il problema del ritmo

      Questa ricerca si affianca a un secondo caso di Sygnia, e la combinazione porta l'argomento.

      In un'intrusione nel cloud che la società ha investigato, il primo segnale non era un exploit. Era il ritmo.

      La scoperta delle credenziali, l'enumerazione del cloud, la revisione del codice sorgente, il probing CI/CD, l'accesso al database e la disruption operativa sono avvenuti tutti contemporaneamente. Somigliava a diversi operatori piuttosto che a uno solo.

      Era una persona, che lavorava con agenti.

      Metti insieme i casi e la forma è chiara. L'IA sta accelerando il modo in cui viene scritto il codice, come vengono trovati i difetti e quanto velocemente una debolezza diventa un percorso di attacco. Abbiamo già tracciato quattro attacchi separati che condividono un unico difetto sottostante.

      Cosa dice Sygnia ai clienti di fare

      Non vietare gli strumenti. I divieti spingono l'uso in account personali, dove nessuno può vederlo.

      La società suggerisce di contrassegnare le richieste di pull che l'IA ha generato o modificato sostanzialmente, nominando lo strumento e segnalando il lavoro che tocca autenticazione, pagamenti, esportazioni di dati o informazioni sui clienti regolamentati.

      Il consiglio più concreto riguarda i prompt. Chiedere “token di accesso temporanei per i richiedenti” è un'istruzione incompleta.

      Un prompt più sicuro afferma che gli identificatori dei richiedenti non devono essere trattati come segreti, che l'emissione di token richiede prova indipendente del controllo del richiedente e che i test negativi devono dimostrare che un richiedente non può ottenere accesso per un altro.

      Il requisito di sicurezza deve essere presente nel prompt, perché il modello non inferirà il modello di rischio di un'istituzione da solo.

      Una avvertenza degna di nota

      Questo è un rapporto di un fornitore su un cliente non nominato, pubblicato insieme a un nuovo servizio commerciale.

      Sygnia ha lanciato i Servizi di Cybersecurity AI lo stesso giorno, coprendo la valutazione della postura, la governance e il test di penetrazione delle applicazioni AI. Nessuno può verificare indipendentemente i risultati, e nessun'altra azienda ha riportato questo caso.

      Il meccanismo che descrive è verificabile, però, e riecheggia la nostra precedente copertura dei fallimenti di sicurezza codificati in vibrazioni, delle fughe di sandbox negli agenti di codifica e dell'iniezione di prompt in un'azione GitHub di Claude Code.

      Ciò che separa questo caso è dove si trovava il difetto. Quelli erano vulnerabilità negli strumenti. Questo era codice generato dall'IA che portava il difetto in produzione, in un'azienda regolamentata, attorno a dati che i clienti sono tenuti a consegnare.