Podpis wyglądał groźnie.
Kontekst zmienił ocenę.

Podpis może wyglądać podejrzanie w oderwaniu od reszty kodu

W pracach nad weryfikacją smart kontraktów analizowaliśmy alarmy związane z podpisami. Samo wystąpienie ecrecover oraz brak jednego z popularnych pól ochronnych powodowały zbyt szerokie wnioski o podatności. Dopiero sprawdzenie walidacji podpisu, nonce i miejsca użycia upoważnienia pozwalało ocenić rzeczywistą granicę bezpieczeństwa.

W tym artykule opisujemy również odrzucone hipotezy. Weryfikacja wykazała, że część alarmów pomijała istniejące zabezpieczenia. Nie przedstawiamy ich jako udanych ataków ani nie publikujemy nazw wdrożeń, adresów portfeli czy gotowych transakcji. Audyt jest wartościowy także wtedy, gdy przekonująco wyjaśnia, dlaczego podejrzenie nie zostało potwierdzone.

Poprawny podpis musi pasować do konkretnego działania

W aplikacjach Web3 podpis może upoważniać do wykonania działania bez osobistego wysyłania transakcji przez podpisującego. Trzeba jednak ustalić, jakie dane obejmuje wiadomość, kto ma prawo ją podpisać i gdzie upoważnienie może zostać wykorzystane. Samo odzyskanie adresu z podpisu nie odpowiada na wszystkie te pytania.

Podczas przeglądu śledzimy pełny przepływ: budowę wiadomości, odzyskanie podpisującego, sprawdzenie jego roli, kontrolę stanu i wykonanie operacji. Dzięki temu oddzielamy błąd kryptograficznej reprezentacji od problemu w logice uprawnień.

Własna kontrola low-s zmienia ocenę alarmu

Jedna z klas alarmów zakładała ryzyko tylko na podstawie użycia ecrecover. Analiza kontekstu pokazała, że w kodzie istniała własna kontrola low-s. Nie można było zatem utrzymać tezy o braku tej kontroli wyłącznie dlatego, że kontrakt nie używał oczekiwanego przez analizator wywołania biblioteki.

Kontrola low-s dotyczy dopuszczalnej reprezentacji podpisu ECDSA. Nie jest samodzielną ochroną przed ponownym użyciem całego upoważnienia. Biblioteki takie jak OpenZeppelin ECDSA opisują własności weryfikacji podpisów, ale audyt musi sprawdzić również logikę otaczającą wywołanie.

Brak deadline nie dowodzi automatycznie replay

Kolejny alarm wiązał brak terminu ważności z możliwością odtworzenia operacji. Tymczasem w analizowanym przepływie istniała kontrola oparta na rosnącym nonce. To zmieniało ocenę ponownego wykorzystania zaakceptowanego upoważnienia i wymagało odrzucenia zbyt ogólnego wniosku.

Jednorazowość i czas ważności to różne właściwości. Nonce może uniemożliwić powtórzenie użytej operacji. Termin ważności ogranicza czas wykorzystania upoważnienia, które jeszcze nie zostało zużyte. Brak deadline nadal może mieć znaczenie biznesowe, ale nie zastępuje dowodu, że ten sam podpis można skutecznie wykorzystać ponownie.

W praktyce sprawdzamy, z czym związany jest nonce, kiedy zostaje zużyty i czy nie istnieje inna ścieżka wykonania omijająca tę samą kontrolę. Ważne są także operacje równoległe i cofnięcie stanu przy błędzie.

Format wiadomości nie zastępuje kompletnej polityki wykonania

Jeżeli projekt korzysta z EIP-712, oceniamy zakres podpisanych danych oraz kontekst domeny. Zależnie od operacji znaczenie mają m.in. kontrakt weryfikujący, sieć, rodzaj działania i odbiorca uprawnienia. Nie przypisujemy tu EIP-712 każdemu analizowanemu kontraktowi: jest to osobny element metodyki przeglądu podpisów.

Specyfikacja EIP-712 zaznacza, że sama nie zapewnia ochrony przed replay. Dlatego w raporcie oceniamy także nonce lub rejestr wykorzystanych upoważnień, uprawnienia podpisującego i reguły wykonania. Uporządkowana wiadomość pomaga użytkownikowi rozumieć zgodę, lecz backend kontraktu nadal musi ją właściwie egzekwować.

Walidujemy to, co rzeczywiście można uzyskać

Nie każdy problem z reprezentacją podpisu prowadzi do dwukrotnej wypłaty. Nie każda publiczna funkcja jest funkcją bez kontroli uprawnień. Do oceny potrzebny jest stan kontraktu, zależności i warunki wykonania. W naszych pracach oddzieliliśmy automatyczne wskazanie od potwierdzonego wpływu i poprawiliśmy sposób odrzucania alarmów pomijających istniejące kontrole.

Podobnie uprawniony administrator lub multisig nie staje się punktem wejścia osoby postronnej tylko dlatego, że ma istotne możliwości. Ryzyko zarządzania kluczami i ryzyko nieautoryzowanego wykonania opisujemy oddzielnie. To pomaga zespołowi wybrać właściwą poprawkę, zamiast usuwać celowo zaprojektowane funkcje.

Zakres audytu podpisów w aplikacjach Web3

Wiadomość i role. Kompletność danych operacji, identyfikacja podpisującego oraz jego aktualne uprawnienia do zatwierdzanego działania.

Jednorazowość i kontekst. Zużywanie nonce, obsługa ponowień, możliwe wykorzystanie upoważnienia w innej funkcji, sieci lub kontrakcie oraz wymagania dotyczące czasu ważności.

Dowody i testy. Próby negatywne, właściwa ocena skutku i osobne oznaczenie luk w pokryciu. Jeżeli brakuje źródeł zależności, nie traktujemy tego jako potwierdzenia bezpieczeństwa.

Takie badanie uzupełnia audyt aplikacji dApp, API, integracji portfela i samych smart kontraktów. Zakres warto ustalić przed wdrożeniem nowego mechanizmu podpisów albo po zmianie logiki autoryzacji.

Pytania o podpisy i audyt Web3