Skip to content

NMap NSE smb-enum-shares and smb-ls won't work with some open shares (NT_STATUS_WERR_INVALID_NAME) #266

Closed
@JPvRiel

Description

@JPvRiel

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.

nmap -PS445 -p445 --script=smb-os-discovery,smbv2-enabled,smb-enum-shares,smb-ls --script-args=ls.maxdepth=10 192.168.56.1

Starting Nmap 7.00 ( https://nmap.org ) at 2016-01-05 18:49 SAST
Nmap scan report for 192.168.56.1
Host is up (0.00082s latency).
PORT    STATE SERVICE
445/tcp open  microsoft-ds

Host script results:
| smb-enum-shares: 
|   account_used: <blank>
|   IPC$: 
|     Type: STYPE_IPC_HIDDEN
|     Comment: IPC Service (<hostname> windows file share service)
|     Users: 2
|     Max Users: <unlimited>
|     Path: C:\tmp
|     Anonymous access: READ/WRITE
|   OpenShare: 
|     warning: Couldn't get details for share: NT_STATUS_WERR_INVALID_NAME (srvsvc.netsharegetinfo)
|     Type: Not a file share
|_    Anonymous access: READ/WRITE
| smb-os-discovery: 
|   OS: Unix (Samba 4.1.17-Ubuntu)
|   Computer name: <hostname>
|   NetBIOS computer name: <hostname>
|   Domain name: 
|   FQDN: <hostname>
|_  System time: 2016-01-05T18:49:16+02:00
|_smbv2-enabled: Server supports SMBv2 protocol

In debug mode, the follwoing seemed to be relevant output

NSE: [smb-enum-shares 192.168.56.1] SMB: Invalid NTLM challenge message: unexpected signature.
NSE: [smb-enum-shares 192.168.56.1] SMB: WARNING: the server appears to be Unix; your mileage may vary.
NSE: [smb-enum-shares 192.168.56.1] SMB: Extended login to 192.168.56.1 as <hostname>\<blank> failed, but was given guest access (username may be wrong, or system may only allow guest)
NSE: [smb-enum-shares 192.168.56.1] SMB: Failed to get share info for OpenShare: NT_STATUS_WERR_INVALID_NAME (srvsvc.netsharegetinfo)
NSE: Finished smb-enum-shares against 192.168.56.1.

So I think smb-ls never gets going because smb-enum-shares doesn't properly find info about the open share It might be:

  • an unnecessary dependence on or problem with srvsvc.netsharegetinfo?
  • it shouldn't report Type: Not a file share given 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

$ 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

>net view 192.168.56.1
Shared resources at 192.168.56.1

<hostname> windows file share service

Share name  Type  Used as  Comment

-------------------------------------------------------------------------------
OpenShare   Disk           Read for all
The command completed successfully.

With full debug -ddd, the following is noted

  • NetShareGetInfo() returned success
NSE: [smb-enum-shares M:24b71c0 192.168.56.1] MSRPC: Function call successful, 12 bytes of returned arguments
NSE: [smb-enum-shares M:24b71c0 192.168.56.1] MSRPC: NetShareGetInfo() returned successfully
NSE: [smb-enum-shares M:24b71c0 192.168.56.1] SMB: Sending SMB_COM_TREE_DISCONNECT

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 MSRPC: NetShareGetInfo() which is at msrpc.lua

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

Anonymous access: READ/WRITE

For samba 4

$ net usershare info OpenShare
[OpenShare]
path=/home/<account>/Desktop/OpenShare
comment=Read for all
usershare_acl=Everyone:R,Unix User\<account>:F,
guest_ok=y

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions