Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upNMap NSE smb-enum-shares and smb-ls won't work with some open shares (NT_STATUS_WERR_INVALID_NAME) #266
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
p-l-
Jan 5, 2016
Hi,
Congrats on that nice catch!
Before commit 4d0e7c9, smb-ls had no way to discover the shares to browse automatically and needed to have a share passed as a parameter.
You can still use this behavior by specifying --script-args smb-ls.share=OpenShare (in your case). Does it work with this?
The bug, IMO, is in smb-enum-shares: it should not consider that OpenShare is "not a file share".
The heuristic "a share of NT_STATUS_OBJECT_NAME_NOT_FOUND indicates this isn't a fileshare" seems to be wrong, but it would be interesting to know why it is used and see if we can refine it.
p-l-
commented
Jan 5, 2016
|
Hi, Congrats on that nice catch! Before commit 4d0e7c9, You can still use this behavior by specifying The bug, IMO, is in The heuristic "a share of |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
JPvRiel
Jan 26, 2016
For nmap 7.01, the smb-ls script fails an assertion in all three cases
- with or explicit credentials in
smbdomain,smbuserandsmbpasssupplied in--script-args - without credentials (try guest and anon/blank user)
- with
smb-ls.share=OpenSharespecified AND correct explicit credentials
Again, smbclient can enum the shares with anon user or an explicit user
Example full command (without debug)
nmap -PS445 -p445 --script=smb-enum-shares,smb-ls --script-args=ls.maxdepth=10,smbdomain=<DOMAIN>,smbuser=<USER>,smbpass='<PASSWORD>',smb-ls.share=PubShare <FQDN>
Starting Nmap 7.01 ( https://nmap.org ) at 2016-01-26 16:30 SAST
Nmap scan report for <FQDN> (<IP>)
Host is up (0.0026s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| smb-enum-shares:
| account_used: <DOMAIN>\<USER>
| ADMIN$:
| warning: Couldn't get details for share: NT_STATUS_WERR_ACCESS_DENIED (srvsvc.netsharegetinfo)
| Anonymous access: <none>
| Current user access: <none>
| C$:
| warning: Couldn't get details for share: NT_STATUS_WERR_ACCESS_DENIED (srvsvc.netsharegetinfo)
| Anonymous access: <none>
| Current user access: <none>
| D$:
| warning: Couldn't get details for share: NT_STATUS_WERR_ACCESS_DENIED (srvsvc.netsharegetinfo)
| Anonymous access: <none>
| Current user access: <none>
| IPC$:
| warning: Couldn't get details for share: NT_STATUS_WERR_ACCESS_DENIED (srvsvc.netsharegetinfo)
| Type: Not a file share
| Anonymous access: READ
| Current user access: READ/WRITE
| PubShare:
| warning: Couldn't get details for share: NT_STATUS_WERR_ACCESS_DENIED (srvsvc.netsharegetinfo)
| Anonymous access: READ
|_ Current user access: READ
|_smb-ls: ERROR: Script execution failed (use -d to debug)
Nmap done: 1 IP address (1 host up) scanned in 1.05 seconds
Debug gainst Samba 3
NSE: Starting smb-ls against <LINUX_IP>.
NSE: [smb-ls <LINUX_IP>] LM Password:
NSE: [smb-ls <LINUX_IP>] SMB: Invalid NTLM challenge message: unexpected signature.
NSE: [smb-ls <LINUX_IP>] SMB: WARNING: the server appears to be Unix; your mileage may vary.
NSE: [smb-ls <LINUX_IP>] SMB: Extended login to <LINUX_IP> as <hostname>\guest failed, but was given guest access (username may be wrong, or system may only allow guest)
NSE: smb-ls against <LINUX_IP> threw an error!
/usr/bin/../share/nmap/nselib/tab.lua:52: assertion failed!
stack traceback:
[C]: in function 'assert'
/usr/bin/../share/nmap/nselib/tab.lua:52: in function 'add'
/usr/bin/../share/nmap/nselib/ls.lua:217: in function 'add_file'
/usr/bin/../share/nmap/scripts/smb-ls.nse:142: in function 'list_files'
/usr/bin/../share/nmap/scripts/smb-ls.nse:204: in function </usr/bin/../share/nmap/scripts/smb-ls.nse:170>
(...tail calls...)
Against Windows 2008
NSE: [smb-ls <WINDOWS_IP>] LM Password:
NSE: [smb-ls <WINDOWS_IP>] SMB: Invalid NTLM challenge message: unexpected signature.
NSE: smb-ls against <hostname> (<WINDOWS_IP>) threw an error!
/usr/bin/../share/nmap/nselib/tab.lua:52: assertion failed!
stack traceback:
[C]: in function 'assert'
/usr/bin/../share/nmap/nselib/tab.lua:52: in function 'add'
/usr/bin/../share/nmap/nselib/ls.lua:217: in function 'add_file'
/usr/bin/../share/nmap/scripts/smb-ls.nse:142: in function 'list_files'
/usr/bin/../share/nmap/scripts/smb-ls.nse:204: in function </usr/bin/../share/nmap/scripts/smb-ls.nse:170>
(...tail calls...)
Just to note, NetBIOS over TCP is disabled for the windows server, but enabled and allowed in the linux samba 3 sever. Either way, same assertion errors for smb-ls result.
JPvRiel
commented
Jan 26, 2016
|
For nmap 7.01, the
Again, smbclient can enum the shares with anon user or an explicit user Example full command (without debug) Debug gainst Samba 3 Against Windows 2008 Just to note, NetBIOS over TCP is disabled for the windows server, but enabled and allowed in the linux samba 3 sever. Either way, same assertion errors for smb-ls result. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
p-l-
Jan 26, 2016
Can you apply the following patch, run again and post the output?
diff --git a/nselib/ls.lua b/nselib/ls.lua
index f1d116d..7c69ed4 100644
--- a/nselib/ls.lua
+++ b/nselib/ls.lua
@@ -214,6 +214,9 @@ function add_file(output, file)
local curvol = output.curvol
local files = curvol["files"]
for i, info in ipairs(file) do
+ stdnse.debug1("ADD_FILES_1 %d", i)
+ stdnse.debug1("ADD_FILES_2 %s", type(file))
+ stdnse.debug1("ADD_FILES_3 %s", file)
tab.add(files, i, info)
end
local size = get_size(file[curvol.hasperms and 4 or 1])
p-l-
commented
Jan 26, 2016
|
Can you apply the following patch, run again and post the output? diff --git a/nselib/ls.lua b/nselib/ls.lua
index f1d116d..7c69ed4 100644
--- a/nselib/ls.lua
+++ b/nselib/ls.lua
@@ -214,6 +214,9 @@ function add_file(output, file)
local curvol = output.curvol
local files = curvol["files"]
for i, info in ipairs(file) do
+ stdnse.debug1("ADD_FILES_1 %d", i)
+ stdnse.debug1("ADD_FILES_2 %s", type(file))
+ stdnse.debug1("ADD_FILES_3 %s", file)
tab.add(files, i, info)
end
local size = get_size(file[curvol.hasperms and 4 or 1]) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cldrn
Jan 26, 2016
Member
Thanks for the detailed reports. I've been looking into it and it seems we have several 'broken' things with the library right now. Hopefully soon we will fix all these issues.
|
Thanks for the detailed reports. I've been looking into it and it seems we have several 'broken' things with the library right now. Hopefully soon we will fix all these issues. |
pushed a commit
that referenced
this issue
Mar 13, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dmiller-nmap
commented
Jun 22, 2016
|
@cldrn Any update on this issue? Should we be looking into it further? |
dmiller-nmap
added
bug
NSE
labels
Jun 22, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cldrn
Aug 19, 2016
Member
I haven't had a chance to keep working on this but I will re take it this week.
|
I haven't had a chance to keep working on this but I will re take it this week. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
JPvRiel
Aug 19, 2016
Just a quick, somewhat arbitrary note, but perhaps useful in testing:
- Seems modern versions of Windows don't play nice trying to setup anonymous / truly open shares. I did get it right, but only after hacking around with several windows security policy settings for SMB and null sessions.
- Seems much easier to setup a null/anonymous share with Samba.
JPvRiel
commented
Aug 19, 2016
|
Just a quick, somewhat arbitrary note, but perhaps useful in testing:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cldrn
Aug 19, 2016
Member
Do you remember what settings did you change? A friend was telling me about this and he couldn't get it to work (not sure how much time he spent on this).
|
Do you remember what settings did you change? A friend was telling me about this and he couldn't get it to work (not sure how much time he spent on this). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
JPvRiel
Aug 21, 2016
@cldrn I'm afraid I can't recall the exact details, but have some old notes. It's hairy enough for me to denounce it as "black magic" when I eventually got null session file share enumeration working with Windows 10...
IIRC, fiddling with policies for ‘Accounts: Guest account status’, ‘Network access: Let Everyone permissions apply to anonymous users’, and ‘Network access: Restrict anonymous access to Named Pipes and Shares’ can be left alone with the more secure defaults if the ‘Shares that can be accessed anonymously’ policy is set… if the 'public' share endpoint is fully known in advance (i.e. don't need to discover share, just use it). BUT listing shares with a null session is where things get messy. In order to list shares, a null session must be allowed to connect to the '$IPC' services that enumerate the share info.
The default settings for Win Vista+ don’t allow the null session user (ANONYMOUS USER) to enumerate shares, so even if ANON access to a share is allowed, that share can’t be discovered (but can be accessed if known in advance).
For the anon user to enumerate shares, I think it needs anon access to the named pipe srvsvc, and you have to go to great lengths to allow this. Windows has two levels of security checks, and even if NULL Session/Anon User is explicitly allowed for that named pipe, it trips up on a second check…
- Even when srvsvc is specified in ‘Network access: Named pipes that can be accessed anonymously’ = srvsvc
- The ‘Network access: Let Everyone permissions apply to anonymous users’ = Enabled is needed to get past the second ‘integrity level’ security check set for security tokens.
I can share some resources I found helpful:
- http://www.hsc.fr/ressources/articles/win_net_srv/hardcoded_named_pipes.html
- how hard coded anonymous pipe access changed
- very technical explanation to provide background of why Null Session listing of shares via srvsvc named pipe fails
- srvsvc pipe is needed to enum shares, and Null Session is not authorised to access this (by default).
- http://blogs.technet.com/b/nettracer/archive/2010/07/23/why-does-anonymous-pipe-access-fail-on-windows-vista-2008-windows-7-or-windows-2008-r2.aspx
- explains how the second security check with security tokens gets in the way of allowing anon user / null session access to the srvsvc pipe in order to list shares
- https://support.microsoft.com/en-us/kb/3034016
- good overview re anon access
- https://technet.microsoft.com/en-us/library/mt629064(v=vs.85).aspx
- This policy setting affects where file shares can be enumerated without a login (anonymous listing of shares)
- http://nikolar.com/2015/03/10/creating-network-share-with-anonymous-access/
- helpful but a bit wrong. ONLY ‘Network access: Shares that can be accessed anonymously’ needs to be specified to allow a share to have anon access.
- http://serverfault.com/questions/272409/setting-up-an-anonymous-windows-server-2008-network-share
- is more accurate I think.
- http://windowsitpro.com/security/ins-and-outs-anonymous-access
- explains difference between anonymous, everyone and guest.
Many blog/forum posts confuse this issue and enable guest access with everyone permissions. That is some kind of authentication (e.g. guest account with blank password or a set password) versus anon access which can still use the ‘IPC$’ service, A.K.A. the ‘null session’ to connect and get info, such as OS version and shares available (if enumeration is allowed). Guest is more like a shared unprivileged account (which can have a password set) whereas anonymous is in fact blank/empty/null account and can never have a password set.
JPvRiel
commented
Aug 21, 2016
|
@cldrn I'm afraid I can't recall the exact details, but have some old notes. It's hairy enough for me to denounce it as "black magic" when I eventually got null session file share enumeration working with Windows 10... IIRC, fiddling with policies for ‘Accounts: Guest account status’, ‘Network access: Let Everyone permissions apply to anonymous users’, and ‘Network access: Restrict anonymous access to Named Pipes and Shares’ can be left alone with the more secure defaults if the ‘Shares that can be accessed anonymously’ policy is set… if the 'public' share endpoint is fully known in advance (i.e. don't need to discover share, just use it). BUT listing shares with a null session is where things get messy. In order to list shares, a null session must be allowed to connect to the '$IPC' services that enumerate the share info. The default settings for Win Vista+ don’t allow the null session user (ANONYMOUS USER) to enumerate shares, so even if ANON access to a share is allowed, that share can’t be discovered (but can be accessed if known in advance). For the anon user to enumerate shares, I think it needs anon access to the named pipe srvsvc, and you have to go to great lengths to allow this. Windows has two levels of security checks, and even if NULL Session/Anon User is explicitly allowed for that named pipe, it trips up on a second check…
I can share some resources I found helpful:
Many blog/forum posts confuse this issue and enable guest access with everyone permissions. That is some kind of authentication (e.g. guest account with blank password or a set password) versus anon access which can still use the ‘IPC$’ service, A.K.A. the ‘null session’ to connect and get info, such as OS version and shares available (if enumeration is allowed). Guest is more like a shared unprivileged account (which can have a password set) whereas anonymous is in fact blank/empty/null account and can never have a password set. |
Varunram
referenced this issue
Feb 25, 2017
Closed
Issues with smb-enum-shares and smb-enum-users #704
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cldrn
May 25, 2017
Member
I have found some issues with the library not using fully qualified paths as share names. After fixing this, all scripts seem to work fine against modern Windows versions (I haven;t tested it against Samba yet)
Hopefully this patch solves your issues.
|
I have found some issues with the library not using fully qualified paths as share names. After fixing this, all scripts seem to work fine against modern Windows versions (I haven;t tested it against Samba yet) Hopefully this patch solves your issues. |
nmap-bot
closed this
in
b0228a2
May 27, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
JPvRiel
Jun 1, 2017
@cldrn, thanks - hope to retest this at some point in the near future. I eventually ended up using Nessus to do the windows file share security checks, but nice to see nmap might once more be an option here.
JPvRiel
commented
Jun 1, 2017
|
@cldrn, thanks - hope to retest this at some point in the near future. I eventually ended up using Nessus to do the windows file share security checks, but nice to see nmap might once more be an option here. |
JPvRiel commentedJan 5, 2016
Testing against an open, browsable share, smb-enum-shares bumps against NT_STATUS_WERR_INVALID_NAME verus a samba 4 server with anon access allowed.
In debug mode, the follwoing seemed to be relevant output
So I think smb-ls never gets going because smb-enum-shares doesn't properly find info about the open share It might be:
srvsvc.netsharegetinfo?Type: Not a file sharegiven it's a valid file share both smbclient and windows can browse and use it by connecting with a null session to IPC$ (the ANONYMOUS LOGIN).smbclient has no problems
Windows 10 net command also works fine
With full debug
-ddd, the following is notedBut looking at smb-enum-share.nse, the following logic in the source code gets triggered
The commit to help smb-ls use smb-enum-shares is here: 4d0e7c9
And the hassles when trying to enumerate shares with might be related to
MSRPC: NetShareGetInfo()which is at msrpc.luaBut at this point, I'm not familiar enough with SMB/CIFS to debug and understand how or why things break. Basically, if Windows and smbclient can list the share via the null session and then access it, there's no reason why nmap can't.
In passing, it also seems like nmap is incorrectly reporting anonymous write access to the test share
For samba 4