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

Merged in significant changes to Microsoft RPC calls

Browse Source
This commit is contained in:
ron
2008-12-07 16:16:11 +00:00
parent e6505d9954
commit ea42f39faa
15 changed files with 5107 additions and 1715 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -3,27 +3,23 @@ Returns information about the SMB security level determined by SMB.
Here is how to interpret the output:
User-level authentication: Each user has a separate username/password that is used
* 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
* 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
* 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.
Message signing: If required, all messages between the client and server must
* 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,
@@ -31,7 +27,7 @@ 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.
attacks or SMB-relay attacks.
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.
@@ -48,8 +44,8 @@ set the username and password, etc.), but it probably won't ever require them.
-- |_ smb-security-mode: Message signing supported
--
-- @args smb* This script supports the <code>smbusername</code>,
-- <code>smbpassword</code>, <code>smbhash</code>, <code>smbguest</code>, and
-- <code>smbtype</code> script arguments of the <code>smb</code> module.
-- <code>smbpassword</code>, <code>smbhash</code>, and <code>smbtype</code>
-- script arguments of the <code>smb</code> module.
-----------------------------------------------------------------------
author = "Ron Bowes"