Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`smb-protocols` runs for ~300 seconds when only SMBv1 is enabled #2203

Closed
tukusejssirs opened this issue Dec 14, 2020 · 9 comments
Closed

`smb-protocols` runs for ~300 seconds when only SMBv1 is enabled #2203

tukusejssirs opened this issue Dec 14, 2020 · 9 comments
Assignees
Labels

Comments

@tukusejssirs
Copy link

@tukusejssirs tukusejssirs commented Dec 14, 2020

Describe the bug
When I run nmap -d -e ens192 -p139,445 --script smb-protocols -T4 "$ip" against a host (that $ip) that supports only SMBv1, it run for quite long, approx. 300 seconds. The server I run this command on, has two network interfaces and it does not matter if I add -e ens192 or not; same for -T4.

Note that on other systems ($ip) that support other SMB versions too, it takes only about 7 seconds.

To Reproduce
Run nmap -d -e ens192 -p139,445 --script smb-protocols -T4 "$ip" against a host (that $ip) that supports only SMBv1.

Expected behavior
It should take max 10 seconds to get the list of SMB versions supported on the remote OS.

Version info (please complete the following information):

  • OS:
    • CentOS 8.2.2004;
    • Linux 4.18.0-193.28.1.el8_2.x86_64;
  • Output of nmap --version:
Nmap version 7.70 ( https://nmap.org )
Platform: x86_64-redhat-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.1 libpcre-8.42 libpcap-1.9.0-PRE-GIT nmap-libdnet-1.12 ipv6
Compiled without: libssh2 libz
Available nsock engines: epoll poll select
  • Output of nmap --iflist

Note: I have sanitised the output:

  • removed timestamp;
  • changed the IP addresses;
  • changed the MAC addresses.
Starting Nmap 7.70 ( https://nmap.org ) at {timestamp}
************************INTERFACES************************
DEV    (SHORT)  IP/MASK                      TYPE     UP MTU   MAC
lo     (lo)     127.0.0.1/8                  loopback up 65536
ens224 (ens224) 10.0.0.1/24               ethernet up 1500  00:00:00:00:00:01
ens224 (ens224) 0000::0000:0000:0000:0001/64 ethernet up 1500  00:00:00:00:00:01
ens192 (ens192) 10.1.0.1/24                 ethernet up 1500  00:00:00:00:00:02
ens192 (ens192) 0000::0000:0000:0000:002/64  ethernet up 1500  00:00:00:00:00:02

**************************ROUTES**************************
DST/MASK                      DEV    METRIC GATEWAY
10.0.0.0/24                 ens224 150
10.1.0.0/24                  ens192 150
0.0.0.0/0                     ens224 150    10.0.0.2
0000::0000:0000:0000:002/128  ens192 0
0000::0000:0000:0000:0001/128 ens224 0
fe80::/64                     ens224 150
fe80::/64                     ens192 150
ff00::/8                      ens224 256
ff00::/8                      ens192 256

Additional context
Add any other context about the problem here, such as special network type.

@tukusejssirs tukusejssirs added the Nmap label Dec 14, 2020
@nnposter nnposter self-assigned this Dec 15, 2020
@nnposter nnposter added enhancement NSE and removed Nmap labels Dec 15, 2020
@nnposter
Copy link

@nnposter nnposter commented Dec 15, 2020

I might have a working fix. Stay tuned.

@nnposter
Copy link

@nnposter nnposter commented Dec 17, 2020

Please try the code from #2208 and report back. For your specific case, you need to refresh at least files nselib/smb.lua and nselib/smb2.lua from the PR.

Note that this new code is likely not fully compatible with your dated version of Nmap. You should use at least 7.80, ideally 7.91.

@tukusejssirs
Copy link
Author

@tukusejssirs tukusejssirs commented Dec 17, 2020

Thanks for such a quick PR! 👍

Note that this new code is likely not fully compatible with your dated version of Nmap. You should use at least 7.80, ideally 7.91.

Well, I used the one available on CentOS 8 repo, I didn’t check if it was the latest version.


I have cloned your repo and built the code using ./configure && make && sudo make install, actually I didn’t ran sudo make install, I just simply run it from the local repo folder.

Now, it is much faster, although when I run the command my XPs (Windows XP Emdebbed), it still takees about 30 seconds to finish its job. I must note that it once took less then 2 seconds the same machine and once nearly 1.5 minutes, however, mostly it took only half a minute to complete the probing.

@nnposter
Copy link

@nnposter nnposter commented Dec 17, 2020

The problem with XP is that the SMB 2 probe needs to time out (in my code just once). It is possible to avoid the time-out completely by replacing the native SMB2 negotiation with a hybrid but it would require more substantial refactoring of the SMB code in NSE.

@tukusejssirs
Copy link
Author

@tukusejssirs tukusejssirs commented Dec 17, 2020

I see. I hope that one day it’ll gets refactored. Nevertheless, thanks for your help and time! 😉

@nnposter
Copy link

@nnposter nnposter commented Dec 17, 2020

If your network has low latency and the targets are responsive then you might try to tinker with the hard-coded time-out:

local TIMEOUT = 10000

@tukusejssirs
Copy link
Author

@tukusejssirs tukusejssirs commented Dec 20, 2020

If your network has low latency and the targets are responsive

I need to test local network, freshly wired up for the needs of an application. From a physical server (which acts as a router for this network) via an unmanagable switch to the machines is at most 100 metres. All machines are connected via cable only.

then you might try to tinker with the hard-coded time-out:

I could do that, although why can’t we set it as a command-line option?


Just a side question: it there a way to calculate that timeout programmatically?


FYI: Actually, I need to know only the latest supported SMB version. I need it only to use CIFS to mount remote shares from Windows clients on a Linux server. As mount.cifs needs to know exact SMB version to be used and because in our network, there can be computers with Win95 though Win10, I need the latest supported SMB version, which we save it into our DB for reuse when needed.

@nnposter
Copy link

@nnposter nnposter commented Dec 21, 2020

With the code changes in #2208, there is only minor performance difference between determining all the supported dialects or just highest one. In both cases the highest revision is determined with a single SMB 2 handshake. If the target does not respond at all then further dialects are not tried so there is no penalty. If the target does respond then the script tests all the lower dialects, one at a time. However, at this point we know that the target is capable of SMB 2 so there should not be any timeouts. In my test environment the script execution against such targets takes less than 5 seconds, Samba being by far the fastest with less than 0.5s.

why can’t we set it as a command-line option?

It would not be difficult to implement. I am guessing that there was no need at the time it was coded.

it there a way to calculate that timeout programmatically?

That's a bit tricky. If you forget the technical implementation, how exactly would you calculate it? When the script starts, it is given a dynamically determined RTT timeout but this number does not in any way reflect how long it takes for the target to process an application-level request. IoT targets are poster examples for this issue. They might be on a reliable low-latency network but their processing power is sometimes very limited. You can connect to them in a fragment of a second but then wait 10-15s to complete a request.

@nnposter nnposter linked a pull request that will close this issue Dec 28, 2020
@nnposter
Copy link

@nnposter nnposter commented Jan 18, 2021

The patch from #2208 has been committed as r38184. Thank you for reporting the issue.

@nmap-bot nmap-bot closed this in 58617a7 Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants