nuclei
nuclei copied to clipboard
projectdiscovery
Javascript SMB module not detecting correct SMB version
Nuclei version:
__ _
____ __ _______/ /__ (_)
/ __ \/ / / / ___/ / _ \/ /
/ / / / /_/ / /__/ / __/ /
/_/ /_/\__,_/\___/_/\___/_/ v3.1.10
projectdiscovery.io
Current Behavior:
When I'm scanning using javascript code with the smb protocol supported it's not returning the correct SMB version on the host being scanned. Every single it time it's saying the version is 2.1 I've verified with shodan and nmap that the host is indeed actually running SMBv1, not SMBv2
Expected Behavior:
I would expect it to return the actual SMB version that's running on the target being scanned.
Steps To Reproduce:
Example: steps to reproduce the behavior:
- Run
nuclei -u https://target_here -t smb-detect-service-version.yaml - Observe results below:
[JS] {
"SupportV1": false,
"Version": {
"Major": 2,
"Minor": 1,
"Revision": 0,
"VerString": "SMB 2.1"
},
"NativeOs": "",
"NTLM": "",
"GroupName": "",
"Capabilities": {
"DFSSupport": true,
"Leasing": true,
"LargeMTU": true,
"MultiChan": false,
"Persist": false,
"DirLeasing": false,
"Encryption": false
},
"HasNTLM": true,
"NegotiationLog": {
"HeaderLog": {
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 0,
"Command": 0,
"Credits": 1,
"Flags": 1
},
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 0,
"Command": 0,
"Credits": 1,
"Flags": 1,
"SecurityMode": 1,
"DialectRevision": 528,
"ServerGuid": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
211,
138,
30,
169,
255,
137,
176,
73,
183,
160,
154,
52,
37,
227,
149,
241
],
"Capabilities": 7,
"SystemTime": 1709586164,
"ServerStartTime": 1703694346,
"AuthenticationTypes": [
"1.3.6.1.4.1.311.2.2.30",
"1.2.840.48018.1.2.2",
"1.2.840.113554.1.2.2",
"1.2.840.113554.1.2.2.3",
"1.3.6.1.4.1.311.2.2.10"
]
},
"SessionSetupLog": {
"HeaderLog": {
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 3221225494,
"Command": 1,
"Credits": 1,
"Flags": 1
},
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 3221225494,
"Command": 1,
"Credits": 1,
"Flags": 1,
"SetupFlags": 0,
"TargetName": "{obfuscate}",
"NegotiateFlags": 2726887941
}
}
Anything else:
Template being used below that got the above response:
id: smb-service-detection-version
info:
name: Detect SMB Service and Version
author: inkeep
severity: info
javascript:
- code: |
var smb = require('nuclei/smb');
var c = smb.SMBClient();
var metadata = c.ConnectSMBInfoMode(Host, Port);
log(to_json(metadata));
args:
Host: "{{Host}}"
Port: 445
extractors:
- type: json
json:
- '.Version.VerString'
@epicsilence99 Would it be possible to provide a target to test? Feel free to join our discord server join our discord server and DM anyone from the staff mentioning this issue if the information cannot be provided publicly. Thanks!
@Mzack9999 I discussed this with @tarunKoyalwar at discord: https://discord.com/channels/695645237418131507/1224092148844986452/1226988099914174474
He suggested this is due to a library issue that's used and it's limitation and there not being a better one available
Any update on anything further we can do about this @tarunKoyalwar ? Or is the answer still to try code protocols instead and this won't be fixed
Example host: 188.166.172.250
$ nmap -p 445 --script smb-protocols 188.166.172.250
Starting Nmap 7.92 ( https://nmap.org ) at 2024-07-26 00:14 IST
Nmap scan report for 188.166.172.250
Host is up (0.16s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| smb-protocols:
| dialects:
| NT LM 0.12 (SMBv1) [dangerous, but default]
| 2.0.2
| 2.1
| 3.0
| 3.0.2
|_ 3.1.1
Nmap done: 1 IP address (1 host up) scanned in 2.98 seconds
id: smb-detect
info:
name: SMB Version - Detection
author: pussycat0x
severity: info
description: |
SMB version detection involves identifying the specific Server Message Block protocol version used by a system or network. This process is crucial for ensuring compatibility and security, as different SMB versions may have distinct features and vulnerabilities.
metadata:
max-request: 1
shodan-query: "port:445"
product: dionaea
vendor: dionaea
tags: js,network,smb,enum
javascript:
- pre-condition: |
isPortOpen(Host,Port);
code: |
let m = require("nuclei/smb");
let c = new m.SMBClient();
let response = c.ConnectSMBInfoMode(Host, Port);
Export(response);
args:
Host: "{{Host}}"
Port: "445"
extractors:
- type: json
name: version
json:
- '.Version.VerString'
$ echo 188.166.172.250 | nuclei -t test.yaml -silent
[smb-detect:version] [javascript] [info] 188.166.172.250:445 ["SMB 2.1"]
hi @ehsandeep yes it always detects as SMB2, but ones that are actually running SMB1 it reports that they are SMB2, so that is where the bug is or issue. It's not properly reporting the correct version for v1 version of SMB
After I tried to replicate it, it seems like SMB1 is indeed disabled for the example host that was given by @ehsandeep.
$ smbclient -L //188.166.172.250 -N
Sharename Type Comment
--------- ---- -------
print$ Disk Printer Drivers
IPC$ IPC IPC Service (sibears-school-lon1-v1 server (Samba, Ubuntu))
SMB1 disabled -- no workgroup available
yes, what I mean is for hosts that do have smbv1 running, it's detecting them as smbv2. If you pick any from shodan or nmap a few IPs that say smbv1, it (nuclei-template) returns smbv2
@epicsilence99 - Can you give me some examples of other hosts (that only runs SMBv1 && not other versions)? This is something worth looking into.
maybe I'm confusing something @dwisiswant0 but in the response and example provided above, it does return SMBv1 version in the response, as well as newer versions. How is it determining to choose only v 2.1 as the response, since technically as long as smbv1 protocol is there and not disabled, theoretically it could be used
I totally get what you're saying, @epicsilence99, and I'm pretty sure that you probably think it'll return all the supported versions, like "SMB v1.X, v2.X".
[...] since technically as long as smbv1 protocol is there and not disabled.
It is disabled (https://github.com/projectdiscovery/nuclei/issues/4832#issuecomment-2251229625), that's why I really need some specific examples of a host to reproduce that the host has enabled SMBv1.
got it. Now this makes more sense to me. Let me see if I can find a few and get back to you, otherwise if I can't i'll let you know and we can close it out
Here is an example out of the box something that does not have V1 enabled by default
Here is a screenshot of us configuring to support V1 and showing how it now shows v1 is supported
We then connected via v1 protocol
I obfuscated a few things for privacy reasons, but this should be enough to work with?
Hopefully that makes sense @dwisiswant0 I think the command that was using to detect it, that you and your colleague shared is a red herring and not actually correct. As you can see based on screenshots above
Thanks for the info, @epicsilence99. Have you run it with Nuclei using that same template yet? If you have, what's the value of SupportV1 and the object Version from the dumped JS output?
Please see below @dwisiswant0 as you can see it says supportV1: false, and is reporting version 2.1 which is incorrect
[JS] {
"SupportV1": false,
"Version": {
"Major": 2,
"Minor": 1,
"Revision": 0,
"VerString": "SMB 2.1"
},
"NativeOs": "",
"NTLM": "",
"GroupName": "",
"Capabilities": {
"DFSSupport": true,
"Leasing": true,
"LargeMTU": true,
"MultiChan": false,
"Persist": false,
"DirLeasing": false,
"Encryption": false
},
"HasNTLM": true,
"NegotiationLog": {
"HeaderLog": {
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 0,
"Command": 0,
"Credits": 1,
"Flags": 1
},
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 0,
"Command": 0,
"Credits": 1,
"Flags": 1,
"SecurityMode": 1,
"DialectRevision": 528,
"ServerGuid": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
118,
114,
45,
100,
101,
118,
50,
49,
0,
0,
0,
0,
0,
0,
0,
0
],
"Capabilities": 7,
"SystemTime": 1723499828,
"ServerStartTime": 1240428288,
"AuthenticationTypes": [
"1.3.6.1.4.1.311.2.2.10"
]
},
"SessionSetupLog": {
"HeaderLog": {
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 3221225494,
"Command": 1,
"Credits": 1,
"Flags": 1
},
"ProtocolID": [
0,
0,
0,
0,
254,
83,
77,
66
],
"Status": 3221225494,
"Command": 1,
"Credits": 1,
"Flags": 1,
"SetupFlags": 0,
"TargetName": "",
"NegotiateFlags": 2726953477
}
}
Have you had a chance to look any futher @dwisiswant0
I don't have an instance to replicate this. But what I'm sure of is also because the package we're using doesn't have the compatibility to detect SMBv1, and I haven't found any alternative packages or other ways to do it.
should we then maybe make it more clear this detection is only good for smbv2 then? It's misleading saying smb detection, especially when most people would think of using it for smbv1 and not realize it can't actually support it @dwisiswant0