Introduction

Now everyone talks about bitcoin and crypto-currencies. My acquaintance with crypto-currencies occurred about five months ago when I started investing in Bitcoin and Ethereum. The rate at that time was $1900 for BTC and $89 for eth. To understand what profit I got, I will say that today bitcoin costs $18 000, and eth $830 and continues to grow along with the rest of the crypto-currencies. I thought it would be great to see how safe the services are where I store my savings.

In the late spring, I bought access for $500 to insiders of one investment club. I purchased more coins, this is besides ETH and BTC, and at the end of August, I received a recommendation that we could give our bitcoins to traders at 15% per month; that was why I started my way from sites that are engaged in trust management (further in the article — TM).

Trade management service #1

The first company example1.com (they forbade disclosing the names associated with their websites), is mighty famous and is known by many investors. Before investing money there, I decided to check my account for vulnerabilities. I went through the registration process, but surprisingly — I didn’t find any abnormal behavior. Then I registered another account, but instead of the name, I entered a script for blind xss callbacks. I got no notifications; I was already reconciled to the fact that the project is doing well with filtering (or there is CSP), but only until the logs came to me (source code, admin IP, local storage, etc.)

JS executed when the admin checked the page with data about a user http://admin.example1.com/user/default/index?page=75. Similar vulnerabilities are increasingly encountered on HackerOne; an example is here https://hackerone.com/reports/251224.

Looking through the logs, I noticed that all the session cookies were with the httponly flag; at the end — I would not be able to access the admin panel, but when I clicked the link http://admin.example1.com/user/default/index?page=75, I saw that the admin panel could be used without authorization, this was a gross developer error (Improper Access Control bug).

It was possible to view and change information about 2010 users (email, phone, links to social networks, bitcoin wallet address, login, balance, referrer). In the screenshot, one of my club’s wealthiest investors, has many subscribers, and I constantly follow his blog. He recommended that all his subscribers invest their money in this TM on a referral link, but not more than 20% of the capital. After a short time, he managed to earn 20 bitcoins on this, which equals $ 227 000 for today.

The attacker, without any training or experience, could go to the admin panel and change the email addresses of all the investors to their own (or change wallets for withdrawal so as not to cause unnecessary suspicion when the victim decides to withdraw money). Investors are large enough there; many of them have deposits >0.5btc. It is extraordinary that there are no “not encrypted” passwords in the admin panel.

After discovering the vulnerability, I sent a report to the developers; they contacted the creator and fixed the vulnerability. I was offered to get the award on the account on their website, where I will receive %, and in half a year, I will be able to break into a breakeven, and in a year, I will take the investment body. A month later, when I found a similar blind xss in their service and got another bounty for it, it was found out that the developers of the TM were fired, and other people began to develop it.

Trust management service #2

A little later, after the first recommendation, the second has come (example2.com). This is also a popular trust management service; it has 20 000 Alexa ranks worldwide.

I thoroughly checked everything, but nothing was found (even clickjacking 😄 ), except for two CSRF vulnerabilities in post requests. The first allowed to change the details for the withdrawal of funds; the user just had to click on the link to the CSRF exploit. The second permitted withdrawal of the user’s money to the already changed details. Thus, users will lose all their money if they go through the link. How was the attack possible? An attacker could hire a specialist in social engineering, spam the participants of the TM’s chat in a telegram and get a good profit.

Immediately after the discovery, I wrote to the site’s developers and asked acquaintances from the club to write to the owner. The developers responded that because the user needed to go through the link, the vulnerability was not dangerous; it looked funny. After the response, I wrote a couple more letters with the evidence that the bug was still worth attention and it should be fixed immediately, but I was ignored.

A little later, there were entirely predictable things for projects of this kind that have dangerous low-hanging fruits — user details began to change in massively. I learned about the incident from their developer, who wrote to me just a couple of days ago (as I understood from his words — the users themselves made the withdrawal, and the money began to disappear). It is terrible to imagine losses if hackers used a vulnerability in funds’ withdrawals. The developer then asked again to send a report of the vulnerability. They added google ReCaptcha and enforced it for the request of details changing and confirmation by SMS.

After that, I decided to look for vulnerabilities in cryptocurrency exchanges.

I decided not to touch Poloniex since they don’t pay for bugs and I don’t keep my money there. It’s because of their ignoring of security problems — the vulnerability bypass two-factor authentication was sold in a darknet - https://twitter.com/misterch0c/status/897756404093726720:

Earlier I had $6000 on my account; by accident, I went to my account from Moldova’s VPN, and my account was immediately blocked. I had to wait a fortnight to unlock it, and after this case, I brought out all my money. It was, at least, good that they hadn’t taken it to themselves, as PayPal does.

Livecoin.net (Exchange #1)

I decided to start with livecoin.net. The exchange proved well-protected; I found only low-impact SELF XSS vulnerability (it remained self, clickjacking on the site, and csrf in the post request weren’t presented). I was paid $ 200 in fiat.

Okex exhange (Exchange #2)

Then I decided to go to okex.com. This exchange is popular not only in China but all over the world. Some functionality is not fully translated into English; it is in Chinese, but it wasn’t a problem - Google translator extension helped me to quickly extract text and translate it without leaving the page. As in all other cases — I carefully checked application, including subdomains and directories. It turned out that https://www.okcoin.com/(6000 Alexa in China), https://www.okcoin.cn/ (9000 worldwide, 2000 in China) have the same design and functionality as okex.com. This means that if I find a vulnerability on one of their sites, the rest will be exposed to it. Later I looked in the user support (a little fantasy about how I load the shell into the ticket and it is running), and I found a lot of vulnerabilities. I’ll talk about them below:

1. IDOR vulnerability https://www.okex.com/question/questionDetail.do?workOrderId=2550, allowed to view all 2500 okex tickets at that time, today the number has increased to 4898, and these are only tickets on one version of the exchange. The ticket displays the full phone number, email, real name, text of the correspondence between the user and the support, and the full path to the attachment.

As it turned out later, many users undergo the support service verification procedure to increase their withdrawal limit. It is necessary to attach a photo of the person holding a passport or simply a photo of the passport.

Here is the example of an attachment (Data is hidden):

In addition to passports, there are many photos and screenshots from the device screens.

I retrieved info on some tickets to use as evidence of the problem’s importance and the presence of a bug in testing time and sent a report.

2. Stored XSS in api. Our js is not displayed in the ticket itself /question/questionDetail.do?workOrderId=2550; apparently, there was filtering on forbidden characters. But in api /question/questionDetail.do?workOrderId=2550, everything loaded fine, even js from third-party domain was loaded.

If we combine 1 and 2 vulnerabilities, we can conduct an attack in which it’s possible to customers’ money. The attack should proceed according to the following scenario:

1. We collect all email addresses.

2. On an API endpoint, we embed a js/HTML redirect to the phishing site of the okex exchange(s), Myetherwallet, blockchain.info, etc.

Some attackers figured out that it’s better to ask a victim to enter their MFA code every n second after entering the login and password on poloniex.com / bittrex.com / blockchain.info - to log in to the account, to withdraw funds, change security settings, etc. Responding to the 2FA input should be very prompt because its validity expires after a short period. In 2017, criminals stole from users more than $80 million using Unicode characters, replacing some letters, for example, i on L (BlTTREX.com, POIONIEX.COm), registering the exchange on a different domain (for example, poloniex.com.br), creating applications on android and advertising in search engines.

3. Send letters we have constructed with the person with expertise in social engineering to the collected email addresses. Users should believe the letter’s authenticity and follow the link.

4. ??

5. We get the credentials/MFA codes. Now we can withdraw the money.

3. IDOR in adding a comment - we can add a message on behalf of the user who created a ticket.

Request:

POST /v2/support/cs/work-order/reply HTTP/1.1

Host: http://www.okcoin.com

workId=718&content=test_message

4. Html injection in the HTML file that was attached to the ticket, but on the domain bafangpublic.oss-cn-hangzhou.aliyuncs.com.

5. Improper access control. I noticed that the developers of exchanges hide the user’s phone number in the intermediate and logged-in state to prevent criminals from disclosing phone numbers for attack expansion. On the security page, the phone is displayed as 636818****; in cookies, it is 6 * 6. But the API’s response in the endpoint /v2/support/cs/work-order/2550/replies displays the phone number fully.

It is clear that all exchanges have one owner/development team, and there is no point in writing to all exchanges separately, so I sent a report to the chat and the email of the okex.com exchange. I quickly received a message from the official okex account on Twitter, and all vulnerabilities have been fixed since then.

Exchange #3

Then I started testing the example3.com exchange. The exchange didn’t allow disclosing information about vulnerabilities:

Regarding posting on your blog, we would appreciate it if you did not do this now. Our site is not 100% secure yet.

I discovered XSS in the wallet, precisely — in the affiliate program. It turned out I could raise my self XSS to stored XSS using CSRF exploit; it was possible to steal cookies since there was no httponly flag.

For this XSS, I was offered $100, but at the same time, I got a blind XSS callback with logs from their employees’ domain.

In the logs, there was only AWS load balancing cookie which doesn’t help much:

AWSELB=2ЕB3B1851EC01CCFEEC18E2DB93AE1EF2A69A2A2F9D65DCC84AB785C7C7773319F1F769CCF35CA8F430D5785D5AE4AB2C48C46EE6BE8F33Cу293D40F3CCA9F92E38E62AA65

The session cookie was missing, and we couldn’t get into the admin panel by substituting cookies. I carefully checked the source code inckluded in the blind XSS report and found the administrator’s login and password in the source code.

I went to the login page, and the credentials were accepted as valid after sending. However, I saw that there’s a need to enter a 2FA code:

We can not get into the admin panel via username and password solely. Still, the attacker can get the 2FA code by redirecting the employee to the phishing site directly from the admin area where blind XSS triggers, stealing the 2FA code and quickly entering it.

While writing a report about blind XSS in the admin panel, on the way, I also spotted:

1. CSRF bug in changing details for withdrawal of partner’s earnings, here’s the short request:

POST /affiliate_program HTTP/1.1

Host: www.example3.com

wallet=my_wallet&act=wallet

A security token wasn’t presented in a request, and an attack is possible through a generation of simple CSRF exploit.

2. IDOR at order deletion; the vulnerable endpoint is https://example3.com/account?act=cancel&order=ID_of_order. The essence of the vulnerability is that if a user has already created an order and wants to transfer their bitcoins to the exchange’s wallet, we can cancel this action. At best, their order will retire from the system; at worst — there’s a risk of money loss. This vulnerability is mainly valuable for exchanges — competitors, not for hackers.

After I sent a new report as a support ticket, I was contacted by the chief security officer to discuss the vulnerabilities. He wanted to call me on Skype or on the phone, but at that moment, I couldn’t accept a call so we decided to discuss the details in chat. For the vulnerabilities, I was offered 0.1 BTC ($ 1130):

After consulting with our finance, we can pay you 0.1 BTC. This is the highest amount we paid for bugs and much higher than we usually pay. It’s to show appreciation for you and how you handled the situation.

I’m very grateful for the allocated bounty. The team made an impression of caring about their users’ safety; it was enjoyable to communicate with them.

Overall, for vulnerabilities searching in applications dealing with cryptocurrency, I earned:

Trust management (example1.com): 1 BTC.

Trust management (example2.com): 0.122 BTC.

livecoin.net exchange: $200.

okex.com exchange: 2 BTC. I’m appreciative to okex for providing such a bounty; the exchange’s CTO allowed to disclose the vulnerability publicly.

example3.com exchange: 0.1 BTC.

1 + 0.122 + 2 + 0.1 + $200 = $59 400, and with the growth of bitcoin rate this amount will grow.

Conclusions

Always hire highly qualified developers for your projects, especially if your budget allows it. In the first two cases, the companies are large enough to afford to hire qualified specialists. Still, they save money, and because of this, users and reputation may suffer — they leave the admin board completely “naked” and ignore the problems pointed out by the security researcher.