NMap NSE smb-enum-shares and smb-ls won't work with some open shares (NT_STATUS_WERR_INVALID_NAME) #266
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:
smbclient has no problems
$ smbclient -N -L 192.168.56.1 Anonymous login successful Domain=[<domain>] OS=[Unix] Server=[Samba 4.1.17-Ubuntu] Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (<hostname> windows file share service) OpenShare Disk Read for all ... $ smbclient -N \\\\192.168.56.1\\OpenShare -c ls Anonymous login successful Domain=[<domain>] OS=[Unix] Server=[Samba 4.1.17-Ubuntu] . D 0 Tue Jan 5 18:07:31 2016 .. D 0 Tue Jan 5 17:38:52 2016 Test D 0 Tue Jan 5 18:07:33 2016 README.TXT N 20 Tue Jan 5 18:06:54 2016 40301 blocks of size 8388608. 15439 blocks available
Windows 10 net command also works fine
With full debug
But looking at smb-enum-share.nse, the following logic in the source code gets triggered
if(type(share['details']) ~= 'table') then share_output['warning'] = string.format("Couldn't get details for share: %s", share['details']) -- A share of 'NT_STATUS_OBJECT_NAME_NOT_FOUND' indicates this isn't a fileshare if(share['user_can_write'] == "NT_STATUS_OBJECT_NAME_NOT_FOUND") then share_output["Type"] = "Not a file share" else table.insert(host.registry['smb_shares'], share.name) end
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
But 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
The text was updated successfully, but these errors were encountered:
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
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.
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])
Just a quick, somewhat arbitrary note, but perhaps useful in testing:
@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.