Atakujący wypłacił 6 milionów dolarów z vaulta zdecentralizowanych finansów (DeFi), mimo że protokół stosował whitelisę zatwierdzonych adresów — kontrolę bezpieczeństwa zaprojektowaną tak, aby ograniczać przepływy środków do wcześniej autoryzowanych miejsc docelowych. Platforma bug bounty i bezpieczeństwa Immunefi ujawniła incydent, potwierdzając stratę 6 milionów dolarów. Naruszenie ujawnia poważną lukę w tym, jak autoryzacja oparta na whitelisach jest wdrażana i audytowana w kontraktach vaultów. Kontrakty vaultów koncentrują depozyty wielu użytkowników za jednym zestawem uprawnień kontraktu, dlatego awaria jednej kontroli autoryzacji może przerodzić się w dużą, natychmiastową stratę dla deponentów.

Konkretny protokół, sieć blockchain, hash transakcji i wektor ataku nie zostały publicznie potwierdzone w momencie pisania tekstu; szczegóły wykraczające poza te fakty pozostają niezweryfikowane.

Czego nie zapobiegła whitelista zatwierdzonych adresów

Whitelista zatwierdzonych adresów ma egzekwować, że wypłaty z vaulta lub transfery aktywów kierowane są wyłącznie do ustalonego zestawu wcześniej autoryzowanych adres. W teorii atakujący, który nie może dodać własnego adresu do tej listy, nie może wykraść środków. W praktyce kontrola ta jest tak silna, jak logika zarządzająca aktualizacjami listy, kontrola dostępu do funkcji administracyjnych, które nią zarządzają, oraz wszystkie kontrakty współdziałające, które mogą wywoływać uprzywilejowane metody vaulta.

Typowe punkty awarii obejmują kompromitację klucza administratora, która pozwala dodać złośliwy adres przed wypłatą środków; ścieżkę reentrancji lub callbacku, która całkowicie omija kontrolę whitelist; lub błędnie skonfigurowany kontrakt proxy, którego implementacja nie egzekwuje tych samych ograniczeń co interfejs proxy. Bez potwierdzonego raportu powyłamowego deponenci nie mogą jeszcze ustalić, którą ścieżką posłużył się atakujący w tym przypadku.

Dlaczego sama whitelista nie wystarcza do bezpieczeństwa vaulta

Whitelista to kontrola perymetryczna, a nie kompletny system obrony wielowarstwowej. W praktyce branżowej kontrole wypłat w stylu whitelist są zazwyczaj związane z vaultami uprawnionymi lub instytucjonalnymi, gdzie ściślejsza kontrola operacyjna odbywa się kosztem ryzyka koncentracji klucza administratora — tej samej zależności, która jest teraz badana w tym incydencie. Bezpieczeństwo vaulta zależy również od tego, czy kontrakt ma działający mechanizm pauzy, czy wypłaty awaryjne są chronione timelockiem oraz czy aktualizacja whitelist wymaga zatwierdzenia multi-sig lub opóźnienia zarządczego. Jeśli którakolwiek z tych warstw jest nieobecna lub błędnie skonfigurowana, pojedynczy skompromitowany klucz lub błąd logiki może uczynić whitelisę bezużyteczną.

Deponenci oceniający vaulty z whitelisą powinni zweryfikować: kto kontroluje klucz administratora umożliwiający aktualizację whitelist, jaki jest opóźnienie timelocka przy dodawaniu adresów, czy kontrakt vaulta znajduje się za upgradeowalnym proxy oraz czy niezależny audyt był specjalnie ukierunkowany na ścieżkę autoryzacji. Vault reklamowany jako „whitelistowany” bez takich ujawnień oferuje słabsze gwarancje, niż sugeruje etykieta. Wzorzec przypomina problemy ze ścieżką autoryzacji widziane wydentach protokołów multi-chain, gdzie zatwierdzone błędy ponownie wprowadzały podatny stan.

Natychmiastowe kroki dla deponentów i operatorów

Każdy deponent posiadający środki w vaultie korzystającym z whitelist zatwierdzonych adresów powinien sprawdzić, czy protokół wydał ogłoszenie o pauzie lub stanie awaryjnym od czasu ujawnienia przez Immunefi. Tam, gdzie dotknięty protokół nie został publicznie nazwany, natychmiastowym krokiem jest monitorowanie feedu ujawnień Immunefi oraz oficjalnego forum zarządzania protokołem w celu uzyskania dalszych szczegółów. Rozwojami najbardziej prawdopodobnymi, by doprecyzować obraz, są: zmienione ujawnienie wskazujące dotknięty protokół i łańcuch, opublikowany raport powyłamowy identyfikujący wektor ataku oraz jakikolwiek widoczny ruch wypłaconych środków na łańcuchu.

Operatorzy vaultów powinni potraktować incydent jako impuls do audytu pełnej ścieżki autoryzacji: nie tylko tego, czy whitelista istnieje, ale czy każdy punkt wejścia do logiki vaulta egzekwuje tę samą kontrolę, czy funkcje administracyjne są chronione multi-sig oraz czy alerty monitorujące uruchamiają się przy transakcjach aktualizacji whitelist. Funkcja pauzy, której nie można uruchomić w ciągu minut od anomalnego transferu, nie zapewnia żadnej realnej ochrony. Struktury zarządzania kontrolujące parametry vaulta powinny również przeanalizować, czy decyzje architektoniczne vaulta narażają deponentów na ryzyko koncentracji klucza administratora.

Strata 6 milionów dolarów potwierdza, że polityki zatwierdzonych adresów są kontrolą konieczną, ale niewystarczającą. Bezpieczeństwo vaulta wymaga warstwowego egzekwowania: kontroli dostępu do funkcji administracyjnych, timelocków na operacjach zmieniających stan, monitoringu w czasie rzeczywistym oraz przetestowanej ścieżki reagowania na incydenty obejmującej weryfikowalną pauzę.