Exploiting Misconfigured CORS via Wildcard Subdomains

In last post about CORS i explained the cases where and how we can detect the presence of CORS misconfiguration, so this post will cover the one of specific case from them.

So last week while testing one of web application for CORS misconfiguration, i came across a scenario and this is how it looks like:

Request 1#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: https://www.attacker.com
Cookie: <Redacted>
Connection: close

Response 1#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

Request 2#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: http://www.site.com
Cookie: <Redacted>
Connection: close

Response 2#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

Request 3#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: https://test.site.com
Cookie: <Redacted>
Connection: close

Response 3#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

Request 4#

GET /settings HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Referer: <Redacted>
Origin: https://www.site.com.attacker.com
Cookie: <Redacted>
Connection: close

Response 4#

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type
Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH
Access-Control-Allow-Origin: https://www.site.com.attacker.com
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html; charset=utf-8
Date: Sat, 10 Jun 2017 00:27:22 GMT
Expires: Fri, 01 Jan 1990 00:00:00 GMT

....
[data]

so from request 1-3 we can see, the ACAO is properly set no matter from what Origin its requested, but in case 4 we can see the anything after domain name site.com is getting reflected back to ACAO header.

So i thought to exploit it, and after bit of confusion and quick tip from James cleared my doubts. so i enabled the wildcard entry for my domain geekboy.ninja.

And idea is of wildcard will work like this, now if i request anything in this manner: https://site.com.geekboy.ninja/exploit.html, it will valid request and exploit.html will be served from domain geekboy.ninja/exploit.html  and other side, Origin will be set as: https://site.com.geekboy.ninja which is the requirement of this case.

And this is how a small misconfiguration allows attacker to bypass the SOP of website.

Takeaways for hackers: check for every variations of Origin header, for dev: use predefined ACAO dynamically.  

 

do let me know if you have any question in comment section.

22 thoughts on “Exploiting Misconfigured CORS via Wildcard Subdomains

  1. Muhammad Khizer Javed says:

    Awesome post, Last post helped me alot…. and Now this one 👌 Can u share any tut on Enabling wildcard entry on my domain 🙂 Thanks

  2. gopinatg says:

    Sorry , i didnt get ” so i enabled the wildcard entry for my domain geekboy.ninja. ” want to do any setup on attackers domain?

  3. how can i get this domain from internet? can you help me to get any cheap domain. where i can create any folder , html file etc.
    i created in wordpress, there i am not able to.

    • Geekboy says:

      Hey, the 3rd case is about allowed any subdomain of the target application, you can exploit it if you XSS on 1 on the subdomain on the target application otherwise NOT.

  4. Vik says:

    Hey,
    Nice post. I came across one application which makes use of CORS. I am able to get the origin header set in the request in the response of Allow-Origin header. Its similar for request and response 2 & 3 as highlighted in the post. Is it still an issue and should be reported?

  5. Rohan Naasha says:

    What if the server checking the origin header like ‘*.domain.net’ so if i set origin header To ‘[Link deleted]it will work or not.

    • Geekboy says:

      No, it means the site is whitelisted the subdomain of the target website, you need to have XSS on any subdomain to perform CORS request.

  6. Kushal says:

    What if you would have received “Access-Control-Allow-Origin: [Link deleted]for request header “Origin: [Link deleted]Notice the scheme in the response header. Would this be exploitable ?

  7. great post . sir if all http methods are allowed in response and credential is true and origin is third party domain is reflected of any user info url of any domain and when we exploit this cors then it is clearly showing third party domain is accessing this user info detail of this domain. then is it possible for third party domain to use put post or delete method do some manipulation in this url .if yes then how? .its urgent pls reply me I have submitted report. thanks

    • Geekboy says:

      Hey, please keep in mind sometimes this is enabled by the design, for showing security impact of the report, you need to find an endpoint which leaks or allows to make changes in users settings.

Leave a Reply

Your email address will not be published. Required fields are marked *