smb_enumshares returns no results in comparison to smbclient #14355
Comments
|
Also replicated with the thm 6.0.2 6.0.3 |
|
Seems like an issue with Samba 4.3.11 which you can easily install with Ubuntu 16.04. |
|
I could reproduce the issue against tryhackme's server but I couldn't with the same Samba version (4.3.11) on a local Ubuntu 16.04. Here are my notes: Ubuntu 16.04
TryHackMe
output:
output: However, according to the protocol, SMB3 with 3.1.1 dialect (the one selected by the server) requires the
|
|
Just for posterity, I was able to replicate with docker, these are the steps I ran through: Docker setupGrabbing ubuntu 16.04 and installing docker: docker run -it --rm -p 139:139 -p 445:445 ubuntu:16.04 /bin/bash
mkdir -p /tmp/foo
apt update
apt install -y sambaVerifying version is as expected: Adding the share: cat << EOF >> /etc/samba/smb.conf
[foo_share]
comment = Foo samba share
path = /tmp/foo
read only = no
browsable = yes
EOFRestart the service: Scanning with MetasploitNow that docker is set up, and bound to the host's ports - I was able to replicate Christophe's and Spencer's findings when scanning with Metasploit: Running without encryption: Running with protocol version 1,2: Using smbclientInstalling Result: I'm assuming smbclient worked as it's not encrypted by default, as if I run with smbclient's encryption enabled it fails: As everything is now pointing to this being an issue with the particular samba version; I wonder if there's any affordance we can add to Metasploit to help users know the steps they could run through to still try extract information out of the rhost |
|
Looks like it's the same results for ubuntu 20.04 LTS and samba 4.11.6 - January 28, 2020 |
|
I can confirm I have this same issue with msfconsole 6.0.17-dev. Unfortunately, I do not have 100% verifiable information about the remote machine's exact distro or Samba version, as I am running into this during a challenge. |
|
I spent some time to debug the |
|
I did more tests with RubySMB directly, forcing SMBv3 with anonymous access. Here are my findings: Samba 4.11.6
Windows 10 version 1909
As we can see, the behavior is different. An empty session key will work with Samba, but it will fail with Windows if encryption is enabled. |
|
We can still force an empty session key when encryption is disabled, which will work with both platforms. But, with encryption enabled, it is another story. |
|
workaround: |
|
Ran into this issue myself when I accidentally tested the |
|
I had completely forgotten about this but it turns out it's been fixed since 6.1.30 released on February 17th, 2022. More specifically it was fixed in commit bd0aba3 which bumps RubySMB from 3.0.2 to 3.0.3. This bump included the changes from two PRs: rapid7/ruby_smb#190 and rapid7/ruby_smb#193. Old and broken: New and fixed: |
|
Can confirm broken on previous versions, and working on the latest release now - thanks! 👍 |
Steps to reproduce
Running against tryhackme's nerdherd room results in no shares output:
Example:
In case it's useful, version output:
Current behavior
There is no output:
For some of the other smb modules, there's more obvious logging that something's gone wrong:
Expected behavior
What should happen?
smbclienton kali works as expected:Interestingly, although
smbclientworks,cmedoesn't work:Output:
Metasploit version
Get this with the
versioncommand in msfconsole (orgit log -1 --pretty=onelinefor a source install).Module/Datastore
The following global/module datastore, and database setup was configured before the issue occurred:
Collapse
History
The following commands were ran during the session and before this issue occurred:
Collapse
Framework Errors
The following framework errors occurred before the issue occurred:
Collapse
Web Service Errors
The following web service errors occurred before the issue occurred:
Collapse
Framework Logs
The following framework logs were recorded before the issue occurred:
Collapse
Web Service Logs
The following web service logs were recorded before the issue occurred:
Collapse
Version/Install
The versions and install method of your Metasploit setup:
Collapse
The text was updated successfully, but these errors were encountered: