An Evaluation Method for Risk Propagation after Decentralized Finance Attacks

Abstract

The present invention discloses a method for evaluating the risk propagation after a decentralized finance attack. At the code level, locate the vulnerable contracts involved in the attack and determine their vulnerability logic, generate vulnerability detectors, and use them to perform pattern matching on the intermediate representation forms of similar contracts to obtain potential victim contracts; at the financial level, locate the contracts that incur asset losses in the attack and the types of assets lost, trace the corresponding historical transactions to identify asset providers and take snapshots; identify the functions in the contracts related to the status of the lost assets, trace their historical calls, and identify the asset dependents related to the status of the lost assets; locate the decentralized applications affected in the attack, identify the tokens they issue, trace the holders of the tokens and their price mechanisms, and determine the decentralized applications related to the price changes of the tokens. The present invention effectively identifies and evaluates the contracts and decentralized applications that may be affected by the attack, and solves the problem of detecting the risk propagation caused by the attack.

Description

Technical Field

[0001] The present invention relates to the technical field of decentralized finance security, and particularly to an evaluation method for risk propagation after a decentralized finance attack. Background Art

[0002] The rapid development of decentralized finance has continuously reshaped the financial landscape. In response, the academic and industrial communities have proposed various security measures, covering all aspects of different life cycles of decentralized protocols. In the stage before the protocol goes live, security services and measures such as code auditing, formal verification, and contract vulnerability detection help identify vulnerabilities and defects in the protocol. In the stage after the protocol goes live, methods such as attack detection and runtime monitoring can be used to detect attacks and identify abnormal states of the protocol. In the stage when an attack occurs, by taking security measures such as attack interception, automatic response, vulnerability analysis, fund flow tracking, and asset rescue, losses can be mitigated and recovered.

[0003] However, although a large amount of work focuses on the three main stages of decentralized finance security, the stage after an attack occurs, especially the cascading impact of an attack on other decentralized applications, has still not received sufficient research, even though the impacts caused by these risk propagations often result in huge asset losses. These cascading risks mainly stem from vulnerabilities at the code level and the financial level. Summary of the Invention

[0004] Aiming at the deficiencies of the prior art, the present invention proposes an evaluation method for risk propagation after a decentralized finance attack, solves the problem of detecting risk propagation caused by an attack, and improves the comprehensiveness and accuracy of risk identification and response.

[0005] The specific technical solution is as follows:

[0006] An evaluation method for risk propagation after a decentralized finance attack, including an independent code level and a financial level; identifying potential victim contracts at the code level, and identifying asset providers, asset dependents, and decentralized applications affected by asset losses at the financial level;

[0007] At the code level, locate the vulnerable contract involved in the attack and determine its vulnerability logic, and accordingly generate a vulnerability detector; use a similarity detection algorithm to obtain similar contracts similar to the vulnerable contract; use the vulnerability detector to perform pattern matching on the intermediate representation form of the similar contracts to obtain potential victim contracts;

[0008] At the financial level, identify the contracts that incur asset losses in the targeted attack and the types of assets lost. Identify the asset providers before the attack corresponding to them by tracing the corresponding historical transactions, take snapshots of them, and then identify the truly damaged asset providers according to the flow of assets. Identify the functions related to the status of the lost assets in the contracts that incur asset losses, trace the historical calls of the functions, and identify the asset dependents related to the status of the lost assets.

[0009] Identify the decentralized applications affected in the attack, i.e., the victim applications. Identify the tokens issued by the victim applications, and determine the decentralized applications related to the price changes of the tokens by tracing the holders of the tokens and their price mechanisms.

[0010] Furthermore, at the code level, generating a vulnerability detector is specifically achieved through the following steps:

[0011] (1) Locate the vulnerable contracts involved in the attack and determine their vulnerability logic, and convert the vulnerable contracts into an intermediate representation form.

[0012] (2) Use static analysis methods to traverse the control paths of the contracts, deduce the execution branches that meet the vulnerability trigger conditions, and take the execution branches as the static analysis results.

[0013] Or use dynamic analysis techniques to obtain the runtime abnormal behaviors triggered by specific inputs through automated inputs, and take the abnormal behaviors as the dynamic analysis results.

[0014] (3) Combine the vulnerability logic with the vulnerability characteristics of the static analysis results or dynamic analysis results to construct a vulnerability detector that can identify the vulnerability characteristics.

[0015] Furthermore, the intermediate representation form includes: abstract syntax tree, Yul intermediate language.

[0016] Furthermore, at the code level, obtaining similar contracts similar to the vulnerable contracts using a similarity detection algorithm is specifically achieved through the following steps:

[0017] (1) Determine the decentralized application to which the vulnerable contract belongs and collect the cloned applications of the decentralized application.

[0018] (2) Use the cloned applications as address tags and collect the corresponding contract addresses and source codes.

[0019] (3) Use the similarity detection algorithm to perform similarity detection on the contract source codes corresponding to the collected contract addresses, and identify the similar contracts similar to the vulnerable contracts.

[0020] Further, at the financial level, identify the asset providers before the attack corresponding to the historical transactions through tracking and take snapshots of them, including the following methods:

[0021] ① When the asset loser issues voucher tokens to the asset provider, generate an asset provider snapshot by tracking the historical transfer transactions of the voucher tokens;

[0022] ② When the asset loser does not issue voucher tokens and receives assets by calling a fixed function, track the historical calls of this fixed function to generate an asset provider snapshot;

[0023] ③ When the asset loser neither issues voucher tokens nor relies on a fixed function to receive assets, track the historical transfer transactions of the asset loser and screen out the historical transfer transactions corresponding to the required lost asset types from them to generate an asset provider snapshot corresponding to the historical transfer transactions.

[0024] Further, at the financial level, the functions related to the status of lost assets include the functions related to the asset status provided by the asset loser and the functions of the token balances related to the lost assets;

[0025] Determine the corresponding asset dependents according to the asset dependence form, specifically including the following methods:

[0026] ① If the asset dependent directly depends on the function related to the status of the lost assets provided by the asset loser, use financial keywords for fuzzy matching to identify the function related to the status of the lost assets and track the historical calls of the function to discover the asset dependent;

[0027] ② If the asset dependent indirectly depends on the asset status of the asset loser by depending on the function of the token balance related to the lost assets, track the function of the token balance of the lost assets, filter out the historical calls related to the asset loser to discover the asset dependent.

[0028] Further, the financial keywords include: price, quantity, balance, value.

[0029] Further, at the financial level, determine the decentralized applications related to the price change of the tokens issued by the victim application through two - layer market levels, specifically as follows:

[0030] The first layer is used to identify the decentralized applications that can directly cause token price fluctuations. The decentralized applications include decentralized exchanges and centralized exchanges;

[0031] For a decentralized exchange, trace the historical transfer transactions of the tokens issued by the victim application, create a snapshot for the token holders, match the names of the token holders with transaction keywords, and filter out the token holders that can cause fluctuations in the token price, which are the decentralized exchanges that can directly cause fluctuations in the token price;

[0032] For a centralized exchange, collect all existing centralized exchanges, and identify whether there is a trading pair of the tokens issued by the victim application and the price change of the tokens through the publicly available call interfaces provided by them. If it exists, it is a centralized exchange that can directly cause fluctuations in the token price;

[0033] The second layer is used to identify decentralized applications directly affected by the change in token price.

[0034] Furthermore, the method for the second layer to identify decentralized applications directly affected by the change in token price includes the following:

[0035] (1) Trace the historical transfer transactions of the issued tokens, create a snapshot for the token holders; by matching the names of the token holders with behavior keywords, filter out the holders affected by the token price, that is, decentralized applications;

[0036] (2) Collect the flowing price oracles and filter out the oracles that provide the price of the issued tokens; track the relevant calls for querying the price of the issued tokens in the oracles to identify the decentralized applications that use and rely on the token price information;

[0037] (3) Combine the relevant information of the issued tokens and the keywords of the relevant decentralized applications, and conduct an associated search on the Internet to collect and filter out the decentralized applications that may be affected by the change in token price.

[0038] Furthermore, the behavior keywords in (1) include: voting, liquidation, transfer; the keywords of the decentralized applications in (3) include: voting, borrowing.

[0039] The beneficial effects of the present invention are:

[0040] The method of the present invention can effectively identify and evaluate the contracts and decentralized applications affected by the attack through multi-dimensional analysis at the code level and the financial level, solves the problem of detecting the risk propagation caused by the attack, and significantly improves the comprehensiveness and accuracy of risk identification and response. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 is a flowchart of the method for evaluating the risk propagation after a decentralized finance attack in an embodiment of the present invention.

[0042] Figure 2It is a schematic flow chart for identifying potential victim contracts at the code level in the embodiments of the present invention. Detailed implementation manners

[0043] The present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments. The purpose and effect of the present invention will become more apparent. The present invention will be further described in detail below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0044] An evaluation method for risk propagation after decentralized finance attacks, based on two risk propagation paths at the code level and the financial level, identifies and evaluates contracts and decentralized applications that may be affected by decentralized finance cascading effects. The risk propagation identification processes at the two levels are independent of each other. The identification and evaluation processes at the two levels are specifically as follows:

[0045] As Figure 1 shown, at the code level, first identify the vulnerable contracts involved in the attack, so as to identify potential victim contracts. A vulnerable contract refers to a contract with vulnerabilities exploited by an attacker, and these vulnerabilities will become the root cause of the attack. If a certain contract has the same vulnerability as the attacked contract, it may be threatened by a similar attack. As Figure 2 shown, these potential victim contracts are specifically identified through two stages: a similar contract identification stage and a vulnerability logic matching stage.

[0046] In the similar contract identification stage, the following operations are sequentially performed: (1) Determine the decentralized application to which the vulnerable contract belongs, and then use the decentralized finance data tracking platform (DeFiLlama) to collect the cloned applications of this decentralized application; (2) Use the collected cloned applications as address tags, and use the Ethereum browser (Etherscan) to collect the corresponding contract addresses and source codes; (3) Use a similarity detection algorithm to perform similarity detection on the contract source codes corresponding to these collected contract addresses, and identify the contracts similar to the vulnerable contract, which are called similar contracts.

[0047] In the vulnerability logic matching phase, the following operations are performed in sequence: (1) Determine the vulnerability logic of the vulnerable contract, that is, clarify the triggering logic and key semantic features of the target vulnerability, such as function call order, state variable dependency relationship, or external call behavior, etc. Then convert the vulnerable contract into an intermediate representation form (such as abstract syntax tree, Yul intermediate language, etc.); (2) Select static analysis or dynamic analysis according to the specific vulnerability logic. For example, for reentrancy vulnerabilities and access control vulnerabilities, static analysis is selected, while for scenarios that trigger vulnerabilities such as external calls and specific input data, dynamic analysis is selected. Use static analysis methods (such as symbolic execution, etc.) to traverse the control path of the contract, derive the execution branches that meet the vulnerability triggering conditions, and use the derivation result as the static analysis result; or use dynamic analysis techniques (such as fuzz testing, etc.) to obtain the runtime abnormal behavior triggered by specific inputs through a large number of automated inputs, and use the abnormal behavior as the dynamic analysis result; (3) Combine the vulnerability features of the vulnerability logic and the static analysis or dynamic analysis results to construct a vulnerability detector that can identify this type of vulnerability.

[0048] The similar contract identification phase and the vulnerability logic matching phase can be carried out simultaneously. Use the vulnerability detector obtained in the vulnerability logic matching phase to perform pattern matching on the intermediate representation form of the similar contracts obtained in the similar contract identification phase, and finally identify the potential victim contracts containing the same vulnerability.

[0049] At the financial level, although an attack will inevitably cause losses to the contract, the lost assets do not necessarily come from the attacked contract. Usually, the assets are transferred or authorized by other users or applications as asset providers. These assets support specific functions (such as staking), and in fact, the directly affected asset providers are the direct victims of the attack. To obtain the directly affected asset providers (i.e., the initial providers of a certain type of asset), first identify the contract that incurs asset losses in the attack, the damaged assets involved and their types, and then take snapshots of the asset providers before the attack through the following three methods:

[0050] ① When the asset loser issues voucher tokens to its asset provider, generate an asset provider snapshot by tracing the historical transfer transactions of these voucher tokens.

[0051] ② When the asset loser does not issue voucher tokens but receives assets by calling a fixed function, generate an asset provider snapshot by tracing the historical calls of this asset receiving function.

[0052] ③ When the asset loser neither issues voucher tokens nor relies on a fixed function to receive assets, trace the historical transfer transactions of the asset loser and filter out the historical transfer transactions corresponding to the required lost asset type among them to generate an asset provider snapshot corresponding to the historical transfer transactions.

[0053] Then, according to the liquidity of the assets, identify the actual asset providers who have suffered losses. The actual asset providers who have suffered losses refer to the initial providers of a certain type of assets.

[0054] In addition, the asset losses caused by the attack usually have a significant impact on the asset status of the asset losers. For example, the assets are exhausted or seriously imbalanced. The asset-dependent contracts that rely on the asset status to perform specific functions may thus suffer losses. After determining the asset losers and the types of assets they have lost, judge their corresponding asset dependence forms (direct dependence or indirect dependence), so as to determine the asset dependents:

[0055] ① Direct dependence: The asset dependents directly depend on the functions related to the status of the lost assets provided by the asset losers. First, use financial keywords for fuzzy matching to identify the functions related to the status of the lost assets, and then discover the asset dependents by tracing the historical calls of these functions; the financial keywords include: "price", "amount", "balance", "value", etc.

[0056] ② Indirect dependence: The asset dependents indirectly depend on the asset status of the asset losers by relying on the functions related to the token balances of the lost assets. Discover the asset dependents by tracing the token balance function "balanceOf" of the lost assets and filtering to obtain the historical calls related to the asset losers.

[0057] In addition, if the decentralized applications affected in the attack have issued tokens, the attack usually triggers the market activities of these tokens. According to the principle of risk propagation in the economic market, this risk will successively affect decentralized applications at different levels. Locate the decentralized applications affected in the attack, that is, the victim applications; identify the tokens issued by the victim applications, and based on market behavior analysis by tracing the holders of these tokens and their price mechanisms, determine the decentralized applications related to the price changes of the tokens and evaluate the risk propagation they have suffered. In the embodiments of the present invention, the impact of risk propagation suffered by decentralized applications is identified and evaluated through two levels of market hierarchies.

[0058] The first layer is used to identify decentralized applications (including decentralized exchanges and centralized exchanges) that can directly cause fluctuations in token prices (such as token selling caused by an attack may lead to a price drop, etc.). For decentralized exchanges, first track the historical transfer transactions of the tokens issued by the victim application to create a snapshot for token holders; then, by matching the names of these token holders with transaction keywords such as "exchange" and "swap", screen out those token holders who can cause fluctuations in token prices, that is, the decentralized exchanges that can directly cause fluctuations in token prices. For centralized exchanges, first collect all existing centralized exchanges, and then identify whether there are trading pairs of tokens issued by the victim application and the price changes of the tokens through the publicly available call interfaces provided by them. If so, it is a centralized exchange that can directly cause fluctuations in token prices, and the token price will drop due to user selling after the attack.

[0059] The second layer is used to identify decentralized applications that are directly affected by token price changes (such as a decrease in token price may lead to a reduction in the cost of secondary attacks, triggering liquidation, etc.). The following lists three typical methods for identifying decentralized applications:

[0060] (1) First, track the historical transfer transactions of the issued tokens to create a snapshot for token holders. Then, by matching the names of these token holders with action keywords such as "vote", "liquidate", and "transfer", screen out those holders affected by the token price, that is, decentralized applications, such as decentralized autonomous organizations, lending platforms, cryptocurrencies, etc.

[0061] (2) First, collect liquid price oracles (such as Chainlink, Pyth), and screen out those oracles that provide the prices of the issued tokens. Then, by tracking the relevant calls for querying the prices of the issued tokens in these oracles, identify the decentralized applications that use and rely on this token price information.

[0062] (3) Combine relevant information such as the name and symbol of the issued token, as well as keywords related to the relevant decentralized applications (such as "vote", "borrow", etc.), and conduct an associated search on the Internet to collect and screen potential decentralized applications that may be affected by token price changes.

[0063] The present invention can identify market fluctuations caused by attacks in real time and track changes in trading behaviors after attacks occur, helping affected decentralized applications and users take countermeasures to avoid possible market losses. At the same time, it can also be reused for contracts and decentralized applications that have been found to be affected by attack cascades to further discover deeper-level contracts and applications in the risk propagation model to prevent the further spread of such risks.

[0064] Those of ordinary skill in the art can understand that the above are only preferred examples of the invention and are not used to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, for those skilled in the art, they can still modify the technical solutions described in the foregoing examples or make equivalent replacements for some of the technical features. Any modifications, equivalent replacements, etc. made within the spirit and principle of the invention shall be included within the protection scope of the invention.

Claims

1. An evaluation method for risk propagation after decentralized finance attacks, characterized in that, It includes an independent code layer and a financial layer; at the code layer, potential victim contracts are identified, and at the financial layer, asset providers, asset dependents, and decentralized applications affected by asset losses are identified. At the code layer, the vulnerable contracts involved in the attack are located and their vulnerability logic is determined, and a vulnerability detector is generated accordingly; a similarity detection algorithm is used to obtain similar contracts similar to the vulnerable contracts. The intermediate representation form of the similar contracts is pattern-matched using the vulnerability detector to obtain potential victim contracts. At the financial layer, the contracts that incur asset losses in the attack and the types of assets they lose are located, the asset providers before the attack corresponding to them are identified by tracing the corresponding historical transactions, and snapshots are taken of them. Then, according to the flow of assets, the truly damaged asset providers are identified; the functions related to the status of the lost assets in the contracts that incur asset losses are identified, and the historical calls of the functions are traced to identify the asset dependents related to the status of the lost assets. The decentralized applications affected in the attack, i.e., victim applications, are located; the tokens issued by the victim applications are identified, and by tracing the holders of the tokens and their price mechanisms, the decentralized applications related to the price changes of the tokens are determined.

2. The evaluation method for risk propagation after a decentralized finance attack according to claim 1, wherein At the code layer, the generation of the vulnerability detector is specifically implemented through the following steps: (1) Locate the vulnerable contracts involved in the attack and determine their vulnerability logic, and convert the vulnerable contracts into an intermediate representation form. (2) Use static analysis methods to traverse the control paths of the contracts, deduce the execution branches that meet the vulnerability trigger conditions, and take the execution branches as the static analysis results. Or use dynamic analysis techniques to obtain the runtime abnormal behaviors triggered by specific inputs through automated inputs, and take the abnormal behaviors as the dynamic analysis results. (3) Combine the vulnerability logic with the vulnerability characteristics of the static analysis results or dynamic analysis results to construct a vulnerability detector that can identify the vulnerability characteristics.

3. The risk propagation assessment method for decentralized finance attacks according to claim 2, characterized in that, The intermediate representation form includes: abstract syntax tree, Yul intermediate language.

4. The risk propagation assessment method for decentralized finance attacks according to claim 1, characterized in that At the code layer, a similarity detection algorithm is used to obtain similar contracts similar to the vulnerable contracts, which is specifically implemented through the following steps: (1) Determine the decentralized application to which the vulnerable contract belongs and collect the cloned applications of the decentralized application. (2) Use the cloned applications as address tags to collect the corresponding contract addresses and source codes. (3) Use the similarity detection algorithm to perform similarity detection on the contract source codes corresponding to the collected contract addresses to identify similar contracts similar to the vulnerable contracts.

5. The risk propagation assessment method for decentralized finance attacks according to claim 1, wherein At the financial layer, the asset providers before the attack corresponding to them are identified by tracing historical transactions, and snapshots are taken of them, including the following methods: ① When the asset loser issues voucher tokens to the asset provider, a snapshot of the asset provider is generated by tracing the historical transfer transactions of the voucher tokens. ② When the asset loser does not issue voucher tokens and receives assets by calling a fixed function, trace the historical calls of the fixed function to generate a snapshot of the asset provider. ③When the asset loser neither issues voucher tokens nor relies on a fixed function to receive assets, track the historical transfer transactions of the asset loser, and screen out the historical transfer transactions corresponding to the required lost asset types from them to generate a snapshot of the asset providers corresponding to the historical transfer transactions.

6. The evaluation method for risk propagation after a decentralized finance attack according to claim 1, characterized in that, At the financial level, the functions related to the status of lost assets include the functions related to the asset status provided by the asset loser and the function of the token balance related to the lost assets; Determine the corresponding asset dependents according to the form of asset dependence, specifically including the following methods: ①If the asset dependent directly depends on the function related to the status of lost assets provided by the asset loser, use financial keywords for fuzzy matching to identify the function related to the status of lost assets, and track the historical calls of the function to discover the asset dependent; ②If the asset dependent indirectly depends on the asset status of the asset loser by depending on the function of the token balance related to the lost assets, track the token balance function of the lost assets, filter out the historical calls related to the asset loser to discover the asset dependent.

7. The risk propagation assessment method for decentralized finance attacks according to claim 6, wherein The financial keywords include: price, quantity, balance, value.

8. The risk propagation assessment method for decentralized finance attacks according to claim 1, characterized in that, At the financial level, determine the decentralized applications related to the price change of the tokens issued by the victim application through two layers of market hierarchies, specifically as follows: The first layer is used to identify the decentralized applications that can directly cause token price fluctuations. The decentralized applications include decentralized exchanges and centralized exchanges; For decentralized exchanges, track the historical transfer transactions of the tokens issued by the victim application, create a snapshot for the token holders, match the names of the token holders with the transaction keywords, and screen out the token holders that can cause token price fluctuations, which are the decentralized exchanges that can directly cause token price fluctuations; For centralized exchanges, collect all existing centralized exchanges, and identify whether there is a trading pair of the tokens issued by the victim application and the price change of the tokens through the public call interfaces provided by them. If it exists, it is a centralized exchange that can directly cause token price fluctuations; The second layer is used to identify the decentralized applications directly affected by the token price change.

9. The evaluation method for risk propagation after a decentralized finance attack according to claim 8, wherein The second layer identifies the decentralized applications directly affected by the token price change, including the following methods: (1) Track the historical transfer transactions of the issued tokens, create a snapshot for the token holders; screen out the holders affected by the token price by matching the names of the token holders with the behavior keywords, that is, the decentralized applications; (2) Collect the flowing price oracles and screen out the oracles that provide the prices of the issued tokens; track the relevant calls for querying the prices of the issued tokens in the oracles to identify the decentralized applications that use and rely on the token price information; (3) Combine the relevant information of the issued tokens and the keywords of the relevant decentralized applications for an associated search on the Internet to collect and screen out the decentralized applications that may be affected by the token price change.

10. The evaluation method for risk propagation after a decentralized finance attack according to claim 9, characterized in that, The behavior keywords in (1) include: voting, liquidation, transfer; the keywords of the decentralized applications in (3) include: voting, borrowing.

Images