ホワイトハットハッカーのsamczsun氏：NFT資産への攻撃はより頻繁になる

注: 元の著者は、「監査の神」として知られるホワイトハットハッカーの samczsun です。彼はパラダイムの研究パートナーでもあります。彼は最近、BitDAO MISOダッチオークションプールから3億5000万ドルの資産を救出した。この記事では、NFT トークン標準の潜在的なセキュリティリスクについて言及しました。また、ERC-721およびERC-1155トークン規格がますます普及するにつれて、NFTへの攻撃がより頻繁になる可能性が高いと予測しました。

ソフトウェア エンジニアリングに携わっている場合、ソフトウェア エンジニアリングの原則を少なくとも 1 つ聞いたことがあるでしょう。すべての原則を厳密に遵守することを推奨するわけではありませんが、確かに注意を払う価値のある原則もいくつかあります。

今日お話しするのは、「驚き最小の原則」です。名前は派手ですが、アイデアは非常にシンプルです。つまり、何かを実行すると主張するコードが提示されると、ほとんどのユーザーは、そのコードがどのようにしてそのことを実現するかについて推測するということです。したがって、開発者としてのあなたの仕事は、ユーザーが驚かないように、これらの仮定に準拠したコードを書くことです。

開発者は物事について仮定を立てることを好むため、これは従うべき良い原則です。 calculateScore(GameState) という関数をエクスポートすると、多くの人は、この関数はゲームの状態からのみ読み取るものと想定します。ゲームの状態も変更すると、ゲームの状態がランダムに壊れる理由を理解しようとして、多くの人が混乱することになります。ドキュメントに記載したとしても、人々がそれを見るという保証はないので、そもそもコードが驚くべきものでないようにすることが最善です。

「6 時間のデバッグで、ドキュメントを読む時間を 5 分節約できます。」

安全であればあるほど良いですよね？

2018 年初頭、ERC-721 標準が起草されていた当時、トークンを処理するように設計されていない受信者の契約でトークンが滞留しないように、転送セキュリティを実装するという提案がありました。この目的のために、提案の作成者は、受信者がトークン転送をサポートできるかどうかを確認するために転送機能の動作を変更しました。また、送信者が希望する場合にこのチェックをバイパスする unsafeTransfer 関数も導入されました。

ただし、下位互換性に関する懸念から、この関数はその後のコミットで名前が変更されました。これにより、ERC-20 トークンと ERC-721 トークンの転送関数は同じ動作をするようになります。ただし、受信機の検査を別の場所に移動する必要があります。そのため、標準の作成者は、安全なクラス関数 safeTransfer と safeTransferFrom を導入しました。

これは正当性の問題に対する解決策です。ERC-20 トークンが、トークンを受け取ることを予期していなかったコントラクトに誤って転送される例が多数あるためです (特によくある間違いは、トークンをトークン コントラクトに転送し、永久にロックしてしまうことです)。 ERC-1155 標準を起草する際に、提案者が ERC-721 標準からインスピレーションを得て、送金時だけでなく発行時にも受取人のチェックを組み込んだのは驚くことではありません。

その後数年間、これらの標準はほとんど使われなくなり、ERC-20 トークン標準は人気を維持し、最近のガスコストの高騰と NFT に対するコミュニティの関心の高まりにより、開発者は自然に ERC-721 および ERC-1155 トークン標準をますます使用するようになりました。こうした新たな関心が高まる中、これらの標準がセキュリティを考慮して設計されていることに感謝すべきではないでしょうか?

安全であればあるほど良い、本当に？

わかりました。しかし、送金や鋳造におけるセキュリティとは何を意味するのでしょうか?安全性については、当事者によって解釈が異なります。開発者にとって、安全な関数とは、バグが含まれていないこと、または追加のセキュリティ問題が発生しないことを意味します。そして、ユーザーにとっては、誤って自分の足を撃ってしまうのを防ぐための追加のガードレールが含まれることを意味するかもしれません。

この場合、機能は後者が多く、前​​者が少ないことがわかります。これは特に残念なことです。なぜなら、transfer 関数と safeTransfer 関数のどちらかを選択する場合、なぜ安全な関数を選択しないのでしょうか?名前がそれを反映しています!

まあ、その理由の 1 つは、古くから親しまれている再入性、または私が名前を変えようとしている「安全でない外部呼び出し」である可能性があります。受信側が攻撃者によって制御されている場合、攻撃者がコントラクトを未定義の状態に移行させる可能性があるため、外部呼び出しは潜在的に安全ではないことに注意してください。設計上、これらの「安全な」関数はトークン受信者への外部呼び出しを実行し、通常は発行時または転送時に送信者によって制御されます。言い換えれば、これはまさに安全でない extern 呼び出しの教科書的な例です。

しかし、契約の受け取り側が処理できない送金を拒否できるとしたら、最悪の事態はどうなるのかと自問する人もいるかもしれません。さて、2つのケーススタディでこの質問に答えてみましょう。

例1: ハッシュマスク

Hashmasks は供給量が限られた NFT アバター プロジェクトであり、ユーザーは 1 回の取引につき最大 20 個のマスク NFT を購入できます (ただし、数か月間売り切れています)。マスクを購入する機能は次のとおりです。

この関数は完全に合理的であると思われるかもしれません。しかし、予想通り、_safeMint 呼び出しには何か不吉なものが潜んでいます。見てみましょう。

セキュリティ上の理由から、この関数はトークンの受信者に対してコールバックを実行し、受信者が転送を受け入れるかどうかを確認します。ただし、私たちはトークンの受信者であるため、コールバックを受け取ったばかりで、この時点では mintNFT 関数を再度呼び出すなど、何でも好きなことができます。これを実行すると、マスクを 1 つだけ作成した後に関数を呼び出すことになり、さらに 19 個のマスクを作成するように要求できるようになります。その結果、ルールでは最大 20 個までしか鋳造できないにもかかわらず、39 個のマスク NFT が鋳造されました。

例2: ENSドメイン名ラッパー

最近、ENS の Nick Johnson から連絡があり、ENS ドメイン ラッパーで行っている作業を見てみたいとのことでした。この名前ラッパーにより、ユーザーは新しい ERC-1155 トークンを使用して ENS 名をトークン化できるようになり、きめ細かい権限とより一貫性のある API がサポートされます。

要約すると、任意の ENS 名 (具体的には、2LD.eth を除くすべての ENS 名) をラップするには、まず名前ラッパーが ENS 名にアクセスできるように承認する必要があります。次に、wrap(bytes,address,uint96,address) を呼び出します。これにより、ERC-1155 トークンが生成され、基礎となる ENS ドメイン名が管理されます。

これは非常に単純な wrap 関数です。まず、_wrap を呼び出してロジックを実行し、ハッシュされたドメイン名を返します。次に、ドメインを引き継ぐ前に、トランザクションの送信者が実際に ENS ドメインの所有者であることを確認します。送信者が基礎となる ENS 名を所有していない場合は、トランザクション全体を元に戻し、_wrap で行われた変更をすべて元に戻す必要があることに注意してください。

以下は _wrap 関数そのものです。ここでは特別なことは何もありません。

残念ながら、この _mint 関数は、何も知らない開発者に恐ろしい驚きを与える可能性があります。 ERC-1155 仕様では、トークンが発行される際に、受信者にトークンを受け入れるかどうか問い合わせる必要があると規定されています。ライブラリ コード (OpenZeppelin ベースからわずかに変更されています) を詳しく調べたところ、これが実際に当てはまることがわかりました。

しかし、これは具体的にどのような利益をもたらすのでしょうか?さて、ここでも再入攻撃を実行するために使用できる安全でない外部呼び出しを確認しました。具体的には、コールバック中は、トークン化された ENS 名の ERC-1155 トークンを所有していますが、名前ラッパーは、基礎となる ENS 名自体を所有していることをまだ確認していないことに注意してください。これにより、ENS ドメインを実際に所有せずに運用できるようになります。たとえば、ドメイン ラッパーにドメインを解凍し、作成したトークンを書き込み、基礎となる ENS ドメインを取得するように要求できます。

基礎となる ENS 名がわかったので、新しいサブドメインの登録やリゾルバの設定など、必要な操作をすべて実行できます。完了したら、コールバックを終了します。名前ラッパーは、基礎となる ENS 名の現在の所有者 (つまり私たち) と対話し、トランザクションを完了します。このようにして、名前ラッパーが承認されたすべての ENS ドメインの一時的な所有権を取得し、変更を加えました。

結論は

予期しないコードにより、状況が壊滅的に悪化する可能性があります。この記事の両方のケースでは、開発者は安全な関数クラスを安全に使用できると合理的に想定していましたが、意図せずに攻撃対象領域を拡大してしまいました。 ERC-721 および ERC-1155 トークン標準が普及するにつれて、この種の攻撃はより頻繁に発生する可能性があります。開発者は、安全なクラス関数を使用するリスクを考慮し、外部呼び出しが記述したコードとどのように相互作用するかを判断する必要があります。