1

00:00:01,350 --> 00:00:02,170

Hello, everyone.



2

00:00:02,790 --> 00:00:09,330

So in this video, we are going to discuss about a report which was submitted on background four months



3

00:00:09,330 --> 00:00:16,240

ago, as you can see, this report was a subdomain take over on ads.sendgrid.com



4

00:00:17,070 --> 00:00:19,740

Now, why are we discussing this report?



5

00:00:19,740 --> 00:00:24,270

Because there is a very important takeaway from this report.



6

00:00:24,960 --> 00:00:25,530

All right.



7

00:00:25,530 --> 00:00:32,640

So the first thing to understand over here is, according to Bugcrowd, Subdomain Takeover's are considered



8

00:00:32,640 --> 00:00:35,120

to be on a priority P three.



9

00:00:35,400 --> 00:00:36,140

Remember this



10

00:00:36,970 --> 00:00:38,870

This is because of the VRT.



11

00:00:39,270 --> 00:00:44,060

So let me just open up the VRT for you and we can search the table.



12

00:00:44,370 --> 00:00:46,560

Wait here for subdomains.



13

00:00:46,560 --> 00:00:47,080

Take over.



14

00:00:47,670 --> 00:00:56,190

Now, you get notice over here if your subdomain is considered to be a basic one, then you can see



15

00:00:56,400 --> 00:00:57,600

it will go to P3.



16

00:00:57,900 --> 00:01:02,640

And if subdomain is high impact subdomain, then it goes to P2.



17

00:01:03,150 --> 00:01:10,440

We do not know how this is being judged by the programs that which subdomain to be considered as a high



18

00:01:10,440 --> 00:01:12,720

impact subdomain or a basic subdomain.



19

00:01:12,990 --> 00:01:19,710

But the subdomain take over vulnerabilities goes under P2 or P3 type of category.



20

00:01:20,970 --> 00:01:21,510

All right.



21

00:01:21,810 --> 00:01:23,390

Now let's get back over here.



22

00:01:23,490 --> 00:01:28,530

So the subdomains that I reported on was on ads.sendgrid.com



23

00:01:29,160 --> 00:01:29,560

Perfect.



24

00:01:30,090 --> 00:01:33,030

Now you can see over here the priority is P3.



25

00:01:33,030 --> 00:01:34,230

And here is the report.



26

00:01:34,240 --> 00:01:36,210

So let's quickly see the report.



27

00:01:37,710 --> 00:01:38,100

Now.



28

00:01:39,160 --> 00:01:46,240

Steps to reproduce as I visited the domain before the takeover, the status was no such bucket and we



29

00:01:46,240 --> 00:01:49,760

already know that this is the fingerprint that we get.



30

00:01:50,110 --> 00:01:54,840

So I got a same fingerprint over here, which is no such bucket.



31

00:01:54,850 --> 00:01:57,570

The specified bucket does not exist.



32

00:01:57,970 --> 00:01:58,450

Perfect.



33

00:01:58,720 --> 00:02:03,830

Now, being very excited, we are going to claim this into our bucket.



34

00:02:04,240 --> 00:02:11,840

So I created my bucket on the AWS account and the status changed to incorrect.



35

00:02:12,340 --> 00:02:17,710

Let me show you how does it looks like ,as you can see incorrect end point.



36

00:02:17,740 --> 00:02:21,600

The specified bucket exist but into another region.



37

00:02:21,910 --> 00:02:29,520

This has happened because I have reported the bucket or claimed that bucket into a wrong region.



38

00:02:30,010 --> 00:02:33,810

Now it says please redirect the request to the specified end point.



39

00:02:34,180 --> 00:02:41,010

So I have made this bucket into ap-south-1, which is Asia Pacific South-1.



40

00:02:41,350 --> 00:02:49,960

That's why I'm getting the error, wherein the ad.sendgrid.com domain has the bucket pointed somewhere



41

00:02:49,960 --> 00:02:50,290

else.



42

00:02:51,160 --> 00:02:55,540

So this is one of the important takeaway that you should take.



43

00:02:55,750 --> 00:03:03,760

Whenever you host a wrong region, then you will get a bad request four zero zero bad request and a message



44

00:03:03,760 --> 00:03:05,090

like incorrect endpoint.



45

00:03:05,650 --> 00:03:06,160

All right.



46

00:03:06,160 --> 00:03:07,980

So what is the change that we have observed?



47

00:03:08,350 --> 00:03:11,380

The change was from four zero four to 400.



48

00:03:11,380 --> 00:03:13,020

We still do not have a 200.



49

00:03:13,030 --> 00:03:14,650

OK, all right.



50

00:03:15,010 --> 00:03:18,750

Let's scroll down and I'm going to put the IP address.



51

00:03:18,760 --> 00:03:25,960

So this IP address belongs to ads dot sendgrid dot com from where I'm going to find the region of



52

00:03:25,960 --> 00:03:27,100

the bucket of it.



53

00:03:27,100 --> 00:03:30,850

It is hosted as can be seen into the screenshot attached.



54

00:03:31,660 --> 00:03:39,430

As you can see over here, I have done a reverse DNS lookup and from here I was able to identify that



55

00:03:39,760 --> 00:03:44,710

the domain name points to S3 website US East one.



56

00:03:44,920 --> 00:03:45,430

All right.



57

00:03:45,460 --> 00:03:49,030

So I know the bucket name and the bucket region.



58

00:03:49,030 --> 00:03:56,110

The bucket region is us e one now deleted the bucket, made it to the new region again.



59

00:03:56,110 --> 00:03:57,550

So I deleted the bucket.



60

00:03:57,550 --> 00:04:04,300

Remember, this is a very, very critical part because when you delete the bucket, if in that particular



61

00:04:04,300 --> 00:04:09,850

period someone else claims that bucket, then he becomes the owner of that particular bucket.



62

00:04:10,300 --> 00:04:15,340

And one more important thing that I want to discuss is whenever you delete a bucket, you cannot claim



63

00:04:15,340 --> 00:04:16,540

it back immediately.



64

00:04:16,540 --> 00:04:21,340

It takes around one hour at least for you to claim that bucket.



65

00:04:21,670 --> 00:04:26,590

So remember, try to take over the bucket regions correctly.



66

00:04:26,590 --> 00:04:35,530

Do not do it in a very, very quick or do not do it very fast so that you miss this specific thing that



67

00:04:35,530 --> 00:04:36,190

is the region.



68

00:04:37,150 --> 00:04:41,020

Now, as you can see, the new bucket has been created and the bucket is this.



69

00:04:41,140 --> 00:04:47,740

So the fixe is kindly delete the dangling entry from your DNS or wait for me to release the bucket so



70

00:04:47,740 --> 00:04:48,760

you can further claim it.



71

00:04:48,760 --> 00:04:55,840

I reported this and these are the logs which are generated into my S3 all right.



72

00:04:55,840 --> 00:05:02,560

After quite of talking, they said in order to be accepted, please provide a PoC demonstrating that



73

00:05:02,560 --> 00:05:06,970

you are able to serve content on subdomains which is ads.sendgrid



74

00:05:07,270 --> 00:05:07,600

Com.



75

00:05:07,630 --> 00:05:09,400

This is pretty a valid answer.



76

00:05:09,400 --> 00:05:16,060

When I was not able to upload content on the sub domain because it was pointed to a wrong region.



77

00:05:16,720 --> 00:05:24,300

Now I fixed this quickly and I was successfully submitted the content on the website ads.sendgrid.com



78

00:05:24,310 --> 00:05:28,960

because I knew the only the region was giving the issue.



79

00:05:28,960 --> 00:05:37,270

I quickly fixed the region and you can see it was serving the content from ads.sendgrid.com.



80

00:05:38,080 --> 00:05:46,120

So I hope you guys understood and how you may not do the same mistake of choosing the wrong region,



81

00:05:46,390 --> 00:05:54,160

which may take your one or two hours of time to fixing it again onto the AWS platform.



82

00:05:54,520 --> 00:06:00,100

So these are some of the key takeaways from this particular report that I have shown over here.



83

00:06:01,300 --> 00:06:04,780

So I hope you guys understood how you can do subdomain.



84

00:06:04,780 --> 00:06:09,520

Takeover's on a A>W.S. and choosing the region is very, very important.



85

00:06:09,760 --> 00:06:10,300

Thank you.