VT working on command line doesn't show expected results in full scan

Vulnerability Tests
1

Thanks a lot @cfi,

Actually, I am testing the script: secpod_hp_smh_detect.nasl to detect the version of HP System Management Homepage. As following your instructions, I got the output:

# openvas-nasl -i /usr/local/var/lib/openvas/plugins -X -B -d -t 125.212.201.29 find_service.nasl secpod_hp_smh_detect.nasl --kb=“Ports/tcp/2381=1”

lib misc-Message: 09:11:37.808: replace key FindService/CnxTime1000/2381 → 444
lib misc-Message: 09:11:37.808: set key Transports/TCP/2381 → 8
lib misc-Message: 09:11:37.808: set key Transport/SSL → 2381
lib misc-Message: 09:11:37.954: replace key FindService/RwTime1000/2381 → 144
lib misc-Message: 09:11:37.956: replace key FindService/tcp/2381/get_http → HTTP/1.1 302 Found
lib misc-Message: 09:11:37.957: set key Services/www → 2381
lib misc-Message: 09:11:37.958: replace key Known/tcp/2381 → www
lib misc-Message: 09:11:37.959: replace key www/banner/2381 → HTTP/1.1 302 Found
lib misc-Message: 09:11:38.589: set key www/2381/keepalive → no
lib misc-Message: 09:11:39.401: set key HP/SMH/version → 7.3.2.1
lib misc-Message: 09:11:39.401: set key HP/SMH/installed → 1
lib misc-Message: 09:11:39.401: set key HostDetails → App

It works.

But when I run the full scan with options:

  • Port list: 2301, 2381
  • San Config: Full and Fast

It return no result for HP SMH version. Although I have checked openvassd.log and confirmed that the script secpod_hp_smh_detect.nasl was launched and OpenVAS can detect this is a HTTPS page (I saw some SSL/TLS reports on port 2381).

It makes me really confused. Do you have any idea to check this situation?

2

Hi,

there might be quite a lot reasons for this:

  1. The system/service stopped to respond during the scan
  2. The service was marked as “broken” (See the output of CGI Scanning Consolidation)
  3. Your filter within the GSA doesn’t include results of VT having a “Log” level
  4. Probably a few more things i currently have missed

If you want to do a little bit more debugging you can work with “display();” calls with this VT to see where it is jumping out like e.g.:

port = get_http_port( default:2301 );
display( "Port:" + port );

The output will end up in the openvassd.dump file in your log directory of OpenVAS/GVM.

1 Like
3

Hi @cfi

  1. I confirmed that the service is up during the scan. I can manually run openvas-nasl against it.
  2. I have checked the results again and there is no CGI Scanning Consolidation in the results.
  3. I included Log level as well as filter QoD to 0 all the time.

I have added the display() function to the script as below:

display( “Start display here\n”);
port = get_http_port( default:2301 );
display( "Port: " + port + “\n”);

And then I ran full scan again with the same config as before:

  • Port list: 2301, 2381
  • San Config: Full and Fast

Here is the scan result (all of them):

openvas_scan
openvas_scan1333×656 104 KB

openvassd.messages indicates the script was launched

message
message1202×43 13.6 KB

The openvassd.dump only has the string “Start display here” (Other ports are from my test before)
dump

So from the dump I can conclude that at the time script “secpod_hp_smh_detect” run, port 2301 and 2381 are not detected. But it conflicts with the scan results cause I can see it detected port 2381. And I think the “Service” result is return by “find_service.nasl” on which “secpod_hp_smh_detect” depends on.

So what could be wrong here?

4

Hi,

based on your posted output i guess the following applies here:

5

Hi @cfi,

I think I know the reason. It’s not because the service was marked as “broken” but because the service was not marked as “www” so the “get_http_port” function cannot return those ports.

Now it seems more complicated to find out why those ports were not marked as http service. Do you have any suggestions?

6

Hi,

unfortunately i need to say that this assumption is not correct. If you check your previously posted screenshot you can see the output of “No 404 check” for both ports 2301 and 2381. This shows that both services where detected correctly as web servers (marked as “www”).