A Technical Analysis of the Genesis Alpha Hack

Community Bug Bounties Work

In this short article, we explain the recent vulnerability that resulted in approximately ~$15k being drained from the Genesis Alpha DAO on the sixth of February.

Genesis Alpha is an ongoing internal experiment by DAOstack in collaboration with its Pollinators community. Genesis Alpha is the first part of a three step plan to launch the official Genesis DAO. Each step in the plan is intended to test different layers of the DAO stack, including the Alchemy dApp and the Arc Platform, as well as to test DAOstack’s Holographic Consensus framework and its effects on emergent group social dynamics.

Genesis Alpha was scheduled to wind down in a few weeks and transition to step two, the Genesis Beta, concurrent with the launch of Alchemy Earth. Internally the team will discuss the future of the Alpha, the current Genesis roadmap, and consider the different options to move forward. We invite the DAOstack community to join the spirited discussion around how the Genesis Beta should be structured, and to share their thoughts as well in regards to the hack.

The Hack

Although the Arc Platform and Alchemy dApp have been live on the Ethereum mainnet for several months now, we expect that the code only just began receiving attention due to the recently posted $150k bug bounty to hack a test version of the dxDAO. While the dxDAO itself is not vulnerable to the Genesis Alpha exploit, we hypothesize the attacker spotted that the Genesis Alpha was.

While we do not fully present the Arc Platform in this analysis, please use this blog post for reference.

The Arc Platform itself is quite complex, as it is designed to allow for the creation of a modular and flexible governance component library for DAOs. Arc uses a Contract-as-a-Service (CaaS) architecture. In a CaaS architecture, a single contract can serve different DAOs. The concern with this approach, however, is that a DAO will be able to potentially get access to the assets of a different DAO. This is the type of vulnerability that was utilized by the attacker.

The hack itself was executed in a single atomic transaction on the Ethereum blockchain. After being deployed by the attacker, the contract initiated the attack from the constructor, drained Genesis Alpha’s funds, and promptly self destructed.

All of the attack events were executed in a single atomic transaction.

Following the events in the attacking transaction, we can see the attacker account that first deployed the attacking contract. When following the logs, we then see:

• The attacking contract made a proposal in Genesis Alpha to reward itself all the Ether and GEN held by the avatar.
• The attacker opened a new DAO with a malicious avatar in the Universal Controller contract. When a new DAO is opened, the Universal Controller first saves its Reputation address. Then, in order for it not to take over a different DAO’s Reputation, the Universal Controller checks that this Reputation contract is not yet listed. However, there was a vulnerability in the implementation of this check. Instead of reading:

1. Call the avatar to get its Reputation contract
2. Save the Reputation address to memory
3. Check if it is listed
4. Save it if it is not listed

The code actually read:

1. Call the malicious avatar to get its Reputation contract
2. Check if the returned Reputation contract address is listed already
3. If it is not listed call the malicious avatar again to get its Reputation contract
4. Save the Reputation address

This allowed the attacking contract to change its returned value between the two calls. For the second call, it returned the address of Genesis Alpha Reputation contract.

• Now that the attacker had a DAO that controlled the Genesis Alpha Reputation system, they directed their DAO to mint a big chunk of Reputation for themselves. Interestingly, some of the Reputation minted was then immediately burned, for reasons we have not yet determined. Following this, the attacker possessed 66% of the total Reputation, and voted yes on a proposal to pass the funds to themselves. Since the attacker now held an absolute majority of voting power — over 51% of the DAO’s Reputation — the proposal passed immediately and was approved and executed.

Looking forward

As DAOstack has stated many times in the past, our approach to security is testing by fire. It is almost impossible to secure a codebase completely. The above code passed two thorough audits by ChainSecurity, which is a top class audit company that discovered the recent bug in the Constantinople hard fork. The ChainSecurity team has further investigated this new type of vulnerability and added a new security pattern to its Securify scanner to help other teams check whether their contracts are safe. You can find further details on the vulnerability and how to check your code at this article.

Nothing provides more security than a large community actively examining the code. We encourage skilled developers and researchers to continue to read our code and report or utilize bugs as they discover them. As part of this effort we have joined Gnosis to together deploy a bug bounty for the dxDAO bug bounty. We reemphasize that neither the current test dxDAO nor the dxDAO itself are vulnerable to this recent exploit.

Finally, if you are the hacker, Please reach out if you’d like to have a discussion or explore other bounty opportunities for additional rewards.

Learn More and Get Involved

• Join our Discord community.
• Follow DAOstack on Medium, Twitter, or any of the other channels you’ll find on our website.
• Developer? Check out the DAOstack Github, or jump into the stack with our friendly Hacker’s Kit.