Back to Blog

Когда «SafeMint» становится небезопасным: уроки инцидента с HypeBears

Code Auditing
February 3, 2022
2 min read

Утром 3 февраля (часовой пояс +8) наша система зафиксировала транзакцию атаки 0xfa97c3476aa8aeac662dae0cc3f0d3da48472ff4e7c55d0e305901ec37a2f704, направленную на NFT-контракт HypeBears. После расследования мы выяснили, что это была атака типа re-entrancy (повторный вход), вызванная функцией _safeMint стандарта ERC721.

Первопричина

В проекте установлено ограничение на количество NFT, которое может минтить один аккаунт. По сути, используется карта addressMinted, которая фиксирует, выпустил ли аккаунт NFT.

При минтинге NFT код использует функцию _safeMint из эталонной реализации OpenZeppelin. Эта функция называется «безопасной» (safe), так как она проверяет, может ли получатель принимать токены ERC721. Это предотвращает ситуацию, когда NFT отправляется на контракт, не способный обрабатывать токены ERC721. Согласно документации:

Если параметр to указывает на смарт-контракт, он должен реализовывать интерфейс IERC721Receiver.onERC721Received, который вызывается при безопасном переводе. Следующий код демонстрирует реализацию функции _safeMint от OZ.

Однако этот вызов внешней функции создает лазейку в безопасности. В частности, злоумышленник может выполнить повторный вызов внутри обратного вызова (callback) onERC721Received. Например, в уязвимом контракте HypeBears злоумышленник может снова вызвать функцию mintNFT внутри обратного вызова onERC721Received (поскольку запись addressMinted еще не обновлена).

Атака

На снимке экрана ниже показана транзакция атаки.

Уроки

Риски, связанные с использованием SafeMint, обсуждались исследователями безопасности link1 link2. Тем не менее, мы до сих пор встречаем уязвимый код и атаки в реальности. Как было показано в случае с safeTransfer во время инцидента безопасности QBridge, использование «безопасной» (safe) функции не гарантирует «безопасность» (safe) контракта 😃.

Sign up for the latest updates
~$800K потеряно: двойное списание в Hinkal | Еженедельник BlockSec
Security Insights

~$800K потеряно: двойное списание в Hinkal | Еженедельник BlockSec

Еженедельный отчёт охватывает 1 инцидент за 29 июня – 5 июля 2026 г.: ~$800K потерь в Ethereum. Протокол Hinkal был атакован через двойное списание из-за уязвимости в устаревшем формате нот, позволявшей извлекать несколько нуллификаторов из одного депозита.

Информационный бюллетень — июнь 2026 г.
Security Insights

Информационный бюллетень — июнь 2026 г.

Отчёт за июнь 2026: три крупнейших инцидента с общими потерями ~$22M. Honeypot атака опустошила MEV-бот на ~$15M. Уязвимости Aztec rollup привели к потере ~$4.35M. Ошибка Ed25519 в SecondFi раскрыла ключи 374 кошельков (~$2.4M).

~$4M потеряно: эксплойты Taiko и SecondFi | Еженедельник BlockSec
Security Insights

~$4M потеряно: эксплойты Taiko и SecondFi | Еженедельник BlockSec

Отчёт за 22–28 июня 2026: два инцидента, ~$4,1М потерь. Эксплойт Taiko: утечка ключа SGX + неполная политика аттестации → подделка L2-доказательств. SecondFi: уязвимость Ed25519 (нонс без секрета) → восстановление приватных ключей Cardano.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit