PenTest/nmap
1
0
Fork 0
mirror of https://github.com/nmap/nmap.git synced 2025-12-06 04:31:29 +00:00
Code Issues Projects Releases Wiki Activity

First-pass copyediting on the remaining scripts.

Browse Source
This commit is contained in:
david
2010-07-12 17:19:26 +00:00
parent 4cdc50e95d
commit 1ff1a4f892
24 changed files with 128 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
scripts/qscan.nse
View File

@@ -23,9 +23,9 @@ description = [[
-- @usage
-- nmap --script qscan --script-args qscan.confidence=0.95,qscan.delay=200ms,qscan.numtrips=10 target
--
-- @args confidence Confidence level: 0.75, 0.9, 0.95, 0.975, 0.99, 0.995, 0.9995
-- @args delay Average delay between packet sends. This is a number followed by <code>ms</code> for milliseconds or <code>s</code> for seconds. (<code>m</code> and <code>h</code> are also supported but are too long for timeouts.) The actual delay will randomly vary between 50% and 150% of the time specified. Default: 200ms.
-- @args numtrips Number of round-trip times to try to get
-- @args confidence Confidence level: <code>0.75</code>, <code>0.9</code>, <code>0.95</code>, <code>0.975</code>, <code>0.99</code>, <code>0.995</code>, or <code>0.9995</code>.
-- @args delay Average delay between packet sends. This is a number followed by <code>ms</code> for milliseconds or <code>s</code> for seconds. (<code>m</code> and <code>h</code> are also supported but are too long for timeouts.) The actual delay will randomly vary between 50% and 150% of the time specified. Default: <code>200ms</code>.
-- @args numtrips Number of round-trip times to try to get.
--
-- @output
-- | qscan:

22
scripts/smb-brute.nse
View File

@@ -3,14 +3,14 @@ Attempts to guess username/password combinations over SMB, storing discovered co
for use in other scripts. Every attempt will be made to get a valid list of users and to
verify each username before actually using them. When a username is discovered, besides
being printed, it is also saved in the Nmap registry so other Nmap scripts can use it. That
means that if you're going to run smb-brute.nse, you should run other smb scripts you want.
means that if you're going to run <code>smb-brute.nse</code>, you should run other <code>smb</code> scripts you want.
This checks passwords in a case-insensitive way, determining case after a password is found,
for Windows versions before Vista.
This script is specifically targeted towards security auditors or penetration testers.
One example of its use, suggested by Brandon Enright, was hooking up smb-brute.nse to the
One example of its use, suggested by Brandon Enright, was hooking up <code>smb-brute.nse</code> to the
database of usernames and passwords used by the Conficker worm (the password list can be
found here, among other places <http://www.skullsecurity.org/wiki/index.php/Passwords>.
found at http://www.skullsecurity.org/wiki/index.php/Passwords, among other places.
Then, the network is scanned and all systems that would be infected by Conficker are
discovered.
@@ -20,10 +20,10 @@ Further, passwords discovered against Windows with SMB might also be used on Lin
or custom Web applications. Discovering a password greatly beneficial for a pen-tester.
This script uses a lot of little tricks that I (Ron Bowes) describe in detail in a blog
posting <http://www.skullsecurity.org/blog/?p=164>. The tricks will be summarized here, but
posting, http://www.skullsecurity.org/blog/?p=164. The tricks will be summarized here, but
that blog is the best place to learn more.
Usernames and passwords are initially taken from the unpw library. If possible, the usernames
Usernames and passwords are initially taken from the unpwdb library. If possible, the usernames
are verified as existing by taking advantage of Windows' odd behaviour with invalid username
and invalid password responses. As soon as it is able, this script will download a full list
of usernames from the server and replace the unpw usernames with those. This enables the
@@ -32,18 +32,18 @@ script to restrict itself to actual accounts only.
When an account is discovered, it's saved in the <code>smb</code> module (which uses the Nmap
registry). If an account is already saved, the account's privileges are checked; accounts
with administrator privileges are kept over accounts without. The specific method for checking
is by calling GetShareInfo("IPC$"), which requires administrative privileges. Once this script
is by calling <code>GetShareInfo("IPC$")</code>, which requires administrative privileges. Once this script
is finished (all other smb scripts depend on it, it'll run first), other scripts will use the saved account
to perform their checks.
The blank password is always tried first, followed by "special passwords" (such as the username
and the username reversed). Once those are exhausted, the unpw password list is used.
and the username reversed). Once those are exhausted, the unpwdb password list is used.
One major goal of this script is to avoid accout lockouts. This is done in a few ways. First,
when a lockout is detected, unless you user specifically overrides it with the <code>smblockout</code>
argument, the scan stops. Second, all usernames are checked with the most common passwords first,
so with not-too-strict lockouts (10 invalid attempts), the 10 most common passwords will still
be tried. Third, one account, called the canary, 'goes out ahead' -- that is, three invalid
be tried. Third, one account, called the canary, "goes out ahead"; that is, three invalid
attempts are made (by default) to ensure that it's locked out before others are.
In addition to active accounts, this script will identify valid passwords for accounts that
@@ -56,7 +56,7 @@ information.
When possible, checks are done using a case-insensitive password, then proper case is
determined with a fairly efficient bruteforce. For example, if the actual password is
'PassWord', then 'password' will work and 'PassWord' will be found afterwards (on the
"PassWord", then "password" will work and "PassWord" will be found afterwards (on the
14th attempt out of a possible 256 attempts, with the current algorithm).
]]
---
@@ -78,11 +78,11 @@ determined with a fairly efficient bruteforce. For example, if the actual passwo
-- | | thisisaverylongnamev:password => Login was successful
-- |_ |_ web:TeSt => Password was correct, but user's account is disabled
--
-- @args smblockout Unless this is set to '1' or 'true', the script won't continue if it
-- @args smblockout Unless this is set to <code>1</code> or <code>true</code>, the script won't continue if it
-- locks out an account or thinks it will lock out an account.
-- @args brutelimit Limits the number of usernames checked in the script. In some domains,
-- it's possible to end up with 10,000+ usernames on each server. By default, this
-- will be 5000, which should be higher than most servers and also prevent infinite
-- will be <code>5000</code>, which should be higher than most servers and also prevent infinite
-- loops or other weird things. This will only affect the user list pulled from the
-- server, not the username list.
-- @args canaries Sets the number of tests to do to attempt to lock out the first account.

44
scripts/smb-check-vulns.nse
View File

@@ -1,5 +1,5 @@
description = [[
Check for vulnerabilities:
Checks for vulnerabilities:
* MS08-067, a Windows RPC vulnerability
* Conficker, an infection by the Conficker worm
* Unnamed regsvc DoS, a denial-of-service vulnerability I accidentically found in Windows 2000
@@ -17,29 +17,27 @@ by a scanner. Penetration testers, on the other hand, might not want to use this
script -- crashing services is not generally a good way of sneaking through a
network.
If you set the script parameter 'unsafe', then scripts will run that are almost
If you set the script parameter <code>unsafe</code>, then scripts will run that are almost
(or totally) guaranteed to crash a vulnerable system; do NOT specify <code>unsafe</code>
in a production environment! And that isn't to say that non-unsafe scripts will
not crash a system, they're just less likely to.
If you set the script parameter 'safe', then script will run that rarely or never
If you set the script parameter <code>safe</code>, then script will run that rarely or never
crash a vulnerable system. No promises, though.
MS08-067 -- Checks if a host is vulnerable to MS08-067, a Windows RPC vulnerability that
MS08-067. Checks if a host is vulnerable to MS08-067, a Windows RPC vulnerability that
can allow remote code execution. Checking for MS08-067 is very dangerous, as the check
is likely to crash systems. On a fairly wide scan conducted by Brandon Enright, we determined
that on average, a vulnerable system is more likely to crash than to survive
the check. Out of 82 vulnerable systems, 52 crashed.
At the same time, MS08-067 is extremely critical to fix. Metasploit has a working and
stable exploit for it, and any system vulnerable can very easily be compromised.
Conficker -- Checks if a host is infected with a known Conficker strain. This check
Conficker. Checks if a host is infected with a known Conficker strain. This check
is based on the simple conficker scanner found on this page:
http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker
http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker.
Thanks to the folks who wrote that scanner!
regsvc DoS -- Checks if a host is vulnerable to a crash in regsvc, caused
regsvc DoS. Checks if a host is vulnerable to a crash in regsvc, caused
by a null pointer dereference. I inadvertently discovered this crash while working
on <code>smb-enum-sessions</code>, and discovered that it was repeatable. It's been
reported to Microsoft (case #MSRC8742).
@@ -47,34 +45,34 @@ reported to Microsoft (case #MSRC8742).
This check WILL crash the service, if it's vulnerable, and requires a guest account
or higher to work. It is considered <code>unsafe</code>.
SMBv2 DoS -- performs a denial-of-service against the vulnerability disclosed in
SMBv2 DoS. Performs a denial-of-service against the vulnerability disclosed in
CVE-2009-3103. Checks if the server went offline. This works agianst Windows Vista
and some versions of Windows 7, and causes a bluescreen if successful. The proof-
of-concept code at http://seclists.org/fulldisclosure/2009/Sep/39 was used,
and some versions of Windows 7, and causes a bluescreen if successful. The
proof-of-concept code at http://seclists.org/fulldisclosure/2009/Sep/39 was used,
with one small change.
MS06-025 -- vulnerability targets the RasRpcSumbitRequest() RPC method which is
MS06-025. Vulnerability targets the <code>RasRpcSumbitRequest()</code> RPC method which is
a part of RASRPC interface that serves as a RPC service for configuring and
getting information from the Remote Access and Routing service. RASRPC can be
accessed using either "\ROUTER" SMB pipe or the "\SRVSVC" SMB pipe (usually on WinXP machines).
This is in RPC world known as "ncan_np" RPC transport. RasRpcSumbitRequest()
accessed using either "\ROUTER" SMB pipe or the "\SRVSVC" SMB pipe (usually on Windows XP machines).
This is in RPC world known as "ncan_np" RPC transport. <code>RasRpcSumbitRequest()</code>
method is a generic method which provides different functionalities according
to the RequestBuffer structure and particulary the RegType field within that
structure. RegType field is of enum ReqTypes type. This enum type lists all
the different available operation that can be performed using the RasRpcSubmitRequest()
RPC method. The one particular operation that this vuln targets is the REQTYPE_GETDEVCONFIG
to the <code>RequestBuffer</code> structure and particulary the <code>RegType</code> field within that
structure. <code>RegType</code> field is of <code>enum ReqTypes</code> type. This enum type lists all
the different available operation that can be performed using the <code>RasRpcSubmitRequest()</code>
RPC method. The one particular operation that this vuln targets is the <code>REQTYPE_GETDEVCONFIG</code>
request to get device information on the RRAS.
MS07-029 -- vulnerability targets the R_DnssrvQuery() and R_DnssrvQuery2() RPC method which is
a part of Dns Server RPC interface that serves as a RPC service for configuring and
getting information from the Dns Server service. Dns Server RPC service can be
MS07-029. Vulnerability targets the <code>R_DnssrvQuery()</code> and <code>R_DnssrvQuery2()</code> RPC method which is
a part of DNS Server RPC interface that serves as a RPC service for configuring and
getting information from the DNS Server service. DNS Server RPC service can be
accessed using "\dnsserver" SMB named pipe. The vulnerability is triggered when
a long string is send as the "zone" parameter which causes the buffer overflow which
crashes the service.
(Note: if you have other SMB/MSRPC vulnerability checks you'd like to see added, and
you can show me a tool with a license that is compatible with Nmap's, post a request
on the Nmap-dev mailing list and I'll add it to my list [Ron Bowes]).
on the nmap-dev mailing list and I'll add it to my list [Ron Bowes].)
]]
---
--@usage

2
scripts/smb-enum-domains.nse
View File

@@ -9,7 +9,7 @@ tester what types of policies to expect. For example, if passwords have a minimu
the tester can trim his database to match; if the minimum length is 14, the tester will
probably start looking for sticky notes on people's monitors.
Another useful piece of information is the password lockouts -- a penetration tester often wants
Another useful piece of information is the password lockouts. A penetration tester often wants
to know whether or not there's a risk of negatively impacting a network, and this will
indicate it. The SID is displayed, which may be useful in other tools; the users are listed,
which uses different functions than <code>smb-enum-users.nse</code> (though likely won't

4
scripts/smb-enum-groups.nse
View File

@@ -1,9 +1,9 @@
description = [[
Obtains a list of groups from the remote Windows system, as well as a list of the group's users.
This works similarly to enum.exe with the /G switch.
This works similarly to <code>enum.exe</code> with the <code>/G</code> switch.
The following MSRPC functions in SAMR are used to find a list of groups and the RIDs of their users. Keep
in mind thatMSRPC refers to groups as 'Aliases'.
in mind that MSRPC refers to groups as "Aliases".
* <code>Bind</code>: bind to the SAMR service.
* <code>Connect4</code>: get a connect_handle.

4
scripts/smb-enum-processes.nse
View File

@@ -9,9 +9,9 @@ penetration tester, since they can effectively do the same thing with metasploit
or other tools. It does, however, provide for a quick way to get process lists
for a bunch of systems at the same time.
WARNING: I have experienced crashes in regsvc.exe while making registry calls
WARNING: I have experienced crashes in <code>regsvc.exe</code> while making registry calls
against a fully patched Windows 2000 system; I've fixed the issue that caused
it, but there's no guarantee that it (or a similar vuln in the same code) won't
it, but there's no guarantee that it (or a similar vulnerability in the same code) won't
show up again. Since the process automatically restarts, it doesn't negatively
impact the system, besides showing a message box to the user.
]]

2
scripts/smb-enum-sessions.nse
View File

@@ -28,7 +28,7 @@ for. The level of access required for this varies between Windows versions, but
2000 anybody (including the anonymous account) can access this, and in Windows 2003 a user
or administrator account is required.
I learned the idea and technique for this from sysinternals' tool, PsLoggedOn.exe. I (Ron
I learned the idea and technique for this from sysinternals' tool, <code>PsLoggedOn.exe</code>. I (Ron
Bowes) use similar function calls to what they use (although I didn't use their source),
so thanks go out to them. Thanks also to Matt Gardenghi, for requesting this script.

4
scripts/smb-enum-users.nse
View File

@@ -87,8 +87,8 @@ doesn't hurt to add more.
The names and details from both of these techniques are merged and displayed.
If the output is verbose, then extra details are shown. The output is ordered alphabetically.
Credit goes out to the enum.exe, sid2user.exe, and user2sid.exe programs,
the code I wrote for this is largely based on the techniques used by them.
Credit goes out to the <code>enum.exe</code>, <code>sid2user.exe</code>, and <code>user2sid.exe</code> programs.
The code I wrote for this is largely based on the techniques used by them.
]]
---

10
scripts/smb-os-discovery.nse
View File

@@ -1,21 +1,21 @@
description = [[
Attempts to determine the operating system, computer name, domain, and current
time over the SMB protocol (ports 445 or 139 -- for more information, see
<code>smb.lua</code>). This is done by starting a session with the anonymous
account (or with a proper user account, if one is given -- likely doesn't make
time over the SMB protocol (ports 445 or 139).
This is done by starting a session with the anonymous
account (or with a proper user account, if one is given; it likely doesn't make
a difference); in response to a session starting, the server will send back all this
information.
Some systems, like Samba, will blank out their name (and only send their domain).
Other systems (like embedded printers) will simply leave out the information. Other
systems will blank out various pieces (some will send back '0' for the current
systems will blank out various pieces (some will send back 0 for the current
time, for example).
Retrieving the name and operating system of a server is a vital step in targeting
an attack against it, and this script makes that retrieval easy. Additionally, if
a penetration tester is choosing between multiple targets, the time can help identify
servers that are being poorly maintained (for more information/random thoughts on
using the time, see <http://www.skullsecurity.org/blog/?p=76>.
using the time, see http://www.skullsecurity.org/blog/?p=76.
Although the standard <code>smb*</code> script arguments can be used,
they likely won't change the outcome in any meaningful way.

121
scripts/smb-psexec.nse
View File

@@ -13,16 +13,16 @@ might run like this).
To use this, a configuration file should be created and edited. Several configuration
files are included that you can customize, or you can write your own. This config file
is placed in nselib/data/psexec (if you aren't sure where that is, search your system
for 'default.lua'), then is passed to Nmap as a script argument (for example,
is placed in <code>nselib/data/psexec</code> (if you aren't sure where that is, search your system
for <code>default.lua</code>), then is passed to Nmap as a script argument (for example,
myconfig.lua would be passed as <code>--script-args=config-myconfig</code>.
The configuration file consists mainly of a module list. Each module is defined by a lua
table, and contains fields for the name of the program, the executable and arguments
for the program, and a score of other options. Modules also have an 'upload' field, which
determines whether or not the module is to be uploaded. Here is a simple example of how
to run 'net localgroup administrators', which returns a list of users in the 'administrators'
group (take a look at the 'examples.lua' configuration file for these examples):
to run <code>net localgroup administrators</code>, which returns a list of users in the "administrators"
group (take a look at the <code>examples.lua</code> configuration file for these examples):
<code>
mod = {}
@@ -98,7 +98,7 @@ want is the IP address and MAC address, and we get it using <code>mod.find</code
</code>
This module searches for lines that contain "IP Address", "Physical Address", or "Ethernet adapter".
In thiese lines, a ". " is replaced with nothing, a "-" is replaced with a colon, and the term
In these lines, a ". " is replaced with nothing, a "-" is replaced with a colon, and the term
"Physical Address" is replaced with "MAC Address" (arguably unnecessary). Run ipconfig /all yourself
to see what we start with, but here's the final output:
@@ -112,10 +112,10 @@ to see what we start with, but here's the final output:
Another interesting part of this script is that variables can be used in any script fields. There
are two types of variables: built-in and user-supplied. Built-in variables can be anything found
in the <code>config</code> table, most of which are listed below. The more interesting ones are:
* $lhost: The address of the scanner
* $rhost: The address being scanned
* $path: The path where the scripts are uploaded
* $share: The share where the script was uploaded
* <code>$lhost</code>: The address of the scanner
* <code>$rhost</code>: The address being scanned
* <code>$path</code>: The path where the scripts are uploaded
* <code>$share</code>: The share where the script was uploaded
User-supplied arguments are given on the commandline, and can be controlled by <code>mod.req_args</code>
in the configuration file. Arguments are given by the user in --script-args; for example, to set $host
@@ -172,8 +172,8 @@ $ ./nmap -n -d -p445 --script=smb-psexec --script-args=smbuser=test,smbpass=test
| |_Request timed out.
</code>
For the final example, we'll use the 'upload' command to upload fgdump.exe, run it,
download its output file, and clean up its logfile. You'll have to put fgdump.exe
For the final example, we'll use the <code>upload</code> command to upload <code>fgdump.exe</code>, run it,
download its output file, and clean up its logfile. You'll have to put <code>fgdump.exe</code>
in the same folder as the script for this to work:
<code>
mod = {}
@@ -186,13 +186,13 @@ in the same folder as the script for this to work:
mod.outfile = "127.0.0.1.pwdump"
table.insert(modules, mod)
</code>
The -l argument for fgdump supplies the name of the logfile. That file is listed in the
The <code>-l</code> argument for fgdump supplies the name of the logfile. That file is listed in the
<code>mod.tempfiles</code> field. What, exactly, does <code>mod.tempfiles</code> do?
It simply gives the service a list of files to delete while cleaning up. The cleanup
process will be discussed later.
<code>mod.url</code> is displayed to the user if <code>mod.program</code> isn't found in
nselib/data/psexec/. And finally, <code>mod.outfile</code> is the file that is downloaded
<code>nselib/data/psexec/</code>. And finally, <code>mod.outfile</code> is the file that is downloaded
from the system. This is required because fgdump writes to an output file instead of to
stdout (pwdump6, for example, doesn't require <code>mod.outfile</code>.
@@ -200,40 +200,40 @@ Now that we've seen a few possible combinations of fields, I present a complete
fields available and what each of them do. Many of them will be familiar, but there are a
few that aren't discussed in the examples:
* upload (boolean) true if it's a local file to upload, false if it's already on the host machine. If <code>upload</code> is true, <code>program</code> has to be in nselib/data/psexec.
* name (string) The name to display above the output. If this isn't given, <code>program</code> .. <code>args</code> are used.
* program (string) If <code>upload</code> is false, the name (fully qualified or relative) of the program on the remote system; if <code>upload</code> is true, the name of the local file that will be uploaded (stored in nselib/data/psexec).
* args (string) Arguments to pass to the process.
* env (string) Environmental variables to pass to the process, as name=value pairs, delimited, per Microosft's spec, by NULL characters (string.char(0)).
* maxtime (integer) The approximate amount of time to wait for this process to complete. The total timeout for the script before it gives up waiting for a response is the total of all 'maxtime' fields.
* extrafiles (string[]) Extra file(s) to upload before running the program. These will *not* be renamed (because, presumably, if they are then the program won't be able to find them), but they will be marked as hidden/system/etc. This may cause a race condition if multiple people are doing this at once, but there isn't much we can do. The files are also deleted afterwards as tempfiles would be. The files have to be in the same directory as programs (nselib/data/psexec), but the program doesn't necessarily need to be an uploaded one.
* tempfiles (string[]) A list of temporary files that the process is known to create (if the process does create files, using this field is recommended because it helps avoid making a mess on the remote system)
* find (string[]) Only display lines that contain the given string(s) (for example, if you're searching for a line that contains 'IP Address', set this to {'IP Address'}. This allows Lua-style patterns, see: <http://lua-users.org/wiki/PatternsTutorial> (don't forget to escape special characters with a '%'). Note that this is client-side only; the full output is still returned, the rest is removed while displaying. The line of output only needs to match one of the strings given here.
* remove (string[]) Opposite of find; this removes lines containing the given string(s) instead of displaying them. Like find, this is client-side only and uses Lua-style patterns. If 'remove' and 'find' are in conflict, the 'remove' takes priority.
* noblank (boolean) Setting this to true removes all blank lines from the output.
* replace (table) A table of values to replace in the strings returned. Like find and replace, this is client-side only and uses Lua-style patterns.
* headless (boolean) If 'headless' is set to true, the program doesn't return any output; rather, it runs detached from the service so that, when the service ends, the program keeps going. This can be useful for, say, a monitoring program. Or a backdoor, if that's what you're into (a Metasploit payload should work nicely). Not compatible with: find, remove, noblank, replace, maxtime, outfile.
* enabled (boolean) Set to false, and optionally set <code>disabled_message</code>, if you don't want a module to run. Alternatively, you can comment out the process.
* disabled_message (string) Displayed if the module is disabled.
* url (string) A module where the user can download the uploadable file. Displayed if the uploadable file is missing.
* outfile (string) If set, the specified file will be returned instead of stdout.
* req_args (string[]) An array of arguments that the user must set in --script-args.
* <code>upload</code> (boolean) true if it's a local file to upload, false if it's already on the host machine. If <code>upload</code> is true, <code>program</code> has to be in <code>nselib/data/psexec</code>.
* <code>name</code> (string) The name to display above the output. If this isn't given, <code>program</code> .. <code>args</code> are used.
* <code>program</code> (string) If <code>upload</code> is false, the name (fully qualified or relative) of the program on the remote system; if <code>upload</code> is true, the name of the local file that will be uploaded (stored in <code>nselib/data/psexec</code>).
* <code>args</code> (string) Arguments to pass to the process.
* <code>env</code> (string) Environmental variables to pass to the process, as name=value pairs, delimited, per Microsoft's spec, by NULL characters (<code>string.char(0)</code>).
* <code>maxtime</code> (integer) The approximate amount of time to wait for this process to complete. The total timeout for the script before it gives up waiting for a response is the total of all <code>maxtime</code> fields.
* <code>extrafiles</code> (string[]) Extra file(s) to upload before running the program. These will not be renamed (because, presumably, if they are then the program won't be able to find them), but they will be marked as hidden/system/etc. This may cause a race condition if multiple people are doing this at once, but there isn't much we can do. The files are also deleted afterwards as tempfiles would be. The files have to be in the same directory as programs (<code>nselib/data/psexec</code>), but the program doesn't necessarily need to be an uploaded one.
* <code>tempfiles</code> (string[]) A list of temporary files that the process is known to create (if the process does create files, using this field is recommended because it helps avoid making a mess on the remote system).
* <code>find</code> (string[]) Only display lines that contain the given string(s) (for example, if you're searching for a line that contains "IP Address", set this to <code>{'IP Address'}</code>. This allows Lua-style patterns, see: http://lua-users.org/wiki/PatternsTutorial (don't forget to escape special characters with a <code>%</code>). Note that this is client-side only; the full output is still returned, the rest is removed while displaying. The line of output only needs to match one of the strings given here.
* <code>remove</code> (string[]) Opposite of <code>find</code>; this removes lines containing the given string(s) instead of displaying them. Like <code>find</code>, this is client-side only and uses Lua-style patterns. If <code>remove</code> and <code>find</code> are in conflict, then <code>remove</code> takes priority.
* <code>noblank</code> (boolean) Setting this to true removes all blank lines from the output.
* <code>replace</code> (table) A table of values to replace in the strings returned. Like <code>find</code> and <code>replace</code>, this is client-side only and uses Lua-style patterns.
* <code>headless</code> (boolean) If <code>headless</code> is set to true, the program doesn't return any output; rather, it runs detached from the service so that, when the service ends, the program keeps going. This can be useful for, say, a monitoring program. Or a backdoor, if that's what you're into (a Metasploit payload should work nicely). Not compatible with: <code>find</code>, <code>remove</code>, <code>noblank</code>, <code>replace</code>, <code>maxtime</code>, <code>outfile</code>.
* <code>enabled</code> (boolean) Set to false, and optionally set <code>disabled_message</code>, if you don't want a module to run. Alternatively, you can comment out the process.
* <code>disabled_message</code> (string) Displayed if the module is disabled.
* <code>url</code> (string) A module where the user can download the uploadable file. Displayed if the uploadable file is missing.
* <code>outfile</code> (string) If set, the specified file will be returned instead of stdout.
* <code>req_args</code> (string[]) An array of arguments that the user must set in <code>--script-args</code>.
Any field in the configuration file can contain variables, as discussed. Here are some of the available built-in variables:
* $lhost: local ip address as a string.
* $lport: local port (meaningless; it'll change by the time the module is uploaded since multiple connections are made).
* $rhost: remote ip address as a string.
* $rport: remote port.
* $lmac: local mac address as a string in the xx:xx:xx:xx:xx:xx format (note: requires root).
* $path: the path where the file will be uploaded to.
* $service_name: the name of the service that will be running this program
* $service_file: the name of the executable file for the service
* $temp_output_file: The (ciphered) file where the programs' output will be written before being renamed to $output_file
* $output_file: The final name of the (ciphered) output file. When this file appears, the script downloads it and stops the service
* $timeout: The total amount of time the script is going to run before it gives up and stops the process
* $share: The share that everything was uploaded to
* (script-args): Any value passed as a script-arg will be replaced (for example, if Nmap is run with <code>--script-args=var3=10</code>, then '$var3' in any field will be replaced with '10'. See the <code>req_args</code> field above. script-args values take priority over config values.
* <code>$lhost</code>: local IP address as a string.
* <code>$lport</code>: local port (meaningless; it'll change by the time the module is uploaded since multiple connections are made).
* <code>$rhost</code>: remote IP address as a string.
* <code>$rport</code>: remote port.
* <code>$lmac</code>: local MAC address as a string in the xx:xx:xx:xx:xx:xx format (note: requires root).
* <code>$path</code>: the path where the file will be uploaded to.
* <code>$service_name</code>: the name of the service that will be running this program
* <code>$service_file</code>: the name of the executable file for the service
* <code>$temp_output_file</code>: The (ciphered) file where the programs' output will be written before being renamed to $output_file
* <code>$output_file</code>: The final name of the (ciphered) output file. When this file appears, the script downloads it and stops the service
* <code>$timeout</code>: The total amount of time the script is going to run before it gives up and stops the process
* <code>$share</code>: The share that everything was uploaded to
* (script args): Any value passed as a script argument will be replaced (for example, if Nmap is run with <code>--script-args=var3=10</code>, then <code>$var3</code> in any field will be replaced with <code>10</code>. See the <code>req_args</code> field above. Script argument values take priority over config values.
In addition to modules, the configuration file can also contain overrides. Most of these
aren't useful, so I'm not going to go into great detail. Search <code>smb-psexec.nse</code>
@@ -255,7 +255,7 @@ Running a script happens in several stages:
1) An open fileshare is found that we can write to. Finding an open fileshare basically
consists of enumerating all shares and seeing which one(s) we have access to.
2) A 'service wrapper', and all of the uploadable/extra files, are uploaded. Before
2) A "service wrapper", and all of the uploadable/extra files, are uploaded. Before
they're uploaded, the name of each file is obfuscated. The obfuscation completely
renames the file, is unique for each source system, and doesn't change between multiple
runs. This obfuscation has the benefit of preventing filenames from overlapping if
@@ -287,14 +287,13 @@ Please post any questions, or suggestions for better modules, to nmap-dev@insecu
And, as usual, since this tool can be dangerous and can easily be viewed as a malicious
tool -- use this responsibly, and don't break any laws with it.
Some ideas for later versions:
-- TODO:
* Set up a better environment for scripts (PATH, SystemRoot, etc). Without this, a lot of programs (especially ones that deal with network traffic) behave oddly.
* Abstract the code required to run remote processes so other scripts can use it more easily (difficult, but will ultimately be well worth it) (later) (may actually not be possible -- there is a lot of overhead and specialized code in this module. We'll see, though.)
* Let user specify an output file (per-script) so they can, for example, download binary files (don't think it's worthwhile)
* Consider running the external programs in parallel (not sure if the benefits outweigh the drawbacks)
* Let the config request the return code from the process instead of the output (not sure if doing this would be worth the effort)
* Check multiple shares in a single session to save packets (and see where else we can tighten up the amount of traffic)
Some ideas for later versions (TODO):
* Set up a better environment for scripts (<code>PATH</code>, <code>SystemRoot</code>, etc). Without this, a lot of programs (especially ones that deal with network traffic) behave oddly.
* Abstract the code required to run remote processes so other scripts can use it more easily (difficult, but will ultimately be well worth it later). (May actually not be possible. There is a lot of overhead and specialized code in this module. We'll see, though.)
* Let user specify an output file (per-script) so they can, for example, download binary files (don't think it's worthwhile).
* Consider running the external programs in parallel (not sure if the benefits outweigh the drawbacks).
* Let the config request the return code from the process instead of the output (not sure if doing this would be worth the effort).
* Check multiple shares in a single session to save packets (and see where else we can tighten up the amount of traffic).
]]
---
@@ -381,9 +380,9 @@ Some ideas for later versions:
-- | | | None
-- |_ |_ |_ Route Table
--
--@args config The config file to use (eg, default). Config files require a .lua extension, and are located in nselib/data/psexec.
--@args config The config file to use (eg, default). Config files require a .lua extension, and are located in <code>nselib/data/psexec</code>.
--@args nohide Don't set the uploaded files to hidden/system/etc.
--@args cleanup Set to '1' or 'true' to simply clean up any mess we made (leftover files, processes, etc. on the host os).
--@args cleanup Set to <code>1</code> or <code>true</code> to simply clean up any mess we made (leftover files, processes, etc. on the host OS).
-- This will attempt to delete the files from every share, not just the first one. This is done to prevent leftover
-- files if the OS changes the ordering of the shares (there's no guarantee of shares coming back in any particular
-- order)
@@ -391,14 +390,14 @@ Some ideas for later versions:
-- delete files, open the services manager, etc.
--@args share Set to override the share used for uploading. This also stops shares from being enumerated, and all other shares
-- will be ignored. No checks are done to determine whether or not this is a valid share before using it. Reqires
-- 'sharepath' to be set.
--@args sharepath The full path to the share (eg, "c:\windows"). This is required when creating a service.
--@args time The minimum amount of time, in seconds, to wait for the external module to finish (default: 15)
-- <code>sharepath</code> to be set.
--@args sharepath The full path to the share (eg, <code>"c:\windows"</code>). This is required when creating a service.
--@args time The minimum amount of time, in seconds, to wait for the external module to finish (default: <code>15</code>)
--
--@args nocleanup If set to '1' or 'true', don't clean up at all; this leaves the files on the remote system and the wrapper
-- service instaleld. This is bad in practice, but significantly reduces the network traffic and makes analysis
--@args nocleanup If set to <code>1</code> or <code>true</code>, don't clean up at all; this leaves the files on the remote system and the wrapper
-- service installed. This is bad in practice, but significantly reduces the network traffic and makes analysis
-- easier.
--@args nocipher Set to '1' or 'true' to disable the ciphering of the returned text (useful for debugging).
--@args nocipher Set to <code>1</code> or <code>true</code> to disable the ciphering of the returned text (useful for debugging).
--@args key Script uses this value instead of a random encryption key (useful for debugging the crypto).
-----------------------------------------------------------------------

2
scripts/smb-security-mode.nse
View File

@@ -5,7 +5,7 @@ Here is how to interpret the output:
* User-level authentication: Each user has a separate username/password that is used to log into the system. This is the default setup of pretty much everything these days.
* Share-level authentication: The anonymous account should be used to log in, then the password is given (in plaintext) when a share is accessed. All users who have access to the share use this password. This was the original way of doing things, but isn't commonly seen, now. If a server uses share-level security, it is vulnerable to sniffing.
* Challenge/response passwords supported: If enabled, the server can accept any type of password (plaintext, LM and NTLM, and LMv2 and NTLMv2). If it isn't set, the server can only accept plaintext passwords. Most servers are configured to use challenge/response these days. If a server is configured to accept plaintext passwords, it is vulnerable to sniffing. LM and NTLM are fairly secure, although there are some brute-force attacks against them. Additionally, LM and NTLM can fall victim to man-in-the-middle attacks or relay attacks (see MS08-068 or my writeup of it: <http://www.skullsecurity.org/blog/?p=110>.
* Challenge/response passwords supported: If enabled, the server can accept any type of password (plaintext, LM and NTLM, and LMv2 and NTLMv2). If it isn't set, the server can only accept plaintext passwords. Most servers are configured to use challenge/response these days. If a server is configured to accept plaintext passwords, it is vulnerable to sniffing. LM and NTLM are fairly secure, although there are some brute-force attacks against them. Additionally, LM and NTLM can fall victim to man-in-the-middle attacks or relay attacks (see MS08-068 or my writeup of it: http://www.skullsecurity.org/blog/?p=110.
* Message signing: If required, all messages between the client and server must be signed by a shared key, derived from the password and the server challenge. If supported and not required, message signing is negotiated between clients and servers and used if both support and request it. By default, Windows clients don't sign messages, so if message signing isn't required by the server, messages probably won't be signed; additionally, if performing a man-in-the-middle attack, an attacker can negotiate no message signing. If message signing isn't required, the server is vulnerable to man-in-the-middle attacks or SMB-relay attacks.
This script will allow you to use the <code>smb*</code> script arguments (to

2
scripts/smb-system-info.nse
View File

@@ -11,7 +11,7 @@ If you know of more information stored in the Windows registry that could be int
post a message to the nmap-dev mailing list and I (Ron Bowes) will add it to my todo list.
Adding new checks to this is extremely easy.
WARNING: I have experienced crashes in regsvc.exe while making registry calls
WARNING: I have experienced crashes in <code>regsvc.exe</code> while making registry calls
against a fully patched Windows 2000 system; I've fixed the issue that caused it,
but there's no guarantee that it (or a similar vuln in the same code) won't show
up again. Since the process automatically restarts, it doesn't negatively impact

3
scripts/smbv2-enabled.nse
View File

@@ -1,5 +1,5 @@
description = [[
Check whether or not a server is running the SMBv2 protocol.
Checks whether or not a server is running the SMBv2 protocol.
]]
---
--@usage
@@ -12,7 +12,6 @@ Check whether or not a server is running the SMBv2 protocol.
--
-- Host script results:
-- |_ smb-v2-enabled: Server doesn't support SMBv2 protocol
-----------------------------------------------------------------------
author = "Ron Bowes"
copyright = "Ron Bowes"

2
scripts/smtp-commands.nse
View File

@@ -13,7 +13,7 @@ SMTP server.
-- | smtp-commands: SMTP.domain.com Hello [172.x.x.x], TURN, SIZE, ETRN, PIPELINING, DSN, ENHANCEDSTATUSCODES, 8bitmime, BINARYMIME, CHUNKING, VRFY, X-EXPS GSSAPI NTLM LOGIN, X-EXPS=LOGIN, AUTH GSSAPI NTLM LOGIN, AUTH=LOGIN, X-LINK2STATE, XEXCH50, OK
-- |_ This server supports the following commands: HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY
--
-- @args smtp-commands.domain Define the domain to be used in the SMTP commands
-- @args smtp-commands.domain Define the domain to be used in the SMTP commands.
-- changelog
-- 1.1.0.0 - 2007-10-12

2
scripts/smtp-enum-users.nse
View File

@@ -12,7 +12,7 @@ The user can specify which methods to use and in which order. The script will ig
repeated methods. If not specified the script will use the RCPT first, then VRFY and EXPN.
An example of how to specify the methods to use and the order is the following:
smtp-enum-users.methods={EXPN,RCPT,VRFY}
<code>smtp-enum-users.methods={EXPN,RCPT,VRFY}</code>
]]
---

2
scripts/snmp-interfaces.nse
View File

@@ -1,5 +1,5 @@
description = [[
Attempts to enumerate network interfaces through SNMP
Attempts to enumerate network interfaces through SNMP.
]]
---

2
scripts/snmp-netstat.nse
View File

@@ -1,5 +1,5 @@
description = [[
Attempts to query SNMP for a netstat like output
Attempts to query SNMP for a netstat like output.
]]
---

2
scripts/snmp-processes.nse
View File

@@ -1,5 +1,5 @@
description = [[
Attempts to enumerate running processes through SNMP
Attempts to enumerate running processes through SNMP.
]]
---

2
scripts/snmp-win32-services.nse
View File

@@ -1,5 +1,5 @@
description = [[
Attempts to enumerate Windows Services through SNMP
Attempts to enumerate Windows services through SNMP.
]]
---

2
scripts/snmp-win32-shares.nse
View File

@@ -1,5 +1,5 @@
description = [[
Attempts to enumerate Windows Shares through SNMP
Attempts to enumerate Windows Shares through SNMP.
]]
---

2
scripts/snmp-win32-software.nse
View File

@@ -1,5 +1,5 @@
description = [[
Attempts to enumerate installed software through SNMP
Attempts to enumerate installed software through SNMP.
]]
---

8
scripts/socks-open-proxy.nse
View File

@@ -6,12 +6,12 @@ socks5 payloads. It is considered an open proxy if the script receives
a Request Granted response from the target port.
The payloads try to open a connection to www.google.com port 80. A
different test host can be passed as openproxy.host (note the table
syntax in the example) argument, as described below.
different test host can be passed as <code>proxy.url</code>
argument.
]]
---
--@args proxy.url Url that will be requested to the proxy
--@args proxy.pattern Pattern that will be searched inside the request results
--@args proxy.url URL that will be requested to the proxy.
--@args proxy.pattern Pattern that will be searched inside the request results.
--@output
-- Interesting ports on scanme.nmap.org (64.13.134.52):
-- PORT STATE SERVICE

4
scripts/telnet-brute.nse
View File

@@ -1,7 +1,5 @@
description = [[
Tries to get Telnet login credentials by guessing usernames and passwords.
Update (Ron Bowes, November, 2009): Now uses unpwdb database.
]]
author = "Eddie Bell, Ron Bowes"
@@ -14,6 +12,8 @@ categories = {'auth', 'intrusive'}
-- 23/tcp open telnet
-- |_telnet-brute: root - 1234
-- Update (Ron Bowes, November, 2009): Now uses unpwdb database.
require('shortport')
require('stdnse')
require('strbuf')

6
scripts/x11-access.nse
View File

@@ -1,15 +1,15 @@
-- NSE x11-access v1.3
description = [[
Checks if you're allowed to connect to the X server
Checks if you're allowed to connect to the X server.
If the X server is listening on TCP port 6000+n (where n is the display
number), it is possible to check if you're able to get connected to the
remote display by sending a X11 initial connection request.
In reply, the success byte (0x00 or 0x01) will determine if you are in
the "xhost +" list. In this case, script will display the message: "X
server access is granted".
the <code>xhost +</code> list. In this case, script will display the message:
<code>X server access is granted</code>.
]]
---