How I Hacked Bitcoin Mining Pool

Today, websites that work with cryptocurrencies are a wishful target for hackers. And despite people's expectations about these sites’ high-level security systems, sadly it is not always the case. Just visit the BlockChain Graveyard, and you will see how the largest services go bankrupt and close as a result of hacker attacks (and cyber security is still not employing AI to the full). This situation got me concerned and I decided to conduct my own study on the security of one of those web applications. In this article, I will tell you exactly what happened and how big of a payment I received. I admit I did consult with a friend of mine, Davin Bykovsky, Elinext app developer.

I started my experiment by visiting ViaBTC Pool — one of the largest pools for joint mining. My choice of a pool was random and based on the diagram below.

I registered a new account, linked my phone and switched a two-factor authentication via Google Authenticator. The "Authenticate When Sign In ViaBTC" option (2fa on login) was also turned on.

This is how the “victim’s” account safe state looks like:

The website has no protection against CSRF attacks.

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts.

In our case, web application’s user will visit a malicious site, then his email will change to the address of the attacker:

1. The user of the web application goes to the site of the attacker.
2. The user does not suspect anything, but at this point, a request was sent to pool.viabtc.com to change the email address.

   

3. An evil hacker immediately receives a letter in his mail to confirm the operation.

   

4. After using a link attached to the letter, the hacker will see this:

   

   Mail is successfully attached and the attacker is automatically logged in the victim’s account. But the sweet fantasies of our imaginary hacker about the crypto-wealth will be interrupted by this automatically “to Home” redirection.

   He will see the window of our second authentication step (our 2fa login):

   

   Bypassing the two-factor authentication at the logging stage, I discovered a critical vulnerability in the implementation of two-factor authentication. Some functions of the web application required confirmation by the second authentication factor only in the frontend. If you send the request directly to the backend, it will be successfully executed without proper authentication.

This way, the attacker can disable the two-factor authentication at the login stage, despite the fact that he did not pass it, which is undoubtedly a disaster for the security system:

1. Hacker uses the request below to disable 2fa during authorization.

   

2. Then he goes to the main page, but this time authentication is not requested.

   

What else could have been done by sending a request directly to the server? Let us recall the first vulnerability, where the victim's browser itself sent a request to change his email. If the user needs to change the email, the frontend will ask for confirmation via the second authentication factor. But if you send the request directly, the confirmation is not required. Because of this lack of security, the attacker was able to change the email using CSRF.

At this stage, the attacker gained access to the account and to its confidential information. But critical operations, like changing passwords, are still protected by two-factor authentication.

Complete Bypass of the Two-factor Authentication

The web application allows you to use two methods transaction confirmation: SMS code or a Google Authenticator code. But I discovered one more method — email code. How? I paid closer attention to the process of confirming the operation via SMS. It consists of sending code request and a confirmation request using the received code:

I changed word “sms” to word “email”.

As well as “sms_code” to “email_code” accordingly.

Even though the attacker does not have an access to victim’s SMS and Google Authenticator, he had an access to his email, since it was linked to the account, thanks to CSRF.

Final Steps

1. The attacker sends a confirmation code request to the Google Authenticator account re-binding operation.

   

2. Receives the code in the email:

   

3. Confirms the operation using the email code:

   

4. Changes the second authentication factor to his own.

   

And this is how the attacker took possession of an ordinary web application user’s account.

Conclusion

The chain of vulnerabilities allows an intruder to steal your account entirely, which is of course critical. Nevertheless, it is not that difficult to fix them:

1. Implement CSRF tokens
2. Perform server-side checks
3. Disable email confirmation

But if you look closer, these vulnerabilities are just the symptoms by which you can diagnose the following:

1. Developers do not have basic knowledge about web application security. Even basic knowledge of OWASP TOP TEN would have excluded the possibility of vulnerability to CSRF.
2. Developers believe that front-end is the only source of data for the web application backend, therefore trust is too much. In reality, we can also send direct requests to the server side.
3. No strict policy regarding the functionality of the web application. Developers allowed the existence of supposedly debug functions in the production version of the web application.

It is important not only to fix those weak spots I have pointed out but also look at the very core of the problem. The technical team must draw conclusions and constantly improve their knowledge in the field of security. You think that this sounds obvious? How about the fact that every month we see big headlines about the break-in of another cryptocurrency exchange. It is a bit strange for me that we are talking about groundbreaking technologies, with lots of money followed by huge risks that they can leave your wallet forever, though the very same developers do not know what CSRF means.

Timeline

1. 2/13/2018 - Reported
2. 2/14/2018 - Accepted
3. 2/15/2018 - Fixed. Received a reward payment

UPD: Reward was 1 BTC. The current rate at the time was $ 9, 300.