Web3 Threat Modeling

This repo comprises of material related to threat modelling of web3 Components and other Blockchain related Ecosystem.

Approach

In this threat analysis, the focus is primarily on dissecting the functional aspects of various web3 components, including NFT marketplaces, DAOs, Bridges, Dex. Recognizing that each component possesses a set of common functionalities, the analysis meticulously explores the potential security vulnerabilities and threats associated with these functionalities. The approach adopts a systematic examination of each functionality in its operational context to unveil risks. The culmination of this analysis presents a comprehensive understanding of the threat landscape within the web3 ecosystem, based on its constituent functionalities.

NFT MarketPlace

Buy	Sell	Mint	List	Unlist
Re-entrancy	Reentrancy	ACP Implementation	Improper Handling Of Token Standard	Front Running
Business Logic	Business Logic	Griefing Attacks	Reentrancy
Matching Order Issues	Matching Order Issues	Tfr to Address(0)	Business Logic
Improper Handling Of Token Standard	Fee Evasion	Fee Evasion	Fee Evasion
Fee Evasion	Griefing Attacks	Business Logic	Arthematical Errors
Unauth Txns	ACP Implementation	SafeMath Checks	Royalty Distribution Issues
Arthematical Errors	Sig Replay	TimeLock Bypass
Gas Refund Issues	Fee Evasion	Poor Randomness
Front Running	Griefing Attacks	Front Running
Governance Manipulation	ACP Implementation
Griefing Attacks	Sig Replay
Mev Attacks	Tfr to Address(0)
Merkle Tree Hash Issue	Front Running
EIP712 Signature Replay	Royalty Distribution Issues
ACP Implementation
Sig Replay
Tfr to Address(0)
Royalty Distribution Issues

DAOs (Decentralized Autonomous Organizations)

Proposal Maker	Voter	Voting Power	Smart Contracts	Oracle	Treasury
Malicious Proposals DAOs beauty is that anyone can submit a proposal. Generally the verification of the proposal lies with the voters and the community. If a Malicious proposal is submiited and not examined and verfied correctly it can have a devastating effects. The classic example to Malicos Proposal Attack is of Tornado Cash in which attacker submitted a malious proposal and gained control over the DAO. Source:https://twitter.com/samczsun/status/1660012956632104960	Double Voting Double Voting refers to the term where an attacker can double vote on a same proposal and affect the outcome of the proposal. This can arise due to the logic flaw in the code of voting code.It is recommended checking the following scenarios: vote → transfer → vote again; vote → delegate → vote again; mangle a vote() arguments to add extra voting power; check for reentrancy.	Flash Loans Attack A Flash Loan Attack is a type of exploit , where an attacker takes advantage of the flash loan feature to manipulate market/protocol conditions. In this type of attack, a malicious actor borrows a large amount of cryptocurrency through a flash loan, uses it to manipulate the market prices of assets, and then repays the loan within the same transaction block. In case of DAOs attacker can use flash loan to gain high amount of voting power and execute proposal in the same block. Example: https://bean.money/blog/beanstalk-governance-exploit https://medium.com/@nvy_0x/the-beanstalk-bean-exploit-b038f4d324ea	Coding Practice Issues	Price Manipulation Oracle Price Manipulation refers to an attack where a malicious actor manipulates the data provided by an oracle to exploit a smart contract or DAO. Many DeFi applications and DAOs rely on this data for critical functions, manipulating an oracle can have severe consequences, including the wrongful distribution of funds or the misrepresentation of asset values. An attacker can manipulate oracle to gain tokens at a low price and get high voting power. An attacker can leverage this to vote on proposal in the DAO	Key Compromise A Private Keys Compromise attack in the context of DAOs occurs when an unauthorized entity gains access to the private keys of participants, especially those who hold significant amounts of governance tokens or who have elevated permissions within the DAO. Private keys are crucial for signing transactions and controlling assets on a blockchain. When private keys are compromised, the attacker essentially gains full control over the associated wallet and can manipulate the DAO by making unauthorized transactions, voting on proposals, or even siphoning funds from the DAO.Keys compromise is considered as END GAME!
Voter Bribing Voter Bribing in DAOs refers to a malicious practice where an entity offers incentives, to members of a Decentralized Autonomous Organization (DAO) in exchange for their voting power or specific voting actions. The intent behind this is usually to manipulate the decision-making process of the DAO to achieve outcomes favorable to the attacker, which may not necessarily be in the best interests of the DAO or its broader community. The likelyhood of this attack depends upon the value to be extracted from the sucessfull exploitation. It should be +ve after the incentives offered to the voters.	51% Attack In terms of DAO 51% Attack refers to the term in which an attacker gains more the 2/3 of the voting power and affects the outcome of the proposal. An attacker pocessing 51% of the voting power can unilateraly pass the proposal. Flash Loan attacks can be considered a type of 51% Attack. Aragon DAO faced the similar attack but averted it https://blog.aragon.org/aragon-repurposes-dao-to-ensure-treasury-serves-its-mission/		Business Logic Issues Business Logic Issues in the context of DAOs refer to vulnerabilities that arise due to flaws in the underlying smart contracts' code or design. Unlike other attacks that exploit the blockchain network, this type of attack takes advantage of unintended consequences of how the smart contract is programmed. It can lead to unauthorized actions, such as the manipulation of votes, fund theft, or unintended distribution of tokens. Example: Yam Finance suffered an issue in it rebase() method due to which after every rebase() $500k worth of yCRV will be added to the YAM treasury. If rebase happens as per the issue ,no further governance actions will possible as so many YAM will be held in the reserve that it will be impossible for any proposals. https://medium.com/yam-finance/save-yam-245598d81cec		Governance Exploit A Governance Takeover attack in the context of DAOs occurs when an entity gains control over a significant portion of the governance tokens, allowing them to unilaterally dictate the decisions and proposals within the DAO. By obtaining a majority or a critical mass of governance tokens, the attacker essentially takes over the governance process, and can then make decisions that benefit themselves at the expense of other participants, such as diverting funds, changing protocols, or making other malicious alterations to the DAO’s operations. Governance Takeover can also be carried out by passing of a malicious proposal proposed by attacker. Example: Takeover of Tornado Cash is a classic example. https://decrypt.co/140932/tornado-cash-governance-attacker-offers-dao-new-lifeline-expensive-lesson
Sybil Attack A Sybil Attack in the context of DAOs is when an attacker creates multiple fake identities, or controls a large number of accounts, in order to exert disproportionate influence over the decision-making process. By flooding the network with these identities, the attacker seeks to manipulate voting or consensus mechanisms in the DAO to their advantage, often at the expense of other participants and the overall health of the system. Example of Sybil Attack can be SteemIt vs Justin Sun , where Sun gained control of the steemit network.Justin Sun, the founder of TRON, acquired Steemit Inc., which was one of the major organizations in the Steem ecosystem. With this acquisition, he also obtained a large quantity of pre-mined STEEM tokens, known as the "Steemit stake," which were originally meant for development and not to be used for governance. Sun used these tokens in conjunction with major exchanges (Binance, Huobi, and Poloniex) to vote in new witnesses, effectively taking over the governance of the Steem blockchain. Many in the community viewed this as a hostile takeover, as it centralized control over a network that was intended to be decentralized. In response, a large portion of the community decided to execute a hard fork to create a new blockchain, Hive, which was essentially a copy of the Steem blockchain but without the Steemit stake. This allowed them to continue with a more decentralized governance model.			Proxy Upgrade Attacks
			Replay Attacks
			Missing proposal validation
			Double Execution In terms of DAO , Double Execution refers to a Smart Contract issue in which an attacker can execute a reentrancy in the execute/vote method of the DAO in the same Block. A theoretical example can be a DAO with voting functionality and in the voting() or execution() there exist a reentrancy and an attacker can abuse it to cause double voting which will eventually affect the output of the proposal.
			Access Control Issue Access control issues refer to a type of security vulnerability that occurs when inadequate controls or restrictions exist on who can access and modify certain resources or data within a system. In terms of DAO an attacker can leverage a misconfigured access control to execute higer leverage methods which can have implication depending upon the methods. Example:DaoMaker was exploited for ~$4m. They left the init function unprotected. The attacker re-initialized the contract with malicious data and then called emergencyExit to get away with the funds. https://twitter.com/Mudit__Gupta/status/1434059922774237185
			Profanity Wallet A vulnerability in Profanity Wallets were identified by 1inch via which it was possible to crack the Private keys of Wallets generated via Profanity Generator. Example: Two projects were hacked via profanity issue FriesDao:https://twitter.com/friesdao/status/1585712229067915264 Wintermute: https://twitter.com/EvgenyGaevoy/status/1572329148411936770 Although Wintermute is not a DAO but the threat is applicable across all type of Blockchain Apps deployed using profanity wallets

Bridges

Swap	Deposit/ Lock	Withdraw/ Unlock	Approve	Mint	Burn	Verify_Func	Pause	Unpause
Insufficient Gas	Chain Rollups	Unauth Unlocking Typically, only the trusted off-chain relayer can authorize unlock actions on the destination chain. However, key leakage caused by traditional cyberattacks or improper access control in on-chain/off-chain codes may allow unauthorized attackers to successfully call the unlock function of the router contract and transfer funds. Example:Ronin Bridge Hack	Access Control Access control issues refer to a type of security vulnerability that occurs when inadequate controls or restrictions exist on who can access and modify certain resources or data within a system. In terms of bridges, if an attacker causes the bridge to mint more tokens than intended, there is an access control issue.	Replay Attacks		Sig Replay Attacks	Access Control	Access Control
Liquidity Drying In liquidity Bridges, Liquidity Drying means that not enough liquidity is available on the destination chain. Hence, if a user attempts to swap a large amount, the swap will not be possible.	Unrestricted Deposit Emitting This bug happens when a user sends a transaction and funds are locked in the contract. Typically, the router contract should lock the sender's tokens before emitting the deposit event E𝑑𝑒𝑝. The relayer will regard E𝑑𝑒𝑝 as proof of locked tokens and authorize unlocking on the destination chain. However, mishandling complex contract interfaces like using unsafe transfer functions may let attackers bypass the lock procedure and trigger a valid deposit event directly.	Cross-Chain Messaging Failure	Checks Bypass	Imbalancement of Src Chain Funds		51% Attack
Fee Evasion On a swap, a protocol/bridge fee is deducted from the transaction. Due to logical bugs, fee evasion issues can occur.
	Chain_id Checks If the destination chain's ID is not properly checked, it can result in the loss of funds and a DOS attack.					Collision attacks
Chain_id DOS *If chain IDs are not whitelisted in a smart contract, it may be vulnerable to various types of attacks or errors. A whitelist is a list of approved or allowed values used to specify which chain IDs are allowed to interact with the contract. This could potentially lead to a variety of problems, such as: •Loss of tokens: If the contract attempts to transfer tokens to an unauthorized chain ID, the tokens may be lost or stolen, and the user will not be able to recover them. •Invalid state: If the contract attempts to transfer tokens to an unauthorized chain ID, the contract's internal state may become inconsistent or invalid. For example, if the contract maintains a record of all token transfers, it may record an invalid transfer to an unauthorized chain ID, which could cause the contract to malfunction or become unresponsive. •Denial of service: If an attacker can call the transfer function with an unauthorized chain ID, they may be able to prevent legitimate users from transferring tokens to certain chain IDs. This could potentially cause a denial of service, as users would not be able to transfer tokens to the affected chain IDs. Overall, a smart contract that does not have a whitelist of allowed chain IDs may be vulnerable to various types of attacks or errors. It is important to include a whitelist of allowed chain IDs to ensure that the contract operates correctly and securely.	Cross-Chain Messaging Failure					Chain Identifications
Business Logic Flaw	Business Logic Flaw
Malicious Token Listing If a bridge allows users to add assets for swapping on multiple chains, a malicious user can add a malicious pair of tokens and trick users into swapping the amount. The attack vector is the same as adding a malicious token pair on Uniswap.
Cross-Chain Messaging Failure Cross-Chain Messaging Failure refers to issues in which an event emitted on Chain A is not properly relayed to Chain B, resulting in the failure of the intended feature, e.g., swap or deposit. Example: Spearbit found an issue in the ConnextNxtp Audit, where Connext was using Multichain v6 for cross-chain messaging. Gas fees need to be paid by either the source or destination chain when the anyCall() method of Multichain is called. However, the anyCall() method was being called without considering the fees, resulting in failure every time.
Address(0) Check In blockchain, anything sent to 0x00 is considered burnt and lost. Checking for address(0) is necessary to prevent the loss of funds and the supply of the token.