4663

Carmo Salgueiro

Hi!

If you ever need Negative SEO Serrvices, we offer it here
https://www.n-seo.co

Unsubscribe:
https://mgdots.co/unsubscribe/

Carmo Salgueiro

Automating the automation is still a challenge, but in some cases it's possible under certain situations.

In 2017 I created logic-evolver, one of my experiments for creating logic automatically or better said evolving logic automatically.

In some way, the computer create its own program that satisfies a set of tests defined by a human.

https://github.com/sha0coder/logic-evolver

This implementation in rust, contains a fast cpu emulator than can execute one million instructions in less than two seconds. And a simple genetic algorithm to do the evolution.

Here we create the genetic algorithm, and configure a population of 1000 individuals, and the top 5 to crossover. We run the genetic algorithm with 500 cycles maximum.
Note that in this case the population are programs initially random until take the correct shape.

An evaluation function is provided in the run method as well, and looks like this:

The evaluation function receives a CPU object, to compute a test you need to set the initial parameters, run the program and set a scoring regarding the return value.

Related word

Carmo Salgueiro

The OWASP Foundation would like to thank the OWASP Las Vegas Chapter Volunteers for taking the time out of their busy schedule to give back and volunteer to work the booth at BlackHat 2019. It was great meeting our Las Vegas OWASP members and working with Jorge, Carmi, Dave, and Nancy.
Also, take a moment to thank Global Board Members Martin Knobloch, Owen Pendlebury, and Gary Robinson for also working the booth and speaking with individuals and groups to answer questions on projects and suggestions on the use of our tools to address their work problems.
OWASP can not exist without support from our members. Related links

Carmo Salgueiro

Beyond Hello World

This will be our last week of basics before we hop into actual vulnerabilities.

In the last chapter, we covered a lot of differences between solidity and a traditional language and the keywords it uses to differentiate functionality within functions and transactions. We also reviewed a simple transaction on Remix. Hopefully, creating your first transaction and reviewing it was a useful exercise.

In this chapter, we will cover some other key aspects of understanding before we hop into our vulnerability discovery and exploitation. These key aspects will round off your understanding and really benefit you when attacking smart contracts. This will enable us to look at advanced solidity concepts with an offensive security mindset and help us to determine how to use them to our advantage when hacking smart contracts in the rest of this series.

I am sure you have noticed from the simple hello world example that Solidity is very much like a traditional program from a structural and coding standpoint. It only has some keywords and financial transnational differences due to its use case.

We will now cover another smart contract example where we will learn a lot more about the other key aspects of coding in solidity that makes it different and interesting, yet still is very easy to understand. This will be a fuller featured contract that covers a large portion of typical functionality. We will break down each part of this smart contract in chunks and explain what the contract does which will provide enough context to jump into the exploitation chapters that follow and start to do some really cool attacks.

I would suggest that you type out this code into Remix and play around with it rather than copy paste or rely on reading this chapter alone.

Note: On the deposit function, just note you will need to add a value to the value field above the deploy options. You can also check the video walk through in the references for a functionality walk through if you get stuck.

Deploying this contract and playing with it, will give you an understanding of how it works in order to better understand what the code does. This is similar to a reconnaissance phase when testing an application where a walk through of the application functionality is the first thing you should do prior to running attacks and scans against your target. The deeper understanding of how an application works at a functional level is always a tremendous asset into subverting its business logic which is where the real vulnerabilities are found that do the most damage. If you do not understand what the application does, you will not find the best attack vectors against it.

Hands on Lab – Type out and review contract functionality:

Below is the full contract for your review. Type this out in remix, play with it a bit, and try out the following steps. Then come back for an explanation of each piece of the code.

Action Steps:

ü Type out the code below and try to understand what it does
ü Compile and deploy the code into remix
ü Deposit 1 Ether into your account using the value field and denomination drop down
ü Check your Balance
ü Withdraw your balance (note this is in a smaller denomination we will explain that)
ü Check your Balance again
ü Click the isOwner button from a few of your accounts, and click the owner button to show the owner
ü Then finally try the withdrawAll from a non-owner account followed by trying withdrawAll

from the owner account and note your balances.

1.  pragma solidity 0.6.6;

2.

3.  contract HelloWorld_Bank{

4.    address public owner;

5.    mapping (address => uint) private balances;

6.

7.    constructor () public payable {

8.      owner = msg.sender;

9.     }

10.

11.//Setting Up authorization

12. function isOwner () public view returns(bool) {

13.   return msg.sender == owner;

14.  }

15.

16. modifier onlyOwner() {

17.   require(isOwner());

18.   _;

19. }

20.

21. function deposit () public payable {

22.  require((balances[msg.sender] + msg.value) >= balances[msg.sender]);

23.  balances[msg.sender] += msg.value;

24. }

25.

26. function withdraw (uint withdrawAmount) public {

27.    require (withdrawAmount <= balances[msg.sender]);

28.

29.    balances[msg.sender] -= withdrawAmount;

30.    msg.sender.transfer(withdrawAmount);

31. }

32.

33.

34. function withdrawAll() public onlyOwner {

35.    msg.sender.transfer(address(this).balance);

36. }

37.

38. function getBalance () public view returns (uint){

39.    return balances[msg.sender];

40.}

41.}

Video Walk Through:

Code Level Walk Through of HelloWorld Bank

While walking through the application in the action steps, you should have gotten a feel for what the contract does. By typing out the code you should also have at least a high-level understanding of the code logic. We will now break the code into chunks and make sure that your understanding does not hold you back from learning as we move into exploitation in the next section.

1.  pragma solidity 0.6.6;

2.

3.  contract HelloWorld_Bank{

4.    address public owner;

5.    mapping (address => uint) private balances;

Our first chunk of code starts off similarly with our pragma line which states the compiler version used for execution of the smart contract as seen in the last chapter followed by the contract name. Next, we have two variables which are created on lines 4 and 5. Both of these variables have a great importance to the flow of the application.

The first variable created is "owner" on line 4. This will be the contracts administrator which is not explicitly defined here, but instead defined in the next chunk of code in the constructor. Defining an owner in the constructor is common convention used in solidity to have an administrative user to limit usage of specific functionality. Usually, authorization of functionality is handled in a security library, for example Openzeppelin, which we will cover extensively when fixing smart contract vulnerabilities. However, in this case, we will show a simple implementation of authorization.

The second variable created "balances" on line 5 is something called a mapping in solidity. Mappings are similar to a dictionary lookup. It is a key value pair where in this case the address is mapped to a uint value. The key is the address of the user, while the value is the users balance within the contract. So, if you were to perform a dictionary lookup of a user's address you would be provided back their bank balance. You will also note that this is a private variable meaning that you cannot retrieve this value directly outside of the contract by referencing it. However, private variables as we will in later chapters are not as private as we think on the blockchain.

1.    constructor () public payable {

2.           owner = msg.sender;

3.    }

4.

5.    function isOwner () public view returns(bool) {

6.           return msg.sender == owner;

7.    }

This next section of code is called the constructor. The constructor runs one time when the contract is deployed and will set things up for the contract. In this case we are creating a constructor which is payable meaning that when you deploy the contract you can send Ethereum and that Ethereum will be stored within the contract's balance. This is useful if the contract requires a balance for some of its actions right out of the gate.

In line 2 we see our previously created owner variable being set to msg.sender. This is a way for the contract to set an administrative user when the contract is created. Since the constructor runs only one time, it's a good place to set an initial user. Often you will see this paired with a change owner function that is protected by the owner's authorization level and allows the current owner to set a new administrative user. The msg.sender variable in solidity is simply the users address who called the function, or in this case the user who published the contract initially. This is tied to the user's public address they use for transactions.

Each time a user interacts with a contract, their address is known by the contract as the msg.sender value and this address is used to associate values with their account sort of like a session variable in a sense. You can use this value to map functionality to that user. In the context of this contract you will see the msg.sender value used to set the Owner, validate the Owner, map balances on accounts and transfer value back to the user.

On line 5 you will see a function created solely for the purpose of checking if the user interacting with a contract is the owner of the application. It checks this by returning true if the msg.sender value equals the current owners address. This is how the application enforces its authorization level on administrative users. For example, if you used require(isOwner) in the beginning of a function the function would refuse to run the rest of its code if the user calling the contract was not the owner:

1.     modifier onlyOwner() {

2.        require(isOwner());

3.        _;

4.     }

Above you will see an authorization modifier using isOwner implemented in line 2. This modifier is used to return a simple true or false based on the same require statement we referenced using isOwner. However, with a modifier we can check within the definition of a function instead of the body of the function as you will see further below with the withdrawAll function. For now, as an example of a modifiers usage check out the following doesSomethingCool function definition, note onlyOwner within the definition. This is how we would use a modifier for authorization checks.

1.  function doesSomeThingCool() public onlyOwner

If the modifier is referenced in the function definition as shown in doesSomethingCool, the function body will not run unless the user's msg.sender value equals that of the owner of the contract. After it checks for a true or false value on line 2 and the modifier code ends, the calling function will continue running as normal following the _; from line 3. This _; value simply means continue running calling code as normal within the function provided the require modifier returned true. This is a much cleaner way to handle authorization across multiple functions with code reuse and ability to change code in one location rather than hunting down every function that needs authorization of some sort.

These next two functions should be pretty self-explanatory by now, but in the spirit of learning Solidity in this chapter we will deep dive all of the code.

1.   function deposit () public payable {

2.     require((balances[msg.sender] + msg.value) >= balances[msg.sender]);

3.     balances[msg.sender] += msg.value;

4.   }

5.

6.   function withdraw (uint withdrawAmount) public {

7.     require (withdrawAmount <= balances[msg.sender]);

8.

9.     balances[msg.sender] -= withdrawAmount;

10.   msg.sender.transfer(withdrawAmount);

11.}

Above we have two functions, a deposit function for filling your account with Ether from an external account and a withdraw function for removing your Ether from the contract. You will notice on line 1 that the definition of deposit has the words public and payable. The reason being that in order to deposit value to an account the function must be marked as a payable function. This goes for addresses as well, when using addresses within value transfers those addresses must also be marked as payable. This was something that was added the Solidity as of version 5, prior to version 5 if you are auditing code you will not see this keyword required within all portions of value transfer events.

In line 2 you will see a require line, the require line is a conditional check that if it fails the transaction will halt and revert back to the state before it was called. In this instance, if the value is not a positive value, it will fail and the function will return an error. If the value is indeed a positive number, the next line will run and increase the account value of the user by the value that was sent.

The withdraw function at line 6 only receives a withdraw amount that is checked on line 7 to require that amount to be withdrawn is less than or equal to the account balance of that user. If this check fails and the user does not have a high enough balance for the withdraw, then transaction returns an error. If it succeeds, then on lines 9 and 10 we decrease the balance of the user internally followed by transferring the approved amount back to the users account address.

Checks Effects Interactions:

Also note that this code follows the proper Solidity secure coding pattern of Checks, Effects, Interactions (CHI). We will go through Solidity coding patterns throughout the book. These are coding patterns which hinder attack vectors by design. In the CHI pattern, we always want to first check that the data is valid for the transaction which we did with the require statement. Then we want to do the effect of the transaction which is to reduce the balance of the user internally to the system. Finally, we want to interact with the external address we are transferring the value to. This pattern will become clear within the Reentrancy attack chapter.

Effectively an attacker could re-enter the contract and perform more actions bypassing initial checks if the value being transferred is not updating the balance prior to interacting with an un-trusted external party. In order to prevent the attacker from continually removing value from the contract, we always make sure to update the balance before transferring the value out of the contract. If the transaction happens to fail, the transfer function will revert the actions taken in the contract effectively refilling the users account.

At this point you are probably starting to notice that Solidity is pretty easy to understand. However, there are a lot of Gotchas if secure coding patterns are not used or dangerous low level functionality is handled incorrectly.

The final snippet of code should be easy to understand. At this point we have covered all of these concepts.

1.     function withdrawAll() public onlyOwner {

2.           msg.sender.transfer(address(this).balance);

3.     }

4.

5.      function getBalance () public view returns (uint){

6.           return balances[msg.sender];

7.      }

8.

The first thing to note is on line 1 which has the onlyOwner modifier created in the beginning of the contract. If you remember from the explanation earlier, when this modifier is added to the function definition, it will run the code within isOwner which checks if the user is the original contract owner created in the constructor when the contract was deployed. If this user is the owner, then the call within the body of the function executes and transfers all of the Ethereum value out of the contracts balance. It does this by simply using a transfer function with the address of the contract and this.balance.

That should all make sense if you have been following along but what doesn't make sense is a bit less obvious. Can you guess what that is?

Before reading the next paragraph, think about what's wrong with this function?

So, did you think about it? Did you ask yourself the question, "Why does this function even exist?" This is an immediate red flag within the code, that the contract being used in this banking application might have nefarious purposes by the creators of the contract. At no time should the owner of the contract have the ability to empty the contract of all its funds. Including that of all of the users funds who are holding their Ethereum within their personal accounts on the contract. Often you will see functions like this within less the reputable games which are planning an exit scam as soon as the contract balance reaches a desired threshold.

So, while its good to look for obvious vulnerabilities within code also think about the use case of the code being reviewed and if something looks off it probably is.

The final getBalance function on line 5 is simply a function that returns the balance of the user who calls the function. You will notice that within the function definition it uses the "view" keyword indicating that it is not modifying anything and should not incur fees for processing. It also indicates that it is returning a uint value which it does in line 6. The function returns the msg.sender's balance by querying the balances mapping with the msg.sender key.

Summary

This chapter should round out your knowledge of solidity enough to get started looking at vulnerabilities. We have covered a lot of common coding themes within solidity which may not be seen in other languages. We will be covering a lot of coding patterns along with vulnerable functionality within the following chapters on exploitation. We will walk through each vulnerability and why it's an issue within Solidity and then we will walk through how to attack it with examples of how an attacker would craft requests or additional attacking code to exploit the flaws. For additional information on the code above and a walk through of the functionality in real time, check out the chapters video in the references below.