Suggestions for P3

[DarkieDuck]

Some P3 reports that I think we should take a closer look at.

[P3] Server Security Misconfiguration No Rate Limiting on Form Login Suggest to downgrade this one to a P4 at best perhaps even a P5 Its more of a best practice than a actual vulnerability to begin with. How did this ever make it up all the way to P3?

[P3] Server Security Misconfiguration Mail Server Misconfiguration Missing SPF on Email Domain Suggest to downgrade this one to a P4 SPF is something we would like to see ofcourse but will missing SPF header really have a P3 impact?

[P3] Server Security Misconfiguration Mail Server Misconfiguration Email Spoofable Via Third-Party API Misconfiguration Im not even sure why this is a thing,can someone help me on this?

[P3] Broken Authentication and Session Management Weak Login Function Over HTTP Suggest to downgrade this one to a P4. Yes login over HTTP isnt something we want but you still gonna need some form of MiTM to gather actual data so by itself this bug isnt P3 worthy at all. Modern browsers are starting to adept to this and actually show warning messages when you login over HTTP

[P3] Broken Authentication and Session Management Session Fixation Suggest to downgrade this one to a P4 or maybe P5 even. This is again something we would like to see fixed but its far from a P3 based on attack vectors. Should not be accepted as a valid bug without atleast one endpoint showing the possibilty to abuse this. (seems rare)

[P3] Application-Level Denial-of-Service (DoS) High Impact and/or Medium Difficulty What would be considered High/Medium impact?

[truemongo]

I agree and would love to see some discussion on this from the Bugcrowd team as well. The only one I'm not sure about is the DoS one, which might be a fair P3 depending on how Impact/Difficulty is measured. But things like "Weak Login Function Over HTTP" and "No Rate Limiting on Form Login" are essentially best practices (maybe Bugcrowd can check what % of these are actually resolved by their customers?...). These being P3 appears to throw programs way off balance, especially on programs with a wide scope, where it is not unusual for there to be 100 sites "vulnerable" to this, leading to 200 submissions just from these two entries.

[jstnkndy]

I agree on all points exception for the session fixation, I think that should be moved to a P4, not a P5.

[jhaddix]

Disclaimer: I no longer run the SecOps group and do not have any role in the final decisions regarding the VRT.

[P3] Server Security Misconfiguration - No Rate Limiting on Form - Login

I could see P4 here.

[P3] Server Security Misconfiguration - Mail Server Misconfiguration - Missing SPF on Email Domain

There is a significant risk to an organization that is easily phished via this misconfiguration. Not sure about a downgrade here.

[P3] Server Security Misconfiguration - Mail Server Misconfiguration - Email Spoofable Via Third-Party API Misconfiguration

I'll have to do some research on this one again.

[P3] Broken Authentication and Session Management - Weak Login Function - Over HTTP

Sorry, I disagree with all of you here. Unencrypted logins are the bane of the internet. Finding unencrypted links and prioritizing using TLS/HTTPS is an important thing to do, not just for an organization, but for the internet. I think you are having an emotional reaction to how hard these bugs are to find and the point value of them, not the impact on an organization. Deprioritizing this one sounds dangerous to me. You would never accept using a bank that served login over HTTP, and if you were a company in that unfortunate position (maybe in a more obscure location than the main login) you'd want to know about it and highly prioritize it.

[P3] Broken Authentication and Session Management - Session Fixation

I'll have to do some research on our exact definition here but in general, I'd think any session that is susceptible to bruteforce is a very tangible bug. P3 is the minimum for something that could have the same impact as an IDOR, maybe even more massive at scale.

[P3] Application-Level Denial-of-Service (DoS) - High Impact and/or Medium Difficulty

Again, I'll have to do some research on our exact definition here.

[jstnkndy]

Broken Authentication and Session Management - Weak Login Function - Over HTTP requires an attacker to be in a privileged position. That's the reason I think P4 makes more sense, not due to the ease of finding it.

Broken Authentication and Session Management - Session Fixation has nothing to do with bruteforce. It requires an attack to provide a link that an attack clicks on that sets the victim's session id to something the attacker knows; then, if the session id is not updated upon login, the attacker is now authenticated because they are the ones that came up with the session id.

[jhaddix]

Broken Authentication and Session Management - Weak Login Function - Over HTTP

I hear and acknowledge your opinion. Still, don't know if I agree with a P4 rating.

Broken Authentication and Session Management - Session Fixation

You are correct, I was confusing session vulnerabilities here. Please, educate me more if I'm wrong here. This, to me, seems to lie in the same impact range as a Reflected XSS. Providing a link is needed as far as exploit delivery and I would posit it's even more dangerous because the vulnerability resides in the application's mishandling of state.

[jstnkndy]

It is only the same as RXSS in that you would end up with an account takeover; however, XSS is much more dangerous as there is a lot more you can do with XSS once you hook someone's browser.

[jhaddix]

Great point. Does that still merit a downgrade though? "Account takeover via Link" is sometimes accepted as a P1 (combinations of RXSS, CSRF, and lack of best practices on an account edit page)

[truemongo]

Regarding "Broken Authentication and Session Management - Weak Login Function - Over HTTP", I'd again like to see stats from Bugcrowd on what % of these have been marked as "Resolved". I think in the majority of cases, it is something well known to the client (its enough to browse to these sites in Chrome and there will be a warning!)... And if it is known and not patched it is probably accepted risk / best practice.

[jhaddix]

FYI thanks so much for being passionate and helpful with the VRT. Love all the discussion here!

Broken Authentication and Session Management - Weak Login Function - Over HTTP

While that would be a good measure to have there are multiple ways a client uses the "Resolved" state. One client may use it in the case of a bug has actually been fixed. Another, which you pointed out, could have accepted the risk and considered it resolved but unfixed. We don't an over abundance of control there.

I would be interested in digging into:

I think in the majority of cases, it is something well known to the client

Although I don't know quite how atm. Reason being is I think most of the ones I hear about (and have legitimately brought value to the customer) are targets they didn't know they had or admin panels on domains they didn't think had any login or PII forms. I would imagine (but cannot confirm) that if your business had decided on HTTP only then they would just edit the brief and remove that VRT category from the scope.

Looking at it from a different angle, this entry in the VRT currently seems to match what most other vuln rating taxonomies give it:

CVSS v3 Base Score: 5.3 Medium CVSS v2 Base Score: 5.0 MEDIUM

From a sample CVE like this Unencrypted-Login-Request

[jstnkndy]

Should we add an additional entry to the VRT for any website that operates over HTTP in the first place due to the potential of cookies being sent over in cleartext?

[truemongo]

Thanks @jhaddix, it is great to be able to discuss the VRT with the team! I think a major concern (that has been brought up before elsewhere) regarding some of these entries, is the potential for so called "kudos padding", which tend to make the platform/ranking unbalanced. This is particularly of concern on wide scope kudos-only programs. I see why the "Resolved" % might not be a good measure, due to the reasons you stated; could we instead see how many of these (for example just "Weak Login Function - Over HTTP" and "No Rate Limiting on Form") have been awarded an actual money reward by the customer (so, not including kudos-only rewards)?

[jhaddix]

A little bit off topic (apologies). Regardless of that Weak Login Function - Over HTTP ends up as, we have seen a number of findings for unencrypted network protocols (FTP, TELNET, rlogin, ++). Are these the same in your views? (asking you all)

[jstnkndy]

Yep, because an attacker would still need to be in a privileged position.

[truemongo]

I think they're similar in that they need an attacker in a position that allows MITM. In 99% of cases, these are going to be either gov/ISP attackers, or an attacker exploiting local proximity through an insecure Wi-Fi. (unless I miss some other case?) For things like FTP/telnet/etc, it seems even less likely, compared to HTTP, that someone would be using those from a coffeeshop or so, where its "easy" to MITM. So, I'd likely see all these "unencrypted things" as P4 (at most). I'd also point out to you that SSL attacks are currently P5.

[csimas1]

Hey guys, thanks for the great discussion. Here are some of my thoughts on three of the categories. I’m unsure how to best score the other three as I haven’t dealt with them much at Bugcrowd.

[P3] Server Security Misconfiguration No Rate Limiting on Form Login I do see a case for lowering this to P4 give the reasoning provided. However I think there might be more to this that is being overlooked. It may still warrant a downgrade, but this should be considered in the discussion.

The lack of rate limiting is a concern for websites that have a weak password policy. We score P5 - Insufficient Security Configurability > Weak Password Policy because by itself it doesn’t warrant a bounty. However combined with No Rate Limiting on Login it becomes a much bigger issue. I think in cases when customers have additional protections in place or feel their password policy is sufficient we can easily justify a downgrade to P4, maybe even P5 (I’m not sure how common this is).

I’m leaning towards keeping this as P3 but I’d love to hear some counterpoints from the researcher perspective :-)

[P3] Broken Authentication and Session Management Weak Login Function Over HTTP I agree with Haddix on this one. Tl;dr: It’s a serious enough issue to warrant P3.

[P3] Broken Authentication and Session Management Session Fixation I feel like the impact here (account takeover) and attack vector (similar to RXSS) would still warrant a P3. While yes RXSS is worse because an attacker could do more, I don’t think that should reduce the impact of this one. But again I'd love to hear some counterpoints.

[plr0man]

These being P3 appears to throw programs way off balance, especially on programs with a wide scope, where it is not unusual for there to be 100 sites "vulnerable" to this, leading to 200 submissions just from these two entries.

Server Security Misconfiguration > No Rate Limiting on Form Is in fact a commonly reported class of issues, but most of those are the P4 variants, like email triggering etc. P3 – Broken Authentication and Session Management > Weak Login Function > Over HTTP seems to be a higher source of P3s when compared to its rate limiting counterpart

Should we add an additional entry to the VRT for any website that operates over HTTP in the first place due to the potential of cookies being sent over in cleartext?

Session cookie sent over HTTP would be a nice one to have. Fortunately the Secure cookie flag variant P4 – Server Security Misconfiguration > Missing Secure or HTTPOnly Cookie Flag > Session Token is doing a good job already, but that doesn't cover the HTTP authentication scheme tokens. The potential priority would be up for discussion, but I'm sure we all agree that passwords are more valuable than session tokens.

Thanks @jhaddix, it is great to be able to discuss the VRT with the team!

:heart:

could we instead see how many of these (for example just "Weak Login Function - Over HTTP" and "No Rate Limiting on Form") have been awarded an actual money reward by the customer (so, not including kudos-only rewards)?

I won't be able to provide an accurate number, but from what I can see I can attest that those are being taken seriously and rewarded at P3. We might occasionally see a downgrade because of the target being a staging environment.

P3 – Server Security Misconfiguration > Mail Server Misconfiguration > Email Spoofable Via Third-Party API Misconfiguration This one would be for cases where the attacker could spoof emails from the vendor's servers due to some misconfiguration. We could definitely work on a better name if this one is confusing.

[P3] Application-Level Denial-of-Service (DoS) High Impact and/or Medium Difficulty What would be considered High/Medium impact?

e.g being able to kill a service vs. the entire application. I personally wouldn't be opposed to removing the variants in favor of context based in this case.

Thanks for being vocal about the points economy, that has been our concern and is being discussed on a higher level. I would be reluctant for this problem to be a factor in assessing severity ratings in the VRT. Out of the entries mentioned in the original comment, I think the team can revisit the ratings on the entries below. The other ones look solid (please let me know if you need any further clarification on those). P3 – Broken Authentication and Session Management > Weak Login Function > Over HTTP P3 - Server Security Misconfiguration > No Rate Limiting on Form > Login P3 – Server Security Misconfiguration > Mail Server Misconfiguration > Missing SPF on Email Domain

[plr0man]

Quick update. We've discussed the 3 entries ^above and decided to downgrade Server Security Misconfiguration > No Rate Limiting on Form > Login to P4. At the same time it's worth noting that if this entry is chained with Insufficient Security Configurability > No Password Policy that would result in a P3 rating.

It was an unanimous decision to keep Broken Authentication and Session Management > Weak Login Function > Over HTTP as P3. To add more context to what's already been said, widespread wifi makes it an opportunistic type of attack, meaning that the attacker doesn't necessarily target a specific victim or a host. At the same time credentials have a wide scope value (people tend to reuse the same passwords). We would consider a downgrade if the browser warnings were more efficient.

Server Security Misconfiguration > Mail Server Misconfiguration > Missing SPF on Email Domain To add to what's already been discussed here, there's room to downgrade depending on major email providers, especially once/if they stop accepting emails originating from domains lacking DMARC and SPF.

While we're at it, it would be awesome if you guys could also look into potential upgrades and downgrades in other entries including P4/P5 so we can cross-reference those.

[jhaddix]

Everyone on this thread also knows there is another conversation regarding the kudos economy (a separate topic from these VRT entries priorities). Should we close this one out?

[ryancblack]

@jhaddix In my view, yes. It is important we draw a clear distinction between point value and security impact for the purpose of default taxonomy prioritization. Also referenced here.