Misleading Voters and Manipulating Governance
Widely deployed yet not widely understood ...
OBSERVATIONS FROM THE BLOCKCHAIN
No shit, there I was, surfin’ the blockchain looking for interesting bugs when I noticed that there are a lot of protocols sending messages … perhaps this is an overlooked part of a protocol since it does not directly show tokens going in and out, yet it can hold just as much or even more power! I started to look at those that could manifest from messaging and using raw bytes.
Here’s the idea I was thinking about recently: Circle (USDC) has a (relatively) new feature called CCTP. It allows devs to integrate the ability to send USDC cross-chain through Circle’s messaging contracts by burning tokens on the source chain and minting on the receiving chain. It functions similar to many bridges where there is an off-chain system monitoring listening for events emitted from a smart contract which then triggers an action.
From the docs:
Initiation. A user accesses an app powered by either CCTP V1 or CCTP V2 and initiates a Standard Transfer of USDC, specifying the recipient's wallet address on the destination chain.
Burn Event. The app facilitates a burn of the specified USDC amount on the source blockchain.
Attestation. Circle's Attestation Service observes the burn event and, after observing hard finality on the source chain, issues a signed attestation. Hard finality ensures the burn is irreversible (about 13 to 19 minutes for Ethereum and L2 chains.)
Mint Event. The app fetches the signed attestation from Circle and uses it to trigger the minting of USDC on the destination chain.
Completion. The recipient wallet address receives the newly minted USDC on the destination blockchain, completing the transfer.
Pretty simple right? The interesting thing is that a protocol can also use Circle’s system to send messages across chains.
Take a look at the MessageTransmitterV2 contract here: https://github.com/circlefin/evm-cctp-contracts/blob/master/src/v2/MessageTransmitterV2.sol
In the code above, notice the messageBody? receiveMessage in the MessageTransmitter contract does not care about the messageBody content that does not apply to Circle’s message.
The exploit idea would be if the protocol sending a message using Circle’s messenger contract encoded its messageBody using abi.encodePacked with adjacent dynamic data, you front-run the call to receiveMessage and manipulate the data so that for example, the original variables of a = “abc” and b = “def” in the sending message become a =”ab” and b = “cdef” in the receiving message, effectively performing a cross-chain exploit on the protocol.
You can use Dune for the events to find protocols interacting with it, or just pull up Bloxy on the mainnet messaging contract: https://bloxy.info/address/0x81D40F21F12A8F0E3252Bccb954D722d4c464B64
Circle CCTP github: https://github.com/circlefin/evm-cctp-contracts/tree/master
CCTP Contract Addresses: https://developers.circle.com/stablecoins/evm-smart-contracts
Mayan protocol (among others) uses CCTP: https://docs.mayan.finance/
WHERE'S RIPTIDE?
I am looking at older contracts! Why, ser chad, are you bothering with code that has been audited and long since forgotten about? Well, it doesn’t mean that it is bug free for one, and secondly, new types of bugs have emerged in the past 2 years that may reveal something interesting in some older (but still used contracts)!
Why?
Few eyeballs
Presumed safe
Older code might mean vulnerable to newer bugs
How I’m searching for these old contracts:
Primarily using Codeslaw: here’s an example how you can sort by deploy date: https://www.codeslaw.app/search?chain=ethereum&q=signature&sort=deployment-asc
THE GLENGARRY LEADS
Voting for what exactly? How to trick Governance.
A vulnerability exists in the governance execution flow of the popular