Back to Blog

Solanaエコシステムの保護 (7) — 型の混同

2022年4月29日
4 min read

0. レビュー

1. 概要

前回のブログでは、一般的なマルチシグの実装について紹介しました。本稿では、もう一つのセキュリティ問題である「型推論」について議論します。

2. デシリアライゼーション/シリアライゼーション

Solanaでは、プログラムの状態はアカウントに保存されます。型推論の問題は、アカウントのデシリアライゼーション/シリアライゼーション中に発生します。プログラムのロジックは通常、データ構造に依存します。しかし、プログラムはデシリアライゼーション/シリアライゼーションプロセス中にアカウントの型を適切にチェックしない場合があります。これは攻撃者によって悪用され、予期せぬ損失につながる可能性があります。

3. コードレビュー(型推論)

以下では、単純なプログラムで型推論の問題を説明します。テストコードはこちらで見つけることができます。

テストプログラムでは、UserとMetadataという2つのデータ構造を実装しています。どちらも別のアカウントの公開鍵を記録しています。

プログラムには3つの異なる命令があります。InitializeUser命令は、Userアカウントを作成し、承認済みアカウント(authority)を設定するように設計されています。同様に、InitializeMeta命令は、MetaDataアカウントを作成し、通常のアカウント(account)を設定するために呼び出されます。Test命令は、攻撃者がプログラムの検証ロジックをバイパスし、制御されたMetaDataで攻撃を実行できることを示しています。

Test()命令を詳しく見てみましょう。プログラムは、渡されたUserアカウントの所有者がプログラム自体であることを保証します(86行目〜89行目)。デシリアライゼーション後(92行目)、プログラムは渡されたauthorityアカウントの公開鍵とUserアカウントに保存されている公開鍵を比較します。それらが等しくない場合、プログラムはロールバックします(93行目〜96行目)。最後のチェックは、authorityアカウントがトランザクションに署名したことを確認することです。しかし、攻撃者が制御されたMetadataアカウントを渡した場合、すべてのチェックはバイパスされる可能性があります。その理由は、プログラムがアカウントの型をチェックしないためです。プログラムはバイト配列を受け取り、プログラムに定義されたさまざまな型の構造体に直接デシリアライズします。

さらなるテストのためにテストプログラムをデプロイしました。リンクはこちらで見つけることができます。

3.1 トランザクションの送信

プログラムをデプロイした後、プログラムで提供されている3つの命令を順に呼び出すスクリプトを作成しました。

まず、InitializeUserとInitializeMetaを呼び出します。Metadataアカウントに保存されているaccountアカウントとして、私たち自身の公開鍵を設定することに注意してください。

test()関数では、MetadataアカウントをUserアカウントとして、私たち自身の(検証済みの)アカウントをauthority_infoとして渡します(347行目〜348行目)。プログラムはMetadataをUser構造体でデシリアライズし、すべてのチェックはバイパスされます。

トランザクションを送信した結果はこちらで見ることができます。プログラムは成功を返しました。これは、チェックされていないアカウント型でチェックを正常にバイパスできたことを意味します。

4. まとめ

本稿では、Solanaにおける型推論の問題を紹介しました。この問題を回避する方法は数多くあります。例えば、構造体にアカウントの型を記録する属性を追加し、プログラムは渡されたアカウントの読み書きを行う前に必ず型属性をチェックするようにすることができます。引き続き、今後の投稿でさらに共有していきます。

このシリーズの他の記事を読む:


BlockSecについて

BlockSecは、世界的に著名なセキュリティ専門家グループによって2021年に設立された、先駆的なブロックチェーンセキュリティ企業です。同社は、進化するWeb3の世界のセキュリティと使いやすさを向上させ、その大規模な採用を促進することに専念しています。この目的のために、BlockSecはスマートコントラクトおよびEVMチェーンのセキュリティ監査サービス、セキュリティ開発と脅威のプロアクティブなブロックのためのPhalconプラットフォーム、資金追跡と調査のためのMetaSleuthプラットフォーム、そしてWeb3ビルダーが仮想通貨の世界を効率的にサーフィンするためのMetaSuites拡張機能を提供しています。

現在までに、同社はMetaMask、Uniswap Foundation、Compound、Forta、PancakeSwapなど300社を超える著名なクライアントにサービスを提供しており、Matrix Partners、Vitalbridge Capital、Fenbushi Capitalなどの著名な投資家から2回の資金調達ラウンドで数千万米ドルを獲得しています。

公式ウェブサイト:https://blocksec.com/

公式Twitterアカウント:https://twitter.com/BlockSecTeam

Sign up for the latest updates
安全な保管を超えて、第2部:ウォレットの暗号技術を安全に実装する
Security Insights

安全な保管を超えて、第2部:ウォレットの暗号技術を安全に実装する

攻撃者は、保護された秘密鍵のコピーを読み取らずに、その秘密鍵を復元できるのでしょうか。『Beyond Secure Storage』の第2部では、乱数の品質不足、エントロピーの損失、署名用ノンスの不備によって鍵の予測や復元が可能になった6件の事例を検証します。そこから鍵生成と署名に関する実装要件を導き出し、決済機関がコードレビューと導入済みシステムのテストを通じて、それらをどう評価できるかを説明します。

安全な保管を超えて、第1部:安全な決済・署名ワークフローの設計
Security Insights

安全な保管を超えて、第1部:安全な決済・署名ワークフローの設計

攻撃者が秘密鍵を盗まずに、認可されていない操作が有効な署名を得ることは、なぜ可能なのでしょうか。「安全な保管の先へ」第1回では、Bitget、Bybit、Binanceなどの事例を通じて、支払い要求、トランザクションの構築、署名、実行、決済の各段階における認可の不備を検討します。そのうえで、認可されていない操作を防ぎ、損失を抑えるための設計原則を導き出し、レビュー、監査、ペネトレーションテスト、演習によって、それらの防御策をどう検証できるかを説明します。

秘密鍵が盗まれなくても暗号資産が奪われる仕組み
Case Studies

秘密鍵が盗まれなくても暗号資産が奪われる仕組み

秘密鍵を安全に管理していても、決済の安全が保証されるわけではありません。BlockSecは、BigONE、Bybit、Resolv、Binance、Drift、Chainflipが関わる実際のインシデントを踏まえ、攻撃者が暗号資産決済のライフサイクル全体にわたる弱点をどのように悪用するかを検証します。決済の承認、トランザクションの構築、署名権限、決済の確定に潜むリスクと、資金を守るために決済機関が何を評価すべきかを解説します。