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).
Install
npx skills add https://github.com/trailofbits/skills/tree/main/plugins/building-secure-contracts/skills/algorand-vulnerability-scanner
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install trailofbits-skills@llmmart
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:
.pywith 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.pycontract.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:
- Search your codebase for TEAL/PyTeal files
- Analyze each file for the 11 vulnerability patterns
- Report findings with file references and severity, above them a coverage table carrying a verdict for every pattern
- Provide fixes for each identified issue
- 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:
- Rekeying Attack ⚠️ CRITICAL - Unchecked RekeyTo field
- Unchecked Transaction Fee ⚠️ HIGH - Fee not validated in smart signatures
- Closing Account (CloseRemainderTo) ⚠️ CRITICAL - Unchecked CloseRemainderTo drains the account
- Closing Asset (AssetCloseTo) ⚠️ CRITICAL - Unchecked AssetCloseTo drains the asset holding
- Group Size Check ⚠️ HIGH - No
Global.group_size()validation on atomic groups - Time-Based Replay Attack ⚠️ MEDIUM - No lease or round-range bound
- Access Controls ⚠️ CRITICAL - Update/delete and privileged calls unprotected
- Asset ID Verification ⚠️ HIGH - Asset ID not validated in asset operations
- Denial of Service (Asset Opt-In) ⚠️ MEDIUM - Push transfers strand on un-opted accounts
- Inner Transaction Fee ⚠️ MEDIUM - Inner fee not explicitly set to 0
- 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
- Confirm file extensions (
.teal,.py) - Identify framework (PyTeal, Beaker, pure TEAL)
- Determine contract type (stateful application vs smart signature)
- 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:
- Search for relevant transaction field usage
- Verify validation logic exists
- Check for bypass conditions
- 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:
- Validate
Global.group_size()checks - Review absolute vs relative indexing
- Check for replay protection (Lease field)
- 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— citefile:lineand 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 notn/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
- 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,clearorn/awith a reason
13. Rationalizations to Reject
- "The contract is small, so most patterns obviously don't apply." Obvious to whom? An
n/acosts 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.
Reviews (0)
No reviews yet.
No comments yet.