los verdaderos reyes de la noche vampiros demonios o angeles de la noche

nefertiti

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.

What is DoS Attack?

DOS is an attack used to deny legitimate users access to a resource such as accessing a website, network, emails, etc. or making it extremely slow. DoS is the acronym for Denial of Service. This type of attack is usually implemented by hitting the target resource such as a web server with too many requests at the same time. This results in the server failing to respond to all the requests. The effect of this can either be crashing the servers or slowing them down.

Cutting off some business from the internet can lead to significant loss of business or money. The internet and computer networks power a lot of businesses. Some organizations such as payment gateways, e-commerce sites entirely depend on the internet to do business.

In this tutorial, we will introduce you to what denial of service attack is, how it is performed and how you can protect against such attacks.

Topics covered in this tutorial

Types of Dos Attacks

There are two types of Dos attacks namely;

DoS– this type of attack is performed by a single host
Distributed DoS– this type of attack is performed by a number of compromised machines that all target the same victim. It floods the network with data packets.

How DoS attacks work

Let's look at how DoS attacks are performed and the techniques used. We will look at five common types of attacks.

Ping of Death

The ping command is usually used to test the availability of a network resource. It works by sending small data packets to the network resource. The ping of death takes advantage of this and sends data packets above the maximum limit (65,536 bytes) that TCP/IP allows. TCP/IP fragmentation breaks the packets into small chunks that are sent to the server. Since the sent data packages are larger than what the server can handle, the server can freeze, reboot, or crash.

Smurf

This type of attack uses large amounts of Internet Control Message Protocol (ICMP) ping traffic target at an Internet Broadcast Address. The reply IP address is spoofed to that of the intended victim. All the replies are sent to the victim instead of the IP used for the pings. Since a single Internet Broadcast Address can support a maximum of 255 hosts, a smurf attack amplifies a single ping 255 times. The effect of this is slowing down the network to a point where it is impossible to use it.

Buffer overflow

A buffer is a temporal storage location in RAM that is used to hold data so that the CPU can manipulate it before writing it back to the disc. Buffers have a size limit. This type of attack loads the buffer with more data that it can hold. This causes the buffer to overflow and corrupt the data it holds. An example of a buffer overflow is sending emails with file names that have 256 characters.

Teardrop

This type of attack uses larger data packets. TCP/IP breaks them into fragments that are assembled on the receiving host. The attacker manipulates the packets as they are sent so that they overlap each other. This can cause the intended victim to crash as it tries to re-assemble the packets.

SYN attack

SYN is a short form for Synchronize. This type of attack takes advantage of the three-way handshake to establish communication using TCP. SYN attack works by flooding the victim with incomplete SYN messages. This causes the victim machine to allocate memory resources that are never used and deny access to legitimate users.

DoS attack tools

The following are some of the tools that can be used to perform DoS attacks.

Nemesy– this tool can be used to generate random packets. It works on windows. This tool can be downloaded from http://packetstormsecurity.com/files/25599/nemesy13.zip.html . Due to the nature of the program, if you have an antivirus, it will most likely be detected as a virus.
Land and LaTierra– this tool can be used for IP spoofing and opening TCP connections
Blast– this tool can be downloaded from http://www.opencomm.co.uk/products/blast/features.php
Panther- this tool can be used to flood a victim's network with UDP packets.
Botnets– these are multitudes of compromised computers on the Internet that can be used to perform a distributed denial of service attack.

DoS Protection: Prevent an attack

An organization can adopt the following policy to protect itself against Denial of Service attacks.

Attacks such as SYN flooding take advantage of bugs in the operating system. Installing security patches can help reduce the chances of such attacks.
Intrusion detection systems can also be used to identify and even stop illegal activities
Firewalls can be used to stop simple DoS attacks by blocking all traffic coming from an attacker by identifying his IP.
Routers can be configured via the Access Control List to limit access to the network and drop suspected illegal traffic.

Hacking Activity: Ping of Death

We will assume you are using Windows for this exercise. We will also assume that you have at least two computers that are on the same network. DOS attacks are illegal on networks that you are not authorized to do so. This is why you will need to setup your own network for this exercise.

Open the command prompt on the target computer

Enter the command ipconfig. You will get results similar to the ones shown below

For this example, we are using Mobile Broadband connection details. Take note of the IP address. Note: for this example to be more effective, and you must use a LAN network.

Switch to the computer that you want to use for the attack and open the command prompt

We will ping our victim computer with infinite data packets of 65500

Enter the following command

ping 10.128.131.108 –t |65500

HERE,

"ping" sends the data packets to the victim
"10.128.131.108" is the IP address of the victim
"-t" means the data packets should be sent until the program is stopped
"-l" specifies the data load to be sent to the victim

You will get results similar to the ones shown below

Flooding the target computer with data packets doesn't have much effect on the victim. In order for the attack to be more effective, you should attack the target computer with pings from more than one computer.

The above attack can be used to attacker routers, web servers etc.

If you want to see the effects of the attack on the target computer, you can open the task manager and view the network activities.

Right click on the taskbar
Select start task manager
Click on the network tab
You will get results similar to the following

If the attack is successful, you should be able to see increased network activities.

Hacking Activity: Launch a DOS attack

In this practical scenario, we are going to use Nemesy to generate data packets and flood the target computer, router or server.

As stated above, Nemesy will be detected as an illegal program by your anti-virus. You will have to disable the anti-virus for this exercise.

Download Nemesy from http://packetstormsecurity.com/files/25599/nemesy13.zip.html
Unzip it and run the program Nemesy.exe
You will get the following interface

Enter the target IP address, in this example; we have used the target IP we used in the above example.

HERE,

0 as the number of packets means infinity. You can set it to the desired number if you do not want to send, infinity data packets
The size field specifies the data bytes to be sent and the delay specifies the time interval in milliseconds.

Click on send button

You should be able to see the following results

The title bar will show you the number of packets sent

Click on halt button to stop the program from sending data packets.

You can monitor the task manager of the target computer to see the network activities.

Summary

A denial of service attack's intent is to deny legitimate users access to a resource such as a network, server etc.
There are two types of attacks, denial of service and distributed denial of service.
A denial of service attack can be carried out using SYN Flooding, Ping of Death, Teardrop, Smurf or buffer overflow
Security patches for operating systems, router configuration, firewalls and intrusion detection systems can be used to protect against denial of service attacks.

@EVERYTHING NT

Related news

nefertiti

You Might have read my previous posts about how to remove windows passwords using chntpw and might be thinking why am I writing another tutorial to do the same thing! Well today we are not going to remove the windows user password rather we are going to be more stealth in that we are not going to remove it rather we are going to know what is the users password and access his/her account with his/her own password. Sounds nice...

Requirements:

A live bootable linux OS (I'm using Kali Linux)(Download Kali Linux)
Mimikatz (Download | Blog)
Physical Access to victim's machine
A Working Brain in that Big Head (Download Here)

Steps:

1. First of all download mimikatz and put it in a pendrive.

2. Boat the victim's PC with your live bootable Pendrive (Kali Linux on pendrive in my case). And open a terminal window

3. Mount the Volume/Drive on which windows 8/8.1 is installed by typing these commands
in the terminal window:

mkdir /media/win
ntfs-3g /dev/sda1 /media/win

[NOTE] ntfs-3g is used to mount an NTFS drive in Read/Write mode otherwise you might not be able to write on the drive. Also /dev/sda1 is the name of the drive on which Windows OS is installed, to list your drives you can use lsblk -l or fdisk -l. The third flag is the location where the drive will be mounted.

4. Now navigate to the System32 folder using the following command

cd /media/win/Windows/System32

5. After navigating to the System32 rename the sethc.exe file to sethc.exe.bak by typing the following command:

mv sethc.exe sethc.exe.bak

sethc.exe is a windows program which runs automatically after shift-key is pressed more than 5 times continuously.

6. Now copy the cmd.exe program to sethc.exe replacing the original sethc.exe program using this command:

cp cmd.exe sethc.exe

[Note] We made a backup of sethc.exe program so that we can restore the original sethc.exe functionality

7. With this, we are done with the hard part of the hack now lets reboot the system and boot our Victim's Windows 8/8.1 OS.

8. After reaching the Windows Login Screen plugin the usb device with mimikatz on it and hit shift-key continuously five or more times. It will bring up a command prompt like this

9. Now navigate to your usb drive in my case its drive G:

10. Now navigate to the proper version of mimikatz binary folder (Win32 for32bit windows and x64 for 64 bit windows)

11. Run mimikatz and type the following commands one after the other in sequence:

privilege::debug
token::elevate
vault::list

the first command enables debug mode
the second one elevates the privilages
the last one lists the passwords which include picture password and pin (if set by the user)

That's it you got the password and everything else needed to log into the system. No more breaking and mess making its simple its easy and best of all its not Noisy lol...

Hope you enjoyed the tutorial have fun :)

los verdaderos reyes de la noche vampiros demonios o angeles de la noche

sábado, 29 de agosto de 2020

Gridcoin - The Bad