This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

What Is postMessage() Vulnerability

By  September 09, 2022  No comments

What Is Post Message()?

The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.

PostMessage uses the following function to send a message

Note that targetOrigin can be a ‘*’ or an URL like https://company.com. __In the second scenario, the message can only be sent to that domain (even if the origin of the window object is different). If the wildcard is used, messages could be sent to any domain, and will be sent to the origin of the Window object.

Attacks And Exploition Of postMessage()

Attacking iframe & wilcard in targetOrigin

As explained in this report if you find a page that can be iframed (no X-Frame-Header protection) and that is sending sensitive message via postMessage using a wildcard (*), you can modify the origin of the iframe and leak the sensitive message to a domain controlled by you. Note that if the page can be iframed but the targetOrigin is set to a URL and not to a wildcard, this trick won’t work.

addEventListener exploitation

addEventListener is the function used by JS to declare the function that is expecting postMessages. A code similar to the following one will be used:

Note in this case how the first thing that the code is doing is checking the origin. This is terribly important mainly if the page is going to do anything sensitive with the received information (like changing a password). If it doesn’t check the origin, attackers can make victims send arbitrary data to this endpoints and change the victims passwords (in this example).

Enumeration

In order to find event listeners in the current page you can:

  • Search the JS code for window.addEventListener and $(window).on (JQuery version)
  • Execute in the developer tools console: getEventListeners(window)
  • Go to Elements –> Event Listeners in the developer tools of the browser

Bypass

addEventListener check origin bypasses

  • If indexOf() is used to check the origin of the PostMessage event, remember that it can be easily bypassed like in the following example: ("https://app-sj17.marketo.com").indexOf("https://app-sj17.ma")\
  • If search() is used to validate the origin could be insecure. According to the docs of String.prototype.search(), the method takes a regular repression object instead of a string. If anything other than regexp is passed, it will get implicitly converted into a regexp. In regular expression, a dot (.) is treated as a wildcard. An attacker can take advantage of it and use a special domain instead of the official one to bypass the validation, like in: "https://www.safedomain.com".search("www.s.fedomain.com").\
  • If escapeHtml function is used, the function does not create a new escaped object, instead it overwrites properties of the existing object. This means that if we are able to create an object with a controlled property that does not respond to hasOwnProperty it will not be escaped.

File object is perfect for this exploit as it has a read-only name property which is used by our template and will bypass escapeHtml function.

X-Frame-Header bypass

In order to perform these attacks ideally you will be able to put the victim web page inside an iframe. But some headers like X-Frame-Header can prevent that behaviour. In those scenarios you can still use a less stealthy attack. You can open a new tab to the vulnerable web application and communicate with it:

postMessage to Prototype Pollution and/or XSS

In scenarios where the data sent through postMessage is executed by JS, you can iframe the page and exploit the prototype pollution/XSS sending the exploit via postMessage.A couple of very good explained XSS though postMessage can be found in https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.htmlExample of an exploit to abuse Prototype Pollution and then XSS through a postMessage to an iframe:

Read More

Hacker’s Top Methods To Bypass 2FA And Otp

By  September 09, 2022  No comments

What Is 2FA And Otp?

2FA ( Two Factor Authentication) is an authentication protocol where access is only granted after providing two pieces of evidence to an authentication mechanism typically a Password and an OTP (One Time Token). To access an account protected with 2FA you need both the password and a secret token, this serves as an extra layer of security. To successfully bypass 2FA means you can gain access to a 2FA protected account without the 2FA code, just the email and password.

Bypassing two-factor authentication Methods

Direct bypass

Fuck the 2FA, just try to access the next endpoint directly (you need to know the path of the next endpoint). If this doesn’t work, try to change the Referrer header as if you came from the 2FA page.

Reusing token

Maybe you can reuse an already used token inside the account to authenticate.

Sharing unused tokens

Check if you can get for your account a token and try to use it to bypass the 2FA in a different account.

Leaked Token

Is the token leaked on a response from the web application?

Session permission

Using the same session start the flow using your account and the victims account. When reaching the 2FA point with both account, complete the 2FA with your account but do not access the next part. Instead of that, try to access to the next step with the victims account floe. If the back-end only set a boolean inside your sessions saying that you have successfully passed the 2FA you will be able to bypass the 2FA of the victim.

Password reset function

In almost all web applications the password reset function automatically logs the user into the application after the reset procedure is completed. Check if a **mail **is sent with a **link **to reset the password and if you can reuse that **link **to reset the password as many times as you want (even if the victim changes his email address).

OAuth

If you can compromise the account of the user in a trusted OAuth platform (Google, Facebook…)

BruteForce Due to Lack of rate limit

There is any limit in the amount of codes that you can try, so you can just brute force it. Be careful with a possible “silent” rate-limit, always try several codes and then the real one to confirm the vulnerability.

BruteForce due to Flow rate limit but no rate limit

In this case there is a flow rate limit (you have to brute force it very slowly: 1 thread and some sleep before 2 tries) but no rate limit. So with enough time you can be able to find the valid code.

BruteForce due to Re-send code reset the limit

There is a rate limit but when you “resend the code” the same code is sent and the rate limit is reset. Then, you can brute force the code while you resend it so the rate limit is never reached.

BruteForce due to Lack of rate limit in user’s account

Sometimes you can configure the 2FA for some actions inside your account (change mail, password…). However, even in cases where there was a rate limit when you tried to log in, there isn’t any rate limit protecting this actions.

Lack of rate limit re-sending the code via SMS

You want be able to bypass the 2FA but you will be able to waste money of the company.

Infinite OTP regeneration

If you can generate a new OTP infinite times, the** OTP is simple enough** (4 numbers), and you can try up to 4 or 5 tokens per generated OTP, you can just try the same 4 or 5 tokens every time and generate OTPs until it matches the ones you are using.

CSRF/Clickjacking

Check if there is a CSRF or a Clickjacking vulnerability to disable the 2FA.

Guessable cookie

If the remember me functionality uses a new cookie with a guessable code, try to guess it.

Apis

If you find that the 2FA is using an API located under a /v*/ directory (like “/v3/”), this probably means that there are older API endpoints that could be vulnerable to some kind of 2FA bypass.

Previous sessions

When the 2FA is enabled, previous sessions created should be ended.This is because when a client has his account compromised he could want to protect it activating the 2FA, but if the previous sessions aren’t ended, this won’t protect him.

Improper access control to backup codes

Backup codes are being generated immediately after 2FA is enabled and are available on a single request. After each subsequent call to the request, the codes can be regenerated or remain unchanged (static codes). If there are CORS misconfigurations/XSS vulnerabilities and other bugs that allow you to “pull” backup codes from the response’ request of the backup code endpoint, then the attacker could steal the codes and bypass 2FA if the username and password are known.

Information Disclosure

If in the 2FA page appears some confidential information that you didn’t know previously (like the phone number) this can be considered an information disclosure vulnerability.

Password-Reset == disable 2fa

  • Create an Account and Turn On 2FA.2.Logout from that account.3.Now, Go to forget Password-Reset page.4.Change your password.5.Now try to log in.6.If you are not asked to enter a 2FA code, You can report.
Read More

Carriage Return Line Feed (CRLF) | CRLF Injection |HTTP Response Splitting

By  September 09, 2022  No comments

 

What is CRLF?

When a browser sends a request to a web server, the web server answers back with a response containing both the HTTP response headers and the actual website content, i.e. the response body. The HTTP headers and the HTML response (the website content) are separated by a specific combination of special characters, namely a carriage return and a line feed. For short they are also known as CRLF.


The web server uses the CRLF to understand when new HTTP header begins and another one ends. The CRLF can also tell a web application or user that a new line begins in a file or in a text block. The CRLF characters are a standard HTTP/1.1 message, so it is used by any type of web server, including Apache, Microsoft IIS and all others.

What is the CRLF Injection Vulnerability?

In a CRLF injection vulnerability attack the attacker inserts both the carriage return and linefeed characters into user input to trick the server, the web application or the user into thinking that an object is terminated and another one has started. As such the CRLF sequences are not malicious characters, however they can be used for malicious intend, for HTTP response splitting etc.

CRLF injection in web applications

In web applications a CRLF injection can have severe impacts, depending on what the application does with single items. Impacts can range from information disclosure to code execution, a direct impact web application security vulnerability. In fact a CRLF injection attack can have very serious repercussions on a web application, even though it was never listed in the OWASP Top 10 list. For example it is also possible to manipulate log files in an admin panel as explained in the below example.

An example of CRLF Injection in a log file

Imagine a log file in an admin panel with the output stream pattern of IP – Time – Visited Path, such as the below:

If an attacker is able to inject the CRLF characters into the HTTP request he is able to change the output stream and fake the log entries. He can change the response from the webs application to something like the below:

The %0d and %0a are the url encoded forms of CR and LF. Therefore the log entries would look like this after the attacker inserted those characters and the application displays it:

IP – Time – Visited Path

Therefore by exploiting a CRLF injection vulnerability the attacker can fake entries in the log file to obfuscate his own malicious actions. The attacker is literally doing page hijacking and modifying the response. For example imagine a scenario where the attacker has the admin password and executed the restrictedaction parameter, which can only be used by an admin.

The problem is that if the administrator notices that an unknown IP used the restrictedaction parameter, will notice that something is wrong. However, since now it looks like the command was issued by the localhost (and therefore probably by someone who has access to the server, like an admin) it does not look suspicious.


The whole part of the query beginning with %0d%0a will be handled by the server as one parameter. After that there is another & with the parameter restrictedactionwhich will be parsed by the server as another parameter. Effectively this would be the same query as:

HTTP Response Splitting Using CRLF Injection

Since the header of a HTTP response and its body are separated by CRLF characters an attacker can try to inject those. A combination of CRLFCRLF will tell the browser that the header ends and the body begins. That means that he is now able to write data inside the response body where the html code is stored. This can lead to a Cross-site Scripting vulnerability.

An example of HTTP Response Splitting leading to XSS

Imagine an application that sets a custom header, for example:

The value of the header is set via a get parameter called “name”. If no URL encoding is in place and the value is directly reflected inside the header it might be possible for an attacker to insert the above mentioned combination of CRLFCRLF to tell the browser that the request body begins. That way he is able to insert data such as XSS payload, for example:

The above will display an alert window in the context of the attacked domain.

An example of HTTP Response Splitting leading to Redirect

Browser to:

And the server responses with the header:

crlf injection In URL Path

You can send the payload inside the URL path to control the response from the server:

HTTP Header Injection Using CRLF Injection

By exploiting a CRLF injection an attacker can also insert HTTP headers which could be used to defeat security mechanisms such as a browser’s XSS filter or the same-origin-policy. This allows the attacker to gain sensitive information like CSRF tokens. He can also set cookies which could be exploited by logging the victim in the attacker’s account or by exploiting otherwise unexploitable cross-site scripting (XSS) vulnerabilities.

An example of HTTP Header Injection to extract sensitive data

If an attacker is able to inject the HTTP headers that activate CORS (Cross Origin Resource Sharing), he can use javascript to access resources that are otherwise protected by SOP (Same Origin Policy) which prevents sites from different origins to access each other.

New HTTP request in SSRF

Abusing CRLF injection you can craft a new HTTP request and inject it.
A good example can be done using the SoapClient deserialization gadget from in PHP. This class is vulnerable to CRLF inside the user_agent parameter allowing to insert new headers and body content. However, you can even be able to abuse this vulnerability to inject a new HTTP request:

Impacts of the CRLF injection Vulnerability

The impact of CRLF injections vary and also include all the impacts of Cross-site Scripting to information disclosure. It can also deactivate certain security restrictions like XSS Filters and the Same Origin Policy in the victim’s browsers, leaving them susceptible to malicious attacks.

How to Prevent CRLF / HTTP Header Injections in Web Applications

The best prevention technique is to not use users input directly inside response headers. If that is not possible, you should always use a function to encode the CRLF special characters. Another good web application security best practise is to update your programming language to a version that does not allow CR and LF to be injected inside functions that set HTTP headers.

CHEATSHEET OF CRLF INJECTION ATTACK

Read More