Вы подделываете подписи, не так ли? Уязвимости класса 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 (https://t.me/web3securityresearch/70), но как по мне, то это значит только то, что на них могут обращать меньше внимания. При этом X-CRA и X-PRA виды неактуальны, если ваш контракт развернут в одной сети и у него нет форков. Если вы используете ESDCA от OpenZeppellin (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/ECDSA.sol), то получаете защиту от SMA "из коробки" А вот избежать SSMI и CASR поможет только внимательная реализация Важно понимать, что атаки SRV класса актуальны для любых смарт-контрактов, где используется подпись для верификации полномочий, а это, например: - Кроссчейн бриджи - Мультисиги - NFT + вайтлисты - Форки проектов - Распределение наград https://t.me/web3securityresearch
- 1 reply
- 0 recasts
- 1 reaction
Как округлить 1.5 до 1 и потерять 9.57кк$, история взлома zkLend В этом году в ТОП 10 (https://t.me/web3securityresearch/70)уязвимостей в смарт контрактах вошли Arithmetic Errors и Proxy & Upgradability Vulnerabilities. Про атаку на прокси уже был написан пост (https://t.me/web3securityresearch/68), сегодня разберем уязвимость класса арифметической ошибки Что случилось В начале 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 (https://t.me/web3securityresearch/35), так что помогли бы dead shares (https://t.me/web3securityresearch/37) 2. Округление в пользу протокола 3. Границы для lending_accumulator 4. Границы для изменения lending_accumulator за одну транзакцию 5. Пороги минимумов на ввод/вывод 6. Тесты edge cases 7. Аудит библиотек Материалы, использованные при подготовке поста: - Анализ (https://blog.solidityscan.com/zklend-hack-analysis-e494cb794f71) от SolidityScan - Пост (https://www.halborn.com/blog/post/explained-the-zklend-hack-february-2025) от Halborn - Подробный (https://blocksec.com/blog/zklend-exploit-post-mortem-unraveling-the-details-and-clarifying-misunderstandings-of-the-10m-flash-loan-attack) пост от BlockSec https://t.me/web3securityresearch
- 0 replies
- 0 recasts
- 1 reaction
Что нам говорит OWASP 2026 Вчера был опубликован список (https://owasp.org/www-project-smart-contract-top-10/) топ 10 уязвимостей смарт контрактов по состоянию на 2026 год 1 место осталось за Access Control Vulnerabilities, писал про эту уязвимость в прошлом году (https://t.me/web3securityresearch/28) Манипуляции ценой оракула (https://t.me/web3securityresearch/27), валидация ввода, реентранси (https://t.me/web3securityresearch/10) и оверфлоу/андерфлоу сдают позиции. Самое большое падение у реентранси, полагаю что дело в образовательной составляющей + оч много инструментов детектят её без особого труда 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 как раз выходил недавно пост (https://t.me/web3securityresearch/68) Есть ощущение, что стоит погрузиться глубже в Arithmetic Errors, то что выше было на слуху и до этого https://t.me/web3securityresearch
- 0 replies
- 0 recasts
- 1 reaction