Introduction

With the advent of Web3 and blockchain technology, decentralised applications (DApp) have risen in popularity. Instead of traditional server-client architecture, a DApp can be implemented on a decentralised blockchain platform. Normally the owner of a platform is charged with the responsibility of risk management and by extension cybersecurity, but with a decentralised application, there are no owners; traversing the security of the unregulated cyber frontier of blockchain can be complicated.

Decentralised Computing

Traditional computing is centralised, application services are executed at a central location, and different clients connect to the same centralised location to access resources (i.e. a web application). In this case, the centralised service has ownership of digital resources.
Decentralised computing occurs when application services are executed by nodes on a distributed network with the absence of a central location, like a blockchain or peer to peer network. In the case of a blockchain, nodes on a blockchain contribute resources when mining or validating new blocks, these resources are used to fund transactions and execute programs on the blockchain.

Blockchain & DApps

A blockchain is a decentralised database used as a ledger, it is associated with transactions, recording and distributing each block for cryptocurrencies like bitcoin. Each block requires resources to push operations like transactions on the blockchain, these are contributed by the nodes on the blockchain, referred to as miners or validators depending on the proofing method. Some blockchains support the use of decentralised applications using the resources created when the nodes generate blocks.
Ethereum is a good example of a popular blockchain that supports DApps and will be referenced throughout this paper, Ethereum has a machine called the “Ethereum Virtual Machine” (EVM), all nodes on the network agree on the state of the EVM and keep a copy of it. Nodes can broadcast requests to execute a computation, if successful, the request propagates throughout the network, when agreed on by all nodes it will execute the function.

Program Code

Decentralised apps are open-sourced and stored on decentralised blocks, this way each node can contribute resources to autonomously execute the application. DApps commonly use the Ethereum blockchain and are written as a “smart contract”. So instead of having to write new code every time the EVM makes a computation, a node can just call a reusable function within the smart contract.

Notable DApps

The Ethereum blockchain supports many DApps, for example, Aave and Audius.
Aave is a decentralised financial system, which allows users to lend, borrow, or stake; lenders and borrowers have anonymity and instead of escrow they trust the autonomous smart contract.
Audius is a music streaming DApp comparable to Spotify. Creators are paid with AUDIO tokens when their music is streamed, the DApp does not need to worry about storage or uptime as it is all handled by the resources on the blockchain.

Properties of a Decentralised Smart Contract

A decentralised smart contract is ownerless, therefore it needs to be completely open source to ensure transparency between all parties involved, this allows potential anonymous exchanges without the need for a central trusted authority.
If a DApp is on a public blockchain, it will be traceable and irreversible, these two qualities cause the DApp to become immutable. Uptime also coincides with blockchain uptime.
All these attributes are both advantages and disadvantages to the security of a DApp.

On Ethereum any developer can upload a smart contract to the network with a bounty fee for nodes on the network, a user can read this contract and execute it again for another fee.

Smart Contract Security Advantages

As contracts are open source for transparency, users can audit the contract for any malicious code, ensuring developers and users can trust the exchange.
The traceability and irreversibility of the blockchain allow the policing of cyberspace whilst still attaining anonymity. The immutability can mitigate supply chain incidents, all users can audit the smart contract and all nodes must agree on the running code.
Eliminating the need for a central authority also eliminates the risk of third-party trust, as users can rely on the code to execute its functions.

Smart Contract Security Disadvantages

Transparency may reveal potential exploits within the application, DApps cannot be patched like a centralised application, any exploits can be devastating; any bug on a smart contract is permanent, there are ways to fix them but this leads to the pseudo-centralisation of DApps. A developer can add an “onlyOwner” function to an Ethereum smart contract for updating and point it to an address, effectively the application becomes centralised as one address has overwhelming control and becomes a single point of failure. An alternative is multi-sig smart contract based ownership, which means a minimum number of signatures are needed to handle a transaction, however this is still a centralised vote and if an account is compromised functions, which require all signatures can’t be executed. A true decentralised approach would be to point the owner to another self-governed smart contract and allow users on the blockchain to vote, but this may require coordination amongst a community to handle bug fixes;  a Decentralised Autonomous Organisation (DAO) uses voting amongst its stakeholders for decisions. Data stored on the blockchain or even in runtime is public, therefore secrets like passwords cannot be handled within decentralised applications, alternative authentication methods are used instead; some DApps use key signing or payments from a wallet for authentication.

Stolen funds can also be hard to retrieve due to the irreversibility of a decentralised blockchain, unlike a centralised system where a bank can freeze assets and roll them back, or an admin can freeze and restore accounts. 

Without central ownership, authority relies on the collective decisions of the nodes. In theory, if an entity has control of 51% of the nodes they become the singular authoritative figure for all applications running on that particular blockchain.

Logic Vulnerabilities

Decentralised Application security vulnerabilities have been broken down into a top 10 as of 2018, known as the DASO Top 10. This is what testers should look for when auditing smart contracts:

  • Re-entrancy
  • Access Control
  • Arithmetic Issues
  • Unchecked Return Values For Low Level Calls
  • Denial of Service
  • Bad Randomness
  • Front-Running
  • Time Manipulation
  • Short Address Attack
  • Unknown Unknowns

Case Study: Binance Bridge Hack

Binance, one of the world’s largest cryptocurrency exchanges, was the target of a $566 million Web3 hack. The attack targeted a binance bridge, which is a smart contract responsible for the conversion of cryptocurrencies from one blockchain to another.

The exploit revolves around the IAVL tree (Immutable-Adelson-Velsky and Landis), an immutable self-balancing binary tree of data, which is designed to store a collection of information of key pairs. Each node on the blockchain is supposed to verify the tree’s integrity, but the attacker was able to exploit it by writing arbitrary messages. It created a new leaf on the tree with a forged payload, which pointed to a previous block, if successfully verified it would grant the address cryptocurrency. The exploit passed the verification checks by adding a blank inner node on the tree and exploiting the program to exit early. This caused the Binance bridge to send them 1 million BNB twice, which was worth $566 million at the time.
In summary, a bug in the smart contract enabled the hacker to forge proofs and receive funds into their crypto wallet.

Binance’s Response

Binance noticed the anomalous activity and shut down 26 of their BNB Chain validators, by contacting each one individually. In the end, the hacker escaped with $110 million. Binance performed a 51% attack on the BNB chain by controlling a dominant percentage of the validators and preventing funds from being transferred by the attacker. This is unique to the Binance bridge chain as their decentralised network nodes are limited to only 19 validators at a time, making it pseudo-centralised.
In a public blockchain network like Ethereum, Binance’s counter-measures would not have been practical, shutting the network with a 51% attack would require the cooperation of thousands of nodes in real-time rather than just 26. The impact could have been more severe in an unregulated decentralised network like Ethereum.

Conclusion

When writing a smart contract for DApps, developers must carefully consider the risks involved. Security updates are not easily propagated without the use of pseudo-centralisation or majority voting within the blockchain. Developers need to ensure their software development lifecycle incorporates formal auditing to minimise risk. Smart contracts should also be dynamically tested for security vulnerabilities in temporary local blockchain environments before being deployed onto a live blockchain where mistakes could lead to significant costs, similar to penetration testing on conventional infrastructure and applications. Whilst Binance demonstrated an excellent active response to the hack, proactive measures like thorough auditing and dynamic testing of the smart contract may have revealed the vulnerability in the contracts dependency.

References

  • https://medium.com/the-challenge/a-brief-history-of-decentralized-computing-d0d665783bcf
  • https://www.investopedia.com/terms/s/smart-contracts.asp
  • https://www.binance.com/en/news/flash/7231194
  • https://www.bnbchain.org/en/blog/bep131-introducing-candidate-validators-bnb-smart-chain/
  • https://dasp.co/