Centrifuge is transforming decentralized finance (DeFi) by enabling the financing of real-world assets directly on-chain. By removing intermediaries, Centrifuge creates a fully transparent market where borrowers and lenders can transact seamlessly. With fully collateralized asset pools spanning mortgages, invoices, microlending, and consumer finance, the protocol lowers borrowing costs for businesses while offering DeFi investors stable, uncorrelated yields.

In this blog, we’ll delve into the technical architecture behind Centrifuge, its core functionalities, and a critical vulnerability recently identified in its router contract during a security review with Spearbit. We’ll explore the vulnerability, its potential impact, and how it was mitigated to maintain the integrity of the protocol.

Centrifuge: A Bridge Between DeFi and Real-World Assets

At its core, Centrifuge was designed to bring real-world assets (RWAs) into the DeFi space. Unlike many other projects that rely heavily on volatile crypto assets, Centrifuge focuses on creating a stable and transparent market where businesses can access liquidity by tokenizing real-world assets such as invoices, real estate, and other forms of collateral. Like all protocols operating in the decentralized space, it must constantly guard against security risks that can compromise its mission.

Key Features of Centrifuge:

• Liquidity Pools: Centrifuge's liquidity pools allow investors to earn a stable yield backed by real-world assets, providing a unique source of uncorrelated returns.
• Tokenization of RWAs: By tokenizing assets, Centrifuge reduces the friction of traditional financing and makes it easier for businesses to access decentralized loans.
• Transparency and Trust: All transactions and assets are fully transparent, recorded immutably on-chain, and auditable by anyone, fostering trust among users.

Understanding the Centrifuge Router Contract

The Centrifuge Router Contract plays a central role in managing user interactions with vaults in the Centrifuge protocol. Vaults are used to store tokenized real-world assets, and the router contract acts as the bridge between users and these vaults. Essentially, the router allows users to perform actions like depositing and withdrawing assets, but only once it has been given permission to act on behalf of the vault owner.

To make these interactions possible, the router contract relies on three key functions: open(), requestDeposit(), and requestRedeem(). Each of these functions plays a specific role in managing the assets inside the vault.

Let’s now understand how these functions work:

1. open(): The open() function is used to give the router contract the authorization to manage a vault. This function is called by the vault owner to allow the router to interact with their vault. Without calling open(), the router cannot perform any actions on the vault, such as depositing or withdrawing assets.

2. requestDeposit(): Once the router has been granted permission using the open() function, the requestDeposit() function is used to move assets into the vault. This function allows the router to deposit assets like tokens or collateral into the vault on behalf of the vault owner. It increases the balance of the vault by adding more assets to it.

3. requestRedeem(): The requestRedeem() function allows the router to withdraw assets from the vault. After the router has permission, it can call this function to redeem (or withdraw) a specified amount of assets from the vault, reducing its balance. This function is used by vault owners when they want to access the assets stored inside their vault.

Now that we’ve examined these three functions, we’ll explore the vulnerability uncovered.

Vulnerability: Lack of Ownership Verification

The vulnerability in the Centrifuge router contract was due to missing ownership verification. The contract did not properly check if the person calling functions like deposits or withdrawals was the actual vault owner.

This meant an attacker could call the open() function to gain control of a vault, and then use functions like requestDeposit() or requestRedeem() to deposit or withdraw assets without the owner’s permission.

How the Vulnerability Worked:

1. open() Function: This function enables the router to gain control over a vault by making it an authorized operator. The flaw was that it didn’t verify if the caller of the function was the true owner of the vault. As a result, anyone could call open() and allow the router to operate on the vault without the owner's approval.
2. requestDeposit() and requestRedeem() Functions: Once the router was authorized through the flawed open() function, it could carry out deposits and redemptions on behalf of the vault owner. However, neither requestDeposit() nor requestRedeem() properly checked if the caller initiating these actions was the vault's owner, allowing attackers to either deposit or withdraw assets without the vault owner’s consent.

Exploitation Workflow

1. Attacker Identifies a Vault: The attacker identifies a vault address that they want to target.
2. Call open(): The attacker calls the open() function on the target vault, giving the router control of the vault’s assets without the vault owner’s permission.
3. Initiate Unauthorized Actions:

• The attacker can call requestDeposit() to deposit assets into the vault without the owner's consent.
• Worse, the attacker can call requestRedeem() to withdraw assets from the vault, draining the vault’s assets.

This vulnerability exposed a critical flaw in how ownership would have been handled within the router contract, leaving user vaults open to unauthorized actions such as deposits and withdrawals. Let’s now explore the potential impact of this vulnerability discovered during the review, how it was remediated, and the key takeaways for improving the protocol.

Impact

The vulnerability posed significant risks to both the protocol and its users:

• Unauthorized Access: Attackers could gain control of vaults and perform actions, such as withdrawing assets, without the owner’s permission.
• Loss of Assets: The lack of ownership verification could result in the theft or misappropriation of user funds, leading to potentially large financial losses for vault owners.
• Damage to Trust: Security vulnerabilities like this could undermine user confidence in the protocol, damaging its reputation and trustworthiness in the DeFi ecosystem.

Remediation

To address this critical vulnerability, the Centrifuge team implemented additional ownership verification checks across the following functions. Specifically:

1. The requestDeposit() and requestRedeem() functions were modified to verify that the caller is the vault owner before allowing any deposits or withdrawals.
2. The recommendation is to document the proper use of the open() function, ensuring that users enable the router as an operator only when necessary to minimize exposure to potential risks.

Note: - denotes removal of code & + denotes addition of code

This blog addressed a critical vulnerability discovered in the Centrifuge router contract during a security review with Spearbit, specifically focusing on the lack of proper ownership verification within key functions. Resolving this vulnerability was essential to safeguarding user assets, ensuring the integrity of vault operations, and maintaining trust within the Centrifuge ecosystem.

This case highlights an important lesson: even seemingly small vulnerabilities can have a significant impact on the security of smart contracts. Proactive security measures, such as regular audits and reviews, are crucial to identifying and addressing these issues early. By undergoing this review, the Centrifuge team demonstrated the importance of prioritizing security as an integral part of the development process.

Contact the Spearbit team today to learn more about our security solutions.