Re: Request for Feedback: exploit.lua

[Paulino Calderon <paulino () calderonpale com>]

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-proftpd-backdoor.nse>
> https://svn.nmap.org/nmap/scripts/ftp-vsftpd-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/jdwp-exec.nse>
> https://svn.nmap.org/nmap/scripts/irc-unrealircd-backdoor.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-cve2012-1823.nse>
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2014-8877.nse 
> <https://svn.nmap.org/nmap/scripts/http-vuln-cve2014-8877.nse>
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2014-3704.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-axis2-dir-traversal.nse>
> https://svn.nmap.org/nmap/scripts/http-majordomo2-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-ip2hosts.nse>
> https://svn.nmap.org/nmap/scripts/hostmap-bfk.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-phpmyadmin-dir-traversal.nse>
> https://svn.nmap.org/nmap/scripts/http-tplink-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-cve2006-3392.nse> (added functionality)
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2013-7091.nse 
> <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-axis2-dir-traversal.nse>
> https://svn.nmap.org/nmap/scripts/http-barracuda-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-majordomo2-dir-traversal.nse>
> https://svn.nmap.org/nmap/scripts/http-phpmyadmin-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-tplink-dir-traversal.nse>
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2006-3392.nse 
> <https://svn.nmap.org/nmap/scripts/http-vuln-cve2006-3392.nse>
> https://svn.nmap.org/nmap/scripts/http-vuln-cve2013-7091.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 <https://github.com/nmap/nmap/issues/186>
> [2]: https://github.com/wongwaituck/nmap/commit/f3a6b9b65d00772ab35595ca184f6b9c8a6853bb 
> <https://github.com/wongwaituck/nmap/commit/f3a6b9b65d00772ab35595ca184f6b9c8a6853bb>
> [3]: https://svn.nmap.org/nmap/scripts/http-fileupload-exploiter.nse 
> <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/