Day15 – “Why?” & “What in?” Security & Blockchain?

Day15 - "Why?" & "What in?" Security & Blockchain?
Reading Time: 2 minutes

author: aman

Blog IV - Part II - Day 15

Let us get some dirty hands on with some more Solidity code and exploit a few more Ethereum - Solidity bugs.

Here we'll discuss about the famous DAO attack, caused by the reentrancy bug.

Let us do it...

In this micro-blog

  • delegatecall (the proxy calls) (SWC-112) (Inclusion of Functionality from Untrusted Control Sphere)
  • DoS With Block Gas Limit (SWC - 128)
  • Integer Overflow (SWC - 101)
  • Reentrancy Bug(DAO attack) (Improper Enforcement of Behavioral Workflow) (SWC-107)
  • uncheckedSend() (SWC - 113)
  • tx.origin bug
  • Variable Shadowing (SWC-119)
3. Reentrancy Bug(DAO attack) (Improper Enforcement of Behavioral Workflow) (SWC-107)

You can find the related files in this gist.

There are two files. One is simpleDAO.sol which is a simple DAO(Decentralised Autonomous Organisation) contract, which is generally available publicily. Other one is reentrancy.sol which is particularly written by the attacker to exploit this bug.

It is termed as Improper Enforcement of Behavioral Workflow, as the attacker is able to make improper use of the conctract function, and play with the workflow of the contract.

Now, look at the 2 very crucial parts of both the contracts, one from each.

-> Attacking contract

function() public payable{
    DAO.withdraw(DAO.retbalance());
}

The variable DAO is the instantiation of the already deployed contract.

-> DAO Contract

function withdraw(uint amount) public{
    if (credit[msg.sender]>= amount) {
        (msg.sender.call.value(amount)());
        credit[msg.sender]-=amount;
    }
}

Now, just go with the flow.

You being the owner of the "attacking contract", will trigger some function to withdraw your money from the DAO Contract, the flow goes as follows:

call is sent to function withdraw() [DAO]

|

the function checks whether you have that amount, which comes to be true

|

amount is transferred to your contract using sender function

|

to accept the payment, "payable" function of your contract automatically gets called

|

The flow moves again to the "withdraw()" Notice!!! the amount is deducted after sending the amount your contract

"Notice the credit[msg.sender]-=amount; line."

|

The flow repeats.

VULNERABILITY SPOTTED<<<<<

This thing, drained off all the money from the DAO contract to the attacker contract.

"One of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways."

*Can you Imagine what the Solution was?

Well, I'll tell that in the next blog. laughing

You are surely gonna kill me for this.

Be honest!!! dont search it up

*will be dropping an "answer" box in the cev insta page @cevsvnit

Thank you.


Adding gist frames here

Reentrancy Bug(DAO attack) (Improper Enforcement of Behavioral Workflow) (SWC-107)

0 0 votes
Article Rating

Leave a Reply

0 Comments
Inline Feedbacks
View all comments
CEV - Handout
0
Would love your thoughts, please comment.x
()
x
%d bloggers like this: