Claude Skill

algorand-vulnerability-scanner

Scans Algorand smart contracts for 11 common vulnerabilities including rekeying attacks, unchecked transaction fees, missing field validations, and access control issues. Use when auditing Algorand projects (TEAL/PyTeal).

LLM Mart · 0 points · 8 views 17 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download trailofbits-skills-plugins_building-secure-contracts_skills_algorand-vulnerability-scanner-123037e.zip · 10 KB
trailofbits/skills 7234 616 forks CC-BY-SA-4.0 Updated 13h ago
Part of trailofbits/skills — 100 skills

Install

skills CLI npx skills add https://github.com/trailofbits/skills/tree/main/plugins/building-secure-contracts/skills/algorand-vulnerability-scanner
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install trailofbits-skills@llmmart
Git git clone https://github.com/trailofbits/skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole trailofbits/skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Algorand Vulnerability Scanner

1. Purpose

Systematically scan Algorand smart contracts (TEAL and PyTeal) for platform-specific security vulnerabilities documented in Trail of Bits' "Not So Smart Contracts" database. This skill encodes 11 critical vulnerability patterns unique to Algorand's transaction model.

2. When to Use This Skill

  • Auditing Algorand smart contracts (stateful applications or smart signatures)
  • Reviewing TEAL assembly or PyTeal code
  • Pre-audit security assessment of Algorand projects
  • Validating fixes for reported Algorand vulnerabilities
  • Training team on Algorand-specific security patterns

3. Platform Detection

File Extensions & Indicators

  • TEAL files: .teal
  • PyTeal files: .py with PyTeal imports

Language/Framework Markers

# PyTeal indicators
from pyteal import *
from algosdk import *

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

Project Structure

  • approval_program.py / clear_program.py
  • contract.teal / signature.teal
  • References to Algorand SDK or Beaker framework

Tool Support

  • Tealer: Trail of Bits static analyzer for Algorand
  • Installation: uv tool install tealer (ensure uv's tool bin dir is on PATH)
  • Usage: tealer contract.teal --detect all

4. How This Skill Works

When invoked, I will:

  1. Search your codebase for TEAL/PyTeal files
  2. Analyze each file for the 11 vulnerability patterns
  3. Report findings with file references and severity, above them a coverage table carrying a verdict for every pattern
  4. Provide fixes for each identified issue
  5. Run Tealer (if installed) for automated detection

5. Example Output

When vulnerabilities are found, you'll get a report like this:

=== 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. Vulnerability Patterns (11 Patterns)

I check for 11 critical vulnerability patterns unique to Algorand. For detailed detection patterns, code examples, mitigations, and testing strategies, see VULNERABILITY_PATTERNS.md.

Pattern Summary:

  1. Rekeying Attack ⚠️ CRITICAL - Unchecked RekeyTo field
  2. Unchecked Transaction Fee ⚠️ HIGH - Fee not validated in smart signatures
  3. Closing Account (CloseRemainderTo) ⚠️ CRITICAL - Unchecked CloseRemainderTo drains the account
  4. Closing Asset (AssetCloseTo) ⚠️ CRITICAL - Unchecked AssetCloseTo drains the asset holding
  5. Group Size Check ⚠️ HIGH - No Global.group_size() validation on atomic groups
  6. Time-Based Replay Attack ⚠️ MEDIUM - No lease or round-range bound
  7. Access Controls ⚠️ CRITICAL - Update/delete and privileged calls unprotected
  8. Asset ID Verification ⚠️ HIGH - Asset ID not validated in asset operations
  9. Denial of Service (Asset Opt-In) ⚠️ MEDIUM - Push transfers strand on un-opted accounts
  10. Inner Transaction Fee ⚠️ MEDIUM - Inner fee not explicitly set to 0
  11. Clear State Transaction ⚠️ HIGH - Clear state program cannot reject, state left inconsistent

For complete vulnerability patterns with code examples, see VULNERABILITY_PATTERNS.md.

7. Scanning Workflow

Step 1: Platform Identification

  1. Confirm file extensions (.teal, .py)
  2. Identify framework (PyTeal, Beaker, pure TEAL)
  3. Determine contract type (stateful application vs smart signature)
  4. Locate approval and clear state programs

Step 2: Static Analysis with 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

Step 3: Manual Vulnerability Sweep

For each of the 11 vulnerabilities above:

  1. Search for relevant transaction field usage
  2. Verify validation logic exists
  3. Check for bypass conditions
  4. Validate inner transaction handling

Step 4: Transaction Field Validation Matrix

Create checklist for all transaction types used:

Payment Transactions:

  • RekeyTo validated
  • CloseRemainderTo validated
  • Fee validated (if smart signature)

Asset Transfers:

  • Asset ID validated
  • AssetCloseTo validated
  • RekeyTo validated

Application Calls:

  • OnComplete validated
  • Access controls enforced
  • Group size validated

Inner Transactions:

  • Fee explicitly set to 0
  • RekeyTo not user-controlled (Teal v6+)
  • All fields validated

Step 5: Group Transaction Analysis

For atomic transaction groups:

  1. Validate Global.group_size() checks
  2. Review absolute vs relative indexing
  3. Check for replay protection (Lease field)
  4. Verify OnComplete fields for ApplicationCalls in group

Step 6: Access Control Review

  • Creator/admin privileges properly enforced
  • Update/delete operations protected
  • Sensitive functions have authorization checks

8. Reporting Format

Coverage Table

Report on every pattern in §6, whether or not it turned anything up. Emit this table above the findings, with all 11 rows present:

# Pattern Verdict Evidence
1 Rekeying Attack found approval.py:45 -- no Txn.rekey_to() assertion on the payment branch
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

Each verdict is one of:

  • found — cite file:line and write the finding up in full below.
  • clear — the pattern applies to this contract and the contract handles it. Name the field, opcode, or check you searched for, so a reader can repeat the search.
  • n/a — the pattern cannot apply here. Give the reason in one clause ("no inner transactions in this contract"). Not having looked is not n/a.

A table with fewer than 11 rows is an incomplete scan and must be reported as one. A row whose Verdict cell is empty is incomplete in the same way: row 1 above is filled in to show the shape, and every row is filled in the same way before the report is done. Eleven clear verdicts is a result a reader can act on. A report that covers four patterns and says nothing about the other seven reads exactly like a clean contract, and that is the failure this table exists to prevent.

Finding Template

## [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. Priority Guidelines

Critical (Immediate Fix Required)

  • Rekeying attacks
  • CloseRemainderTo / AssetCloseTo issues
  • Access control bypasses

High (Fix Before Deployment)

  • Unchecked transaction fees
  • Asset ID validation issues
  • Group size validation
  • Clear state transaction checks

Medium (Address in Audit)

  • Inner transaction fee issues
  • Time-based replay attacks
  • DoS via asset opt-in

10. Testing Recommendations

Unit Tests Required

  • Test each vulnerability scenario with PoC exploit
  • Verify fixes prevent exploitation
  • Test edge cases (group size = 0, empty addresses, etc.)

Tealer Integration

# 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

Scenario Testing

  • Submit transactions with all critical fields manipulated
  • Test atomic groups with unexpected sizes
  • Attempt access control bypasses
  • Verify inner transaction fee handling

11. Additional Resources


12. Quick Reference Checklist

Before completing Algorand audit, verify ALL items checked:

  • RekeyTo validated in all transaction types
  • CloseRemainderTo validated in payment transactions
  • AssetCloseTo validated in asset transfers
  • Transaction fees validated (smart signatures)
  • Group size validated for atomic transactions
  • Lease field used for replay protection (where applicable)
  • Access controls on Update/Delete operations
  • Asset ID validated in all asset operations
  • Asset transfers use pull pattern to avoid DoS
  • Inner transaction fees explicitly set to 0
  • OnComplete field validated for ApplicationCall transactions
  • Tealer scan completed with no critical/high findings
  • Unit tests cover all vulnerability scenarios
  • Coverage table emitted with all 11 rows, each carrying a verdict of found, clear or n/a with a reason

13. Rationalizations to Reject

  • "The contract is small, so most patterns obviously don't apply." Obvious to whom? An n/a costs one clause and makes the judgment reviewable. Silence records nothing, and a reader cannot tell it apart from not having checked.
  • "Tealer reported nothing, so the contract is clean." Tealer covers a subset of these 11 patterns and does not reach the logic-level ones at all. A clean tool run is one row of evidence, not a verdict on the patterns it never examined. Say which patterns it covered.
  • "I checked the patterns that matter for this contract." Deciding which patterns matter is the scan, not a precondition for starting it. Rank by severity after the table is complete, not by leaving rows out.
  • "No findings, so there is nothing to report." A zero-finding scan still emits the full coverage table. That table is the deliverable: it is what distinguishes a contract that was examined from one that was glanced at.
  • "PyTeal/Beaker handles this." Name the version and the mechanism. Framework defaults change between releases, and a framework that covers a pattern on one call path often does not on another.
  • "The RekeyTo check is in the other program." Then cite it. A validation you believe exists elsewhere is an assumption until you have the file:line, and split-program contracts are where these checks go missing.
Files (skills)
  • agents
    • openai.yaml 250 B
      interface:
        display_name: "Algorand Vulnerability Scanner"
        short_description: "Find common vulnerabilities in Algorand contracts"
        icon_small: "assets/trail-of-bits-mark.svg"
        icon_large: "assets/trail-of-bits-mark.svg"
        brand_color: "#D83A34"
      
  • assets
    • trail-of-bits-mark.svg 3 KB · in bundle
  • resources
    • VULNERABILITY_PATTERNS.md 12.3 KB
      ## 6. Vulnerability Checklist (11 Patterns)
      
      ### 6.1 REKEYING ATTACK ⚠️ CRITICAL
      
      **Description**: Missing validation of the `RekeyTo` transaction field allows attackers to change account authorization and bypass contract restrictions.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: No RekeyTo check
      If(Txn.type_enum() == TxnType.Payment)
          # Missing: Assert(Txn.rekey_to() == Global.zero_address())
      
      # VULNERABLE: Inner transactions with user-controlled RekeyTo
      InnerTxnBuilder.SetField(TxnField.rekey_to, Txn.accounts[1])  # User controlled
      ```
      
      **What to Check**:
      - [ ] All transaction approval logic validates `Txn.rekey_to() == Global.zero_address()`
      - [ ] Inner transactions in Teal v6+ do not use user-controlled RekeyTo
      - [ ] Group transactions verify RekeyTo for all relevant txns
      
      **Mitigation**:
      ```python
      # SECURE: Validate RekeyTo field
      Assert(Txn.rekey_to() == Global.zero_address())
      
      # OR: Explicitly allow specific rekey target
      Assert(Txn.rekey_to() == intended_address)
      ```
      
      **Tool Detection**: Tealer detector `unprotected-rekey` available
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/rekeying
      
      ---
      
      ### 4.2 UNCHECKED TRANSACTION FEE ⚠️ HIGH
      
      **Description**: Smart signatures without fee validation allow users to set excessive fees, draining the sender's account balance.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: No fee check in smart signature
      def approval_program():
          return If(Txn.type_enum() == TxnType.Payment, Int(1), Int(0))
          # Missing fee validation
      
      # VULNERABLE: Unbounded fee
      If(Txn.fee() <= some_large_value)  # Still vulnerable
      ```
      
      **What to Check**:
      - [ ] Smart signatures enforce `Txn.fee() == Global.min_txn_fee()`
      - [ ] OR fee is explicitly set to 0 with fee pooling enabled
      - [ ] No user control over transaction fee amounts
      
      **Mitigation**:
      ```python
      # SECURE: Force fee to zero (with fee pooling)
      Assert(Txn.fee() == Int(0))
      
      # OR: Enforce minimum fee only
      Assert(Txn.fee() == Global.min_txn_fee())
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/unchecked_transaction_fee
      
      ---
      
      ### 4.3 CLOSING ACCOUNT (CloseRemainderTo) ⚠️ CRITICAL
      
      **Description**: Missing validation of `CloseRemainderTo` field allows attackers to drain entire account balance to arbitrary address.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: Payment without CloseRemainderTo check
      If(Txn.type_enum() == TxnType.Payment)
          # Missing: Assert(Txn.close_remainder_to() == Global.zero_address())
      
      # VULNERABLE: Inner transaction with close field
      InnerTxnBuilder.SetFields({
          TxnField.type_enum: TxnType.Payment,
          # Missing CloseRemainderTo validation
      })
      ```
      
      **What to Check**:
      - [ ] All payment transactions validate `Txn.close_remainder_to() == Global.zero_address()`
      - [ ] OR explicitly allow specific close address
      - [ ] Inner transactions do not set CloseRemainderTo unless intended
      
      **Mitigation**:
      ```python
      # SECURE: Validate CloseRemainderTo
      Assert(Txn.close_remainder_to() == Global.zero_address())
      
      # OR: Allow specific close target
      Assert(Txn.close_remainder_to() == authorized_address)
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/closing_account
      
      ---
      
      ### 4.4 CLOSING ASSET (AssetCloseTo) ⚠️ CRITICAL
      
      **Description**: Missing validation of `AssetCloseTo` field enables transferring entire asset balance to arbitrary address.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: Asset transfer without AssetCloseTo check
      If(Txn.type_enum() == TxnType.AssetTransfer)
          # Missing: Assert(Txn.asset_close_to() == Global.zero_address())
      ```
      
      **What to Check**:
      - [ ] All asset transfer transactions validate `Txn.asset_close_to() == Global.zero_address()`
      - [ ] OR explicitly specify allowed close target
      - [ ] Inner asset transfers validate AssetCloseTo field
      
      **Mitigation**:
      ```python
      # SECURE: Validate AssetCloseTo
      Assert(Txn.asset_close_to() == Global.zero_address())
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/closing_asset
      
      ---
      
      ### 4.5 GROUP SIZE CHECK ⚠️ HIGH
      
      **Description**: Missing validation of `Global.group_size()` allows attackers to include multiple application calls in atomic group, executing operations multiple times.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: No group size validation
      # Attacker can repeat call 10 times in single group
      If(Gtxn[0].type_enum() == TxnType.Payment)
      
      # VULNERABLE: Absolute indices without size check
      Assert(Gtxn[2].sender() == Gtxn[0].sender())  # No group size validation
      ```
      
      **What to Check**:
      - [ ] Atomic transaction logic validates `Global.group_size()` matches expected size
      - [ ] Using absolute indices is paired with group size verification
      - [ ] OR use relative indexing with ABI methods (Teal v6+)
      
      **Mitigation**:
      ```python
      # SECURE: Validate group size
      Assert(Global.group_size() == Int(3))  # Exact size
      # OR
      Assert(Global.group_size() <= Int(3))  # Maximum size
      
      # BETTER: Use ABI with relative indexing (Teal v6+)
      @router.method
      def method():
          # Automatically handles group indexing
      ```
      
      **Tool Detection**: Tealer detector `group-size-check` available
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/group_size_check
      
      ---
      
      ### 4.6 TIME-BASED REPLAY ATTACK ⚠️ MEDIUM
      
      **Description**: Transactions with same `FirstValid`/`LastValid` but different hashes can be submitted multiple times without `Lease` field protection.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: Periodic payments without lease
      def recurring_payment():
          return Seq([
              Assert(Global.latest_timestamp() >= next_payment_time),
              # Missing Lease validation for replay protection
              InnerTxnBuilder.Submit()
          ])
      ```
      
      **What to Check**:
      - [ ] Recurring/periodic transactions validate `Txn.lease()` field
      - [ ] Lease field set to unique value per logical transaction
      - [ ] Time-dependent operations have replay protection
      
      **Mitigation**:
      ```python
      # SECURE: Validate Lease field
      Assert(Txn.lease() == expected_lease_value)
      
      # OR: Use Lease for mutual exclusion
      lease = Sha256(Concat(Bytes("prefix"), Txn.sender(), Itob(counter)))
      Assert(Txn.lease() == lease)
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/time_based_replay_attack
      
      ---
      
      ### 4.7 ACCESS CONTROLS ⚠️ CRITICAL
      
      **Description**: Missing access control checks on `UpdateApplication` and `DeleteApplication` operations allow unauthorized contract modifications.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: No access control on updates
      program = Cond(
          [Txn.application_id() == Int(0), on_creation],
          [Txn.on_completion() == OnComplete.UpdateApplication, Int(1)],  # Anyone can update!
          [Txn.on_completion() == OnComplete.DeleteApplication, Int(1)],  # Anyone can delete!
      )
      
      # VULNERABLE: Weak access control
      If(Txn.on_completion() == OnComplete.UpdateApplication,
          Int(1))  # Missing sender validation
      ```
      
      **What to Check**:
      - [ ] `UpdateApplication` checks `Txn.sender() == creator/admin`
      - [ ] `DeleteApplication` checks `Txn.sender() == creator/admin`
      - [ ] OR explicitly disable updates/deletes: `Return(Int(0))`
      - [ ] OnComplete field validated for all application calls
      
      **Mitigation**:
      ```python
      # SECURE: Proper access control
      is_creator = Txn.sender() == Global.creator_address()
      
      program = Cond(
          [Txn.application_id() == Int(0), on_creation],
          [Txn.on_completion() == OnComplete.UpdateApplication, is_creator],
          [Txn.on_completion() == OnComplete.DeleteApplication, is_creator],
      )
      
      # OR: Disable updates entirely
      [Txn.on_completion() == OnComplete.UpdateApplication, Return(Int(0))],
      ```
      
      **Tool Detection**: Tealer detector `update-application-check` available
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/access_controls
      
      ---
      
      ### 4.8 ASSET ID VERIFICATION ⚠️ HIGH
      
      **Description**: Missing validation of `Txn.xfer_asset()` allows attackers to transfer wrong/worthless assets instead of expected tokens.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: No asset ID check
      If(And(
          Txn.type_enum() == TxnType.AssetTransfer,
          Txn.asset_amount() >= required_amount,
          # Missing: Txn.xfer_asset() == expected_asset_id
      ))
      
      # VULNERABLE: User-provided asset ID
      def swap(asset_id):  # User controlled!
          return If(Txn.xfer_asset() == asset_id, ...)  # No validation
      ```
      
      **What to Check**:
      - [ ] All asset transfer validations include `Txn.xfer_asset() == expected_asset_id`
      - [ ] Asset IDs stored in global state or hardcoded
      - [ ] No user control over which asset ID is considered valid
      
      **Mitigation**:
      ```python
      # SECURE: Validate asset ID
      expected_asset_id = Int(12345678)  # Or from global state
      Assert(And(
          Txn.type_enum() == TxnType.AssetTransfer,
          Txn.xfer_asset() == expected_asset_id,
          Txn.asset_amount() >= required_amount
      ))
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/asset_id_verification
      
      ---
      
      ### 4.9 DENIAL OF SERVICE (Asset Opt-In) ⚠️ MEDIUM
      
      **Description**: Transferring assets to non-opted-in accounts causes transaction failure, enabling DoS attacks when using push pattern.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: Push pattern for asset distribution
      For(i IN users).Do(
          InnerTxnBuilder.SetFields({
              TxnField.type_enum: TxnType.AssetTransfer,
              TxnField.receiver: users[i],
              TxnField.asset_amount: rewards[i]
          })
      )  # Fails if any user not opted-in, DoS all users
      
      # VULNERABLE: Batch operations with asset transfers
      # Single failure blocks entire batch
      ```
      
      **What to Check**:
      - [ ] Asset distributions use pull pattern (users claim) instead of push
      - [ ] OR batch operations handle opt-in failures gracefully
      - [ ] Critical operations not blocked by asset transfer failures
      
      **Mitigation**:
      ```python
      # SECURE: Pull pattern
      @router.method
      def claim_reward():
          # User initiates, must be opted-in
          amount = App.localGet(Txn.sender(), Bytes("reward"))
          Assert(amount > Int(0))
          # Transfer asset to opted-in user
      
      # BETTER: Users trigger their own transfers
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/dos
      
      ---
      
      ### 4.10 INNER TRANSACTION FEE ⚠️ MEDIUM
      
      **Description**: Inner transactions with unset or non-zero fees drain application balance when fee pooling is used.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: Missing fee field in inner transaction
      InnerTxnBuilder.Begin()
      InnerTxnBuilder.SetFields({
          TxnField.type_enum: TxnType.Payment,
          TxnField.receiver: receiver,
          # Missing: TxnField.fee: Int(0)
      })
      InnerTxnBuilder.Submit()  # Drains app balance for fees!
      
      # VULNERABLE: Non-zero inner transaction fee
      InnerTxnBuilder.SetField(TxnField.fee, Int(1000))  # Drains balance
      ```
      
      **What to Check**:
      - [ ] All inner transactions explicitly set `TxnField.fee: Int(0)`
      - [ ] Fee pooling strategy documented and validated
      - [ ] Internal bookkeeping accounts for any non-zero fees
      
      **Mitigation**:
      ```python
      # SECURE: Explicitly set fee to zero
      InnerTxnBuilder.Begin()
      InnerTxnBuilder.SetFields({
          TxnField.type_enum: TxnType.Payment,
          TxnField.receiver: receiver,
          TxnField.amount: amount,
          TxnField.fee: Int(0),  # Explicit zero fee
      })
      InnerTxnBuilder.Submit()
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/inner_transaction_fee
      
      ---
      
      ### 4.11 CLEAR STATE TRANSACTION ⚠️ HIGH
      
      **Description**: Missing `OnComplete` field validation allows attackers to invoke clear state program instead of approval program, bypassing logic.
      
      **Detection Patterns**:
      ```python
      # VULNERABLE: Only checks transaction type, not OnComplete
      def validate_group():
          return And(
              Gtxn[0].type_enum() == TxnType.Payment,
              Gtxn[1].type_enum() == TxnType.ApplicationCall,  # Could be ClearState!
              # Missing: Gtxn[1].on_completion() == OnComplete.NoOp
          )
      
      # VULNERABLE: Assumes ApplicationCall is approval
      If(Gtxn[i].type_enum() == TxnType.ApplicationCall,
          validate_app_call())  # May be ClearStateProgram
      ```
      
      **What to Check**:
      - [ ] Group transaction validation checks `Gtxn[i].on_completion() == OnComplete.NoOp`
      - [ ] OR explicitly allows specific OnComplete values
      - [ ] Not just checking `TxnType.ApplicationCall` without OnComplete validation
      
      **Mitigation**:
      ```python
      # SECURE: Validate OnComplete field
      def validate_group():
          return And(
              Gtxn[0].type_enum() == TxnType.Payment,
              Gtxn[1].type_enum() == TxnType.ApplicationCall,
              Gtxn[1].on_completion() == OnComplete.NoOp,  # Explicit check
          )
      ```
      
      **References**: building-secure-contracts/not-so-smart-contracts/algorand/clear_state_transaction
      
      ---
      
  • SKILL.md 12.3 KB
    ---
    name: algorand-vulnerability-scanner
    description: Scans Algorand smart contracts for 11 common vulnerabilities including rekeying attacks, unchecked transaction fees, missing field validations, and access control issues. Use when auditing Algorand projects (TEAL/PyTeal).
    ---
    
    # Algorand Vulnerability Scanner
    
    ## 1. Purpose
    
    Systematically scan Algorand smart contracts (TEAL and PyTeal) for platform-specific security vulnerabilities documented in Trail of Bits' "Not So Smart Contracts" database. This skill encodes 11 critical vulnerability patterns unique to Algorand's transaction model.
    
    ## 2. When to Use This Skill
    
    - Auditing Algorand smart contracts (stateful applications or smart signatures)
    - Reviewing TEAL assembly or PyTeal code
    - Pre-audit security assessment of Algorand projects
    - Validating fixes for reported Algorand vulnerabilities
    - Training team on Algorand-specific security patterns
    
    ## 3. Platform Detection
    
    ### File Extensions & Indicators
    - **TEAL files**: `.teal`
    - **PyTeal files**: `.py` with PyTeal imports
    
    ### Language/Framework Markers
    ```python
    # PyTeal indicators
    from pyteal import *
    from algosdk import *
    
    # Common patterns
    Txn, Gtxn, Global, InnerTxnBuilder
    OnComplete, ApplicationCall, TxnType
    @router.method, @Subroutine
    ```
    
    ### Project Structure
    - `approval_program.py` / `clear_program.py`
    - `contract.teal` / `signature.teal`
    - References to Algorand SDK or Beaker framework
    
    ### Tool Support
    - **Tealer**: Trail of Bits static analyzer for Algorand
    - Installation: `uv tool install tealer` (ensure uv's tool bin dir is on PATH)
    - Usage: `tealer contract.teal --detect all`
    
    ---
    
    ## 4. How This Skill Works
    
    When invoked, I will:
    
    1. **Search your codebase** for TEAL/PyTeal files
    2. **Analyze each file** for the 11 vulnerability patterns
    3. **Report findings** with file references and severity, above them a coverage table carrying a verdict for every pattern
    4. **Provide fixes** for each identified issue
    5. **Run Tealer** (if installed) for automated detection
    
    ---
    
    ## 5. Example Output
    
    When vulnerabilities are found, you'll get a report like this:
    
    ```
    === 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. Vulnerability Patterns (11 Patterns)
    
    I check for 11 critical vulnerability patterns unique to Algorand. For detailed detection patterns, code examples, mitigations, and testing strategies, see [VULNERABILITY_PATTERNS.md](resources/VULNERABILITY_PATTERNS.md).
    
    ### Pattern Summary:
    
    1. **Rekeying Attack** ⚠️ CRITICAL - Unchecked RekeyTo field
    2. **Unchecked Transaction Fee** ⚠️ HIGH - Fee not validated in smart signatures
    3. **Closing Account (CloseRemainderTo)** ⚠️ CRITICAL - Unchecked CloseRemainderTo drains the account
    4. **Closing Asset (AssetCloseTo)** ⚠️ CRITICAL - Unchecked AssetCloseTo drains the asset holding
    5. **Group Size Check** ⚠️ HIGH - No `Global.group_size()` validation on atomic groups
    6. **Time-Based Replay Attack** ⚠️ MEDIUM - No lease or round-range bound
    7. **Access Controls** ⚠️ CRITICAL - Update/delete and privileged calls unprotected
    8. **Asset ID Verification** ⚠️ HIGH - Asset ID not validated in asset operations
    9. **Denial of Service (Asset Opt-In)** ⚠️ MEDIUM - Push transfers strand on un-opted accounts
    10. **Inner Transaction Fee** ⚠️ MEDIUM - Inner fee not explicitly set to 0
    11. **Clear State Transaction** ⚠️ HIGH - Clear state program cannot reject, state left inconsistent
    
    For complete vulnerability patterns with code examples, see [VULNERABILITY_PATTERNS.md](resources/VULNERABILITY_PATTERNS.md).
    
    ## 7. Scanning Workflow
    
    ### Step 1: Platform Identification
    1. Confirm file extensions (`.teal`, `.py`)
    2. Identify framework (PyTeal, Beaker, pure TEAL)
    3. Determine contract type (stateful application vs smart signature)
    4. Locate approval and clear state programs
    
    ### Step 2: Static Analysis with Tealer
    ```bash
    # Run Tealer on contract
    tealer contract.teal --detect all
    
    # Or specific detectors
    tealer contract.teal --detect unprotected-rekey,group-size-check,update-application-check
    ```
    
    ### Step 3: Manual Vulnerability Sweep
    For each of the 11 vulnerabilities above:
    1. Search for relevant transaction field usage
    2. Verify validation logic exists
    3. Check for bypass conditions
    4. Validate inner transaction handling
    
    ### Step 4: Transaction Field Validation Matrix
    Create checklist for all transaction types used:
    
    **Payment Transactions**:
    - [ ] RekeyTo validated
    - [ ] CloseRemainderTo validated
    - [ ] Fee validated (if smart signature)
    
    **Asset Transfers**:
    - [ ] Asset ID validated
    - [ ] AssetCloseTo validated
    - [ ] RekeyTo validated
    
    **Application Calls**:
    - [ ] OnComplete validated
    - [ ] Access controls enforced
    - [ ] Group size validated
    
    **Inner Transactions**:
    - [ ] Fee explicitly set to 0
    - [ ] RekeyTo not user-controlled (Teal v6+)
    - [ ] All fields validated
    
    ### Step 5: Group Transaction Analysis
    For atomic transaction groups:
    1. Validate `Global.group_size()` checks
    2. Review absolute vs relative indexing
    3. Check for replay protection (Lease field)
    4. Verify OnComplete fields for ApplicationCalls in group
    
    ### Step 6: Access Control Review
    - [ ] Creator/admin privileges properly enforced
    - [ ] Update/delete operations protected
    - [ ] Sensitive functions have authorization checks
    
    ---
    
    ## 8. Reporting Format
    
    ### Coverage Table
    
    Report on every pattern in §6, whether or not it turned anything up. Emit this table above the findings, with
    all 11 rows present:
    
    | # | Pattern | Verdict | Evidence |
    |---|---------|---------|----------|
    | 1 | Rekeying Attack | `found` | `approval.py:45` -- no `Txn.rekey_to()` assertion on the payment branch |
    | 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 | | |
    
    Each verdict is one of:
    
    - **`found`** — cite `file:line` and write the finding up in full below.
    - **`clear`** — the pattern applies to this contract and the contract handles it. Name the field, opcode, or
      check you searched for, so a reader can repeat the search.
    - **`n/a`** — the pattern cannot apply here. Give the reason in one clause ("no inner transactions in this
      contract"). Not having looked is not `n/a`.
    
    A table with fewer than 11 rows is an incomplete scan and must be reported as one. A row whose Verdict cell is empty is incomplete in the same way: row 1 above is filled in to show the shape, and every row is filled in the same way before the report is done. Eleven `clear` verdicts is
    a result a reader can act on. A report that covers four patterns and says nothing about the other seven reads
    exactly like a clean contract, and that is the failure this table exists to prevent.
    
    ### Finding Template
    ````markdown
    ## [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. Priority Guidelines
    
    ### Critical (Immediate Fix Required)
    - Rekeying attacks
    - CloseRemainderTo / AssetCloseTo issues
    - Access control bypasses
    
    ### High (Fix Before Deployment)
    - Unchecked transaction fees
    - Asset ID validation issues
    - Group size validation
    - Clear state transaction checks
    
    ### Medium (Address in Audit)
    - Inner transaction fee issues
    - Time-based replay attacks
    - DoS via asset opt-in
    
    ---
    
    ## 10. Testing Recommendations
    
    ### Unit Tests Required
    - Test each vulnerability scenario with PoC exploit
    - Verify fixes prevent exploitation
    - Test edge cases (group size = 0, empty addresses, etc.)
    
    ### Tealer Integration
    ```bash
    # 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
    ```
    
    ### Scenario Testing
    - Submit transactions with all critical fields manipulated
    - Test atomic groups with unexpected sizes
    - Attempt access control bypasses
    - Verify inner transaction fee handling
    
    ---
    
    ## 11. Additional Resources
    
    - **Building Secure Contracts**: `building-secure-contracts/not-so-smart-contracts/algorand/`
    - **Tealer Documentation**: https://github.com/crytic/tealer
    - **Algorand Developer Docs**: https://developer.algorand.org/docs/
    - **PyTeal Documentation**: https://pyteal.readthedocs.io/
    
    ---
    
    ## 12. Quick Reference Checklist
    
    Before completing Algorand audit, verify ALL items checked:
    
    - [ ] RekeyTo validated in all transaction types
    - [ ] CloseRemainderTo validated in payment transactions
    - [ ] AssetCloseTo validated in asset transfers
    - [ ] Transaction fees validated (smart signatures)
    - [ ] Group size validated for atomic transactions
    - [ ] Lease field used for replay protection (where applicable)
    - [ ] Access controls on Update/Delete operations
    - [ ] Asset ID validated in all asset operations
    - [ ] Asset transfers use pull pattern to avoid DoS
    - [ ] Inner transaction fees explicitly set to 0
    - [ ] OnComplete field validated for ApplicationCall transactions
    - [ ] Tealer scan completed with no critical/high findings
    - [ ] Unit tests cover all vulnerability scenarios
    - [ ] Coverage table emitted with all 11 rows, each carrying a verdict of `found`, `clear` or `n/a` with a reason
    
    ---
    
    ## 13. Rationalizations to Reject
    
    - **"The contract is small, so most patterns obviously don't apply."** Obvious to whom? An `n/a` costs one
      clause and makes the judgment reviewable. Silence records nothing, and a reader cannot tell it apart from
      not having checked.
    - **"Tealer reported nothing, so the contract is clean."** Tealer covers a subset of these 11 patterns and
      does not reach the logic-level ones at all. A clean tool run is one row of evidence, not a verdict on the
      patterns it never examined. Say which patterns it covered.
    - **"I checked the patterns that matter for this contract."** Deciding which patterns matter *is* the scan,
      not a precondition for starting it. Rank by severity after the table is complete, not by leaving rows out.
    - **"No findings, so there is nothing to report."** A zero-finding scan still emits the full coverage table.
      That table is the deliverable: it is what distinguishes a contract that was examined from one that was
      glanced at.
    - **"PyTeal/Beaker handles this."** Name the version and the mechanism. Framework defaults change between
      releases, and a framework that covers a pattern on one call path often does not on another.
    - **"The RekeyTo check is in the other program."** Then cite it. A validation you believe exists elsewhere is
      an assumption until you have the `file:line`, and split-program contracts are where these checks go missing.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related