[Openvas-plugins] Add own *_detect.nasl script detection

[Tomasz Jadowski]

Hi,

I have some custom stack (configuration and packages installed) and for example gb_php_detect.nasl
can't detect my PHP software. How I could add my own *detect.nasl in
a proper way? (for PHP I'd like to detect it via command-line, i.e.
"php -i" command).

Tom

[Eero Volotinen]

Just open ssh connection and execute command(s)?

i think there are examples in other files how to run ssh commands.

--
Eero

Post by Tomasz Jadowski
Hi,
I have some custom stack (configuration and packages installed) and for
example gb_php_detect.nasl
can't detect my PHP software. How I could add my own *detect.nasl in
a proper way? (for PHP I'd like to detect it via command-line, i.e.
"php -i" command).
Tom
--

“It’s not the daily increase but the daily decrease.
Hack away at the unessential.”
– Bruce Lee
http://tjadowski.sdf.org

_______________________________________________
Openvas-plugins mailing list
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins

[Christian Fischer]

Hi,

Post by Tomasz Jadowski
I have some custom stack (configuration and packages installed) and for example gb_php_detect.nasl
can't detect my PHP software. How I could add my own *detect.nasl in
a proper way? (for PHP I'd like to detect it via command-line, i.e.
"php -i" command).

i would go for submitting issues where a software is not detected
properly to us at this list so we can include it into the feed instead
of building some custom plugins.

In the case of PHP a detection on command line via the php binary is
already done. For this detection you need to configure Authenticated
Scans via SSH like described here:

http://docs.greenbone.net/GSM-Manual/gos-3.1/en/scanning.html#authenticated-scan

[Tomasz Jadowski]

Post by Christian Fischer
Hi,

Post by Tomasz Jadowski
I have some custom stack (configuration and packages installed) and for example gb_php_detect.nasl
can't detect my PHP software. How I could add my own *detect.nasl in
a proper way? (for PHP I'd like to detect it via command-line, i.e.
"php -i" command).

i would go for submitting issues where a software is not detected
properly to us at this list so we can include it into the feed instead
of building some custom plugins.
In the case of PHP a detection on command line via the php binary is
already done. For this detection you need to configure Authenticated
http://docs.greenbone.net/GSM-Manual/gos-3.1/en/scanning.html#authenticated-scan

I have an autenticate scan (it detects other flaws as well), but it
don't
touch PHP (which is affected). Some inside detection based on package
names from official vendors repos, I guess. Am I right? My PHP package
is from my own compilation.

I'm thinking about more generic, inside (with ssh access) procedure
similar to outsite web HTTP port 80 and phpinfo() scan detection. In my
case
I have only non-standard HTTPS port on web and php cli installed.

So, runs generic "php -i" command to detect PHP version will be desire
as a backup to standard detection. Sure it is required php cli package
installed, but it's true in my case.

Best,
Tom

[Christian Fischer]

Hi,

Post by Tomasz Jadowski

Post by Christian Fischer
Hi,

Post by Tomasz Jadowski
I have some custom stack (configuration and packages installed) and for example gb_php_detect.nasl
can't detect my PHP software. How I could add my own *detect.nasl in
a proper way? (for PHP I'd like to detect it via command-line, i.e.
"php -i" command).

i would go for submitting issues where a software is not detected
properly to us at this list so we can include it into the feed instead
of building some custom plugins.
In the case of PHP a detection on command line via the php binary is
already done. For this detection you need to configure Authenticated
http://docs.greenbone.net/GSM-Manual/gos-3.1/en/scanning.html#authenticated-scan

I have an autenticate scan (it detects other flaws as well), but it
don't
touch PHP (which is affected). Some inside detection based on package
names from official vendors repos, I guess. Am I right? My PHP package
is from my own compilation.

Not directly. As long as one of the following binaries are found in the
PATH of the user for authenticated scans:

php
php-cli
php5
php7.0

the detection of PHP should work and you should get a "Linux PHP
Detection" (OID: 1.3.6.1.4.1.25623.1.0.103592) Log entry with the
detected PHP version. Based on this Vulnerabilities are reported for the
detected PHP independently from the distro package names.

Post by Tomasz Jadowski
I'm thinking about more generic, inside (with ssh access) procedure
similar to outsite web HTTP port 80 and phpinfo() scan detection. In my
case
I have only non-standard HTTPS port on web and php cli installed.
So, runs generic "php -i" command to detect PHP version will be desire
as a backup to standard detection. Sure it is required php cli package
installed, but it's true in my case.

This shouldn't be needed if the detection above works as expected.

Regards,

[Tomasz Jadowski]

Post by Christian Fischer
Not directly. As long as one of the following binaries are found in the
php
php-cli
php5
php7.0
the detection of PHP should work and you should get a "Linux PHP
Detection" (OID: 1.3.6.1.4.1.25623.1.0.103592) Log entry with the
detected PHP version. Based on this Vulnerabilities are reported for the
detected PHP independently from the distro package names.

How can I debug this detection? I've checked login into with ssh credentials
manually and scan user has:

$ whereis php
php: /usr/bin/php /etc/php.ini /etc/php.d /usr/lib64/php
/usr/include/php /usr/share/php /usr/share/man/man1/php.1.gz

But I don't have any issue with PHP in my report :(

[Christian Fischer]

Hi,

Post by Tomasz Jadowski

Post by Christian Fischer
Not directly. As long as one of the following binaries are found in the
php
php-cli
php5
php7.0
the detection of PHP should work and you should get a "Linux PHP
Detection" (OID: 1.3.6.1.4.1.25623.1.0.103592) Log entry with the
detected PHP version. Based on this Vulnerabilities are reported for the
detected PHP independently from the distro package names.

How can I debug this detection? I've checked login into with ssh credentials

the debugging of this detection depends if you're getting the above log
entry or not. Also make sure that your Authenticated Scans are actually
working correctly.

Regarding,

[Tomasz Jadowski]

Post by Christian Fischer
the debugging of this detection depends if you're getting the above log
entry or not. Also make sure that your Authenticated Scans are actually
working correctly.

Right, I had some minor problems with correct scan. Now, I have a
some result in scan report:

Summary

This script finds the installed PHP version on Linux and saves the version in KB.
Vulnerability Detection Result

Detected PHP
Version: 5.x.xx
Location: /usr/bin/php
CPE: cpe:/a:php:php:5.x.xx

Concluded from version identification result:
PHP 5.x.xx

Vulnerability Detection Method

Details: Linux PHP Detection (OID: 1.3.6.1.4.1.25623.1.0.103592)

Version used: $Revision: 3592 $

But I have out of vendor's package installed and I don't have any
advisory from PHP (i.e. http://www.php.net/ChangeLog-5.php#5.6.27). I
see on this list on PHP page some CVE ids, but I suppose that OpenVAS
rely on official Red Hat Security Advisory. Am I right? How could I
improve my scan results?

Best,
Tom

[Christian Fischer]

Hi,

Post by Tomasz Jadowski

Post by Christian Fischer
the debugging of this detection depends if you're getting the above log
entry or not. Also make sure that your Authenticated Scans are actually
working correctly.

Right, I had some minor problems with correct scan. Now, I have a
Summary
This script finds the installed PHP version on Linux and saves the version in KB.
Vulnerability Detection Result
Detected PHP
Version: 5.x.xx
Location: /usr/bin/php
CPE: cpe:/a:php:php:5.x.xx
PHP 5.x.xx
Vulnerability Detection Method
Details: Linux PHP Detection (OID: 1.3.6.1.4.1.25623.1.0.103592)
Version used: $Revision: 3592 $

ok that looks good now.

Post by Tomasz Jadowski
but I suppose that OpenVAS rely on official Red Hat Security Advisory. Am I right?

Not exactly in this case. As explained previously there are two types of
vulnerability checks OpenVAS is relying on:

1. Local Security Checks (LSC)

These are auto generated based on Distro Advisories (Like Red Hat RHSA
or Debian DSA) and are checking for vulnerabilities based on the
installed Distro package names like 5.6.27+dfsg-0+deb8u1. These checks
mostly won't catch your custom build PHP as long as it is not installed
via your package manager.

2. Network Vulnerability Tests (NVT)

These are manually created tests which are e.g. checking actively and/or
version/CPE based (e.g. cpe:/a:php:php:5.6.26) for a vulnerability. For
these it doesn't matter if you have a custom build PHP or not, as long
as PHP is correctly detected.

As most of the PHP based vulnerabilities are version/banner based they
are prone to false positives on linux-like systems due to backports.
These are getting a Quality of Detection (QoD) value of 30% and won't
show up in a default report (QoD of 70%+ is needed here). Because of
this you might need to update your filter to show also vulnerabilities
with lower QoD values.

Regards,

[Tomasz Jadowski]

Post by Christian Fischer
2. Network Vulnerability Tests (NVT)
These are manually created tests which are e.g. checking actively and/or
version/CPE based (e.g. cpe:/a:php:php:5.6.26) for a vulnerability. For
these it doesn't matter if you have a custom build PHP or not, as long
as PHP is correctly detected.

For example scripts/2016/gb_php_mult_vuln03_sep16_lin.nasl, right?

But I see, this test has:
(...)
script_dependencies("gb_php_detect.nasl", "os_fingerprint.nasl");
script_mandatory_keys("php/installed","Host/runs_unixoide");
script_require_ports("Services/www", 80);
(...)

And gb_php_detect.nasl also has this "script_require_ports("Services/www",
80);" dependency.

As I mentioned I don't have a running port 80 and I don't have a PHP
banner on it. Should there tests to be more generic? Based on
gb_php_detect_lin.nasl also?

Best,
Tom

[Christian Fischer]

Hi,

Post by Tomasz Jadowski
As I mentioned I don't have a running port 80

this is no issue here. In this case "Services/www" means every port
where a webserver is detected (as long as you're scanning that
non-standard HTTPS port you have mentioned).

Post by Tomasz Jadowski
and I don't have a PHP banner on it.

I think that might be the issue here. The mentioned NVT
scripts/2016/gb_php_mult_vuln03_sep16_lin.nasl has:

## get the port
if(!phpPort = get_app_port(cpe:CPE)){
exit(0);
}

## Get the version
if(!phpVer = get_app_version(cpe:CPE, port:phpPort)){
exit(0);
}

which means that the vulnerability is only reported if PHP was detected
on a specific port by gb_php_detect.nasl. If thats not the case in your
environment (due to the missing PHP banner) you won't get any
vulnerabilities shown.

Need to think about that and see if its possible to use a mix of
gb_php_detect.nasl and gb_php_detect_lin.nasl.

Thanks for the hint.

Regards,

[Christian Fischer]

Hi,

Post by Tomasz Jadowski

Post by Christian Fischer
2. Network Vulnerability Tests (NVT)
These are manually created tests which are e.g. checking actively and/or
version/CPE based (e.g. cpe:/a:php:php:5.6.26) for a vulnerability. For
these it doesn't matter if you have a custom build PHP or not, as long
as PHP is correctly detected.

For example scripts/2016/gb_php_mult_vuln03_sep16_lin.nasl, right?
(...)
script_dependencies("gb_php_detect.nasl", "os_fingerprint.nasl");
script_mandatory_keys("php/installed","Host/runs_unixoide");
script_require_ports("Services/www", 80);
(...)
And gb_php_detect.nasl also has this "script_require_ports("Services/www",
80);" dependency.
As I mentioned I don't have a running port 80 and I don't have a PHP
banner on it. Should there tests to be more generic? Based on
gb_php_detect_lin.nasl also?

just want to let you know that i have committed a few updates to the
feed today which should be included in the next feed update.

After the update we're now also reporting vulnerabilities if PHP was
only detected by the following NVTs (new names after the feed update):

- PHP Version Detection (Linux, local)
- PHP Version Detection (Windows, local)

but not by the "PHP Version Detection (Remote)".

I'm still undecided if the script_require_ports("Services/www", 80);
should be also removed but i'm open for discussions here. :-)

Be aware that the PHP vulnerabilities are not showing up for linux hosts
by default as they have a low Quality of Detection (QoD) value of 30%.
You need to update your filters to show them.

Feedback is welcome. Regards,