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

Wrap long lines in NSE (>200 columns)

Browse Source 
Mostly in documentation (the description field, for instance), but also
some long literal strings. Lua 5.2 introduces a string escape, "\z",
which escapes any amount of subsequent whitespace, including newlines.
This can be used to wrap string literals without upsetting indentation.
http://www.lua.org/manual/5.2/manual.html#3.1
This commit is contained in:
dmiller
2014-02-13 15:47:35 +00:00
parent c9714990c7
commit b73c3aa60f
9 changed files with 461 additions and 178 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
nselib/mobileme.lua
View File

@@ -52,7 +52,19 @@ MobileMe = {
-- @return status true on success, false on failure -- @return status true on success, false on failure
-- @return err string containing the error message (if status is false) -- @return err string containing the error message (if status is false)
sendMessage = function(self, devid, subject, message, alarm) sendMessage = function(self, devid, subject, message, alarm)
local data = '{"clientContext":{"appName":"FindMyiPhone","appVersion":"1.3","buildVersion":"145","deviceUDID":"0000000000000000000000000000000000000000","inactiveTime":5911,"osVersion":"3.2","productType":"iPad1,1","selectedDevice":"%s","shouldLocate":false},"device":"%s","serverContext":{"callbackIntervalInMS":3000,"clientId":"0000000000000000000000000000000000000000","deviceLoadStatus":"203","hasDevices":true,"lastSessionExtensionTime":null,"maxDeviceLoadTime":60000,"maxLocatingTime":90000,"preferredLanguage":"en","prefsUpdateTime":1276872996660,"sessionLifespan":900000,"timezone":{"currentOffset":-25200000,"previousOffset":-28800000,"previousTransition":1268560799999,"tzCurrentName":"Pacific Daylight Time","tzName":"America/Los_Angeles"},"validRegion":true},"sound":%s,"subject":"%s","text":"%s"}' local data = '{"clientContext":{"appName":"FindMyiPhone","appVersion":\z
"1.3","buildVersion":"145","deviceUDID":\z
"0000000000000000000000000000000000000000","inactiveTime":5911,\z
"osVersion":"3.2","productType":"iPad1,1","selectedDevice":"%s",\z
"shouldLocate":false},"device":"%s","serverContext":{\z
"callbackIntervalInMS":3000,"clientId":\z
"0000000000000000000000000000000000000000","deviceLoadStatus":"203",\z
"hasDevices":true,"lastSessionExtensionTime":null,"maxDeviceLoadTime":\z
60000,"maxLocatingTime":90000,"preferredLanguage":"en","prefsUpdateTime":\z
1276872996660,"sessionLifespan":900000,"timezone":{"currentOffset":\z
-25200000,"previousOffset":-28800000,"previousTransition":1268560799999,\z
"tzCurrentName":"Pacific Daylight Time","tzName":"America/Los_Angeles"},\z
"validRegion":true},"sound":%s,"subject":"%s","text":"%s"}'
data = data:format(devid, devid, tostring(alarm), subject, message) data = data:format(devid, devid, tostring(alarm), subject, message)
local url = ("/fmipservice/device/%s/sendMessage"):format(self.username) local url = ("/fmipservice/device/%s/sendMessage"):format(self.username)
@@ -87,7 +99,10 @@ MobileMe = {
} }
local url = ("/fmipservice/device/%s/initClient"):format(self.username) local url = ("/fmipservice/device/%s/initClient"):format(self.username)
local data= '{"clientContext":{"appName":"FindMyiPhone","appVersion":"1.3","buildVersion":"145","deviceUDID":"0000000000000000000000000000000000000000","inactiveTime":2147483647,"osVersion":"4.2.1","personID":0,"productType":"iPad1,1"}}' local data= '{"clientContext":{"appName":"FindMyiPhone","appVersion":\z
"1.3","buildVersion":"145","deviceUDID":\z
"0000000000000000000000000000000000000000","inactiveTime":2147483647,\z
"osVersion":"4.2.1","personID":0,"productType":"iPad1,1"}}'
local retries = 2 local retries = 2

61
scripts/couchdb-stats.nse
View File

@@ -94,9 +94,64 @@ action = function(host, port)
return msg return msg
end end
-- The html body should look like this : -- The html body should look like this (minus whitespace):
-- --[[
--{"httpd_status_codes":{"200":{"current":10,"count":29894,"mean":0.0003345152873486337,"min":0,"max":1,"stddev":0.01828669972606202,"description":"number of HTTP 200 OK responses"},"500":{"current":1,"count":28429,"mean":0.00003517534911534013,"min":0,"max":1,"stddev":0.005930776661631644,"description":"number of HTTP 500 Internal Server Error responses"}},"httpd_request_methods":{"GET":{"current":12,"count":29894,"mean":0.00040141834481835866,"min":0,"max":2,"stddev":0.02163701147572207,"description":"number of HTTP GET requests"}},"httpd":{"requests":{"current":12,"count":29894,"mean":0.00040141834481835866,"min":0,"max":2,"stddev":0.02163701147572207,"description":"number of HTTP requests"}},"couchdb":{"request_time":{"current":23,"count":12,"mean":32.58333333333333,"min":1,"max":287,"stddev":77.76723638882608,"description":"length of a request inside CouchDB without MochiWeb"}}} {
"httpd_status_codes": {
"200": {
"count": 29894,
"description": "number of HTTP 200 OK responses",
"min": 0,
"max": 1,
"current": 10,
"stddev": 0.01828669972606202,
"mean": 0.0003345152873486337
},
"500": {
"count": 28429,
"description": "number of HTTP 500 Internal Server Error responses",
"min": 0,
"max": 1,
"current": 1,
"stddev": 0.005930776661631644,
"mean": 3.517534911534013e-05
}
},
"httpd": {
"requests": {
"count": 29894,
"description": "number of HTTP requests",
"min": 0,
"max": 2,
"current": 12,
"stddev": 0.02163701147572207,
"mean": 0.00040141834481835866
}
},
"couchdb": {
"request_time": {
"count": 12,
"description": "length of a request inside CouchDB without MochiWeb",
"min": 1,
"max": 287,
"current": 23,
"stddev": 77.76723638882608,
"mean": 32.58333333333333
}
},
"httpd_request_methods": {
"GET": {
"count": 29894,
"description": "number of HTTP GET requests",
"min": 0,
"max": 2,
"current": 12,
"stddev": 0.02163701147572207,
"mean": 0.00040141834481835866
}
}
}
]]--
local status, result = json.parse(data.body) local status, result = json.parse(data.body)
if not status then if not status then

37
scripts/flume-master-info.nse
View File

@@ -19,8 +19,8 @@ Information gathered:
If this script is run wth -v, it will output lots more info. If this script is run wth -v, it will output lots more info.
Use the <code>newtargets</code> script argument to add discovered hosts to the Use the <code>newtargets</code> script argument to add discovered hosts to
Namp scan queue. the Nmap scan queue.
]] ]]
--- ---
@@ -89,7 +89,8 @@ portrule = function(host, port)
-- Run for the special port number, or for any HTTP-like service that is -- Run for the special port number, or for any HTTP-like service that is
-- not on a usual HTTP port. -- not on a usual HTTP port.
return shortport.port_or_service ({35871}, "flume-master")(host, port) return shortport.port_or_service ({35871}, "flume-master")(host, port)
or (shortport.service(shortport.LIKELY_HTTP_SERVICES)(host, port) and not shortport.portnumber(shortport.LIKELY_HTTP_PORTS)(host, port)) or (shortport.service(shortport.LIKELY_HTTP_SERVICES)(host, port)
and not shortport.portnumber(shortport.LIKELY_HTTP_PORTS)(host, port))
end end
function add_target(hostname) function add_target(hostname)
@@ -137,8 +138,34 @@ action = function( host, port )
local uri = "/flumemaster.jsp" local uri = "/flumemaster.jsp"
local env_uri = "/masterenv.jsp" local env_uri = "/masterenv.jsp"
local config_uri = "/masterstaticconfig.jsp" local config_uri = "/masterstaticconfig.jsp"
local env_keys = {"java.runtime","java.version","java.vm.name","java.vm.vendor","java.vm.version","os","user.name","user.country","user.language,user.timezone"} local env_keys = {
local config_keys = {"dfs.datanode.address","dfs.datanode.http.address","dfs.datanode.https.address","dfs.datanode.ipc.address","dfs.http.address","dfs.https.address","dfs.secondary.http.address","flume.collector.dfs.dir","flume.collector.event.host","flume.master.servers","fs.default.name","mapred.job.tracker","mapred.job.tracker.http.address","mapred.task.tracker.http.address","mapred.task.tracker.report.address"} "java.runtime",
"java.version",
"java.vm.name",
"java.vm.vendor",
"java.vm.version",
"os",
"user.name",
"user.country",
"user.language,user.timezone"
}
local config_keys = {
"dfs.datanode.address",
"dfs.datanode.http.address",
"dfs.datanode.https.address",
"dfs.datanode.ipc.address",
"dfs.http.address",
"dfs.https.address",
"dfs.secondary.http.address",
"flume.collector.dfs.dir",
"flume.collector.event.host",
"flume.master.servers",
"fs.default.name",
"mapred.job.tracker",
"mapred.job.tracker.http.address",
"mapred.task.tracker.http.address",
"mapred.task.tracker.report.address"
}
local nodes = { } local nodes = { }
local zookeepers = { } local zookeepers = { }
local hbasemasters = { } local hbasemasters = { }

28
scripts/http-coldfusion-subzero.nse
View File

@@ -1,5 +1,7 @@
description = [[ description = [[
Attempts to retrieve version, absolute path of administration panel and the file 'password.properties' from vulnerable installations of ColdFusion 9 and 10. Attempts to retrieve version, absolute path of administration panel and the
file 'password.properties' from vulnerable installations of ColdFusion 9 and
10.
This was based on the exploit 'ColdSub-Zero.pyFusion v2'. This was based on the exploit 'ColdSub-Zero.pyFusion v2'.
]] ]]
@@ -20,10 +22,8 @@ This was based on the exploit 'ColdSub-Zero.pyFusion v2'.
-- |_encrypted=true -- |_encrypted=true
-- --
-- @xmloutput -- @xmloutput
-- <script id="http-coldfusion-subzero" output="&#xa; installation_path: C:\inetpub\wwwroot\CFIDE\adminapi\customtags&#xa; version: 9&#xa; password_properties: #Fri Mar 02 17:03:01 CST 2012&#xd;&#xa;rdspassword=&#xd;&#xa;password=AA251FD567358F16B7DE3F3B22DE8193A7517CD0&#xd;&#xa;encrypted=true&#xd;&#xa;"><elem key="installation_path">C:\inetpub\wwwroot\CFIDE\adminapi\customtags</elem>
-- <elem key="version">9</elem> -- <elem key="version">9</elem>
-- <elem key="password_properties">#Fri Mar 02 17:03:01 CST 2012&#xd;&#xa;rdspassword=&#xd;&#xa;password=AA251FD567358F16B7DE3F3B22DE8193A7517CD0&#xd;&#xa;encrypted=true&#xd;&#xa;</elem> -- <elem key="password_properties">#Fri Mar 02 17:03:01 CST 2012&#xd;&#xa;rdspassword=&#xd;&#xa;password=AA251FD567358F16B7DE3F3B22DE8193A7517CD0&#xd;&#xa;encrypted=true&#xd;&#xa;</elem>
-- </script>
-- @args http-coldfusion-subzero.basepath Base path. Default: /. -- @args http-coldfusion-subzero.basepath Base path. Default: /.
-- --
--- ---
@@ -41,10 +41,16 @@ local openssl = stdnse.silent_require "openssl"
portrule = shortport.http portrule = shortport.http
local PATH_PAYLOAD = "CFIDE/adminapi/customtags/l10n.cfm?attributes.id=it&attributes.file=../../administrator/analyzer/index.cfm&attributes.locale=it&attributes.var=it&attributes.jscript=false&attributes.type=text/html&attributes.charset=UTF-8&thisTag.executionmode=end&thisTag.generatedContent=htp" local PATH_PAYLOAD = "CFIDE/adminapi/customtags/l10n.cfm?attributes.id=it&\z
attributes.file=../../administrator/analyzer/index.cfm&attributes.locale=it&\z
attributes.var=it&attributes.jscript=false&attributes.type=text/html&\z
attributes.charset=UTF-8&thisTag.executionmode=end&thisTag.generatedContent=htp"
local IMG_PAYLOAD = "CFIDE/administrator/images/loginbackground.jpg" local IMG_PAYLOAD = "CFIDE/administrator/images/loginbackground.jpg"
local LFI_PAYLOAD_FRAG_1 = "CFIDE/adminapi/customtags/l10n.cfm?attributes.id=it&attributes.file=../../administrator/mail/download.cfm&filename=" local LFI_PAYLOAD_FRAG_1 = "CFIDE/adminapi/customtags/l10n.cfm?attributes.id\z
local LFI_PAYLOAD_FRAG_2 = "&attributes.locale=it&attributes.var=it&attributes.jscript=false&attributes.type=text/html&attributes.charset=UTF-8&thisTag.executionmode=end&thisTag.generatedContent=htp" =it&attributes.file=../../administrator/mail/download.cfm&filename="
local LFI_PAYLOAD_FRAG_2 = "&attributes.locale=it&attributes.var=it&\z
attributes.jscript=false&attributes.type=text/html&attributes.charset=UTF-8&\z
thisTag.executionmode=end&thisTag.generatedContent=htp"
local CREDENTIALS_PAYLOADS = { local CREDENTIALS_PAYLOADS = {
"../../lib/password.properties", "../../lib/password.properties",
"..\\..\\lib\\password.properties", "..\\..\\lib\\password.properties",
@@ -59,13 +65,15 @@ local CREDENTIALS_PAYLOADS = {
} }
--- ---
-- Extracts absolute path of installation by reading the ANALIZER_DIRECTORY value from the header 'set-cookie' -- Extracts absolute path of installation by reading the ANALIZER_DIRECTORY
-- value from the header 'set-cookie'
-- --
local function get_installation_path(host, port, basepath) local function get_installation_path(host, port, basepath)
local req = http.get(host, port, basepath..PATH_PAYLOAD) local req = http.get(host, port, basepath..PATH_PAYLOAD)
if req.header['set-cookie'] then if req.header['set-cookie'] then
stdnse.print_debug(1, "%s:Header 'set-cookie' detected in response.", SCRIPT_NAME) stdnse.print_debug(1, "%s:Header 'set-cookie' detected in response.", SCRIPT_NAME)
local _, _, path = string.find(req.header['set-cookie'], "path=/, ANALYZER_DIRECTORY=(.-);path=/") local _, _, path = string.find(req.header['set-cookie'],
"path=/, ANALYZER_DIRECTORY=(.-);path=/")
if path then if path then
stdnse.print_debug(1, "%s: Extracted path:%s", SCRIPT_NAME, path) stdnse.print_debug(1, "%s: Extracted path:%s", SCRIPT_NAME, path)
return path return path
@@ -105,7 +113,9 @@ local function exploit(host, port, basepath)
for i, vector in ipairs(CREDENTIALS_PAYLOADS) do for i, vector in ipairs(CREDENTIALS_PAYLOADS) do
local req = http.get(host, port, basepath..LFI_PAYLOAD_FRAG_1..vector..LFI_PAYLOAD_FRAG_2) local req = http.get(host, port, basepath..LFI_PAYLOAD_FRAG_1..vector..LFI_PAYLOAD_FRAG_2)
if req.body and string.find(req.body, "encrypted=true") then if req.body and string.find(req.body, "encrypted=true") then
stdnse.print_debug(1, "%s: String pattern found. Exploitation worked with vector '%s'.", SCRIPT_NAME, vector) stdnse.print_debug(1,
"%s: String pattern found. Exploitation worked with vector '%s'.",
SCRIPT_NAME, vector)
return true, req.body return true, req.body
end end
end end

52
scripts/p2p-conficker.nse
View File

@@ -10,29 +10,36 @@ local string = require "string"
local table = require "table" local table = require "table"
description = [[ description = [[
Checks if a host is infected with Conficker.C or higher, based on Conficker's peer to peer communication. Checks if a host is infected with Conficker.C or higher, based on
Conficker's peer to peer communication.
When Conficker.C or higher infects a system, it opens four ports: two TCP and two UDP. The ports are When Conficker.C or higher infects a system, it opens four ports: two TCP
random, but are seeded with the current week and the IP of the infected host. By determining the algorithm, and two UDP. The ports are random, but are seeded with the current week and
one can check if these four ports are open, and can probe them for more data. the IP of the infected host. By determining the algorithm, one can check if
these four ports are open, and can probe them for more data.
Once the open ports are found, communication can be initiated using Conficker's custom peer to peer protocol. Once the open ports are found, communication can be initiated using
If a valid response is received, then a valid Conficker infection has been found. Conficker's custom peer to peer protocol. If a valid response is received,
then a valid Conficker infection has been found.
This check won't work properly on a multihomed or NATed system because the open ports will be based on a nonpublic IP. This check won't work properly on a multihomed or NATed system because the
The argument <code>checkall</code> tells Nmap to attempt communication with every open port (much like a version open ports will be based on a nonpublic IP. The argument
check) and the argument <code>realip</code> tells Nmap to base its port generation on the given IP address instead <code>checkall</code> tells Nmap to attempt communication with every open
of the actual IP. port (much like a version check) and the argument <code>realip</code> tells
Nmap to base its port generation on the given IP address instead of the
actual IP.
By default, this will run against a system that has a standard Windows port open (445, 139, 137). The arguments By default, this will run against a system that has a standard Windows port
<code>checkall</code> and <code>checkconficker</code> will both perform checks regardless of which port is open, see the args section for open (445, 139, 137). The arguments <code>checkall</code> and
more information. <code>checkconficker</code> will both perform checks regardless of which
port is open, see the args section for more information.
Note: Ensure your clock is correct (within a week) before using this script! Note: Ensure your clock is correct (within a week) before using this script!
The majority of research for this script was done by Symantec Security Response, and some was taken The majority of research for this script was done by Symantec Security
from public sources (most notably the port blacklisting was found by David Fifield). A big thanks goes Response, and some was taken from public sources (most notably the port
out to everybody who contributed! blacklisting was found by David Fifield). A big thanks goes out to everybody
who contributed!
]] ]]
--- ---
@@ -179,7 +186,18 @@ end
local function is_blacklisted_port(port) local function is_blacklisted_port(port)
local r, l local r, l
local blacklist = { 0xFFFFFFFF, 0xFFFFFFFF, 0xF0F6BFBB, 0xBB5A5FF3, 0xF3977011, 0xEB67BFBF, 0x5F9BFAC8, 0x34D88091, 0x1E2282DF, 0x573402C4, 0xC0000084, 0x03000209, 0x01600002, 0x00005000, 0x801000C0, 0x00500040, 0x000000A1, 0x01000000, 0x01000000, 0x00022A20, 0x00000080, 0x04000000, 0x40020000, 0x88000000, 0x00000180, 0x00081000, 0x08801900, 0x00800B81, 0x00000280, 0x080002C0, 0x00A80000, 0x00008000, 0x00100040, 0x00100000, 0x00000000, 0x00000000, 0x10000008, 0x00000000, 0x00000000, 0x00000004, 0x00000002, 0x00000000, 0x00040000, 0x00000000, 0x00000000, 0x00000000, 0x00410000, 0x82000000, 0x00000000, 0x00000000, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000008, 0x80000000, }; local blacklist = { 0xFFFFFFFF, 0xFFFFFFFF, 0xF0F6BFBB, 0xBB5A5FF3,
0xF3977011, 0xEB67BFBF, 0x5F9BFAC8, 0x34D88091, 0x1E2282DF, 0x573402C4,
0xC0000084, 0x03000209, 0x01600002, 0x00005000, 0x801000C0, 0x00500040,
0x000000A1, 0x01000000, 0x01000000, 0x00022A20, 0x00000080, 0x04000000,
0x40020000, 0x88000000, 0x00000180, 0x00081000, 0x08801900, 0x00800B81,
0x00000280, 0x080002C0, 0x00A80000, 0x00008000, 0x00100040, 0x00100000,
0x00000000, 0x00000000, 0x10000008, 0x00000000, 0x00000000, 0x00000004,
0x00000002, 0x00000000, 0x00040000, 0x00000000, 0x00000000, 0x00000000,
0x00410000, 0x82000000, 0x00000000, 0x00000000, 0x00000001, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000008, 0x80000000,
}
r = bit.rshift(port, 5) r = bit.rshift(port, 5)
l = bit.lshift(1, bit.band(r, 0x1f)) l = bit.lshift(1, bit.band(r, 0x1f))

385
scripts/smb-psexec.nse
View File

@@ -10,30 +10,36 @@ local string = require "string"
local table = require "table" local table = require "table"
description = [[ description = [[
Implements remote process execution similar to the Sysinternals' psexec tool, Implements remote process execution similar to the Sysinternals' psexec
allowing a user to run a series of programs on a remote machine and read the output. This tool, allowing a user to run a series of programs on a remote machine and
is great for gathering information about servers, running the same tool on a range of read the output. This is great for gathering information about servers,
system, or even installing a backdoor on a collection of computers. running the same tool on a range of system, or even installing a backdoor on
a collection of computers.
This script can run commands present on the remote machine, such as ping or tracert, This script can run commands present on the remote machine, such as ping or
or it can upload a program and run it, such as pwdump6 or a backdoor. Additionally, it tracert, or it can upload a program and run it, such as pwdump6 or a
can read the program's stdout/stderr and return it to the user (works well with ping, backdoor. Additionally, it can read the program's stdout/stderr and return
pwdump6, etc), or it can read a file that the process generated (fgdump, for example, it to the user (works well with ping, pwdump6, etc), or it can read a file
generates a file), or it can just start the process and let it run headless (a backdoor that the process generated (fgdump, for example, generates a file), or it
might run like this). can just start the process and let it run headless (a backdoor might run
like this).
To use this, a configuration file should be created and edited. Several configuration To use this, a configuration file should be created and edited. Several
files are included that you can customize, or you can write your own. This config file configuration files are included that you can customize, or you can write
is placed in <code>nselib/data/psexec</code> (if you aren't sure where that is, search your system your own. This config file is placed in <code>nselib/data/psexec</code> (if
for <code>default.lua</code>), then is passed to Nmap as a script argument (for example, you aren't sure where that is, search your system for
myconfig.lua would be passed as <code>--script-args=config=myconfig</code>. <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 The configuration file consists mainly of a module list. Each module is
table, and contains fields for the name of the program, the executable and arguments defined by a lua table, and contains fields for the name of the program, the
for the program, and a score of other options. Modules also have an 'upload' field, which executable and arguments for the program, and a score of other options.
determines whether or not the module is to be uploaded. Here is a simple example of how Modules also have an 'upload' field, which determines whether or not the
to run <code>net localgroup administrators</code>, which returns a list of users in the "administrators" module is to be uploaded. Here is a simple example of how to run <code>net
group (take a look at the <code>examples.lua</code> configuration file for these examples): 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> <code>
mod = {} mod = {}
@@ -44,11 +50,12 @@ group (take a look at the <code>examples.lua</code> configuration file for these
table.insert(modules, mod) table.insert(modules, mod)
</code> </code>
<code>mod.upload</code> is <code>false</code>, meaning the program should already be <code>mod.upload</code> is <code>false</code>, meaning the program should
present on the remote system (since 'net.exe' is on every version of Windows, this should already be present on the remote system (since 'net.exe' is on every version
be the case). <code>mod.name</code> defines the name that the program will have in the of Windows, this should be the case). <code>mod.name</code> defines the name
output. <code>mod.program</code> and <code>mod.args</code> obviously define which program that the program will have in the output. <code>mod.program</code> and
is going to be run. The output for this script is this: <code>mod.args</code> obviously define which program is going to be run. The
output for this script is this:
<code> <code>
| Example 1: Membership of 'administrators' | Example 1: Membership of 'administrators'
@@ -66,11 +73,12 @@ is going to be run. The output for this script is this:
| |_ | |_
</code> </code>
That works, but it's really ugly. In general, we can use <code>mod.find</code>, That works, but it's really ugly. In general, we can use
<code>mod.replace</code>, <code>mod.remove</code>, and <code>mod.noblank</code> to clean up <code>mod.find</code>, <code>mod.replace</code>, <code>mod.remove</code>,
the output. For this example, we're going to use <code>mod.remove</code> to remove a lot and <code>mod.noblank</code> to clean up the output. For this example, we're
of the useless lines, and <code>mod.noblank</code> to get rid of the blank lines that we going to use <code>mod.remove</code> to remove a lot of the useless lines,
don't want: and <code>mod.noblank</code> to get rid of the blank lines that we don't
want:
<code> <code>
mod = {} mod = {}
@@ -84,6 +92,7 @@ don't want:
</code> </code>
We can see that the output is now much cleaner: We can see that the output is now much cleaner:
<code> <code>
| Example 2: Membership of 'administrators', cleaned | Example 2: Membership of 'administrators', cleaned
| | Administrator | | Administrator
@@ -91,10 +100,10 @@ We can see that the output is now much cleaner:
| |_test | |_test
</code> </code>
For our next command, we're going to run Windows' ipconfig.exe, which outputs a significant For our next command, we're going to run Windows' ipconfig.exe, which
amount of unnecessary information, and what we do want isn't formatted very nicely. All we outputs a significant amount of unnecessary information, and what we do want
want is the IP address and MAC address, and we get it using <code>mod.find</code> and isn't formatted very nicely. All we want is the IP address and MAC address,
<code>mod.replace</code>: and we get it using <code>mod.find</code> and <code>mod.replace</code>:
<code> <code>
mod = {} mod = {}
@@ -108,10 +117,11 @@ want is the IP address and MAC address, and we get it using <code>mod.find</code
table.insert(modules, mod) table.insert(modules, mod)
</code> </code>
This module searches for lines that contain "IP Address", "Physical Address", or "Ethernet adapter". This module searches for lines that contain "IP Address", "Physical
In these lines, a ". " is replaced with nothing, a "-" is replaced with a colon, and the term Address", or "Ethernet adapter". In these lines, a ". " is replaced with
"Physical Address" is replaced with "MAC Address" (arguably unnecessary). Run ipconfig /all yourself nothing, a "-" is replaced with a colon, and the term "Physical Address" is
to see what we start with, but here's the final output: replaced with "MAC Address" (arguably unnecessary). Run ipconfig /all
yourself to see what we start with, but here's the final output:
<code> <code>
| Example 3: IP Address and MAC Address | Example 3: IP Address and MAC Address
@@ -120,20 +130,25 @@ to see what we start with, but here's the final output:
| |_ IP Address: 192.168.1.21| Example 3: IP Address and MAC Address | |_ IP Address: 192.168.1.21| Example 3: IP Address and MAC Address
</code> </code>
Another interesting part of this script is that variables can be used in any script fields. There Another interesting part of this script is that variables can be used in any
are two types of variables: built-in and user-supplied. Built-in variables can be anything found script fields. There are two types of variables: built-in and user-supplied.
in the <code>config</code> table, most of which are listed below. The more interesting ones are: Built-in variables can be anything found in the <code>config</code> table,
most of which are listed below. The more interesting ones are:
* <code>$lhost</code>: The address of the scanner * <code>$lhost</code>: The address of the scanner
* <code>$rhost</code>: The address being scanned * <code>$rhost</code>: The address being scanned
* <code>$path</code>: The path where the scripts are uploaded * <code>$path</code>: The path where the scripts are uploaded
* <code>$share</code>: The share where the script was 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> User-supplied arguments are given on the commandline, and can be controlled
in the configuration file. Arguments are given by the user in --script-args; for example, to set $host by <code>mod.req_args</code> in the configuration file. Arguments are given
to '1.2.3.4', the user would pass in --script-args=host=1.2.3.4. To ensure the user passes in the host by the user in --script-args; for example, to set $host to '1.2.3.4', the
variable, <code>mod.req_args</code> would be set to <code>{'host'}</code>. user would pass in --script-args=host=1.2.3.4. To ensure the user passes in
the host variable, <code>mod.req_args</code> would be set to
<code>{'host'}</code>.
Here is a module that pings the local ip address: Here is a module that pings the local ip address:
<code> <code>
mod = {} mod = {}
mod.upload = false mod.upload = false
@@ -156,7 +171,9 @@ And the output:
| |_Reply from 192.168.1.100: bytes=32 time<1ms TTL=64 | |_Reply from 192.168.1.100: bytes=32 time<1ms TTL=64
</code> </code>
And this module pings an arbitrary address that the user is expected to give: And this module pings an arbitrary address that the user is expected to
give:
<code> <code>
mod = {} mod = {}
mod.upload = false mod.upload = false
@@ -170,8 +187,9 @@ And this module pings an arbitrary address that the user is expected to give:
table.insert(modules, mod) table.insert(modules, mod)
</code> </code>
And the output (note that we had to up the timeout so this would complete; we'll talk about override And the output (note that we had to up the timeout so this would complete;
values later): we'll talk about override values later):
<code> <code>
$ ./nmap -n -d -p445 --script=smb-psexec --script-args=smbuser=test,smbpass=test,config=examples,host=1.2.3.4 192.168.1.21 $ ./nmap -n -d -p445 --script=smb-psexec --script-args=smbuser=test,smbpass=test,config=examples,host=1.2.3.4 192.168.1.21
[...] [...]
@@ -183,9 +201,11 @@ $ ./nmap -n -d -p445 --script=smb-psexec --script-args=smbuser=test,smbpass=test
| |_Request timed out. | |_Request timed out.
</code> </code>
For the final example, we'll use the <code>upload</code> command to upload <code>fgdump.exe</code>, run it, For the final example, we'll use the <code>upload</code> command to upload
download its output file, and clean up its logfile. You'll have to put <code>fgdump.exe</code> <code>fgdump.exe</code>, run it, download its output file, and clean up its
in the same folder as the script for this to work: logfile. You'll have to put <code>fgdump.exe</code> in the same folder as
the script for this to work:
<code> <code>
mod = {} mod = {}
mod.upload = true mod.upload = true
@@ -197,114 +217,212 @@ in the same folder as the script for this to work:
mod.outfile = "127.0.0.1.pwdump" mod.outfile = "127.0.0.1.pwdump"
table.insert(modules, mod) table.insert(modules, mod)
</code> </code>
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 The <code>-l</code> argument for fgdump supplies the name of the logfile.
<code>nselib/data/psexec/</code>. And finally, <code>mod.outfile</code> is the file that is downloaded That file is listed in the <code>mod.tempfiles</code> field. What, exactly,
from the system. This is required because fgdump writes to an output file instead of to 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 <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>. stdout (pwdump6, for example, doesn't require <code>mod.outfile</code>.
Now that we've seen a few possible combinations of fields, I present a complete list of all Now that we've seen a few possible combinations of fields, I present a
fields available and what each of them do. Many of them will be familiar, but there are a complete list of all fields available and what each of them do. Many of them
few that aren't discussed in the examples: will be familiar, but there are a few that aren't discussed in the examples:
* <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>upload</code> (boolean) true if it's a local file to upload, false
* <code>name</code> (string) The name to display above the output. If this isn't given, <code>program</code> .. <code>args</code> are used. if it's already on the host machine. If
* <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>upload</code> is true, <code>program</code> has
* <code>args</code> (string) Arguments to pass to the process. to be in <code>nselib/data/psexec</code>.
* <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>name</code> (string) The name to display above the output. If this
* <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. isn't given, <code>program</code> .. <code>args</code>
* <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. are used.
* <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>program</code> (string) If <code>upload</code> is false, the name
* <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. (fully qualified or relative) of the program on the
* <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. remote system; if <code>upload</code> is true, the
* <code>noblank</code> (boolean) Setting this to true removes all blank lines from the output. name of the local file that will be uploaded (stored
* <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. in <code>nselib/data/psexec</code>).
* <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>args</code> (string) Arguments to pass to the process.
* <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>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>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>url</code> (string) A module where the user can download the
* <code>outfile</code> (string) If set, the specified file will be returned instead of stdout. uploadable file. Displayed if the uploadable file is
* <code>req_args</code> (string[]) An array of arguments that the user must set in <code>--script-args</code>. 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: Any field in the configuration file can contain variables, as discussed.
Here are some of the available built-in variables:
* <code>$lhost</code>: local IP address as a string. * <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>$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>$rhost</code>: remote IP address as a string.
* <code>$rport</code>: remote port. * <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>$lmac</code>: local MAC address as a string in the
* <code>$path</code>: the path where the file will be uploaded to. xx:xx:xx:xx:xx:xx format (note: requires root).
* <code>$service_name</code>: the name of the service that will be running this program * <code>$path</code>: the path where the file will be uploaded to.
* <code>$service_file</code>: the name of the executable file for the service * <code>$service_name</code>: the name of the service that will be running
* <code>$temp_output_file</code>: The (ciphered) file where the programs' output will be written before being renamed to $output_file this program
* <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>$service_file</code>: the name of the executable file for the
* <code>$timeout</code>: The total amount of time the script is going to run before it gives up and stops the process 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 * <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. * (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 In addition to modules, the configuration file can also contain overrides.
aren't useful, so I'm not going to go into great detail. Search <code>smb-psexec.nse</code> Most of these aren't useful, so I'm not going to go into great detail.
for any reference to the <code>config</code> table; any value in the <code>config</code> Search <code>smb-psexec.nse</code> for any reference to the
table can be overridden with the <code>overrides</code> table in the module. The most useful <code>config</code> table; any value in the <code>config</code> table can be
value to override is probably <code>timeout</code>. overridden with the <code>overrides</code> table in the module. The most
useful value to override is probably <code>timeout</code>.
Before and after scripts are run, and when there's an error, a cleanup is performed. in the Before and after scripts are run, and when there's an error, a cleanup is
cleanup, we attempt to stop the remote processes, delete all programs, output files, temporary performed. in the cleanup, we attempt to stop the remote processes, delete
files, extra files, etc. A lot of effort was put into proper cleanup, since making a mess on all programs, output files, temporary files, extra files, etc. A lot of
remote systems is a bad idea. effort was put into proper cleanup, since making a mess on remote systems is
a bad idea.
Now that I've talked at length about how to use this script, I'd like to spend some time Now that I've talked at length about how to use this script, I'd like to
talking about how it works. spend some time talking about how it works.
Running a script happens in several stages: Running a script happens in several stages:
1) An open fileshare is found that we can write to. Finding an open fileshare basically 1. An open fileshare is found that we can write to. Finding an open
consists of enumerating all shares and seeing which one(s) we have access to. 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.
they're uploaded, the name of each file is obfuscated. The obfuscation completely Before they're uploaded, the name of each file is obfuscated. The
renames the file, is unique for each source system, and doesn't change between multiple obfuscation completely renames the file, is unique for each source system,
runs. This obfuscation has the benefit of preventing filenames from overlapping if and doesn't change between multiple runs. This obfuscation has the benefit
multiple people are running this against the same computer, and also makes it more difficult of preventing filenames from overlapping if multiple people are running this
to determine their purposes. The reason for keeping them consistent for every run is to against the same computer, and also makes it more difficult to determine
make cleanup possible: a random filename, if the script somehow fails, will be left on their purposes. The reason for keeping them consistent for every run is to
the system. make cleanup possible: a random filename, if the script somehow fails, will
be left on the system.
3) A new service is created and started. The new service has a random name for the same 3. A new service is created and started. The new service has a random name
reason the files do, and points at the 'service wrapper' program that was uploaded. for the same reason the files do, and points at the 'service wrapper'
program that was uploaded.
4) The service runs the processes. 4. The service runs the processes. One by one, the processes are run and
their output is captured. The output is obfuscated using a simple (and
highly insecure) xor algorithm, which is designed to prevent casual sniffing
(but won't deter intelligent attackers). This data is put into a temporary
output file. When all the programs have finished, the file is renamed to the
final output file
One by one, the processes are run and their output is captured. The output is obfuscated 5. The output file is downloaded, and the cleanup is performced. The file
using a simple (and highly insecure) xor algorithm, which is designed to prevent casual being renamed triggers the final stage of the program, where the data is
sniffing (but won't deter intelligent attackers). This data is put into a temporary output downloaded and all relevant files are deleted.
file. When all the programs have finished, the file is renamed to the final output file
5) The output file is downloaded, and the cleanup is performced. The file being renamed 6. Output file, now decrypted, is formatted and displayed to the user.
triggers the final stage of the program, where the data is downloaded and all relevant
files are deleted.
6) Output file, now decrypted, is formatted and displayed to the user.
And that's how it works! And that's how it works!
Please post any questions, or suggestions for better modules, to dev@nmap.org. Please post any questions, or suggestions for better modules, to
dev@nmap.org.
And, as usual, since this tool can be dangerous and can easily be viewed as a malicious And, as usual, since this tool can be dangerous and can easily be viewed as
tool -- use this responsibly, and don't break any laws with it. a malicious tool -- use this responsibly, and don't break any laws with it.
Some ideas for later versions (TODO): 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.) * Set up a better environment for scripts (<code>PATH</code>,
* Let user specify an output file (per-script) so they can, for example, download binary files (don't think it's worthwhile). <code>SystemRoot</code>, etc). Without this, a lot of programs (especially
* Consider running the external programs in parallel (not sure if the benefits outweigh the drawbacks). ones that deal with network traffic) behave oddly.
* Let the config request the return code from the process instead of the output (not sure if doing this would be worth the effort). * Abstract the code required to run remote processes so other scripts can
* Check multiple shares in a single session to save packets (and see where else we can tighten up the amount of traffic). 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).
]] ]]
--- ---
@@ -744,7 +862,10 @@ local function get_config(host, config)
-- Make sure we got a proper modules array -- Make sure we got a proper modules array
if(type(modules) ~= "table") then if(type(modules) ~= "table") then
return false, string.format("The chosen configuration file, %s.lua, doesn't have a proper 'modules' table. If possible, it should be modified to have a public array called 'modules' that contains a list of all modules that will be run.", filename) return false, string.format("The chosen configuration file, %s.lua, \z
doesn't have a proper 'modules' table. If possible, it should be \z
modified to have a public array called 'modules' that contains a \z
list of all modules that will be run.", filename)
end end
-- Loop through the modules for some pre-processing -- Loop through the modules for some pre-processing

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

@@ -9,13 +9,36 @@ Returns information about the SMB security level determined by SMB.
Here is how to interpret the output: 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. * User-level authentication: Each user has a separate username/password that
* 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. is used to log into the system. This is the default setup of pretty much
* 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. everything these days.
* 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. * 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.
* 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 This script will allow you to use the <code>smb*</code> script arguments (to
set the username and password, etc.), but it probably won't ever require them. set the username and password, etc.), but it probably won't ever require
them.
]] ]]
--- ---

11
scripts/ssh-hostkey.nse
View File

@@ -14,11 +14,16 @@ local openssl = stdnse.silent_require "openssl"
description = [[ description = [[
Shows SSH hostkeys. Shows SSH hostkeys.
Shows the target SSH server's key fingerprint and (with high enough verbosity level) the public key itself. It records the discovered host keys in <code>nmap.registry</code> for use by other scripts. Output can be controlled with the <code>ssh_hostkey</code> script argument. Shows the target SSH server's key fingerprint and (with high enough
verbosity level) the public key itself. It records the discovered host keys
in <code>nmap.registry</code> for use by other scripts. Output can be
controlled with the <code>ssh_hostkey</code> script argument.
You may also compare the retrieved key with the keys in your known-hosts file using the <code>known-hosts</code> argument. You may also compare the retrieved key with the keys in your known-hosts
file using the <code>known-hosts</code> argument.
The script also includes a postrule that check for duplicate hosts using the gathered keys. The script also includes a postrule that check for duplicate hosts using the
gathered keys.
]] ]]
--- ---

13
scripts/teamspeak2-version.nse
View File

@@ -6,7 +6,8 @@ local stdnse = require "stdnse"
local string = require "string" local string = require "string"
description = [[ description = [[
Detects the TeamSpeak 2 voice communication server and attempts to determine version and configuration information. Detects the TeamSpeak 2 voice communication server and attempts to determine
version and configuration information.
A single UDP packet (a login request) is sent. If the server does not have a A single UDP packet (a login request) is sent. If the server does not have a
password set, the exact version, name, and OS type will also be reported on. password set, the exact version, name, and OS type will also be reported on.
@@ -21,7 +22,15 @@ author = "Marin Maržić"
license = "Same as Nmap--See http://nmap.org/book/man-legal.html" license = "Same as Nmap--See http://nmap.org/book/man-legal.html"
categories = { "version" } categories = { "version" }
local payload = "\xf4\xbe\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x002x\xba\x85\tTeamSpeak\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\nWindows XP\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00 \x00<\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08nickname\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" local payload = "\xf4\xbe\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\z
\x00\x002x\xba\x85\tTeamSpeak\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\z
\x00\x00\x00\x00\x00\x00\x00\x00\x00\nWindows XP\x00\x00\x00\x00\x00\x00\x00\z
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00 \x00<\x00\z
\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\z
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\z
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\z
\x00\x00\x00\x00\x00\x08nickname\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\z
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
portrule = shortport.version_port_or_service({8767}, "teamspeak2", "udp") portrule = shortport.version_port_or_service({8767}, "teamspeak2", "udp")