Rooting Out Hosts that Support Older Samba Versions

Published: 2017-08-01. Last Updated: 2017-08-01 23:38:42 UTC
by Rob VandenBrink (Version: 2)
4 comment(s)

I've had a number of people ask how they can find services on their network that still support SMBv1.  In an AD Domain you can generally have good control of patching and the required registry keys to disable SMBv1.  However, for non-domain members that's tougher.  You can enumerate what SMB version is negotiated using Powershell, with the smb-getconnections command.

https://technet.microsoft.com/en-us/library/jj635713(v=wps.630).aspx


Below we see a W2k3 server negotiate SMBv1 and 2008r2 server negotiate to SMBvx

Dialects versions are outlined here: https://msdn.microsoft.com/en-us/library/cc246492.aspx

Essentially they loosely match up with SMB versions - Dialect 1.5 is SMBv1, Dialect 2.1 is SMBv2.1

Note that to get a negotiated protocol version, PowerShell needs to authenticate and actually negotiate a connection, so this isn't great if you are scanning non-domain members.  It also gives you what it negotiates to - in other words, the best protocol that both ends support - not all the old stuff that the target host might still support.

What folks are keen to find is Linux hosts offering up Samba shares for instance, or old Windows hosts that aren't in the inventory and don't support SMBv2.  It's also a rude shock to find that your SMB "Filer" interface to your corporate SAN or NAS still supports SMBv1  (yes, really).

 

NMAP is my go-to for stuff like this, but in the latest stable version (7.50 as of today) we see a ton of useful SMB scripts, but not one that tells us all versions that are supported on target hosts.

However, with a bit of digging I did find exactly this - - a new script in the dev forums by Paulino Calderon - his article is here:
http://seclists.org/nmap-dev/2017/q3/20
with the code here:
smb2.lua: https://github.com/cldrn/nmap/blob/smbv2/nselib/smb2.lua
smb.lua: https://github.com/cldrn/nmap/blob/smbv2/nselib/smb.lua
smb-protocols: https://github.com/cldrn/nmap/blob/smbv2/scripts/smb-protocols.nse
smb2-capabilities: https://github.com/cldrn/nmap/blob/smbv2/scripts/smb2-capabilities.nse
smb2-security-mode: https://github.com/cldrn/nmap/blob/smbv2/scripts/smb2-security-mode.nse
smb2 branch: https://github.com/cldrn/nmap/tree/smbv2

The script I run below is "smb-protocols", scanning the same two hosts - note that we have a list of supported protocol versions now, not just a "what did we negotiate" value.  Also, this NMAP script gives up the version without a login to the target host - PowerShell needs an authenticated, negotiated connection in order to get a negotiate connection SMB version (no surprise there).  Note that this needs a new nselib - smb2.lua, and it also needs a new version of smb.lua.  These aren't supported versions, so don't make these changes on a production scanner (at least don't make them permanently unless you understand your risks)

C:\>nmap -p139,445 192.168.249.10,18 --script smb-protocols.nse

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-01 00:48 Eastern Daylight Time
Nmap scan report for 192.168.249.10
Host is up (0.013s latency).

PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb-protocols:
|   dialects:
|_    NT LM 0.12 (SMBv1) [dangerous, but default]

Nmap scan report for 192.168.249.18
Host is up (0.015s latency).

PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb-protocols:
|   dialects:
|     NT LM 0.12 (SMBv1) [dangerous, but default]
|     2.02
|_    2.10

Nmap done: 2 IP addresses (2 hosts up) scanned in 280.32 seconds

If you've got a different tool that will do this, by all means please use our comment form to share this info around.  We're not done with these SMBv1 vulnerabilties, they're here to stay, so rooting out old versions of SMB is something we need to stay on top of!

Happy scanning! 

 

******************  UPDATE **************

I posted this  story on July 31, and 24 hours later NMAP 7.6 was released, which includes the NSE scripts and updates for the SMB libraries that are described here, along with several other SMB (and non-SMB) related scripts.  Find the latest version of NMAP at https://nmap.org/download.html

 

===============
Rob VandenBrink
Compugen

4 comment(s)

Comments

How about Eternal Blues?

https://www.bleepingcomputer.com/news/security/app-finds-more-than-50-000-computers-vulnerable-to-eternalblue-exploit/

http://omerez.com/eternalblues/
Best advice for that set of vulnerabilities and attacks is to patch your systems, and disable SMBv1.
Not putting hosts with SMB (of any version) facing the public internet is of course also important
Just tried it and my Windows 10 fully updated machines all showed

Host script results:
| smb-protocols:
| dialects:
| NT LM 0.12 (SMBv1) [dangerous, but default]
| 2.02
| 2.10
| 3.00
| 3.02
|_ 3.11

And Windows 7

Host script results:
| smb-protocols:
| dialects:
| NT LM 0.12 (SMBv1) [dangerous, but default]
| 2.02
|_ 2.10


I used this command on Nmap 7.60

nmap -p139,445 192.168.100.0/24 --script smb-protocols.nse
Not exactly nmap, but a more passive approach:
BPF (Berkeley Packet Filter) for SMB version (with tcpdump example).
So, here is the short version of a message I've posted about 2 months ago in a LinkedIn group I'm a member of:


While searching for a tcpdump filter to identify the SMB version in the captured packets, I ran across this:
"You cannot directly filter on SMB2 while capturing".
Where? Well, here:
https://wiki.wireshark.org/SMB2

Please correct me if I'm wrong, but the following has worked for me:

To capture SMBv1 packets:
tcpdump -i blablabla -s 0 -nn dst port 445 and ip[44]=0xff
For SMBv2 packets, the same but with 0xfe.

And yes, it does work on Wireshark, too. Why shouldn't it?

Diary Archives