Prepared by:
HALBORN
Last Updated 04/26/2024
Date of Engagement by: August 18th, 2022 - September 12th, 2022
100% of all REPORTED Findings have been addressed
All findings
15
Critical
0
High
2
Medium
4
Low
6
Informational
3
HbarSuite
engaged Halborn to conduct a security audit on the DEX and smart nodes, beginning on 2022-08-18 and ending on 2022-09-12.
The team at Halborn assigned two full-time security engineers to audit the security of the HbarSuite
DEX and smart nodes. These security engineers are blockchain and smart-contract security experts with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols and web application security and architecture.
The goals of our security audits are to improve the quality of systems and aim for sufficient remediation to help protect users.
In summary, Halborn identified some security risks that were mostly addressed by the HbarSuite team
.
The HbarSuite team
were kept informed of both HIGH
rated findings, and solved both issues.
While some automated testing was being performed, two of the smart nodes became unresponsive. The HbarSuite team
were informed of this, but after their investigation it was ruled out that it could have been from the testing.
It was also found that there appears to be no timeouts being enforced on transactions that are waiting for manual user approval through the wallet software. A possible improvement on this could be to enforce a timeout based on the blocktime.
Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the pentest. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques assist enhance coverage of the infrastructure and can assist in quickly identifying potential issues. Halborn was also provided with an SDK to interact with the smart nodes. The following categories of vulnerabilities were evaluated during the audit:
Mapping Application Content and Functionality.
Application Logic Flaws.
Access Handling.
Authentication/Authorization Flaws.
Rate Limitation Tests.
Brute Force Attempts.
Denial of Service and Resource Exhaustion Attempts.
Safe Input Handling.
Fuzzing of all input parameters.
Injection (SQL/JSON/HTML/Command).
Attack surface and publicly available services.
Testing that pool ratio remain balanced.
Testing for zero slippage.
testnet-sn1.hbarsuite.network
testnet-sn2.hbarsuite.network
testnet-sn3.hbarsuite.network
testnet-sn4.hbarsuite.network
Smart Rebalance Market Maker is a unique AMM algorithm, created in order to utilize native Atomic Swaps on Hedera.
Critical
0
High
2
Medium
4
Low
6
Informational
3
Impact x Likelihood
HAL-03
HAL-04
HAL-05
HAL-06
HAL-01
HAL-02
HAL-13
HAL-14
HAL-15
HAL-07
HAL-08
HAL-09
HAL-10
HAL-11
HAL-12
Security analysis | Risk level | Remediation Date |
---|---|---|
DUPLICATED POOLS CREATED | High | Solved - 09/10/2022 |
POOLS BECOME UNAVAILABLE | High | Solved - 09/11/2022 |
LARGE VALUES IN INPUT FIELDS SITE CRASH | Medium | Solved - 09/15/2022 |
UNAUTHENTICATED CACHE PURGING | Medium | Solved - 09/15/2022 |
LAUNCHPAD PURCHASE PAIRING SWAPPED | Medium | Solved - 09/15/2022 |
USDC DECIMALS | Medium | Solved - 09/15/2022 |
NEGATIVE AMOUNTS IN INPUT FIELDS | Low | Solved - 09/15/2022 |
NOT-A-NUMBER VALUES | Low | Solved - 09/15/2022 |
MISSING CLICKJACKING PREVENTION | Low | Solved - 09/15/2022 |
MISSING HTTP SECURITY HEADERS | Low | Solved - 09/15/2022 |
CACHEABLE HTTPS RESPONSE | Low | Solved - 09/15/2022 |
STRICT TRANSPORT SECURITY NOT ENFORCED | Low | Solved - 09/15/2022 |
DEVELOPER LOGS | Informational | Acknowledged |
OPEN PORTS | Informational | Acknowledged |
HISTORICAL IP INFORMATION | Informational | Acknowledged |
// High
It was found that by sending a valid pool create
payload to the /pools/create
API endpoint on all the smart nodes at the same, duplicated pools could be created.
This resulted in no positions being able to be opened in those duplicated pools.
A script was created to send a payload to the /pools/create
API endpoint of testnet-sn1
, testnet-sn2
, testnet-sn3
and testnet-sn4
at virtually the same time.
This resulted in the pool being created through at least more than one of the nodes because it was observed that duplicated pools were created.
An example of the payload:
{"baseToken":{"id":"0.0.34332104"},"swapToken":{"id":"HBAR"}}
{width=384 height=458}SOLVED: While testing was ongoing, this issue was raised with the HbarSuite team
. A fix was implemented and after retesting, it was noted that the same method could no longer be used to create a duplicated pool.
// High
It was found, after some time, all the pools that were created while testing became unavailable. This varied from becoming unavailable any time between 3 hours after creation, up to 24 hours after creation.
This resulted in no positions being able to be opened in those duplicated pools.
A new pool was created. Monitoring was enabled using a custom-made script to check for available pools at an interval of 20 minutes.
During the test, it was observed that the created pool become unavailable after approximately 4 hours.
SOLVED: While testing was ongoing, this issue was raised with the HbarSuite team
. A fix was implemented and after retesting over a 24-hour period, it was noted that the pools remained available.
// Medium
It was found that https://hsuite-finance.firebaseapp.com
when large values are entered into the amount
input fields, an error is generated and the site becomes unresponsive until a manual refresh of the browser. It appeared that the error was due to the number being converted into scientific notation.
SOLVED: The HbarSuite team
implemented a fix by using encodingUrl
on all parameters.
// Medium
It was found that https://hsuite-finance.firebaseapp.com
allows unauthenticated cache purging. This allows an attacker to purge the site's caches.
This could lead to additional bandwidth costs and could also potential lead to Denial of Services.
SOLVED: The HbarSuite team
implemented a fix by white listing only the official links on the smart nodes. By doing this, the Firebase application will no longer be operational. The official links are all under Cloudflare, where it is not possible for an anonymous user to purge the cache.
// Medium
It was found that when a negative value is provided when purchasing $LPT
in Launchpad
on https://hsuite-finance.firebaseapp.com
, the tokens are swapped around and you will be spending $LPT
instead of earning it.
SOLVED: The HbarSuite team
implemented a fix by making sure no negative values can be entered into the input fields.
// Medium
It was found that the USDC
token has been set up with 4
decimals. This was observed in the /tokens/list
API endpoint.
The accepted standard for the amount of decimals to be used when working with USDC
is 6
. By performing calculations using 4
decimal places, It might result in unexpected results.
SOLVED: The HbarSuite team
has fixed this by adjusting the decimal value of USDC
to 6
.
// Low
It was found that https://hsuite-finance.firebaseapp.com
allowed for negative values to be entered in the amount
input fields. When the transaction was performed, it did, however, use the positive representation of the value.
SOLVED: The HbarSuite team
implemented a fix by making sure no negative values can be entered into the input fields.
// Low
It was observed that when creating a new position on https://hsuite-finance.firebaseapp.com
the values being shows on the labels indicate incorrect values being parsed. They are showing NaN (Not-a-Number) values, instead of a properly formed numeric value.
SOLVED: The HbarSuite team
implemented a fix and no further NaN values were observed on the UI. There were, however, NaN errors being shown in the developer console of the browser, which the HbarSuite team
has acknowledged.
// Low
It was found that https://hsuite-finance.firebaseapp.com
does not implement the anti-clickjacking X-Frame-Options header, which made it susceptible to clickjacking attacks.
Clickjacking is an attack that tricks a user into clicking a webpage element which is invisible or disguised as another element. This can cause users to unwittingly download malware, visit malicious web pages, provide credentials or sensitive information, transfer money, or purchase products online.
Typically, clickjacking is performed by displaying an invisible page or HTML element, inside an iframe, on top of the page the user sees. The user believes they are clicking the visible page, but in fact they are clicking an invisible element in the additional page transposed on top of it.
The invisible page could be a malicious page, or a legitimate page the user did not intend to visit - for example, a login page.
SOLVED: The HbarSuite team
has fixed the issue by implementing the correct HTTP response headers.
// Low
It was found that https://hsuite-finance.firebaseapp.com
does not implement a number of the standard and recommended HTTP security headers.
The headers that were found to be missing are:
SOLVED: The HbarSuite team
has fixed the issue by implementing the correct HTTP response headers.
// Low
It was found that responses from https://hsuite-finance.firebaseapp.com
may be cached by browsers. Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time.
SOLVED: The HbarSuite team
has fixed the issue by implementing the correct HTTP response headers.
// Low
The application running on https://hsuite-finance.firebaseapp.com
failed to prevent users from connecting to it over unencrypted connections. An attacker able to modify a legitimate user's network traffic could bypass the application's use of SSL/TLS encryption, and use the application as a platform for attacks against its users. This attack is performed by rewriting HTTPS links as HTTP, so that if a targeted user follows a link to the site from an HTTP page, their browser never attempts to use an encrypted connection.
SOLVED: The HbarSuite team
has fixed this by implementing the correct HTTP response headers.
// Informational
It was found on https://hsuite-finance.firebaseapp.com
it appears that some developer logs have been left enabled. This could lead to potentially sensitive information being made available to the user.
ACKNOWLEDGED: The HbarSuite Team
has acknowledged this finding.
// Informational
The three provided hosts were scanned to see which ports are open and which services were running.
testnet-sn1.hbarsuite.network (104.21.73.174)
:
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Port} & \textbf{Service Banner} \
\hline
80 & cloudflare \
\hline
443 & cloudflare \
\hline
2052 & No banner \
\hline
2053 & nginx \
\hline
2082 & No banner \
\hline
2083 & nginx \
\hline
2086 & No banner \
\hline
2087 & nginx \
\hline
2095 & No banner \
\hline
2096 & nginx \
\hline
8080 & cloudflare \
\hline
8443 & cloudflare \
\hline
8880 & No banner \
\hline
\end{tabular}
\end{center}
testnet-sn2.hbarsuite.network (104.21.73.174)
:
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Port} & \textbf{Service Banner} \
\hline
80 & cloudflare \
\hline
443 & cloudflare \
\hline
2052 & No banner \
\hline
2053 & nginx \
\hline
2082 & No banner \
\hline
2083 & nginx \
\hline
2086 & No banner \
\hline
2087 & nginx \
\hline
2095 & No banner \
\hline
2096 & nginx \
\hline
8080 & cloudflare \
\hline
8443 & cloudflare \
\hline
8880 & No banner \
\hline
\end{tabular}
\end{center}
testnet-sn3.hbarsuite.network (104.21.73.174)
:
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Port} & \textbf{Service Banner} \
\hline
80 & cloudflare \
\hline
443 & cloudflare \
\hline
2052 & No banner \
\hline
2053 & nginx \
\hline
2082 & No banner \
\hline
2083 & nginx \
\hline
2086 & No banner \
\hline
2087 & nginx \
\hline
2095 & No banner \
\hline
2096 & nginx \
\hline
8080 & cloudflare \
\hline
8443 & cloudflare \
\hline
8880 & No banner \
\hline
\end{tabular}
\end{center}
testnet-sn4.hbarsuite.network (172.67.146.161)
:
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Port} & \textbf{Service Banner} \
\hline
80 & cloudflare \
\hline
443 & cloudflare \
\hline
2052 & No banner \
\hline
2053 & nginx \
\hline
2082 & No banner \
\hline
2083 & nginx \
\hline
2086 & No banner \
\hline
2087 & nginx \
\hline
2095 & No banner \
\hline
2096 & nginx \
\hline
8080 & cloudflare \
\hline
8443 & cloudflare \
\hline
8880 & No banner \
\hline
\end{tabular}
\end{center}
ACKNOWLEDGED: The HbarSuite Team
has acknowledged this finding.
// Informational
It was found that previous IP addresses that have been associated with the smart nodes were accessible in publicly available DNS history records. Using this information, the direct IP addresses of the nodes were found.
It should, however, be noted that the Cloudflare proxy and firewall has been set up to correctly to not allow direct access to these nodes using those IP addresses.
ACKNOWLEDGED: The HbarSuite Team
has acknowledged this finding.
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed