The DAO Exploits analysis

I'm sure everyone has heard that the headlines about DAO theft up to $150m are exploited by hackers using recursive ethereum to send exploits.

This article will be the first to cover what this series might be, providing a blockchain to track the attackers ' actions on the timeline, deconstructing and explaining what was wrong at the technical level. The first release will focus on how the attacker specifically stole all the money from the DAO. a multi-level attack

This exploit of DAO is obviously not trivial, and the specific programming pattern makes DAO's weaknesses not only known, but also repaired by the DAO's creator in the early schedule to update the framework's code. Ironically, as they write blogs and celebrate victories, hackers are preparing and exploiting a loophole that sucks up all of DAO's money with the same features they just fixed.

Let's take a look at this attack. The attackers analyzed the Dao.sol, and noted that the "Splitdao" feature was vulnerable to being attacked to recursively send the pattern we mentioned above: This feature will eventually update the user's balance and total, so if we can call this feature before it accesses the Splitdao, We can use infinite recursion to transfer whatever amount of money we want (the code comment flag is XXXX, you may need to slide to see):

The basic idea is as follows: Propose a split. Run split. When DAO wants to undo the response to you, call this function to execute split before the undo is complete. This feature will run without updating your balance, this command line we marked as "the attacker wants to run more than once" will run multiple times. What it will do. Source code in Tokencreation.sol, it shifts tokens from the parent DAO to the child DAO. Basically the attacker is using this to get more tokens than he should have been transferred to the child DAO.

How does DAO decide how much to transfer the tokens? Use a balanced array, of course:

Because P.splitdata[0] is the same every time an attacker invokes this feature (it is a property of the proposed P, not the general state of DAO), and the attacker can invoke this function from the undo response before the balanced array is updated. An attacker could then get this code and run countless attacks at random, so that each time the same amount of money was transferred out.

The first foreshadowing of an attacker's ability to successfully exploit this vulnerability is the need to have a DAO recall function that, when actually running, is vulnerable to a deterministic recursive send vulnerability. Let's look at what needs to be done in the code to make this happen (from Dao.sol):

If the hacker can get the first if declaration evaluated as wrong, this statement will be run by a flag-bit vulnerable to attack. When this declaration is run, the following code will be called:

Note that the command line that is flagged is specifically how to become vulnerable code, and we link the description of this exploit to be mentioned.

This command line will send the message to "_recipient" (the attacker) from the DAO Protocol. "_recipient" certainly contains the wrong functionality, and it will call Splitdao again to send the arguments that were generated when the attacker first called. Remember that because it all happened in the withdrawfor in Splitdao, the code update balance in Splitdao did not run. So split will send more tokens to the child DAO, then the request proceeds will be withdrawn again. It will attempt to send tokens again to "_recipient", and it will call the split DAO again before updating the balanced array.

will run as follows: Propose a split and wait for a direct voting period to expire. (Dao.sol, Createproposal) run split. (Dao.sol, Splitdao) let DAO send a share of tokens to new DAO (Splitdao-Tokencreation.sol, Createtokenproxy) Make sure that DAO tries to send you the proceeds after (3) before updating your balance. (Splitdao, Withdrawrewardfor, Managedaccount.sol, payout) when DAO is in step (4), run Splitdao again with the same parameters as (2). (Payout, _recipient.call.value, _recipient ()) DAO will send you more descendant coins and withdraw your earnings before updating your balance. (Dao.sol, Splitdao) returns (5). Let DAO update your balance. Because (7) returns to (5), so this will not happen.

(Side note: Ethereum Gas technology is not helpful here.) Call.value will default on the gas required to deliver the exchange, not like the Send function. So as long as the attacker pays the code will run, which is considered a low-level exploit means instability)

With these above, we can step-by-step anti-tracking DAO is how to step by step is hollowed out.

1th step: Propose split

The first step is simply to make a regular split, as we mentioned earlier.

In this step, the attacker presents #59 in DAO in the blockchain, named "Lonely, so Lonely".

Because this one command line:
He had to wait for a week to get the proposal approved. But it doesn't matter, it's just a simple split proposal like the rest. No one is overly concerned about it, right.

2nd step: Get the proceeds

This is fully explained in the slock.it's previous posts on the matter, and there is still no revenue distribution in the DAO. (because there is no revenue generated).

As we mentioned in the overview, this key command line needs to be run here:

If the hacker can get the first command line to be flagged, then the second flag will run the default function he chooses (this is called return Splitdao as we described earlier).
Let's deconstruct the first if declaration:

The function of the balance is defined in Token.sol, which is, of course, specific:

The rewardaccount.accumulatedinput () command line is evaluated from the code in Managedaccount.sol:

Fortunately, the operation of Accumulatedinput is very simple. You only need to use the default features of the revenue account.

Not only that, because there is no logic to reduce accumulatedinput to anywhere (it follows the input trajectory of the account in all trades), the attacker is to send some Wei to the revenue account, and our initial conditions will not only be evaluated as errors, And its component values are evaluated to be the same each time they are called:

Remember that since balanceof refers to the balance, it has never been updated since the code in Splitdao never really executed, paidout and totalsupply are not followed by the new, and the attackers claim that their small share of the proceeds is no problem. Because they can claim the proceeds of this share, they can run the default function and return to Splitdao again.

But do they really need to include a benefit? Let's take a look at this command line again:

What happens if the balance of the income account is 0. Then we can get:

If not paid, this will always be evaluated as error and never stops. Why is it. Since the initial command line is equivalent, after subtracting paidout from both sides, the result is:

How much of the first part was paid. So the check is actually like this:

But if Amounttobepaid is 0,dao will pay you anyway. It doesn't make much sense to me – why waste gas in this way. I think that's why many people think that attackers need a balance of income accounts to attack, something that they don't actually need. Both an empty income account and a full account attack are all running the same way.

Let's take a look at the revenue address of DAO. From Slockit pegs in DAO's account file, this address is 0xd2e16a20dd7b1ae54fb0312209784478d069c7b0. Check the trading of this account and you will see this mode: 200 pages of. 00000002 Ethereum Trading to 0XF835A0247B0063C04EF22006EBE57C5F11977CC4 And 0xc0ee9db1a9e07ca63e4ff0d5fb6f86bf68d47b89, the attacker's two malicious protocol (which we'll talk about later). Each recursive call to Withdrawrewardfor in this transaction is mentioned above. So in this attack there is indeed a balance in the income account that the attacker did not apply to it.

the 3rd step: a huge shortage

On social media, there have been unsubstantiated allegations that there was a $3 million shortfall in Bitfinex before the attack, claiming that the shortfall was close to $1 million in profits.

No matter who builds and analyzes this attack, it is clear that some of the performance of DAO (especially if any split must run the same code as the original DAO) requires that the currency in which the attacker withdraws the malicious split must wait through the creation period of the child Dao (27 days). This gives the community time to respond to the theft by freezing the attacker's account with a soft fork or withdrawing the entire protocol through a fork.

Any economically motivated attacker trying to exploit a vulnerability on a test network would want to ensure that profit, whether a potential rollback or a cross-selling underlying token, triggered by a malicious split, led to a sharp plunge in prices in a matter of minutes, providing a great opportunity for profit, But there is no evidence that the attackers took advantage of this opportunity, and we can at least conclude that they are foolish in this regard.

Step 3a: Prevent exit (resistance is invalid)

Another possibility an attacker would have to consider is that a DAO split appeared before the attacker emptied the DAO. In this case, because there is another user as a separate manager, the attacker will not have access to DAO's funds.

Unfortunately, the attacker was smart: there was evidence that all of the attackers ' split proposals came from his own terms, making sure he had some license for any DAO split. We'll talk later in this article about the nature of DAO, and the DAO split we're talking about here is vulnerable to the same attack. All the attackers have to do is to send some ethereum to the income account after the creation period, themselves to propose and execute a split away from the new DAO. If he can execute before the new DAO manager updates the Code to eliminate vulnerability, he will be able to successfully bring the etheric currency that does not belong to him from the DAO.

By the time axis here it can be noted that the attacker started all this at the beginning of a malicious split, almost at the same time. I think of all this as more of an unnecessary insult to DAO than an economically viable offense: in fact, the entire DAO has been emptied, and the effort to pick up the possible remaining coins on the table may be to try to dismantle the holders ' inaction. Many people come to the conclusion, and I agree that the motive of this attack is to completely destroy DAO rather than gain profit. Although no one knows the truth, I suggest you judge by yourselves.

Interestingly, the attack took place after the blockchain was described by Emin Gün Sirer, but the public did not notice it before.

4th step: Run Split

After we painstakingly described all the boring technical aspects of this attack, let's step into an interesting part of action: Execute a malicious split. The account for trading after split is: 0xf35e2cc8e6523d683ed44870f5b7cc785051a77d.

They put money into the child DAO is 0x304a554a310c7e546dfe434669c62820b7d83490. Create and initiate a proposed account

Is 0xb656b2a9c3b2416437a811e07466ca712f5a5b5a (you can see the proposed call to create in the history of the blockchain).

The parameters of the deconstructed construct created the child DAO to lead us to the manager 0xda4a4626d3e16e094de3225a751aab7128e96526. This smart protocol is just an ordinary multi-signature wallet, and most of the past transactions are just add/remove owners and other money management tasks. And there's nothing interesting about that.

Johannes Pfeffer has a great deal in the media. The perfect blockchain-based reconstruction involves the child DAO. Since he has done such a good job, I don't spend too much time analyzing the blockchain. I strongly recommend that the person interested in this article begin.

In the next article in this series, we will focus on the code of the malicious protocol itself (including the actual release of the exploit in a recursive attack). To facilitate the release, we have not completed the complete analysis.

Step 4a: Expand Split

This step is followed by the new initial update, and masks how an attacker can convert a a-30x amplification attack (because the size of the Ethereum stack is limited to 128) into an almost unlimited dry account.

Savvy readers on top may notice that even after overwhelming stacks and executing more malicious split than needed, by code after Splitdao ends the hacker's balance with them is still 0 output:

So how do attackers get around this limit. There is no need for an attacker to do this because the DAO tokens have the ability to transfer money. All he needs to do is call the Help conversion feature of DAO at the top of the stack, from this malicious feature of his:

To transfer tokens to an agent account, the original account will be 0 output at the end of the Splitdao (note that if a transfers all money to B,a's account, it will have been transferred to 0 output by transfer before the Splitdao 0 output is available). The attacker could then return funds from the proxy account to the original account and start the process again. Even if the totalsupply in Splitdao is lost, given that p.totalsupply[0] is used to calculate payments, it is a property of the original proposal and can only be present until an attack occurs. So although the etheric currency in DAO is reduced in each iteration. The intensity of the attack can remain the same.

The two malicious protocol calls to withdrawrewardfor on the blockchain indicate that the attacker's proxy account is also a contract that can be used for an attack, and simply alternates with the attacker's original account. This optimization saves one trade in each offensive cycle, but it does not seem necessary.

1.1 is vulnerable to attack.