Noobing Security Research

Анализируем взлом в реальном времени вместе с AI

Безопасность в web3 не ограничивается аудитом кода, это всем известно (хотя и не всеми принимается всерьез). И для аудита кода уже существует несколько десятков скиллов, которые, например, можно посмотреть тут, хотя даже этот список не покрывает все кейсы

Один из секторов безопасности - это реагирование на взлом, который происходит здесь и сейчас. Сегодня расскажу про инструмент, который позволяет проанализировать взлом максимально быстро и вести мониторинг активности кошельков хакеров

Знакомьтесь - Herd Agent
Это ни что иное как MCP-сервер, который вы можете установить в свой Claude Code/Cursor/Codex/etc. Он может проанализировать контракт, деплой, роли, отдельные транзакции, кошельки и записывать результаты

Я наткнулся на него в блоге Crypto Data Bytes, который уже добавлен в мой список источников

В своем посте Andrew Hong рассказывает о том, что когда он увидел транзакцию с минтом 50кк$ в недавнем взломе USR, то через Herd Agent запустил анализ транзакции и достаточно быстро получил структурированный анализ произошедшего. Взлом был связан с компрометацией приватных ключей, что сложно назвать чем-то из ряда вон, но в любом случае инструмент показал свою полезность для первичного анализа + с помощью команды /loop он настроил мониторинг адреса взломщиков, а результатом стал этот gist файл

Экономия времени - часы. Считаю кайф

Источники:
- Пост на Crypto Data Bytes

https://t.me/web3securityresearch

Детектирование CPIMP атак

Вот здесь был пост про CPIMP атаки, когда скрытно компрометируется прокси контракт

Особенность такого вида атак в том числе состоит в том, что их достаточно сложно детектировать, потому что атака специально разработана для скрытного присутствия

Но обнаружить её всё же можно, в этом нам помогут
1. Анализ логов транзакции деплоя. Двойной event Upgraded является признаком CPIMP. Само событие - стандарт для прокси-контрактов, но в норме оно одно.
2. Глубокая трассировка вызовов. Сначала основной прокси вызывает контракт CPIMP, который выполняет свою вредоносную логику, а затем делает второй delegatecall к оригинальному контракту реализации. Это отображается как двойной delegatecall
3. Проверка подмены слотов хранения. Хакеры используют spoofing для обмана блокчейн-сканеров, так что при взгляде на контракт в сканере не видно ничего подозрительного. Так что необходимо вручную считывать содержимое всех критических слотов через eth_getStorageAt и сравнивать их с ожидаемыми значениями.
4. Верификация байткода и хеш-сумм. CPIMP может мимикрировать под ABI легитимного контракта, простой проверки функций недостаточно. Лучше получить сырой байткод по адресу, указанному в слоте реализации EIP-1967, и сравнить его хеш с хешем байткода заведомо чистого контракта реализации.
5. Анализ на устойчивость к обновлениям. Особенность атаки заключается в том, что вредоносный контракт перезаписывает адрес реализации в конце каждой транзакции. Вредоносный код использует функцию, которая выполняет операцию SSTORE в критический слот реализации. Для того, чтобы увидеть это, необходимо отслеживать изменения в слоте реализации в рамках одной транзакции. Если в начале транзакции слот указывает на один адрес, а в конце принудительно возвращается к адресу CPIMP, это явный признак persistence-логики (логики, направленной на удержание контроля)

Так же существуют диагностические инструменты, такие как Watchdog от компании Dedaub, которые способны выявить подозрительные контракты

Источники
- Пост в блоге Dedaub
- Пост от Halburn
- Пост от Nevermind

https://t.me/web3securityresearch

Formal Verification, часть 7.2
про _safeTransfer()

Что я имею в виду. Полный стек вызова выглядит так:

Staking._stake()
    │
    ▼
SafeERC20.safeTransferFrom()  ← CVL summary перехватывает ЗДЕСЬ
    │                            
    ✗                            
SafeERC20._safeTransferFrom() ← никогда не достигается
    ✗
assembly call                  ← никогда не достигается
    ✗
Token.transferFrom()           ← никогда не достигается

4. Решением стало проводить суммаризацию на уровне SafeERC20.safeTransferFrom(), до появления assembly блока, что позволило корректно менять состояние ghost переменной

Как обычно, теперь, оглядываясь назад, кажется, что это достаточно очевидные вещи, но это конечно не так, учитывая сколько времени я потратил на то, чтобы во всем этом разобраться. Естественно, что для погружения в эти дебри я использовал всю известную мне мощь нейронок, включая NotebookLM и Claude, это сильно помогло, но еще раз доказало насколько тяжело языковым моделям в новых областях знаний

https://t.me/web3securityresearch

Formal Verification, часть 7.1
про _safeTransfer()

На прошлой неделе я участвовал в коротком аудит контесте, который решил "взять" с помощью формальной верификации

Спойлер: я ничего не нашел, но зато вернулся к ФВ и мне есть чем поделиться

Речь сегодня пойдет про поведение SMT-solver при контакте с assembly блоками кода. Я не нашел статей на эту тему, Claude не нашел статей на эту тему, возможно плохо искали, есть вероятность, что их нет, тк тема достаточно узкоспециальная. В этой статье я хочу изложить последовательное решение задачи, включая части, не давшие результата, но важные для понимания. Для тех, кто занимается ФВ постоянно и давно многие вещи должны быть известны, для всех остальных будет полезно.

В июле 2025 OpenZeppellin обновили код SafeERC20 так, что теперь _safeTransfer(), _safeTransferFrom(), _safeApprove() используют низкоуровневые вызовы через assembly. Так что речь идет о пятой версии контрактов, OZ v5

Для формальной верификации это существенное изменение, потому что происходящее в блоке assembly для SMT-solver'a фактически является слепой зоной. Когда солвер не может определить последствий вызова какой либо функции внешнего контракта, он применяет HAVOC_ECF - havoc external contract fields (подстановка случайных значений во все storage слоты). В моем случае, когда Stacking контракт обращался к контракту Token, это приводило к полной перезаписи всей информации в Token -> консистентность нарушена, проверка не работает

Более того, поскольку вызов внутри SafeERC20 не может быть отслежен, то Prover видел его как [?].[?], то есть неизвестно ни к кому обращается вызов, ни к какой функции

1. Было решено применить DISPATCHER(true), который позволяет явно указать на реализации, которые ожидаемо должны быть вызваны.

function _.transfer(address, uint256) external => DISPATCHER(true);
function _.transferFrom(address, address, uint256) external => DISPATCHER(true);

В случае OZ v5 важно понимать, что сам по себе диспетчер не вызывает тело функции, он проверяет, что функция по "адресу" существует, что её вызов не вызывает revert, а в ответ возвращает произвольное значение, которое НЕ записывается в storage. Это называется режимом подмены, он используется, если sighash (селектор функции) недоступен. Если же sighash доступен, то возвращаемое значение запишется в storage
Итог: [?].[?] сменилось на [Token.transferFrom]/, но это не помогло, потому что дальше вызов все равно идет из assembly блока -> HAVOC -> нарушение маппинга балансов токена

2. Попробовал конкретизировать место возникновения с помощью unresolver external in Staking (неопределенные вызовы из контракта стейкинга), DISPATCH должен был эти вызовы сопоставить с конкретными методами контракта Token и возвращаемое значение поменял на NONDET, т.е. любое произвольное. Это должно было ограничить HAVOC токена,

unresolved external in Staking._ => DISPATCH [
    Token.transfer, 
    Token.transferFrom
] default NONDET

Это в какой-то мере сработало, система перестала погружаться в хаос, но NONDET значения тоже не записываются в storage, потому что NONDET тоже работает в режиме подмены, если неизвестен sighash. DISPATCH находил функцию, но unresolved external заставляет Prover оценивать функции внутри как view-only.
Поэтому внутренний маппинг стейкинга увеличивался, а вот баланс контракта стейкинга в контракте токена не обновлялся -> ложное нарушение инварианта

3. Следующим шагом я решил отслеживать изменения балансов ghost переменной, чтобы обойти view-only ограничение + прописать явную суммаризацию. План надежный, как швейцарские часы:
- создаем ghost переменную ghostBalance
- меняем её через специально написанную функцию tokenTransferFromSummary()
- tokenTransferFromSummary() через блок methods привязывается к Token.transferFrom()

Но оказалось, что при входе в unresolved external происходит перехват вызова на уровне опкода CALL раньше, чем применяется суммаризация метода.

https://t.me/web3securityresearch

Пришло время поговорить про Proxy

Атаки на прокси в этом году замыкают TOP 10 OWASP, при этом являясь новинкой сезона. Какие-то уязвимости попроще, например использование коллизии storage, какие-то достаточно изощренные, как CPIMP, про который я писал ранее

В любом случае, для дальнейшего разбора хорошо иметь обзорный пост про виды прокси, без глубокого погружения в то, как именно они функционируют

Смарт-контракты по своей природе неизменяемы, поэтому их код нельзя обновить после деплоя. Прокси позволяют обойти это ограничение, давая возможность обновлять логику, сохраняя при этом тот же адрес контракта и все накопленные данные. Они работают за счет разделения контракта на две части: хранилище/прокси (Storage/Proxy Contract) и логику/имплементацию (Implementation/Logic Contract)

Существуют 5 видов прокси-схем:

1) Clones/Minimal Proxy, они же ERC-1167. Самая минималистичная и простая версия прокси. Необновляемые контракты, где адрес имплементации вшит в байткод контракта, а еще вшита логика DELEGATECALL и возврат результата. И это в общем-то всё содержимое клона, 45 байт совершенства. Стандарт существует в виде библиотеки, суть в том, чтобы выпускать множество клонов контрактом Фабрикой (Factory). Пользователь -> клон -> имплементация
2) Transparent Proxy Pattern (TPP). Схема простая: пользователь отправляет запрос на прокси контракт, а тот делает переадресацию на текущую имплементацию. Здесь код последней на данный момент версии от OZ, существует в виде контракта. Рекомендуется делать так, чтобы владельцем прокси контракта был контракт ProxyAdmin, а не EOA. При каждом вызове прокси проверяет, является ли вызывающий админом, а это стоит 2100 газа. Администратор не имеет права вызывать бизнес-логику. Обновление имплементации контролируется прокси контрактом. Пользователь -> прокси -> имплементация
3) Universal Upgradeable Proxy Standard (UUPS). Ровно та же схема пользователь -> прокси -> имплементация, но функционал обновления имплементации находится в самой имплементации, отсутствие необходимости проверки администратора при каждом вызове экономит газ. Каждая новая имплементация обязана содержать функцию upgradeTo(). Стандарт существует в виде абстрактного контракта
4) Beacon Proxy. Пользователь обращается к своему beacon proxy, тот посылает запрос на Маяк (UpgradeableBeacon), который хранит адрес имплементации, то есть получается пользователь -> Beacon Proxy -> UpgradeableBeacon -> имплементация. Этот промежуточный Маяк позволяет обновлять адрес имплементации для множества пользователей одновременно
5) Diamond proxy. Стандарт EIP-2535. Единственный в списке без реализации от OpenZeppellin. Придуман как решение обхода ограничения размера контракта, по сути служит другим целям нежели остальные, является сложным и нишевым (как будто остальные просты). Суть в том, что прокси контракт перенаправляет вызовы в зависимости от приходящего селектора функции, то есть фактически один большой контракт разбивается на модули и увязывается с помощью прокси-оркестратора. Позволяет менять логику частично. В ноябре 2025 выходил гайд от QuickNode.

- Clones и Beacon используются для связи один ко многим
- Transparent и UUPS используются для связи один к одному
- Transparent и UUPS наследуются от ERC1967Proxy
- Beacon и ERC1967Proxy наследуется от Proxy
- Beacon при этом использует библиотеку ERC1967Utils, как и ERC1967Proxy
- Proxy просто кайфует

Стандарт EIP1967 отвечает за хранение адреса имплементации и другой прокси специфичной информации

Ставь лайк, если стало немного понятнее кто есть кто

https://t.me/web3securityresearch

Вы подделываете подписи, не так ли?
Уязвимости класса Signature Replay Vulnerabilities, SVR

Сегодня обзорный пост на виды уязвимостей, использующих подделку/повторное использование подписи

В ноябре 2025 вышла статья "One Signature, Multiple Payments: Demystifying and Detecting
Signature Replay Vulnerabilities in Smart Contracts" от коллектива авторов из Китая. Статья достаточно короткая, но любопытная

В ней авторы приводят классификацию уязвимостей, связанных с подписями, а так же презентуют свой аналитический инструмент на основе LLM, получивший название LASiR и демонстрирующий впечатляющие результаты. Я сегодня сосредоточусь на классификации

Всего выделяют 5 видов уязвимостей:

1. Межсетевая атака повторного воспроизведения (Cross-chain Replay Attack, X-CRA).
Возникает из-за отсутствия проверки идентификатора блокчейна (Blockchain ID) в сообщении подписи. Это позволяет атакующему взять валидную подпись из одной сети и использовать её для авторизации той же операции в другой сети, если там развернут аналогичный контракт. Это ведет к несанкционированному списанию активов сразу в нескольких сетях

2. Межпроектная атака повторного воспроизведения (Cross-project Replay Attack, X-PRA).
Если в подписи не проверяется адрес самого контракта (address(this)), подпись, созданная для одного проекта, может быть повторно использована в другом проекте с тем же кодом или в форке оригинального проекта

3. Повторное использование подписи контрактного аккаунта (Contract Account Signature Replay, CASR): Эта уязвимость касается подписей, созданных смарт-контрактами (стандарт EIP-1271). Если при проверке не контролируется адрес конкретного контрактного аккаунта, одна и та же подпись может быть валидирована разными аккаунтами одного и того же владельца. Это создает риск потери активов из-за возможности манипулирования несколькими идентичностями

4. Проблемы управления состоянием подписи (Signature State Management Issue, SSMI).
Возникает, когда в контракте отсутствует механизм отслеживания того, была ли подпись уже использована, следить можно через nonce или реестр использованных хешей. В результате злоумышленник может отправить одну и ту же транзакцию многократно

5. Атака на пластичность подписи (Signature Malleability Attack, SMA).
Алгоритм ECDSA позволяет изменять параметры подписи (v, r, s) таким образом, что получается новая валидная подпись для того же самого сообщения. Если контракт не ограничивает диапазоны этих значений, злоумышленник может создать «двойника» подписи и обойти защиту от повторного использования, даже если в контракте есть проверка хеша оригинальной подписи

Да, этот вид атак не входит в топ 10, но как по мне, то это значит только то, что на них могут обращать меньше внимания.

При этом X-CRA и X-PRA виды неактуальны, если ваш контракт развернут в одной сети и у него нет форков. Если вы используете ESDCA от OpenZeppellin, то получаете защиту от SMA "из коробки"

А вот избежать SSMI и CASR поможет только внимательная реализация

Важно понимать, что атаки SRV класса актуальны для любых смарт-контрактов, где используется подпись для верификации полномочий, а это, например:
- Кроссчейн бриджи
- Мультисиги
- NFT + вайтлисты
- Форки проектов
- Распределение наград

https://t.me/web3securityresearch

Как округлить 1.5 до 1 и потерять 9.57кк$, история взлома zkLend

В этом году в ТОП 10 уязвимостей в смарт контрактах вошли Arithmetic Errors и Proxy & Upgradability Vulnerabilities. Про атаку на прокси уже был написан пост, сегодня разберем уязвимость класса арифметической ошибки

Что случилось
В начале 2025 года был взломан zkLend, развернутый в сети Starknet. В перспективе это привело к закрытию проекта

Немного деталей о проекте
zkLend позволял давать и брать в долг активы, то есть это набор lending / borrowing операций. После внесения активов пользователю выдавалась обёртка, например wstEth -> zwstEth. Эти zTokens являются nonrebase transferable токенами. То есть количество токенов на кошельке не меняется, но растет их стоимость по мере того, как протокол получает доход. Чтобы вычислять актуальную стоимость активов пользователя используется формула:

collateral_balance = lending_accumulator × raw_balance

где
- collateral_balance - рыночная стоимость активов
- raw_balance - количество zTokens пользователя
- lending_accumulator - множитель, через который проходит распределение прибыли протокола

Еще zkLend позволял брать flash loans. Это краткосрочный займ, который надо вернуть в конце транзакции. Если не вернуть, то транзакция откатывается, если возвращаешь, то надо доплатить комиссию за пользование. Но в версии zkLend был еще и donation механизм. Он позволял отправить вместе с возвратом flash loan некоторую сумму. Эта сумма считывается как доход протокола и обновляет lending_accumulator. Выглядит формула обновления так:

new_accumulator = (reserve_balance + totaldebt - amount_to_treasury) / ztoken_supply

где
- reserve_balance - общая сумма базового токена в контракте
- totaldebt - совокупная задолженность всех заемщиков
- amount_to_treasury - доля выручки, направляемая в казначейство протокола
- ztoken_supply - общее количество выпущенных zTokens

В норме ztoken_supply - это большое число, но взлом не является нормой

Как проводилась атака
1. Пул wstEth был пуст. Это позволило хакеру сминтить 1 wei zwstEth за 1 wei wstEth, начальное значение аккумулятора стало равно 1
2. Атакующий вызывает flash_loan() функцию, занимает 1 wei, а затем возвращает 1000 wei. 999 wei при этом считываются как donation и отправляются в reserve_balance. Новое значение аккумулятора = 851
3. После повторения этого приема 10 раз значение аккумулятора разгоняется до 4.069 × 10^18. 10 в 18 степени - это уровень точности wstEth
4. Хакер через функцию deposit() вносит в пул 4.069297906051644020 wstETH. Благодаря огромному аккумулятору его raw_balance теперь равен 2
5. Дальше он поочередно совершает deposit и withdraw операции. Эти операции вызывают mint() и burn()

Протокол написан на языке Cairo, для деления использовалась библиотека SafeMath с округлением вниз. Как и в Solidity, это означает, что при делении остаток отбрасывается.

При выводе средств, протокол должен рассчитать какое количество raw_balance должно быть списано, тут мы возвращаемся к

raw_balance= collateral_balance / lending_accumulator

Цикл
- На ввод отправляется около 8.13859 wstEth (х2 к значению аккумулятора), теперь у хакера raw_balance = 4
- На вывод идет 6.10394 (х1.5 к значению аккумулятора), функция div() из SafeMath делает следующее

1 = 6.10394 / 4.0692, т.к. полтора округляется вниз до единицы

- теперь raw_balance = 3, хотя истина должна быть 2.5

Повторяя этот цикл, атакующий разгоняет свой raw_balance до 1724, которые оцениваются в 7000 wstEth

6. Заключительная часть атаки в том, что под это разогнанное значение хакер делает borrow в других пулах на сумму в 9.57кк$

Что можно было сделать?
1. По сути в этом что-то есть от Inflation Attack, так что помогли бы dead shares
2. Округление в пользу протокола
3. Границы для lending_accumulator
4. Границы для изменения lending_accumulator за одну транзакцию
5. Пороги минимумов на ввод/вывод
6. Тесты edge cases
7. Аудит библиотек

Материалы, использованные при подготовке поста:
- Анализ от SolidityScan
- Пост от Halborn
- Подробный пост от BlockSec

https://t.me/web3securityresearch

Что нам говорит OWASP 2026

Вчера был опубликован список топ 10 уязвимостей смарт контрактов по состоянию на 2026 год

1 место осталось за Access Control Vulnerabilities, писал про эту уязвимость в прошлом году

Манипуляции ценой оракула, валидация ввода, реентранси и оверфлоу/андерфлоу сдают позиции. Самое большое падение у реентранси, полагаю что дело в образовательной составляющей + оч много инструментов детектят её без особого труда

Flash loan атаки поднялись на 4 место, как и логические ошибки. Оба вида сменили название, на Flash Loan-Facilitated Attacks и Business Logic Vulnerabilities. Бизнес логика - это пока что та часть, с которой тяжеловато справляться агентам

Из списка пропали Insecure Randomness (спасибо Chainlink VRF) и Denial of Service. Второе может быть связано с двумя обновлениями сети эфира в 2025 году, pectra сделала calldata дороже, так что забивать блок своей транзой тоже стало дороже, fusaka в декабре увеличила размер блока + ограничила максимальный размер транзакции, теперь переполнить блок одной транзой просто нельзя

Два новичка: Arithmetic Errors и Proxy & Upgradability Vulnerabilities.

Arithmetic Errors - то что связано с округлениями и потерей точности, а про атаку через Proxy как раз выходил недавно пост

Есть ощущение, что стоит погрузиться глубже в Arithmetic Errors, то что выше было на слуху и до этого

https://t.me/web3securityresearch

❗️❗️❗️ В Solidity баг!

Если ты используешь в своих смарт-контрактах:

• версию от 0.8.28 до 0.8.33,
• --via-ir для промежуточной компиляции Solidity в YUL,
• хранение в transient storage,

, то тебе срочно нужно задуматься! Ну, или взять на заметку в будущем.

Ребята из hexens нашли критическую уязвимость компилятора. Solidity в спешном порядке выкатили версию 0.8.34 с исправлениями.

Суть: наличие переменной в transient storage того же типа, что и в обычном storage, при операции очистки transient-слота затирает слот в обычном storage.

Если не вдаваться в детали работы компилятора, то под капотом просто происходит коллизия ключей кеша при генерации через --via-ir. В итоге удаляется storage-переменная вместо transient-storage переменной.

Никогда не задумывался, но ошибка компилятора затрагивает всех. Независимо от типа протокола, его разработчиков или количества аудитов.

Когда transient storage только появился как концепт, мы с коллегой обсуждали мнения разработчиков. Они были неоднозначными: одни считали, что это небезопасно, другие (например, Uniswap) ждали, чтобы использовать это в своих контрактах.
Тогда мы решили, что время покажет и, как минимум, одну проблему transient storage уже принёс в наш мир.

P.S. Команда компилятора говорит, что сейчас в сети всего три контракта, которые пострадали от этой уязвимости.

#павел_найданов

🤟 Сайт | ТГ-канал | Наш чат

CPIMP атака на 1kk$ или почему аудит скрипта деплоя важен

Итак, представьте, ваш код проходит два аудита, вы исправляете то, что считаете важным (а что считаете неважным помечаете known), но это не делает ваш протокол безопасным, потому что уязвимость в другом месте, а вот проекту UPD_io и представлять не нужно

Clandestine Proxy In the Middle Proxy — "скрытый/подпольный прокси посередине". Это сложная атака, включающая в себя фронтраннинг (посты про MEV не теряют актуальности: раз, два), направленная на upgradable контракты. Суть её заключается во вставке посредника между proxy и implementation контрактами. Эта вставка по сути является man in the middle. Известна стала в июле 2025 года.

В первом приближении схема upgradable контрактов выглядит так:
Прокси -> Имплементация
После CPIMP получается так:
Прокси -> Атакующий -> Имплементация

Что случилось
- 16 сентября 2025 года команда деплоила неинициализированный прокси-контракт
- В окне между деплоем и инициализацией (36 секунд) атакующий опередил команду с помощью Multicall3-транзакции, первым вызвал функцию initialize и захватил права администратора
- Атакующий установил свой malicious proxy, который перенаправлял вызовы на легитимный (аудированный) код, но позволял манипулировать транзакциями
- Для маскировки использовались манипуляции с событиями (events) и слотами хранения, чтобы на блок-эксплорерах (типа Etherscan) всё выглядело нормально — показывался легитимный код
- Атакующий ждал 78 дней, пока протокол набирал ликвидность, и только в декабре активировал эксплойт.

Почему его никто не заметил?
Потому что он гений. Строго говоря, заметить атаку можно было, если бы был проведен анализ логов сразу после деплоя, на это указывают и объясняют Chain Argos. Были подозрительные раздачи ролей на несвязанные с командой адреса, была инициализация контрактов.

А вот после деплоя для маскировки использовались две тактики:
1) Самовосстановление (self-restoration). После делегирования каждого вызова легитимному implementation-контракту CPIMP перезаписывал свой собственный адрес обратно в слот implementation до завершения транзакции. Пытаешься апгрейдить прокси, чтобы избавиться от него? Не сработает, такие дела
2) Подделка слотов для Etherscan (spoofing). Etherscan и другие блок-эксплореры определяют, какой код показывать для upgradeable-прокси, так:
- Читают стандартный слот хранения ERC1967/EIP-1967 (конкретный keccak-хэш), где лежит адрес implementation.
- Показывают верифицированный исходный код по этому адресу.

В реальности слот указывает на malicious-контракт. Но malicious-контракт специально написан так, чтобы перехватывать чтение этого самого слота: Когда кто-то (включая Etherscan) вызывает геттер implementation() или напрямую читает слот, malicious возвращает адрес легитимного контракта (тот, который команда задеплоила и верифицировала).
Поэтому на Etherscan всё выглядит идеально: показывается правильный, аудированный код, как будто ничего не случилось.
Сам malicious-контракт остаётся «в тени» — его код не отображается, и он не верифицирован. Атакующий изучил, как именно работают блок-эксплореры, и встроил эту подделку, чтобы даже внимательный осмотр на Etherscan не вызывал подозрений.

Всё это привело к тому, что 4 декабря 2025 года команда USPD сообщила о взломе. Атакующий сминтил около 98 миллионов токенов USPD и вывел ликвидность из пулов — примерно 232–237 stETH (около $1 млн на тот момент).

Тема прокси достаточно объемная, писать про них посты? Ставь реакцию, если да (и если просто понравился пост)

Источники для подготовки поста:
- Пост на rekt.news
- Разбор теории атаки от Nevermind
- Критика и разбор от chain argos
- Анализ от safe edges
- Анализ от halborn

https://t.me/web3securityresearch

Взлом Cross Curve Bridge на 1.4кк$

Пост основан на разборе атаки от QuillAudits, статье о взломе от MixBytes и гитхабе Axelar GMP SDK

Еще пару недель назад мне казалось, что атаки на мосты ушли в прошлое, но реальность говорит о другом.

Атака была направлена на контракт ReceiverAxelar, интегрированный с Axelar. Сам контракт я не нашел, но он наследуется от AxelarValuedExpressExecutable, в нем есть функция expressExecute(), являющаяся публичной и не имеющая ограничений по доступу

    function expressExecute(
        bytes32 commandId,
        string calldata sourceChain,
        string calldata sourceAddress,
        bytes calldata payload
    ) external payable virtual {
        if (gateway().isCommandExecuted(commandId)) revert AlreadyExecuted();

        address expressExecutor = msg.sender;
        bytes32 payloadHash = keccak256(payload);

        emit ExpressExecuted(commandId, sourceChain, sourceAddress, payloadHash, expressExecutor);

        _setExpressExecutor(commandId, sourceChain, sourceAddress, payloadHash, expressExecutor);

        {
            (address tokenAddress, uint256 value) = contractCallValue(sourceChain, sourceAddress, payload);
            _transferFromExecutor(expressExecutor, tokenAddress, value);
        }

        _execute(commandId, sourceChain, sourceAddress, payload);
    }

Атакующий сгенерировал commandId, подделал sourceChain и sourceAddress, чтобы вызов выглядел легитимным.
Зловредный payload нёс в себе информацию о целевом контракте, количестве токенов (почти миллиард $EYWA) и инструкции по трансферу на свой адресс,

Единственная проверка, которую осуществляет expressExecute() это проверка на то, исполнялся ли такой commandId, а проверки внутри _execute() проверяли только соответствуют ли sourceChain и sourceAddress друг другу. Такая проверка не давала какого-либо эффекта, поскольку эти данные предоставляет инициатор транзакции.

Кроме того, сonfirmation threshold был установлен на значении 1, что означает очень быструю конфирмацию, ведь требуется одобрение только одного валидатора. Обычно транзакции должны пройти validation process от Axelar Gateway, но для экспресс функции эта часть пропускалась.

Подводя итог, атака была релизована через General Message Passing - GMP технологию, которая является основополагающей при бридже, подробнее про то как это устроено можно почитать здесь. Ошибка содержалась в имплементации.

https://t.me/web3securityresearch

Новые векторы атак: EIP-7702.
"EOA only" защита больше не работает

Новые они, конечно, относительно, потому что EIP-7702 был принят еще в мае 2025 с Pectra обновлением сети, но тем не менее

Что изменилось
EIP-7702 позволяет EOA (Externally Owned Account, то, что мы называем кошельком) исполнять код. И это нововведение ломает обратную совместимость для некоторых видов проверок, в частности под удар попадает конструкция

msg.sender == tx.origin

которая использовалась для подтверждения того, что caller является EOA

Такая проверка "EOA only" могла использоваться как защита от вызова функций контрактами и оберегала от reentrancy и flashloan атак

Что случилось
В Notorious Bug Digest #5 от OpenZeppelin описан следующий инцедент.
В августе 2025 года был атакован контракт с неверифицированным кодом на BSC Chain. Это был стейкинг контракт для Wrapped POT токенов с наградами, рассчитывающимися от времени стейкинга.

Цена для POT токенов устанавливалась через PancakeSwap BSC-USD/POT пул.

1. Атакующий деплоит зловредный контракт и делегирует его на EOA адрес через транзакцию типа 7702
2. Атакующий использует EOA для трансфера около 13.9 BNB на свой адрес. Поскольку это трансфер нативного токена, то у привязанного контракта срабатывает fallback функция, которая проходит EOA проверку
3. В этой функции атакующий берет flashloan на 3.5кк $ в BSC-USD токене и покупает в PancakeSwap BSC-USD/POT пуле эквивалентное количество POT токенов, тем самым поднимая цену .
4. Затем атакующий вызывают функцию для стейка токенов, которая считывает цену из пула, подвергнутого манипуляции. Он стейкает примерно 220к POT токенов.
5. Атакующий свапает остальные POT токены обратно в BSC-USD, гасит flashloan, чем приводит цену в норму, а на отправленные ранее 13.9 BNB покупает BSC-USD, чтобы компенсировать купленные 220к POT.
6. Таким же образом был вызван unstake через fallback, который отправил атакующему 3.3кк POT токенов, что стало возможным из-за завышенной оценки застейканных активов. Атакующий смог извлечь 85к$ из протокола

Помимо прочего, в качестве одной из мер защиты, между стейком и анстейком должен был пройти 1 день, но эту защиту хакер обошел. Первую транзакцию он отправил в 2025-08-24 23:59:06 (UTC), а вторую через минуту в 2025-08-25 00:00:14.

Неверифицированный код не служит защитой! Примеры декомпиляции функций контракта представлены в оригинальной статье

https://t.me/web3securityresearch

Разбирая MEV: Кто такой этот ваш PBS

Для того, чтобы начать тему защиты от MEV, надо углубиться в то, как устроена работа сети эфира на данный момент

В 2022 году, во время The Merge произошел переход к архитектуре Proposer-Builder Separation (PBS). Суть ее заключается в том, что собирает блок builder, а включает его в сеть proposer (валидатор). До этого момента сборкой и предложением блоков сети занимался один актор, что вело к доминации крупных институционалов

На данный момент PBS реализуется через промежуточное ПО, носящее название MEV-Boost. Это опенсорсный проект, разработанный Flashbots. То, что я пишу здесь по большей части базируется на документации FlashBots Auction

Стоит отметить, что валидаторы по прежнему могут строить блоки самостоятельно

На изображении представлен флоу, по которому транзакция движется от бандла до блока, включенного в цепочку. От сёрчера до валидатора. Эта схема называется Flashbots Auction

В процессе участвуют несколько акторов/сущностей:
- Искатели/сёрчеры (Searchers). Собирают транзакции в публичном и/или приватном мемпуле так, чтобы максимизировать выгоду. Они собирают транзакции в
- Бандлы (Bundles). Массив независимых транзакций, сопровождающихся метаданными, содержащими условия исполнения. Все транзакции должны быть исполнены в том порядке, в котором их собрал сёрчер, причем бандл обладает атомарностью. Сёрчер отправляет бандл дальше по цепочке билдеру.
- Строитель/Билдер (Builder). Его задача - сборка из бандлов наиболее прибыльного блока. Билдер видит все транзакции. Он передает собранный блок в реле
- Реле/релэй (Relay). Это доверенный посредник между билдерами и валидаторами. Собирает готовые блоки, выбирает самый выгодный вариант для передачи валидатору

При этом и сёрчеры, и билдеры, и реле имеют свой высококонкурентный рынок игроков

Важно, что реле не отправляют валидаторам сразу готовые блоки, сначала отправляются заголовок самого доходного блока. Если валидатор возвращает подписанный заголовок реле, то получает в ответ полный блок, который предлагает для включения в блокчейн

Кроме того, вся схема называется аукционом не просто так: сёрчеры и билдеры вынуждены отправлять дальше по цепочке bids (ставки), чтобы следующий актор выбрал их предложение. При этом сами транзакции могут быть скрыты до включения в блок

В прошлом посте я писал, что MEV бот зафронтранил хакера. Он мог бы этого избежать, если бы использовал приватный мемпул, тем более, что для этого нужен был простой советский.. нужно было использовать приватный RPC

Этот RPC прокидывает транзакцию в приватный мемпул, ну а дальше вы знаете, её подхватывает сёрчер

https://t.me/web3securityresearch

Взлом Makina Finance

Вчера произошел взлом Makina Finance, атакующий эксплуатировал уязвимость в оракуле MachineShareOracle.sol

По сути это Price Oracle Manipulation с использованием flash-loan, которая описана в этом посте, она затронула пул DUSD/USDC (Dialectic USD/USDC Stableswap pool) на Curve Finance. Makina Finance быстро отреагировала, активировав security mode

но я решил написать про эту атаку потому, что бОльшую часть прибыли атакующего перехватил MEV-бот, который зафронтранил транзакцию атакующего, оказывается так тоже бывает

Получается, что крупным протоколам было бы неплохо иметь своих ботов на страже

Про подобных ботов я писал разбор статьи

https://t.me/web3securityresearch

Перевод статьи "Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents, 2025, Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal, Pramod Viswanath"

AI-агенты с фальшивыми воспоминаниями: атака на web3-агентов манипуляцией контекстом. Июль 2025

Вокруг нас появляется достаточно много решений, основанных на AI-агентах. Агенты могут торговать с твоего кошелька, воспринимая задачи из чата, написанные обычным языком. Агенты обладают значительной степенью автономности. Агенты получают всё больше задач прямо сейчас, в том числе берут часть работы в аудите на себя.

Но что там с безопасностью? Насколько существующие решения гарантируют, что агент не будет действовать во вред? Что надо знать аудиторам, чтобы вступить на эту новую область?

Я сделал перевод статьи, посвященной этим вопросам. Работать со статьями очень удобно: помимо того, что они, как правило, сами хорошо структурированы и основательны, в них содержится большое количество ссылок на смежные материалы. Советую обратить внимание на список литературы, а так же на Appendix, переводом которого я не занимался.

Статья достаточно большая, получилось 2 лонгрида, тк в 1 телеграф пост материал просто не влез. Ссылка на оригинальную статью добавил в начало поста, сам файл статьи прикрепил сюда же, тк онлайн там поехала верстка в некоторых частях

Часть 1
Часть 2

https://t.me/web3securityresearch

Пост-навигация, дополняется

- Начало

Обучение никогда не заканчивается
- Про курсы
- Про источники информации о взломах
- Базовый учебник по Ethereum
- Про тесты
- Formal Verification в серии постов 1, 2, 3, 4, 5, 6, 7
- Что такое dead shares
- База про Proxy
- Как понять что у вас CPIMP

Защита AI-агентов на практике
- Статья 1. Про memory injection и ее эффективность
- Статья 2. Почему guardrails в промпте не помогают и что делать

Механики аудита
- Какой бывает
- Стадии аудита
- Рект тест
- Оценка уязвимостей

Уязвимости
- OWASP TOP 10 2026
- Reentrancy
- Price Oracle Manipulation
- Access Control Vulnerabilities
- Inflation Attack 1, 2
- Signature Replay Vulnerability, SRV

Обзор статей
- MEV, Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. Про MEV-ботов. Устройство, математика, статистика (неполная и на 2019 год)
- AI, Перевод статьи «Detecting Functional Bugs in Smart Contract through LLM-powered and Bug-Oriented Compose Analysis», 2025, в нескольких частях (про фреймворк для поиска багов в смарт-контрактах)
- AI, Перевод статьи "Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents, 2025" (про то, каким уязвимостям подвержены AI-агенты)
- SRV, "One Signature, Multiple Payments: Demystifying and Detecting Signature Replay Vulnerabilities in Smart Contracts". Пост про виды уязвимости репликации подписи, но в статье про новый инструмент детекции на основе LLM

Разборы взломов
- Взлом GMX, что это было?
- Неэффективность NFT Strategy, стоившая почти 1кк$
- EOA only больше не работает
- Взлом моста Cross Curve
- Взлом UDP через CPIMP атаку (proxy), MEV
- Как ошибка округления привела к закрытию zkLend
- Как перехитрить MEV-бота

Разбирая MEV:
- Кто такой этот ваш PBS
- Защита от MEV, часть1. На уровне кода
- Защита от MEV, часть 2. На уровне инфраструктуры

AI-agents
- AIUC-1 + OWASP. Стандарт безопасности и список угроз, обзор

Безопасность окружения разработки
- Kipuka - контроль npm-пакетов


https://t.me/web3securityresearch