Ruba il mio Bitcoin: hype sugli exploit PHP vs realtà

Se negli ultimi tempi hai passato un po' di tempo sui social dedicati alla sicurezza, avrai sentito questa affermazione: le nuove vulnerabilità di remote code execution in PHP sono così banali che agenti AI stanno già sfruttando autonomamente server vulnerabili a migliaia. Sciami di agenti. Inarrestabili. Uno sviluppatore si è stancato del rumore e ha fatto qualcosa di deliziosamente diretto. Ha tirato su un server con una versione di PHP precedente alle patch, ha nascosto una chiave Bitcoin del valore di circa cinquecento dollari dove un attaccante, se riuscisse nell'intento, potrebbe raggiungerla, e ha pubblicato un link con un invito in due parole: rubalo. Del resto, un exploit per PHP era presumibilmente qualcosa che un chatbot potesse sputare prima di pranzo. Il timer del sito ha iniziato a contare. Poi è successo qualcosa di interessante: niente.

Sono passate le ore. Le monete sono rimaste lì. La sezione commenti si è riempita di un silenzio molto particolare: quello di decine di persone che per giorni avevano sostenuto che l'exploit fosse un gioco da ragazzi e che all'improvviso avevano scoperto urgenti motivi per non poterlo dimostrare. Qualunque sia il giudizio sull'iniziativa, ha fatto qualcosa di raro nel dibattito sulla sicurezza: ha preso un'affermazione virale e l'ha resa falsificabile.

Un server costruito per essere derubato

La configurazione prende la sua meccanica dalle competizioni capture-the-flag. La chiave privata Bitcoin non si trova in un file della web root o in una variabile d'ambiente: è custodita da un binario print-flag accessibile all'utente di sistema di PHP. Questo significa che un attaccante deve avere un'esecuzione di codice reale sulla macchina, non solo una divulgazione di informazioni o un path traversal. Bisogna ottenere una shell, eseguire il binario, leggere la chiave e svuotare il portafoglio prima che lo faccia qualcun altro. La build di PHP è stata scelta deliberatamente tra quelle precedenti alle recenti patch CVE, e il tutto è stato annunciato con un allegro avviso secondo cui tutto il traffico viene registrato e nulla sulla macchina dovrebbe considerarsi privato.

C'è una chiave bitcoin nascosta su questo server, del valore di circa 502 dollari. È accessibile all'utente di PHP tramite il binario print-flag. Chi per primo ottiene il portafoglio vince.

L'autore ha aggiunto anche un tocco di eleganza: se non hai bisogno dei soldi, valuta di donarli in beneficenza. E il sito mostrava in bella vista un contatore in tempo reale, le ore senza un hack riuscito, che trasformava l'intera pagina in un tabellone punteggi. Ogni ora in più era di per sé un dato. Nel giro di un giorno, il contatore era diventato la metrica di sicurezza più interessante di internet, proprio perché misurava una previsione su cui le persone avevano puntato la reputazione.

Perché una taglia da 500 dollari è una macchina per la falsificabilità

La maggior parte delle affermazioni in ambito sicurezza è, per costruzione, non falsificabile. «Gli attaccanti stanno già sfruttando questa falla», sulla base di telemetria che non puoi vedere. «Qualunque analista junior potrebbe trasformarla in un'arma in un pomeriggio», mai dimostrato. «I nostri agenti hanno trovato exploit funzionanti in autonomia», fidati del video demo. Non c'è modo di provare un negativo, quindi le affermazioni si accumulano. Il panico costa poco perché il panico non deve rendere conto di nulla.

Una taglia pubblica con un timer pubblico cambia i conti. Se migliaia di agenti autonomi stanno davvero scansionando internet e compromettendo ogni macchina PHP non aggiornata che trovano, allora una macchina che pubblicizza esattamente quella vulnerabilità, con un premio in denaro e un permesso esplicito, dovrebbe cadere in pochi minuti. Non ore. Minuti. Gli incentivi sono perfettamente allineati: è legale, è incoraggiato e paga. Quando invece il contatore continuava a salire, un'affermazione specifica, ovvero che lo sfruttamento di massa autonomo fosse già in corso, ha ricevuto un colpo diretto. Come ha scritto un commentatore, la narrazione degli sciami di agenti che compromettono tutto ciò che incontrano evidentemente non stava accadendo, altrimenti le monete sarebbero sparite.

È un trucco che vale la pena rubare per il tuo lavoro. La prossima volta che un vendor o un influencer ti dice che una vulnerabilità viene sfruttata ovunque, chiedi quale osservazione potrebbe dimostrare che sbaglia. Se non ne esiste una, non stai ascoltando un'analisi, ma marketing. La taglia Bitcoin ha funzionato perché ha trasformato le sensazioni in una scommessa, e le scommesse hanno la bella proprietà di poter essere verificate.

Economia degli exploit: perché gli attaccanti veri non giocano

Ecco il controargomento, ed è valido: il silenzio dimostra meno di quanto sembri, perché un exploit funzionante per una CVE appena scoperta vale molto più di 500 dollari, ma solo come segreto. Ogni volta che lanci un exploit contro un bersaglio rischi che venga registrato, sottoposto a reverse engineering e bruciato. Lanciarlo contro un server il cui proprietario ha annunciato in anticipo che tutto il traffico viene registrato e che l'intera internet sta guardando? Non è una taglia, è un falò.

Il thread ha fatto emergere questo ragionamento da entrambi i fronti. Gli attori offensivi hanno obiettivi di valore superiore a un portafoglio da 500 dollari e nessun interesse a consegnare i propri strumenti a chi sta leggendo i log. I ricercatori difensivi che possiedono informazioni riservate sulle vulnerabilità hanno una finestra di patch da proteggere: il CEO di una società di sicurezza ha dichiarato pubblicamente che il suo team aveva un RCE funzionante ma non lo avrebbe dimostrato, proprio perché far circolare i dettagli mentre le persone stavano ancora applicando le patch avrebbe causato danni reali. Entrambi i gruppi hanno fatto lo stesso calcolo: il valore atteso di reclamare le monete è di cinquecento dollari, e il costo atteso è bruciare qualcosa di molto più prezioso. Pessimo affare. Quindi la lettura onesta della taglia non reclamata non è «non esiste nessun exploit». È «nessuno che possiede un exploit considera 500 dollari più importanti della segretezza». Sono conclusioni molto diverse, e solo una di queste era sotto processo.

Il controllo di realtà sugli agenti AI

La parte più divertente del thread è stata guardare le affermazioni sull'AI scontrarsi con un bersaglio reale. Un commentatore ha sottoposto la sfida a cinque modelli di frontiera e ha pubblicato le prove. Due modelli l'hanno interpretata come una sfida pubblica legittima, che effettivamente era, e si sono messi al lavoro. Uno l'ha segnalata come richiesta di cybersecurity e ha reindirizzato l'utente a un programma di verifica. Uno ha rifiutato senza mezzi termini. Uno è stato bloccato da un filtro sui contenuti lato provider prima di poter rispondere. Quindi, su cinque sistemi allo stato dell'arte, due hanno accettato di provarci e, nelle prime fasi, nessuno dei due ha prodotto la flag.

Questo quadro misto conta più di entrambe le posizioni estreme. Il riflesso «l'AI non hackererà mai nulla» è sbagliato: i modelli si sono cimentati, e lo sfruttamento agentico di bersagli in stile CTF con vulnerabilità note sta davvero migliorando. Ma chi sostiene che «gli sciami autonomi stanno svuotando ogni server non aggiornato» fa un'affermazione molto più forte, ed è proprio l'affermazione forte che un honeypot pubblico, con permessi espliciti e premio in denaro, mette alla prova. Nel frattempo, un noto personaggio del mondo pentesting aveva appena dichiarato di aver costruito un PoC generico funzionante con un chatbot in due ore, e poi, in una coincidenza che sono sicuro sia del tutto casuale, è passato a promuovere la sua piattaforma di pentesting basata su AI. Se quell'affermazione avesse retto, la taglia sarebbe sparita prima che il timer raggiungesse un'ora. Non è successo. Abbiamo già visto questo schema: demo e classifiche lusingano capacità che crollano al primo contatto con il lavoro reale, ed è esattamente il divario che abbiamo esplorato in perché i benchmark dell'AI non colgono la maggior parte del lavoro reale.

Il caso per cui l'esperimento era truccato

Prima di incoronare il timer come scienza, c'è un'obiezione tecnica che merita di essere presa sul serio: la configurazione specifica del server potrebbe non essere effettivamente sfruttabile con le CVE in questione. Un commentatore attento l'ha analizzata: la macchina usa il server CLI di PHP invece di una tradizionale configurazione CGI, limita le richieste a 1 MiB, serve una pagina sostanzialmente inerte e consente un limite di memoria elevato. A seconda dei percorsi di codice in cui si trovano le vulnerabilità, questa combinazione può chiudere le primitive di cui un exploit ha bisogno. In altre parole, l'honeypot potrebbe essere inattaccabile non perché i bug siano difficili, ma perché questa particolare macchina non espone la superficie vulnerabile.

Se è vero, l'esperimento resta utile: raccoglie tentativi di proof-of-concept per configurazioni che sono vulnerabili e falsifica l'idea di un exploit banale, universale, che funziona ovunque. Ma non falsificherebbe l'esistenza di un exploit funzionante contro installazioni reali, che in gran parte non assomigliano a una macchina CTF irrobustita. Questa è la lezione generale sui risultati negativi in sicurezza: valgono solo quanto la fedeltà dell'ambiente di test. L'assenza di prove è prova di assenza solo quando stavi guardando nel posto giusto con gli strumenti giusti. Il timer misura la capacità di internet di hackerare questo server, che si rivela una domanda più stretta e più interessante di quella su cui tutti stavano discutendo.

Cosa dovrebbero portarsi a casa davvero i difensori

Nulla di tutto questo è un invito alla compiacenza. La finestra di patch dopo il rilascio di un RCE in PHP è davvero pericolosa: abbiamo scritto di perché staccare la spina ha battuto le soluzioni intelligenti durante la precedente finestra di CVE su PHP, e quel consiglio resta valido. Ciò che cambia la taglia è la calibrazione della tua paura. Applica le patch perché gli RCE esposti su internet sono una minaccia esistenziale, non perché un thread ti ha detto che il cielo sta già cadendo.

• Pretendi la falsificabilità. Quando qualcuno sostiene che lo sfruttamento di massa è in corso, chiedi quali prove lo risolverebbero. Un honeypot pubblico con un timer è grezzo, ma più rigoroso di mille retweet.
• Usa le tue canary. Un commentatore ha raccontato di tenere per anni un portafoglio Bitcoin non cifrato sul proprio computer personale, come trappola. Canary token, credenziali esca e file esca sono sistemi di allerta precoce economici che trasformano la domanda «sono compromesso?» da questione di sensazioni a questione di telemetria.
• Rispetta l'economia. Gli attaccanti esperti accumulano exploit; i commentatori più rumorosi monetizzano la paura. Nessuno dei due gruppi ha incentivi allineati con il tuo bisogno di una valutazione accurata delle minacce, quindi dai più peso alla telemetria primaria che ai commenti.
• Separa le affermazioni. «Esiste un exploit», «lo sfruttamento è in corso» e «gli agenti autonomi stanno sfruttando tutto» sono tre affermazioni diverse con tre soglie di prova diverse. Il panico le fonde in una sola. Non lasciarglielo fare.
• Applica le patch comunque, e in fretta. Un honeypot tranquillo non significa esposizione tranquilla. I tuoi server di produzione non offrono un premio da 500 dollari, il che paradossalmente li rende bersagli più attraenti per chi possiede un exploit funzionante.

La parte migliore dell'intera trovata è che è costata al suo autore quasi nulla e ha prodotto un segnale reale. Un VPS, una build vulnerabile di PHP, un binario con la flag e cinquecento dollari hanno comprato una misurazione di cui tutto il dibattito aveva bisogno. Il divario tra «esiste un exploit» e «l'exploit è ovunque» è il luogo in cui vive il panico, e adesso, in mezzo a quel divario, c'è un timer che conta silenziosamente, sfidando chiunque a colmarlo.