Server Security Misconfiguration > Unsafe File Upload > File Extension Filter Bypass should be higher severity

[blischalk]

According to OWASP guidance on unrestricted file uploads

Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The impact of this vulnerability is high, supposed code can be executed in the server context or on the client side. The likelihood of detection for the attacker is high. The prevalence is common. As a result the severity of this type of vulnerability is high.

Currently unsafe file upload is considered P5 "informational" severity which differs significantly with how OWASP and NIST classifies the severity of this issue. As an example of precedent, cve-2022-31041 is a file extension filter bypass which is categorized as medium severity by NIST CVSS 3 scoring and High severity by GitHub CVSS 3 scoring.

[vortexau]

Without the demonstrated ability to execute the uploaded code, the ability to perform an unrestricted upload is not directly helpful which is why it's rated at P5 by default in VRT.

Consider also our dataset on this is significant, and based on that - in the majority of recent cases - unrestricted file uploads or bypasses that enable it, infrequently lead to the code being executed.

In VRT, the priority is a guide - should it be demonstrated by the researcher that a higher impact is possible, such as executing the uploaded code, the priority would be adjusted at the time of triage; or more likely, the researcher would select a different category such as RCE which is a P1 by default under VRT.

[foobar7]

@vortexau The type of execution this is generally about - see CVE-2022-31041 - is client side (otherwise it would just be RCE/XSS).

Many applications rely on users sharing files of any type, and there it's not an issue. But many do not. For the security of their endusers, they may implement a file type filter. If that filter can be bypassed, that's a bypass of a security mechanism.

I know from other platforms that programs do care about this bypass of a security mechanism they decided to implement. IMHO this is something that should be above P5, unless the policy specifically puts it OOS.

[blischalk]

Adding to what @foobar7 said, from CVE-2022-31041:

These files may be downloaded (manually or automatically) by staff and/or other applications for further processing. Malicious files can therefore find their way into internal/trusted networks.

For example, if an application only allows images to be uploaded and a malicious user can upload executables or other file types which might contain executable code, then it is possible that other users of the system may download and run these files, compromising their systems. The file extension filter is a control put in place to mitigate this threat to system users and being able to bypass it puts users of the system at risk.

[vortexau]

Thanks for the clarifications @foobar7 @blischalk - The OWASP guidance above references both server-side and client-side; and while I've incorrectly assumed this was server-side predominantly, I still believe this is appropriately rated in VRT for a number of reasons.

The primary reason is that the client side is generally not under the control of the owners of the application where the bypass exists, and as a result - in the bug bounty context - the risk to the program itself is low to informational.
In cases where this is demonstrated to be a risk to the program (such as the ability to target malicious files to a programs staff, for example) this would typically be discussed with the customer when triaged by the ASE. However, at that point, they would likely point to mitigations they have in place on staff workstations such as AV, Endpoint detection which in many situations would reduce the risk rating again.

The CVE cited was in software specifically designed for the distribution of forms and files to many users, and I agree that as presented that specific finding should rate higher than a P5 if were submitted via a Bugcrowd program; but also consider we have a much larger base of applications to consider when setting base priorities for VRT categories.

That said - I'm just one opinion, and not the sole arbitrator of these decisions. We can include this in our next internal VRT meeting for a wider discussion.

[foobar7]

@vortexau Thanks for your response!

the client side is generally not under the control of the owners of the application where the bypass exists

That's true. But that's eg also the case for open redirect. It is primarily an attack against endusers (it can be exploited in other contexts, but that's not the primary issue).

I agree that attacking staff is a non-issue. It's either theoretical or - if attempted for real - OOS.

But imho there is an impact on the program itself, namely it's reputation & the trust users put in it. If its security can be bypassed to spread malware, that's something that can affect the program (depending on the type of program).

Re cve-2022-31041: I've seen a lot of programs that are designed like that. I would argue that they are the primary type of program where this sort of issue can be found (next to other types of apps with lots of user interaction like chat etc).

My main point is that the program implemented a filter for a reason. It's a security mechanism that can be bypassed. Many programs would like to be aware of that so it can be fixed (and those that don't could always put it OOS).

I'd be interested what the result of your internal discussion is :)