Win10 doesn't support SMB1 functionality in `lib/rex/proto/smb/simpleclient.rb`

[asoto-r7]

Windows 10 appears to completely ignore our attempts to connect with our existing Rex::Proto::SMB login() method. In fact, it will immediately respond with a TCP RST if we try to use something like the windows/x64/meterpreter_bind_named_pipe payload.

This problem is likely present in other new versions of Windows, but I have not tested it.

Steps to reproduce

1. Build a meterpreter_bind_named_pipe payload:

./msfvenom -p windows/x64/meterpreter_bind_named_pipe -f exe -o bind_named_pipe_x64.exe

2. Deploy the above payload on a Windows 10 x64 target (fully patched, in my case).

3. Configure a handler for meterpreter_bind_named_pipe:

use exploit/multi/handler
set PAYLOAD windows/x64/meterpreter_bind_named_pipe
set RHOST 127.0.0.1
run

4. (Optional, set up a packet capture to see the immediate SMB failure.)

Expected behavior

The payload should connect successfully, or at least progress past SMB Session Negotiation.

Current behavior

The SMB session is aborted by the target when it realizes that SMB2 isn't possible. Surprisingly, there is no response packet indicating an error. The TCP connection is just forcibly reset.

See below for a side-by-side comparison of current vs expected behavior. Left is Metasploit's simpleclient::login(). Right is known-good OS X SMB implementation:

We get a traceback in the case of either error, but because of over-zealous exception handling, we get back a 'login failed' error, but not enough information to know why:

[-] SMB login Failure .\USERNAME:PASSWORD 192.168.108.217:445

Modifying metasploit-framework/lib/msf/core/handler/bind_named_pipe.rb:317 to not catch every exception gives us a more helpful traceback:

#<Thread:0x00007fb3062c28b8@/Users/asoto/git/r7/metasploit-framework/lib/msf/core/thread_manager.rb:93 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
    3: from /Users/asoto/git/r7/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
    2: from /Users/asoto/git/r7/metasploit-framework/lib/msf/core/handler/bind_named_pipe.rb:313:in `block in start_handler'
    1: from /Users/asoto/git/r7/metasploit-framework/lib/rex/proto/smb/simpleclient.rb:45:in `login'
/Users/asoto/git/r7/metasploit-framework/lib/rex/proto/smb/simpleclient.rb:85:in `rescue in login': Login Failed: Connection reset by peer (Rex::Proto::SMB::Exceptions::LoginError)

System stuff

Metasploit version

msf5 exploit(multi/handler) > version
Framework: 5.0.0-dev-b83bcf2d3d
Console  : 5.0.0-dev-b83bcf2d3d
msf5 exploit(multi/handler) > ruby -v
[*] exec: ruby -v

ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]

I installed Metasploit with:

• [ ] Kali package via apt
• [ ] Omnibus installer (nightly)
• [ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• [x] Source install (please specify ruby version)

OS

Mac OS X 10.13.4 (fully patched) against a Windows 10 x64 target.

[UserExistsError]

The TCP reset is expected behavior when SMB1 is not supported and no SMB2 dialects are requested. See #9365.

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[github-actions[bot]]

Thanks for your contribution to Metasploit Framework! We've looked at this issue, and unfortunately we do not currently have the bandwidth to prioritize this issue.

We've labeled this as attic and closed it for now. If you believe this issue has been closed in error, or that it should be prioritized, please comment with additional information.