Hello, everyone.
So in this video, we are going to discuss about a report which was submitted on background four months
ago, as you can see, this report was a subdomain take over on ads.sendgrid.com
Now, why are we discussing this report?
Because there is a very important takeaway from this report.
All right.
So the first thing to understand over here is, according to Bugcrowd, Subdomain Takeover's are considered
to be on a priority P three.
Remember this
This is because of the VRT.
So let me just open up the VRT for you and we can search the table.
Wait here for subdomains.
Take over.
Now, you get notice over here if your subdomain is considered to be a basic one, then you can see
it will go to P3.
And if subdomain is high impact subdomain, then it goes to P2.
We do not know how this is being judged by the programs that which subdomain to be considered as a high
impact subdomain or a basic subdomain.
But the subdomain take over vulnerabilities goes under P2 or P3 type of category.
All right.
Now let's get back over here.
So the subdomains that I reported on was on ads.sendgrid.com
Perfect.
Now you can see over here the priority is P3.
And here is the report.
So let's quickly see the report.
Now.
Steps to reproduce as I visited the domain before the takeover, the status was no such bucket and we
already know that this is the fingerprint that we get.
So I got a same fingerprint over here, which is no such bucket.
The specified bucket does not exist.
Perfect.
Now, being very excited, we are going to claim this into our bucket.
So I created my bucket on the AWS account and the status changed to incorrect.
Let me show you how does it looks like ,as you can see incorrect end point.
The specified bucket exist but into another region.
This has happened because I have reported the bucket or claimed that bucket into a wrong region.
Now it says please redirect the request to the specified end point.
So I have made this bucket into ap-south-1, which is Asia Pacific South-1.
That's why I'm getting the error, wherein the ad.sendgrid.com domain has the bucket pointed somewhere
else.
So this is one of the important takeaway that you should take.
Whenever you host a wrong region, then you will get a bad request four zero zero bad request and a message
like incorrect endpoint.
All right.
So what is the change that we have observed?
The change was from four zero four to 400.
We still do not have a 200.
OK, all right.
Let's scroll down and I'm going to put the IP address.
So this IP address belongs to ads dot sendgrid dot com from where I'm going to find the region of
the bucket of it.
It is hosted as can be seen into the screenshot attached.
As you can see over here, I have done a reverse DNS lookup and from here I was able to identify that
the domain name points to S3 website US East one.
All right.
So I know the bucket name and the bucket region.
The bucket region is us e one now deleted the bucket, made it to the new region again.
So I deleted the bucket.
Remember, this is a very, very critical part because when you delete the bucket, if in that particular
period someone else claims that bucket, then he becomes the owner of that particular bucket.
And one more important thing that I want to discuss is whenever you delete a bucket, you cannot claim
it back immediately.
It takes around one hour at least for you to claim that bucket.
So remember, try to take over the bucket regions correctly.
Do not do it in a very, very quick or do not do it very fast so that you miss this specific thing that
is the region.
Now, as you can see, the new bucket has been created and the bucket is this.
So the fixe is kindly delete the dangling entry from your DNS or wait for me to release the bucket so
you can further claim it.
I reported this and these are the logs which are generated into my S3 all right.
After quite of talking, they said in order to be accepted, please provide a PoC demonstrating that
you are able to serve content on subdomains which is ads.sendgrid
Com.
This is pretty a valid answer.
When I was not able to upload content on the sub domain because it was pointed to a wrong region.
Now I fixed this quickly and I was successfully submitted the content on the website ads.sendgrid.com
because I knew the only the region was giving the issue.
I quickly fixed the region and you can see it was serving the content from ads.sendgrid.com.
So I hope you guys understood and how you may not do the same mistake of choosing the wrong region,
which may take your one or two hours of time to fixing it again onto the AWS platform.
So these are some of the key takeaways from this particular report that I have shown over here.
So I hope you guys understood how you can do subdomain.
Takeover's on a A>W.S. and choosing the region is very, very important.
Thank you.