How we hacked one of the worlds largest Cryptocurrency Website

Bug Bounty

One of the world’s largest cryptocurrency site was hacked by the Strynx team to find a flaw exposing multiple vulnerabilities that could to lead loss of millions of dollars. One of the team members shared his point of view on how we discovered such a critical issue involving data of millions of users.

Here’s on how we discovered it:

The testing began in two phases: Manual and Automated Recon.

The main purpose was for the discovery of an HTTP API, that could be accessed and exploited via a few commands. Manual recon is always preferred is because it allows people to be independent of different scripts and tools. Automated tools make things simple but consume a lot of time and throw out a lot of false positives. Whereas Manual Recon eliminates the possibilities of false positives and discovers issues much faster.

To begin, the website was behind Cloudflare. There are various methods on retrieving the actual server IP but Censys is generally preferred. Fast and accurate results make the recon process much faster. There are various tools used for automated recon and Censys is one of the best one to use. We’ll deep dive into some of these tools in the next blog. After obtaining the IP, port scanning was performed. Nmap was used to discover all open ports and services which could be potentially used to potentially take over the server or cause harm to the company. No special posts were found except for the port 443 used for website. The website was blockchain-based and It is always assumed that sites dealing with blockchain as usually secure and no harm can be done. But this is not the case here. A way is shown down how this server was exploited by using various methodologies including exploiting and chaining various issues.

On exploring the website, it was seen that each of the requests in the site was accompanied by a CSRF Token. For those who don’t know what a CSRF token is, it is a unique secret which has an unpredictable value that is generated server-side such that It cannot be guessed by users who make scripts which send a request on behalf of the target user. It is similar to a captcha which changes for every request. It was observed that there was an endpoint which was called to generate the CSRF Token. Thus, to automate the process of manually inserting new CSRF Token, A python script was developed. If you want to know how it was done, refer to this link: https://stackoverflow.com/questions/13567507/passing-csrftoken-with-python-requests. And it was time to deep dive.

Here is a short code snippet we used:

from cmd import cmd
import requests
from bs4 import BeautifulSoup

class Terminal(Cmd):
prompt = '>'

def __init__(self):
url = "url"
header = {}
cookies = {"PHPSESSID": "a1sw4s4e7s4s55w6s6sw8s5q2a"}

respose = requests.get(url, header=header, cookies=cookies)
soup = BeautifulSoup(respose.text, 'html.parser')
self.token = soup.find ('input', {'name': 'token'}) {'value'}
Cmd.__init__(self)

def default(self, args)
cmd = agrs
injection = "example" + cmd
print = (injection)
url = "example.coin"

header = {}
cookies = {"PHPSESSID": "a1sw4s4e7s4s55w6s6sw8s5q2a"}
data = {

"username" : "b"
"password" : "a"
"db" : "injection"
"token" : self.token,
"login" : ""
}


respose = requests.post(url, header=header, cookies=cookies, data=data)
soup = BeautifulSoup(respose.text, 'html.parser')

print(respose.text)
if "PDOException" not in respose.text
self.token = soup.find('input'. {'name' : 'token'}) ['value']

trminal = Terminal()
trminal.cmdloop()

The next thing was to look for hidden directories and paths of the webserver. Using tools like dirbuster and gobuster can be used. Along with this, a wordlist was used to enumerate. As rockyou4.txt and directory-list-2.3-*.txt are very well known, a wordlist was prepared with unknown terms. Usually, the wordlists are known to developers and Pen-testers, hence another one was made. The main focus would be to search for JS files with the help of jQuery. Different methods were also used to enumerate hidden files, but we’ll leave that for later on. After this, Burp was used to analyse all the requests. Various POST requests were observed to look out for any issues. Various Parameters were tampered to check the functionality of the site and how database connection is used. Turns out there was a lack of error protection in the site which leaked data when certain parameters were being tampered.

Protip#- Always tamper data to look out for any loopholes. Suppose the value of a parameter is 0, make it 1 to see what happens. Always contradict values of parameters to look out for any loopholes.

On analysing the server (looking into JS files and the error messages) multiple occurrences of hidden parameters were found along with some sensitive information of the internal functions used by the website. These functions helped the site to give more user experience but turned out to be the worst nightmare. Various types of injections did work but we will focus on one of these in much depth. On observing the communications, it was noted that the application did accept some SQL special elements. Thus, it was time to search for SQL Injections. On testing one of the hidden parameters, it was observed that there was an error based SQLi. The working of the parameter wasn’t understood at it wasn’t making any observable changes on the page. Although, the parameter still made calls to the database. Hence it was maybe some functionality which was used for testing but the code wasn’t removed after sending the site to production.  

PDO Exception #1
PDO Exception #2

Here are some of the PDO Exceptions we found. If you don’t know what PDO Exceptions are stay tuned for upcoming blogs. We would write about this in the blogs such that if you find exceptions of this kind, you will learn how to exploit it.

An example of a hidden parameter would be as:

Suppose in JS Files, something like document.getElementById(‘id’) is mentioned. If the JS file is called to some Html page, the parameter can be called from the URL as: example.com/index.php?Id=somevalue. Thus, in some other ways including this, hidden parameters can be found.

The parameter was also tampered to search for code injections such as ‘;id’ or ‘;pwd’ to see if these values delivered any output or throw some error which can be useful for us in understanding the application. But this didn’t work so the next step was to exploit the SQLi found before.

There are various methods to find or exploit SQLi, for that, you can refer to any cheat sheets available online, as too much content is to be delivered. If another blog is needed for this please write in the comments so that we can blog about it later on. Various data from the database was extracted and the juiciest credentials were the database login credentials. If you know, the credentials are usually hashed by default, hence the next job was trying to decrypt these hashes. The hashes were decrypted easily as it was using one common password from public wordlists. It was like Ummm… Such critical site such less protection.

Ok, we got SQL access. What next?

It’s time for RCE.

If you know, after getting SQL remote access to the database, it is possible to upload a PHP shell if the database had executable permissions. To a surprise it did. It was possible to upload a shell to var/www/html directory which created a PHP shell in the root directory of the website. But this wasn’t as easy.

Hurdles don’t ever stop

Turns out there was a filter on the parameter searching out for tags. (XSS Prevention :P). This was bypassed by using double encoding which allowed malicious PHP files to be uploaded on the system. For those who don’t know about how to get a shell from SQLi, please try out Sqlmap to learn about this more. SQLmap does have a function which allows us to get a PHP shell on the webserver. It checks if it has permissions to upload to the web directories and creates a PHP file, which when opened, has options to upload our malicious web shells to the server. From the web shell, we were able to get a reverse shell to the system and hence RCE!

After this, the report was submitted using screenshots and proper POC via secure channels. Within one hour a reply was obtained back acknowledging the report and asking to provide personal details to receive a bounty. To my surprise, a 5-digit bounty was rewarded by the company for this effort. Appreciate the response and the fix time for the company as it was fixed in just 2 hours. Everything from the error codes to the database names was fixed in no time. Kudos to the company!

Please leave down any comments or any suggestions for this blog and any further blogs which you would like to read. We provide services to companies who would like their products to be tested. If you’re a company who wants us to perform complete testing of your site, please use the Contact Us page to drop a message or info(at)strynx.org. We would try to reply at the earliest.

5,825 thoughts on “How we hacked one of the worlds largest Cryptocurrency Website”

  1. Pingback: Keto Diet Pills

  2. Pingback: Jazzct.com

  3. Pingback: Cutting Steroids for Weight Loss

  4. Pingback: Diet Pills

  5. Pingback: Buy Best Testosterone Booster

  6. Pingback: Gym Exercises

  7. Pingback: Information on Brain and Nootropics

  8. Pingback: Digital Health

  9. Pingback: lowest price for viagra 100mg generic

  10. Pingback: generic viagra pills

  11. Pingback: http://droga5.net/

Leave a Reply to DennisRooft Cancel reply

Your email address will not be published. Required fields are marked *

*