Guadagni:
- Capacità di riconoscere modelli di vulnerabilità comuni come rientro, controllo degli accessi, manipolazione di oracoli e front-running e di scansionarli con uno strumento di analisi statica + intelligenza artificiale + essere umano
- Capacità di distinguere tra i punti di forza dell'intelligenza artificiale nello spiegare l'output dello strumento e nel dare priorità ai falsi positivi e ai punti deboli nel MEV e nella logica aziendale
- Tieni presente che una "scansione pulita" non è un certificato di sicurezza, che la scansione è solo un livello di controllo
Abbiamo visto la disciplina olistica dell'auditing nell'unità precedente. In questa unità ci concentreremo su un argomento più tecnico: la scansione delle vulnerabilità: la ricerca sistematica di modelli di vulnerabilità noti nel codice. Qui utilizzeremo l’intelligenza artificiale, insieme a strumenti di analisi statica, come assistente che scansiona e descrive modelli di vulnerabilità noti. L’obiettivo: conoscere in modo approfondito le vulnerabilità più comuni e distinguere dove l’AI è affidabile e dove è inadeguata nel scansionarle.
Scansione statica e dinamica
La scansione è di due tipi. Analisi statica: esame del codice senza eseguirlo: strumenti come Slither e Mythril scansionano il codice del contratto e segnalano modelli noti. L'analisi dinamica/simbolica (eseguendo il codice con input diversi o esplorandolo matematicamente): il fuzzing (bombardamento con input casuali) e l'esecuzione simbolica (esplorando tutti i percorsi possibili) rientrano in questo gruppo.
L’intelligenza artificiale non sostituisce questi strumenti, li integra: quando il veicolo emette un avviso, l’intelligenza artificiale spiega l’avviso in un linguaggio semplice; L'intelligenza artificiale può ricordare quando lo strumento manca uno schema; Ma l’intelligenza artificiale da sola non può garantire quanto scansiona. Il giusto flusso di lavoro: strumento + AI + uomo.
Suggerimento: fornire all’intelligenza artificiale l’output di uno strumento di analisi statica (ad esempio il rapporto Slither) e chiedere “spiegare ogni avviso in un linguaggio semplice, quali sono rischi reali e quali potrebbero essere falsi positivi?” chiedere. L’intelligenza artificiale ha un valore inestimabile nel rendere i risultati grezzi degli strumenti comprensibili e prioritari per gli esseri umani.
Modelli di vulnerabilità più comuni
1. Rientro. Se una funzione richiama un contratto esterno senza aggiornarne lo stato, il contratto richiamato può tornare indietro, attivare nuovamente la stessa funzione e prelevare il fondo più volte. Soluzione: ordine di controlli-effetti-interazioni e guardia di rientro.
2. Mancanza di controllo degli accessi. Una funzione critica (ritiro, ritiro, aggiornamento) viene resa pubblica accidentalmente. È uno degli errori più comuni e costosi.
3. Manipolazione dell'oracolo. La cieca dipendenza del contratto da una fonte esterna di prezzo (oracolo). L’aggressore manipola istantaneamente il prezzo e inganna il protocollo. Soluzione: prezzo medio ponderato nel tempo (TWAP), multi-sorgente.
4. Overflow/underfall di numeri interi. Quando un numero supera il valore massimo consentito e ritorna all'inizio. Modern Solidity ne rileva la maggior parte automaticamente, ma il rischio rimane nel codice di basso livello (assembly).
5. In prima linea. Le transazioni appaiono nel pool pubblico (mempool) prima di essere confermate; L'aggressore può vedere la tua transazione e inserirvi la propria transazione. MEV (Maximal Extractable Value - il valore estratto dalla sequenza della transazione) è il nome generale di questo argomento.
6. Negazione di servizio (DoS). Un loop diventa troppo costoso e rende la funzione inutilizzabile oppure una dipendenza da un indirizzo viene bloccata.
7. Rischi di aggiornamento. Collisione di storage e abuso di autorità nei contratti aggiornabili.
vulnerabilità
Fiducia nella scansione dell'intelligenza artificiale
Perché
rientro
alto
Modello ben noto e chiaro
controllo degli accessi
alto
La muffa può essere scansionata
Operazioni sugli interi
alto
controllo standard
Manipolazione dell'oracolo
medio
Richiede contesto
In prima linea/MEV
Medio-Basso
specifico del protocollo
errore di logica aziendale
basso
Autentico, contestuale
Prompt debole / Prompt forte
Suggerimento debole:
C'è una scappatoia in questo codice?
Suggerimento potente:
Il tuo ruolo: assistente ai controlli di sicurezza. Esegui la scansione del contratto di seguito per i seguenti modelli noti e "a rischio/no/incerto" per ciascuno: rientro, controllo degli accessi, operazioni su numeri interi, dipendenza da Oracle, front-running, DoS, sicurezza dell'aggiornamento. Collega ciascuna determinazione alla riga pertinente e spiega perché esiste un rischio. Si tratta di ipotesi che VERRANNO VERIFICATE con uno strumento di analisi statica e auditor. Tieni presente che potrebbero esserci falsi positivi.
Quattro modelli copiabili
1) Descrizione dell'output dello strumento:
Di seguito è riportato il report di uno strumento di analisi statica (Slither). Spiega ogni avviso in un linguaggio semplice: cosa significa, è un rischio reale o un possibile falso positivo, quale dovrebbe essere la sua priorità? Non prendere una decisione ferma; Dare priorità alla conferma del revisore.
2) Screening focalizzato sul rientro:
Trova tutte le funzioni che effettuano chiamate esterne in questo contratto. Esaminare se per ciascuno di essi viene seguito l'ordine di prove-effetti-interazioni e se esiste una guardia di rientro. Mostra quelli rischiosi con una linea. Segna se non sei sicuro; Generazione del codice di exploit.
3) Mappa del controllo accessi:
Elenca tutte le funzioni esterne/pubbliche presenti in questo contratto e specifica "chi può chiamare" (tutti/proprietario/ruolo) per ciascuna. Esegui operazioni critiche (ritiro, stampa, aggiornamento) e contrassegna quelle con controllo degli accessi debole. Presentatelo con una tabella.
4) Eliminazione dei falsi positivi:
Considera perché questo avviso di scansione potrebbe non essere un rischio REALE (falso positivo): quale contesto o condizione del codice invaliderebbe questo avviso? Ma non dire "non c'è assolutamente nessun problema"; Elencare i punti che necessitano di conferma.
Tre mini custodie (in numeri)
Caso 1: Veicolo + AI hanno raddoppiato l’efficienza. Un team ha gestito Slither su un progetto da 12 contratti e ha ricevuto 140 avvisi. Una volta che l’IA ha spiegato e dato la priorità agli avvisi, si è scoperto che 95 dei 140 avvisi erano falsi positivi; Il team si è concentrato su 45 candidati reali. Il tempo di triage è diminuito da 2 giorni a 5 ore. Lezione: l’intelligenza artificiale è potente nell’umanizzare la produzione dei veicoli.
Caso 2: l’IA ha dirottato il MEV. In un contratto DEX (scambio decentralizzato), l’IA ha trovato i modelli standard puliti ma non è riuscita a rilevare una vulnerabilità in primo piano; perché questo era specifico dell'ordine delle operazioni del protocollo. Auditor umano e simulazione catturati. Lezione: i rischi specifici del protocollo come MEV/frontrunning sono l’area debole dell’IA.
Caso 3: evitato di perdere tempo con un falso positivo. Al team è stata risparmiata un'inutile riscrittura quando l'IA ha spiegato che un avviso di rientro era in realtà un falso positivo (la funzione era già protetta). Ma il team lo ha comunque confermato con un unico test. Lezione: l’intelligenza artificiale dà priorità; La conferma arriva ancora una volta con i test.
Limiti della scansione
La scansione rileva modelli noti. Né lo strumento né l’intelligenza artificiale possono garantire il rilevamento di una vulnerabilità nuova, unica o specifica del protocollo. Pertanto, lo screening fa parte dell'audit; non se stesso. L'idea che "la scansione è pulita, quindi significa che è sicura" è uno dei malintesi più pericolosi in questo campo. Il dragaggio raccoglie i frutti più bassi; Per rischi profondi e unici, sono essenziali la competenza umana, i test, il fuzzing e l’audit formale.
Attenzione: un report "pulito" di uno strumento di scansione o di un'intelligenza artificiale non è un certificato di sicurezza. Presentarlo in questo modo, soprattutto agli investitori, è fuorviante e non etico.
Errori comuni
- Sostituzione dello screening con l'ispezione. La scansione è uno strato, non l'intero.
- Usare l'intelligenza artificiale senza strumenti. Analisi statica + AI + lavoro umano insieme.
- Eliminazione dei falsi positivi senza conferma. Ogni schermo è testato/verificato da esseri umani.
- Bypassare i rischi specifici del protocollo (MEV) affidandosi all’intelligenza artificiale. L'area debole dell'IA.
- Pensare "scansione pulita" = "sicuro". Non riesce a trovare l'ignoto.
- Generazione del codice di exploit. Solo la descrizione difensiva del rischio è legittima.
In sintesi
- La scansione delle vulnerabilità cerca modelli di vulnerabilità noti con veicolo + IA + essere umano.
- L'intelligenza artificiale è potente nello spiegare e dare priorità all'output dello strumento di analisi statica.
- Affidabile in schemi chiari come il rientro e il controllo degli accessi; Debole nel MEV e nella logica aziendale.
- Anche l’eliminazione dei falsi positivi richiede conferma.
- Una "scansione pulita" non è un certificato di sicurezza; Non sostituisce la supervisione.
Compito dell'applicazione
Esegui uno strumento di analisi statica su un contratto campione (se possibile) o trova un rapporto Slither già pronto. Applicare il prompt "descrizione output strumento" all'IA. Valutare se l'intelligenza artificiale: (1) spiega correttamente gli avvertimenti, (2) ha senso nel distinguere tra falsi positivi e (3) non rileva un rischio specifico del protocollo. Compila le colonne "veicolo trovato / AI spiegata / umano confermato" in una tabella.
lista di controllo
- [ ] Ho posizionato il tratteggio come livello del controllo.
- [ ] Ho utilizzato insieme lo strumento di analisi statica + l'intelligenza artificiale + l'essere umano.
- [ ] Ho cercato categoria per categoria i modelli conosciuti.
- [ ] Ho eliminato i falsi positivi con la conferma.
- [] Mi sono affidato agli esseri umani in aree deboli come il MEV/la logica aziendale.
- [] Non ho offerto "pulizia pulita" come garanzia.
- [ ] Ho lavorato solo per scopi di difesa; Non ho creato exploit.