Add not-so-smart-contracts for algorand

Author: Vara Prasad Bandaru

not-so-smart-contracts/algorand/README.md

@@ -0,0 +1,33 @@
+# (Not So) Smart Contracts
+
+This repository contains examples of common Algorand smart contract vulnerabilities, including code from real smart contracts. Use Not So Smart Contracts to learn about Algorand vulnerabilities, as a reference when performing security reviews, and as a benchmark for security and analysis tools.
+
+## Features
+
+Each _Not So Smart Contract_ includes a standard set of information:
+
+* Description of the vulnerability type
+* Attack scenarios to exploit the vulnerability
+* Recommendations to eliminate or mitigate the vulnerability
+* Real-world contracts that exhibit the flaw
+* References to third-party resources with more information
+
+## Vulnerabilities
+
+| Not So Smart Contract | Description |
+| --- | --- |
+| [Rekeying](rekeying) | Smart signatures are rekeyable |
+| [Unchecked Transaction Fees](unchecked_transaction_fee) | Attacker sets excessive fees for smart signature transactions |
+| [Closing Account](closing_account) | Attacker closes smart signature accounts |
+| [Closing Asset](closing_asset) | Attacker transfers entire asset balance of a smart signature |
+| [Group Size Check](group_size_check) | Contract does not check transaction group size |
+| [Time-based Replay Attack](time_based_replay_attack) | Contract does not use lease for periodic payments |
+| [Access Controls](access_controls) | Contract does not enfore access controls for updating and deleting application | 
+| [Asset Id Check](asset_id_check) | Contract does not check asset id for asset transfer operations |
+| [Denial of Service](denial_of_service) | Attacker stalls contract execution by opting out of a asset |
+
+## Credits
+
+These examples are developed and maintained by [Trail of Bits](https://www.trailofbits.com/).
+
+If you have questions, problems, or just want to learn more, then join the #ethereum channel on the [Empire Hacking Slack](https://empireslacking.herokuapp.com/) or [contact us](https://www.trailofbits.com/contact/) directly.

not-so-smart-contracts/algorand/access_controls/README.md

@@ -0,0 +1,18 @@
+# Access Controls
+
+Lack of appropriate checks for application calls of type UpdateApplication and DeleteApplication allows attackers to update application’s code or delete an application entirely.
+
+## Description
+
+When an application call is successful, additional operations are executed based on the OnComplete field. If the OnComplete field is set to UpdateApplication the approval and clear programs of the application are replaced with the programs specified in the transaction. Similarly, if the OnComplete field is set to DeleteApplication, application parameters are deleted. 
+This allows attackers to update or delete the application if proper access controls are not enforced in the application.
+
+## Exploit Scenarios
+
+A stateful contract serves as a liquidity pool for a pair of tokens. Users can deposit the tokens to get the liquidity tokens and can get back their funds with rewards through a burn operation. The contract does not enforce restrictions for UpdateApplication type application calls. Attacker updates the approval program with a malicious program that transfers all assets in the pool to the attacker's address.
+
+## Recommendations
+
+- Set proper access controls and apply various checks before approving applications calls of type UpdateApplication and DeleteApplication.
+
+- Use [Tealer](https://github.com/crytic/tealer) to detect this issue.

not-so-smart-contracts/algorand/asset_id_check/README.md

@@ -0,0 +1,38 @@
+# Asset Id Check
+
+Lack of verification of asset id in the contract allows attackers to transfer a different asset in place of the expected asset and mislead the application.
+
+## Description
+
+Contracts accepting and doing operations based on the assets transferred to the contract must verify that the transferred asset is the expected asset by checking the asset Id. Absence of check for expected asset Id could allow attackers to manipulate contract’s logic by transferring a fake, less or more valuable asset instead of the correct asset.
+
+## Exploit Scenarios
+
+- A liquidity pool contract mints liquidity tokens on deposit of two tokens. Contract does not check that the asset Ids in the two asset transfer transactions are correct. Attacker deposits the same less valuable asset in the two transactions and withdraws both tokens by burning the pool tokens.
+- User creates a delegate signature that allows recurring transfers of a certain asset. Attacker creates a valid asset transfer transaction of more valuable assets.
+
+## Examples
+
+Note: This code contains several other vulnerabilities, see [Rekeying](../rekeying), [Unchecked Transaction Fees](../unchecked_transaction_fee), [Closing Asset](../closing_asset), [Time-based Replay Attack](../time_based_replay_attack).
+
+```py
+def withdraw_asset(
+    duration,
+    period,
+    amount,
+    receiver,
+    timeout,
+):
+    return And(
+        Txn.type_enum() == TxnType.AssetTransfer,
+        Txn.first_valid() % period == Int(0),
+        Txn.last_valid() == Txn.first_valid() + duration,
+        Txn.asset_receiver() == receiver,
+        Txn.asset_amount() == amount,
+        Txn.first_valid() < timeout,
+    )
+```
+
+## Recommendations
+
+Verify the asset id to be expected asset for all asset related operations in the contract.

not-so-smart-contracts/algorand/closing_account/README.md

@@ -0,0 +1,39 @@
+# Closing Account
+
+Lack of check for CloseRemainderTo transaction field in smart signatures allows attackers to transfer entire funds of the contract account or the delegator’s account to their account.
+
+## Description
+
+Algorand accounts must satisfy minimum balance requirement and protocol rejects transactions whose execution results in account balance lower than the required minimum. In order to transfer the entire balance and close the account, users should use the CloseRemainderTo field of a payment transaction. Setting the CloseRemainderTo field transfers the entire account balance remaining after transaction execution to the specified address.
+
+Any user with access to the smart signature may construct and submit the transactions using the smart signature. The smart signatures approving payment transactions have to ensure that the CloseRemainderTo field is set to the ZeroAddress or any other specific address to avoid unintended transfer of funds.
+
+## Exploit Scenarios
+
+A user creates a delegate signature for recurring payments. Attacker creates a valid transaction and sets the CloseRemainderTo field to their address.
+
+## Examples
+
+Note: This code contains several other vulnerabilities, see [Rekeying](../rekeying), [Unchecked Transaction Fees](../unchecked_transaction_fee), [Time-based Replay Attack](../time_based_replay_attack).
+
+```py
+def withdraw(
+    duration,
+    period,
+    amount,
+    receiver,
+    timeout,
+):
+    return And(
+        Txn.type_enum() == TxnType.Payment,
+        Txn.first_valid() % period == Int(0),
+        Txn.last_valid() == Txn.first_valid() + duration,
+        Txn.receiver() == receiver,
+        Txn.amount() == amount,
+        Txn.first_valid() < timeout,
+    )
+```
+
+## Recommendations
+
+Verify that the CloseRemainderTo field is set to the ZeroAddress or to any intended address before approving the transaction in the Teal contract.

not-so-smart-contracts/algorand/closing_asset/README.md

@@ -0,0 +1,39 @@
+# Closing Asset
+
+Lack of check for AssetCloseTo transaction field in smart signatures allows attackers to transfer the entire asset balance of the contract account or the delegator’s account to their account.
+
+## Description
+
+Algorand supports Fungible and Non Fungible Tokens using Algorand Standard Assets(ASA). An Algorand account must first opti-in to the asset before that account can receive any tokens. Opting to an asset increases the minimum balance requirement of the account. Users can opt-out of the asset and decrease the minimum balance requirement using the AssetCloseTo field of Asset Transfer transaction. Setting the AssetCloseTo field transfers the account’s entire token balance remaining after transaction execution to the specified address.
+
+Any user with access to the smart signature may construct and submit the transactions using the smart signature. The smart signatures approving asset transfer transactions have to ensure that the AssetCloseTo field is set to the ZeroAddress or any other specific address to avoid unintended transfer of tokens.
+
+## Exploit Scenarios
+
+User creates a delegate signature that allows recurring transfers of a certain asset. Attacker creates a valid asset transfer transaction with AssetCloseTo field set to their address.
+
+## Examples
+
+Note: This code contains several other vulnerabilities, see [Rekeying](../rekeying), [Unchecked Transaction Fees](../unchecked_transaction_fee), [Closing Asset](../closing_asset), [Time-based Replay Attack](../time_based_replay_attack), [Asset Id Check](../asset_id_check).
+
+```py
+def withdraw_asset(
+    duration,
+    period,
+    amount,
+    receiver,
+    timeout,
+):
+    return And(
+        Txn.type_enum() == TxnType.AssetTransfer,
+        Txn.first_valid() % period == Int(0),
+        Txn.last_valid() == Txn.first_valid() + duration,
+        Txn.asset_receiver() == receiver,
+        Txn.asset_amount() == amount,
+        Txn.first_valid() < timeout,
+    )
+```
+
+## Recommendations
+
+Verify that the AssetCloseTo field is set to the ZeroAddress or to the intended address before approving the transaction in the Teal contract.

not-so-smart-contracts/algorand/denial_of_service/README.md

@@ -0,0 +1,40 @@
+# Denial of Service
+
+When a contract does not verify whether an account has opted in to an asset and attempts to transfer that asset, an attacker can DoS other users if the contract's operation is to transfer asset to multiple accounts. 
+
+## Description
+
+A user must explicitly opt-in to receive any particular Algorand Standard Asset(ASAs). A user may also opt out of an ASA. A transaction will fail if it attempts to transfer tokens to an account that didn’t opt in to that asset. This could be leveraged by attackers to DOS a contract if the contract’s operation depends on successful transfer of an asset to the attacker owned address. 
+
+## Exploit Scenarios
+
+Contract attempts to transfer assets to multiple users. One user is not opted in to the asset. The transfer operation fails for all users.
+
+## Examples
+
+Note: This code contains several other vulnerabilities, see [Rekeying](../rekeying), [Unchecked Transaction Fees](../unchecked_transaction_fee), [Closing Asset](../closing_asset), [Group Size Check](../group_size_check), [Time-based Replay Attack](../time_based_replay_attack), [Asset Id Check](../asset_id_check)
+
+```py
+def split_and_withdraw_asset(
+    amount_1,
+    receiver_1,
+    amount_2,
+    receiver_2,
+    lock_expire_round,
+):
+    return And(
+        Gtxn[0].type_enum() == TxnType.AssetTransfer,
+        Gtxn[0].asset_receiver() == receiver_1,
+        Gtxn[0].asset_amount() == amount_1,
+
+        Gtxn[1].type_enum() == TxnType.AssetTransfer,
+        Gtxn[1].receiver() == receiver_2,
+        Gtxn[1].amount() == amount_2,
+
+        Gtxn[0].first_valid == lock_expire_round,
+    )
+```
+
+## Recommendations
+
+Use pull over push pattern for transferring assets to users.

not-so-smart-contracts/algorand/group_size_check/README.md

@@ -0,0 +1,42 @@
+# Group Size Check
+
+Lack of group size check in contracts that are supposed to be called in an atomic group transaction might allow attackers to misuse the application.
+
+## Description
+
+Algorand supports atomic transfers, an atomic transfer is a group of transactions that are submitted and processed as a single transaction. A group can contain upto 16 transactions and the group transaction fails if any of the included transactions fails. Algorand applications make use of group transactions to realize operations that may not be possible using a single transaction model. In such cases, it is necessary to check that the group transaction in itself is valid along with the individual transactions. One of the checks whose absence could be misused is group size check.
+
+## Exploit Scenarios
+
+Application only checks that transactions at particular indices are meeting the criteria and performs the operations based on that. Attackers can create the transactions at the checked indices correctly and include equivalent application call transactions at all the remaining indices. Each application call executes successfully as every execution checks the same set of transactions. This results in performing operations multiple times, once for each application call. This could be damaging if those operations include funds or assets transfers among others.
+
+## Examples
+
+Note: This code contains several other vulnerabilities, see [Rekeying](../rekeying), [Unchecked Transaction Fees](../unchecked_transaction_fee), [Closing Account](../closing_account), [Time-based Replay Attack](../time_based_replay_attack).
+
+```py
+def split_and_withdraw(
+    amount_1,
+    receiver_1,
+    amount_2,
+    receiver_2,
+    lock_expire_round,
+):
+    return And(
+        Gtxn[0].type_enum() == TxnType.Payment,
+        Gtxn[0].receiver() == receiver_1,
+        Gtxn[0].amount() == amount_1,
+
+        Gtxn[1].type_enum() == TxnType.Payment,
+        Gtxn[1].receiver() == receiver_2,
+        Gtxn[1].amount() == amount_2,
+
+        Gtxn[0].first_valid == lock_expire_round,
+    )
+```
+
+## Recommendations
+
+- Verify that the group size of an atomic transfer is the intended size in the contracts.
+
+- Use [Tealer](https://github.com/crytic/tealer) to detect this issue.

not-so-smart-contracts/algorand/rekeying/README.md

@@ -0,0 +1,45 @@
+# Rekeying
+
+The lack of check for RekeyTo field in the Teal program allows malicious actors to rekey the associated account and control the account assets directly, bypassing the restrictions imposed by the Teal contract.
+
+## Description
+
+Rekeying is an Algorand feature which allows a user to transfer the authorization power of their account to a different account. When an account has been rekeyed, all the future transactions from that account are accepted by the blockchain, if and only if the transaction has been authorized by the rekeyed account.
+
+A user can rekey their account to the selected account by sending a rekey-to transaction with rekey-to field set to the target account address. A rekey-to transaction is atransaction which has the rekey-to field set to a well formed Algorand address.
+Any algorand account can be rekeyed by sending a rekey-to transaction from that account, this includes the contract accounts.
+
+Contract accounts are accounts which are derived from the Teal code that is in control of that account. Anyone can set the fields and submit a transaction from the contract account as long as it passes the checks enforced in the Teal code. This results in an issue if the Teal code is supposed to approve a transaction that passes specific checks and does not check the rekey-to field. A malicious user can first send a transaction approved by the Teal code with rekey-to set to their account. After rekeying, the attacker can transfer the assets, algos directly by authorizing the transactions with their private key.
+
+Similar issue affects the accounts that created a delegate signature by signing a Teal program. Delegator is only needed to sign the contract and any user with access to delegate signature can construct and submit transactions. Because of this, a malicious user can rekey the sender’s account if the Teal logic accepts a transaction with the rekey-to field set to the user controlled address.
+
+## Exploit Scenarios
+
+A user creates a delegate signature for recurring payments. Attacker rekeys the sender’s account by specifying the rekey-to field in a valid payment transaction.
+
+## Example
+
+Note: This code contains several other vulnerabilities, [Unchecked Transaction Fees](../unchecked_transaction_fee), [Closing Account](../closing_account), [Time-based Replay Attack](../time_based_replay_attack).
+
+```py
+def withdraw(
+    duration,
+    period,
+    amount,
+    receiver,
+    timeout,
+):
+    return And(
+        Txn.type_enum() == TxnType.Payment,
+        Txn.first_valid() % period == Int(0),
+        Txn.last_valid() == Txn.first_valid() + duration,
+        Txn.receiver() == receiver,
+        Txn.amount() == amount,
+        Txn.first_valid() < timeout,
+    )
+```
+
+## Recommendations
+- For the Teal programs written in Teal version 2 or greater, either used as delegate signature or contract account, include a check in the program that verifies rekey-to field to be equal to ZeroAddress or any intended address. Teal contracts written in Teal version 1 are not affected by this issue. Rekeying feature is introduced in version 2 and Algorand rejects transactions that use features introduced in the versions later than the executed Teal program version.
+
+- Use [Tealer](https://github.com/crytic/tealer) to detect this issue.

not-so-smart-contracts/algorand/time_based_replay_attack/README.md

@@ -0,0 +1,39 @@
+# Time-based Replay Attack
+
+Lack of check for lease field in smart signatures that intend to approve a single transaction in the particular period allows attackers to submit multiple valid transactions in that period. 
+
+## Description
+
+Algorand stops transaction replay attacks using a validity period. A validity period of a transaction is the sequence of blocks between FirstValid block and LastValid block. The transaction is considered valid only in that period and a transaction with the same hash can be processed only once in that period. Algorand also limits the period to a maximum of 1000 blocks. This allows the transaction creator to select the FirstValid, LastValid fields appropriately and feel assured that the transaction is processed only once in that period.
+
+However, The same does not apply for transactions authorized by smart signatures. Even if the contract developer verifies the FirstValid and LastValid transaction fields to fixed values, an attacker can submit multiple transactions that are valid as per the contract. This is because any user can create and submit transactions authorized by a smart signature. The attacker can create transactions which have equal values for most transaction fields, for fields verified in the contract and slightly different values for the rest. Each one of these transactions will have a different hash and will be accepted by the protocol.
+
+## Exploit Scenarios
+
+A user creates a delegate signature for recurring payments. Contract verifies the FirstValid and LastValid to only allow a single transaction each time. Attacker creates and submits multiple valid transactions with different hashes.
+
+## Examples
+
+Note: This code contains several other vulnerabilities, see [Rekeying](../rekeying), [Unchecked Transaction Fees](../unchecked_transaction_fee), [Closing Account](../closing_account).
+
+```py
+def withdraw(
+    duration,
+    period,
+    amount,
+    receiver,
+    timeout,
+):
+    return And(
+        Txn.type_enum() == TxnType.Payment,
+        Txn.first_valid() % period == Int(0),
+        Txn.last_valid() == Txn.first_valid() + duration,
+        Txn.receiver() == receiver,
+        Txn.amount() == amount,
+        Txn.first_valid() < timeout,
+    )
+```
+
+## Recommendations
+
+Verify that the Lease field of the transaction is set to a specific value. Lease enforces mutual exclusion, once a transaction with non-zero lease is confirmed by the protocol, no other transactions with same lease and sender will be accepted till the LastValid block