Zal.:.

Zal Walt

Welcome back to Linux Command Line Hackery, yes this is Part 2 and today we are going to learn some new skills. Let's rock

Let us first recap what we did in Part 1, if you are not sure what the following commands do then you should read Part 1.

mkdir myfiles # make a directory (folder) with myfiles as name
cd myfiles # navigate to myfiles folder
touch file1 file2 file3 # create three empty files file1, file2, file3
ls -l # view contents of current directory
echo This is file1 > file1 # write a line of text to file1
cat file1 # display contents of file1
echo This is another line in file1 >> file1 # append another line of text to file1
cat file1 # display the modified content of file1

Command: cp
Syntax: cp source1 [source2 ...] destination
Function: cp stands for copy. cp is used to copy a file from source to destination. Some important flags are mentioned below
Flags: -r copy directories recursively
-f if an existing destination file cannot be opened, remove it and try again

Let us make a copy of file1 using the new cp command:

cp file1 file1.bak

what this command is going to do is simply copy file1 to another file named file1.bak. You can name the destination file anything you want.
Say, you have to copy file1 to a different folder maybe to home directory how can we do that? well we can do that like this:

cp file /home/user/

I've used the absolute path here you can use whatever you like.

[Trick: ~ has a special meaning, it stands for logged in user's directory. You could have written previous command simply as
cp file1 ~/
and it would have done the same thing.]

Now you want to create a new directory in myfiles directory with the name backup and store all files of myfiles directory in the backup directory. Let's try it:

mkdir backup
cp file1 file2 file3 backup/

this command will copy file1 file2 file3 to backup directory.
We can copy multiple files using cp by specifying the directory to which files must be copied at the end.
We can also copy whole directory and all files and sub-directories in a directory using cp. In order to make a backup copy of myfiles directory and all of it's contents we will type:

cd .. # navigate to previous directory
cp -r myfiles myfiles.bak # recursively copy all contents of myfiles directory to myfiles.bak directory

This command will copy myfiles directory to myfiles.bak directory including all files and sub-directories

Command: mv
Syntax:   mv source1 [source2 ...] destination
Function: mv stands for move. It is used for moving files from one place to another (cut/paste in GUI) and also for renaming the files.

If we want to rename our file1 to  file1.old in our myfiles folder we'll do the follow:

cd myfiles # navigate first to myfiles folder
mv file1 file1.old

this command will rename the file1 to file1.old (it really has got so old now). Now say we want to create a new file1 file in our myfiles folder and move the file1.old file to our backup folder:

mv file1.old backup/ # move (cut/paste) the file1.old file to backup directory
touch file1 # create a new file called file1
echo New file1 here > file1 # echo some content into file1

Command: rmdir
Syntax: rmdir directory_name
Function: rmdir stands for remove directory. It is used for removing empty directories.

Let's create an empty directory in our myfiles directory called 'garbage' and then remove it using rmdir:

mkdir garbage
rmdir  garbage

Good practice keep it doing. (*_*)
But wait a second, I said empty directory! does it mean I cannot delete a directory which has contents in it (files and sub-directories) with rmdir? Yes!, you cannot do that with rmdir.
So how am I gonna do that, well keep reading...

Command: rm
Syntax: rm FILE...
Function:   rm stands for remove. It is used to remove files and directories. Some of it's important flags are enlisted below.
Flags: -r remove directories and their contents recursively
-f ignore nonexistent files and arguments, never prompt

Now let's say we want to delete the file file1.old in backup folder. Here is how we will do that:

rm backup/file1.old # using relative path here

Boom! the file is gone. Keep in mind one thing when using rm "IT IS DESTRUCTIVE!". No I'm not yelling at you, I'm just warning you that when you use rm to delete a file it doesn't go to Trash (or Recycle Bin). Rather it is deleted and you cannot get it back (unless you use some special tools quickly). So don't try this at home. I'm just kidding but yes try it cautiously otherwise you are going to loose something important.

Did You said that we can delete directory as well with rm? Yes!, I did. You can delete a directory and all of it's contents with rm by just typing:

rm -r directory_name

Maybe we want to delete backup directory from our myfiles directory, just do this:

rm -r backup

And it is gone now.
Remember what I said about rm, use it with cautious and use rm -r more cautiously (believe me it costs a lot). -r flag will remove not just the files in directory it will also remove any sub-directories in that directory and there respective contents as well.

That is it for this article. I've said that I'll make each article short so that It can be learned quickly and remembered for longer time. I don't wanna bore you.

Related news

Zal Walt

In this post we will show why Gridcoin is insecure and probably will never achieve better security. Therefore, we are going to explain two critical implementation vulnerabilities and our experience with the core developer in the process of the responsible disclosure.

In our last blog post we described the Gridcoin architecture and the design vulnerability we found and fixed (the good). Now we come to the process of responsibly disclosing our findings and try to fix the two implementation vulnerabilities (the bad).

Update (15.08.2017):
After the talk at WOOT'17 serveral other developers of Gridcoin quickly reached out to us and told us that there was a change in responsibility internally in the Gridcoin-Dev team. Thus, we are going to wait for their response and then change this blog post accordingly. So stay tuned :)

Update (16.08.2017):
We are currently in touch with the whole dev team of Gridcoin and it seems that they are going to fix the vulnerabilities with the next release.

TL;DR
The whole Gridcoin currency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.

What is Gridcoin?

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,530,738 as of August the 4th 2017 and its users contributed approximately 5% of the total scientific BOINC work done before October 2016.

A detailed description of the Gridcoin architecture and technical terms used in this blog post are explained in our last blog post.

The Issues

Currently there are 2 implementation vulnerabilities in the source code, and we can mount the following attacks against Gridcoin:

We can steal the block creation reward from many Gridcoin minters
We can efficiently prevent many Gridcoin minters from claiming their block creation reward (DoS attack)

So why do we not just open up an issue online explaining the problems?

Because we already fixed a critical design issue in Gridcoin last year and tried to help them to fix the new issues. Unfortunately, they do not seem to have an interest in securing Gridcoin and thus leave us no other choice than fully disclosing the findings.

In order to explain the vulnerabilities we will take a look at the current Gridcoin source code (version 3.5.9.8).

WARNING: Due to the high number of source code lines in the source files, it can take a while until your browser shows the right line.

Stealing the BOINC block reward

The developer implemented our countermeasures in order to prevent our attack from the last blog post. Unfortunately, they did not look at their implementation from an attacker's perspective. Otherwise, they would have found out that they conduct not check, if the signature over the last block hash really is done over the last block hash. But we come to that in a minute. First lets take a look at the code flow:

In the figure the called-by-graph can be seen for the function VerifyCPIDSignature.

CheckBlock → DeserializeBoincBlock [Source]

Here we deserialize the BOINC data structure from the first transaction

CheckBlock → IsCPIDValidv2 [Source]

Then we call a function to verify the CPID used in the block. Due to the massive changes over the last years, there are 3 possible verify functions. We are interested in the last one (VerifyCPIDSignature), for the reason that it is the current verification function.

IsCPIDValidv2 → VerifyCPIDSignature [Source]
VerifyCPIDSignature → CheckMessageSignature [Source, Source]

In the last function the real signature verification is conducted [Source]. When we closely take a look at the function parameter, we see the message (std::string sMsg) and the signature (std::string sSig) variables, which are checked. But where does this values come from?

If we go backwards in the function call graph we see that in VerifyCPIDSignature the sMsg is the string sConcatMessage, which is a concatenation of the sCPID and the sBlockHash.
We are interested where the sBlockHash value comes from, due to the fact that this one is the only changing value in the signature generation.
When we go backwards, we see that the value originate from the deserialization of the BOINC structure (MiningCPID& mc) and is the variable mc.lastblockhash [Source, Source]. But wait a second, is this value ever checked whether it contains the real last block hash?

No, it is not....

So they just look if the stored values there end up in a valid signature.

Thus, we just need to wait for one valid block from a researcher and copy the signature, the last block hash value, the CPID and adjust every other dynamic value, like the RAC. Consequently, we are able to claim the reward of other BOINC users. This simple bug allows us again to steal the reward of every Gridcoin researcher, like there was never a countermeasure.

Lock out Gridcoin researcher
The following vulnerability allows an attacker under specific circumstances to register a key pair for a CPID, even if the CPID was previously tied to another key pair. Thus, the attacker locks out a legit researcher and prevent him from claiming BOINC reward in his minted blocks.

Reminder: A beacon is valid for 5 months, afterwards a new beacon must be sent with the same public key and CPID.

Therefore, we need to take a look at the functions, which process the beacon information. Every time there is a block, which contains beacon information, it is processed the following way (click image for higher resolution):

In the figure the called-by-graph can be seen for the function GetBeaconPublicKey.

We now show the source code path:

ProcessBlock → CheckBlock [Source]
CheckBlock → LoadAdminMessages [Source]
LoadAdminMessages → MemorizeMessages [Source]
MemorizeMessages → GetBeaconPublicKey [Source]

In the last function GetBeaconPublicKey there are different paths to process a beacon depending on the public key, the CPID, and the time since both were associated to each other.
For the following explanation we assume that we have an existing association (bound) between a CPID A and a public key pubK_A for 4 months.

First public key for a CPID received [Source]

The initial situation, when pubK_A was sent and bind to CPID A (4 months ago)

Existing public key for a CPID was sent [Source]

The case that pubK_A was resent for a CPID A, before the 5 months are passed by

Other public key for a CPID was sent [Source]

The case, if a different public key pubK_B for the CPID A was sent via beacon.

The existing public key for the CPID is expired

After 5 months a refresh for the association between A and pubK_A is required.

When an incoming beacon is processed, a look up is made, if there already exists a public key for the CPID used in the beacon. If yes, it is compared to the public key used in the beacon (case 2 and 3).
If no public key exists (case 1) the new public key is bound to the CPID.

If a public key exists, but it was not refreshed directly 12.960.000 seconds (5 months [Source]) after the last beacon advertisement of the public key and CPID, it is handled as no public key would exist [Source].

Thus, case 1 and 4 are treated identical, if the public key is expired, allowing an attacker to register his public key for an arbitrary CPID with expired public key. In practice this allows an attacker to lock out a Gridcoin user from the minting process of new blocks and further allows the attacker to claim reward for BOINC work he never did.

There is a countermeasure, which allows a user to delete his last beacon (identified by the CPID) . Therefore, the user sends 1 GRC to a special address (SAuJGrxn724SVmpYNxb8gsi3tDgnFhTES9) from an GRC address associated to this CPID [Source]. We did not look into this mechanism in more detail, because it only can be used to remove our attack beacon, but does not prevent the attack.

The responsible disclosure process

As part of our work as researchers we all have had the pleasure to responsible disclose the findings to developer or companies.

For the reasons that we wanted to give the developer some time to fix the design vulnerabilities, described in the last blog post, we did not issue a ticket at the Gridcoin Github project. Instead we contacted the developer at September the 14th 2016 via email and got a response one day later (2016/09/15). They proposed a variation of our countermeasure and dropped the signature in the advertising beacon, which would result in further security issues. We sent another email (2016/09/15) explained to them, why it is not wise to change our countermeasures and drop the signature in the advertising beacon.
Unfortunately, we did not receive a response. We tried it again on October the 31th 2016. They again did not respond, but we saw in the source code that they made some promising changes. Due to some other projects we did not look into the code until May 2017. At this point we found the two implementation vulnerabilities. We contacted the developer twice via email (5th and 16th of May 2017) again, but never received a response. Thus, we decided to wait for the WOOT notification to pass by and then fully disclose the findings. We thus have no other choice then to say that:

The whole Gridcoin cryptocurrency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.

Further Reading

A more detailed description of the Gridcoin architecture, the old design issue and the fix will be presented at WOOT'17. Some days after the conference the paper will be available online.

Zal.:.

8/28/2020

Linux Command Line Hackery Series: Part 2

Gridcoin - The Bad

What is Gridcoin?

The Issues

Stealing the BOINC block reward

The responsible disclosure process

Related articles