The rapid growth of the Decentralized Finance (DeFi) ecosystem has led to the emergence of new security issues.
Existing smart contract vulnerability detection tools cannot detect certain DeFi attacks due to their lack of capacity to recover and understand high-level DeFi semantics.
The researchers propose a platform-independent mechanism to recover high-level DeFi semantics and detect price manipulation attacks using patterns expressed in the recovered DeFi semantics.
Core Research Question
How can price manipulation vulnerabilities and attacks on DeFi applications be detected?
Front-running: A practice in which an attacker profits off privileged information about an upcoming transaction.
Pump and Dump (P&D) Scams: Manipulating a stock’s value through misleading statements and selling once the price has risen following artificial inflation.
Flash Loan: A form of non-collateral loan where an entire transaction is encapsulated in a single transaction.
Price Manipulation Attack: An attack that exploits the vulnerabilities in the interface of an app to make a profit on loans and trades.
Direct Price Manipulation Attack: An attack where an attacker directly manipulates a token’s price in the liquidity of an AMM by performing an unwanted trade in the DEX.
Indirect Price Manipulation Attack: An attack where the token price of a vulnerable DeFi app whose price mechanism depends on real-time status is indirectly manipulated through making a trade on an AMM. If the price mechanism of a lending app is manipulable, a borrower may borrow more tokens than they are eligible to borrow.
Decentralized Exchange (DEX): An exchange where users can trade different tokens in a decentralized way by interacting with smart contracts.
Lending App: A DeFi app that allows users to lend their cryptocurrencies to borrowers. It relies on an AMM’s real-time reserve to price clients’ collaterals.
Automated Market Maker (AMM): A decentralized exchange that provides cryptocurrency exchange service without an intermediary.
Portfolio Management Application: A DeFi app that helps users invest their cryptocurrencies. It leverages AMM’s real-time quotation to price clients’ deposits.
Summary
The boom in decentralized finance has led to the emergence of DeFi related security issues such as front-running, P&D scams, and flash loan attacks.
Code and logic vulnerabilities in DeFi apps contribute to the occurrence of many security incidents.
Existing detection tools focus on code vulnerability, such as re-entrancy and integer overflow. However, they cannot be used to detect attacks caused by logic vulnerabilities due to the lack of capability to recover and understand high-level DeFi semantics.
Two new types of attack, direct and indirect price manipulation, are emerging alongside the increasing popularity of two Defi apps, DEX and lending apps.
Price manipulation emanates from the logic vulnerabilities of DeFi apps, thereby requiring an analysis of multiple smart contracts and an understanding of the high-level semantics of DeFi apps to be detected.
The researchers propose a new approach in a tool called DeFiRANGER to detect price manipulation attacks.
Method
Using a full Ethereum node with a modified Geth client, the researchers collect internal transaction metadata, EVM depth, and execution order.
After collecting Ethereum raw transactions, a cash flow tree (CFT) was built to convert raw transactions to token transfers, laying a foundation to lift DeFi semantics from.
Based on the CFT, the researchers lifted DeFi semantics and used predefined patterns expressed in DeFi actions to detect price manipulation attacks.
Results
DeFiRANGER detected 524 attacks from 350,823,625 transactions. Of the 524 attacks detected, 432 were true positives, while the remainder consisted of 51 false-positive arbitrage transactions and 31 transactions with misidentified DeFi actions.
Insufficient access control of a smart contract’s API makes vulnerable DeFi apps susceptible to direct price manipulation attacks.
Four DeFi apps were found susceptible to direct price manipulation attacks. They are Loopring, Dracula, Seal Finance, and Metronome.
Four vulnerable functions due to non-enforcement of access control, namely, sellTokenForLRC, drain, breed and closeAuction, were detected in the apps. An attacker could exploit the first three to sell cryptocurrencies in the liquidity pool of an AMM while the last one (closeAuction) directly deposits ether into Metronome’s AMM pool.
The root cause of indirect price manipulation attacks in DeFi apps was insecure price dependency. Portfolio management and lending apps are susceptible to indirect price manipulation.
Attackers now use a clean attack strategy to attack vulnerable apps and launder profits making attack traceability more difficult.
Security incidents directly impact the market value of vulnerable DeFi apps.
Discussion and Key Takeaways
DeFiRANGER cannot identify some DeFi actions, such as loan-related actions.
DeFiRANGER can only identify two types of price manipulation attacks. However, with the recovered SeFi semantics, the tool has the potential to detect more attacks.
Implications and Follow-ups
This paper is the first structured work to systematically detect price manipulation attacks in DeFi apps.
The biggest challenges to detecting price manipulation attacks are complicated interactions between multiple smart contracts in a transaction and the semantic gap between raw transactions in Ethereum and high-level DeFi semantics in DeFi apps.
DeFiRANGER misidentifies actions and gives false positives in some cases, especially in exchanges with more than two types of token.
Improving the security of the DeFi ecosystem by enhancing DeFiRANGER to detect more DeFi actions and attack types could be the focus of future works.
Can DeFiRANGER be developed to proactively detect vulnerabilities in smart contracts instead of detecting attacks only?
Applicability
When designing DeFi apps, developers should enforce sufficient access control on the functions that may change the AMM’s reserves.
DeFiRANGER can be used by DeFi apps to periodically monitor their vulnerabilities and detect price manipulation attacks.
Let me quickly ask some questions. Did the researchers particularly mention what sets DeFiRANGERS apart from pre-existing tools for detecting attacks on DeFi platforms?
Secondly, are there hints on method(s) which could be deployed for the proactive detection of vulnerabilities in DeFi smart contracts? Because realistically, prevention should be the ultimate target.
Yes, the researchers explained how DeFiRangers is different from every other tool for detecting attacks on DeFi platforms. Other tools are only able to detect attacks caused as a result of code vulnerabilities due to their inability to understand high-level DeFi semantics. On the other hand, DeFiRangers is created specifically with the ability to recover and understand high-level DeFi semantics.
Also, I agree with you that prevention should be the ultimate target. Numerous research has been conducted on the proactive detection of vulnerabilities in DeFi smart contracts. In Making Smart Contracts Smarter, the researchers examined Ethereum smart contract vulnerabilities. and proposed some improvements to the operational semantics of Ethereum. +However, some of the tools that have been proposed have several issues that make it difficult to achieve optimal detection. This paper and it’s supplementary material examine several tools that have been developed and highlight their problems. It is also important to note that most of the tools created to detect vulnerabilities focus on code vulnerabilities and not logic vulnerabilities. One of the future works for DeFiRangers could be improving the tool to proactively detect vulnerabilities.
By exploiting the transparency of the Ethereum blockchain, a large group of DeFi-related checking devices should be made accessible to general society to communicate with more noteworthy trust in monetary applications.
Checking network wellbeing: For individual clients
On loaning stages, client stores are in danger of liquidation once the guarantee proportions dip under specific limits because of cost vacillations. When the insurance falls, the rate drops, and the vault becomes open for liquidation. Clients can follow the insurance and choose to take care of borrowers or add stores to keep the vault protected and out of liquidation. Observing apparatuses will assume a significant part in sure client association with loaning conventions in the event that these devices give dependable ongoing and solid cost takes care of for various resources to make clients aware of make a move ahead of time.
One more proportion of observing on loaning stages is the use proportion of resource liquidity. The usage proportion is determined by separating the aggregate sum of obligations in view of the size of the proposal in the liquidity pool. On the off chance that all the cash in the complex is acquired and not paid, the use rate is practically 100 percent.
Smart contract reviews/audits
Auditing can recognize potential contract weaknesses through severe testing and white hat penetration before protocol or feature release. As the DeFi conventions fill in number, intricacy, and interconnectedness, more vulnerabilities and security dangers are probably going to happen.
Good use and understanding of TWAP can prevent most price attacks. This paper does not mention it. Using something external to the EVM for attack detection typically ends up being a centralization/attack vector. (Fully transparent and deterministic mechanisms, be them on chain or off, are gamble.)
I think all of this falls under MEV. (Miner/Maximal Extractable Value) Detecting price attacks is easy. Preventing them given a faulty smart contract is impossible / indeterminable since the agent doing the prevention can be included in the attacker’s plan.
There are a range of tools currently used to this end by most smart contract auditors. They fall into different categories. Slyther, a static analysis framework is a popular and free one that is usually a default in smart contract developers’ environment. Other, more powerful, commercial tools: Mythx, Certora.
For me, having not read the paper, there’s alot of distance between detecting unusual price changes (attack) and smart contract vulnerabilities. As such, I think it’s unlikely and definatelly innoportune given the existing advances and research already present in the space.
P.S.
I was just looking for a place to write my first comment on this forum.
I’m glad you found a place to write your first comment!
I’m hoping you can go into more depth about your observation that TWAP can prevent most price attacks. The article you linked to also indicates there are many weaknesses to TWAP as a solution as well. Even with those weaknesses, would you see TWAP being a better solution to the same problem that DeFiRANGERS is trying to solve in a less centralized way?
I agree with you that TWAP can prevent price attacks, I think it is possible that the authors did not mention this due to the ‘easy’ manipulation of TWAP. Also, I think another thing to point out is that the researchers are focused on attacks that arise from the smart contract logic and not the code. Logic vulnerabilities are seemingly not as commonly researched as the code vulnerabilities and have higher chances of passing DeFi audits based on existing tools that tackle code-based attacks like re-entrancy and integer overflow. It seems TWAP may be unable to prevent attacks arising from the smart contract logic.
To contextualise this, take the Harvest case, for instance, the arbitrage opportunity used by the hacker was not based on the code or detected in the security audit, rather, it was based on the protocol infrastructure. So, it seems there is still more research to be done on tools that can detect and prevent attacks that are based on the smart contract logic as opposed to the code.
Also, Promutator is a great tool that examines price oracle susceptibility (but based on the code vulnerabilities in the smart contract).
I fail to understand the distinction between code and logic. The code is a materialized sequence of logical instructions. If the code (smart contract) is vulnerable to a price attack it is so as a result of a failure in its logic. Its authors for example failed to account for a particular sequence of events. That is, they used unsound assumption.
But here I am getting ahead of myself because the reality is that a price attack is just an unwanted or wanted change in price at an inconvenient or perfect time because ‘the attacker’ is nothing more than a user that executes that which was made possible by the price attacked protocol.
The job of the smart contract developer is to ensure that the desirable is possible and, ideally, the undesirable impossible. Preventing price attacks is a matter of risk management in the specific use case. The only way to prevent price attacks is to define them as such: if my source says to me that the price is 1% different that what I did on average with the past 5 transactions then I refuse to execute this function. And that might just work for the top 10 most traded pairs but will brick your protocol relative to low volume or infrequent/niche tokens. So you can either limit what your protocol can do (fail to serve on volatility) or who it can serve (whitelisting collateral tokens etc.) or you accept that price is a number that is produced as a result of “this authority says so” or “this immutable logic living at this EVM memmory address determines it so”. Either way, it’s a matter of risk management and trust assumptions.
Formal verification (certora) is to the best of my knowledge the only way to prove that all undesirable states are unreachable. But that in turn require humans to logically map the totality of the undesirable.
TWAP is perfectly suitable for more meaningful applications where you can always ensure the attack is irrationally expensive. It’s not fine if you’re trying to prevent an intra-second arbitrage involving a low volume token. But this is a limited, niche activity in the grand scheme of things because in truth there’s nothing but surplus capital at stake in such DeFi. If this were the price of potatoes, the consumer as well as crop insurance companies would be totally fine using a 1 week fully traceable TWAP price.
No.
I just fail at seeing how anything mempool or external to the EVM, that’s also rational can detect and mitigate price attacks consistently in the presence of faulty logic. That’s implying there’s a superpower that can be used only by the good guys to cost efficiently cancel the bad guys with no hope for the bad guys to work their way around it. I think it’s possible on chain with risk management, but not reactive and from outside looking in. In my world, risk management is the only way to prevent price attacks in decentralized, deterministic, permissions protocols whereby a successful price attack is an unfortunate event in a calamitous state where it’s unreasonable to expect for the protocol to perform.
Thanks for the wonderful summary of the subject. I understand that price manipulation attacks are a serious concern in DeFi because they impact on trust. I believe there should be a further distinction made between the direct beneficiaries of price manipulation and the threat agents. This is because, given the DeFiRANGER detection analysis in the research, there were some false positives. Also, the need to enforce access control on API calls as a way to reduce the vulnerability of DeFi Apps
In the research, it was stated that DeFiRANGER can only identify two types of price manipulation. Is there a way to categorize the potential of other detection mechanisms for DeFiRANGER?
Thank you for your comment. I agree with you that a distinction should be drawn between direct beneficiaries of price manipulation and threat agents but I would like to know your thought process. Why do you think this distinction is necessary?
Also, yes! access control is absolutely necessary as a mitigating measure to reduce vulnerabilities of DAPPs. I think the categorisation of other detection mechanisms for DeFiRanger could form a part of future work for the tool.
I appreciate your feedback. The reason for the distinction is to narrow down the actual threat actors in the chain. For instance, a couple of malicious actors focus on an individual on DApp vs an organization focusing on the entire network. In either case loss of funds and reputations. I think this will further create an avenue to holistically classify the intents of the threat agents. Whether for undue benefits or disruption.
Hi @Tolulope I appreciate your research summary. I just needed to enquire one thing, since DEFIRANGER is the first tool that has the capability to detect price manipulation attacks in Ethereum, I am curious to know the reason why DeFiRANGER cannot identify some DeFi actions, such as loan-related actions?
Hence, can there be a tool that can help identify some Defi actions, such as loan -related actions?
It’s quite an amazing summary and knowledgeable, presenting the idea in a clear form.
As illustrated in this research, DeFiRANGER identified 51 false positives out 524 attacks. This is quite some percentage at 9.73.
Although the identification level of DeFiRANGER is better compared to other means as detailed through in the comments that it is profiled for high-level DeFi semantics.
However, as rightly pointed out,
Is this one of the cons of DeFiRANGER if yes, are there ways to mitigate this?
Is there an expectancy level of False Positive for any DeFiRANGER used to identify attacks in some transactions?
Is this one of the cons of DeFiRANGER if yes, are there ways to mitigate this?
Yes, this can be deemed as one of the cons of DeFiRanger. However, this can be easily mitigated as all attacks are manually confirmed.
Is there an expectancy level of False Positive for any DeFiRANGER used to identify attacks in some transactions?
This research yields a false positive rate of 4.42%. I don’t think that is enough to set an expectancy level, but it provides insight into the rate at which false positives occur.
Hello @Henry. The inability of DeFiRANGERS to detect specific DeFi actions, including loan-related actions, is identified by the researchers as one of its limitations. However, it will be considered one of the prototype’s improvements.
Hence, can there be a tool that can help identify some Defi actions, such as loan -related actions?
Etherscan is another tool that is used in identifying DeFi actions.
Nice research summary @Tolulope
Price Manipulation is one of the most frequent attack in the DeFi area and this involves manipulating the asset price data on decentralized exchanges (DEX), like Uniswap. Attackers can buy or sell a specific asset on a DeFi platform below or above the fair market price if the manipulated exchange is the only source of pricing information. Flash loans, which enable anyone to access enormous sums of funds at a very low cost, have becoming more frequently used to target susceptible contracts because this type of assault demands a significant amount of capital.
for the prevention of this price manipulation on Defi applications, it have been observed that protocols that rely on centralized on-chain price oracles, like a single DEX, have left themselves vulnerable to flash loan vulnerabilities. Since it only reflects the market condition of a single exchange, the data of an asset is severely constrained when employing a single on-chain exchange as price feed. Using a decentralized oracle like Chainlink, which is supported by a network of decentralized oracles that collects price information from many sources like Coingecko, and others to obtain complete market coverage, would help minimize the risk. Consequently, one flash loan transaction won’t have an impact on the price feed.
Numerous enhancements have been made to Uniswap V2 to support the price manipulation-resistant oracle. The price feed will only calculate the asset’s market price at the start of each block, before to any trade, rather than storing all market values in one block. By doing this, price becomes more difficult to manipulate because it is set by the prior block. Attackers must therefore make sure they can surpass the arbitrageurs by manipulating the price at the conclusion of the previous block, which is quite difficult at the end.
