Most smart contract developers are familiar with concepts such as ‘reentrancy,’ ‘overflow/underflow,’ and even ‘front-running.’ These are pretty common vulnerabilities that have led to malicious actors stealing millions of dollars for years. However, have most smart contract developers heard of ‘flash loan attacks,’ ‘oracle manipulation,’ and ‘Beacon Chain front-running’? These are just a few examples of attacks that are overlooked but can cause major damage. It is important to share knowledge with the community about these types of vulnerabilities to enhance the security of the blockchain ecosystem.

‍

The first attack vector we are going to look at is flash loans. Flash loans are a concept in DeFi where users can take out large loans without having to provide collateral, as long as they return the funds (usually with some interest) within the same transaction. This sounds great—borrow a lot of funds for free and then pay it back. It’s what happens between the borrow and payback that can be malicious. Flash loan attacks can come in multiple different forms. A common attack is using flash loans for price manipulation. By executing multiple large transactions on an exchange, the attacker can temporarily impact the price of the token pair, causing significant losses for protocols and traders that use these pools for trading. Attackers also use flash loans to take advantage of existing vulnerabilities in contracts. These include overflow attacks as well as reentrancy bugs. For smaller DAOs, which rely heavily on trustlessness, attackers can use flash loans to obtain large amounts of governance tokens and use this to manipulate the protocol. Being able to access large amounts of funds is a powerful tool but needs to be taken into consideration when developing your smart contracts.

‍

Many security engineers are hyper-focused on the blockchain and the EVM and tend to forget about other elements in the world of decentralization, such as Oracles, which form an integral part of many DeFi applications. If these oracles are manipulated, it can lead to undesired results. Just like flash loans, oracle manipulation happens in many different ways, and it is important to understand them all before building protocols that rely on these external sources. Spot price manipulation piggybacks off our flash loan attacks. Protocols that use spot prices on decentralized exchanges (DEX’s) as a form of price discovery are victims of this. An attacker can easily take out a flash loan to drain one side of a liquidity pool, pumping the price of the token they are receiving (increase in demand). This can lead to severe issues for the protocol using the DEX as a form of price discovery, such as a complete drain of funds and an inflated amount of shares to the attacker. Other oracle manipulation examples such as mirroring and freeloading in decentralized oracles are also noticeably important but not covered in this article.

‍

We have all heard of front-running, right? But have we all heard of Beacon Chain front running? This is a specific type of front-running attack that occurs on the Beacon Chain when users stake. Let’s go one step back. In 2022, Ethereum updated its consensus model from Proof of Work (PoW) to Proof of Stake (PoS). This opened Ethereum up to staking, which is the process of spinning up a node on Ethereum to become a validator on the network. Users can stake themselves, but it can become quite pricey considering you need 32 ETH. This led to a rise in liquid staking protocols such as EtherFi and Lido, who pool user ETH together, and when 32 ETH is pooled, they can stake and pair the stake with a node operator who will run the validator. When the stake is submitted to the Beacon Chain, it gets sent along with something called ‘Deposit Data,’ which contains unique information about the stake. One element inside the deposit data is the withdraw credentials, which is an Ethereum address in which all rewards and withdrawals from your validator get sent to. But, based on the architecture of the Beacon Chain, a validator may only have one set of withdrawal credentials, and it will always be the first set submitted. They do not enforce the same withdrawal credentials for subsequent deposits. See any issues yet? A malicious actor, who has access to the information about the deposit, can wait for the liquid staking protocol (LSP) to submit a stake with 32 ETH and front-run the transaction by depositing (staking) their own minimum deposit (1 ETH) into the Beacon Chain with their own set of deposit data that has the same keys and information as the stake coming from the LSP, except with one very important difference—the withdrawal credentials. Now, as soon as the front-run transaction succeeds and gets added to a block, the malicious actor can exit the validator, and where will all the funds be sent? To the first withdrawal credentials that were set—the malicious actor's address.

‍

The reason we put this type of specific attack vector in the article is to show how vast the vulnerabilities in smart contracts can be. There are so many different protocols and systems on the blockchain, and it is extremely important to do your due diligence on any protocol or chain you wish to interact with because they all come with their own set of unique problems, as mentioned above.