Incydent bezpieczeństwa Binance przyciągnął uwagę nie tylko ze względu na skalę podejrzanej aktywności portfeli, ale także z powodu jednego szczegółu technicznego widocznego na krótko przed rozpoczęciem przemieszczania głównych aktywów Ethereum: partii autoryzacji EIP-7702.
Ten szczegół szybko wypchnął EIP-7702 do centrum dyskusji. Mechanizm delegowania kont Ethereum pozwala zwykłemu kontu posiadanemu zewnętrznie, czyli EOA, tymczasowo wykonywać logikę inteligentnego kontraktu. W incydencie Binance badacze blockchain zidentyfikowali delegację EIP-7702 na krótko przed tym, jak aktywa zostały przetransferowane z gorącego portfela powiązanego z Binance.
Istnieje jednak ważne rozróżnienie.
Samo istnienie autoryzacji EIP-7702 nie dowodzi, że EIP-7702 zostało wykorzystane.
Wstępne dochodzenie Binance wskazuje natomiast na kompromitację infrastruktury operacyjnej. Giełda poinformowała, że laptop inżyniera DevOps mógł zostać przejęty, co pozwoliło atakującemu uzyskać dostęp do kontenera usługi i złożyć nieautoryzowane transakcje wypłat. Binance oświadczyła również, że nie znalazła dowodów na wyciek kluczy prywatnych portfeli.
To czyni ten incydent szczególnie istotnym dla zrozumienia nowoczesnego bezpieczeństwa portfeli. Klucz prywatny może pozostać wewnątrz chronionej infrastruktury, podczas gdy atakujący nadużywa innego systemu, który jest uprawniony do żądania legalnych podpisów.
Ten artykuł wyjaśnia, co EIP-7702 najprawdopodobniej zrobiło w tym incydencie, dlaczego doniesienia o wielu autoryzacjach przyciągnęły uwagę oraz dlaczego różnica między kradzieżą klucza a kompromitacją infrastruktury podpisywania ma znaczenie.
Co wydarzyło się w incydencie bezpieczeństwa Binance?
Podejrzana aktywność dotycząca gorących portfeli powiązanych z Binance zaczęła przyciągać uwagę 30 października 2026 roku.
Śledczy on-chain zaobserwowali duże transfery z portfeli powiązanych z giełdą na nowo utworzone adresy. Wczesne szacunki znacznie się różniły, gdy badacze śledzili transakcje w sieciach Ethereum, Bitcoin, Tron i innych.
Binance następnie potwierdziła incydent bezpieczeństwa i rozpoczęła dochodzenie w sprawie źródła nieautoryzowanych transakcji. Giełda tymczasowo zawiesiła depozyty i wypłaty, przeprowadzając kontrole bezpieczeństwa.
W swoim biuletynie bezpieczeństwa z 30 października Binance poinformowała, że jej wstępne dochodzenie sugeruje, iż przejęty laptop inżyniera DevOps pozwolił atakującemu uzyskać dostęp do kontenera usługi i złożyć nieautoryzowane transakcje wypłat.
Giełda oszacowała ogólny wpływ na około 6,3 miliarda dolarów na tym etapie dochodzenia i poinformowała, że około 3 miliardy dolarów dotkniętych aktywów zostało zamrożonych on-chain. Binance oświadczyła również, że pokryje straty ze swojego funduszu SAFU oraz funduszy spółki.
Co najważniejsze dla dyskusji technicznej, Binance stwierdziła:
Nie znalazła dowodów na wyciek klucza prywatnego portfela.
To stwierdzenie zmienia sposób, w jaki należy interpretować zgłoszoną aktywność EIP-7702.
Zamiast pytać wyłącznie, czy atakujący ukradł klucz prywatny gorącego portfela, bardziej istotne staje się pytanie, czy przejęty system wewnętrzny był w stanie zażądać lub ułatwić uzyskanie ważnej autoryzacji z chronionej infrastruktury podpisywania.
Dlaczego EIP-7702 stało się częścią dochodzenia?
EIP-7702 zostało wprowadzone wraz z aktualizacją Ethereum Pectra, aby dać kontom posiadanym zewnętrznie niektóre możliwości zwykle kojarzone z portfelami inteligentnych kontraktów.
Tradycyjnie EOA Ethereum jest kontrolowane przez klucz prywatny. Może podpisywać transakcje, transferować aktywa i wchodzić w interakcje z inteligentnymi kontraktami, ale jego własne konto nie zawiera programowalnej logiki wykonawczej.
EIP-7702 zmienia tę relację.
Pozwala EOA autoryzować kod innego kontraktu do działania jako jego logika wykonawcza, zachowując oryginalny adres Ethereum.
Umożliwia to użyteczne funkcje abstrakcji kont, takie jak grupowanie transakcji, sponsorowanie gazu i bardziej zaawansowane systemy uprawnień.
Oznacza to również, że autoryzacja EIP-7702 zasługuje na znacznie więcej uwagi niż konwencjonalna zgoda na token.
Podczas analizy incydentu Binance badacze poinformowali, że adres zasilony przez Tornado Cash złożył wiele autoryzacji EIP-7702 dotyczących gorącego portfela Ethereum powiązanego z Binance na krótko przed wystąpieniem głównych transferów aktywów.
Jedna autoryzacja podobno odpowiadała stanowi portfela i stała się skuteczna.
Około trzy minuty później znaczne aktywa zaczęły opuszczać portfel.
Czas ten naturalnie uczynił autoryzację ważną częścią dochodzenia.
Nadal nie mówi nam jednak, w jaki sposób uzyskano ważną autoryzację.
Jak działa autoryzacja EIP-7702?
Najłatwiejszym sposobem zrozumienia tego mechanizmu jest wyobrażenie sobie, że EIP-7702 pozwala zwykłemu kontu Ethereum tymczasowo powiedzieć:
„Użyj logiki wykonania tego inteligentnego kontraktu, gdy moje konto otrzymuje wywołania.”
Uproszczony przepływ wygląda następująco:
Ethereum EOA
│
│ Podpisuje autoryzację EIP-7702
▼
Delegacja zostaje przypisana
│
▼
Delegowany inteligentny kontrakt
│
│ Zapewnia wykonywalną logikę
▼
Oryginalne EOA może wykonywać
zachowania w stylu inteligentnego kontraktu
Oryginalne konto nie znika.
Jego adres, salda i istniejąca historia on-chain pozostają nienaruszone. Zmienia się kod, który można wykonać za pośrednictwem tego konta.
EIP-7702 zawiera również zabezpieczenia. Autoryzacje są powiązane ze stanem konta, w tym z nonce, i mogą być zastępowane lub odwoływane. Nie są więc dowolnymi instrukcjami, które ktokolwiek może dołączyć do portfela innej osoby.
Prawidłowa autoryzacja nadal wymaga legalnej kryptograficznej autoryzacji od odpowiedniego konta.
Ten punkt ma kluczowe znaczenie dla zrozumienia incydentu z Binance.
Jeśli atakującemu uda się skutecznie zainstalować złośliwą logikę delegacji, ważne pytanie bezpieczeństwa nie brzmi po prostu:
„Czy atakujący użył EIP-7702?”
Brzmi ono:
„W jaki sposób atakujący uzyskał uprawnienia do utworzenia prawidłowej autoryzacji EIP-7702?”
Dlaczego zgłoszono wiele autoryzacji EIP-7702?
Badacze bezpieczeństwa analizujący transakcje zgłosili, że atakujący przesłał partię zawierającą około 50 autoryzacji powiązanych z różnymi wartościami nonce.
Na pierwszy rzut oka „50 autoryzacji” może brzmieć jak 50 skompromitowanych portfeli.
Niekoniecznie tak się stało.
Konta Ethereum utrzymują nonce, który zmienia się w miarę wykonywania transakcji. Autoryzacja EIP-7702 musi odpowiadać odpowiedniemu stanowi konta.
Jeśli atakujący wie, który portfel chce zaatakować, ale nie może wiarygodnie określić, jaki nonce będzie prawidłowy, gdy transakcja dotrze do sieci, może przygotować autoryzacje dla kilku możliwych wartości nonce.
Powiodłaby się tylko autoryzacja odpowiadająca prawidłowemu stanowi portfela.
Ta technika jest czasami określana jako nonce spraying.
Ważną implikacją jest to, że istnienie 50 wpisów autoryzacji niekoniecznie oznacza 50 udanych uprawnień, 50 skompromitowanych kluczy prywatnych ani 50 oddzielnych ataków na portfele.
Zamiast tego wzorzec mógł zostać zaprojektowany w celu zwiększenia prawdopodobieństwa, że jedna wcześniej uzyskana autoryzacja będzie odpowiadać stanowi docelowego konta w momencie przesłania.
To rodzi kolejne pytanie:
Kto — lub jaki wewnętrzny system — miał uprawnienia do utworzenia bazowego podpisu?
I tu właśnie wstępne ustalenia Binance stają się szczególnie istotne.
Kradzież klucza prywatnego i kompromitacja infrastruktury podpisywania to różne problemy
Wiele dyskusji na temat bezpieczeństwa kryptowalut sprowadza ochronę portfela do jednej zasady:
Chroń klucz prywatny.
To pozostaje niezbędne, ale portfele instytucjonalne są znacznie bardziej skomplikowane.
Giełda może używać modułów bezpieczeństwa sprzętowego, usług podpisywania, silników polityk, usług wypłat, systemów kontroli dostępu i innej infrastruktury wokół bazowego klucza.
Atakujący może zatem próbować skompromitować proces, który żądania podpisu, zamiast wydobywać sam klucz prywatny.
Wstępne dochodzenie Binance wskazuje obecnie znacznie bardziej na drugi scenariusz.
Giełda podała, że skompromitowany laptop DevOps mógł umożliwić dostęp do kontenera usługi zdolnego do przesyłania nieautoryzowanych transakcji wypłat, jednocześnie wyraźnie stwierdzając, że nie znalazła dowodów na wyciek klucza prywatnego.
To rozróżnienie jest istotne.
Klucz prywatny chroniony sprzętowo może technicznie pozostać bezpieczny, podczas gdy otaczająca infrastruktura generuje podpis dla czegoś, co nigdy nie powinno zostać zatwierdzone.
Czy EIP-7702 spowodował hack Binance?
Na podstawie obecnie dostępnych informacji nie ma publicznych dowodów na to, że luka w samym EIP-7702 spowodowała incydent bezpieczeństwa Binance.
To rozróżnienie jest kluczowe.
Atakujący wykorzystujący legalną funkcję protokołu nie oznacza automatycznie, że funkcja ta została złamana.
Rozważmy prostszy przykład.
Jeśli atakujący uzyska legalne dane uwierzytelniające do konta bankowego i zainicjuje przelew za pośrednictwem normalnego systemu płatności banku, fakt, że infrastruktura przelewowa banku zrealizowała płatność, nie dowodzi, że sam protokół przelewu był wadliwy.
Podobne rozróżnienie ma zastosowanie tutaj.
EIP-7702 mógł zapewnić mechanizm wykonawczy, za pośrednictwem którego skutecznie autoryzowane konto mogło delegować swoje zachowanie do złośliwego kodu.
Jednak EIP-7702 normalnie wymaga ważnej autoryzacji.
Nierozstrzygniętym pytaniem jest, w jaki sposób ta autoryzacja stała się możliwa.
Wstępne wyjaśnienie Binance sugeruje, że śledczy badają skompromitowaną infrastrukturę operacyjną, a nie awarię protokołu Ethereum.
Dlatego najdokładniejsza interpretacja na tym etapie jest następująca:
EIP-7702 wydaje się istotny dla badanej ścieżki wykonania, ale nie ustalono, że jest podstawową podatnością.
Co zostało potwierdzone, a co pozostaje przedmiotem dochodzenia?
Ponieważ duże incydenty bezpieczeństwa rozwijają się szybko, rozróżnienie potwierdzonych ustaleń od analizy na poziomie transakcji jest szczególnie ważne.
To rozróżnienie ma znaczenie, ponieważ transakcje blockchain zapewniają doskonałą widoczność tego, co wydarzyło się w łańcuchu, ale niekoniecznie ujawniają, w jaki sposób wewnętrzny system podpisywania został skompromitowany.
Badacze mogą obserwować delegacje, przelewy i interakcje z kontraktami.
Nie mogą jednak ustalić wyłącznie na podstawie danych z blockchain, czy podpis został utworzony po kradzieży klucza prywatnego, czy wewnętrzna usługa legalnie go zażądała, czy też skompromitowany przepływ pracy spowodował, że chroniony podpisujący autoryzował złośliwe instrukcje.
Wymaga to dowodów z wnętrza dotkniętej infrastruktury.
Dlaczego infrastruktura podpisywania ma znaczenie równie duże jak przechowywanie kluczy prywatnych
Instytucjonalne bezpieczeństwo kryptowalut coraz częściej składa się z kilku warstw.
Pierwszą jest bezpieczeństwo kluczy.
Gdzie przechowywany jest klucz prywatny? Czy można go wyodrębnić? Czy jest chroniony przez moduł bezpieczeństwa sprzętowego lub inny kryptograficzny system powierniczy?
Drugą jest bezpieczeństwo podpisywania.
Które usługi mogą żądać podpisów od chronionego klucza? Jakie uwierzytelnianie, zasady i mechanizmy zatwierdzania muszą spełniać te usługi?
Trzecią jest bezpieczeństwo autoryzacji.
Nawet jeśli żądanie jest kryptograficznie ważne, co dokładnie konto jest proszone do autoryzowania?
Ta trzecia warstwa staje się coraz ważniejsza w miarę zwiększania możliwości inteligentnych kont i delegowania kont.
Konwencjonalny transfer tokenów może przenieść stałą kwotę jednego zasobu.
Delegacja może natomiast zmienić sposób, w jaki konto może wykonywać przyszłe instrukcje.
Dla zespołów bezpieczeństwa różnica oznacza, że sama walidacja podpisu nie jest już wystarczająca.
Należy również ocenić znaczenie transakcji.
Dlaczego EIP-7702 zmienia założenia bezpieczeństwa portfeli
EIP-7702 jest potężny właśnie dlatego, że rozszerza to, co może robić zwykłe konto Ethereum.
Portfel może zyskać programowalne funkcje bez migracji aktywów do całkowicie nowego portfela inteligentnego kontraktu.
Dla portfeli konsumenckich może to poprawić użyteczność.
Dla zaawansowanej infrastruktury instytucjonalnej może wspierać bardziej zaawansowane zasady wykonania.
Jednak dodatkowa programowalność tworzy dodatkowe powierzchnie autoryzacji.
Złośliwa zgoda ERC-20 zazwyczaj daje innemu adresowi uprawnienia do jednego tokena.
Złośliwa delegacja EIP-7702 może potencjalnie wpłynąć na sposób, w jaki konto wykonuje znacznie szersze klasy działań.
To nie czyni EIP-7702 z natury niebezpiecznym.
Oznacza to, że portfele, giełdy i dostawcy usług powierniczych powinni traktować autoryzację delegacji jako operację bezpieczeństwa wysokiego ryzyka.
Podpis EIP-7702 nie powinien być oceniany wyłącznie jako kryptograficznie ważny.
Systemy bezpieczeństwa powinny również pytać, czy cel delegacji jest oczekiwany, czy jego kod bajtowy został sprawdzony, czy żądana autoryzacja odpowiada normalnemu zachowaniu konta oraz czy wewnętrzne zasady w ogóle pozwalają temu kontu delegować wykonanie.
Co powinno wyjaśnić post-mortem Binance?
Binance poinformowała, że szczegółowe techniczne post-mortem zostanie opublikowane po zakończeniu jej śledztwa.
Kilka pytań zadecyduje o tym, jak branża ostatecznie zinterpretuje ten incydent.
Po pierwsze, w jaki sposób atakujący uzyskał dostęp do ścieżki podpisywania?
Wstępne wyjaśnienie DevOps wskazuje na potencjalnie skompromitowaną część infrastruktury, ale pełny łańcuch od tego dostępu do ważnej autoryzacji blockchain pozostaje istotny.
Po drugie, jaką dokładnie rolę odegrał EIP-7702?
Śledczy będą musieli ustalić, czy delegacja była wymagana do wykonania przelewów Ethereum, w jaki sposób przygotowano autoryzację i dlaczego mechanizmy kontroli wewnętrznej na to pozwoliły.
Po trzecie, czy klucze prywatne kiedykolwiek zostały ujawnione?
Binance obecnie twierdzi, że nie ma dowodów na wyciek kluczy prywatnych. Pełny raport kryminalistyczny mógłby dostarczyć więcej szczegółów na temat tego, w jaki sposób klucze były odizolowane od skompromitowanej infrastruktury.
Wreszcie, która kontrola powinna była zatrzymać transakcję?
Dla instytucjonalnych zespołów ds. bezpieczeństwa może to być najcenniejsze pytanie ze wszystkich.
Technicznie ważny podpis nie powinien automatycznie oznaczać operacyjnie ważnej transakcji.
Najsilniejsze systemy powiernicze oddzielają autoryzację kryptograficzną od autoryzacji biznesowej.
Co to oznacza dla zwykłych użytkowników portfeli Ethereum?
Incydent w Binance dotyczy infrastruktury instytucjonalnej i nie powinien być automatycznie interpretowany jako dowód, że zwykłe portfele Ethereum są narażone na tę samą ścieżkę ataku.
Osobisty portfel z samodzielnym przechowywaniem i system hot-wallet giełdy działają bardzo różnie.
Jednak EIP-7702 wprowadza ważną lekcję również dla indywidualnych użytkowników:
Podpis delegacji zasługuje na taki sam poziom ostrożności jak inne potężne uprawnienia portfela.
Użytkownicy powinni dokładnie weryfikować, o co portfel prosi ich do podpisania, szczególnie gdy nieznana witryna żąda delegacji konta.
Złośliwej delegacji nie należy mylić ze zwykłym podpisem logowania.
Użytkownicy powinni również polegać na sprawdzonych interfejsach portfeli, które wyraźnie identyfikują żądania delegacji i oznaczają podejrzane kontrakty.
Kluczowa zasada bezpieczeństwa pozostaje prosta: nie oceniaj podpisu tylko po tym, czy natychmiast przenosi środki. Niektóre podpisy zmieniają to, co konto będzie mogło zrobić później.
Większa lekcja: bezpieczeństwo portfeli wykracza poza klucze prywatne
Incydent bezpieczeństwa w Binance podkreśla szerszą ewolucję w bezpieczeństwie blockchain.
Przez lata dominujące założenie branży było proste:
Chroń klucz, chroń portfel.
Ten model staje się niekompletny.
Nowoczesne instytucjonalne portfele często zależą od warstw infrastruktury wokół klucza—API, usług podpisywania, silników wypłat, systemów polityk, kontroli dostępu i zautomatyzowanych środowisk wykonawczych.
Mechanizmy abstrakcji kont, takie jak EIP-7702, dodają kolejną warstwę, pozwalając portfelom delegować logikę wykonawczą.
W rezultacie bezpieczeństwo kryptowalut coraz częściej zależy od trzech odrębnych pytań:
Kto kontroluje klucz?
Kto może zażądać podpisu?
I jakie uprawnienia ten podpis faktycznie przyznaje?
System może odnieść sukces w pierwszym pytaniu, jednocześnie ponosząc porażkę w drugim lub trzecim.
Wydaje się, że jest to jedna z najważniejszych kwestii podniesionych dotychczas przez śledztwo Binance.
FAQ
Czy EIP-7702 było przyczyną hacku Binance?
Niepotwierdzone. Wstępne ustalenia Binance wskazują na skompromitowaną infrastrukturę operacyjną, podczas gdy EIP-7702 wydaje się być częścią badanej ścieżki autoryzacji.
Czy klucze prywatne Binance zostały skradzione?
Binance poinformowała, że w swoim wstępnym śledztwie nie znalazła dowodów na wyciek kluczy prywatnych portfela.
Czym jest EIP-7702?
EIP-7702 pozwala EOA Ethereum delegować logikę wykonawczą do kodu smart-kontraktu, zachowując ten sam adres portfela.
Dlaczego zaobserwowano wiele autoryzacji EIP-7702?
Mogły one zostać przygotowane dla różnych wartości nonce, aby dopasować się do stanu docelowego konta. Nie oznacza to koniecznie, że wiele portfeli zostało skompromitowanych.
Czy zwykli użytkownicy Ethereum są dotknięci?
Nie ma dowodów na kompromitację portfeli Ethereum w całej sieci. Użytkownicy powinni jednak zachować ostrożność wobec nieznanych żądań delegacji lub podpisywania.
Czy cofnięcie zatwierdzeń tokenów wystarczy?
Nie zawsze. Zatwierdzenia ERC-20 i delegacja EIP-7702 to odrębne uprawnienia, więc usunięcie zatwierdzenia tokena nie usuwa automatycznie delegacji konta.
Wnioski
Pojawienie się EIP-7702 w incydencie Binance sprawia, że mechanizm ten staje się ważną częścią dochodzenia technicznego, jednak dostępne dowody nie potwierdzają, że sam EIP-7702 został naruszony.
Wstępne ustalenia Binance sugerują natomiast, że atakujący mógł przejąć laptop inżyniera DevOps, uzyskać dostęp do kontenera usługi operacyjnej i przesłać nieautoryzowane transakcje wypłat. Giełda twierdzi, że nie znalazła dowodów na wyciek kluczy prywatnych portfeli.
To rozróżnienie ma znaczenie.
Jeśli chroniony system podpisywania można nakłonić do autoryzacji złośliwych instrukcji, atakujący mogą w ogóle nie potrzebować kradzieży klucza prywatnego.
EIP-7702 może zwiększyć konsekwencje takiej autoryzacji, ponieważ pozwala kontu Ethereum delegować programowalną logikę wykonawczą. Jednak złośliwe wykorzystanie tej możliwości a znalezienie luki w protokole to dwie różne rzeczy.
Dopóki Binance nie opublikuje pełnego technicznego post-mortem, EIP-7702 najlepiej rozumieć jako element zgłoszonej ścieżki wykonania — a nie jako potwierdzoną główną przyczynę incydentu.
Dla giełd, dostawców usług powierniczych i deweloperów portfeli szersza lekcja jest już jasna: nowoczesne bezpieczeństwo portfeli musi chronić nie tylko klucze prywatne, ale także systemy żądające podpisów i uprawnienia, które te podpisy tworzą.
Zastrzeżenie dotyczące ryzyka: Ten artykuł ma wyłącznie charakter informacyjny i edukacyjny. Kryptowaluty i systemy blockchain wiążą się z ryzykiem technicznym, operacyjnym i rynkowym. Czytelnicy powinni niezależnie weryfikować informacje dotyczące bezpieczeństwa i stosować odpowiednie mechanizmy kontroli ryzyka podczas zarządzania aktywami cyfrowymi.
