Helper function for external tools/calls

[c-f]

Hi PD Team,

I'd like to start a discussion about dynamic generated payloads outside of nuclei.
Since this is a design choice, I'd like to know what you think about it and how we can tackle this.

Related topics

• Could nuclei launch tools like safety, bandit, semgrep in templates? #1617 : launch tools like safety, bandit, semgrep
• how encode decode like with python3 struct.pack struct.unpack in yaml #2270 : use python3 methods
• Advanced scripting engine - Continues #641 #914 : PR for python (closed :/ )
• Add embedded scripting language support for more complex workflows #549 : enable scripting languages
• Custom expressions / tranforms on request values #1424: Mutators (somehow related, but maybe not directly use case)

Details

Use cases:

• As nuclei is implemented in Golang, one can only use the existing helper methods.

  --> on the fly changes are not possible.

  --> nice-to-have helpers might be added in the future (e.g. as implemented by hackvector: https://github.com/hackvertor/hackvertor/blob/master/src/main/java/burp/Convertors.java#L526 ), but some times a helper is required for only one specific weird software encoding/encryption pattern.

  ==> however, some helpers are only used once (for weird software)

• Especially when dealing with signing/encrypting payloads, there are currently two options:

  • generate the payload outside of nuclei and paste the raw payload into the template.
    --> This will fail if the vulnerability triggers an OOB request.

  • reimplement/converting the library into a nuclei helper function and use your local copy of it.
    --> This is often not possible since encryption libs cannot be ported easily.

• Templates including Binary Data or large payloads are not well suited for yaml. Take a zip-slip payload as an example.

• Manually crafted payloads cannot be easily reviewed or worse cannot be changed.

• Web-application-firewalls will look for specific payloads/requests and block them.

• Context wise payloads: If the payload changes between different versions, you require including all potential payloads to be included in the template.

• Integration with external data (e.g. payloads or other) is currently not possible.

Benefits:

• Huge flexibility options and fast prototyping for edge cases
• Option for targeted workflows (e.g. version specific handling)

Risks:

• Code Execution by design
• performance impact
• Result is depended on successful execution of payload generation / bugs in payload generating script.
• Depending on the source, it might leak information to 3rd parties /requires review, including dependencies.
• Requires environment and dependencies (if required) to be installed correctly.

Don't get me wrong. This should only be used for specific scenarios, where it is not possible to do it otherwise. But in reality we often face these cases, which in my opinion should be handled by nuclei.

Potential Implementation Concepts

1. Implement Dynamic helper directly:

{{ python_file('cve.py')}}

2. Implement "get payload" function, which sends some meta information to a server to retrieve the payload.

vars:
    payload: {{ get_payload(.Host, . , 'optional argument') }}

The payload server might be a custom tool, a new tool or even a static web server (if its ok). Payloads were requested e.g. for every request/for one target / for one template and can be used as variables in payloads.

3. Allow dynamic payloads only to be used in Workflows. E.g. generate "payload files" for every target, then use payload_files in templates. Similar to a "pre-processing wrapping-script"

4. allow/use go plugin to quickly allow nuclei to be extended on the fly: https://pkg.go.dev/plugin

Security Considerations

Several considerations might be added:

• security by default. Options related to unsafe-helpers should be disabled by default
• payload file can be signed and only executed if valid and requires being in a specific directory
• payloads are not directly generated on the same system, similar approach as interact-sh.
• docker can be used as a segmentation layer. An additional benefit would be the reliability of the external payload data.

TL;DR

• Specific scenarios cannot be covered currently by nuclei.
• Dynamic payloads would solve this problem, but have several risks to be aware of.