UNIX Testing Functionality Provided by the Local Testing Include Files

Nessus can connect to a remote UNIX host that supports SSH (Secure Shell). Currently, the following operating systems have tests that verify whether a remote host contains an appropriate path for a vulnerability: AIX, Debian, Fedora, FreeBSD, Geneto, HP-UNIX, Mandrake, Red Hat, Solaris, and SuSE.

Verifying whether a remote host has installed the appropriate patch is done via several query mechanisms, depending on the type of operating system and the type of package querying mechanism used by that operating system.

In most cases, pkg_list or dpkg, programs whose purpose is to list all available installed software on the remote host and each software’s version, are used to retrieve a list of all the products on the remote host. This information is then quantified and stored in the knowledge base under the item Host/OS Type. For example, in the case of Red Hat, the program rpm is launched, and the content returned by it is stored in Host/RedHat/rpm-list.

You do not have to directly access the content found in a knowledge base item; rather, several helper functions analyze the data found in the software list and return whether the appropriate patch has been installed or not.

A list of the software components of an operating system is not the only information that is indexed by the helper functions; the operating system’s level, or more specifically its patch level, is also stored in the knowledge base and is used to verify whether a certain patch has been installed on the remote host.

Currently, several automated scripts take official advisories published by the operating system vendors and convert them into simple NASL (Nessus Attack Scripting Language) scripts that verify whether the advisory is relevant to the remote host being scanned. Let’s discuss these scripts now.

The rpm_check function determines whether the remote host contains a specific RPM (RPM Package Manager, originally called Red Hat Package Manager) package and whether the remote host is of a certain release type. Possible release types are MDK, SUSE, FC1, FC2, FC3, RHEL4, RHEL3, and RHEL2.1. These correspond to Mandrake, SuSE, Fedora Core 1, Fedora Core 2, Fedora Core 3, Red Hat Enterprise Linux 4, Red Hat Enterprise Linux 3, and Red Hat Enterprise Linux 2.1, respectively.

The value of one is returned if the package installed on the remote host is newer or exactly as the version provided, whereas the value of zero is returned if the package installed on the remote host is newer or exactly the same as the version provided.

For example, the following code will verify whether the remote host is a Red Hat Enterprise Level 2.1 and whether the remote host has a Gaim package that is the same or later than version 0.59.9-4:

if ( rpm_check( reference:"gaim-0.59.9-4.el2", release:"RHEL2.1") )

The same test can be done for Red Hat Enterprise Level 3 and Red Hat Enterprise Level 4:

if ( rpm_check( reference:"gaim-1.2.1-6.el3", release:"RHEL3") || rpm_check( reference:"gaim-1.2.1-6.el4", release:"RHEL4") )

However, in the preceding case, the Gaim version available for Red Hat Enterprise Level 3 and 4 is newer than the version available for Red Hat Enterprise Level 2.1.

The rpm_exists function is very similar to rpm_check. However, in this case, rpm_exists tests not for which version of the package is running, but for only whether the RPM package exists on the remote host. The value of one is returned if the package exists, whereas the value of zero is returned if the package does not exist.

The return values of rpm_check function are zero if the remote host’s distribution is irrelevant and one if the package exists on the remote host.

For example, you can determine whether the remote Fedora Core 2 host has the mldonkey package installed; if it does, your cooperation policy is broken, and you will want to be informed of it:

if ( rpm_exists(rpm:"mldonkey", release:"FC2") )

The aix_check_patch function is very similar to rpm_check; however, AIX software patches are bundled together in a manner similar to the Microsoft’s service packs; therefore, you verify whether a certain bundle has been installed, not whether a certain software version is present on a remote host.

The return values of this function are zero if the release checked is irrelevant, one if the remote host does not contain the appropriate patch, and minus one if the remote host has a newer version than the provided reference.

– The deb_check function is equivalent to the rpm_check function, but unlike the rpm_check, the different Debian versions are provided as input instead of providing a release type (such as Red Hat/Fedora/Mandrake/SuSE). In addition, unlike the rpm_check function, the version and the package name are broken into two parts: prefix, which holds the package name, and reference, which holds the version you want to be present on the remote host.

The return values of this function are one if the version found on the remote host is older than the provided reference and zero if the architecture is not relevant or the version found on the remote host is newer or equal to the provided reference.

For example, in Debian’s DSA-727, available from www.debian.org/security/2005/dsa-727, you can see that for stable distribution (woody) this problem has been fixed in version 0.201-2woody1; therefore, you conduct the following test:

if (deb_check(prefix: 'libconvert-uulib-perl', release: '3.0', reference: '0.201-2woody1'))

For the testing (sarge) and unstable (sid) distributions, this problem has been fixed in version 1.0.5.1-1; therefore, you conduct the following test:

if (deb_check(prefix: 'libconvert-uulib-perl', release: '3.2', reference: '1.0.5.1-1'))

if (deb_check(prefix: ‘libconvert-uulib-perl’, release: ‘3.1’, reference: ‘1.0.5.1-1’))

The pkg_cmp function is equivalent to the rpm_check, but is used for the FreeBSD operating system. The function pkg_cmp doesn’t verify which version of FreeBSD is being queried; this has to be done beforehand by grabbing the information found under the Host/FreeBSD/release knowledge base key and comparing it with the FreeBSD release version. The return values of this functions are one or larger if the remote host’s version of the package is older than the provided reference, zero if both versions match, and minus one or smaller if the package is irrelevant to the remote host or the version running on the remote host is newer than the provided reference.

The hpux_check_ctx function determines whether the remote host is of a certain HP UNIX hardware version and HP UNIX operating system version. This is done by providing values separated by a space for each relevant hardware and operating system pair. Each such pair is separated by a colon. The return values of this function are one for architecture matched against the remote host and zero for architecture that does not match against the remote host.

For example, the string 800:10.20 700:10.20 indicates that you have two relevant sets for testing. The first hardware version is 800, and its operating system version is 10.20. The second hardware version is 700, and its operating system version is also 10.20. If one of the pairs is an exact match, a value of one is returned; if none of them match, the value of zero is returned. The value of the remote host’s hardware version is stored under the Host/HP-UX/version knowledge base item key, and the remote host’s operating system version is stored under the Host/HP-UX/hardware knowledge base item key.

The hpux_patch_installed function determines whether a remote HP-UNIX host has an appropriate patch installed, such as AIX. HP-UNIX releases patches in bundles named in the following convention: PHCO_XXXXX. The return values of this function are one if the patch has been installed and zero if the patch has not been installed.

Once you have used the hpux_check_ctx function to determine that the remote host’s hardware and operating system versions are relevant, you can call the hpux_patch_installed function and determine whether the patch has been installed. Multiple patches can be provided by separating each patch with a space character.

For example, to create a test for the vulnerability patched by PCHO_22107, available at ftp://ftp.itrc.hp.com/superseded_patches/hp-ux_patches/s700_800/11.X/PHCO_22107.txt, you’ll start by verifying that the remote host’s hardware and system operating system versions are correct:

if ( ! hpux_check_ctx ( ctx:“800:11.04 700:11.04 ” ) )

{

exit(0);

}

Follow up by testing whether the remote host has the appropriate PHCO installed and all the ones this PHCO_22107 depends on:

if ( !hpux_patch_installed (patches:“PCHO_22107 PHCO_21187 PHCO_19047 PHCO_17792 PHCO_17631 PHCO_17058 PHCO_16576 PHCO_16345 PHCO_15784 PHCO_14887 PHCO_14051 PHCO_13606 PHCO_13249”))
{

security_hole(0);

}

However, the code in the previous example doesn’t verify whether the remote host’s patch files have been installed; instead, it verifies only whether the remote host has launched the appropriate patches. To verify whether the remote host has been properly patched, you need to call the hpux_check_patch function.

The hpux_check_patch function verifies whether a remote HP-UNIX system has installed a patch and if the user has let the patch modify the operating system’s files. The return values of this function are one if the package is not installed on a remote host and zero if the patch has been installed or is irrelevant for a remote host.

For example, for the aforementioned PHCO_22107 advisory, you must confirm that OS-Core.UX-CORE’s version is B.11.04. The following code will verify that OS-Core.UX-CORE is in fact of the right version; if it is not, it will notify that the remote host is vulnerable:

if ( hpux_check_patch( app:"OS-Core.UX-CORE", version:"B.11.04") )

{

security_hole(0);

exit(0);

}

The qpkg_check function is equivalent to the rpm_check, but it is used for testing the existence of packages on Gentoo distributions. The function verifies that the package has been installed on the remote host and then verifies whether a certain version is equal to, lower than, or greater than the provided version of vulnerable and immune versions.

The return values of this function are zero for irrelevant architecture or when a package is not installed on a remote host, and one if the patch has been installed.

In the following example, you will verify whether a remote host contains the patches provided for the gdb package, as described in www.gentoo.org/security/en/glsa/glsa-200505-15.xml:

For the GLSA-200505-15 you need to check first the package named sys-devel/gdb and then the unaffected version >= 6.3-r3, meaning you need to write ge 6.3-r3 followed by the vulnerable version < 6.3-r3. So you need to write l 6.3-r3. The complete line of this code reads as follows:

if (qpkg_check(package: "sys-devel/gdb", unaffected: make_list("ge 6.3-r3"), vulnerable: make_list("lt 6.3-r3") ))

{

security_hole(0);

exit(0);

}

Master Craftsman

Adding Additional Operating Systems

The aforementioned functions do not cover all available UNIX-based operating systems. Extending these functions to support other operating systems is easy. Operating systems that are extensions of other operating systems would require little, if any, changes; for example, Ubuntu, which is an extension of Debian. Other operating systems would require more changes; however, if you can provide two functions to the Nessus environment, you can easily add support to your operating system:

·         SSH connectivity

·         A way to list all the packages/products installed on the operating systems and their corresponding versions

If the preceding two functions are available, you can index the list of packages and their versions through the SSH channel. You then can create a test that determines whether the package is installed and if its version is lower than the one that is immune to attack.

The solaris_check_patch function verifies whether a certain patch exists on a remote Solaris machine. As in the case of HP-UNIX, the function verifies the release type, architecture—hardware type, patch (which can be made obsolete by some other patch), followed by the name of the vulnerable package. The vulnerable packages can be more than one, in which case they are separated by the character space.

The return values of this function are minus one if the patch is not installed, zero for irrelevant architecture or if the package is not installed on the remote host, and one if the patch has been installed.

Final Touches

You have learned different functions provided by the smb_nt.inc include file and the smb_hotfixes.inc file that can be used to test Windows-based devices. Furthermore, you have seen what functions are provided by the aix.inc, debian_package.inc, freebsd_package.inc, hpux.inc, qpkg.inc, rpm.inc and solaris.inc include files to test UNIX-based devices. After viewing examples in this chapter, you should understand how to use these various functions.