Nmap Development mailing list archives

Request for Feedback: exploit.lua


From: Wong Wai Tuck <wongwaituck () gmail com>
Date: Thu, 15 Jun 2017 22:45:27 +0000

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/

Current thread: