Nyereség:
- Képes felismerni a gyakori sebezhetőségi mintákat, mint például a visszatérés, a hozzáférés-szabályozás, az orákulum-manipuláció és a front-running, és átvizsgálni azokat statikus elemző eszközzel + mesterséges intelligencia + ember
- Képes különbséget tenni a mesterséges intelligencia erősségei között az eszköz kimenetének magyarázatában, valamint a téves pozitívumok és a gyengeségek előnyben részesítésében az MEV és az üzleti logika terén
- Értse meg, hogy a „tiszta vizsgálat” nem biztonsági tanúsítvány, hanem a szkennelés csak az ellenőrzés egyik rétege
Az auditálás holisztikus fegyelmét az előző egységben láthattuk. Ebben az egységben egy technikaibb témára összpontosítunk: a sebezhetőségi vizsgálatra – az ismert sebezhetőségi minták szisztematikus keresésére a kódban. Itt az AI-t a statikus elemző eszközökkel együtt használjuk asszisztensként, amely megvizsgálja és leírja az ismert sebezhetőségi mintákat. A cél: a leggyakoribb sérülékenységek alapos megismerése, és annak megállapítása, hogy az AI hol megbízható és hol nem megfelelő a szkennelésükben.
Statikus és dinamikus szkennelés
A szkennelés kétféle. Statikus elemzés – a kód vizsgálata futtatás nélkül: Az olyan eszközök, mint a Slither és a Mythril, átvizsgálják a szerződés kódját, és megjelölik az ismert mintákat. Ebbe a csoportba tartozik a dinamikus/szimbolikus elemzés (a kód futtatása különböző bemenetekkel vagy matematikai feltárása): fuzzing (bombázás véletlenszerű bemenettel) és szimbolikus végrehajtás (minden lehetséges út feltárása).
A mesterséges intelligencia nem helyettesíti ezeket az eszközöket, hanem kiegészíti őket: amikor a jármű figyelmeztetést ad ki, az AI közérthető nyelven elmagyarázza a figyelmeztetést; A mesterséges intelligencia emlékeztethet arra, ha az eszköz kihagy egy mintát; Az AI azonban önmagában nem tudja garantálni, hogy mennyit szkennel. A megfelelő munkafolyamat: eszköz + AI + ember.
Tipp: Adja meg az AI-nak egy statikus elemző eszköz (pl. Slither jelentés) kimenetét, és kérdezze meg: „magyarázza el minden riasztást egyszerű nyelven, melyek a valós kockázatok, és melyek lehetnek hamis pozitívumok?” kérdez. A mesterséges intelligencia felbecsülhetetlen értékű abban, hogy a nyerseszköz-kimenetet érthetővé és rangsorolhatóvá tegye az emberek számára.
A leggyakoribb sebezhetőségi minták
1. Visszalépés. Ha egy függvény meghív egy külső szerződést anélkül, hogy frissítené állapotát, akkor a hívott szerződés visszaléphet, újra elindíthatja ugyanazt a függvényt, és többször is kiveheti az alapot. Megoldás: ellenőrzések-hatások-kölcsönhatások sorrendje és visszatérési őr.
2. A hozzáférés-szabályozás hiánya. Egy kritikus funkció (kivonás, visszavonás, frissítés) véletlenül nyilvánosságra kerül. Ez az egyik leggyakoribb és legdrágább hiba.
3. Oracle manipuláció. A szerződés vak támaszkodása egy külső árforrásra (Oracle). A támadó azonnal manipulálja az árat, és megtéveszti a protokollt. Megoldás: idővel súlyozott átlagár (TWAP), több forrás.
4. Egész szám túlcsordulás/alulcsordulás. Amikor egy szám meghaladja a megengedett maximális értéket, és visszatér az elejére. A Modern Solidity a legtöbbet automatikusan elkapja, de a kockázat az alacsony szintű (assembly) kódban marad.
5. Elöljáró. A tranzakciók a visszaigazolásuk előtt megjelennek a nyilvános poolban (mempool); A támadó láthatja az Ön tranzakcióját, és beszúrhatja elé a saját tranzakcióját. MEV (Maximális kinyerhető érték – a tranzakciósorozatból kinyert érték) ennek a tárgynak az általános neve.
6. Szolgáltatásmegtagadás (DoS). Egy hurok túl drágává válik, és használhatatlanná teszi a funkciót, vagy egy címtől való függőség zárolódik.
7. Frissítési kockázatok. Tárolási ütközés és a hatáskörrel való visszaélés a bővíthető szerződésekben.
sebezhetőség
AI szkennelési bizalom
Miért
visszatérés
magas
Ismert, tiszta minta
hozzáférés-szabályozás
magas
A penész beszkennelhető
Egész műveletek
magas
szabványos vezérlés
Oracle manipuláció
közepes
Kontextust igényel
Elölfutó/MEV
Közepes-alacsony
protokoll specifikus
üzleti logikai hiba
alacsony
Hiteles, kontextuális
Gyenge felszólítás / Erős felszólítás
Gyenge felszólítás:
Van kiskapu ebben a kódban?
Erőteljes felszólítás:
Az Ön szerepe: biztonsági átvilágítási asszisztens. Vizsgálja meg az alábbi szerződést a következő ismert mintákért, és mindegyikhez "kockáztatott/nincs/bizonytalan": újrabelépés, hozzáférés-vezérlés, egészszámú műveletek, oracledependency, front-running, DoS, frissítési biztonság. Minden meghatározást kapcsoljon a megfelelő sorhoz, és magyarázza el, miért áll fenn a kockázat. Ezek olyan hipotézisek, amelyeket egy statikus elemző eszközzel és auditálóval ELLENŐRZŐDNEK. Vegye figyelembe, hogy lehetnek téves pozitív eredmények.
Négy másolható sablon
1) A szerszám kimenet leírása:
Az alábbiakban egy statikus elemző eszköz (Slither) jelentése látható. Magyarázza el minden riasztást közérthető nyelven: mit jelent ez, valós kockázat vagy lehetséges téves pozitív eredmény, mi legyen a prioritása? Ne hozzon határozott döntést; A könyvvizsgáló megerősítésének prioritása.
2) Reentancy fókuszú szűrés:
Ebben a szerződésben megtalálja az összes külső hívást kezdeményező funkciót. Vizsgálja meg, hogy mindegyiknél betartják-e az ellenőrzések-hatások-kölcsönhatások sorrendjét, és van-e visszalépési őr. A kockázatosakat mutasd meg egy vonallal. Jelölje meg, ha nem biztos benne; Kihasználási kód generálása.
3) Beléptető térkép:
Sorolja fel az összes külső/nyilvános funkciót ebben a szerződésben, és adja meg, hogy „ki hívhat” (mindenki/tulajdonos/szerep). Hajtsa végre a kritikus műveleteket (visszavonás, nyomtatás, frissítés), és jelölje meg azokat, amelyek hozzáférés-szabályozása gyenge. Mutassa be táblázattal.
4) Hamis pozitív elimináció:
Fontolja meg, hogy ez a vizsgálati figyelmeztetés miért nem jelent VALÓDI kockázatot (hamis pozitív): milyen környezet- vagy kódfeltétel érvénytelenítené ezt a figyelmeztetést? De ne mondd, hogy "nincs semmi probléma"; Sorolja fel azokat a pontokat, amelyek megerősítésre szorulnak.
Három mini tok (számokban)
1. eset – Jármű + mesterséges intelligencia megduplázta a hatékonyságot. Az egyik csapat a Slithert egy 12 szerződésből álló projekten futtatta, és 140 figyelmeztetést kapott. Miután a mesterséges intelligencia megmagyarázta és rangsoroltuk a riasztásokat, kiderült, hogy a 140 riasztásból 95 téves volt; A csapat 45 valódi jelöltre összpontosított. A triage ideje 2 napról 5 órára csökkent. Tanulság: Az AI hatékonyan humanizálja a jármű teljesítményét.
2. eset – AI eltérítette a MEV-t. Egy DEX (decentralizált csere) szerződésben az AI tisztának találta a szabványos mintákat, de nem észlelt egy előre futó sebezhetőséget; mert ez a protokoll műveleti sorrendjére jellemző. Emberi auditor és szimuláció rögzítve. Tanulság: A protokoll-specifikus kockázatok, például a MEV/front-running az AI gyenge területei.
3. eset – elkerülhető az időveszteség a hamis pozitív eredmény miatt. A csapatot megkímélték a szükségtelen átírástól, amikor az AI elmagyarázta, hogy a visszatérési figyelmeztetés valójában hamis pozitív (a funkció már védett volt). A csapat azonban egyetlen teszttel is megerősítette. Tanulság: AI prioritások; A megerősítés ismét a teszteléssel jár.
A szkennelés korlátai
A vizsgálat ismert mintákat talál. Sem az eszköz, sem az AI nem garantáltan észlel új, egyedi vagy protokollspecifikus sebezhetőséget. Ezért a szűrés az audit része; nem önmagát. Az az elképzelés, hogy "a vizsgálat tiszta, tehát biztonságos" az egyik legveszélyesebb tévhit ezen a területen. A kotrás felszedi az alacsonyan csüngő gyümölcsöt; A mély és egyedi kockázatokhoz elengedhetetlen az emberi szakértelem, a tesztelés, a fuzzing és a formális auditálás.
Figyelem: A leolvasó eszköz vagy mesterséges intelligencia „tiszta” jelentése nem biztonsági tanúsítvány. Ennek így bemutatása – különösen a befektetők számára – félrevezető és etikátlan.
Gyakori hibák
- Szűrés helyettesítése ellenőrzéssel. A szkennelés egy réteg, nem az egész.
- AI használata eszközök nélkül. Statikus elemzés + AI + emberi munka együtt.
- A hamis pozitívumok eltávolítása megerősítés nélkül. Minden képernyő tesztelt/ember által ellenőrzött.
- A protokoll-specifikus kockázatok (MEV) megkerülése mesterséges intelligencia segítségével. Az AI gyenge területe.
- A "tiszta vizsgálat" = "biztonságos" gondolkodás. Nem találja meg az ismeretlent.
- Kihasználási kód generálása. Csak a védekező kockázat leírása jogos.
Összefoglalva
- A sebezhetőségi vizsgálat ismert sebezhetőségi mintákat keres a jármű + AI + ember használatával.
- Az AI hatékonyan magyarázza és rangsorolja a statikus elemző eszköz kimenetét.
- Megbízható az olyan egyértelmű mintákban, mint a visszatérés és a hozzáférés-szabályozás; Gyenge a MEV és az üzleti logika.
- Még a hamis pozitív eredmények kiküszöbölése is megerősítést igényel.
- A „tiszta vizsgálat” nem biztonsági tanúsítvány; Nem helyettesíti a felügyeletet.
Pályázati feladat
Futtasson statikus elemző eszközt egy szerződésmintán (ha lehetséges), vagy keressen egy kész Slither jelentést. Alkalmazza a "tool output description" promptot az AI-ra. Értékelje, hogy a mesterséges intelligencia: (1) helyesen magyarázza-e a figyelmeztetéseket, (2) van-e értelme megkülönböztetni a hamis pozitívakat, és (3) elmulaszt-e egy protokoll-specifikus kockázatot. Töltse ki a „jármű talált / AI magyarázata / ember által megerősített” oszlopokat egy táblázatban.
ellenőrző lista
- [ ] A sraffozást a vezérlő rétegeként helyeztem el.
- [ ] Statikus elemző eszközt + AI + embert használtam együtt.
- [ ] Kategóriánként kerestem ismert mintákat.
- [ ] Megerősítéssel kiküszöböltem a hamis pozitívakat.
- [ ] Olyan gyenge területeken támaszkodtam az emberekre, mint a MEV/üzleti logika.
- [ ] Nem ajánlottam fel a "tiszta söprést" biztosítékul.
- [ ] Csak védelmi céllal dolgoztam; Nem én készítettem exploitokat.