RT @dobsec: "Žádný běžný člověk nepoužívá VPN" ukazuje, že zjevně neviděl bajillion tvůrců, kteří nabízejí VPN v každém videu.

BlockThreat - Týden 28, 2025 💙 Sponzorováno společností @SecurityOak 🔥 Masové využívání proxy kontraktů odhalených @deeberiroz a whitehatovaných @pcaversaccio @dedaub a @_SEAL_Org 💸 @GMX_IO hack opětovného přístupu 42 milionů $ (37 milionů $ získáno) 💸 @KintoXYZ neinicializovaný proxy server. 1,55 milionu dolarů

Poučení pro bezpečnostní experty: Auditujte proxy inits důsledně. Monitorujte řetězce hovorů delegátů (snadno to proveďte v naší aplikaci) a zajistěte integritu úložiště pomocí složitých vzorů proxy. Rekvizity jdou na @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Zůstaňte ostražití.

tak jsem zjistila, že je to ještě hezčí. Všiml jsem si, že frontrunning tx (útočníky) volá 'initialize' a protokoly také volají _úspěšně_ 'initialize' poté (takže si myslí, že je vše v pořádku). Ale počkat, jak je to vůbec možné? Musel jsem se podívat velmi hluboko na změny slotu úložiště a odhadnout, co jsem našel: _resetovali_ hodnotu slotu úložiště '_initialized' na konci frontrunning tx (poté, co přešli na škodlivý implementační kontrakt). To znamená, že úložiště proxy nyní vypadá tak, jak nebylo nikdy inicializováno. Relevantní slot pro úložiště, na který se musíte podívat, je 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' To je zlo další úrovně.

Začátkem tohoto týdne byla identifikována potenciální zranitelnost ve smlouvě Orderlyho cross-chain manager na BNB chainu. V reakci na to byl náš BNB trezor pro vklady a výběry okamžitě pozastaven, smlouvy byly migrovány a vklady/výběry byly obnoveny do 2 hodin. ✅ Žádné prostředky uživatelů nejsou ohroženy nebo byly ztraceny. Zvláštní poděkování patří @deeberiroz, @VennBuild, @seal_911, @pcaversaccio a zbytku týmu, kteří pomohli tuto událost nahlásit! Společně 🤝 bezpečněji

[5/5] Poděkování • @SlowMist_Team za nepřetržité třídění a záplatování • @dedaub, @pcaversaccio a @seal_911 válečná místnost za 36hodinovou kontrolu kódu • @etherscan za bleskurychlé vyčištění uživatelského rozhraní • A ještě jednou, děkuji vám @deeberiroz, @VennBuild, @davidberiro – vaše hlavy vzhůru zachránily situaci 💙.

Je to ještě úžasnější: způsob, jakým byl Etherscan oklamán a ukázal nesprávnou implementační smlouvu, je založen na nastavení 2 různých slotů proxy ve stejném frontrunning tx. Etherscan tedy používá určitou heuristiku, která zahrnuje různé úložné sloty k načtení implementační smlouvy. Existuje starý proxy server od OpenZeppelin, který používal následující slot: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Nyní máme také standardní slot EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Stalo se tedy, že do starého proxy slotu OpenZeppelin byl zapsán s neškodnou implementační adresou _a_ do standardního slotu EIP-1967 se zapsalo také se škodlivou implementační adresou. Vzhledem k tomu, že se Etherscan nejprve dotazuje na starý slot proxy, načetl nejprve neškodně vypadající slot a tak jej zobrazil.

RT @devops199fan: .@seal_911 v podstatě slouží jako dobrovolné globální bezpečnostní operační centrum (GSOC) kryptoměny Máme štěstí, že máme lidi rádi ...

Nevím, člověče, ale skutečnou hrozbou pro Ethereum ve skutečnosti není stát (alespoň ne dnes). Jsou to VC a protokolární kariéristé, kteří se to snaží vykastrovat na nablýskané fintech hřiště pro "bezpečné", vyhovující DeFi. Poslouchejte mě: Nechtějí nezastavitelný kód. Nechtějí odpor. Chtějí kontrolu. Protože v hloubi duše vědí, čím by se Ethereum mohlo stát, kdyby zůstalo nespoutané: globální popravčí vrstvou odolnou vůči cenzuře a na prvním místě soukromí, kterou by žádný stát, žádná korporace, žádný kartel obleků nikdy kurva nezastavil. Pojďme to uskutečnit.

Někdo vás tedy kontaktuje na LinkedIn se slibnou pracovní příležitostí. Zní to hezky, ne? Vypadají důvěryhodně (po jejich kontrole po dobu 1 minuty) a po krátkém rozhovoru vám pošlou repozitář GitHub s jednoduchým Next.js "náborovým úkolem". Naklonujete to, spustíte... A o 10 minut později je vaše zařízení plně ohroženo, protože zjistíte, že vaše horké peněženky byly vyčerpány. Dobře, co se stalo? Vzhledem k tomu, že jsme (= SEAL 911) viděli tento útok znovu a znovu, dovolte mi prozradit některé z nejdůležitějších detailů: - za prvé, nejdůležitější upozornění: NESPOUŠTĚJTE náhodný kód, který vám poslal nějaký náhodný týpek. Upřímně, kurva ne. - Vždy důkladně zkontrolujte konfigurační soubory _executable_ v úložištích. V tomto konkrétním případě měl soubor 'next.config.js' velké odsazení, které skrývalo škodlivý náklad daleko vpravo. - Vždy posouvejte vodorovně – to, že při pohledu na obsah nevidíte nic škodlivého, neznamená, že je čistý. Důležité: Škodlivý kód se může skrývat v souborech, kterým důvěřujete, ale ne tam, kde byste ho očekávali. Opravdu doufám, že se tento tweet dostane k dostatečnému počtu lidí, aby se zabránilo alespoň několika budoucím obětem, aby se staly obětí tohoto druhu útoku.