Zmiana implementacji.
Zmiana zasad.

Smart kontrakt może zmienić zachowanie po wdrożeniu

W pracach nad weryfikacją bezpieczeństwa Web3 zajmowaliśmy się kontraktami aktualizowalnymi. Jeden z kontrolowanych benchmarków obejmował celowo podatny wariant UUPS, w którym osoba bez wymaganych uprawnień mogła doprowadzić do zmiany implementacji. Chcieliśmy sprawdzić nie tylko sygnał w kodzie, ale także skutek tej zmiany w teście.

To opis testu laboratoryjnego i naszego sposobu walidacji. Nie jest raportem o przejęciu produkcyjnego protokołu ani o stracie środków klienta. Test dotyczył przygotowanego scenariusza. Nie wysyłaliśmy w jego ramach transakcji do cudzego wdrożenia na mainnecie.

Proxy to adres, implementacja to wykonywana logika

W uproszczeniu użytkownik wywołuje proxy, które kieruje wykonanie do implementacji. Aktualizacja zmienia kod odpowiedzialny za zachowanie systemu, podczas gdy użytkownicy nadal korzystają z adresu proxy. Dlatego uprawnienie do upgrade’u jest jedną z najważniejszych granic zaufania w takim projekcie.

Dokumentacja OpenZeppelin UUPS opisuje mechanizm aktualizacji umieszczony w implementacji oraz potrzebę właściwej autoryzacji. Samo wykorzystanie standardowej biblioteki nie zastępuje sprawdzenia, kto może uruchomić zmianę w konkretnym wdrożeniu.

Niechroniona aktualizacja w kontrolowanym benchmarku

W podatnym wariancie testowym sprawdziliśmy możliwość zmiany implementacji z konta, które nie powinno mieć uprawnień administracyjnych. Następnie test wprowadzał przygotowaną implementację demonstracyjną i weryfikował skutki jej działania na testowym saldzie. Asercja wymagała wykazania przyrostu salda kontrolowanego konta.

Dopiero taki wynik pozwalał potraktować scenariusz jako potwierdzony w granicach benchmarku. Zwykłe wywołanie funkcji bez błędu nie dowodziłoby ani skutecznego upgrade’u, ani wpływu na aktywa. Wynik testu musi odpowiadać dokładnie temu, co deklaruje opis podatności.

Dlaczego samo „transakcja przeszła” nie wystarcza

Jednym z ważnych usprawnień naszej walidacji było oddzielenie sondy technicznej od dowodu wpływu. Sonda odpowiada na wąskie pytanie, np. czy dana ścieżka wywołania jest dostępna. Potwierdzenie skutku musi wykazać zmianę odpowiedniego stanu i naruszenie założonej granicy uprawnień.

Dla upgrade’u oznacza to przynajmniej sprawdzenie tożsamości wywołującego, implementacji przed i po operacji oraz wpływu nowej logiki na kontrolowany zasób. Test negatywny powinien pokazać, że poprawnie zabezpieczony wariant odrzuca tę samą próbę osoby postronnej. Tak przygotowany PoC jest użyteczny przy naprawie i reteście.

Administrator protokołu nie jest anonimowym atakującym

W tych samych pracach porządkowaliśmy ocenę uprawnień administracyjnych. Poprawnie uprawniony właściciel, multisig lub ProxyAdmin może zgodnie z projektem wykonywać określone operacje. Samo istnienie takiej roli nie stanowi dowodu, że te same czynności wykona dowolna osoba.

Rozdzielamy więc dwie oceny. Pierwsza dotyczy błędu kontroli dostępu: ktoś bez wymaganych praw może zmienić zachowanie kontraktu. Druga dotyczy ryzyka zarządzania: jakie możliwości ma uprawniony administrator i jak zabezpieczono jego klucze. Oba tematy są ważne, ale wymagają innych dowodów i innych zaleceń.

Podobnie brak inicjalizacji samej implementacji nie jest automatycznie potwierdzeniem przejęcia proxy. Trzeba ustalić, w jakim kontekście wykonuje się kod i jaki stan jest modyfikowany. W naszej walidacji sygnał dotyczący inicjalizacji nie otrzymywał statusu pełnego dowodu tylko dlatego, że brzmiał groźnie.

Analizujemy wdrożenie, nie pojedynczy plik Solidity

Audyt smart kontraktów wymaga powiązania proxy, implementacji, ról i kontraktów zależnych. Ograniczony fragment kodu może pomijać właśnie ten komponent, który przechowuje stan lub egzekwuje autoryzację. Podczas naszych prac rozszerzyliśmy materiał analityczny o źródła, ABI i relacje między kontraktami.

Sprawdzamy również zgodność analizowanego kodu z wdrożeniem i siecią. Jeżeli brakuje krytycznej implementacji albo odczyt stanu się nie powiedzie, wynik powinien wskazywać lukę pokrycia. Błąd odczytu nie jest dowodem braku aktywów ani bezpieczeństwa kontraktu. Standardowe sloty proxy opisuje ERC-1967.

Od ustalenia do sprawdzalnej naprawy

Raport powinien określać komponent, wymagane uprawnienia, warunki uruchomienia i potwierdzony skutek. Dla mechanizmu aktualizacji istotne są zalecenia dotyczące ról, inicjalizacji i procesu wdrożeniowego. Po poprawce powtarza się scenariusz w uzgodnionym środowisku oraz sprawdza, czy legalne aktualizacje nadal działają.

Takie podejście pomaga zespołom budującym aplikacje Web3, tokeny, vaulty i protokoły DeFi. Wycena audytu zależy od złożoności kodu, architektury, zależności i oczekiwanego zakresu weryfikacji. Potrzebny jest zakres odnoszący się do konkretnego wydania, a nie ogólna deklaracja, że projekt „ma audyt”.

Pytania o audyt smart kontraktów UUPS