Quando l'IA non era l'anello debole: l'esposizione dei dati dei candidati McHire

Cosa è successo

Nel giugno 2025, i ricercatori di sicurezza Ian Carroll e Sam Curry hanno rivelato una catena di vulnerabilità in McHire, la piattaforma di assunzione di McDonald's costruita da Paradox.ai e utilizzata dalla stragrande maggioranza dei franchising McDonald's. I rapporti pubblici di Wired e BleepingComputer stimano che il set di dati esposto sia di circa 64 milioni di candidati, con nomi, indirizzi email, numeri di telefono e trascrizioni di chat accessibili a chiunque abbia seguito lo stesso percorso dei ricercatori.

Il titolo che si è diffuso più velocemente ha inquadrato questo come un attacco di prompt injection al chatbot "Olivia". Questa inquadratura è sbagliata. I ricercatori affermano di aver provato prima il prompt injection, e ha fallito: il bot era strettamente limitato a risposte predefinite e non aveva mai dati di backend che potessero essere indotti a divulgare. Il compromesso non aveva nulla a che fare con il modello linguistico.

Il punto di ingresso effettivo era una pagina di login amministrativa di Paradox.ai su McHire, raggiungibile da internet pubblico. I ricercatori hanno provato le credenziali "123456" / "123456" su un account di test che, secondo i rapporti pubblici, era rimasto attivo dal 2019. Sono entrati.

Una volta dentro, un classico Insecure Direct Object Reference (IDOR) sull'API dei candidati ha permesso loro di incrementare un ID numerico e recuperare il record di qualsiasi candidato. Nessuna sfruttamento del modello, nessuna tecnica nuova, nessun zero-day. Credenziali predefinite più un riferimento a oggetti non autenticato.

Perché questo schema continua a ripetersi

Il fallimento interessante qui non è tecnico, è organizzativo. Il chatbot era il componente visibile, "AI", quindi ha assorbito l'attenzione sulla sicurezza. La noiosa amministrazione web dietro di esso era il raggio d'azione effettivo, e quasi nessuno la vedeva in quel modo.

Questo accade ogni volta che un acquirente tratta un fornitore di AI come un prodotto AI piuttosto che come un'applicazione SaaS che per caso contiene un modello. Il modello riceve una revisione red-team. La console di amministrazione, l'API dei candidati, il bucket di archiviazione, la registrazione degli audit, la politica di rotazione delle credenziali — le cose che hanno decenni di modalità di fallimento note — vengono trattate come semplici tubature.

La struttura degli incentivi dei fornitori lo rafforza. I fornitori di AI spediscono velocemente, spesso prima di avere un programma di sicurezza maturo, e i team di acquisto dei loro clienti chiedono informazioni sul comportamento del modello piuttosto che sull'applicazione circostante. Un account di test del 2019 con la password "123456" sopravvive a questa lacuna per anni perché nessuno ha limitato la revisione per trovarlo.

Le violazioni AI più costose dei prossimi due anni non saranno exploit di modelli. Saranno vulnerabilità web dell'era degli anni '90 nell'applicazione che avvolge il modello.

Il playbook dell'attaccante passo dopo passo

La sequenza divulgata era breve, e questa è la parte scomoda. Un attaccante esperto non aveva bisogno di una catena di primitive nuove.

Passo 1: enumerare la superficie del fornitore AI

Identificare il fornitore di terze parti dietro il chatbot visibile. In questo caso il bot si è identificato come costruito da Paradox.ai, il che ha indicato una superficie amministrativa separata — una pagina di login sullo stesso dominio McHire.

Passo 2: provare le credenziali ovvie

Le credenziali predefinite e deboli rimangono l'attacco più redditizio contro i pannelli di amministrazione dei fornitori. I rapporti indicano che un singolo account di test con "123456" / "123456" è stato sufficiente.

Passo 3: passare dall'amministratore ai dati

Il ruolo di amministratore ha esposto un'API interna per i candidati. L'API utilizzava un identificatore numerico sequenziale e non controllava che l'account chiamante fosse autorizzato a leggere ogni specifico candidato. L'iterazione dell'ID restituiva record arbitrari.

Passo 4: confermare l'ambito e divulgare

I ricercatori si sono fermati alla prova d'impatto, hanno convalidato la dimensione del set di dati e hanno segnalato a Paradox.ai e McDonald's. Paradox.ai ha disabilitato l'account di test e, secondo quanto riferito, ha risolto l'IDOR entro poche ore dalla divulgazione.

Cosa hanno perso i difensori

Tre cose, in ordine di gravità decrescente.

Primo, nessuna igiene delle credenziali sulla superficie amministrativa del fornitore. Un account di test che precedeva la distribuzione in produzione, con una password numerica di sei caratteri, era raggiungibile da internet pubblico cinque anni dopo la sua creazione. Qualsiasi audit periodico delle credenziali lo avrebbe trovato.

Secondo, nessun controllo di autorizzazione sull'API dei candidati. IDOR è una delle vulnerabilità web più antiche e ben documentate nel catalogo OWASP. Il fatto che una chiamata amministrativa autenticata restituisse record di candidati arbitrari significa che l'API applicava l'autenticazione ma non l'autorizzazione.

Terzo, nessuna revisione di sicurezza della superficie "noiosa". Il chatbot ha ricevuto attenzione perché era l'AI. Il login amministrativo, il gateway API e l'archiviazione di 64 milioni di record PII non hanno ricevuto lo stesso controllo — presso McDonald's, presso Paradox.ai o presso i franchising che hanno implementato McHire.

Una checklist difensiva pratica

Le soluzioni sono poco affascinanti. Sono anche ciò che avrebbe prevenuto questo incidente.

• Inventariare ogni superficie di autenticazione esposta da qualsiasi fornitore di AI che utilizzi, inclusi pannelli di amministrazione, ambienti di test e strumenti di supporto clienti. Trattali come applicazioni web gioiello, non come semplici tubature per il modello.
• Richiedere ai fornitori di attestare, per iscritto, che non esistono credenziali predefinite o condivise in produzione e che gli account di test creati durante l'onboarding vengano eliminati al momento del go-live.
• Eseguire test IDOR/BOLA autenticati contro ogni API esposta dal fornitore, specialmente le API che restituiscono record per utente. L'OWASP API Security Top 10 classifica questo al primo posto per una buona ragione.
• Forzare l'SSO con il tuo provider di identità per ogni superficie amministrativa del fornitore, in modo che le credenziali non possano divergere indipendentemente e i vecchi account muoiano quando i dipendenti se ne vanno.
• Limitare i privilegi delle sessioni amministrative in modo che un singolo account amministrativo compromesso non possa enumerare l'intero set di dati dei candidati o dei clienti.
• Richiedere al fornitore di registrare e avvisare su schemi di lettura massiva contro API sensibili. Il recupero di decine di milioni di record di candidati non dovrebbe apparire come un giorno normale.

Come i moderni test offensivi avrebbero colto questo

Un'attività offensiva mirata e autorizzata contro la superficie del fornitore McHire — non contro il chatbot — avrebbe trovato questo nel primo pomeriggio. I controlli pertinenti sono ben noti: credential-spray contro il login amministrativo, controllo di accesso orizzontale autenticato su ogni API parametrizzata e revisione degli account di test e dei flussi di lavoro di reset.

Il modello stesso non ha bisogno di un red team in questa storia. Il modello si è comportato correttamente. Le protezioni del chatbot hanno retto. La lezione è che una revisione approfondita della sicurezza dell'applicazione del prodotto circostante avrebbe segnalato ogni passo della kill chain prima che fosse mai attivo.

Cosa guardare dopo

Aspettatevi di più. I fornitori di AI stanno assorbendo flussi di lavoro più sensibili — assunzioni, reclami, servizio clienti, pianificazione — e le console amministrative di backend attorno a questi flussi di lavoro ora contengono concentrazioni di dati personali regolamentati che in precedenza si trovavano in sistemi meno raggiungibili.

Due cose da osservare nel tuo programma: quali fornitori di AI detengono la più alta concentrazione di dati personali regolamentati per tuo conto, e come appare il tuo diritto contrattuale di testare la loro superficie amministrativa. Se non puoi eseguire una revisione della sicurezza dell'applicazione autenticata contro il pannello del fornitore, ti fidi che il prossimo account di test sia stato eliminato, la prossima API applichi l'autorizzazione e la prossima password predefinita sia stata ruotata. La divulgazione di McHire mostra cosa succede quando questa fiducia è malriposta.