Introduction

Moonbeam is a Polkadot-based Parachain that provides EVM compatibility.

It is ranked 1st in TVL among Polkadot Parachain, and the moonbeam team is interested in security enough to set a bug bounty of $1,000,000 in immunefi.

So, while I was analyzing Moonbeam for vulnerabilities, I saw an update that happened recently on the Moonbeam Network.

I am writing this article for DAPP developers in the Moonbeam ecosystem, considering that this update may adversely affect the DAPPs that exist in the Moonbeam ecosystem.

‍

What Happened at Moonbeam Governance

On September 21, 2022, on Moonbeam Governance, the Moonbeam Council submitted a Proposal to upload the following three new precompile contracts to the mainnet, which was passed and updated on the mainnet. (link)

• Batch
• Call-Permit
• Proxy

The precompile contract was also used as an attack vector by pwning.eth, and recently it is an attack vector that has a lot of potential to cause problems in avalanche.

It is made differently from a general contract and given more authority than a general contract, which may cause critical problems in the ecosystem.

Although I did not find vulnerabilities such as directly stealing or freezing user’s funds, we describe such cases because the above-mentioned precompile contract can cause unintend code execution in Moonbeam Chain.

‍

Call-Permit Precompiled Contract

It seems to be inspired by gasless-transfer using the permit function in the ERC20 Token.

This is a precompile contract that allows other EOAs to pay the gas fee and execute the desired function even if a specific EOA does not have enough funds to use as a gas fee.

The code below is the "dispatch" function code that performs the above role in the Call-Permit Precompile Contract.

Check if the signature is the correct signature, and if it is, set "msg.sender" as "from" received as a parameter, and then call a specific function by referring to "to" and "data" received as parameters.

‍

Vulnerable Case

In many Contracts, a modifier or require statement similar to the following is written so that only EOA, not Contract, can be accessed to a specific function.

The code below is a snippet of code that exists somewhere.

The reason for using the above code may be different for each Dapp, but it is usually to prevent side effects caused by multiple calls within a single transaction. ex) Price Oracle Manipulation using flashloan etc..

‍

Below is the code that bypasses the simple sample onlyEOA modifier using Call-Permit.

I searched for verified contract that could cause a security incident in the Moonbeam Network, but could not find it.

However, as the moonbeam ecosystem grows and the number of dapps increases, I think there is enough room for problems.

‍

Recommendation

Although it is not a vulnerability that can directly extort or freeze users' money, it is judged that it can be utilized when a security incident occurs in the DAPP running on Moonbeam Network in the future. .

Even if it is not to eliminate the precompile contract, it is necessary to write a warning in the official document of the call-permit precompile contract.

‍

Conclusion

I contacted the developer of Moonbeam Team AlbertoV19, and he added a warning to the link below to note that a vulnerable case may occur.

(https://docs.moonbeam.network/builders/get-started/eth-compare/security/#bypass-sender-origin-checks)