HAECHI Audit is now KALOS (read more)
We have secured over $60b worth of crypto assets across 400+ global crypto projects — L1/L2 projects, defi protocols, P2E games, and bridges — notably 1inch, SushiSwap, Badger DAO, SuperRare, Klaytn and Chainsafe.
Blogs & Analysis
Tech
List View
Search
Article realeased on Dec 8, 2022
Summary
•
The Extended Berkeley Packet Filter (eBPF) was originally created to filter packets in the kernel.
•
Currently, eBPF is used in various areas such as Application Profiling due to its efficiency and scalability.
•
Considering these advantages, when Smart Contracts running in Solana are compiled, they are converted into eBPF Bytecode, and a separate virtual machine exists to execute them.
•
According to the Audit Report (https://solana.com/solana-security-audit-2019.pdf) issued by Kudelski Security in 2019, rBPF Virtual Machine was not an audit scope, and no audits for rBPF were seen after that.
•
So, among the attack surfaces that exist in Solana, I thought it was the point where zero day vulnerabilities can be found with the highest probability, and I document what I had learned before looking for bugs.
Introduction
The Extended Berkeley Packet Filter (eBPF) was originally created to filter and monitor packets in the kernel.
Solana rBPF Vulnerability Case Study
Article realeased on Nov 29, 2022
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
Why the Moonbeam’s new pre-compile contract can create side-effect on its ecosystem
Article realeased on Oct 14, 2022
Introduction
On August 3rd, security researchers Jinu and Allen found a vulnerability in THORChain TSS module, and submitted it via ImmuneFi. A malicious node operator (with a small number of malicious nodes) could launch DoS and blame other innocent node operator for it.
Understanding TSS & Usage
First, we need to understand what TSS actually is. Basically, a group of operators will each have their share of the ECDSA private key, and with enough people they can sign a message without revealing their share. THORChain used this to sign outbound transactions.
The cryptography inside TSS has been improving in terms of efficiency, security, and other properties over the years. The paper https://eprint.iacr.org/2021/060 presents a method where if the TSS signing fails, the system can find out which signer had caused the failure.
This is called “Identifiable Abort” - and this is great as now the system can penalize the signer who caused the failure. For example, they can remove the rewards for block generation.
THORChain Bug Disclosure
Audit Reports
Reports
Search
Report realeased on Oct 21, 2022
About MarbleX - NFT Marketplace Protocol
The contract we audited is mostly equal to the contracts of Wyvern v2.2 in this repository. There are two major components of the project, the NFT Marketplace and the DAO.
The NFT Marketplace works as follows. There’s an Order structure that contains the information on the order placed. This includes, among other things, maker/taker of the order, exchange address, payment token address, price information, fee information, listing time and expiration time, and the salt for preventing duplicate hashes. The execution of NFT transfers are handled in a much more general way in Wyvern 2.2. It allows the buyer and the seller to decide on a contract call parameters, i.e. the target of the call, the call method (call or delegatecall) and the calldata. To decide on the calldata, both the buyer and the seller decide on their idea on the calldata and the bitmap on which bits can be changed by the other. With some memory manipulation, the contract computes the final calldata based on the two order structures of buyer and seller and executes the contract. To verify that the orders are approved by the buyer or seller, either the appropriate ECDSA signatures should be provided, or they have to call the contract for approvals, or they have to call the contract themselves. In this project, the Klaytn format of signing hashes was applied.
The DAO in Wyvern v2.2 is based on a vote by an ERC20 share token. To make voting for small shareholders easier, the system allows the delegation of votes to a larger shareholder. Each proposal consists of the target address and contract calldata, along with the amount of ETH that will be sent alongside with it. The vote will pass if the minimum quorum is reached and more than half of the voters agree with it. It is also possible to change the voting rules via governance.
The DAO part of the contract was not used, and is out of the scope for audit.
Purpose of this report
This report was prepared to audit the security of the NFT Marketplace contracts developed by the MarbleX team. HAECHI AUDIT conducted the audit focusing on whether the system created by the MarbleX team is soundly implemented and designed as specified in the published materials, in addition to the safety and security of the NFT Marketplace contracts. As the contract is based on Wyvern 2.2 which was widely used, we have focused on the following.
•
different codes between the contracts and Wyvern 2.2
•
correct fixes of 1-day vulnerabilities of Wyvern 2.2
[Audit Report] MarbleX - NFT Marketplace
.png&blockId=1022f7e5-bf0b-417e-bac0-e19dd38eab63)
Report realeased on Sep 23, 2022
About Meter.io System
Meter Bridge is a bridge which is used to transfer various assets across different blockchains. It can transfer native tokens, and tokens in various token standards like ERC20, ERC721, ERC1155. The GenericHandler, which allows any function calls that the admin has allowed, makes it possible to do much more generic operations over blockchains, as its name suggests.
The system works as follows. If a user wants to transfer some tokens from chainA to chainB, it first deposits the token into the bridge contract of chainA. The contract will then lock the tokens in chainA, then emit an event which implies a deposit was created. The relayers, off-chain operators of the system, will listen to these events and either sign their approval of the messages or directly call the bridge contract of chainB to notify them that they agree with the proposal.
To execute each deposit proposal, a threshold number of signatures or approvals must be sent to the blockchain. This threshold, along with the relayer configuration, is controlled by the admin.
To gather the signatures more efficiently, a Signature contract is deployed on the relay chain. Most relayers will submit their signatures on the relay chain, and the final relayer will collect all the signatures and send them to the chains where the bridge process actually takes place.
The ERCHandlers and GenericHandler will handle the deposit requests and proposal execution requests. The bridge contract will receive these requests by users and relayers, and send them to the appropriate handler contracts. It should be noted that ERC20Handler also deals native tokens.
There is also a fee handler, which deals with the fee logic, fee collection, and fee transfers. A fee oracle could be utilized to get the required information to calculate the fees as well.
To support contract upgrades, the Transparent Proxy Pattern is used. Our audit assumed that the system admin uses the Transparent Proxy Pattern with best practices in a safe manner.
Our audit covers the smart contracts that are used in the Meter Bridge system. Our audit does not cover the relayer network, and does not cover the fee oracle system if there is one.
Purpose of this report
This report was prepared to audit the security of the Meter bridge and related contracts developed by the Meter team. HAECHI AUDIT conducted the audit focusing on whether the system created by the Meter team is soundly implemented and designed as specified in the published materials, in addition to the safety and security of the bridge.
[Audit Report] Meter.io
.png&blockId=f5c40155-2b74-4578-8ecf-6630c0a9208f)
Team
We are a group of security researchers, cryptographers and whitehat hackers with global top-tier experiences in both web2 and web3.
