Unlucky 2017: Two Parity Fiascos Explained

Daria Smirnova
5 min readSep 17, 2018
$$Photo by David Wirzba on Unsplash

A partial translation of my article originally published at: https://decenter.org/ru/chernyi-iyul-parity-podrobnosti-ataki-i-instrukciya-po-vzlomu-koshelka

During the hack of Parity on 19 July 2017 the attackers managed to steal 153,037 Ether (worth more than $30 million at that time). It was called “the second largest hack, in terms of ETH stolen, in the history of the Ethereum network.” The hack became possible due to a vulnerability in the Parity multisig wallet, so it’s also known as a “multisig hack.”

Santiago Palladino, a developer and security researcher at Zeppelin Solutions, summarized the process of the attack: the hacker “sent two transactions to each of the affected contracts.” The first contained a call to initWallet function and gained him an exclusive ownership of the multisig wallet. The second allowed him to move all the funds from this wallet to his own address.

Parity multisig wallets are so designed that they forward calls to the contract of the library.

“It’s the library where all functionality is implemented,” Eduard Karionov, an expert on token economics, blockchain and logistics smart-contracts, explained. It allows not to write new code for each wallet: “Each particular Parity wallet was like a casing that delegated all the calls to the main contract of the library through delegate call in its fallback function.”

The main characteristic of delegatecall is that it works with the data of the wallet itself, meaning it applies the functionality of the library (its code) to a specific wallet, its balance and ownership data. Thus, all callable functions must be public. And the initWallet method responsible for wallet initialization was public as well. “It’s assumed that the [initWallet] method will be only called once — as the wallet contract is created. I.e. I want to create a new wallet, I send an ethereum transaction saying ‘create a new wallet, that refers to this library,’ and at the time of [its] creation the function initWallet triggers in the library, and it appoints me as the owner of this wallet,” Karionov details.

There were no mechanisms, however, to check that this process was carried out just once. It means, any user could execute initialization (initWallet) again and become the owner of the wallet. That’s exactly what the hacker did.

Parity admitted that the attack became possible because of this bug in the code. “The bug was in a pair of extremely sensitive functions designed to allow the set-up of “multi-sig” wallets in the Parity Wallet software. The functions should have been protected in order that they be usable only in one specific circumstance, as the contract was being created. However, they were entirely unguarded, which allowed the attacker to reset the ownership and usage parameters of existing wallets arbitrarily,” Parity team explained.

After that the hacker only needed to call the execute function, that allowed to transfer funds to his account.

The next day the Parity team published a new version of the code, but it also contained a vulnerability that was activated on 6 November 2017. That day a developer under the nickname devops199 wrote he had “accidentally killed” the contract. devops199 was not the member of the Parity team and had an empty GitHub account. For some time he took part in the conversation broke out under his post. Answering the question on why he did that, devops199 said he is “eth newbie,” “just a beginner poking around the system.”

Not everyone believes it thought. Thetta Founder Anton Akentiev thinks it’s impossible to ‘unintentionally’ take all the steps devops199 did.

“…@devops199 “accidentally” called initWallet() method to own the library https://etherscan.io/tx/0x05f71e1b2cb4f03e547739db15d080fd30c989eda04d37ce6264c5686e0722c9

@devops199 “accidentally” called kill() method to selfdestruct it https://etherscan.io/tx/0x47f7cff7a5e671884629c93b368cb18f58a993f4b19c2a53a8662e3f1482f690," Akentiev wrote.

During the discussion on GitHub he suggested an analogy:

“1) you walk and see that bank’s door is open

2) then you go inside (method 1 call)

3) then you burn all the money (method 2 call)

would FBI believe you that it was “unintentional”?”

Cappasity project, which was conducting ICO as the attack happened, carried out an internal investigation. It pointed out that the devops199 actions were intentional (as for now, the Medium post on the results of the investigation is deleted).

The GitHub account of devops199 doesn’t exist anymore.

Akentiev also drew attention to the fact that the second attack became possible due to an incorrect initialization of the library contract that enabled anyone to become its owner and to destroy it.

In the official statement the Parity team said that the attack affected only those users who held funds in multisig wallets deployed after 20th July, i.e. wallets that run code modified after the first attack. “Unfortunately, that code contained another vulnerability which was undiscovered at the time — it was possible to turn the Parity Wallet library contract into a regular multi-sig wallet and become an owner of it by calling the initWallet function… a user deleted the library-turned-into-wallet, wiping out the library code which in turn rendered all multi-sig contracts unusable and funds frozen since their logic (any state-modifying function) was inside the library,” Parity wrote.

As a result, the owners of these wallets were unable to withdraw funds and 513,744 Ether became frozen.

In December 2017 CEO of Parity Jutta Steiner promised that access to funds would be opened after a planned upgrade in 4–6 months. It still hasn’t happened, however. The problem remains unsolved, while the discussions surrounding recovery strategies led to a split in the Ethereum community. In February Ethereum developer Yoichi Hirai resigned as a code editor, saying EIP 867, a proposal on returning lost funds, may violate the law. At the end of April another proposal caused heated controversy at the Ethereum developers’ meeting. Many participants believed that the implementation of EIP 999 will cause a hard fork because two main Ethereum clients — Parity and Geth — took different stances on this proposal. “We’re talking about exactly the same networks and we’re basically starting a tribalism war. I don’t think we’ll reach a consensus,” Péter Szilágyi, the lead developer of Geth, said.

Today much of the discussion is focused on the funds freeze occured in November, while — no matter was it intentional or not — Ether wasn’t stolen. It is still teasing the community lying at exactly the same addresses. But the origin of this ‘tribalism war’ was 19 July 2017, when the first attack took place. This attack led to a need for changing the code and it was the bug in this code that made the second accident possible. That’s why it would be no exaggeration to say that the July attack has formed the Ethereum community in its current state.

--

--