Re: Request for Feedback: exploit.lua

[Wong Wai Tuck <wongwaituck () gmail com>]

Hey list,

The PR for exploit.lua has been submitted on Github! This release focuses
on refactoring and improving LFI related scripts as well as standardizing
how script arguments are handled with regards to the commands to execute on
the target system for exploitation scripts. The PR with the full
description and scripts affected can be found here [1].

Looking forward to the feedback from you guys!

[1]: https://github.com/nmap/nmap/pull/960

Wai Tuck

On Wed, Jun 21, 2017 at 7:52 PM Paulino Calderon <paulino () calderonpale com>
wrote:

> Hey,
>
> This is a very interesting idea. A library where we can share code
> commonly found in exploitation scripts will certainly help get rid of all
> the duplicated code (Like in the LFI/RFI scripts you mentioned). LFI/RFI is
> a good place to start and probably where most code can be re-used from the
> scripts we have.
>
> For the shell command argument if the command is not set manually, it
> would be great if it also uses the os information available to set the
> default command to execute. However, most of our exploitation scripts
> target *nix boxes so I'm not sure how useful this will be in the future.
>
> For common file paths in different OS, I recommend a tool from a friend
> called Panoptic (https://github.com/lightos/Panoptic/). Useful for
> identifying and downloading files through LFI/RFI vulnerabilities. Its
> database is already categorized and the collection is very complete ->
> https://github.com/lightos/Panoptic/blob/master/cases.xml
>
> Another thing is the possibility of providing a 'framework' for script
> writes like the Brute engine with function definitions like check_target(),
> exploit() or maybe report() and cleanup(). For example, all scripts need to
> check if a target is valid before sending the payload. This will make
> script writers write more robust scripts and at the same time maybe we can
> take care of some things for them.
>
> I look forward to seeing this library.
>
> Cheers!
>
>
>
> On Jun 15, 2017, at 5:45 PM, Wong Wai Tuck <wongwaituck () gmail com> wrote:
>
> Hey all!
>
> I have been discussing with my mentor George on the idea of creating a
> exploit.lua for nmap. The idea came originally from [1] and I want to see
> what other features you guys might want to see in the library!
>
> Here is the design plan so far, and a sample refactoring and some sample
> output can be found in [2]:
>
> INTRODUCTION
> In the exploit scripts, quite a lot of code is repeated and honestly very
> painful to write and to maintain. One such example is the http-vuln-cve2006-3392.nse,
> which makes use of LFI code that is repeated for a lot of other code, and
> we can really see the issue - its current implementation does not work as
> intended. The exploit library makes exploiting less painful, and focuses
> on larger abstractions rather than working with the primitives, allowing
> code for exploit scripts to be written in a terse manner, as well as
> provide some utility functions for more general cases. The ultimate goal
> is to create an exploit utility like what pwntools did for Python, but
> tailored towards normal Nmap usage. This library will depend on other
> libraries, including http, stdnse, io, string and more as other
> functionalities get proposed.
>
> FUNCTIONALITY PROPOSED
> get_shell_cmd(SCRIPT_NAME: string): string  A function that return the
> value of the most-specific provided script-arg between "exploit.cmd" and
> "SCRIPT_NAME.cmd".  Based on [1].
> Affected scripts:
> https://svn.nmap.org/nmap/scripts/ftp-proftpd-backdoor.nse
> https://svn.nmap.org/nmap/scripts/ftp-vsftpd-backdoor.nse
> https://svn.nmap.org/nmap/scripts/jdwp-exec.nse
> https://svn.nmap.org/nmap/scripts/irc-unrealircd-backdoor.nse
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2012-1823.nse
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2014-8877.nse
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2014-3704.nse
>
> LFI framework
> For a lot of the LFI related scripts, all of them are duplicates of each
> other (with a slightly different payload), leading to a lot of repeated
> code, as well as redundant functionality (e.g. file_write). The exploit
> library will seek to refactor the methods so that writing an LFI can be as
> simple as writing a single line in a script.
>
> *status, lfi_success, contents = lfi_check(remote, port, payload,
> [filename, outfile , is_post, post_data]): *A function that attempts to
> retrieve a file on the remote system through Local File Inclusion, and
> checks against known signatures of the file (if it is a known file, e.g.
> for the filename "/etc/passwd", there should be "root:"). It returns the
> status of the request (e.g. 200), whether the lfi was deemed to be a
> success (true, false), and the contents of the webpage. If outfile is
> provided, the lfi'd file is stored locally in the file pointed at by
> outfile. As you can see in the sample implementation, I have created
> filename and outfile to take in exploit script arguments, hence simplifying
> the interface for nmap script users.
>
> *Affected Scripts (for outfile refactoring)*
> https://svn.nmap.org/nmap/scripts/http-axis2-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-majordomo2-dir-traversal.nse
> http-barracuda-dir-traversal (added functionality)
> supermicro-ipmi-conf
> https://svn.nmap.org/nmap/scripts/hostmap-ip2hosts.nse
> https://svn.nmap.org/nmap/scripts/hostmap-bfk.nse
> https://svn.nmap.org/nmap/scripts/http-phpmyadmin-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-tplink-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2006-3392.nse (added
> functionality)
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2013-7091.nse (added
> functionality)
>
> *Affected Scripts (for LFI refactoring)*
> https://svn.nmap.org/nmap/scripts/http-axis2-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-barracuda-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-majordomo2-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-phpmyadmin-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-tplink-dir-traversal.nse
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2006-3392.nse
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2013-7091.nse
>
> Other new functionality I would be adding is as follows:
>
> *get_common_filepaths(platforms: table)**: table* A function that takes
> an array containing the platforms to include, e.g.  {"Windows", "Linux",
> "BSD"},  which causes it to output common Windows filepaths, Linux
> filepaths, BSD filepaths to an array. It returns an array of common
> filepaths that can be included, e.g. index.php, /etc/passwd and so on.
>
> *status, rfi_success, contents = rfi_check(remote, port, payload, rfi_url,
> [bind_port, file_to_include, is_post, post_data]):*  A function similar
> to LFI check except it checks for RFI through the provided rfi_url, and
> allows you to specify whether you want to open a service on a local port to
> host a file you wish to include. This is useful if the machines you are
> scanning can access your own machine (i.e. in some intranet) and you wish
> to scan for RFI which could be potentially a huge security risk.
>
> SUGGESTIONS
> We are also thinking of including XSS payloads and SQL Injection payloads,
> and even reverse shell/binary payloads. We could potentially produce
> payloads and detect the generated string, similar to what George did in the
> http-fileupload-exploiter script [3]. However, I would like to seek the
> opinion of the community to see if these payloads fit Nmap's typical use
> case, and prioritize those which are more useful to script writers. I am
> quite new to NSE, so I would appreciate any other ideas which you would
> find to be useful in a library like this! Any feedback would be much
> appreciated.
>
> Thank you!
>
> [1]: https://github.com/nmap/nmap/issues/186
> [2]:
> https://github.com/wongwaituck/nmap/commit/f3a6b9b65d00772ab35595ca184f6b9c8a6853bb
> [3]: https://svn.nmap.org/nmap/scripts/http-fileupload-exploiter.nse
>
> Wai Tuck
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/