bitsCrunch Blackbox - bitsCrunch

Denial of Service (DoS) vulnerability that arises from the exploitation of SQL Injection (SQLi) vulnerabilities, specifically through the use of the PostgreSQL pg_sleep function. By injecting malicious SQL queries that include the pg_sleep function, an attacker can induce significant delays in the processing of database queries, effectively causing a denial of service for legitimate users and applications dependent on the database.

pg_sleep is a function in PostgreSQL that pauses the execution of a query for a specified amount of time (in seconds). While designed for legitimate uses such as process timing and testing, in the hands of an attacker, it becomes a tool for inducing deliberate delays in database response times.

The exploitation involves an attacker identifying a SQL injection point within an application that interacts with a PostgreSQL database. The attacker then crafts a query incorporating the pg_sleep function, causing the database to pause for a significant amount of time.

'; SELECT pg_sleep(10); --

This would cause the database to halt processing for 10 seconds, if injected into a vulnerable SQL query. Repeated or concurrent exploitation of this vulnerability can overwhelm the database, resulting in a DoS condition where legitimate requests cannot be processed in a timely manner.

Furthermore, there was not found any rate limit mechanisms (we have the PoC of sending +300req/min) which chained with this pg_sleep(20) could stack a high amount of requests with the sleep which will cause a major DoS on the application.

Note: A video PoC was shared with the client showing the impact of the vulnerability.

It is recommended to use parameterized queries when dealing with SQL queries that contain user input. Parameterized queries allow the database to understand which parts of the SQL query should be considered as user input, thus solving SQL injection.

SOLVED: The critical issue was solved by implementing proper parameterized queries.

bitsCrunch mail server contained multiple misconfigurations, allowing an attacker to impersonate emails as bitsCrunch and performing scams/fraud/phishing users, which may result in financial and customer loss.

• An email was sent under false pretences, purporting to originate from the email address noreply@bitscrunch.com.

• The individual identified as the victim, with the email address pau.carrasco@halborn.com, received an email from the attacker, who had assumed the identity of gobi@bitscrunch.com.

• Victim access malicious website.

Configure the SPF and DMARC records with the appropriate policies, preventing an attacker from spoofing emails on behalf of the company.

SOLVED: The issue was solved by configuring the SPF v=spf1 include:_spf.google.com ~all and the DMARK to v=DMARC1; p= quarantine; rua=mailto:dd62a1cbfae64407adc2335298e1df48@dmarc-reports.cloudflare.net

API requests consume resources such as network, CPU, memory, storage, and budget. This vulnerability occurs when too many requests arrive simultaneously, and the API does not have enough compute resources to handle those requests or increases the price of the invoice if using a pay-per-use mode.

An attacker could exploit this vulnerability to overload the API by sending more requests than it can handle. As a result, the API becomes unavailable or unresponsive to new requests.

NOTE: It was possible to send a lot of requests in a short time frame (300req/min).

This vulnerability is due to the application accepting requests from users at a given time without performing request throttling checks. It is recommended to follow the following best practices:

- Implement a limit on how often a client can call the API within a defined timeframe.

- Notify the client when the limit is exceeded by providing the limit number and the time the limit will be reset.

PENDING: The issue will be solved by implementing correct rate limit in a future release. Client already implemented Cloudflare, but the issue is not completely solved.

Deprecated TLS Versions Offered is a security vulnerability that occurs when a server or application continues to support outdated and insecure versions of the Transport Layer Security (TLS) protocol. This exposes users to potential man-in-the-middle attacks, data interception, and decryption of sensitive information by malicious actors. Regularly updating and configuring systems to use only the latest, secure TLS versions is crucial in mitigating this risk and maintaining the integrity of data transmissions.

As the application functionality was hosted across multiple servers, the TLS configuration of each should be reviewed and updated to comply with security best practice and to minimize the risk of existing and future TLS vulnerabilities. \begin{itemize} \item Support for TLS 1.0 and TLS 1.1 should be disabled.\item Support for the weak cipher suites identified above should be removed. \item Key lengths of 256 bits and above should be used for symmetric encryption algorithms and a length of 4096 bits should be used for RSA algorithms. For asymmetric keys generated with ECC algorithms, the minimum recommended key size is 512 bits. \end{itemize} References [Lucky13 Vulnerability](https://crashtest-security.com/prevent-ssl-lucky13/)

SOLVED: The issue was solved by not supporting of TLS 1.0 and TLS 1.1 and only TLS 2.0.

Several security headers were missing from the bitsCrunch web application. These headers used by the client browser improve the security against common attacks.

Missing important security headers;

Content Security Policy, Strict-Transport-Security and X-XSS-Protection response headers.

- Strict-Transport-Security protects HTTPS web servers from downgrade attacks. These attacks redirect web browsers from an HTTPS web server to an attacker-controlled server, allowing bad actors to compromise user data and cookies.

- Content-Security-Policy reduces or eliminates the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowed domains, ignoring all other scripts (including inline scripts and event-handling HTML attributes).

- X-XSS-Protection prevents pages from loading when they detect reflected cross-site scripting (XSS) attacks.

Consider adding the response headers Strict-Transport-Security and X-Frame-Options with appropriate policies.

PENDING: The issue will be solved by configuring the headers mentioned in a future release.

Improper handling of errors can introduce a variety of security problems for software. The most common problem is when detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the user.

These messages reveal implementation details that should never be revealed. Such details can provide hackers important clues on potential flaws in the site, and such messages are also disturbing to normal users.

Make all cryptography-related error messages more generic. Another way to fix this issue could be implementing the error code - error message mapping.

SOLVED: The issue was solved by limiting the error handling on the application.

The current way the front end handles the user session was by directly requesting the backend the user information, it was possible to modify the request or the response to make the front end trust the input data and load the view.

It was important to mention that it does not mean that when performing the response, manipulation was possible to do the actions. However, it was possible to load the views in the front end as an operator or add data such as account number, etc.

Verify in the front end that the user loaded data does correspond with the role user. Moreover, do not let restricted views from the backend to be served to non-authorized users.

ACKNOWLEDGED: The bitsCrunch team acknowledged the issue.

The application does not validate or incorrectly validates the input from the user, which has not the properties that are required to process the data safely and correctly.

It is possible to safe information which contains characters such as &, >, <, ", ', {, }, [, ], # etc. which can potentially lead to other vulnerabilities such as:

- Cross site scripting

- SQL Injection

- Server site template injection

and so on. These characters are not being sanitized, in the frontend.

1. Introduce the characters in inputs fields.

Input validation should be applied on both syntactical and Semantic level. Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol). Semantic validation should enforce correctness of their values in the specific business context (e.g. start date is before end date, price is within expected range).

It is always recommended to prevent attacks as early as possible in the processing of the user's (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application.

SOLVED: The issue was solved by filtering the input characters on the application.