Merge branch 'master' into release

Author: montyly

.github/dependabot.yml

@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "daily"

.github/workflows/ci.yml

@@ -12,17 +12,17 @@ on:
 
 jobs:
   tests:
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-22.04
     strategy:
       fail-fast: false
       matrix:
         type: ["slither", "manticore"]
     steps:
-    - uses: actions/checkout@v1
-    - name: Set up Python 3.6
-      uses: actions/setup-python@v1
+    - uses: actions/checkout@v3
+    - name: Set up Python 3.8
+      uses: actions/setup-python@v4
       with:
-        python-version: 3.6
+        python-version: 3.8
     - name: Install dependencies
       run: |
         sudo wget -O /usr/bin/solc https://github.com/ethereum/solidity/releases/download/v0.5.11/solc-static-linux

.github/workflows/echidna.yml

@@ -14,7 +14,7 @@ jobs:
   tests:
     name: ${{ matrix.name }}
     continue-on-error: ${{ matrix.flaky == true }}
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-22.04
     strategy:
       fail-fast: false
       matrix:

development-guidelines/guidelines.md

@@ -2,19 +2,20 @@
 
 Follow these high-level recommendations to build more secure smart contracts.
 
-* [Design (before development)](#design-guidelines)
-  * [Documentation and specifications](#documentation-and-specifications)
-  * [On-chain vs off-chain computation](#on-chain-vs-off-chain-computation)
-  * [Upgradeability](#upgradeability)
-* [Implementation (during development)](#implementation-guidelines)
-  * [Function composition](#function-composition)
-  * [Inheritance](#inheritance)
-  * [Events](#events)
-  * [Avoid known pitfalls](#avoid-known-pitfalls)
-  * [Dependencies](#dependencies)
-  * [Testing and verification](#testing-and-verification)
-  * [Solidity](#solidity)
-* [Deploymnent (after development)](#deployment-guidelines)
+- [Development Guidelines](#development-guidelines)
+  - [Design guidelines](#design-guidelines)
+    - [Documentation and specifications](#documentation-and-specifications)
+    - [On-chain vs off-chain computation](#on-chain-vs-off-chain-computation)
+    - [Upgradeability](#upgradeability)
+  - [Implementation guidelines](#implementation-guidelines)
+    - [Function composition](#function-composition)
+    - [Inheritance](#inheritance)
+    - [Events](#events)
+    - [Avoid known pitfalls](#avoid-known-pitfalls)
+    - [Dependencies](#dependencies)
+    - [Testing and verification](#testing-and-verification)
+    - [Solidity](#solidity)
+  - [Deployment guidelines](#deployment-guidelines)
 
 ## Design guidelines
 
@@ -76,13 +77,12 @@ The architecture of your codebase should make your code easy to review. Avoid ar
 ### Testing and verification
 
 - **Write thorough unit-tests.** An extensive test suite is crucial to build high-quality software. 
-- **Write [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) and [Manticore](https://github.com/trailofbits/manticore) custom checks and properties.** Automated tools will help ensure your contract is secure. Review the rest of this guide to learn how to write efficient checks and properties.
-- **Use [crytic.io](https://crytic.io/).** Crytic integrates with Github, provides access to private Slither detectors, and runs custom property checks from Echidna.
+- **Write [Slither](https://github.com/crytic/slither) and [Echidna](https://github.com/crytic/echidna) custom checks and properties.** Automated tools will help ensure your contract is secure. Review the rest of this guide to learn how to write efficient checks and properties.
 
 ### Solidity
 
-- **Favor Solidity 0.5 or 0.6.** In our opinion, Solidity 0.5 and 0.6 are more secure and have better built-in practices than 0.4. Solidity 0.7 is too young to be used in production and needs time to mature.
-- **Use a stable release to compile; use the latest release to check for warnings.** Check that your code has no reported issues with the latest compiler version. However, Solidity has a fast release cycle and has a history of compiler bugs, so we do not recommend the latest version for deployment (see Slither’s [solc version recommendation](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-39)).
+- **Favor Solidity versions outlined in our [Slither Recommendations](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity)** In our opinion, older Solidity are more secure and have better built-in practices. Newer Solidity versions may be ttoo young to be used in production and require additional time to mature.
+- **Use a stable release to compile; use the latest release to check for warnings.** Check that your code has no reported issues with the latest compiler version. However, Solidity has a fast release cycle and has a history of compiler bugs, so we do not recommend the latest version for deployment (see Slither’s [solc version recommendation](https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity)).
 - **Do not use inline assembly.** Assembly requires EVM expertise. Do not write EVM code if you have not _mastered_ the yellow paper.
 
 ## Deployment guidelines

development-guidelines/incident_response.md

@@ -18,4 +18,13 @@ Here, we provide recommendations around the formulation of an incident response
   - Consider adding more resilient solutions for detection and mitigation, especially in terms of specific alternate endpoints and queries for different data as well as status pages and support contacts for affected services.
 - [ ] **Combine issues and determine whether new detection and mitigation scenarios are needed.**
 - [ ] **Perform periodic dry runs of specific scenarios in the incident response plan to find gaps and opportunities for improvement and to develop muscle memory.**
-  - Document the intervals at which the team should perform dry runs of the various scenarios. For scenarios that are more likely to happen, perform dry runs more regularly. Create a template to be filled in after a dry run to describe the improvements that need to be made to the incident response.  
+  - Document the intervals at which the team should perform dry runs of the various scenarios. For scenarios that are more likely to happen, perform dry runs more regularly. Create a template to be filled in after a dry run to describe the improvements that need to be made to the incident response.  
+
+## Incident Response Plan Resources 
+
+- [How to Hack the Yield Protocol](https://docs.yieldprotocol.com/#/operations/how_to_hack)
+- [Emergency Steps – Yearn](https://github.com/yearn/yearn-devdocs/blob/master/docs/developers/v2/EMERGENCY.md)
+
+## Well-handled IR Incidents 
+
+- [Yield Protocol](https://medium.com/yield-protocol/post-mortem-of-incident-on-august-5th-2022-7bb70dbb9ada)

development-guidelines/workflow.md

@@ -34,7 +34,7 @@ Finally, be mindful of issues that automated tools cannot easily find:
 
 ## Ask for help
 
-[Ethereum office hours](https://calendly.com/dan-trailofbits/office-hours) run every Tuesday afternoon. These 1-hour, 1-on-1 sessions are an opportunity to ask us any questions you have about security, troubleshoot using our tools, and get feedback from experts about your current approach. We will help you work through this guide.
+[Office Hours](https://calendly.com/trail-of-bits-sales/trail-of-bits-office-hours) run every Tuesday afternoon. These 1-hour, 1-on-1 sessions are an opportunity to ask us any questions you have about security, troubleshoot using our tools, and get feedback from experts about your current approach. We will help you work through this guide.
 
 Join our Slack: [Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw). We're always available in the #crytic and #ethereum channels if you have any questions.
 

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.