Blockchain Exploitation Labs - Part 3 Exploiting Integer Overflows And Underflows




In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.

Integer Attack Explanation:

An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.

If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.

In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.


Normally in your math class the following would be true:

99 + 1 = 100
00 - 1 = -1


In solidity with unsigned numbers the following is true:

99 + 1 = 00
00 - 1 = 99



So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.

That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.

Simple Example:

Lets say we have the following Require check as an example:
require(balance - withdraw_amount > 0) ;


Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?

This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?

Let's do some math.
5 - 6 = 99

Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.

Because the following math returns true:
 require(99 > 0) 

Withdraw Function Vulnerable to an UnderFlow:

The below example snippet of code illustrates a withdraw function with an underflow vulnerability:

function withdraw(uint _amount){

    require(balances[msg.sender] - _amount > 0);
    msg.sender.transfer(_amount);
    balances[msg.sender] -= _amount;

}


In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.

require(balances[msg.sender] - _amount > 0);


It will then send the value of the _amount variable to the recipient without any further checks:

msg.sender.transfer(_amount);

Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:

balances[msg.sender] -= _amount;


Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.

Transfer Function Vulnerable to a Batch Overflow:

Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?


You have 10,000 tokens in your account
You are sending 200 users 499 tokens each
Your total sent is 200*499 or 99,800

The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.


You have 10,000 tokens in your account
You are sending 200 users 500 tokens each
Your total sent is 200*500 or 100,000
New total is actually 0

This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.



Lets take our new numbers and plug them into the below code and see what happens:

1. uint total = _users.length * _tokens;
2. require(balances[msg.sender] >= total);
3. balances[msg.sender] = balances[msg.sender] -total;

4. for(uint i=0; i < users.length; i++){ 

5.       balances[_users[i]] = balances[_users[i]] + _value;



Same statements substituting the variables for our scenarios values:

1. uint total = _200 * 500;
2. require(10,000 >= 0);
3. balances[msg.sender] = 10,000 - 0;

4. for(uint i=0; i < 500; i++){ 

5.      balances[_recievers[i]] = balances[_recievers[i]] + 500;


Batch Overflow Code Explanation:

1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.

2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.

3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000.  The sender has lost no funds.

4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.

In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.

Lab Follow Along Time:

We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.

For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently.
https://remix.ethereum.org/

Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:


Download Video Lab Example Code:

Download Sample Code:

//Underflow Example Code: 
//Can you bypass the restriction? 
//--------------------------------------------
 pragma solidity ^0.5.12;

contract Underflow{
     mapping (address =>uint) balances;

     function contribute() public payable{
          balances[msg.sender] = msg.value;  
     }

     function getBalance() view public returns (uint){
          return balances[msg.sender];     
     }

     function transfer(address _reciever, uint _value) public payable{
         require(balances[msg.sender] - _value >= 5);
         balances[msg.sender] = balances[msg.sender] - _value;  

         balances[_reciever] = balances[_reciever] + _value;
     }
    
}

This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:


 

Conclusion: 

We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.

Related word


  1. Aprender Hacking Etico
  2. Brain Hacking
  3. Hacker Etico
  4. Hacking Python
  5. Blog Hacking
  6. Hacker Significado
  7. Como Empezar A Hackear
  8. White Hacking
  9. Aprender Hacking
  10. Que Es Un Hacker

No comments:

Post a Comment

Labels

14.6.2014 draw 297/14 19 Mei 2013 23 Jun 2013 24.04.2013 25 Jun 2013 4 mei 2014 - draw 278/14 6 mei 2014 Adakah anda bersetuju dengan pernyataan tentang zakar ini? BERIKUT MERUPAKAN NOMBOR RAMALAN UNTUK MAGNUM 4D PADA 30 OGOS 2014 draw 143/13 draw 279/14 DRAW ID 098/13. DRAW ID 099/13: NOMBOR RAMALAN UNTUK MAGNUM 4D PADA 4 MEI 2013 DRAW ID 139/13. DRAW ID 141/13. DRAW ID 142/13 DRAW ID 142/13 / PREDICTION FOR MAGNUM 4D COUNTER ON 3 AUGUST 2013 ID CABUTAN 098/13 / PREDICTION FOR MAGNUM 4D COUNTER ON 1 MAY 2013 ID CABUTAN 099/13 / ID CABUTAN 139/13 / PREDICTION FOR MAGNUM 4D COUNTER ON 27 JULY 2013 ID CABUTAN 141/13 / PREDICTION FOR MAGNUM 4D COUNTER ON 31 JULY 2013 Keputusan dan perbandingan antara nombor ramalan dan result Magnum 4D pada 31 Julai 2013 Keputusan Magnum 4D Kerja part time/ sambilan : Peluang tambah pendapatan Magnum 4d result 1 May 2013 Draw 098/13 Magnum draw 094/13 nombor 4d 6.7.2014 308/14 Nombor 4d untuk hari ini : 21/04/2013 nombor magnum 4d draw 107/13 ; Ahad nombor magnum 4d untuk draw 101/13: 7 mei 2013 ( magnum 4d prediction number for draw 101/13 : 7 may 2013 Nombor ramalan 4d : 24.04.2013 Nombor ramalan dan keputusan Magnum 4D draw 119/13 pada 15 Jun 2013 Nombor ramalan Magnum 4D 4 Ogos 2013 draw 143/13 Nombor ramalan Magnum 4D 7 Ogos 2013 draw 144/13 nombor ramalan Magnum 4D dan result pada 4 Ogos 2013 Nombor ramalan magnum 4d draw 112/13 29 Mei 2013 Nombor ramalan Magnum 4D pada 1 Jun 2013 draw 113/13 nombor ramalan magnum 4d pada 14.6.2014 draw 297/14 Nombor ramalan Magnum 4D pada 2 Jun 2013 Draw 114/13 nombor ramalan magnum 4d pada 23 ogos 2014 draw 329/14 Nombor ramalan magnum 4d pada 26.05.2015 draw 467/15 - special draw Nombor Ramalan Magnum 4D pada 30 April 2014 draw 276/14 nombor ramalan magnum 4d pada 30 ogos 2014 draw 333/14 nombor ramalan magnum 4d pada 4 mei 2014 - draw 278/14 Nombor ramalan magnum 4d pada 5 julai 2014 hari sabtu draw 307/14 nombor ramalan magnum 4d pada 7 september 2014 draw 338/14 ( 7.9.2014/338/14) nombor ramalan magnum 4d pada 8 Februari 2014 (8/2/2014) draw 235/14 nombor ramalan magnum 4d pada hari ahad nombor ramalan magnum 4d pada hari ahad 6 julai 2014 draw 308/14 nombor ramalan magnum 4d pada hari rabu 25 september 2013 draw 168/13 nombor ramalan magnum 4d pada hari rabu 9 julai 2014 draw 309/14 nombor ramalan magnum 4d pada hari sabtu nombor ramalan magnum 4d pada hari sabtu 13.9.2014 draw 340/14 nombor ramalan magnum 4d pada hari sabtu 26 oktober 2013 draw 182/13 nombor ramalan magnum 4d pada hari selasa Nombor ramalan Magnum 4D untuk draw 118/13 pada hari Rabu 12 Jun 2013 Nombor ramalan Magnum 4D untuk draw 119/13 pada hari Sabtu 16 Jun 2013 Nombor ramalan Magnum 4D untuk draw 120/13 pada hari Ahad 16 Jun 2013 Nombor ramalan Magnum 4D untuk draw 121/13 pada hari Rabu 19 Jun 2013. Nombor ramalan Magnum 4D untuk draw 123/13 pada hari Ahad Nombor ramalan Magnum 4D untuk draw 124/13 pada hari Selasa (special draw) Nombor ramalan Magnum 4D untuk draw 231/14 pada hari Sabtu 1 Februari 2014 Nombor ramalan Magnum 4D untuk hari Sabtu 7 Ogos 2013 draw 149/13 Nombor ramalan Magnum 4D untuk hari Selasa 3 September 2013 draw 158/13 | SPECIAL DRAW Nombor ramalan MAGNUM 4D untuk special draw 111/13 28 Mei 2013 Nombor ramalan untuk hari Rabu nombor ramalan untuk MAGNUM 4D Nombor ramalan untuk magnum 4d draw 105/13: 15 Mei 2013 Nombor ramalan untuk magnum 4d draw 120/13 dan keputusan/result magnum 4d pada 16 Jun 2013 NOMBOR RAMALAN UNTUK MAGNUM 4D PADA 1 MEI 2013 NOMBOR RAMALAN UNTUK MAGNUM 4D PADA 27 JULAI 2013 NOMBOR RAMALAN UNTUK MAGNUM 4D PADA 3 OGOS 2013 NOMBOR RAMALAN UNTUK MAGNUM 4D PADA 31 JULAI 2013 nombor ramalan untuk magnun 4d pada 3 mei 2014-277/14 nombor untuk magnum 4d draw 095/13 : 27 April 2013 PREDICTION FOR MAGNUM 4D ON 4 MAY 2013 ramalan magnum 4d 9.7.14 309/14 Ramalan pada 12 Jun 2013 dan keputusan Magnum 4D Result 21.4.2013 Cash Sweep Result 21.4.2013 DaMaCai Result 21.4.2013 Magnum Result 21.4.2013 Toto special draw 28 Mei 2013 special draw pada 28 MEI 2013. TERKINI| TERBARU: nombor magnum 4d 7 mei 2013; 101/13 ; special draw Toto draw 3871/13

**Penafian**

Nombor ramalan hanyalah sebagai panduan dan dicadangkan untuk MAGNUM SAHAJA (atau kaunter lain sekiranya sesuai) . Segala pertaruhan adalah atas risiko anda sendiri.