algorand-vulnerability-scanner

Algorand 脆弱性スキャナー

1. 目的

Trail of Bits の「Not So Smart Contracts」データベースに記載されている、Algorand 固有のセキュリティ脆弱性について、Algorand スマートコントラクト（TEAL および PyTeal）を体系的にスキャンします。このスキルでは、Algorand のトランザクションモデル特有の重大な脆弱性パターンを 11 個検出します。

2. このスキルを使用する場面

• Algorand スマートコントラクト（ステートフルアプリケーションまたはスマート署名）の監査
• TEAL アセンブリまたは PyTeal コードのレビュー
• Algorand プロジェクトの監査前セキュリティ評価
• 報告された Algorand の脆弱性に対する修正の検証
• Algorand 固有のセキュリティパターンに関するチームのトレーニング

3. プラットフォームの検出

ファイル拡張子と識別情報

• TEAL ファイル：.teal
• PyTeal ファイル：PyTeal のインポートを含む .py ファイル

言語／フレームワークの識別子

# PyTeal indicators
from pyteal import *
from algosdk import *

# Common patterns
Txn, Gtxn, Global, InnerTxnBuilder
OnComplete, ApplicationCall, TxnType
@router.method, @Subroutine

プロジェクト構成

• approval_program.py / clear_program.py
• contract.teal / signature.teal
• Algorand SDK または Beaker フレームワークへの参照

ツールのサポート

• Tealer：Algorand 向けの Trail of Bits 静的解析ツール
• インストール：uv tool install tealer（uv のツール用 bin ディレクトリが PATH に含まれていることを確認してください）
• 使用方法：tealer contract.teal --detect all

---

4. このスキルの動作

このスキルが呼び出されると、次の処理を行います。

1. TEAL／PyTeal ファイルをコードベースから検索します
2. 各ファイルを分析し、11 個の脆弱性パターンを検査します
3. ファイル参照と重大度を含む検出結果を報告し、その上に各パターンの判定を記載したカバレッジ表を表示します
4. 特定した各問題の修正方法を提示します
5. （インストールされている場合）自動検出のためにTealer を実行します

---

5. 出力例

脆弱性が見つかった場合、次のようなレポートが表示されます。

=== ALGORAND VULNERABILITY SCAN RESULTS ===

Project: my-algorand-dapp
Files Scanned: 3 (.teal, .py)
Vulnerabilities Found: 2

Coverage: 11/11 patterns reported
 1 Rekeying Attack ................... found   approval.py:45
 2 Unchecked Transaction Fee ......... n/a     stateful app, fees paid by sender
 3 Closing Account ................... clear   Assert(Txn.close_remainder_to() == Global.zero_address())
 ... one row per pattern, all 11 present ...

---

[CRITICAL] Rekeying Attack
File: contracts/approval.py:45
Pattern: Missing RekeyTo validation

Code:
    If(Txn.type_enum() == TxnType.Payment,
        Seq([
            # Missing: Assert(Txn.rekey_to() == Global.zero_address())
            App.globalPut(Bytes("balance"), balance + Txn.amount()),
            Approve()
        ])
    )

Issue: The contract doesn't validate the RekeyTo field, allowing attackers
to change account authorization and bypass restrictions.

---

6. 脆弱性パターン（11 パターン）

Algorand 固有の重大な脆弱性パターンを 11 個検査します。詳細な検出パターン、コード例、緩和策、テスト戦略については、VULNERABILITY_PATTERNS.md を参照してください。

パターンの概要：

1. Rekey 攻撃 ⚠️ CRITICAL - RekeyTo フィールドの検証不足
2. トランザクション手数料の検証不足 ⚠️ HIGH - スマート署名で手数料が検証されていない
3. アカウントのクローズ（CloseRemainderTo） ⚠️ CRITICAL - CloseRemainderTo の検証不足によりアカウントの資産が流出する
4. アセットのクローズ（AssetCloseTo） ⚠️ CRITICAL - AssetCloseTo の検証不足によりアセット保有分が流出する
5. グループサイズのチェック ⚠️ HIGH - アトミックグループに対する Global.group_size() の検証がない
6. 時間ベースのリプレイ攻撃 ⚠️ MEDIUM - リースまたはラウンド範囲の制限がない
7. アクセス制御 ⚠️ CRITICAL - 更新／削除および特権付き呼び出しが保護されていない
8. アセット ID の検証 ⚠️ HIGH - アセット操作でアセット ID が検証されていない
9. サービス拒否（アセットへのオプトイン） ⚠️ MEDIUM - プッシュ転送により、オプトインしていないアカウントが送金を受け取れなくなる
10. 内部トランザクション手数料 ⚠️ MEDIUM - 内部手数料が明示的に 0 に設定されていない
11. 状態クリアトランザクション ⚠️ HIGH - 状態クリアプログラムでは拒否できず、状態に不整合が残る

コード例を含む脆弱性パターンの全容については、VULNERABILITY_PATTERNS.md を参照してください。

7. スキャンのワークフロー

ステップ 1：プラットフォームの特定

1. ファイル拡張子（.teal、.py）を確認します
2. フレームワーク（PyTeal、Beaker、純粋な TEAL）を特定します
3. コントラクトの種類（ステートフルアプリケーションかスマート署名か）を判断します
4. 承認プログラムと状態クリアプログラムを見つけます

ステップ 2：Tealer による静的解析

# Run Tealer on contract
tealer contract.teal --detect all

# Or specific detectors
tealer contract.teal --detect unprotected-rekey,group-size-check,update-application-check

ステップ 3：脆弱性の手動チェック

上記の 11 個の脆弱性それぞれについて、次を行います。

1. 関連するトランザクションフィールドの使用箇所を検索します
2. 検証ロジックが存在することを確認します
3. バイパス条件がないか確認します
4. 内部トランザクションの処理を検証します

ステップ 4：トランザクションフィールドの検証マトリクス

使用するすべてのトランザクションタイプについて、チェックリストを作成します。

支払いトランザクション：

• RekeyTo を検証する
• CloseRemainderTo を検証する
• Fee を検証する（スマート署名の場合）

アセット転送：

• アセット ID を検証する
• AssetCloseTo を検証する
• RekeyTo を検証する

アプリケーション呼び出し：

• OnComplete を検証する
• アクセス制御を適用する
• グループサイズを検証する

内部トランザクション：

• Fee が明示的に 0 に設定されている
• RekeyTo がユーザーによって制御されていない（Teal v6 以降）
• すべてのフィールドを検証する

ステップ 5：グループトランザクションの分析

アトミックトランザクショングループについて：

1. Global.group_size() のチェックを検証する
2. 絶対インデックスと相対インデックスを確認する
3. リプレイ保護（Lease フィールド）を確認する
4. グループ内の ApplicationCalls について OnComplete フィールドを検証する

ステップ 6：アクセス制御のレビュー

• 作成者／管理者の権限が適切に適用されている
• 更新／削除操作が保護されている
• 機密性の高い関数に認可チェックがある

---

8. レポート形式

カバレッジ表

§6 のすべてのパターンについて、検出の有無にかかわらず報告します。以下の表を検出結果より上に出力し、 11 行すべてを含めてください。

#	パターン	判定	根拠
1	Rekeying Attack	found	approval.py:45 -- 支払い分岐に Txn.rekey_to() のアサーションがない
2	Unchecked Transaction Fee
3	Closing Account (CloseRemainderTo)
4	Closing Asset (AssetCloseTo)
5	Group Size Check
6	Time-Based Replay Attack
7	Access Controls
8	Asset ID Verification
9	Denial of Service (Asset Opt-In)
10	Inner Transaction Fee
11	Clear State Transaction

判定は次のいずれかです。

• found — file:line を示し、以下で検出結果の詳細を記述します。
• clear — このパターンがコントラクトに該当し、コントラクトで適切に処理されています。読者が検索を再現できるよう、検索したフィールド、オペコード、またはチェックを記載します。
• n/a — このパターンは該当しません。その理由を 1 つの節で記載します（「このコントラクトには内部トランザクションがない」など）。確認していないことは n/a の理由になりません。

11 行に満たない表はスキャンが不完全であり、そのように報告する必要があります。Verdict セルが空欄の行も同様に不完全です。行 1 は形式を示すために記入されており、レポートが完了する前にすべての行を同様に記入します。11 件すべてが clear という結果も、読者が対応に活用できます。4 つのパターンだけを取り上げ、残り 7 つについて何も述べないレポートは、問題のないコントラクトの報告とまったく同じように見えてしまいます。この表は、その失敗を防ぐためのものです。

検出結果のテンプレート

## [SEVERITY] Vulnerability Name (e.g., Missing RekeyTo Validation)

**Location**: `contract.teal:45-50` or `approval_program.py:withdraw()`

**Description**:
The contract approves payment transactions without validating the RekeyTo field, allowing an attacker to rekey the account and bypass future authorization checks.

**Vulnerable Code**:
```python
# approval_program.py, line 45
If(Txn.type_enum() == TxnType.Payment,
    Approve()  # Missing RekeyTo check
)
```

**Attack Scenario**:
1. Attacker submits payment transaction with RekeyTo set to attacker's address
2. Contract approves transaction without checking RekeyTo
3. Account authorization is rekeyed to attacker
4. Attacker gains full control of account

**Recommendation**:
Add explicit validation of the RekeyTo field:
```python
If(And(
    Txn.type_enum() == TxnType.Payment,
    Txn.rekey_to() == Global.zero_address()
), Approve(), Reject())
```

**References**:
- building-secure-contracts/not-so-smart-contracts/algorand/rekeying
- Tealer detector: `unprotected-rekey`

---

9. 優先度の指針

重大（直ちに修正が必要）

• Rekeying 攻撃
• CloseRemainderTo／AssetCloseTo の問題
• アクセス制御の回避

高（デプロイ前に修正）

• 未検証のトランザクション手数料
• アセット ID の検証に関する問題
• グループサイズの検証
• Clear State トランザクションのチェック

中（監査時に対応）

• 内部トランザクションの手数料に関する問題
• 時間ベースのリプレイ攻撃
• アセットのオプトインによる DoS

---

10. テストの推奨事項

必須のユニットテスト

• 各脆弱性のシナリオを PoC エクスプロイトでテストする
• 修正によってエクスプロイトが防止されることを確認する
• エッジケース（グループサイズ = 0、空のアドレスなど）をテストする

Tealer の統合

# Add to CI/CD pipeline
tealer approval.teal --detect all --json > tealer-report.json

# Fail build on critical findings
tealer approval.teal --detect all --fail-on critical,high

シナリオテスト

• すべての重要なフィールドを操作したトランザクションを送信する
• 想定外のサイズのアトミックグループをテストする
• アクセス制御の回避を試みる
• 内部トランザクションの手数料処理を検証する

---

11. 追加リソース

• セキュアなコントラクトの構築：building-secure-contracts/not-so-smart-contracts/algorand/
• Tealer のドキュメント：https://github.com/crytic/tealer
• Algorand 開発者向けドキュメント：https://developer.algorand.org/docs/
• PyTeal のドキュメント：https://pyteal.readthedocs.io/

---

12. クイックリファレンスチェックリスト

Algorand の監査を完了する前に、すべての項目にチェックが入っていることを確認してください。

• すべてのトランザクションタイプで RekeyTo を検証済み
• 支払いトランザクションで CloseRemainderTo を検証済み
• アセット転送で AssetCloseTo を検証済み
• トランザクション手数料を検証済み（スマート署名）
• アトミックトランザクションのグループサイズを検証済み
• リプレイ攻撃対策として Lease フィールドを使用済み（該当する場合）
• Update／Delete 操作にアクセス制御を設定済み
• すべてのアセット操作でアセット ID を検証済み
• DoS を回避するため、アセット転送にプルパターンを使用済み
• 内部トランザクションの手数料を明示的に 0 に設定済み
• ApplicationCall トランザクションの OnComplete フィールドを検証済み
• Tealer スキャンを完了し、重大または高深刻度の検出事項がないことを確認済み
• すべての脆弱性シナリオをユニットテストでカバー済み
• 11 行すべてを含み、各行に found、clear、n/a のいずれかの判定と理由を記載したカバレッジ表を出力済み

---

13. 退けるべき合理化

• 「コントラクトは小さいので、ほとんどのパターンは明らかに該当しません。」 誰にとって明らかなのでしょうか。n/a は節を 1 つ追加するだけで、判断をレビュー可能にします。何も記録しなければ、読者には確認していないのかどうかも分かりません。
• 「Tealer で何も検出されなかったので、コントラクトに問題はありません。」 Tealer がカバーするのはこの 11 個のパターンの一部に限られ、ロジックレベルのパターンにはまったく対応していません。ツールの実行結果がクリーンであっても、それは証拠の 1 行にすぎず、検査対象外のパターンに対する判定ではありません。どのパターンをカバーしたかを明記してください。
• 「このコントラクトで重要なパターンは確認しました。」 どのパターンが重要かを判断することがスキャンそのものであり、スキャンを始めるための前提条件ではありません。行を省くのではなく、表を完成させてから深刻度の順に並べてください。
• 「検出事項がないので、報告することはありません。」 検出事項が 0 件のスキャンでも、完全なカバレッジ表を出力します。その表こそが成果物です。十分に調査されたコントラクトと、ざっと目を通しただけのコントラクトを区別するものです。
• 「PyTeal/Beaker が対応しています。」 バージョンと仕組みを明記してください。フレームワークのデフォルト設定はリリース間で変わります。また、ある呼び出し経路ではパターンをカバーするフレームワークでも、別の経路ではカバーしないことがよくあります。
• 「RekeyTo のチェックは別のプログラムにあります。」 その場合は該当箇所を示してください。別の場所に検証があるという認識は、file:line を確認するまでは仮定にすぎません。プログラムを分割したコントラクトでは、こうしたチェックが抜け落ちやすくなります。