Kotya security

Hey everyone, Kotya Guardians!

I guess it's time to make a summary for this year. It has been crazy for me, both in positive and negative ways and I'm really glad that it is finished. For the next year I promise to be more active with this channel, I have a lot of cool articles in drafts, read hundreds of interesting posts that I can't wait to share with you, found incredibly complex findings and also joined Consensys, where met lots of top-tier level hackers!
And most importantly, second full year in security space - 0 exploits after audits where I took part.

Regarding audits, I was fully booked almost all the time and have done 9 audits this year, so on average every engagement took more than a month (I don't separate fix reviews and reaudits after audit and count it as 1 finalized engagement).

Unexpectedly for myself I had 4 audits related to ZK, one of which was an audit of circuits, so looks like I'm becoming more ZK proofs oriented. I have done one solo audit, and there was one audit where I have been leading a team.

My audit portfolio has increased with new big names, such as Linea, Metamask, Ramses, Privacy Pools.

What about the findings?
3 Solo Crits
10 Solo Majors
And a bunch of Crits and Majors that I have found together with my colleagues. Last year this numbers were literally 10 times higher, but since this year I have worked mostly with top-tier projects and there were fewer projects, so I would say that's a fantastic result.

For example, in recent Ramses audit we have found with colleagues 1 Crit and 2 Major issues, while later Code4rena had a contest for the same codebase and have found only 2 Medium issues, where 1 Medium was copied from our report 😅 This proves that this year we provide top level audits, leaving the codebases fully clean, which is feaking awesome!

I wish you all to stay safe, find great findings, continue being a whitehat and never stop learning new stuff! ❤️

The Election phase has started, I would appreciate receiving a vote for us 🚀

Link to vote - https://www.tally.xyz/gov/arbitrum/council/security-council/election/2/round-2/nominee/0xEFA6e02047eDc1B55C93bB6B320B9728baA97Bb6

Thanks guys for your support ❤️

We got nominated, next step is elections 😎

OnyxDAO has just recently been hacked, >3.8 M $ already stolen.

Looks like it's a classic empty market attack.

"Another issue that facilitates the hack is related to the NFTLiquidation contract, which does not properly validate (untrusted) user input and was exploited to inflate the self-liquidation reward amount." - PeckShield.

https://x.com/peckshield/status/1839302663680438342

How to Lose $600k After Pausing a Protocol? The Penpie Exploit Explained (September 2024).

On September 3, 2024, the Penpie platform was exploited due to a reentrancy vulnerability, resulting in the theft of 11,113.6 ETH. The team has noticed the attack early, however it still didn't help them to fully stop the exploitation. Read all of the details in my latest article!

https://medium.com/@gr_gred/how-to-lose-600k-after-pausing-a-protocol-the-penpie-exploit-explained-september-2024-78a49250bc1c

Li.Fi Exploits Explained: The Same Mistake Twice

Read the full details about both exploits in my latest article:

https://medium.com/@gr_gred/li-fi-exploits-explained-the-same-mistake-twice-b46b1b9b4610

Type: #arbitraryData #validation

Project: Li.Fi protocol

Date: 16/07/24
Blockchain: Eth, Arbitrum

Problem: Possible calling arbitrary addresses with arbitrary data.

On July 11, 2024, Li.Fi added the GasZipFacet to their protocol, enabling ERC20 token swaps to native tokens and deposits to gas.zip, and just five days after integrating new facet, the contract was exploited. The vulnerability was exactly the same as in previous protocol exploit, the LibSwap library allowed arbitrary calls to arbitrary contracts. Despite having contract and selector whitelists in other helper contract, developers mistakenly imported the incorrect contract during development, and the lack of an audit for the new facet compounded the issue. This has led to a problem that anyone could transfer from funds from the users wallets, who has made infinite approvals to the Li.Fi contract.


Lessons learned by Li.Fi:
1) Contracts must be audited.
2) The repo must have good test coverage to ensure secure code delivery.
3) Any written code which goes to production should be cross-checked and reviewed.
4) Add documentation to the code, specifying how to use libraries securely, there was no documentation in the hacked library.
5) Teams must prepare an incident response to be ready for any circumstances.
6) A contract should have a blacklist of function selectors/addresses.
7) All contracts of big protocols are always monitored by bad actors. For example, a Telegram channel posts new updates of proxy contracts.
8) Don’t make infinite approvals. Revoke your existing approvals using revoke.cash.

The Hacker:
1) Called the depositToGasZipERC20 function, passing arbitrary transferFrom data and assetId as the attacker’s contract.
2) During the approve call to the hacker’s contract, a new contract was deployed and self-destructed, increasing the Li.Fi contract’s balance by 1 wei.
3) Executed the call from the facet to the token addresses, calling transferFrom from users who had given excessive allowance to the contract, transferring tokens to their address.
4) Finished the transaction with the successful deposit of 1 wei.

Discoverer: NaN, was hacked.
Harm: 11.6 M $
link | boost | twitter

Type: #arbitraryData #validation

Project: Li.Fi protocol

Date: 20/03/22
Blockchain: Eth

Problem: Possible calling arbitrary addresses with arbitrary data.

The hack took advantage of the pre-bridge swap feature, smart contract allows a caller to pass an array of multiple swaps using any address with arbitrary calldata. This design gave them maximum flexibility in what DEXs they could call and what methods they could call, but also allowed anyone to call other contracts, not just DEXs. To mitigate this, there was a check that the result of the swap or swaps is enough tokens to continue the bridging operation.

The attacker started by passing a legitimate swap of a small amount followed by multiple calls directly to various token contracts. Specifically, they called the transferFrom method which allowed the attacker to transfer funds from users’ wallets that had previously given infinite approval to our contract for that specific token.

Lessons learned by Li.Fi:
1) Implement contract whitelist.
2) Implement selector whitelist.
3) Disabled infifite approvals from the user by default.

The Hacker:
1) Called swapAndStartBridgeTokensViaCBridge function, started the legitimate swap swapping 50 USDT to USDC.
2) Called tokens addresses directly executing transferFrom from the users, who had excessive allowance to the contract, to his address.
3) Finished successfully the bridge of the 50 USDC.

Discoverer: NaN, was hacked.
Harm: 600 k $
link | boost | twitter

So, less than one third of all has chosen the correct variant.

This problem is quite hard to find in the codebase, especially if the data is formed in different contracts and passed between each other, so it's always important to write high quality code, minimising the quantity of the redundant operations (in this case encoding several times), and even at the first glance having two encodePacked calls in the function flow doesn't seem to lead to anything bad, it does. This is the reason why I personally try to clean the clients repo from all of the infos and optimize the codebase, even if there is no bug today in the low-quality code, it doesn't mean there will be no bug later during the code development.

Here is the next poll, take a look to the picture from this message and choose the correct answer: