pry0cc / axiom

The dynamic infrastructure framework for everybody! Distribute the workload of many different scanning tools with ease, including nmap, ffuf, masscan, nuclei, meg and many more!
MIT License
4k stars 622 forks source link

[ffuf] Can't use multiple matchers #510

Closed storenth closed 2 years ago

storenth commented 2 years ago

There are few scenarios I tested before filed this issue. Let's dive into most expected. Steps to reproduce:

  1. Create custom module called ffuf-hostpath-lfi, note -mr param
    [{
        "command":"/home/op/go/bin/ffuf -u HOSTPATH -w input:PATH -w _wordlist_:HOST -mr \"admin|root|info\" -of csv -o output",
        "wordlist":"/home/op/lists/seclists/Discovery/Web-Content/big.txt",
        "ext":"csv",
        "threads":"1"
    }]
  2. Prepare wordlists (any of your choice to match the body response):
    $ cat words
    3525
    $ cat target
    http://XX.XX.XXX.XXX/image.php?id=
    $ curl http://XX.XX.XXX.XXX/image.php?id=3525
    <?php phpinfo(); ?>
  3. Call the next line:
    $ axiom-scan words -m ffuf-hostpath-lfi -wL target -o lfi-matched-url.csv

    Expected behavior: lfi-matched-url.csv contains matched path and query Actual behavior: axiom-scan produces matchers with additional spaces, so phpinfo string doesn't match admin|root|info pattern, see screenshots attached:

modules ffuf-issue proof-target

If we call pure ffuf, works like a charm:

pure-ffuf-poc

Tested potential workaround failed with command not found issue, see additional screenshots:

script issue
0xtavian commented 2 years ago

@storenth Thanks for opening this issue. Just to make sure we are on the same page, we confirmed in the axiom channel in 0x00sec discord that removing the pipes | from the command resolved the issue right?

If removing the pipes fixed it, than I know exactly what the issue is. This line https://github.com/pry0cc/axiom/blob/5dd1137956d288b951081a448b5a6135daa09b2d/interact/axiom-scan#L195

The way axiom combines command line arguments with arguments in the module is by changing the Internal Field Separator, the string that bash uses to split strings when looping etc. The default is the white space characters: \n (newline), \t (tab) and space.) Changing this to something else allows you to split strings using different characters. We change it to | ( for better for or worse ) as a way to add the cli args to the right location. So there is a limitation with | for axiom, only a max of two pipes|` can exist in any module at any given time IIRC. Any more then this will error.

I've thought about some possible solution, one is using a prefix/suffix function/tool that just combines strings based on some simple algorithm / formula. Another option might be to add an optional _command_ variable to axiom modules. The idea being users can place the _command_ variable anywhere in the module and then any user provided arguments ( excluding those that have a strictly defined place such as -w ), would be replaced with command line args, this would replace the function that sets IFS so adding many | shouldnt be an issue.

Thanks again. I'll be working on this

storenth commented 2 years ago

@storenth Thanks for opening this issue. Just to make sure we are on the same page, we confirmed in the axiom channel in 0x00sec discord that removing the pipes | from the command resolved the issue right?

Yes, by removing the | sign (one matcher still exist) resolves the issue.

0xtavian commented 2 years ago

@storenth a fix for your use case has been pushed to master. the patch fails for one edge case, if a module contains more than two | pipes AND there are additional command line arguments supplied that need to be added to the module - this will fail.

So you can use as many pipes as you wish, just dont supply extra args via the command line. Any command line args intended for axiom, such has -wL , -w, -o etc are not affected. The only restriction are with arguments intended to be passed to the binary ( in this case ffuf )

0xtavian commented 2 years ago

Closing as the main issue has been fixed.