RT @dobsec: «Жодна звичайна людина не використовує VPN» показує, що він явно не бачив, щоб творці bajillion використовували VPN у кожному відео.

BlockThreat - Тиждень 28, 2025 💙 За підтримки @SecurityOak 🔥 Масове використання проксі-контрактів, виявлених @deeberiroz і відкинутих @pcaversaccio @dedaub і @_SEAL_Org 💸 @GMX_IO хак на повторне входження склав $42 млн (відновлено $37 млн) 💸 @KintoXYZ неініціалізований проксі. $ 1.55 МІЛЬЙОН

Уроки для експертів з безпеки: Аудит проксі впроваджується суворо. Контролюйте ланцюжки делегатів (легко це зробити в нашому додатку) і забезпечуйте цілісність сховища за допомогою складних шаблонів проксі. Реквізит йде в @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Будьте пильні.

Тому я з'ясувала, що це ще вишуканіше. Я помітив, що передній tx (зловмисники) викликає 'initialize', а протоколи також викликають _successfully_ 'initialize' після (таким чином вони думають, що все нормально). Але стривайте, як таке взагалі можливо? Мені довелося дуже глибоко заглянути в зміни слотів сховища і здогадатися, що я знайшов: вони _скинули_ значення слота сховища '_initialized' в кінці frontrunning tx (після того, як вони перейшли на шкідливий контракт на реалізацію). Це означає, що проксі-сховище тепер виглядає так, ніби воно ніколи не було ініціалізоване. Відповідний слот для зберігання, на який варто звернути увагу: 'keccak256(abi.encode(uint256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' Це зло наступного рівня.

Раніше на цьому тижні була виявлена потенційна вразливість в контракті крос-чейн менеджера Orderly на BNB chain. У відповідь наше сховище BNB для депозитів та зняття коштів було негайно призупинено, контракти перенесено, а депозити/зняття коштів відновилися протягом 2 годин. ✅ Жодні кошти користувачів не перебувають під загрозою, або були втрачені. Особлива подяка @deeberiroz, @VennBuild, @seal_911, @pcaversaccio та решті команди, хто допоміг відзначити це! Разом 🤝 безпечніше

[5/5] Перекличка подяки • @SlowMist_Team за безперервне сортування та виправлення • @dedaub, @pcaversaccio та @seal_911 war-room за 36-годинну зачистку коду • @etherscan за блискавичне очищення інтерфейсу • І ще раз дякую вам @deeberiroz, @VennBuild, @davidberiro — ваші хедз-ап врятували ситуацію 💙

Це стає ще більш вигадливим: спосіб, яким Etherscan був обдурений, показавши неправильний контракт на впровадження, заснований на налаштуванні 2 різних проксі-слотів в одному передньому TX. Таким чином, Etherscan використовує певну евристику, яка включає різні слоти для зберігання для отримання контракту на реалізацію. Існує старий проксі від OpenZeppelin, який використовував наступний слот: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Тепер ми також маємо стандартний слот EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Отже, сталося те, що старий проксі-слот OpenZeppelin був записаний з доброякісною адресою реалізації _і_ стандартний слот EIP-1967 також був записаний з адресою шкідливої реалізації. Оскільки Etherscan спочатку запитує старий проксі-слот, він спочатку витягує той, що виглядає доброякісно, і таким чином відображає його.

RT @devops199fan: .@seal_911 в основному виступає в якості добровільного Глобального операційного центру безпеки криптовалют (GSOC) Нам пощастило, що людям подобається...

Ідк, але справжня загроза для Ethereum полягає не в державі насправді (принаймні не сьогодні). Це венчурні капіталісти та кар'єристи протоколів, які намагаються перетворити його на блискучий фінтех-майданчик для «безпечного», сумісного DeFi. Вислухайте мене: вони не хочуть нестримного коду. Вони не хочуть опору. Вони хочуть до біса _контроль_. Тому що в глибині душі вони знають, чим може стати Ethereum, якщо його залишити без ланцюга: стійкий до цензури, глобальний рівень виконання, який не зможе зупинити жодна держава, жодна корпорація, жоден картель позовів. Давайте зробимо це реальністю.

Тож хтось зв'язується з вами в LinkedIn з перспективною можливістю працевлаштування. Звучить приємно, інніт? Вони здаються законними (після перевірки протягом 1 хв) і після короткого конвою вони надсилають вам репозиторій GitHub з простим Next.js "завдання з рекрутингу". Ти його клонуєш, запускаєш... А через 10 хвилин ваш пристрій буде повністю скомпрометовано, оскільки ви дізнаєтеся, що ваші гарячі гаманці були розряджені. Гаразд, що сталося? Враховуючи той факт, що ми (= SEAL 911) бачили цю атаку знову і знову, дозвольте мені розкрити деякі з найважливіших деталей: - перше, найголовніше застереження: НЕ запускайте випадковий код, який вам надіслав якийсь випадковий чувак. Чесно кажучи, бл*дь, не треба. - Завжди ретельно перевіряйте файли конфігурації _executable_ репозиторіїв. У цьому конкретному випадку файл «next.config.js» мав велику відбивку, яка приховувала шкідливе корисне навантаження набагато правіше. - Завжди прокручуйте горизонтально - те, що ви не бачите нічого шкідливого, коли дивитеся на контент, не означає, що він чистий. Важливо: шкідливий код може ховатися у файлах, яким ви довіряєте, але не там, де ви його очікуєте. Я дуже сподіваюся, що цей твіт дійде до достатньої кількості людей, щоб запобігти хоча б кільком майбутнім жертвам, які попадуться на такого роду атаки.