Smart Contract Vulnerabilities in On-Chain Lending – Part II

By CCA Member Firm Cicada Partners

This article was originally published on Medium.com

Click here for part I

Given the positive reception from our prior post on smart contract exploits in decentralized finance (DeFi) and the amount of misinformation we’ve seen in both non-crypto and crypto-native media, we decided to expand our research in Part 2 of this series. The following research provides an update to DeFi exploit statistics, as well as a more granular time series view on the evolving trends in attack vectors. Lastly, we review the operational flows of smart contract exploits on lending platforms, to better contextualize exploit risks for both overcollateralized lending platforms (e.g. Compound, Aave, etc.) and credit origination architectures like Atlendis, Centrifuge, and Maple Finance.

Exploit Statistics through Oct ‘23

Since our last post in August, there were ~$225MM of assets affected by exploits, bringing the overall LDEPD [1] for 2023 to 3.4% and an overall LDEPD since inception of 3.16% (down from 3.21% in our prior analysis). Ironically, our data shows that 2021 (1.9% LDEPD) and 2022 (2.0%) were both safer years for DeFi, even with what felt like daily occurring exploits. Bridging remains a key attack vector accounting for most of the losses since August (~89%) due almost exclusively to the $200MM Mixen Network exploit. Sadly, the Mixin exploit is not even a result of failed Smart Contracts, but due to poor operational security that allowed hackers to access Mixin’s cloud service provider, ultimately granting them direct access to the platform’s private keys for their hot wallets. As such, it is important for readers to recognize the context of an exploit and not become overly simplistic on DeFi risk analysis by unfairly lumping together true smart contract vulnerabilities with administrative and operational stupidity. Adjusting for these types of private key losses, LDEPD since inception would fall from 3.16% to 2.82%. As for the lending category, only 6% of exploited funds since August were tied to lending protocols.

Taking a more granular look at the data on a yearly basis from 2020–2023 we highlight a few trends. Most importantly, lending applications (more specifically credit origination protocols) have become extremely safe relative to other DeFi applications since 2021 and, specifically, credit origination protocols have never experienced an exploit. Data collected by us indicates that annualized loss rates for the Lending category dropped to only 0.4% in 2021, and 0.2% in 2022 and 2023 when you remove pricing manipulations, oracle failures and flash loan attacks from the exploit totals. As we will expand on below, such pricing manipulations are not relevant to credit origination platforms. Additionally, as you can see in the charts below, the lending category has been declining as a % of exploits since 2020, going from 23% in 2020 to 17% in 2023. We believe this trend will continue into 2024, as the Euler Hack in early 2023 dramatically skewed the results upwards for the year given the size of their TVL on the day of the attack.

Looking at exploits by vulnerability type over the years is eye opening. An embarrassingly large amount of at-risk funds has simply been a result of private key losses over the years, which ultimately makes DeFi and the underlying smart contracts look a lot riskier than they actually are. Additionally, pricing manipulations and flash loan attacks continue to plague the industry, both of which will need to be solved as we onboard new users over time.

Contextualizing Operational Attack Vectors

With that being said, let’s now spend some time outlining the operational process of lending platforms, all with different architectures and risk profiles. To start, we will look at AAVE, the blue-chip over-collateralized platform and we will then compare it with Maple Finance and Atlendis in terms of safety and attack vectors.

The above flow chart shows the general structure of the AAVE platform. The core attack vectors have been numbered 1–3 to help provide a visual representation.

#1: Flash Loans, 18.4% of Historic DeFi Exploits

Ironically AAVE is both the originator of flash loans as well as the potential victim, a cruel dichotomy in the DeFi lending landscape. In a flash loan, anyone without collateral can source loans from AAVE with the platform’s unused liquidity, so long as assets are repaid during the same block/transaction. As such, pricing manipulation attacks are much easier to occur as an attacker does not need millions of dollars of at-risk capital to affect prices on other AMMs or DEXs that ultimately provide Dapps like AAVE with pricing data. As such, the cost of a pricing manipulation attack is a fraction of what it should be in normal circumstances. Without adequate safety modules built into the collateral pricing engine, like TWAP Pricing from diverse set of both CEX and DEX pricing feeds, the platform is susceptible to supplied assets being temporarily overinflated, allowing for large amounts of assets to be borrowed and effectively stolen from the lending pool module. Inversely, borrowed assets can be manipulated down to make loan repayments artificially cheap. There are other games that can be played using flash loans as well, like what happened during the Euler exploit, but we will leave that to another day.

#2: Oracles, 2.5% of Historic DeFi Exploits

Label two on the Aave operational workflow chart displays how oracle risks come into the ecosystem. The risk here is two-fold. One, oracles have the risk of down time. Even if momentary, they could dramatically affect fast-moving prices as they relate to collateral values. Additionally, given many Oracle Networks rely on a multi-sig (Chainlink I’m looking at you), there is potential for collusion from the private key owners and the ability for hackers to attempt to steal the keys in order to manipulate the Oracle Feeds. In either case, the controller of the Oracle price feed effectively has God mode on whatever application uses it as their exclusive pricing/data provider (i.e., no secondary Oracle feed for safety checks). Unfortunately, this is a risk that cannot be fully eliminated in most cases given the necessity for outside data and therefore must be handled with care and consideration for instances of Oracle failures.

#3: Collateral, 3.2% of Historic DeFi Exploits

The collateral module is also susceptible to market manipulation attacks not derived from flash loans or oracle issues, but due to old-fashioned market manipulation occurring on CEXs or DEXs. A good example of this would be Mango Markets. Coordinated buying of the Mango token was performed across numerous CEXs to pump the token price before exploiters used the tokens as collateral to borrow against. Obviously, in hindsight, high prices were illusory and could not be absorbed in the market, but the return of funds was never the intent of the manipulator. While this issue is unlikely to occur for the majors (e.g. ETH, USDT, etc), this remains a problem for more exotic assets and AAVE (and other platforms like it) have come dangerously close to having similar issues occur, as seen with the CRV liquidation saga this summer.

Credit Origination Platform Workflows

#1: Maple Finance

Above, is a schematic provided by Maple Finance to demonstrate how funds flow through their credit origination platform. To be clear, the above three core vulnerabilities are removed from the flow of funds as any pricing and/or collateral monitoring happens off-chain with real legal agreements in place to protect users’ funds. While this does open an attack vector that does not exist to the same degree in over-collateralized or automated systems like AAVE (human involvement), Maple has intentionally built in safeguards to prevent the worst from happening in an adversarial environment. Key safety features are listed below:

  • Smart Contract Vaults prevent Pool Delegates from withdrawing money to non-whitelisted addresses and can only approve a loan to a whitelisted borrower.
  • Capital is isolated for each lending pool to prevent contagion in the event of a hack or some other black swan event.
  • Emergency Protocol pause can granularly pause the whole protocol, specific contracts, and even specific functions, if needed.
  • Maple tests contracts religiously with more added frequently (even for already released contracts). Testing predominantly involves a multi-level approach, with simple unit tests, invariant test, and more complex end-to-end tests, as well as full scale simulations in real conditions.
  • Maple has real-time monitoring and notification capabilities of all their contracts so that they can track, identify, and mitigate any situations that might occur on the platform.

#2: Atlendis

The above chart depicts Atlendis’ general smart contract architecture, with analysis provided by the Atlendis team showing what each module is responsible for on the platform. Much like Maple, the attack vectors of traditional AAVE-like platforms are removed and are replaced with human involvement risk. Atlendis has also built out specific safety features to lower the chance of exploits or pool managers affecting lender funds. Key safety features are listed below:

  • Smart contract Vaults prevent Pool Delegates from withdrawing money to non-whitelisted addresses and can only disburse funds to a whitelisted borrower. KYC is also enforced for all lenders/LPs allowing them to know all relevant parties if something were to happen.
  • Capital is isolated for each lending pool to prevent contagion in the event of a hack or some other black swan occurs. Additionally, V2 contracts are not upgradeable to prevent bad actors sneaking in malicious code after release.
  • Atlendis has procedures that they can follow to pause select actions on the protocol (including closing the pool) subject to a governance decision. In case of emergency, governance can activate a safeguarding procedure that helps secure funds from potential attackers while the issue is responded to.
  • Atlendis has real-time monitoring and notification capabilities of all their contracts so that they can track, identify, and mitigate any situations that might occur on the platform.
  • Atlendis tests contracts religiously with more added frequently (even for already released contracts). Testing predominantly involves a multi-level approach, with simple unit tests, invariant test, and more complex end-to-end tests, as well as full scale simulations in real conditions.

Takeaways

So, what lessons can we collectively follow to make DeFi safer for all? We have a few suggestions that would dramatically lower the chance for individuals and institutions to become victims of fraud and theft. Hopefully they serve as a general guide for proper business operations and thought processes when interacting with the DeFi lending space.

  • Lesson #1: The industry needs to create flash loan rate limiters and circuit breakers (e.g., only 20% of TVL can be withdrawn during a 12-hour period) for lending applications to minimize the tools and capital available for exploiters to utilize, as well as slow them down as much as possible when they try to run away with the funds.
  • Lesson #2: Avoid anon projects to prevent rug pulls and purposefully built in smart contract vulnerabilities. If a person is creating an advanced DeFi platform and is unwilling to put their name behind it, it’s not worth the risk. Satoshi is the only anon that is granted a hall pass.
  • Lesson #3: Avoid DeFi projects with hot wallets or private keys that are stored on the cloud. This becomes even more important for projects that do not have legally binding contracts to fall back on. Moreover, be hesitant of multi-sigs that control core functionality and have direct control access to assets or oracle feeds.
  • Lesson #4: Double check your URLs when interacting with DeFi, better yet, double check the SC you are interacting with matches the one listed in the docs provided by the project as a safety check. Avoid blind signing when possible.
  • Lesson #5: Youcan de-risk some of your lending activities by focusing on credit origination platforms. Clearly, you’ll want to get paid for the increased credit risk, but you can take comfort in de-risking away from oracles, flash loans, and pricing manipulation attacks that do not exist on platforms such as Atlendis or Maple.
  • Lesson #6: If you continue to use overcollateralized lending platforms, stick to blue-chip projects such as AAVE and Compound. The initial liquidity rewards on new lending Dapps are rarely worth it. Let someone else be the hero. Additionally, consider hedging your bets by borrowing against your position and removing the liquidity (e.g., post USDC and borrow ETH for staking) so that if the worst-case scenario does happen, you don’t lose all of your stolen fund’s value.

[1] Loss Due to Exploits Per Day

One response to “Smart Contract Vulnerabilities in On-Chain Lending – Part II”

  1. […] Smart Contract Vulnerabilities in ON-Chain lending – Part II (By Cicada Partners) […]

Leave a Reply

%d