RT @dobsec: "Ни один обычный человек не использует VPN" показывает, что он явно не видел миллиарды создателей, рекламирующих VPN в каждом видео.

BlockThreat - Неделя 28, 2025 💙 Спонсор @SecurityOak 🔥 Массовая эксплуатация прокси-контрактов, обнаруженная @deeberiroz и белыми хакерами @pcaversaccio @dedaub и @_SEAL_Org 💸 Хак @GMX_IO с повторным входом на $42M ($37M восстановлено) 💸 @KintoXYZ неинициализированный прокси. $1.55M

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

Я обнаружил, что это еще более изощренно. Я заметил, что транзакция фронтраннинга (со стороны атакующих) вызывает `initialize`, и протоколы также _успешно_ вызывают `initialize` после этого (поэтому они думают, что все в порядке). Но подождите, как это вообще возможно? Мне пришлось глубоко изучить изменения в слотах хранения, и угадайте, что я нашел: они _сбрасывают_ значение слота хранения `_initialized` в конце транзакции фронтраннинга (после того, как они переключились на контракт злонамеренной реализации). Это означает, что хранилище прокси теперь выглядит так, как будто оно никогда не было инициализировано. Соответствующий слот хранения, на который стоит обратить внимание, это `keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))` = `0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00` Это зло на следующем уровне.

На этой неделе была выявлена потенциальная уязвимость в контракте менеджера кросс-цепи Orderly на цепи BNB. В ответ наш BNB-кошелек для депозитов и выводов был немедленно приостановлен, контракты были мигрированы, и депозиты/выводы возобновились в течение 2 часов. ✅ Ни один пользовательский фонд не находится под угрозой и не был потерян. Особая благодарность @deeberiroz, @VennBuild, @seal_911, @pcaversaccio и остальной команде, которые помогли выявить это! Безопаснее вместе 🤝

[5/5] Список благодарностей • @SlowMist_Team за непрерывную работу по устранению неполадок и патчинг • @dedaub, @pcaversaccio и @seal_911 в военной комнате за 36-часовую проверку кода • @etherscan за молниеносную очистку интерфейса • И снова спасибо @deeberiroz, @VennBuild, @davidberiro — ваш сигнал спас день 💙

Ситуация становится еще более интересной: способ, которым Etherscan был обманут, показывая неправильный контракт реализации, основан на установке 2 различных прокси-слотов в одной транзакции фронтраннинга. Таким образом, 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) видели эту атаку снова и снова, позвольте мне раскрыть некоторые из самых важных деталей: - во-первых, самое важное предостережение: не запускайте случайный код, который вам прислал какой-то случайный человек. Честно, черт возьми, не делайте этого. - всегда тщательно проверяйте _исполняемые_ конфигурационные файлы репозиториев. В данном конкретном случае файл `next.config.js` имел большую подложку, скрывающую вредоносный код далеко вправо. - всегда прокручивайте горизонтально - просто потому, что вы не видите ничего вредоносного, когда смотрите на содержимое, не означает, что оно чистое. Важно: Вредоносный код может быть скрыт в файлах, которым вы доверяете, просто не там, где вы его ожидаете. Я действительно надеюсь, что этот твит достигнет достаточного количества людей, чтобы предотвратить хотя бы несколько будущих жертв от того, чтобы стать жертвами этой атаки.