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
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: 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 PORT STATE SERVICE Host script results: Nmap scan report for 192.168.249.18 PORT STATE SERVICE Host script results: 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 577 Posts ISC Handler Aug 1st 2017 |
Thread locked Subscribe |
Aug 1st 2017 4 years ago |
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/ |
rand0m 8 Posts |
Quote |
Aug 1st 2017 4 years ago |
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 |
Rob VandenBrink 577 Posts ISC Handler |
Quote |
Aug 1st 2017 4 years ago |
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 |
Anonymous |
Quote |
Aug 2nd 2017 4 years ago |
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? |
Adrian 1 Posts |
Quote |
Aug 2nd 2017 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!