How I hacked the bitcoin mining pool
Today, cryptocurrency websites are a very tasty target for hackers. And their security seems to be at a high level, but no. This is not always the case. Look at least at BlockChain Graveiard , where you can see how the largest services go bankrupt and are closed as a result of hacker attacks. It inspired me and I decided to conduct my own security research on one of these web applications. In this article I will tell what came out of it and how much I was paid. Interesting? Welcome under cat.
So, I visited ViaBTC Pool - one of the largest pools for joint mining. The selection was random and based on the diagram below.
The chart is based on the market share of the most popular bitcoin pools for mining as of 09/23/2017
I registered an account, tied my phone and connected two-factor authentication through Google Authenticator. The option “Authenticate When Sign In ViaBTC” (2fa at the entrance) was also included.
')
That’s how the potential victim’s account looked safe :
Go!
1. The site is not protected from CSRF attacks.
In this case, if the user of the web application visits a malicious site, his email will change to the attacker's address.
It works like this:
Sumptuously! The mail was successfully attached and the attacker automatically logged in the victim’s account. But the wet fantasies of our imaginary hacker about untold crypto-wealth will be interrupted by the very redirect “that home”. Yes, this is the second authentication step (2fa at the entrance, remember?):
2. Bypass two-factor authentication at the entrance
Next, a critical vulnerability was discovered 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 a request directly to the backend, it will be successfully executed without proper authentication.
Thus, the attacker is able to disable two-factor authentication at the entrance, despite the fact that he did not pass the same two-factor authentication, which, undoubtedly, is a very convenient feature .
See for yourself:
What else could be done by sending a request directly to the server? Let's remember the first vulnerability, where the victim's browser itself sent a request to change the email. If the user needs to change the email, the front will request confirmation via the second authentication factor. But if you send a request directly, then 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 his account and to his confidential information. But such important operations as, for example, changing the password is still protected by two-factor authentication.
3. Full bypass of two-factor authentication
The web application allows using two methods of confirming transactions: SMS code or code from Google Authenticator. But I discovered another method - email code.
How? I drew attention to the process of confirming transactions via SMS. It consists of a request for sending a code and a request for confirmation using the received code. It looks like this:
“In this request, it would be nice to change“ sms ”to“ email ”,” I thought.
And here it is logical “sms_code” to “email_code”.
What can I say, sleight of hand and no fraud !
Yes, the attacker does not have access to the victim’s SMS. And yes, he does not have access to the victim's Google Authenticator account. But he has access to email (he was tied to an account thanks to CSRF).
So, the final steps:
This is how the intruder took over the account of a regular user of the web application.
The chain of vulnerabilities allows you to completely steal your account, which, of course, is critical. However, fixing vulnerabilities is not difficult:
But if you look deeper, these vulnerabilities are simply symptoms that can be diagnosed:
The main thing is not just fix those few vulnerabilities that I discovered. It is important to look at the root of the problem. The technical team must draw conclusions and continuously improve their safety knowledge. Yes, perhaps this thought is banal and obvious. But every month we see loud headlines about hacking another cryptobirge. The funny thing is that it seems to be like new technologies with huge risks, millions of money that can permanently leave your wallet, but all the same developers who do not know what CSRF is. I am everything.
UPD: Paid 1 BTC. At the rate at that time about $ 18,000.
So, I visited ViaBTC Pool - one of the largest pools for joint mining. The selection was random and based on the diagram below.
The chart is based on the market share of the most popular bitcoin pools for mining as of 09/23/2017
I registered an account, tied my phone and connected two-factor authentication through Google Authenticator. The option “Authenticate When Sign In ViaBTC” (2fa at the entrance) was also included.
')
That’s how the potential victim’s account looked safe :
Go!
1. The site is not protected from CSRF attacks.
CSRF (English Cross Site Request Forgery - “Cross-site request forgery”, also known as XSRF) is a type of attack on website visitors that uses the disadvantages of the HTTP protocol. If the victim enters the site created by the attacker, a request is secretly sent to another server (for example, to the server of the payment system), performing some kind of malicious operation (for example, transferring money to the attacker's account). To carry out this attack, the victim must be authenticated on the server to which the request is sent, and this request should not require any confirmation from the user, which cannot be ignored or forged by the attacking script.
In this case, if the user of the web application visits a malicious site, his email will change to the attacker's address.
It works like this:
- The user of the web application goes to the attacker's website.
- The victim does not suspect anything, but at that moment a request was sent to the website pool.viabtc.com to change the email address.
- An angry hacker immediately receives a letter to his mail to confirm the operation.
- After clicking on the link in the letter, the attacker sees:
Sumptuously! The mail was successfully attached and the attacker automatically logged in the victim’s account. But the wet fantasies of our imaginary hacker about untold crypto-wealth will be interrupted by the very redirect “that home”. Yes, this is the second authentication step (2fa at the entrance, remember?):
2. Bypass two-factor authentication at the entrance
Next, a critical vulnerability was discovered 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 a request directly to the backend, it will be successfully executed without proper authentication.
Thus, the attacker is able to disable two-factor authentication at the entrance, despite the fact that he did not pass the same two-factor authentication, which, undoubtedly, is a very convenient feature .
See for yourself:
- The attacker uses the query below to disable 2fa during authorization.
- The attacker goes to the main page, but now authentication is not requested.
What else could be done by sending a request directly to the server? Let's remember the first vulnerability, where the victim's browser itself sent a request to change the email. If the user needs to change the email, the front will request confirmation via the second authentication factor. But if you send a request directly, then 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 his account and to his confidential information. But such important operations as, for example, changing the password is still protected by two-factor authentication.
3. Full bypass of two-factor authentication
The web application allows using two methods of confirming transactions: SMS code or code from Google Authenticator. But I discovered another method - email code.
How? I drew attention to the process of confirming transactions via SMS. It consists of a request for sending a code and a request for confirmation using the received code. It looks like this:
“In this request, it would be nice to change“ sms ”to“ email ”,” I thought.
And here it is logical “sms_code” to “email_code”.
What can I say, sleight of hand and no fraud !
Yes, the attacker does not have access to the victim’s SMS. And yes, he does not have access to the victim's Google Authenticator account. But he has access to email (he was tied to an account thanks to CSRF).
So, the final steps:
- The attacker sends a request for a verification code for the operation rebind Google Authenticator account.
- Receives code by email.
- Confirms the operation using the email code.
- Changes the second authentication factor to your own.
This is how the intruder took over the account of a regular user of the web application.
Conclusion
The chain of vulnerabilities allows you to completely steal your account, which, of course, is critical. However, fixing vulnerabilities is not difficult:
- Implement CSRF tokens.
- Perform server side checks.
- Disable confirmation via email.
But if you look deeper, these vulnerabilities are simply symptoms that can be diagnosed:
- Developers do not have basic knowledge of web application security. At a minimum, the knowledge of a hackneyed OWASP TOP TEN would exclude the emergence of such a banal vulnerability as CSRF.
- The developers believe that the frontend is the only data source for the backend of a web application and too trust the data from it. But this is not the case: we can send direct requests to the server side.
- There is no strict policy regarding the functionality of the web application. The developers allowed the existence of a supposedly debug function in the production version of the web application.
The main thing is not just fix those few vulnerabilities that I discovered. It is important to look at the root of the problem. The technical team must draw conclusions and continuously improve their safety knowledge. Yes, perhaps this thought is banal and obvious. But every month we see loud headlines about hacking another cryptobirge. The funny thing is that it seems to be like new technologies with huge risks, millions of money that can permanently leave your wallet, but all the same developers who do not know what CSRF is. I am everything.
Timeline
- 12/13/2017 - Reported.
- 12/14/2017 — Accepted.
- 12/15/2017 - Fixed. Paid the reward.
UPD: Paid 1 BTC. At the rate at that time about $ 18,000.
Source: https://habr.com/ru/post/348396/
All Articles