Newb at NVTs

Vulnerability Tests
1

Hi all,

Bit of a newb when it comes to writing NVT’s - I need to write two NVT’s to collect the output of these commands from the CLI. ie collect a list of users, and of installed software.

List one - a list of user accounts:

  • dscl . list /Users (OS X)
  • awk -F’:’ ‘{ print $1}’ /etc/passwd (UNIX / LINUX)
  • net users (windows)

List two - a list of installed software:

  • wmic product get /format:csv > Software_%Computername%.csv (windows)
  • system_profiler -detailLevel full SPApplicationsDataType > app.txt (OS X)
  • apt list --installed (linux)

Is there a “build your first NVT” tutorial somewhere?

2

Hi,

did you take a look at: VT Development ?

Also it might be helpful to have a look to already existing VTs. Maybe there are some in the feed doing something similar to what you want to do?

If you need further help, don’t hesitate to ask :slight_smile:

1 Like
3

Thanks!

It says “Avoid writing your own product detection inside a vulnerability check.”.

Technically I am doing sorta detection here (Local accounts & software); am I using NVT’s wrong then?

4

This is a general note on the concept of “Detection” and “Vulnerability”-VTs and that both should be split into two separate tasks.

As an example many years ago quite a lot Vulnerability-VTs for the very same product had done an own connection via SMB to a target host to gather the version of the product from the registry:

vuln1.nasl
-> SMB login/registry gathering for version of product1, report a Vulnerability if affected version 1.2.3 was detected.
vuln2.nasl
-> SMB login/registry gathering for version of product1, report a Vulnerability if affected version 3.2.1 was detected.
vuln3.nasl
-> SMB login/registry gathering for version of product1, report a Vulnerability if affected version 3.1.2 was detected.

As you might see this is causing e.g. three SMB connections for collecting the very same information and a bad example on how to use such “Product detection” within a vulnerability check.

Instead there should have been one single “Detection”-VT like e.g.:

detection.nasl
-> SMB login/registry gathering for version of product1, saving the info about the product like e.g. the existence of a product and its version (e.g. via set_kb_item) within the internal Knowledge Base (KB).

vuln1.nasl
-> Getting the information from the internal KB (e.g. via get_kb_item), report a Vulnerability if affected version 1.2.3 was found.

vuln2.nasl
-> Getting the information from the internal KB (e.g. via get_kb_item), report a Vulnerability if affected version 3.2.1 was found.

vuln3.nasl
-> Getting the information from the internal KB (e.g. via get_kb_item), report a Vulnerability if affected version 3.1.2 was found.

With this recommended concept you can see that we’re doing only one SMB connection (instead of three). Additional you could also set something like the following:

set_kb_item(name:"productname/detected", value:TRUE);

which could be added to the vuln*.nasl as something like:

script_mandatory_keys("productname/detected");

This helps to e.g. not launch the vuln*.nasl if the Product wasn’t detected and improves the performance of your tests.

5

Ok, I took peoples advice, and trawled the existing libraries, and I think I’ve found what I need:

wmi_user.inc

This appears to build a list of accounts on a windows machines. (I still need to look for a SSH version).

However, how do I output this list via an .nvt?

6

Hi,

This appears to build a list of accounts on a windows machines. (I still need to look for a SSH version).

I’m not quite sure if there is a Linux / SSH pendant to that (yet). But you can try read the /etc/passwd file on the target host using ssh_cmd().

However, how do I output this list via an .nvt?

You can use log_message() to output it.
Examples on how to use the function can be found in other VTs.

Good luck and keep on trying :wink:

1 Like