Penetration Testing Report for Centralized Exchange

Management Summary

Centralized Exchange team contacted Sayfer in order to perform full blackbox penetration testing on their web application and whitebox review for their crypto architecture in December 2021.

Before assessing the above services, we held a kickoff meeting with the Centralized Exchange technical team and received an overview of the system and the goals for this research.

Over the research period of 4 weeks, we discovered 10 vulnerabilities in the system. The most dangerous vulnerabilities were SQL injection and flaws in business logic.

The impact on the system is critical as a malicious attacker could exploit some of these vulnerabilities to take advantage of the system, either by changing his user role to “super_user” via the SQL injection or by abusing the system and stealing money from the Centralized Exchange using the 30s system update mechanism.

Security Evaluation Methodology

Sayfer uses OWASP WSTG as our technical standard when reviewing web applications. After gaining a thorough understanding of the system we decided which OWASP tests are required to evaluate the system.

Security Assessment Findings

Saving Private MPC Keys Insecurely

Description

Centralized exchanges suffer from low-quality key management practices. There are many examples of such cases where the keys were lost or stolen causing the service to lose all the wallet funds or lock the funds completely.

During our configuration files audit, we went over the key management storage. We found that the keys that are being used for the cold multi-sig wallet are not stored in distributed enough places.

There are 3 keys that are being used within the MPC key signing. 1 is stored in a physical protected machine. The other 2 are stored within the same dedicated machine in GCP.

There are a couple of security measurements taken to secure these machines but the problem relies on the distribution, if the machine deployed on GCP gets compromised, an attacker can sign any transaction from the cold wallet.

This is a high-risk and sensitive place where many have failed in the past, best practices should be strictly followed.

Mitigation

Use 3rd party custodian service to manage hot wallets and vaults. We will be happy to recommend one of our partners.

These services handle MPC and key management for you, with other added security layers making the use of such services the best choice for centralized exchanges.

SQL Injection

Description

An SQL injection attack involves inserting or “injecting” a partial or complete SQL query into the data input that is transmitted from the client to the web application. A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), perform database administration operations (such as shutting down the DBMS), recover the content of a given file on the DBMS file system or write files into the file system, and, in some cases, issue commands to the operating system.

Using the transaction endpoint we were able to abuse the more URL query parameter to injection malicious SQL payload:

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

The payload we used was:

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b – Which in this case, checks if the running instance of Postgres is version 10 or not.

An attacker that exploits this vulnerability could take over the system. We were able to extract the table schemas, update our own user’s role or dump any information saved on the DB and even changed our user’s balance on the DB.

Mitigation

SQL injection vulnerability is easy to fix but hard to mitigate. Strong linting or implementation of compiling rules that enforce future change are needed.

Mitigation of SQL injection vulnerabilities is usually done by following a framework of choice, which means that the developer should never concatenate strings into a full SQL statement.

Every user input should be sanitized into an SQL executor rather than being used as a simple SQL query string.

For more information about SQL injection perfection please refer to the SQL Injection Prevention CheatSheet.

Insecure Direct Object References

Description

Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.

We found that the █████████ API lets an attacker view other users’ dashboard information, including all the financial data of this user.
The vulnerability relies on the dashboard id parameter which is a guessable integer. Example request for a single dashboard (for a dashboard that is not owned by the current user):

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

That indicates that the /dashboard/DASHBOARD_ID endpoint does not check for authorization for the requested resource. An authenticated attacker could scrape every single dashboard which holds information about the user funds and past transactions.

Mitigation

There are multiple ways to mitigate IDOR vulnerabilities, for this case it seems the solution might be to check for authorization for each and every request.

This means that every request key will be able to fetch only its account’s dashboards

Weaker Authentication in Alternative Channel

Description

Even if the primary authentication mechanisms does not include any vulnerabilities, it may be that vulnerabilities exist in alternative legitimate authentication user channels for the same user accounts.

This vulnerability is part of a chain of 2 vulnerabilities that enabled us to take over any account with just an email address.

As part of our reconnaissance phase where we try to find a wider attack vector by enumerating the main target subsystems, we found an admin interface under the subdomain ██████████████████. It is possible to login into the admin interface using a normal app user, but for almost all the network requests we inspected during the loading of the main page, the server returns a 401 error.

[IMAGE_REDACTED]

We reverse-engineered the main.js bundle file which has the front-end code for the app and found all the potential endpoints an admin can interact with.

We could exploit only the endpoint of api/updateUser. The endpoint enabled us to edit any user email, and by doing so we were able to reset the victim’s password and take over the account

[IMAGE_REDACTED]

Mitigation

It is highly recommended to make an authentication mechanism or a VPN for debugging or for the administrative services of the system to prevent the presence of unsecured public applications that can be exploited by an attacker.

In addition, there is an authorization mechanism in the admin interface, but this is out of the scope of this project.

Review Webserver Metafiles for Information Leakage

Description

As part of our research about the target and its sub-domains we found some metafiles that should not be public, or at least not without the proper authentication mechanism.

• ████████████████████████.gitignore
• ██████████████████████████████/docker-compose.yml
• ████████████████████████/swagger-ui.html

[IMAGE_REDACTED]

[IMAGE_REDACTED]

[IMAGE_REDACTED]

We found three kinds of files that may harm ████████ services, .gitignore, swagger-ui and the docker-compose.yml file. These three files reveal sensitive data

about the service architecture. A malicious actor can use this information to increase his attack vector on the target.

Mitigation

If possible, remove these files from the public service or implement an authorization mechanism that grants access only to privileged users.

Missing Content Security Policy header

Description

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.

We didn’t find a CSP header in any of the server’s responses.

[IMAGE_REDACTED]

By using CSP website administrators add another line of defense against XSS or clickjacking attacks, by doing so the system will be safe even if future unsecured changes are made to the source code.

A basic CSP policy should at least describe the default whitelisted domains for static files (like scripts, images, and CSS). And frame-ancestors to prevent clicking-jacking attacks.

More info:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

Mitigation

Adding the Content-Security-Policy: [policy] on every response where loading external resources could be dangerous

We highly recommend using it and testing it first with the “Report-Only” variation to test your policy before releasing it to production:

Content-Security-Policy-Report-Only: [policy]

Testing for Security Headers

Description

1. Browsers support many HTTP headers that can improve applications security to protect against a variety of common attacks, the headers are exchanged between a web client (usually a browser) and a server to specify the security-related details of HTTP communication.

When looking at ████████ security headers the following are missing:

• X-Content-Type-Options

Setting this header will prevent the browser from interpreting files as something other than what is declared by the content type in the HTTP headers.

• Strict-Transport-Security

HSTS is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.

• Referrer-Policy

The Referer header is a request header that indicates the site from which the traffic originated. If there is no adequate prevention in place, the URL itself, and even sensitive information contained in the URL will be leaked to the cross-origin site.

• Access-Control-Allow-Origin

The header has the value of “*” which exposes the API for every website, this might not be the desired outcome.

Mitigation

Adding the headers mentioned above to all back-end services.

Review Webserver Metafiles for Information Leakage

Description

While researching the target with DevTool we were able to view the frontend source code without any obfuscation. This vulnerability occurs because the JS bundles are shipped with sourcemaps to production, which make it possible to read the original source code with comments that might reveal information, for instance, the following paths.ts file:

█████████████████████/paths.ts [IMAGE_REDACTED]

By having the sourcemap, an attacker can learn about the code base, read comments, and find deprecated code parts which later can be used to find vulnerabilities.

Mitigation

Do not ship sourcemaps to production, most logging and error tracing systems have an opinion to upload the sourcemaps to a back-office system. Another approach would be to serve the sourcemaps to only authenticated users via VPN or other mechanisms.

Fingerprint Web Server

Description

While exposed server information in itself is not necessarily a vulnerability, it is information that can assist attackers in exploiting other vulnerabilities that may exist. Most of the endpoints are not disclosing any information about the server through HTTP headers or error pages.
Using the following mal-formed HTTP request we were able to fingerprint an Nginx server through a 400 response
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

The response body is:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

Mitigation

There are different ways to obscure web server headers, the most commonly used methods are:

1. Reverse proxy servers that stand between the global internet and the internal
2. Configure each web server to strip these headers.

Appendix A: Security Evaluation Fixes

Will be updated by the Sayfer team after the first revision.