Testing methodology for crypto-exchanges and crypto-wallets

Crypto wallets and crypto exchanges can suffer from hacker attacks (or from the stupidity of users, developers, as well as problems with the logic of the system). Testing to identify vulnerabilities and problems in the logic of the application could help this, but I did not find a formalized methodology in which it was written what to look for during testing. Having tested a good dozen exchanges and wallets, I decided to formalize the procedure for testing them, who are interested, welcome under cat.

During the testing of exchanges and wallets, I paid attention to their functioning, and I formulated aspects of their testing below in the form of a small method, but all in order.
First of all, you need to understand what is important for the customer? For the customer, it is important that money be not stolen from the stock exchange or wallet and the preservation of personal data of users. And since, in fact, each exchange or wallet, for the most part, is a website or web application, the customer wants to conduct a hacker attack simulation, i.e. Black Box testing (see Table 1), but for completeness of testing, the Gray Box testing is chosen more often (see Table 1).
To test the logic of the work you need a test crypto-currency. And since each exchange has its own limitations on deposit / withdrawal of funds, the sum of the test crypto-currency must be at least minimum acceptable for withdrawal and it should be enough to conduct at least 5 purchase-sale and / or input-output transactions.

Table 1. Types of testing depending on the information provided.

Type	Description
Black box	testing is carried out without the involvement of the technical team of the customer
Gray box	contact with the technical team of the customer adding accounts from which testing is underway in the “white list” the customer provides the means (coins) for testing
White box	full customer support provision of application source code provision of logs providing access to different privileges provision of funds (coins) in the quantity required for testing

We, at Hacken, test for vulnerabilities in the following order:

1. The study of publicly available information.
2. Verification by automated means.
3. Manual check.
4. Report writing.

Features of testing crypto exchanges and crypto wallets

1. Testing KYC Verification is the requirement of most crypto exchanges and ICO.

This section discusses file download testing (photographs or screenshots of documents confirming a person’s identity).

• Check for the ability to download executable files to the server system
• Check for the possibility of theft of scanned documents - brute-force file names and directories.
• Check unauthorized access to the server file system.

2. Testing I / O funds

• Verifying the correctness of rounding numbers when depositing funds.
• Checking the substitution of the address of the wallet during the deposit / withdrawal of funds (the simplest mistake is not to check the sender's and the recipient's wallet, but very critical).
• Checking the logic of work during the withdrawal of funds.
• Verification of the bypass of the confirmation of the execution of the purchase-sale operation (two-factor authentication code, OTP, special password).
• Checking Race condition vulnerabilities when withdrawing funds.
• Checking the possibility of going beyond the limits of I / O funds.

3. Testing the purchase and sale of cryptocurrency (refer only to exchanges)

• Verifying the correctness of rounding numbers when buying and selling funds.
• Checking the substitution address for the sale.
• Checking the logic of work when buying and selling funds.
• Check the possibility of substitution or modification of a sell order.
• Verification of the bypass of the confirmation of the execution of the purchase-sale operation (two-factor authentication code, OTP, special password).
• Check the possibility of Race condition in the implementation of the operations of purchase / sale.
• Checking the possibility of changing the address of the wallet.

Testing the Web Part

4. Testing the registration process

• Check the filtering of incoming parameters during registration.
• Check user confirmation functionality.
• Check the possibility of sorting out user names, email addresses and phone numbers.
• Checking the possibility of bypassing the captcha check during registration.
• Check for vulnerabilities and logic when resetting passwords and changing data.

5. Testing the authentication process

• Checks filtering parameters during authentication.
• Checking the possibility of selecting a username and password to the account in the dictionary (brute force protection).
• Check bypass checking captcha.
• Check bypass two-factor authentication.
• Checking the possibility of disabling two-factor authentication.
• Verify the possibility of data leakage during authentication.

6. Testing the frameworks and technologies that were used in the development of the exchange.

During the testing for vulnerability, it is necessary to determine the technologies and methods (frameworks) with which the exchanges were developed. Thus, with the understanding of the technology with which the wallet or the exchange was developed, it is possible to find a possible exploit or already found vulnerabilities in open sources. It is necessary to check that all third-party libraries, frameworks and software do not have publicly available vulnerabilities at the time of release or correct configuration of protection systems (for example, CloudFlare).

7. OWASP Testing

The OWASP methodology contains a checklist that considers all possible security risks for a website. Thus such a check reveals potential weak spots (well, much more dependent on the straightness hand experience and skills of the tester)

The most common:

• Checking the filtering of parameters on the back end, as often they are checked only on the front end
• The lack of HTTP request flags, which is not critical, but can lead to password caching or the ability to perform a Clickjacking attack.
• Lack of session management: this can lead to the fact that when stealing a cookie or direct access by an attacker to a computer or phone, you can perform operations from a valid user
• Vulnerable versions of open services
• Using JSON Web Tokens (JWT), with weak encryption algorithms

8. API Testing

• Check for API vulnerabilities by writing a software module for interacting with the API and checking for possible logical vulnerabilities on the client side and the API.
• Using Swagger to view the structure of the request, it is necessary to understand what needs to be sent to the server and thus check the API for vulnerability.

9. Testing WebSockets

Software, which is usually used for testing:

• Burpsuite
• Acunetix
• Zenmap
• Owasp zap
• SQLmap

And other tools as needed.

Conclusion:

In this article I tried to formalize and structure the methodology for testing exchanges, which I applied in more than 10 cases of testing exchanges and wallets. We took this methodology as the main method of testing exchanges at Hacken . Today, the blockchain technology industry, decentralized solutions, and cryptocurrency are in peak use. FAQs and training manuals become obsolete much faster than Moore's Law; therefore, the article does not claim to be the exclusive manual for testing crypto exchanges, it only expresses the experience gained during the repeated repetition of this procedure.