Turning self xss into remote xss
I googled a bit and found out that cookie-based xss can be exploited and turned into good xss. The steps:
- I must set the same name as our vulnerable cookie “customer_name” on some subdomain of terrahost.no, ie. sub.terrahost.no this way:
document.cookie=’customer_name=<img src=x onerror=alert(document.domain)>; domain=.terrahost.no’;
The dot at the beginning is important. This way despite the cookie being set by the subdomain, it is valid on the main terrahost.no domain.
- I must redirect the victim from the sub.terrahost.no to terrahost.no
Ok, how can I execute these steps? I came up with two ways:
- sending cookie headers injected by CRLF vulnerabilities on the subdomain – haven’t tested this method yet
- using some other XSS on the subdomain to set the cookie with javascript code
The Failures Time
The first thing I did was subdomain enumeration of terrahost.no with the following tools: subfinder, amass, findomain and assetfinder. Then tried to find a CRLF header injection with CRLFFuzz. But failed – none of the subdomains was vulnerable. Now it was time to look for XSS. I found some apps protected by login screens, and some 404 pages, I was looking for CVEs, fuzzing the 404/403/302 endpoints, and found some more apps but I could not find any XSS anywhere :(. After about a week I gave up and decided to report the vulnerability as it is – cookie-based self-XSS. As I expected the team said it’s self xss so there is no threat here.
VPS to the rescue… or not?
As this company offers VPSes, dedicated servers, etc., I thought what If I buy the cheapest VPS and then probably get the subdomain like myserver.terrahost.no, then set up the web server and put the payload there. So I did that and get the subdomain like… srvXXX.terrahost.com.
Noooo! I needed the subdomain of terrahost.no. Anyway, the srvXXX.terrahost.com was just the hostname not visible outside. I played a bit with the VPS and looked for some other services hoping to get some subdomain.terrahost.no and link it somehow with the VPS. But failed again.
I had a new shiny VPS with the static IP… Not what I expected. 🙁 Another failure.
Terrahost’s object storage buckets
I gave up on this bug and started to hunt on the management panel at https://enigma.terrahost.com. What I suddenly noticed, one of Terrahost’s services is AWS S3-like object storage buckets. The bucket address is… mybucket.s3.terrahost.no. I immediately created my bucket called berdzibucket. And now I had what I wanted – berdzibucket.s3.terrahost.no – the subdomain where I could put my files!!! The hard part here was to learn how to use the buckets. I spent some time trying to use AWS CLI tools. Finally contacted support and they told me I needed to use the MinIO tool to operate the buckets. I set up the tool, created the HTML file which set both cookies (step and customer_id) and redirects the victim to the main domain, put this on the s3 bucket, and set the policy to the public:
$ minio cp poc_xss.html terra/berdzibucket
$ minio policy set public terra/berdzibucket/poc_xss.html
The content of the files poc_xss.html was like this:
<script type=”text/javascript”>
document.cookie=’customer_id=<img src=x onerror=alert(document.domain)>;domain=.terrahost.no’;
document.cookie=’step=2;domain=.terrahost.no’;
window.location.href=”https://terrahost.no/bestilling?pid=3813″
</script>
Where https://terrahost.no/bestilling?pid=3813 was the URL of the order page. So I had the URL like:
https://berdzibucket.s3.terrahost.no/poc_xss.html
Clicking the URL redirected the victim to the main terrahost.no domain and the alert box popped up.