Platform: Code4rena
Start Date: 29/07/2022
Pot Size: $50,000 USDC
Total HM: 6
Participants: 75
Period: 5 days
Judge: GalloDaSballo
Total Solo HM: 3
Id: 149
League: ETH
Rank: 54/75
Findings: 1
Award: $56.32
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: oyc_109
Also found by: 0x1f8b, 0x52, 0xNazgul, 0xSmartContract, 0xf15ers, 8olidity, Aymen0909, Bnke0x0, CertoraInc, Chom, CodingNameKiki, Deivitto, Dravee, ElKu, IllIllI, JC, Lambda, Noah3o6, NoamYakov, RedOneN, Respx, ReyAdmirado, Rohan16, Rolezn, Ruhum, Sm4rty, TomJ, Twpony, Waze, Yiko, __141345__, ajtra, apostle0x01, ashiq0x01, asutorufos, bardamu, benbaessler, berndartmueller, bharg4v, bulej93, c3phas, cccz, ch13fd357r0y3r, codexploder, cryptonue, cryptphi, defsec, djxploit, durianSausage, fatherOfBlocks, gogo, hansfriese, horsefacts, ignacio, kyteg, lucacez, mics, rbserver, robee, sashik_eth, simon135, sseefried, tofunmi, xiaoming90
56.3243 USDC - $56.32
https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/auth/AxelarAuthWeighted.sol#L47
This is not a bug in the code but more of a logical and architectural issue.
A lot of recent bridges exploits were due to some stolen private keys that could be used to sign messages and steal the protocol funds.
This is why it is so important to keep our message verifying process decentralized so it will not be possible to hack the system with only a couple of stolen keys.
The protocol tries to implement such solution with the need of a majority of operators to sign a transaction on the bridge.
The problem is the there is an owner address that can set those operator to what ever he wants, so basically the owner is a point of failure of the protocol and in a case of a stolen owner key the protocol can be hacked and lose all of its money.
A lot of other bridges demand the majority of the operators to change the operators addresses, so in that way the protocol stays decentralized
(see in PoC an example of such implementation in other system).
As we can see here: https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/auth/AxelarAuthWeighted.sol#L47
The owner can call transferOperatorship and set the operators to whatever he wants, for example a single address that is in his conrol. And after that he has full control over the protocol and can steal all the protocol funds.
And as we can see here this is other implementation of setting the operators with the need of a majority of validators to do so. https://github.com/crypto-org-chain/gravity-bridge/blob/v2.0.0-cronos/solidity/contracts/Gravity.sol#L249
Vscode.
I recommend to find a way to set the operators in a decentralized way. Perhaps consider the solution I show on PoC.
#0 - GalloDaSballo
2022-08-03T21:17:50Z
Admin privilege is historically Medium Severity
Report seems to lack actual POC (only shows transfer of ownership)
#1 - re1ro
2022-08-23T00:53:13Z
In our deployment setup the owner of the AxelarAuthWeighted is the AxelarGateway itself. So transferOperatorship can be called only by the gateway contract and transferOperatorship command needs to be signed by the majority of operators first.
#2 - GalloDaSballo
2022-09-04T23:40:34Z
The warden makes a statement about the owner being a center vulnerability point for AxelarAuthWeighted
The sponsor disputes by stating that such contract will be owned by the AxerarGateway meaning that operators will be effectively acting as a multisig for the contract.
I think the statement from the Warden has validity in that the systems weakest point seems to be the transferOperatorship function, however there's a difference between tating that that's the weak link to proving it as such and showing how to break it.
Because of that I think that the finding can be "interpreted" as owner is able to change weights and kick operators in one block.
Because the Network itself relies on trusted validators, I think a more appropriate severity for this report is QA