Privilidge escalations & language.

[subrosaassociates]

Hey guys, just another point arount terminology

there have been cases and current penting cases where a program has web/api/thick client and the scope states that they care for privilidge escalations (by name)

yet thick client privescs are usually a p4 ... like compromising the desktop is less important (via the app) than a web privesc

they have different risks and different results I get that, but I feel like Bugcrowd is leading customers to a lower score by default on thick clients

if you care about privescs and arent mentioning what specifically and where, we as hunters will assume all privescs as web privescs are pretty naughty, but in my opinion client side compromise (in context) is alot worse.

so I ask, local privilidge escalations should be set higher. because they are higher.

fight me.

x

[plr0man]

As promised we've been investigating the potential for priority adjustments here, and the results are looking promising. I was actually going to file myself today, so looks like this one is going be no contest;)

What is being proposed: Client-Side Injection -> Binary Planting -> No Privilege Escalation P5 Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P4 (new one) Client-Side Injection -> Binary Planting -> Default Folder Privilege Escalation P3 (upgrade from P4)

Let us know what you think and if this can be improved. All community feedback is appreciated.

[subrosaassociates]

Client-Side Injection -> Binary Planting -> No Privilege Escalation P5 well, p5 for a persistant foothold is bad in my eyes you're getting userlevel privilidge - and that might well be admin dependent on the user/environment - back to the previous chat about worth and effort, is it worth me telling you about for a p5 ? nope, is it worth a CVE and a blogpost Yup.

Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P4 (new one)
it's not binary planting, it's permissions. but agree on the p4

Client-Side Injection -> Binary Planting -> Default Folder Privilege Escalation P3 (upgrade from P4 P3 better than a p4!

now, if a customer specifically highlights they are interested in privilidge escalations, shouldnt that add more weight to the default stance on how they are measured? otherwise ... it's all the same and we can ignore it/ pay little attention to what they would like us to focus on ?

Thanks for the rapid reply !

[plr0man]

Client-Side Injection -> Binary Planting -> No Privilege Escalation P5 well, p5 for a persistant foothold is bad in my eyes you're getting userlevel privilidge

• Local attacker: In this case the attacker already has userlevel privilege so there's no gain if there's no privilege escalation, correct me if I'm misunderstanding anything
• Remote attacker: If there's no privilege escalation, the same can be accomplished with regular malware. This boils down to user awareness of what is being downloaded onto their machines. We have extensively discussed this scenario in one of our recent Issues

Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P4 (new one) it's not binary planting, it's permissions. but agree on the p4

Do you have any specific classification in mind that could separate permissions and at the same time allow us for this level of granularity in case of binary planting? To give some context, those variants are for a common scenario of being able to choose an alternative folder (with broader permissions) during software installation.

now, if a customer specifically highlights they are interested in privilidge escalations, shouldnt that add more weight to the default stance on how they are measured? otherwise ... it's all the same and we can ignore it/ pay little attention to what they would like us to focus on ?

Our customers have the freedom to specify that on the brief, which happens quite often. We are working on some process improvements that will help all of our customers better understand what VRT entries deserve closer look/revaluation for that purpose

[subrosaassociates]

Client-Side Injection -> Binary Planting -> No Privilege Escalation P5 well, p5 for a persistant foothold is bad in my eyes you're getting userlevel privilidge

Local attacker: In this case the attacker already has userlevel privilege so there's no gain if there's no privilege escalation, correct me if I'm misunderstanding anything

==

• of course, what you're missing is access to current users data, profile, privilidges and access, and also a perfect pivot point to search for other oppertunities *

think of it this way, If $application facilitates persistant userlevel compromise, is that useful to an attacker ? ==

Remote attacker: If there's no privilege escalation,the sa me can be accomplished with regular malware. This boils down to user awareness of what is being downloaded onto their machines. We have extensively discussed this scenario in one of our recent Issues

== same thoughts reguarding user level access. ==

Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P4 (new one) it's not binary planting, it's permissions. but agree on the p4

Do you have any specific classification in mind that could separate permissions and at the same time allow us for this level of granularity in case of binary planting? To give some context, those variants are for a common scenario of being able to choose an alternative folder (with broader permissions) during software installation.

== Insecure Permissions! the difference being, ability to read,write,delete files that should be protected

the difference between them is DLL / Binary planting is usually creating files that arent there, that are being requested, insecure permissions can overwrite what is there patch, delete steal (configs) whatever, it's a different bug. I've sent many of this to you guys and it's something that has been difficult to understand from the BC bug markers, but can share a draft Blog post OTR for you to share amongst ya'll

in the context of thick clients it's a high if the data is important, and a medium if it's more about being a foothold but everything looses it's confidentiallity, availability and integrity. what more do you want !

you could put it under insecure configuration, but its a permission issue, oh and aside from all that ^ obviously you have the ability to plant files too but you wouldnt need to)

==

now, if a customer specifically highlights they are interested in privilidge escalations, shouldnt that add more weight to the default stance on how they are measured? otherwise ... it's all the same and we can ignore it/ pay little attention to what they would like us to focus on ?

Our customers have the freedom to specify that on the brief, which happens quite often. We are working on some process improvements that will help all of our customers better understand what VRT entries deserve closer look/revaluation for that purpose

== agree, we are paid on what people want to pay, as apposed to what they might be worth, sometimes more sometimes less it is what it is. ==

apologies for the format of this, i'm at offensivecon in berlin and I dont have my 2fa token with me - email ftw

On Sat, Feb 17, 2018 at 8:40 PM, PLRoman notifications@github.com wrote:

Client-Side Injection -> Binary Planting -> No Privilege Escalation P5 well, p5 for a persistant foothold is bad in my eyes you're getting userlevel privilidge

• Local attacker: In this case the attacker already has userlevel privilege so there's no gain if there's no privilege escalation, correct me if I'm misunderstanding anything
• Remote attacker: If there's no privilege escalation, the same can be accomplished with regular malware. This boils down to user awareness of what is being downloaded onto their machines. We have extensively discussed this scenario in one of our recent Issues

Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P4 (new one) it's not binary planting, it's permissions. but agree on the p4

Do you have any specific classification in mind that could separate permissions and at the same time allow us for this level of granularity in case of binary planting? To give some context, those variants are for a common scenario of being able to choose an alternative folder (with broader permissions) during software installation.

now, if a customer specifically highlights they are interested in privilidge escalations, shouldnt that add more weight to the default stance on how they are measured? otherwise ... it's all the same and we can ignore it/ pay little attention to what they would like us to focus on ?

Our customers have the freedom to specify that on the brief, which happens quite often. We are working on some process improvements that will help all of our customers better understand what VRT entries deserve closer look/revaluation for that purpose

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bugcrowd/vulnerability-rating-taxonomy/issues/131#issuecomment-366466155, or mute the thread https://github.com/notifications/unsubscribe-auth/AhPxIGmVgniVzDaMBYd2cPMD55fHS6TWks5tVytKgaJpZM4SFTTM .

[plr0man]

Local attacker: In this case the attacker already has userlevel privilege so there's no gain if there's no privilege escalation, correct me if I'm misunderstanding anything

of course, what you're missing is access to current users data, profile, privilidges and access, and also a perfect pivot point to search for other oppertunities think of it this way, If $application facilitates persistant userlevel compromise, is that useful to an attacker ?

Just to make sure we're on the same page. In case of local attacker we are talking about someone who already has local OS access, meaning they already have a low priv account, correct?

Do you have any specific classification in mind that could separate permissions and at the same time allow us for this level of granularity in case of binary planting? To give some context, those variants are for a common scenario of being able to choose an alternative folder (with broader permissions) during software installation.

Insecure Permissions! the difference being, ability to read,write,delete files that should be protected

What I was trying to say is that it would be great if you had a moment to propose something specific that we could implement (down to variants classification). I understand that you are mainly concerned with folder permissions as a broader problem, but would it possible to retain the folder-based level of granularity in case of binary planting? In other words, is the classification that you have in mind supposed to efficiently solve both?

I've sent many of this to you guys and it's something that has been difficult to understand from the BC bug markers, but can share a draft Blog post OTR for you to share amongst ya'll

Yes, please share, I would love to see it:)

[subrosaassociates]

I'll put something together for you to thrash out if you like... i'll need a day or two, do you want me to put it on here or ping it to support@bc :)

[plr0man]

As long as the content is meant for the general public please share here, otherwise support sounds good. Thanks!

[ryancblack]

@subrosaassociates,

First, thank you for adding your voice and the extended dialog. We really appreciate you being both engaged and invested in the VRT! It's been a bit of a sprint lately so I also appreciate your patience with additional response here.

I've taken a look over your blog and you make some great points about the known risks of non-default location installations. As for typical bounty eligibility, and VRT itself, the context of such a risk would normally see this non-rewardable unless specifically included by the program owner. The issue is chiefly with the OS and user decisions on installation location, absent a requirement for assembly signing/verification.

What does this mean for VRT (in my view)?

Client-Side Injection -> Binary Planting -> Privilege Escalation

This entry would apply and have appropriate purpose in the VRT if:

• there is additional context beyond a privileged user installing in a non-default location where default filesystem permissions did not prevent the addition of user controlled binararies called by the application

and

• the application was not properly verifying strong name signatures without skipping enabled (reference)

VRT operations on a principle of default, broadly applicable severity. That is, we'd much rather upgrade a submission based upon clear technical context, brief guidance, or exceptional justification.

As a consequence of the above I am of the opinion that we should only have a base category of:

Client-Side Injection -> Binary Planting no variant, and "Varies" priority.

We try very hard to avoid "Varies" entries however as with Broken Authentication and Session Management -> Privilege Escalation or IDOR, context is truly key. I feel the same applies to this issue until binary signing is an industry norm and typically-enforced OS requirement - we're a long way from that.

In conclusion, I believe our best action is to remove variants that set the wrong expectation. The onus is on the report recipient to interpret priority in the context of the subject and business risk. The counterpoint to this is something you've certainly highlighted, if a vulnerability report appears to not be worth the non-disclosure requirement would we indirectly cause a lack of submission for these?

I feel the answer to this is to ensure "varies" is clearly understood by our community, both the intent of these limited entries and typical requirements to see them assigned P1 - P4. Additionally, the conversations we have with our customers when qualifying a bounty brief suited for their program. It is in these conversations elevations of priority are done to account for their specific application details and security requirements.

I'll be looking for additional comment from our community and internal teams prior to any action on the taxonomy. We have a large variety of informed and passionate opinions on issues like these which I view as a strength of the project. Please let me know your thoughts on the above.

[ryancblack]

After involved additional discussion I have a small modification to the above opinion:

Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P5

This is Informational, by default, based on an installation decision by the user and the current industry norms around signing and verification.

Client-Side Injection -> Binary Planting -> Default Folder Privilege Escalation P3

If the application installs in the default OS paths and may be abused to run unintended code which may allow privilege escalation this would be a default P3.

The intention is to ensure a distinction in default severity, set proper priority expectations absent additional context, and recognize the current state of code signing enforcement in major OSes. I still prefer "Varies" for proper technical context but recognize the value in clear, tightly-constrained, variants where truly necessary.

My colleagues will comment more on this issue soon.

[plr0man]

If we consider that folder permissions can only be made inadequate based one the user's custom decision, then P5 in case of 'Non-Default Folder' makes sense. That would result in: Client-Side Injection -> Binary Planting -> No Privilege Escalation P5 Client-Side Injection -> Binary Planting -> Non-Default Folder Privilege Escalation P5 (new one) Client-Side Injection -> Binary Planting -> Default Folder Privilege Escalation P3 (upgrade from P4)

[plr0man]

Addressed in #142