"Subdomain Takeover" prioritization

[truemongo]

Right now subdomain takeover is classified with a base severity of P2, per VRT. I think it should be changed to varies: it would require researchers to prove impact (or at least potential impact), for what is a vulnerability type with wildly varying impacts.

Some potential impacts I've come up with quickly:

• Subdomain is still receiving data from other systems (this could be sensitive data, like CC data or session tokens, potential P1 - other kinds of data, evaluated on a case-by-case basis)
• Subdomain is in a Oauth redirect_uri whitelist, and can be used to steal Oauth tokens (likely a P2, as per current VRT for those issues)
• Subdomain is on the CORS whitelist for some other domain (impact varies, should be judged as CORS issues normally are)
• Main domain sources Javascript from the subdomain - this leads to Stored XSS on the main domain (likely P2)
• Main domain cookies are widely scoped, and the subdomain can access them (as this is essentially equivalent to a RXSS on main domain - you still need to trick user into visiting a subdomain which is likely not often used - likely P3)
• Subdomain can be used to facilitate CSP bypasses on core domains (if whitelisted there), thus allowing XSS on those (likely P3)
• Subdomain can be used for the researcher to put up cat pictures and cause brand image damage (likely P5, unless it happens to be an important subdomain with considerable organic traffic. Maybe P4.)

Probably plenty more, and I welcome additions or corrections, this is just a quick list off the top of my head which hopefully demonstrates how varied the impact for this VRT entry really is. Reports that are just "I can take over subdomain X" should get a reply asking for impact.

[jhaddix]

Thanks for writing out all the scenarios, and I agree the impact can be "varies". I know as of now we ask for proof of the takeover in most cases. So there's that.

What I worry about is that some of the scenarios aren't visible to BC (like amount of traffic) so a designation of "varies" means the client gets to make this call, which sometimes, can lead to a bad priority judgement to the researcher. Keeping it at a the same base priority of P2 (same as a Stored XSS) protects the researchers.

That being said, that's probably a judgement not based on data. I'd love to look at what the average threat scenario is for this bug, and any adjustments for it that customers are commonly doing.

So, TLDR (my opinion, not official BC stance), I kind of agree. Overall I just don't want to run counter to the idea of "Get the researchers paid!" for a common impact scenario. Sometimes the VRT is a protection mechanism for bad decisions regarding impact judgement by the client. Prevalence would also be something I'd want to look at. Are programs receiving a ton of these? On any given program are they impacting payout/points drastically?

Looking forward to other thoughts...

[jstnkndy]

Rather than taking the "help the researcher" approach, I think we should be discussing this from a neutral perspective, and do what is fair/right for both parties, that way no one gets screwed. To do that, it should be looked at on a case by case basis (varies); the researcher needs to prove the impact of the domain being taken over.

[CharlieEriksen]

If leaving it at P2 is to in any way "protect" researchers, that suggests the program needs some education more than anything else. Or maybe engage a researcher in dialog better.

Looking at the VRT, there are varies entries that seem far more likely to deserve a fixed P2, than subdomain takeovers do.

If the researcher can't show impact that makes it clear it deserves a P2, then they must trust the program to make the right call. Otherwise they should have done their research better.

[ghost]

I would like to see a varies classification as outlined by @truemongo , but with an additional bonus to account for damages to the company's reputation and other factors the researcher and program owner might not understand properly.

[jhaddix]

If leaving it at P2 is to in any way "protect" researchers, that suggests the program needs some education more than anything else. Or maybe engage a researcher in dialog better.

This is true. Many are in need of education, but in the limited capacity we can educate them (private comments and customer calls), and the competing factors of pool spend, this is idealistic to think it's so simple. Why not have a base that reflects the most common impact, making sure everything stays rightly incentivized?

Looking at the VRT, there are varies entries that seem far more likely to deserve a fixed P2, than subdomain takeovers do.

We welcome the VRT issues!

If the researcher can't show impact that makes it clear it deserves a P2, then they must trust the program to make the right call. Otherwise they should have done their research better.

I disagree. We're successful in what we do here at Bugcrowd because we're constantly advocating for you all on the back-end. Baseline VRT ratings help us do this. "Varies" allows for subjectivity in a negative way a lot of the times.

I would like to see a varies classification as outlined by @truemongo , but with an additional bonus to account for damages to the company's reputation and other factors the researcher and program owner might not understand properly.

We don't control bonuses, the client does.

Like I said, def some compelling feedback here. Still not 100% sure though. I also love to see what @ryancblack and some of the other ASE's think.

[arkadiyt]

Some thoughts on impact:

Main domain cookies are widely scoped, and the subdomain can access them (as this is essentially equivalent to a RXSS on main domain - you still need to trick user into visiting a subdomain which is likely not often used - likely P3)

This can be weaponized in an iframe ad, serve it to twitter/facebook/etc (you can ever target users of the website) and you will get tons of cookies without user interaction

Also the subdomain can change its document.domain to any parent domain, so if you have example.com with an api at example.com/api, and you takeover subdomain.example.com, then javascript on subdomain.example.com can set its document.domain to example.com and make requests against example.com/api. I think this is a fairly common setup

[darkarnium]

I definitely echo @jstnkndy and the OP's sentiment around varies.

The burden of proof for impact is, for the most part, on the researcher. A PoC provided by the researcher should clearly demonstrate real world impact, not a theoretical impact. As a concrete example, a subdomain takeover of an S3 bucket which is no-longer referenced by any external assets should not automatically qualify as a P2 in my view.

Ultimately, although the onus is on the program / provider to do the right thing and upgrade or downgrade issues according to any changes in severity during internal triage, the researcher also needs to demonstrate a tangible impact in order to justify a vulnerability being marked as high-severity in the first place.

[ryancblack]

To @jhaddix's comment and my latest in #181 (related #180), we're crunching numbers on real outcomes as pertains to:

• how often a suggested minimum VRT entry (the intent) is upgraded or downgraded
• categories for current varies including how these are accepted by average, min, and max

In both cases outliers will be spot checked. The intent of the exercise is to understand that in our imperfect world how we might continue to inform discussions with minimum priority yet facilitate unbiased conversations where we see sufficient need with varies.

As a project, we've tried very hard to minimize the use of varies in favor of explicit minimums however this can be a two-edged sword. Having an understanding of the norms will inform either suggested minimums or guidance my team and I can give customers with respect to varies and the specific submission's actual impact/context.

[truemongo]

@arkadiyt Yup, point well taken, thanks!, but it reinforces the point that impact widely varies and it should be laid out by the researcher, and verified by the triage team, rather than being given a default P2 rating.

@jhaddix

I disagree. We're successful in what we do here at Bugcrowd because we're constantly advocating for you all on the back-end. Baseline VRT ratings help us do this. "Varies" allows for subjectivity in a negative way a lot of the times.

I think the varies is more for the ASEs than for the customers, correct me if I'm wrong, customers are not likely to argue with the ASEs decision. If varies is deemed too vague, however, we could always have a bunch of sub-entries for "Subdomain takeover", each with set priorities, according to the scenarios outlined in the OP (and several other scenarios that will probably be brought up).

So, TLDR (my opinion, not official BC stance), I kind of agree. Overall I just don't want to run counter to the idea of "Get the researchers paid!" for a common impact scenario.

I want researchers to get paid, too! (I'm one of them, so I got a horse in that race). I want, however, researchers to get paid on an even field where vulnerabilities are paid depending on their impact, and not in a field where some vulnerability types have "special status", have a fixed priority set, no demonstration of impact is required, etc - and, as I think has been illustrated, their impact is anything but fixed.

[ryancblack]

@truemongo

I think the varies is more for the ASEs than for the customers, correct me if I'm wrong, customers are not likely to argue with the ASEs decision. If varies is deemed too vague, however, we could always have a bunch of sub-entries for "Subdomain takeover", each with set priorities, according to the scenarios outlined in the OP (and several other scenarios that will probably be brought up).

The reality is "it depends." If we find cause to recommend a higher priority over default there is sometimes friction, certainly in paid programs. It's easier to accept at the VRT recommendation, irrespective of if that's a minimum. For kudos programs there is little to no friction, including suggested upgrades from the researcher, ASE, or customer perspective.

As I mention in #181, one potential benefit of varies is encouraging justification. That said, the impact of this hinges more upon the deep data investigation we're working on now for this beyond subjective view. By nature I see more escalations and unique situations over the bulk norm. I fully recognize my impression is influenced by this perspective.

We need to keep varies under control (or everything could just be varies and that's a nightmare) but it has its place and categorical precedent for good reason. We have a lot of new faces in this thread (thanks @truemongo/ Twitter) I would love similar input in #180 and #181 which are very much related.

[CharlieEriksen]

@ryancblack

Your comment adds a lot of value to the conversation. It's an interesting perspective.

I have mixed feelings about the items that have sub-items. For instance: Directory Listing Enabled > Sensitive Data Exposure Directory Listing Enabled > Non-Sensitive Data Exposure

But the logical conclusion, IMO, is that if you need a P-value, then you almost need to start making a decision tree regards to P-values. These already exist partially, as is the case with Directory Listing Enabled.

On one hand, I dislike too complex systems. Trying to catch every case is pretty silly. But on the other hand, if we're going to find a way to capture the complexity of a severity scale, then the logical conclusion seems to be that it should be more broken out.

[leifdreizler]

I think an automatic P2 for something like this potentially hurts program owners that actually analyze the impact of submissions and try to do the right thing instead of blindly following the VRT. I realize not all program owners are like this and the VRT is applied to almost all programs making it tough to find something that works for all the different use cases. If the researcher doesn't show real impact but selects the correct VRT category it will automatically be marked a P2, and from there the program owner has to explain to the researcher why they are going to get less money than expected even if the submission isn't P2 worthy.

I think a lower default rating (P3?) or a varies would help in this regard. If you can show an attack with increased damage and a higher likelihood (plenty of examples in the twitter thread) I'm happy to reward a P2 or a P1. If all you're doing is taking over some unused junk domain that nobody has used in years and not doing anything else--that really isn't on par with Stored XSS, a good SSRF, etc.

Semi-related, this is also an area where researchers could use some education to help identify when a sub-domain is actually susceptible to takeover, we get a reasonable number of findings in this category that don't end up being reproducible. Do some research into what the hosting provider requires to take over a domain at minimum, if its clearly some unused junk domain go ahead and take it over (some programs maybe ask permission first). That being said, I usually P5 $100 these kind of submissions if it leads to me taking removing the DNS entry for that domain. So maybe that's a point in favor of varies? or maybe its a point in favor of a second VRT category 🤷🏻‍♂️

[ryancblack]

@CharlieEriksen

You've hit the nail on the head. There is a balance with appropriate granularity and we strive to include variants that facilitate clear understanding of current classification and expected outcomes, e.g. sensitive, non-sensitive. As with minimum recommended priorities we have similar normalization opportunity in the taxonomy across VRT that aren't groundbreaking but rather equal application of methodology and precedent, supported by broad platform data observations.

@leifdreizler

It's great to have your perspective, especially from the program owner side!

I think an automatic P2 for something like this potentially hurts program owners that actually analyze the impact of submissions and try to do the right thing instead of blindly following the VRT. ... If the researcher doesn't show real impact but selects the correct VRT category it will automatically be marked a P2, and from there the program owner has to explain to the researcher why they are going to get less money than expected even if the submission isn't P2 worthy.

As mentioned in #180 and #181 this is one big reason why varies plays an important role. As far as a lower recommended minimum or varies we'll have hard data soon that will paint a very clear distinction in normal outcomes; the short is in questioning how often recommended minimums are upgraded, why, and what norms are reached for varies.

I'm happy to reward a P2 or a P1. If all you're doing is taking over some unused junk domain that nobody has used in years and not doing anything else--that really isn't on par with Stored XSS, a good SSRF, etc.

100% agreed and one point in the varies column, like with IDOR and other categories we've recognized require such latitude despite the potential outcome risk and additional discussion requirement the lack of explicit minimum recommendations may introduce.

To your point about exploit feasibility, we do not recommend proceeding with a takeover without permission but we do require the presentation of contextual information that:

• demonstrates it is actually possible and can be validated by the ASE
• provides an attacker's perspective on impact, e.g. what is the domain apparently used for? What general risk is involved in this vulnerability class itself?

Both of the above allow managed triage confirmation of program eligibility and technical validity at which point the conversation can be about actual impact in the context of architecture and the application(s). The outcome of that conversation should inform reward and remediation prioritization.

[jhaddix]

I LOVE the conversation going on here, and encourage more of it.

When this goes to vote though, I will likely vote to keep this entry P2. I did a spot analysis of about 50 of these today, none deserved lower than a P2 rating (similar to stored XSS). In each case when reviewing the comments, the customer also has little understanding of the impact of the bug. I think this baseline is correct for the vast majority of the subs we see.

"varies" VRT designations should be used sparingly IMO. The VRT is a baseline, if the impact of the baseline is off, there can be a conversation between the researcher and customer about adjustments, and further impact can be discussed.

Honestly though, most of my analysis is to protect the work and value of the bug to the researcher. On the macro level, many customers can't (or don't have time to) properly risk rate bugs. VRT baselines help in doing this.

[truemongo]

I did a spot analysis of about 50 of these today, none deserved lower than a P2 rating (similar to stored XSS).

In all those 50 cases was there a core asset sourcing Javascript from the subdomain that was taken over? Or were there high traffic links to that subdomain from core assets? If not, even though it is "technically" a stored XSS for anyone that visits the subdomain, I still find that is more equivalent to a Reflected XSS than a Stored one... After all, the value of a Stored XSS over a Reflected XSS is that the victim will "trip" on it without the attacker having to send them directly to it, right?... That logic sorta falls through for a domain that is totally off the beaten path...

And then you say yourself the clients often have little understanding of impact...

Honestly though, most of my analysis is to protect the work and value of the bug to the researcher. On the macro level, many customers can't (or don't have time to) properly risk rate bugs. VRT baselines help in doing this.

Yes, lets defend the "work and value of the bug" of the researcher who spends 5 minutes scanning for subdomain takeovers, and submits a template "subdomain takeover" report, with no concern for impact whatsoever, and no proof of impact. Perhaps does this for 10 different subdomains. And then lets feed it to the client as a P2, in accordance with VRT baseline, and anyway the clients don't have time to review it, so its OK. It is a great day for sure.

Sorry for the tone in the last paragraph but it seems to me that is exactly what is being said, and I absolutely cannot agree with it.

[leifdreizler]

My limited experience with these reports from our program is that this VRT category is plagued w/ lower quality reports. We have received 8 reports, all against relatively obscure subdomains that I don't think most users would encounter. 6 were against the same subdomain, which is actually in use and so far nobody has actually been able to hijack it, 1 was against firebase which requires a TXT record to validate the domain, and 1 may have been available for takeover.

In the last case the researcher said it was available for takeover, but required a CC payment to the provider. There was no attack scenarios or PoCs provided. We removed the DNS entry and rewarded at the P3 level. The researcher responded asking why it was a P3 to which I provided a reply of similar length as this post explaining our reasoning.

If the researcher or ASE can demonstrate additional impact, I'm always happy to assign a priority that exceeds the VRT baseline rating regardless of category.

[jhaddix]

Just so everyone knows how we're approaching this. We have a data project looking at all subs for this category and whether they were upgraded or downgraded, final priority, etc. This will be a big factor going into a vote that we have at the VRT council meeting on Friday (of which I am one vote of many). Thanks for all the constructive feedback all! Thanks for caring so much!

[fransr]

I just want to add some additional things to this so it's not forgotten about in the discussion. I totally agree that a report without a PoC should either not be rewarded at all, or maybe at the very minimum a P5 if the customer decides to remove the DNS-entry because of the report. I've seen the same issues as you're mentioning, reporting potential takeovers without any PoC, which should be as bad as reporting anything else without a PoC, really.

However, there are things that a subdomain takeover could lead to that a Stored XSS will not, and there are also different levels of takeovers that should be accounted for, like being able to open additional ports on the service the subdomain is pointing to. (like Elastic Beanstalk or a bunch of Azure-services or a takeover using AWS R53). In these cases you can also start receiving emails using @subdomain.example.com (since SMTP will try port 25 on A/CNAME if no MX exists). Having access to an email address of a subdomain of the domain opens up a bunch of potential exploitation vectors, "TicketTrick" (coined by Inti De Ceukelaire) being one example.

R53 and Azure DNS and similar DNS-services are special breeds of a "subdomain takeover" and more like a real DNS-hijack which gives you a bunch of more options in your exploitation such as MX-records and allowing DNS-validations for other services.

Having email or DNS access, but also in some cases just having the ability to place files on the domain will also enable you to verify the subdomain for SSL-issuing (Not only for Let's Encrypt, other CAs are using similar ACME-based verification methods). Issuing a cert might trigger alerts, but could also potentially lead to someone having SSL-certs for a domain which later on starts to be used. I've seen a lot of cases where services demands you to point the domain to the service before you can claim it (which is really bad). This gives the attacker the possibility to claim it before, issue a cert, leave the domain again and then have a working cert for a domain that will be used. (Yes I do understand that only having a valid SSL-cert doesn't do anything, unless you can use it in combination with other things, or affect the company's threat model in some way).

Also, depending on the scoping of your cookies (as mentioned before) a takeover could also leak httpOnly / Secure cookies depending on the service (Heroku and CloudFront being two where you're able to attach a working cert that will be served on the domain). An exploitation with a stored XSS might still be able to utilize those cookies (by making ajax-calls etc) but there's a difference being able to utilize the cookies separately of the current user's interaction imho.

Regarding "unless it happens to be an important subdomain with considerable organic traffic" I agree in some way, but you could also argue that the organic traffic could also be generated by the attacker by Google or Facebook ads, depending on the ad service there might be verification methods involved but those methods would most likely be possible to go through due to you having access of the subdomain anyway.

A bit of a rant, but I think it's important to identify and know of the different scenarios and exploitations that could be leveraged. I do still believe that without any PoC and an explanation of what could potentially be done the triage team should be very sceptical about reports regarding takeovers.

[jhaddix]

@ryancblack can answer in more detail here but these subs don't get triaged without taking over the domain at Bugcrowd (unless the customer asks the researcher NOT to). You can't just submit a dangling CNAME and get paid for that. PoC , always.

[truemongo]

@fransr

Personally, I really appreciate you coming in on this, and I dont read it as a "bit of a rant", there are few people with more knowledge about the potential impacts of subdomain takeovers than you - this is all important information, particularly the impact scenarios you presented and which I missed in the first post (I knew I'd probably miss quite a few).

I think of particular importance to the discussion is:

I do still believe that without any PoC and an explanation of what could potentially be done the triage team should be very sceptical about reports regarding takeovers.

I think a lot of the discussion here is gonna revolve around what should be considered a PoC for these kinds of submissions. Is it enough to take over the domain and provide a list of things that could "potentially be done" (which I think we've established, in a lot of cases it depends on the subdomain itself, its use, as well as the service to which a CNAME points...). Or should there be a requirement for bit more in terms of PoC from the researcher, to show what can be done in each particular case?

Basically I'm asking whether when you say "an explanation of what could potentially be done", do you mean for the particular case which is being reported, or a generic list of stuff that does not necessarily apply to the submission/affected subdomain?

Finally - and this is probably related to the previous question - do you feel there should be a set priority for this bug class? If so, would P2 be appropriate, or not?

[yesnet0]

I wanted to chime in here and thank everyone for contributing to help make VRT better. Keep it rolling... As @jhaddix and @ryancblack said we're going through data to help us work out the best way to modify or add to this class. There are additional conversations going on about how to ensure that everyone understands the purpose of VRT.

[fransr]

@truemongo

Good discussion! Had a hard time sorting out my brain dumping below, sorry again for the wall-of-text.

This vulnerability type has its variants, as mentioned before (which vuln type doesn't tho.. :). This complicates a straight answer to your question I think. There is still a big lack of knowledge around this vulnerability type, and as you probably know I do my share to try to change that by speaking publicly, blogging etc about the core idea, the mutations and the issues that comes with it and the many different ways you can utilise the vulnerability. The problem with this is that a lot of companies still needs understanding on why it's bad and the potential scenarios affecting them.

I've been experiencing programs that directly understands the impact, or know they have unknown unknowns regarding the total impact of a malicious party having access to a subdomain, being email, web, cookies, dns et al. Those programs:

• have already been introduced by a proper PoC that is business specific to their needs, like showing that their SSO is scoped using *.domain.com or similar. Arne Swinnen did a great report a few years back to Uber showing this.
• already know that their threat model is affected by someone having a subdomain of theirs. They understand that a bunch of password managers still autofill forms for subdomains of the same service, they have trained people to always verify the domain name when they sign in, or they become very uncomfortable knowing that a malicious party could potentially run something on a domain of theirs without any WAF or monitoring catching it being used maliciously.

I've also come across programs that either doesn't think it's that bad or believe that if it doesn't affect their application they are fine. In these cases I try my best to come up with scenarios that affects them specifically, in some cases this challenge is the most fun part. In some cases it doesn't really make sense (I've had cases like pay.domain.com and secure.domain.com for example, which I personally don't think should need an explanation of why it's bad that it's controlled by someone else than the company itself).

Talking about a regular takeover, I personally think that the core issue that makes this a troubling vulnerability is that there's no way for a regular user to verify that the domain is not in fact controlled by the company. Even a tech-savy user would not be able to tell if the domain was hijacked or not.

If EV-SSL is your only indication that you're on a legit service owned by the company, this has also proven to be broken, one example being the trailing dot story a while back. Another example is Heroku sharing wildcard SSL-certs across all apps with domains matching the wildcard cert, having an wildcard SSL uploaded there would serve the hijacked domain with the same cert as the legit services also running on Heroku by the same company.

There's also an addition of being able to fool employees of the company itself, which are most likely trained to make sure they are signing into the domain of their own company. The argument regarding "weird subdomains" is also interesting in that aspect. Since the DNS-record is there, there is most likely already an internal culture of -using- "weird" subdomains already, which probably explains why the DNS record was there in the first place.

It also comes down to what the VRT should solve. If it should be used to easier define the impact of the vulnerability, "subdomain takeover" should maybe have different categories or classifications. I would probably rank them like this:

1. Having access to a subdomain delegation and its DNS (enables SMTP, WEB, DNS-validations and arbitrary DNS-records for various purposes)
2. Being able to open additional ports (enables SMTP and WEB (httpOnly+secure cookies))
3. Being able to put content on the site incl HTTPS possible (WEB + Secure-cookies (if scoped to *.domain.com)) (Should also most likely not need the researcher to issue a cert, you don't want what Uber got back in Oct 2016
4. Being able to put content on web, but HTTPS not possible (A regular AWS S3-bucket takeover without any additional proxy (Cloudflare, Fastly) in between for example)

Other mutations exists, look at the issues with MX-services (SendGrid, Mailgun etc) having issues a while back. That enabled only receiving emails but it was still very very bad for a lot of companies. Also, another example not being applicable to the cases above is Unbounce. It was vulnerable before, and is a wysiwyg-editor for pages on the domain, this never enabled you to steal any httpOnly cookies for example, since you only controlled JS/HTML on the domain).

However, due to the vast amount of services being affected (I think we're probably close to 200 different cloud services not doing proper domain validation) it will be hard for the triage-team to validate the difference between 3 and 4 without the researcher issuing a cert, which is not optimal at all.

(Btw, an addition this this: never put PoCs directly on the domain itself)

I don't think I really gave you a proper answer above, I tried mostly to explain that it's a lot of different things that could be affected depending on what service is being used for the takeover. A part from the cases above we then have business specific things, like redirect- or JS-regexes written by the company that could enable business specific bypasses as you mentioned in your first post.

[jhaddix]

Hey All,

We looked into the data here. 72% of these submissions were kept as-is, while 28% were downgraded. Some are downgraded for impact and some get downgraded because they are not in or out of scope explicitly. With this in mind (and a consensus from the whole ASE team) we decided on the following:

P2 - Server Security Misconfiguration   >  Misconfigured DNS  >  Subdomain Takeover > High Impact (like Stored XSS, CORS Cookie sharing, high traffic subdomain)

and

P3 - Server Security Misconfiguration  >  Misconfigured DNS >  Subdomain Takeover > Medium Impact (like Reflected XSS, No CORS Cookie sharing, low traffic subdomain)

We really appreciate the feedback and hope to hear more in the future! Also be on the lookout for communication on leaderboard changes next week!

[plr0man]

While in line with the above proposed revision the team decided to simplify the entry names. The idea being that just any valid subdomain takeover without further details outlining its criticality would be accepted as P3: P3 - Server Security Misconfiguration > Misconfigured DNS > Basic Subdomain Takeover P2 - Server Security Misconfiguration > Misconfigured DNS > High Impact Subdomain Takeover

We appreciate all of the great feedback provided here and will have our ASEs apply lessons learned from it when applying the appropriate severity rating

[melardev]

Sorry for reviving this old thread again, I want to discuss a little bit the fact of some reports being triaged as P3. Let's take as an example a subdomain takeover report triaged as P3, the takeover could deploy server-side code and hence, steal httpOnly cookies and any headers, the triager states it is "Basic Subdomain Takeover" because we can not prove High traffic on that subdomain, I find very weak this argument because a stored XSS is usually getting P2, so why a takeover should get less? a subdomain takeover is wildcard stored XSS, we can serve the malicious at multiple endpoints.

• First, if only a single user(or employee) accesses the website the stored XSS is triggered, so here we have a stored XSS(P2) and not an R-XSS.
• Second: Let's assume there is no traffic on the taken over subdomain, to exploit this we should trick the user to visit the hijacked subdomain, if we do so, it seems like it is an R-XSS, except it is not, with a subdomain takeover where you can read the HTTP headers the impact is bigger than an R-XSS even if both require user interaction, it is not the same being able to steal sensitive cookies with no restriction than having them.
• Third: With a subdomain takeover where we can deploy server-side code or configure wildcard routes, we can serve a malicious XSS anywhere in that subdomain(https://example.com/*).
• Fourth: A subdomain takeover has extra points on impact, it can be used to host inappropriate content which may impact the brand's reputation, which an R-XSS can't. Owning a subdomain may also mean other impact points such as email, etc.

I think this requires a little bit more explanation, leaving it vague means having some misunderstandings and either of both sides unhappy. I don't think a subdomain takeover can be given the same as an R-XSS, I think, we should at least specify that a subdomain takeover that is able to access the whole HTTP request should never be triaged as P3, it should be P2, and let the company downgrade if they really don't agree.

PD: Anything in life is "it depends", so please do not bring edge cases to classify the norm, I am talking about the most likely scenarios and hence should be reflected in the VRT, I agree a subdomain takeover severity depends and can range from P1 to P5(for example the company migrated to another domain, the old domain is still claimed but unused) in an edge case, we all know that, but we are talking about what we see the most, which is what the VRT is about.

[hakluke]

Hi there @melardev,

Thanks for your detailed comment, we discussed this at length in our weekly VRT council. Ultimately we decided to leave the ratings as is (low-impact takeover at P3, high-impact at P2). I want to address each of your points one by one.

the takeover could deploy server-side code and hence, steal httpOnly cookies and any headers, the triager states it is "Basic Subdomain Takeover" because we can not prove High traffic on that subdomain, I find very weak this argument because a stored XSS is usually getting P2, so why a takeover should get less? a subdomain takeover is wildcard stored XSS, we can serve the malicious at multiple endpoints.

In many subdomain takeover cases, there can not be any server-side code deployed. In cases where it can be deployed, the code is not deployed on the company servers, it is deployed on the attacker's servers, which has significantly less impact. Also in most cases, the attacker is not able to steal any cookies - although if they were able to steal session tokens, this would be considered a high impact takeover and marked as P2.

First, if only a single user(or employee) accesses the website the stored XSS is triggered, so here we have a stored XSS(P2) and not an R-XSS.

In this case, most likely the XSS can not be used to do anything meaningful, because it is not on the same subdomain as any important application which would utilise authentication tokens. By default, SOP would deny any XSS on this subdomain from interacting with other important applications/subdomains. If this is not the case because of a misconfigured CORS policy, and the takeover could be utilised to impact another application, then the takeover may be considered as a high-impact takeover, and receive P2 priority.

Second: Let's assume there is no traffic on the taken over subdomain, to exploit this we should trick the user to visit the hijacked subdomain, if we do so, it seems like it is an R-XSS, except it is not, with a subdomain takeover where you can read the HTTP headers the impact is bigger than an R-XSS even if both require user interaction, it is not the same being able to steal sensitive cookies with no restriction than having them.

As above, even though we can execute JavaScript on this domain, in most cases we can't really do anything with it unless there is some other misconfiguration, like a bad CORS policy, in which case the researcher could provide a PoC and it would be considered P2.

Third: With a subdomain takeover where we can deploy server-side code or configure wildcard routes, we can serve a malicious XSS anywhere in that subdomain(https://example.com/*).

It really doesn't matter where the XSS payload is within the code you deploy, it will still have the same impact as the cases above.

Fourth: A subdomain takeover has extra points on impact, it can be used to host inappropriate content which may impact the brand's reputation, which an R-XSS can't. Owning a subdomain may also mean other impact points such as email, etc.

The ability to host inappropriate content on a subdomain might be considered a P2 if it is on an especially prominent subdomain, or one that is still receiving significant traffic. For example, if you could take over some key domains on a prominent root domain like www.example.com and blog.example.com, these may be considered high-impact depending on the circumstance. If you were able to take over 14.staging.dev-environment.jenkins.example.com and host content there, it really wouldn't affect the company much.

TL;DR: Subdomain takeovers vary greatly in impact, and I think it's important for the VRT to reflect that. I think keeping two different ratings for subdomain takeovers it the best way to go because it allows the VRT more accuracy, and also doesn't set unrealistic researcher expectations.

[melardev]

@hakluke Hi and thanks for the detailed response and discussing this issue internally. I know you won't discuss it anymore because you just did and it is fine, but let me react with three points:

• I may agree in some points, but, it still is more than a reflected XSS, even more than a stored XSS, but not less, most stored XSS are P2, regardless of the subdomain, a subdomain takeover is somewhat more than that, or the least, deserves the same.
• About:

  especially prominent subdomain

yes, but unfortunately this is not easy to prove for the reporter nor for the triager, and in my experience in multiple platforms, companies don't help to clarify this either, they take the report as given by the triager, sometimes two very similar bugs are forwarded with different severity, because the triagers are different, and the company did not change the severity to make them the same, they just took it as such.

• About:

  If you were able to take over 14.staging.dev-environment.jenkins.example.com and host content there, it really wouldn't affect the company much.

Well, maybe yes, but if you host, for example, a racist content in these times on a company's subdomain, and you spread the word across the media you may end up with a company's building on flames in a matter of minutes even if the hostname is not that "nice" (it belongs to the company anyway) ... and the spokesperson rushing to appear on the media to explain what happened, these two drastic situations would not happen for a P3 issue such as an XSS.

I understand your side of having to make the VRT flexible, though, but it just seems not right to me sometimes when I get a report treated the same as if it would for a r-XSS.