OP 30 October, 2024 - 07:18 PM
Distributed Blind Bruteforce Attacks Using No-CORS and JavaScript
Introduction
In the ever-evolving landscape of web security, attackers continuously find new methods to exploit vulnerabilities. One such technique gaining attention is the Distributed Blind Bruteforce Attack, which can be executed using JavaScript and the No-CORS feature in browsers. This article delves into how such an attack can be performed against websites that do not implement CSRF tokens, and how even without direct responses, attackers can leverage the browser’s context to perform unauthorized actions.
Understanding the Attack Mechanism
1. What is a Distributed Blind Bruteforce Attack?
A Distributed Blind Bruteforce Attack is a method where multiple clients (often through a compromised script on a webpage) attempt to guess credentials or exploit an API endpoint by sending numerous requests. "Blind" refers to the fact that the attacker does not receive a response that indicates whether each guess was correct or incorrect, making the attack less detectable, as for the attack, the requests are being done by clients with different IP's, browser agents, at different times, it enables 24/7 attacks without limits of resources, without requiring proxies.
2. No-CORS Explained
Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers to prevent malicious websites from making requests to a different domain than the one that served the original web page. No-CORS is a mode that allows requests to be made without regard for the same-origin policy, but it comes with limitations, particularly in how responses are handled.
In a No-CORS request, the browser will send the request, but the response will be opaque, meaning the JavaScript code running on the page cannot read it. However, the request still gets processed by the server.
3. Targeting Unprotected Endpoints
Websites that do not implement CSRF tokens or other authentication checks on sensitive actions leave themselves vulnerable. When a user is authenticated, the session is maintained via cookies. This allows JavaScript running in the browser context to perform actions on behalf of the user, even without receiving specific feedback from the server about the success or failure of each request.
The Attack Process
Step 1: Injecting Malicious JavaScript
The first step in executing this attack is to inject malicious JavaScript code into a target website with traffic, every user visiting the page will become a zombie into the net that will perform attacks using his own IP and browser resources. This can be done through various means, such as Cross-Site Scripting (XSS) vulnerabilities or by compromising third-party resources that the website uses.
Step 2: Initiating the Blind Bruteforce
Once the malicious script is running in a visitor's browser, it can initiate multiple requests to the target endpoint using the No-CORS mode. The script will systematically try different credential combinations or exploit various API endpoints by sending requests that do not require CSRF tokens.
Here’s a simplified example of what the JavaScript might look like:
Step 3: Utilizing the Browser Context
Even though the attacker does not receive a response indicating success or failure, the key point is that any request made by the JavaScript code will be sent with the cookies of the authenticated user. If the script guesses the correct credentials, subsequent requests can exploit the authenticated session.
For instance, after a successful login, the attacker can send requests to perform privileged actions like changing account settings, transferring funds, or accessing sensitive data. The browser does not block these actions because they originate from an authenticated context.
like so:
POST user:pass /auth
403
POST [email protected] /change_email 403
POST correct:userpass /auth 200
POST [email protected] /change_email 200
Doing 1 auth request and 1 change email request immediately, if the first one succeeded, the second one will have cookie and browserstorage context authenticated even if the no-cors doesn't show it to us, meaning the change_email will be accepted.
Consequences of the Attack
The implications of a successful Distributed Blind Bruteforce Attack can be severe:
Account Takeovers: If an attacker gains access to an account, they can perform any action that the legitimate user can.
Additional information:
JavaScript is very flexible with this type of attack. There is a high probability of being able to write a script that generates millions of valid CSRF tokens and store them in the database, while the javascript running on the clients can simply get bulks of 1000-10000 of them in a single get_csrf's tokens and then use them in the request, possibly bypassing captcha systems and csrf systems, while also the majority of the websites nowadays have a CSRF system but it's not correctly implemented, allowing it's reuse.
leaving a like is much appreciated and help me to keep publishing threads.
Introduction
In the ever-evolving landscape of web security, attackers continuously find new methods to exploit vulnerabilities. One such technique gaining attention is the Distributed Blind Bruteforce Attack, which can be executed using JavaScript and the No-CORS feature in browsers. This article delves into how such an attack can be performed against websites that do not implement CSRF tokens, and how even without direct responses, attackers can leverage the browser’s context to perform unauthorized actions.
Understanding the Attack Mechanism
1. What is a Distributed Blind Bruteforce Attack?
A Distributed Blind Bruteforce Attack is a method where multiple clients (often through a compromised script on a webpage) attempt to guess credentials or exploit an API endpoint by sending numerous requests. "Blind" refers to the fact that the attacker does not receive a response that indicates whether each guess was correct or incorrect, making the attack less detectable, as for the attack, the requests are being done by clients with different IP's, browser agents, at different times, it enables 24/7 attacks without limits of resources, without requiring proxies.
2. No-CORS Explained
Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers to prevent malicious websites from making requests to a different domain than the one that served the original web page. No-CORS is a mode that allows requests to be made without regard for the same-origin policy, but it comes with limitations, particularly in how responses are handled.
In a No-CORS request, the browser will send the request, but the response will be opaque, meaning the JavaScript code running on the page cannot read it. However, the request still gets processed by the server.
3. Targeting Unprotected Endpoints
Websites that do not implement CSRF tokens or other authentication checks on sensitive actions leave themselves vulnerable. When a user is authenticated, the session is maintained via cookies. This allows JavaScript running in the browser context to perform actions on behalf of the user, even without receiving specific feedback from the server about the success or failure of each request.
The Attack Process
Step 1: Injecting Malicious JavaScript
The first step in executing this attack is to inject malicious JavaScript code into a target website with traffic, every user visiting the page will become a zombie into the net that will perform attacks using his own IP and browser resources. This can be done through various means, such as Cross-Site Scripting (XSS) vulnerabilities or by compromising third-party resources that the website uses.
Step 2: Initiating the Blind Bruteforce
Once the malicious script is running in a visitor's browser, it can initiate multiple requests to the target endpoint using the No-CORS mode. The script will systematically try different credential combinations or exploit various API endpoints by sending requests that do not require CSRF tokens.
Here’s a simplified example of what the JavaScript might look like:
Step 3: Utilizing the Browser Context
Even though the attacker does not receive a response indicating success or failure, the key point is that any request made by the JavaScript code will be sent with the cookies of the authenticated user. If the script guesses the correct credentials, subsequent requests can exploit the authenticated session.
For instance, after a successful login, the attacker can send requests to perform privileged actions like changing account settings, transferring funds, or accessing sensitive data. The browser does not block these actions because they originate from an authenticated context.
like so:
POST user:pass /auth
403
POST [email protected] /change_email 403
POST correct:userpass /auth 200
POST [email protected] /change_email 200
Doing 1 auth request and 1 change email request immediately, if the first one succeeded, the second one will have cookie and browserstorage context authenticated even if the no-cors doesn't show it to us, meaning the change_email will be accepted.
Consequences of the Attack
The implications of a successful Distributed Blind Bruteforce Attack can be severe:
Account Takeovers: If an attacker gains access to an account, they can perform any action that the legitimate user can.
Additional information:
JavaScript is very flexible with this type of attack. There is a high probability of being able to write a script that generates millions of valid CSRF tokens and store them in the database, while the javascript running on the clients can simply get bulks of 1000-10000 of them in a single get_csrf's tokens and then use them in the request, possibly bypassing captcha systems and csrf systems, while also the majority of the websites nowadays have a CSRF system but it's not correctly implemented, allowing it's reuse.
leaving a like is much appreciated and help me to keep publishing threads.
