Nellaricerca delle vulnerabilità e dei CVE, si presenta un problema di spazio di ricerca. La superficie di attacco è apparentemente illimitata, tanto che la selezione degli obiettivi è spesso considerata la competenza più importante di un bug bounty hunter.
In questo articolo, racconterò il processo che ho utilizzato per restringere l'ambito della ricerca. Da milioni di righe di codice all'identificazione di tre righe difettose. Mi hanno aiutato, ovviamente, gli agenti LLM più recenti, oltre ad anni di esperienza nella sicurezza delle applicazioni, che mi hanno aiutato a evitare i falsi positivi, un evento comune quando gli agenti sono orientati verso l'hacking a scopo di ricompensa.
Lo spazio di ricerca
Nell'ottobre2025, Wiz ha annunciato un nuovo concorso di hacking denominato Zeroday Cloud in collaborazione con i tre principali cloud , Google Cloud, AWS e Microsoft. Ispirato a competizioni di hacking come Pwn2Own, Zeroday Cloud includeva 20 obiettivi software open source, librerie, applicazioni e toolkit ampiamente utilizzati cloud per creare e potenziare cloud . L'obiettivo della competizione era semplice, anche se non facile da raggiungere: dimostrare l'esecuzione di codice remoto non autenticato (RCE) sul bersaglio.
Stabilire i confini
Daun ampio spazio di ricerca, l'elenco iniziale degli obiettivi è stato definito in soli venti repository. Tralasciando eventuali bypass dell'autenticazione, possiamo restringere ulteriormente i percorsi di codice da prendere in considerazione solo a quelli accessibili da un utente non autenticato. Inoltre, la maggior parte delle regole relative agli obiettivi specifica che gli exploit devono essere distribuiti sulla rete, in genere tramite un server API HTTP locale.
Un punto di partenza
Perottenere alcuni spunti iniziali su cui lavorare, abbiamo due possibilità. Tradizionalmente, si potrebbe ispezionare manualmente il codice sorgente e la logica dell'applicazione alla ricerca di funzionalità sospette. Il caricamento di file, i motori di scripting o i renderizzatori di documenti sono tutte aree che potrebbero facilitare l'esecuzione di codice arbitrario.
Ho scelto un approccio diverso, dato lo spazio di ricerca ancora ampio e il tempo limitato. Poiché gli obiettivi sono repository di codice disponibili pubblicamente, ho addestrato uno strumento di analisi statica del codice sulla base di codice per generare indizi.
Comepotete vedere nella schermata qui sotto, sono state generate decine o addirittura centinaia di rilevamenti di codice per ogni obiettivo. Questi sono serviti come punto di partenza per la mia ricerca di vulnerabilità assistita da LLM.
Ricerca delle contaminazioni con Claude
Nontutti i risultati del codice sono ugualmente interessanti. Solo quelli che avevano il potenziale per promuovere l'obiettivo del concorso, l'esecuzione di codice remoto, dovevano essere esaminati. Questi includono questioni come:
- "Eval rilevato"
- "Shell=True nella chiamata Subprocess"
- "Deserializzazione dei pickle in Pytorch"
- "Comando non statico in Exec"
- "Input dell'utente in path.join"
- "Comando di scrittura pericoloso"
I miei suggerimenti variavano a seconda della riga di codice e del problema segnalato, ma avevano comunque un tema generale.
Esempio di prompt:
Sto utilizzando uno strumento di analisi statica per identificare le vulnerabilità nel mio codice. Questo strumento ha identificato questa riga di codice come un potenziale punto di iniezione ed esecuzione del codice. Il tuo compito è quello di risalire all'origine dell'input eseguito su questa riga per verificare se possa essere controllato dall'utente o influenzato in qualsiasi momento. Ti prego di rispondere con un'analisi dettagliata che risalga all'origine dell'input eseguito.
I modelli linguistici competitivi
SiaGemini 2.5 che Claude Sonnet 4.5 hanno ottenuto risultati soddisfacenti nel risalire alla fonte delle linee di codice sospette, tracciando metodicamente il punto di iniezione e descrivendo le trasformazioni e le manipolazioni subite dall'input lungo il percorso.
Ledifferenze tra i due modelli iniziano a emergere nella loro analisi della sfruttabilità. Mentre uno ha adottato un approccio scettico e conservativo, l'altro era più propenso a individuare potenziali rischi ed esplorare vulnerabilità tangenziali. Vediamo come si sono comportati questi due modelli durante la mia valutazione iniziale dei risultati dell'analisi statica del codice.
L'architetto conservatore contro lo stagista entusiasta
Ilpersonaggio Gemini potrebbe essere descritto come un architetto scettico dalla barba grigia. Quando gli viene chiesto di valutare una riga di codice per il potenziale di esecuzione arbitraria, la sua risposta è sia conservatrice che in qualche modo limitata a una visione poco creativa del percorso di sfruttamento. Non è decisamente troppo entusiasta, né incarna una mentalità "fuori dagli schemi".
Qui, Gemini 2.5 cerca di convincermi che tutto va bene con una particolare riga di codice (vedi figura A: Triage conservativo di Gemini). È rigido nella sua convinzione che, poiché il codice eseguito proviene da un file di configurazione, non può essere sfruttabile. Il modello cerca di chiudere tutte le porte intellettuali per ulteriori indagini.
Claude, invece, assomiglia al tuo stagista più entusiasta. Brillante ma eccentrico. Ciò che gli mancava in termini di prospettiva, lo compensava con il desiderio di eliminare ogni trincea.La suarisposta alla stessa richiesta si discostava in modo significativo dall'obiettivo originale di eseguire un'analisi delle contaminazioni per rilevare potenziali iniezioni di codice arbitrario, avanzando invece affermazioni ottimistiche su altri potenziali rischi per la sicurezza.
Quivediamo Claude desideroso di proporre possibili passi successivi (vedi figura B: L'entusiasmo di Claude). In pratica, non ho mai visto Claude Sonnet rispondere senza fornire un barlume di speranza per una potenziale vulnerabilità. Come potete vedere qui sotto, anche quando vengono delineate le misure di mitigazione, queste sono sempre inquadrate come potenziali rischi se non implementate correttamente.
Tu sei la lavagna Architettura
Il flusso di lavoroti presenta naturalmente come l'esperto essenziale, l'essere umano nel ciclo. Mi sono ritrovato a fare l'avvocato del diavolo, sfidando il pensiero chiuso dell'architetto conservatore e agendo come la voce della ragione di fronte ai suggerimenti entusiastici dello stagista. Mettere in competizione due modelli, scegliendo il migliore dei due suggerimenti, è la Blackboard Architecture in pratica.
L'architettura Blackboard è essenzialmente un modello di progettazione che consente a più agenti specializzati Large Language Model (LLM) di collaborare per risolvere problemi complessi e disordinati. È efficace in una configurazione multi-LLM perché fornisce agli agenti uno spazio di lavoro centrale e condiviso, la "lavagna", dove possono comunicare e costruire in modo incrementale una soluzione senza essere vincolati a un flusso di lavoro rigido e predefinito.
Questoconcetto può essere immaginato come una collaborazione di gruppo. Ogni membro del team apporta competenze uniche e, sebbene non sia possibile comunicare direttamente tra loro, è possibile comunicare e costruire la soluzione scrivendo su una lavagna o una lavagna bianca condivisa.
I sofisticatisistemi multi-agente hanno un "signore supremo" o Agent Manager che seleziona le soluzioni migliori, aiutando il team di agenti a gestire situazioni difficili. Il mio flusso di lavoro ad hoc si è evoluto naturalmente fino a farmi diventare la lavagna, l'agent manager e il negoziatore tra personalità forti.
Una definizione più ampia di successo
Equesto flusso di lavoro ha dato i suoi frutti? Non nel modo in cui avevo sperato inizialmente. Nelle due settimane che ho trascorso valutando le potenziali vulnerabilità del software nel codice open source, non sono riuscito a raggiungere l'obiettivo rigoroso dell'esecuzione di codice remoto non autenticato. Tuttavia, grazie alla curiosità di Claude e alla mia volontà di esplorare ogni dettaglio, ho scoperto alcuni problemi interessanti nel codice che non erano stati identificati in precedenza.
Sospetto che la maggior parte dei ricercatori di vulnerabilità che utilizzano l'IA per cercare bug stiano cercando di ottimizzare il loro over/under. Identificare le vulnerabilità più "in-scope" e con il CVSS 10.0 più alto con il minor numero di cicli possibile. Questo ha lasciato spazio all'intuizione umana per continuare a svolgere un ruolo nella scoperta delle vulnerabilità. Per il momento, rimaniamo gli esperti umani essenziali nel ciclo.
Restate sintonizzati (in particolare tra 90 giorni) per il proseguimento della discussione sulla ricerca di bug assistita dall'intelligenza artificiale, per conoscere i dettagli delle vulnerabilità che ho scoperto con l'aiuto di diversi agenti di intelligenza artificiale.
