EnsoFi Audit Case Study

Background:

EnsoFi is the first decentralized peer-to-peer cross-chain lending protocol, enabling users to lend and borrow at mutually agreed-upon interest rates. It offers a flexible and user-defined interest rate system that remains constant throughout the lending period, empowering users with greater control.

Vision and Mission:

EnsoFi’s vision is to bridge the user experience gap in DeFi by providing a seamless interface familiar to web2 users. The protocol seeks to solve two major problems in DeFi lending:

• Fluctuating Interest Rates:

Traditional lending protocols often operate on a peer-to-pool model with floating interest rates driven by supply and demand. In the volatile web3 environment, these rates can fluctuate significantly within a short period, creating uncertainty for borrowers and discouraging the use of DeFi lending/borrowing protocols.

• Interest Rate Spread:

In the peer-to-pool model, the spread between the rate borrowers pay and the rate lenders receive can lead to inefficiencies. A high spread reduces returns for lenders and increases costs for borrowers, making the model less appealing for both sides.

Additionally, EnsoFi enables cross-chain lending by leveraging the Wormhole protocol.

Audit Focus

The audit of EnsoFi was scoped to the Solana Network Program, with a focus on analyzing the protocol’s design in comparison to standard DeFi lending and borrowing protocols. The assessment centered on the core logic of the program, aiming to identify potential security vulnerabilities in the following areas:

1. Potential for borrowers to bypass interest payments.
2. Risk of lenders’ or borrowers’ funds being indefinitely locked within the protocol.
3. Presence of overflow or underflow scenarios in the program’s logic.
4. Effectiveness of constraints on PDA account creation.
5. Vulnerabilities related to the reinitialization of PDAs.
6. Adequacy of validation checks throughout the program’s logic.
7. Adherence to Anchor framework best practices.
8. Potential for borrowers to evade liquidation events.
9. Risks of frontrunning within the protocol.
10. Degree of centralization and control within the protocol.

Audit Findings

BlockApex’s comprehensive audit uncovered several vulnerabilities in the EnsoFi lending/borrowing protocol. The EnsoFi team responded swiftly and effectively, addressing and resolving the issues in a timely manner. Their proactive approach and quick mitigation of risks demonstrate a strong commitment to prioritizing security and ensuring the integrity of the protocol, creating a safer environment for users.

Read the detailed Audit Report.

Key Findings:

Reinitialization Attack:

When an account is initialized using “init_if_needed” there is room for a potential Reinitialization Attack. During the audit, it was found that setting_account can be reinitialized which would mess up the lending/borrowing functionality under the hood.

Recommendation: The usage of “init” constraint ensures that the instruction can be called once per account meaning reinitialization won’t be possible.

Reference: https://www.anchor-lang.com/docs/account-constraints

Erroneous status update leads to funds locking:

It was found that when the borrower repays the loan back, an erroneous update in the status of the loan leads to a situation in which the system will not be able to pay back the collateral that the borrower deposited to get the loan. This led to a permanent loss of funds.

Recommendation: Implementation of correct LoanOfferStatus after the repay_loan_offer call fixed the issue.

Frontrunning Scenario:

It was found that a Lender can grief the borrower by frontrunning the borrower’s loan request to update the interest amount of the loan. This leads to a situation where the borrower is forced to accept the new interest amount causing financial damage.

Recommendation: It was recommended to put a cooldown period after editing the lend_offer,this should be checked in the loan_offer creation too. Within the cooldown period, the offer from the borrower should not be matched with the lend_offer.

 

Key Takeaways for Solana Auditing

• Solana’s Transaction Model:

Solana transactions are attacker-controlled, allowing the sender to specify the program, the accounts, and the instruction data. This puts the responsibility on the program to correctly parse and validate the provided information, making strong validation and constraint implementation critical.

• Logical Issues:

Flaws in the program’s logic can be exploited to trigger unintended behavior, such as asset loss or unauthorized access. This also includes failing to correctly implement the project’s intended functionality — if a program claims to perform a specific task, it must do so accurately, addressing all associated nuances. Documentation is the perfect place to learn the intended purpose of the protocol.

• PDA Vulnerabilities:

Incorrect generation or handling of PDAs can allow attackers to hijack or spoof them, leading to unauthorized access or manipulation of program-controlled accounts.

• Cross-Program Invocation (CPI) Risks:

Mishandling CPIs can lead to unexpected state changes or errors, especially if the called program behaves maliciously or unexpectedly.

• Access Control Weaknesses:

Insufficient access control checks, such as failing to verify account ownership, can lead to unauthorized actions by malicious actors.

• Account Closure Issues:

Improper closure of accounts can lead to reinitialization vulnerabilities or misuse scenarios, creating potential security risks.

• Shared PDA Risks:

Using the same PDA across multiple authorities or roles can allow malicious actors to misuse PDAs as signers, potentially gaining access to data or funds that do not belong to them.