The ScanLite module used by NetReg to fire a Nessus scan against registering machines takes a list of Nessus plugins to run against the target. The job of anyone using this thing seriously is to keep the list of plugins up to date in order to detect the most recent threats.
Unfortunately, Nessus doesn’t make this very easy for us. They have tens of thousands of plugins that can be searched by category, name, etc. The problem is that they don’t easily tell you if the plugin employs a passive or active scan. By passive, I mean that they try to detect the particular vulnerability by crafting packets to expose the flaw. Active, on the other hand, means that they look through registry entries or use other methods requiring privileged access in order to determine if a particular hole is patched.
For a completely effective Nessus scan, you need to have some sort of access to the machine in question and it probably needs to be running certain services. This might be a workable scenario for lab machines where you control everything and maybe have some admin account set up on every one. But for the masses of students and faculty, this simply won’t work. So, you want to limit the list of plugins to only the ones that use passive scanning, but the only way to figure that out in most cases is to look at the code of the plugin to see what it does.
Here is a list of plugins that we use and what each one scans for. We aim for the big name vulnerabilities and simple version checks while trying to keep the list small so the user doesn’t wait too long for the scan to finish when they register. At the end is the line from Variables.pm that you can just copy and paste in order to use the same plugin list. I hope to keep this list updated as frequently as possible. For you Nessus people, give us a way to search for plugins that use passive scanning, please!
- 11808 – Microsoft RPC Interface Buffer Overrun (823980) – Windows
- 11835 – Microsoft RPC Interface Buffer Overrun (KB824146) (network check) – Windows
- 11890 – Buffer Overrun in Messenger Service (real test) – Windows
- 12054 – ASN.1 Parsing Vulnerabilities (NTLM check) – Windows
- 12204 – Microsoft Hotfix for KB835732 IIS SSL check – Windows
- 12209 – Microsoft Hotfix for KB835732 (SMB check) – Windows
- 18027 – Vulnerability in MSMQ Could Allow Code Execution (Network Check) – Windows
- 18028 – Vulnerabilities in TCP/IP Could Allow Remote Code Execution (network check) – Windows
- 18502 – Vulnerability in SMB Could Allow Remote Code Execution (896422) – Network Check - Windows
- 19407 – Vulnerability in Printer Spooler Service Could Allow Remote Code Execution (896423) – Network Check – Windows
- 19408 – Vulnerability in Plug and Play Service Could Allow Remote Code Execution (899588) – Network Check – Windows
- 20008 – Vulnerabilities in MSDTC Could Allow Remote Code Execution (902400) – Network check – Windows
- 21334 – Vulnerability in Microsoft Distributed Transaction Coordinator Could Allow Denial of Service (913580) – Network check – Windows
- 21696 – Vulnerability in Routing and Remote Access Could Allow Remote Code Execution (911280) – Network check – Windows
- 21783 – iTunes AAC File Integer Overflow Vulnerability (network check) – Gain a shell remotely
Make sure you paste this as one line!
$NESSUS_PLUGIN = "11808;11835;11890;12054;12204;12209;
18027;18028;18502;19407;19408;20008;21334;21696;21783";
Determining if a plugin is active or passive is not a clear cut exercise, at least not that I can tell. First, you can view the source of the plugin from the Nessus page for that plugin. If you see something that looks like data is being specifically crafted into a packet of some sort, that may indicate that the plugin is passive. For example, here’s a section from 12054:
ntlmssp = "NTLMSSP" + raw_string (0x00);
ntlmssp += raw_dword (d:1); # NTLMSSP_NEGOTIATE
ntlmssp += raw_dword (d:NTLMSSP_NEGOTIATE_UNICODE |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_NTLM |
NTLMSSP_NEGOTIATE_NTLM2); # Flags
ntlmssp += ntlmssp_data (data:NULL,offset:0); # workstation domain NULL
ntlmssp += ntlmssp_data (data:NULL,offset:0); # workstation name NULL
It appears that this plugin is building a packet in a certain way in order to test for the vulnerability. Sometimes, the source will contain a comment about how it works, but I don’t see many of those.
You can also look for dependencies on other scripts that handle gaining access to a machine. Here is a bit from 21725:
script_dependencies("netbios_name_get.nasl", "smb_login.nasl",
"smb_registry_full_access.nasl", "smb_enum_services.nasl");
script_require_keys("SMB/name", "SMB/login",
"SMB/password", "SMB/registry_full_access",
"SMB/transport");
script_require_ports(139, 445);
This one is pretty obviously going to look for an entry in the Windows registry to see if a particular item is installed.
Examining the Nessus scan logs can also help. If scripts require access, you will see errors indicating that a plugin doesn’t have what it needs in order to run. There is also some information on the Nessus site about network checks which indicates that if the plugin has that phrase in the name, it uses a passive method.
Maybe if I took the time to learn the Nessus plugin language, things would be more clear to me.