Để cài đặt Foundry chỉ cần chạy command dưới đây:

curl -L https://foundry.paradigm.xyz | bash

Sau đó chạy: foundryup

• forge: build, compile, debug, deploy smart contracts.

• cast: interact with the blockchain via RPC calls.

• anvil: create local ethereum node.

• chisel: solidity CLI shell for debugging.

Khởi tạo một project sử dụng forge.

Đây là lỗi do chưa config git.

git config –global user.email "devtest@example.com"

git config –global user.email "devtest"

Thực hiện build để kiểm tra xem có lỗi hay không.

Cấu trúc của một project.

• lib: nơi chứa các thư viện, vd: OpenZeppelin.

• script: dùng để deploy smartcontract lên network.

• src: chứa mã nguồn của smartcontract.

• test: là nơi viết các unit-test cho smartcontract trước khi được deploy lên network.

• foundry.toml: nơi chứa thông tin cấu hình, vd: rpc url, key…vv.

Vd: thực hiện deploy smartcontract lên U2U network.

forge create --rpc-url "https://rpc-nebulas-testnet.uniultra.xyz" --private-key "your_private_key" src/Test1.sol:Test1

Sau khi deploy thành công.

Kiểm tra trên explorer. Vì smartcontract chưa được verify nên chỉ hiện thị ở dạng bytecode.

Để cho dễ hình dung hơn, chúng ta sẽ thực hiện tạo một ERC20 token và thực hiện các công việc như: deploy, transfer,…vv.

Sử dụng lại project TestCode đã tạo trước đó, cài thư viện OpenZeppelin với câu lệnh:

forge install OpenZeppelin/openzeppelin-contracts

Tiếp theo sẽ tạo một file MyToken.sol nằm trong folder /src

• Token name: MyToken

• Symbol: MTK

• Decimals: 18

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

import {ERC20} from "openzeppelin-contracts/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    address public owner;
    mapping(address=>address) public owner_spender;

    constructor() ERC20("MyToken", "MTK") {
        _mint(msg.sender, 100000);
        owner = msg.sender;
    }

    function newAllowance(address _owner, address _spender) public {
        allowance(_owner, _spender);
        owner_spender[_owner] = _spender;
    }

    function newMint(address to, uint256 value) external{
        require(msg.sender == owner,"Not owner !!!");
        require(value > 0,"Check Value Error !!!");
        _mint(to, value);
    }
}

Nói qua về ý nghĩa của đoạn code này: deployer account sẽ mint 100k token khi thực hiện deploy contract này lên network và deployer account sẽ được gán cho biến owner. Ngoài ra có định nghĩa thêm 2 function newMint và newAllowance.

• newAllowance: tracking approver & spender

• newMint: mint token (chỉ cho phép owner được thực hiện)

Để deploy smartcontract cần có chain network, sẽ có 2 option mà foundry cung cấp:

• fork network: deploy lên bất kỳ network nào vì foundry hỗ trợ fork.

• local test network: foundry sử dụng anvil để tạo local network (anvil cũng hỗ trợ fork network bất kỳ với any block number -> khá là hữu ích cho việc test các smartcontract đã được deploy trên mainnet)

Ở đây sẽ sử dụng local test network. Sử dụng câu lệnh sau để tạo local network và tạo 4 EOA account:

• EOA(0) : deployer/owner 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

• EOA(1) : user1 0x70997970C51812dc3A010C7d01b50e0d17dc79C8

• EOA(2) : user2 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC

• EOA(3) : user3 0x90F79bf6EB2c4f870365E785982E1f101E93b906

rpc url lúc này là: http://127.0.0.1:8545 (giá trị này có thể cấu hình luôn trong file foundry.toml)

giá trị PRIVATE_KEY chính là privatekey của EOA(0) account hay chính là deployer account.

Sau khi đã tạo test network, tiến hành deploy MyToken.sol, trong folder /script tạo một file Deploy.s.sol.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Script, console} from "forge-std/Script.sol";
import {MyToken} from "../src/MyToken.sol";

contract Deploy is Script {
    function setUp() public {}

    function run() public {
        uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY"); //lấy từ biến môi trường
        vm.startBroadcast(deployerPrivateKey);
        // Make a new token ~ deploy
        MyToken mtk = new MyToken();
        vm.stopBroadcast();
        //vm.broadcast();
    }
}

vm.startBroadcast (cheatcode: https://book.getfoundry.sh/cheatcodes/start-broadcast).

Tại sao lại sử dụng startBroadcast là bởi vì khi deploy một smartcontract thì EOA account sẽ sinh ra transaction và cần sign (sử dụng privatekey) transaction đó. Do đó transaction sẽ được ký bởi EOA(0).

Chạy câu lệnh sau để deploy:

forge script ./script/Deploy.s.sol --broadcast -vvvv --rpc-url rpcapi

Deployed Contract Address: 0x5FbDB2315678afecb367f032d93F642f64180aa3

Như vậy đã deploy contract MyToken thành công, tiếp theo sẽ tương tác với contract này như thế nào ? Ở đây sẽ viết test script để tương tác (tham khảo: writing-testa)

Trong folder /test tạo 1 file MyTokenTest.t.sol

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console2} from "forge-std/Test.sol";
import {MyToken} from "../src/MyToken.sol";
import "forge-std/console.sol";

contract MyTokenTest is Test {
    function setUp() public {}
    function test_Transfer() public {
        // user accounts
        address owner = 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266; //EOA(0)
        address user1 = 0x70997970C51812dc3A010C7d01b50e0d17dc79C8; //EOA(1)
        address user2 = 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC; //EOA(2)
        address user3 = 0x90F79bf6EB2c4f870365E785982E1f101E93b906; //EOA(3)
        // fork from local network
        uint256 rpcapi = vm.createFork("rpcapi");
        vm.selectFork(rpcapi);
    }

Test script sẽ không update storage trên network, mà nó chỉ đơn thuần fork network xong và run trong một isolated EVM. Vì lúc deploy contract đã thực hiện luôn mint 100k token cho tài khoản owner, thử kiểm tra xem tài khoản đó đã có 100k token hay chưa.

forge test --match-contract MyTokenTest --match-test test_Transfer -vvv

Mint 5k token cho các tài khoản user1->user3.

Chuyển 100 token từ tài khoản từ user2 tới user3.

user3 approve cho user1 chuyển 1000 token từ user3 tới user1.

Đoạn test script đầy đủ:

    function test_Transfer() public {
        // user accounts
        address owner = 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266; //EOA(0)
        address user1 = 0x70997970C51812dc3A010C7d01b50e0d17dc79C8; //EOA(1)
        address user2 = 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC; //EOA(2)
        address user3 = 0x90F79bf6EB2c4f870365E785982E1f101E93b906; //EOA(3)
        // fork from local network
        uint256 rpcapi = vm.createFork("rpcapi");
        vm.selectFork(rpcapi);
        //get contract MyToken
        MyToken mtk = MyToken(0x5FbDB2315678afecb367f032d93F642f64180aa3);
        //get token of owner account
        emit log_named_uint("Token of Owner is ", mtk.balanceOf(owner));
        emit log_named_uint("Token of user1 is ", mtk.balanceOf(user1));
        emit log_named_uint("Token of user2 is ", mtk.balanceOf(user2));
        emit log_named_uint("Token of user3 is ", mtk.balanceOf(user3));
        emit log("====> Mint 5k token to each one of users");
        vm.startBroadcast(owner);
        mtk.newMint(user1, 5000);
        mtk.newMint(user2, 5000);
        mtk.newMint(user3, 5000);
        vm.stopBroadcast();
        emit log_named_uint("Token of user1 is ", mtk.balanceOf(user1));
        emit log_named_uint("Token of user2 is ", mtk.balanceOf(user2));
        emit log_named_uint("Token of user3 is ", mtk.balanceOf(user3));
        emit log("====> Transfer 100 tokens from user2 to user3");
        vm.startBroadcast(user2);
        mtk.transfer(user3, 100);
        vm.stopBroadcast();
        emit log_named_uint("Token of user1 is ", mtk.balanceOf(user1));
        emit log_named_uint("Token of user2 is ", mtk.balanceOf(user2));
        emit log_named_uint("Token of user3 is ", mtk.balanceOf(user3));
        // From user3 approve user1 to spend 1k tokens
        emit log("====> user3 approve user1 to transfer 1000 token");
        vm.startBroadcast(user3);
        emit log_named_address("Approver", user3);
        mtk.approve(user1, 1000);
        mtk.newAllowance(user3, user1);
        emit log_named_address("spender", mtk.owner_spender(user3));
        vm.stopBroadcast();
        emit log("===> user1 transfer 1000 tokens from user3 to user1");
        vm.startBroadcast(user1);
        mtk.transferFrom(user3, user1, 1000);
        vm.stopBroadcast();
        emit log("-> After transfered");
        emit log_named_uint("Token of user1 is ", mtk.balanceOf(user1));
        emit log_named_uint("Token of user2 is ", mtk.balanceOf(user2));
        emit log_named_uint("Token of user3 is ", mtk.balanceOf(user3));
        
    }

Qua đó chúng ta có thể thấy sử dụng foundry để làm việc với smartcontract đem lại thuận tiện, chỉ cần code solidity rất dễ nhớ. Ngoài ra foundry hỗ trợ khá nhiều cheatcode hữu ích khác, các bạn có tham khảo tại trang chủ để hiểu rõ hơn cách dùng.

• Critical

• High

• Medium

• Low

The development of this scale took into consideration multiple factors that may affect a vulnerability and its likelihood of exploitation, but finalizes them largely by the impact that they cause.

Blockchain/DLT

• Critical:

  • Network not being able to confirm new transactions (total network shutdown)

  • Unintended permanent chain split requiring hard fork (network partition requiring hard fork)

  • Direct loss of funds

  • Permanent freezing of funds (fix requires hardfork)

• High:

  • Unintended chain split (network partition)

  • Temporary freezing of network transactions by delaying one block by 500% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments

  • Causing network processing nodes to process transactions from the mempool beyond set parameters

  • RPC API crash affecting projects with greater than or equal to 25% of the market capitalization on top of the respective layer

• Medium:

  • Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours

  • Shutdown of greater than or equal to 30% of network processing nodes without brute force actions, but does not shut down the network

  • A bug in the respective layer 0/1/2 network code that results in unintended smart contract behavior with no concrete funds at direct risk

• Low:

  • Shutdown of greater than 10% or equal to but less than 30% of network processing nodes without brute force actions, but does not shut down the network

  • Modification of transaction fees outside of design parameters

Smart Contracts

• Critical:

  • Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results

  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

  • Direct theft of any user NFTs, whether at-rest or in-motion, other than unclaimed royalties

  • Permanent freezing of funds

  • Permanent freezing of NFTs

  • Unauthorized minting of NFTs

  • Predictable or manipulable RNG that results in abuse of the principal or NFT

  • Unintended alteration of what the NFT represents (e.g. token URI, payload, artistic content)

  • Protocol insolvency

• High:

  • Theft of unclaimed yield

  • Theft of unclaimed royalties

  • Permanent freezing of unclaimed yield

  • Permanent freezing of unclaimed royalties

  • Temporary freezing of funds

  • Temporary freezing NFTs

• Medium:

  • Smart contract unable to operate due to lack of token funds

  • Block stuffing

  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

  • Theft of gas

  • Unbounded gas consumption

• Low:

  • Contract fails to deliver promised returns, but doesn't lose value

Websites and Apps

• Critical:

  • Execute arbitrary system commands

  • Retrieve sensitive data/files from a running server, such as:

    • /etc/shadow

    • database passwords

    • blockchain keys (this does not include non-sensitive environment variables, open source code, or usernames)

  • Taking down the application/website

  • Taking down the NFT URI

  • Taking state-modifying authenticated actions (with or without blockchain state interaction) on behalf of other users without any interaction by that user, such as:

    • Changing registration information

    • Commenting

    • Voting

    • Making trades

    • Withdrawals, etc.

  • Changing the NFT metadata

  • Subdomain takeover with already-connected wallet interaction

  • Direct theft of user funds

  • Malicious interactions with an already-connected wallet, such as:

    • Modifying transaction arguments or parameters

    • Substituting contract addresses

    • Submitting malicious transactions

  • Direct theft of user NFTs

  • Injection of malicious HTML or XSS through NFT metadata

• High:

  • Injecting/modifying the static content on the target application without JavaScript (persistent), such as:

    • HTML injection without JavaScript

    • Replacing existing text with arbitrary text

    • Arbitrary file uploads, etc.

  • Changing sensitive details of other users (including modifying browser local storage) without already-connected wallet interaction and with up to one click of user interaction, such as:

    • Email or password of the victim, etc.

  • Improperly disclosing confidential user information, such as:

    • Email address

    • Phone number

    • Physical address, etc.

  • Subdomain takeover without already-connected wallet interaction

• Medium:

  • Changing non-sensitive details of other users (including modifying browser local storage) without already-connected wallet interaction and with up to one click of user interaction, such as:

    • Changing the first/last name of user

    • Enabling/disabling notifications

  • Injecting/modifying the static content on the target application without JavaScript (reflected), such as:

    • Reflected HTML injection

    • Loading external site data

  • Redirecting users to malicious websites (open redirect)

• Low:

  • Changing details of other users (including modifying browser local storage) without already-connected wallet interaction and with significant user interaction, such as:

    • Iframing leading to modifying the backend/browser state (must demonstrate impact with PoC)

  • Taking over broken or expired outgoing links, such as:

    • Social media handles, etc.

  • Temporarily disabling user to access target site, such as:

    • Locking up the victim from login

    • Cookie bombing, etc.

Ref:

• https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/

• https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System?utm_source=immunefi

Subscribe now

The popularity of blockchain 2.0 technology has resulted in a wide range of related services. Decentralized finance (DeFi) is an example of a financial service built on blockchains to provide transaction transparency. From January 2020 to April 2022, the total value locked in DeFi climbs from $600 million to around $200 billio.. However, there was a sharp drop in May 2022, which caused us to ponder the safety of DeFi. Attacks have emerged gradually with the rapid development of DeFi. Security incidents against DeFi continue to proliferate, and there has been a lot of research to improve the security of blockchain.

2. BACKGROUND

   • ETHEREUM: Ethereum is a public blockchain that uses the Turing-complete programming language, such as Solidity, to develop smart contracts. Anyone can deploy decentralized applications (dapps) on the Ethereum that can communicate with others, and the most popular financial field is DeFi, which provides a wide range of financial services.

   • GAS: To avoid overuse of network resources, all transactions on Ethereum are paid a cost, and the total gas cost equals the amounts of gas multiplied by gasPrice. The user who proposes transactions sets the gasPrice, and the transaction is conducted earlier if the gasPrice is high.

   • MINER - EXTRACTABLE VALUE (MEV): It refers to the profit miners make by performing a series of operations on the blocks they mine, such as transaction inclusion, exclusion, and reordering. Miners reorder transactions to optimize the initial ordering of transactions. Earning additional ordering optimization (OO) fees is also a source of MEV.

3. ANALYSIS OF VULNERABILITIES

   1. Data Security Vulnerabilities:

      Oracle Mechanism Vulnerabilities: The oracle is an automated service mechanism that allows the system to obtain off-chain asset data as input.

      Inappropriate Key Management: In the DeFi ecosystem, wallets are used to manage private keys, and authentication is based on private keys in most cases. However, even the safest hardware wallets have security issues [20] caused by the design.

   2. Consensus Mechanism Vulnerabilities:

      Transaction Order Vulnerability: It means that attackers alter the initial sequence of transactions by leveraging the desire of miners for profit. The sandwich attack is an example, the attacker spies on the victim, and pays a higher gas fee to miners before the victim gets asset A, then sells A for arbitrage since the victim’s purchase boosts the price.

      Forking Vulnerability: Forking in DeFi is generally associated with transaction fee-based forks and time-bandit attacks [18]. Mining revenue incentivizes miners to perform normally, but the OO fee motivates them to reorder transactions in the block, enhancing the income.

   3. Smart Contract Vulnerabilities:

      Suicidal and Greedy Contracts: Smart contracts usually include a provision enabling the owner to commit suicide if the contract is challenged. This suicide procedure can be carried out for any cause under the suicidal contract. Greedy contracts do not have functions related to extraction. The contract locks all ether and cannot withdraw.

      Block Info Dependency: In Ethereum, the discrepancy between successive blocks is valid when the timestamps are within 12 minutes. However, if the contract combines states in the block, the miner can control it for profit. Unchecked External Call: The return values and arguments of an external call can affect the states, and many contracts do not check the return value leads to errors. Multiple functions are nested, and the external call does not check the return value can go wrong. Smart contracts trade by using external call functions such as call() and send(). More crucially, a failed external call results in a transaction not being rolled back, which can cause logical effects.

   4. Application Layer Vulnerabilities:

      Lending Market Imperfection: When the prices in the market are out of balance, it will result in bad debts for one of the participants in the market. To get more loans, attackers can boost the exchange rate on the oracle by modifying the real-time price-related status before the loan is made. Cryptocurrency Instability: The large fluctuations of cryptocurrencies come from many reasons, one of which is the Pump-and-Dump. The instability can easily trigger liquidation procedures. Exchanges have chosen stablecoin, which is tied to the price of real money, as the pricing standard to minimize losses, but they still exist as a risk.

      Design imperfection: The attackers make use of incorrectly configured functionality or specific convenience features of DeFi platform exchanges . Flash loan is designed as riskfree loans to be a convenient improvement to the loan that need to borrow the flash loan, exchange it for currency and repay the loan in an atomic transaction.

      Abusive Exposure Transaction: Exchanges disclose all transactions as soon as feasible to ensure complete behavioral transparency because off-chain matching services are not automated. Unfortunately, exchanges can restrict access to select users and launch denial of service attacks to dominate the market, audit transactions and even front run the orders.

4. CONCLUSION AND FUTURE DIRECTION

   The focus of this paper is on the security of DeFi, and we summarize a series of security risks of DeFi by analyzing their projects deployed in Ethereum. For each vulnerability, we explore its causes with real-world cases. Finally, we investigate the optimization options for decentralized finance and suggest possible future directions.

   Comprehensive knowledge of security and risk problems is critical to improving blockchain and establishing powerful defense capabilities in practice. There is a strong possibility to combine static detection with dynamic supervision technologies to protect DeFi at the consensus mechanism, smart contract, and application levels for the future development of DeFi application security.

   References:

   • 2022 IEEE International Conference on Blockchain (Blockchain)