[FEATURE] Advanced fuzzing capability: Follow-up requests and comparisons

[nf-works]

Describe your feature request

Allow following-up fuzzing iterations (which is a combination of a payload and a parameter it was injected into) with additional requests so comparisons between them can be made. The follow-up requests should inject into the same parameter.

Describe the use case of the feature

I have not used Nuclei for a good while and I wanted to try the fuzzing functionality, since Nuclei apparently is pivoting into the direction of not looking for known vulnerabilities but dynamically finding new vulnerabilities in (perhaps) custom applications. However, I found the fuzzing functionality to be rather limited when trying to create templates. I don't think any of the ideas are possible in Nuclei.

2 examples:

Suspicious input transformations by James Kettle

Simplified, he starts by sending one single request, which injects two backslashes into the insertion point (injection point/parameter). If the response contains just one slash in the reflection, it will continue working on the same parameter. If not, it will stop. This makes the technique very efficient, too. It then verifies if the reflection never contains the backslash by requesting \zz, which usually does not have any special meaning.

If the reflection contains the backslash for the arbitrary string, it follows up with different payloads injected into the same insertion point, for example: \{ If the application consumes the backslash and the reflection is only {, this would be a reportable issue. He does this with a variety of characters, which tend to have a special meaning, such as \[ or \&.

References:

• https://github.com/PortSwigger/backslash-powered-scanner/blob/master/src/burp/TransformationScan.java
• https://portswigger.net/research/backslash-powered-scanning-hunting-unknown-vulnerability-classes (headline “Suspicious input transformations”)

A trivial indicator for potential LFI

This shows the same problem, perhaps in a simpler way. Taking the base concepts of James work, one could come up with an additional idea to fuzz parameters by prepending ./. If the content remains the same (comparing it to a previous response without altering any parameter), one would want to make follow-up requests working on the very same parameter the match was found to make further checks. One of these checks could be simply requesting ../ instead of ./. If the content significantly changes or the status code becomes 500/404, this might be an indicator for LFI. This might be another feature request, too. I don't think response differences (as in a score) can be compared. Perhaps a Levenshtein distance may be a good idea? A DSL-way it may look like would be this: difference(body_1, body_2) > 50.

When I tried writing the templates, it became apparent that if a fuzzer matches, one can only fuzz all parameters or headers again in a subsequent fuzzing block, but not continue working on the same parameter (perhaps even without fuzzing, but a regular request). This way, the first match may have been on header 1, while the second fuzzer may have matched on parameter 3, which is not useful. Even if that would be usable, it would cause a lot of unnecessary requests to all the other parameters. A normal subsequent request wouldn't know what parameter to work on.

Describe alternatives you've considered

Using set() in Flow may (I'm honestly not even sure about this) be usable to work with one payload at a time throughout multiple requests or fuzzers, but the subsequent requests (after a fuzzer matched) still would not know which parameter a match was found at.

Reading the documentation multiple times, I don't think there are any features that could really help with this. I'm happy to learn I'm wrong, though, because that would make a lot of interesting templates possible.

Additional context

No response

[GeorginaReeder]

Thanks for your feature request @nf-works , we'll take a look into this!

[nf-works]

Thank you 🙂

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you think this is a mistake or would like to continue the discussion, please comment or feel free to reopen it.

[nf-works]

@GeorginaReeder You may want to adjust your GitHub Actions. Feature requests (label: Type: Enhancement) can't really become stale/abandoned. Theres just nothing to add or discuss. Or are you actually not planning on enhancing the rather limited DAST capabilities?