mnCollaborativelaw: August 2020

Jan Hoistad Ph.D., LP

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.

Contact Info:

@ficti0n

http://cclabs.io

http://consolecowboys.com

References:

https://www.youtube.com/watch?v=U9IWSHcfR08

Open Zeppelin

https://github.com/OpenZeppelin/openzeppelin-contracts

Checks Effects Interactions

https://solidity.readthedocs.io/en/v0.6.0/security-considerations.html?highlight=checks%20effects#use-the-checks-effects-interactions-pattern

Related word

Jan Hoistad Ph.D., LP

In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them.

In the last past years we saw many scientific publications about cryptocurrencies. Some focused on theoretical parts [Source] and some on practical attacks against specific well-known cryptocurrencies, like Bitcoin [Source]. But in general there is a lack of practical research against alternative coins. Or did you know that there are currently over 830 currencies listed online? So we asked ourselves how secure are these currencies, and if they are not just re-branded forks of the Bitcoin source code?

Background

Gridcoin is an Altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is not as widespread as Bitcoin, its draft is very appealing as it attempts to eliminate Bitcoin's core problems. It possesses a market capitalization of $13,719,142 (2017/08/10).

Berkeley Open Infrastructure for Network Computing

To solve general scientific meaningful problems, Gridcoin draws on the well-known Berkeley Open Infrastructure for Network Computing (BOINC). It is a software platform for volunteer computing, initially released in 2002 and developed by the University of California, Berkeley. It is an open source software licensed under the GNU Lesser General Public License. The platform enables professionals in need for computation power to distribute their tasks to volunteers. Nowadays it is widely used by researchers with limited resources to solve scientific problems, for example, healing cancer, investigate global warming, finding extraterrestrial intelligence in radio signals and finding larger prime numbers.
When launching a BOINC project, its maintainer is required to set up his own BOINC server. Project volunteers may then create accounts (by submitting a username, a password and an email address) and work on specific project tasks, called workunits. The volunteers can process the project tasks and transfer their solutions with a BOINC client.

BOINC architecture

BOINC uses a client-server architecture to achieve its rich feature set. The server component handles the client requests for workunits and the problem solutions uploaded by the clients. The solutions are validated and assimilated by the server component. All workunits are created by the server component and each workunit represents a chunk of a scientific problem which is encapsulated into an application. This application consists of one or multiple in-/output files, containing binary or ASCII encoded parameters.

BOINC terminology

iCPID

The BOINC project server creates the internal Cross Project Identifier (iCPID) as a 16 byte long random value during account creation. This value is stored by the client and server. From this time on, the iCPID is included in every request and response between client and server

eCPID

The external Cross Project Identifier (eCPID) serves the purpose of identifying a volunteer across different BOINC projects without revealing the corresponding email address. It is computed by applying the cryptographic hash function MD5 to (iCPID,email) and thus has a length of 16 byte [Source].

eCPID = MD5(iCPID||email)

Credits

BOINC credits are generated whenever a host submits a solution to an assigned task. They are measured in Cobblestone, whereas one Cobblestone is equivalent to 1/200 of CPU time on a reference machine with 1,000 mega floating point operation per seconds [Source]

Total Credit

Total number of Cubblestones a user invested with his machines for scientific computations

Recent Average Credit (RAC)

RAC is defined as the average number of Cobblestones per day generated recently [Source]. If an entire week passes, the value is divided by two. Thus old credits are weakly weighted. It is recalculated whenever a host generates credit [Source].

Gridcoin

As a fork of Litecoin, Gridcoin-Research is a blockchain based cryptocurrency and shares many concepts with Bitcoin. While Bitcoin's transaction data structure and concept is used in an unmodified version, Gridcoin-Research utilizes a slightly modified block structure. A Gridcoin-Research block encapsulates a header and body. The header contains needed meta information and the body encloses transactions. Due to the hashPrevBlockHeader field, which contains the hash of the previous block-header, the blocks are linked and form the distributed ledger, the blockchain. Blocks in the blockchain are created by so called minters. Each block stores a list of recent transactions in its body and further metadata in its header. To ensure that all transactions are confirmed in a decisive order, each block-header field contains a reference to the previous one. To regulate the rate in which new blocks are appended to the blockchain and to reward BOINC contribution, Gridcoin-Research implements another concept called Proof-of-Research. Proof-of-Research is a combination of a new overhauled Proof-of-BOINC concept, which was originally designed for Gridcoin-Classic and the improved Proof-of-Stake concept, inspired by alternative cryptocurrencies.

Fig. 1: Gridcoin block structure

Gridcoin terminology

In order to understand the attacks we need to introduce some Gridcoin specific terms.

eCPID

Identifier value from BOINC used in Gridcoin to identify the researcher.

CPIDv2

contains a checksum to prove that the minter is the owner of the used eCPID. We fully describe the content of this field in the last attack section.

GRCAddress

contains the payment address of the minter.

ResearchAge

is defined as the time span between the creation time of the last Proof-of-Research generated block with the user's eCPID and the time stamp of the last block in the chain measured in days.

RSAWeight

estimates the user's Gridcoin gain for the next two weeks, based on the BOINC contribution of the past two weeks.

Proof-of-Stake

Proof-of-Stake is a Proof-of-Work replacement, which was first utilized by the cryptocurrency Peercoin in 2012. This alternative concept was developed to showcase a working Bitcoin related currency with low power consumption. Therefore, the block generation process has been overhauled. To create a new valid block for the Gridcoin blockchain the following inequality have to be satisfied:

SHA256(SHA256(kernel)) < Target * UTXO Value + RSAWeight

The kernel value represents the concatenation of the parameters listed in Table 2. The referenced unspent transaction output (UTXO) must be at least 16 hours old. The so called RSAWeight is an input value to the kernel computation, it's indicates the average BOINC work, done by a Gridcoin minter.
In direct comparison to Bitcoin's Proof-of-Work concept, it is notable that the hash of the previous block-header is not part of the kernel. Consequently, it is theoretically possible to create a block at any previous point in time in the past. To prevent this, Gridcoin-Research creates fixed interval checkpoint blocks. Once a checkpoint block is synchronized with the network, blocks with older time stamps became invalid. Considering the nature of the used kernel fields, a client with only one UTXO is able to perform a hash calculation each time nTime is updated. This occurs every second, as nTime is a UNIX time stamp. To be able to change the txPrev fields and thereby increase his hash rate, he needs to gain more UTXO by purchasing coins. Note that high UTXO and RSAWeight values mitigate the difficulty of the cryptographic puzzle, which increase the chance of finding a valid kernel. RSAWeight was explained above. Once a sufficient kernel has been found, the referenced UTXO is spent in a transaction to the creator of the block and included in the generated block. This consumes the old UTXO and generates a new one with the age of zero.

The Gridcoin-Research concept does not require much electrical power, because the maximum hash rate of an entity is limited by its owned amount of UTXOs with suitable age.

Proof-of-Research

Minters relying solely on the Proof-of-Stake rewards are called Investors. In addition to Proof-of-Stake, Gridcoin gives minters a possibility to increase their income with Proof-of-Research rewards. The Proof-of-Research concept implemented in Gridcoin-Research allows the minters to highly increase their block reward by utilizing their BOINC Credits. In this case the minter is called a Researcher.
To reward BOINC contribution, relevant BOINC data needs to be stored in each minted block. Therefore, the software uses the BOINCHash data structure, which is encapsulated in the first transaction of each block. The structure encloses the fields listed in Table 6. The minting and verification process is shown in Figure 2 and works as follows:

A minter (Researcher) participates in a BOINC project A and performs computational work for it. In return the project server increases the users Total Credit value on the server. The server therefore stores the minter's email address, iCPID, eCPID and RAC.
Statistical websites contact project server and down-load the statistics for all users from the project server (A).
After the user earns credits, his RAC increases. Consequently, this eases the finding of a solution for the Proof-of-Stake cryptographic puzzle, and the user can create (mint) a block and broadcast it to the Gridcoin network.
Another minter (Investor or Researcher) will receive the block and validate it. Therefore, he extracts the values from the BOINCHash data structure inside the block.
The minter uses the eCPID from the BOINCHash to request the RAC and other needed values from a statistical website and compares them to the data extracted from the BOINCHash structure, in the event that they are equal and the block solves the cryptographic puzzle, the block is accepted.

Fig. 2: Gridcoin architecture and minting process

Reward calculation

The total reward for a solved block is called the Subsidy and is computed as the sum of the Proof-of-Research and the Proof-of-Stake reward.

If a minter operates as an Investor (without BOINC contribution), the eCPID is set to the string Investor and all other fields of the BOINCHash are zeroed. An Investor receives only a relatively small Proof-of-Stake reward.
Because the Proof-of-Research reward is much higher than its Proof-of-Stake counterpart, contributing to BOINC projects is more worth the effort.

Statistic Website

At the beginning of the blog post, the core concept behind BOINC was described. One functionality is the creation of BOINC Credits for users, who perform computational work for the project server. This increases the competition between BOINC users and therefore has a positive effect on the amount of computational work users commit. Different websites 4 collect credit information of BOINC users from known project servers and present them online. The Gridcoin client compares the RAC and total credit values stored in a new minted block with the values stored on cpid.gridcoin.us:5000/get_user.php?cpid=eCPID where eCPID is the actual value of the researcher. If there are differences, the client declines the block. In short, statistical websites are used as control instance for Gridcoin. It is obvious that gridcoin.us administrators are able to modify values of any user. Thus, they are able to manipulate the amount of Gridcoins a minter gets for his computational work. This is crucial for the trust level and undermines the general decentralized structure of a cryptocurrency.

Project Servers

Gridcoin utilizes BOINC projects to outsource meaningful computation tasks from the currency. For many known meaningful problems there exist project servers 5 that validate solutions submitted by users, 6 and decide how many credits the users receive for their solutions. Therefore, the project servers can indirectly control the amount of Gridcoins a minter gets for his minted block via the total credit value. As a result, a Gridcoin user also needs to trust the project administrators. This is very critical since there is no transparency in the credit system of project server. If you want to know why decentralization is not yet an option, see our paper from WOOT'17.

Attacks

In addition to the trust a Gridcoin user needs to put into the project server and statistic website administrators, Gridcoin suffers from serious flaws which allows the revelation of minter identities or even stealing coins. Our attacks do not rely on the Gridcoin trust issues and the attacker does not need to be in possession of specific server administrative rights. We assume the following two simple attackers with limited capability sets. The first one, is the blockchain grabber which can download the Gridcoin blockchain from an Internet resource and runs a program on the downloaded data. The second one, the Gridcoin attacker, acts as a normal Gridcoin user, but uses a modified Gridcoin client version, in order to run our attacks.

Interestingly, the developer of Gridcoin tried to make the source code analysis somewhat harder, by obfuscating the source code of relevant functions.

Fig. 3: Obfuscated source code in Gridcoin [Source]

Grab Gridcoin user email addresses

In order to protect the email addresses of Gridcoin Researchers, neither BOINC project websites nor statistical websites directly include these privacy critical data. The statistical websites only include eCPID entries, which are used to reward Gridcoin Researchers. However, the email addresses are hidden inside the computation of the BOINCHash (cf. Table 1). A BOINCHash is created every time a Researcher mints a new block and includes a CPIDv2 value. The CPIDv2 value contains an obfuscated email address with iCPID and a hash over the previous blockchain block.

By collecting the blockchain data and reversing the obfuscation function (cf. Figure 4 and Figure 7), the attacker gets all email addresses and iCPIDs ever used by Gridcoin Researchers. See the reversed obfuscation function in Figure 4 and Figure 5.

Evaluation

We implemented a deobfuscation function (cf. Figure 7) and executed it on the blockchain. This way, we were able to retrieve all (2709) BOINC email addresses and iCPIDs used by Gridcoin Researchers. This is a serious privacy issue and we address it with our fix (cf. The Fix).

Steal Gridcoin users BOINC reward

The previous attack through deobfuscation allows us to retrieve iCPID values and email addresses. Thus, we have all values needed to create a new legitimate eCPID. This is required because the CPIDv2 contains the last block hash and requires a re-computation for every new block it should be used in. We use this fact in the following attack and show how to steal the computational work from another legitimate Gridcoin Researcher by mining a new Gridcoin block with forged BOINC information. Throughout this last part of the post, we assume the Gridcoin Minter attacker model where the attacker has a valid Gridcoin account and can create new blocks. However, the attacker does not perform any BOINC work.

Tab. 1: BOINCHash structure as stored and used in the Gridcoin blockchain.

As stated at the beginning of the blog post, the pre-image of the eCPID is stored obfuscated in every Gridcoin block, which contains a Proof-of-Research reward. We gathered one pre-image from the minted blocks of our victim and deobfuscated it. Thus, we know the values of the iCPID, and the email address of our victim. Subsequently, use the hash of the last block created by the network and use these three values to create a valid CPIDv2. Afterwards we constructed a new block. In the block we also store the current BOINC values of our victim, which we can gather from the statistics websites. The final block is afterwards sent into the Gridcoin network. In case all values are computed correctly by the attacker, the network will accept the block, and resulting in a higher reward for the attacker, consisting of Proof-of-Stake and Proof-of-Research reward.


Fig. 4: Obfuscation function	Fig. 5: Deobfuscation function

Evaluation

In order to verify our attacks practically, we created two virtual machines (R and A), both running Ubuntu 14.04.3 LTS. The virtual machine R contained a legitimate BOINC and Gridcoin instance. It represented the setup of a normal Gridcoin Researcher. The second machine A contained a modified Gridcoin-Research client 3.5.6.8 version, which tried to steal the Proof-of-Research reward of virtual machine R. Thus, we did not steal reward of other legitimate users. The victim BOINC client was attached to the SETI@home project 11 with the eCPID 9f502770e61fc03d23d8e51adf7c6291.

The victim and the attacker were in possession of Gridcoins, enabling them to stake currency and to create new blocks.

Fig. 6: CPIDv2 calculation deobfuscated

Initially both Gridcoin-Research clients retrieved the blockchain from other Gridcoin nodes in the Gridcoin network.

The Gridcoin attack client made it possible to specify the victim email address, iCPID and target project. All these values can be retrieved from the downloaded blockchain and our previous attack via the reverseCPIDv2 function as shown in Figure 7. The attack client read the iCPID and email address of the victim from a modified configuration file. All other values, for example, RAC or ResearchAge, were pulled from http://cpid.gridcoin.us:5000/get_user.php?cpid=. As soon as all values were received, the client attempted to create a new valid block.

Fig. 7: Reverse the CPIDv2 calculation to get iCPID and email address

Once a block had been created and confirmed, the attacker received the increased coin reward with zero BOINC contribution done. The attack could only be detected by its victims because an outside user did not know the legitimate Gridcoin addresses a Researcher uses.

All blocks created with our victim's eCPID are shown in Table 2. Illegitimate blocks are highlighted. We were able to mint multiple illegitimate blocks, and thus stealing Research Age from our victim machine R. All nine blocks created and send by our attacker to the Gridcoin network passed the Gridcoin block verification, were confirmed multiple times, and are part of the current Gridcoin blockchain. During our testing timespan of approximately three weeks, the attacker machine was wrongfully rewarded with 72.4 Proof-of-Research generated Gridcoins, without any BOINC work. The results show that the attack is not only theoretically possible, but also very practical, feasible and effective. The attack results can be reproduced with our Gridcoin-Research-Attack client.

Tab. 2:Blocks minted with the victim's eCPID

The Fix

In order to fix the security issue, we found one solution which does not require any changes to the BOINC source code nor the infrastructure. It is sufficient to change some parts of the already existing Gridcoin Beacon system. Thus, our solution is backwards compatible.
The current Gridcoin client utilizes so called Beacons to register new eCPIDs and stores them as a transaction of 0.0001 Gridcoins in a Superblock which is created every 24 hours. A Beacon encloses the user's personal eCPIDs, a corresponding unused (but irreversible) CPIDv2, and the wallet's main Gridcoin payment address. Once the Superblock is created, the eCPIDs is bound to one Gridcoin payment address. During the block verification process this bond is unfortunately not checked. Furthermore, the existing Beacon system does not use any strong asymmetric cryptography to ensure authenticity and integrity of the broadcasted data. We propose to extend the Beacon system with public key cryptography. In detail, we suggest that a user binds his fresh public key PK_1 to a newly generated eCPID, and then storing them together in a Superblock. An initial Beacon would therefore contain a hashed (e.g. SHA-256) eCPID, the public key, a Nonce, and a cryptographic signature created with the corresponding secret key SK_1 of the public key. This allows only the owner of the secret key to create valid signatures over blocks created with his eCPID. Thus, an adversary first needs to forge a cryptographic signature before he can claim Proof-of-Research work of another Gridcoin user. Thus, he is not capable of stealing the reward of the user.

Beacon to create a eCPID, public/secret key pair bond

For verification purposes nodes fetch the corresponding latest public key from one of the Superblocks. Furthermore, this Beacon structure allows a user to replace his previous public key associated with his eCPID. This is realized by submitting a new Beacon with a new public key PK_2, signed with his old secret key.

Beacon to update a eCPID, public/secret key pair bond

All Beacons in the chain are verifiable and the latest public key is always authentic. The Nonce provide freshness for the signature input, and therefore prevent replay attacks against the Beacon system.
Note that the eCPID needs to be completely unknown to the network, when sending the initial Beacon, for this concept to work as intended. The hash function ensures, that the Beacon does not reveal the fresh eCPID. As a result, an attacker is unable to mint with a eCPID even if he was able to intercept an initial Beacon and replaced the public key and signature with his own parameters, beforehand. This solution does not require any changes in the BOINC source code or the project servers.

Sign a block

In order to claim the Proof-of-Research reward for a newly created block, the Gridcoin minter computes a signature over the hash of the blockheader. Afterwards, he stores the resulting value at the end of the corresponding block in a new field. The private key used for the signature generation must correspond to the advertised public key by the user. It is important to note that the signature value is not part of the Merkle tree, and thus does not change the blockheader. In the end, the signature can then be verified by every other Gridcoin user via the advertised public key corresponding to the eCPID of the Gridcoin minter.

Responsible Disclosure

The attacks and the countermeasures were responsibly disclosed to the Gridcoin developer on the 14th of September, 2016. The developer used our proposed countermeasures and started to implement a new version. Since version 3.5.8.8, which is mandatory for all Gridcoin users, there exists an implementation, which contains countermeasures to our reward stealing attack.
See our next blog post, why Gridcoin is still insecure and should not be used anymore.

Further Reading

A more detailed description of Gridcoin and the attacks will be presented at WOOT'17, the paper is available here.

Authors

Tobias Niemann

Juraj Somorovsky

Martin Grothe

Related articles

Monday, August 31, 2020

Smart Contract Hacking Chapter 2 – Solidity For Penetration Testers Part 2

Beyond Hello World

Hands on Lab – Type out and review contract functionality:

Video Walk Through:

Code Level Walk Through of HelloWorld Bank

Checks Effects Interactions:

Summary

Contact Info:

References:

Related word

Sunday, August 30, 2020

Gridcoin - The Good

In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them.

Background

Berkeley Open Infrastructure for Network Computing

BOINC architecture

BOINC terminology

Gridcoin

Gridcoin terminology

Proof-of-Stake

Proof-of-Research

Reward calculation

Statistic Website

Project Servers

Attacks

Grab Gridcoin user email addresses

Evaluation

Steal Gridcoin users BOINC reward

Evaluation

The Fix

Sign a block

Responsible Disclosure

Authors

Visit our Website

Categories

Blog Archive

Contributors