Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

In DeFi, there are many lending and borrowing platforms. Users on these platforms can either lend tokens to receive interest or borrow tokens to conduct other activities. Naturally, the borrowers need to provide collateral to take out these loans.

If the borrower doesn't make the repayment schedule or the collateral drops below a certain price threshold, then the load is liquidated. This allows other players to payback the loans assets. In exchange, they get a discount on the collateral that the user provided. The original user keeps the assets in this case.

The first vulnerability is Liquidation Before Default. The liquidation process allows for a liquidator to make money by purchasing the collateral at a discount. If it's possible to force this early, then money can be stolen.

In the first example case, there is a function to return whether a payment is on time or not. If they are overdue, then a user can liquidate the loan. If the loans first payment hasn't been made, then the value is 0, which results in it being liquidatable. Another case allows for the loan parameters to be changed after the loan has been given. Another was a lack of an updated variable leads to instantly written off loan.

The next bug is borrower can't be liquidated. If a borrower can devise a loan offer that results in the collateral not being able to be liquidated, this creates a major problem. The AddressSet type will override existing values. So, if an attacker has a loan they could potentially override their collateral with 0, making it impossible to get any collateral out. Another case is providing a malicious oracle.

If it's possible to keep the collateral and keep the borrowed funds, the whole system falls apart. In the example, a user can take out multiple loans. When they close out a non-existent loan, it will subtract from the counter without actually doing anything. Hence, a user can take out a large loan, subtract the loan counter and keep the collateral. Some of the other examples are logic flaws that allow for the code to perform unintended executions.

The next two findings are related to access controls: repayments paused while liquidations enabled and Collateral Pause Stops Existing Repayment & Liquidation. It's common for smart contracts to be pausable in the event of a vulnerability or market crash. However, should everything be pausible?

Depending on the case, it can have problems. For instance, if repayment is blocked then the crash of a cryptocurrency asset being used as collateral could drastically effect the protocol. Additionally, if repayments are not allowed but liquidations are, then it's not fair since the proper payments cannot be made on the funds.

A few more... if is a liquidator paying back the collateral for the loaner but the amount is insufficient. And, infinite loan rollover with the borrower continually getting an extension on the loan without the lender being able to get it back.

There are many more ways that loans can go wrong. denial of service and several other financial related issues. Overall, a very interesting post on loans related issues with good links to the previous findings.