A way to avoid multiple templates to match the same vulnerability

[dogasantos]

Hey guys,
I've noticed that we have a few templates with positive match for the same vulnerability in some situations, like these two:

generic-linux-lfi  = {{BaseUrl}}/etc/passwd
huawei-firewall-lfi = {{BaseURL}}/umweb/../etc/passwd

and

laravel-env
codeigniter-env

There are other examples, but these are classic.

Solve this would be hard I believe, but I'd like to bring this to the attention of others that might have good ideas

Perhaps provide a second match as required to evaluate a product-specific situation might help. Example:
In order to "/umweb/../etc/passwd" be a real match, it will call for a second request to a different endpoint that should identify if this is a huawei firewall or not.

It sounds like a workflow I know, but the point is to have single templates calling for the need of a workflow in order to produce a real match.

If the first match (LFI) happens, and the second fails, then it might be a generic-linux-lfi then the proper template-id match could be issued.

Sounds crazy? expensive?

[princechaddha]

Hi @dogasantos, Thank you for taking the time to create this discussion and for contributing to this project 🍻

The proposed solution for addressing the issue is feasible, and we can incorporate additional requests to accurately match specific products. To facilitate the team's work, it would greatly assist if you could provide the template IDs that you have identified as incorrectly matching with the wrong products. Instead of updating all templates, which can be quite difficult, we can begin by focusing on those templates that have matched other products. Sharing the template IDs will enable the team to promptly address these cases.

[dogasantos]

Hey there,
I noticed you closed this, but the problem is still there. I was very busy these last months for that reason I did not provided any follow up. But here it is, if I may:

yes, I believe that this might be a process that needs a start.
Here are a few templates that detect the very same thing:

For a given /.env exposed file:

http/vulnerabilities/generic/generic-env.yaml
http/exposures/configs/laravel-env.yaml
http/exposures/configs/codeigniter-env.yaml

Local file inclusion templates matching same thing:

http/vulnerabilities/generic/generic-linux-lfi.yaml
http/vulnerabilities/huawei/huawei-firewall-lfi.yaml

matching /metrics:

http/exposures/configs/prometheus-metrics.yaml
http/misconfiguration/postgres-exporter-metrics.yaml
http/technologies/kubernetes/kubelet/kubelet-metrics.yaml

We can see that some of those could not be solved by the first proposed solution.
Perhaps a secondary option would be create "groups" of templates and on those groups, do something similar as "stop-at-first-match" between templates.

A third option (alternative for the second) would be improve the request optimization feature to optimize matches as well.
How many requests were pointed to the same endpoint? Is there different matchers or it's the same thing?
If you already flagged a /metrics endpoint, don't need to check the others

I'll keep looking for more cases, but it might take some time to get back

[princechaddha]

We really appreciate the follow-up and the additional details, @dogasantos. The optimal choice would be to update the templates with an additional matcher. This is because most users tend to utilize the templates rather than the workflows. However, it might be challenging to update all the older templates. Alternatively, the third option seems feasible as well. Making changes at the engine level can prevent duplicate results, making it a viable solution for most users.