RT @dobsec: "Żaden zwykły człowiek nie używa VPN" pokazuje, że wyraźnie nie widział miliona twórców reklamujących VPN w każdym filmie.

BlockThreat - Tydzień 28, 2025 💙 Sponsorowane przez @SecurityOak 🔥 Odkryto masowe wykorzystanie kontraktów proxy przez @deeberiroz, a białe kapelusze to @pcaversaccio @dedaub i @_SEAL_Org 💸 Hakerstwo reentrancy @GMX_IO $42M ($37M odzyskane) 💸 @KintoXYZ nieinicjalizowany proxy. $1.55M

Lekcje dla ekspertów ds. bezpieczeństwa: Rigorystycznie audytuj inicjalizacje proxy. Monitoruj łańcuchy delegatecall (łatwe do zrobienia w naszej aplikacji) i zapewnij integralność pamięci przy użyciu złożonych wzorców proxy. Słowa uznania dla @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Bądź czujny.

Więc odkryłem, że to jest jeszcze bardziej wyrafinowane. Zauważyłem, że transakcja frontrunningowa (przez atakujących) wywołuje `initialize`, a protokoły również wywołują _pomyślnie_ `initialize` później (więc myślą, że wszystko jest w porządku). Ale chwila, jak to w ogóle możliwe? Musiałem bardzo dokładnie przyjrzeć się zmianom w slotach pamięci i zgadnij, co znalazłem: _zresetowali_ wartość slotu pamięci `_initialized` na końcu transakcji frontrunningowej (po tym, jak przeszli do złośliwej umowy implementacyjnej). To oznacza, że pamięć proxy wygląda teraz tak, jakby nigdy nie była inicjowana. Odpowiedni slot pamięci, na który należy zwrócić uwagę, to `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` To jest poziom zła.

Na początku tego tygodnia zidentyfikowano potencjalną lukę w kontrakcie menedżera cross-chain Orderly na łańcuchu BNB. W odpowiedzi nasz skarbiec BNB do wpłat i wypłat został natychmiast wstrzymany, kontrakty zostały przeniesione, a wpłaty/wypłaty wznowiono w ciągu 2 godzin. ✅ Żadne środki użytkowników nie są zagrożone ani nie zostały utracone. Szczególne podziękowania dla @deeberiroz, @VennBuild, @seal_911, @pcaversaccio oraz reszty zespołu, którzy pomogli to zgłosić! Razem bezpieczniej 🤝

[5/5] Lista wdzięczności • @SlowMist_Team za nieprzerwaną triage i łatanie • @dedaub, @pcaversaccio i @seal_911 w centrum dowodzenia za 36-godzinne przeszukiwanie kodu • @etherscan za błyskawiczne czyszczenie UI • I jeszcze raz, dziękuję @deeberiroz, @VennBuild, @davidberiro—wasze ostrzeżenie uratowało sytuację 💙

To staje się jeszcze bardziej wyszukane: sposób, w jaki Etherscan został oszukany, aby pokazać niewłaściwy kontrakt implementacji, opiera się na ustawieniu 2 różnych slotów proxy w tej samej transakcji frontrunning. Etherscan używa pewnej heurystyki, która uwzględnia różne sloty pamięci, aby pobrać kontrakt implementacji. Istnieje stary proxy od OpenZeppelin, który używał następującego slotu: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Mamy teraz również standardowy slot EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Co się stało, to to, że stary slot proxy OpenZeppelin został zapisany z benignym adresem implementacji _i_ standardowy slot EIP-1967 również został zapisany z złośliwym adresem implementacji. Ponieważ Etherscan najpierw zapytuje o stary slot proxy, najpierw pobrał ten wyglądający na nieszkodliwy i w ten sposób go wyświetlił.

RT @devops199fan: .@seal_911 zasadniczo pełni rolę wolontariackiego globalnego centrum operacji bezpieczeństwa w kryptowalutach (GSOC) mamy szczęście, że są tacy ludzie jak...

Nie wiem, człowieku, ale prawdziwe zagrożenie dla Ethereum nie pochodzi od państwa (przynajmniej nie dzisiaj). To VC i karierowicze protokołów próbujący osłabić je w błyszczący plac zabaw fintech dla "bezpiecznego", zgodnego DeFi. Posłuchaj mnie: oni nie chcą niepowstrzymanego kodu. Nie chcą oporu. Chcą pierdolonej _kontroli_. Bo głęboko w sobie wiedzą, czym Ethereum mogłoby się stać, gdyby zostało uwolnione: warstwą wykonawczą odporną na cenzurę, z priorytetem na prywatność, której żadne państwo, żadna korporacja, żaden kartel garniturów nigdy nie mogłoby zatrzymać. Sprawmy, aby to stało się rzeczywistością.

Więc ktoś kontaktuje się z tobą na LinkedIn z obiecującą ofertą pracy. Brzmi dobrze, prawda? Wydają się legitni (po sprawdzeniu ich przez 1 minutę) i po krótkiej rozmowie wysyłają ci repozytorium GitHub z prostym "zadaniem rekrutacyjnym" w Next.js. Klonujesz je, uruchamiasz... a 10 minut później, twoje urządzenie jest całkowicie skompromitowane, gdy odkrywasz, że twoje gorące portfele zostały opróżnione. Dobrze, co się stało? Biorąc pod uwagę fakt, że my (= SEAL 911) widzieliśmy ten atak wielokrotnie, pozwól, że ujawnię kilka najważniejszych szczegółów: - po pierwsze, najważniejsze zastrzeżenie: nie uruchamiaj losowego kodu, który wysłał ci jakiś przypadkowy gość. Szczerze, nie rób tego. - zawsze dokładnie sprawdzaj _wykonywalne_ pliki konfiguracyjne repozytoriów. W tym konkretnym przypadku plik `next.config.js` miał dużą przestrzeń, która ukrywała złośliwy ładunek daleko na prawo. - zawsze przewijaj poziomo - to, że nie widzisz nic złośliwego, gdy patrzysz na zawartość, nie oznacza, że jest czysta. Ważne: Złośliwy kod może być ukryty w plikach, którym ufasz, tylko nie tam, gdzie się go spodziewasz. Naprawdę mam nadzieję, że ten tweet dotrze do wystarczającej liczby osób, aby zapobiec przynajmniej kilku przyszłym ofiarom wpadnięcia w ten rodzaj ataku.