Last updated at Sat, 19 Aug 2017 16:05:40 GMT

Nexpose version 5.9.10 includes significant improvements to its Oracle Database fingerprinting and vulnerability coverage. When configured with appropriate database credentials, Nexpose scans can accurately identify which patches have been applied. This post will go through the steps for setting up such a scan, as well as discuss some of the finer details about Oracle's versioning scheme and the terminology around their quarterly Critical Patch Update program.

Scanning Oracle Databases with Nexpose

Nexpose requires access to the sys.registry$history table in order to determine the patch level of the database. While Nexpose will happily scan your database when configured to log in as a highly privileged role such as SYSDBA, this is not recommended. You may create a user with more limited access as follows:

CREATE USER nxpscan IDENTIFIED BY aStrongerPasswordThanThis;
GRANT create session TO nxpscan;
GRANT select ON sys.registry$history TO nxpscan;

With this account in place, you may now configure a Nexpose site to use the Oracle-specific credentials. Assuming you have a site with your database hosts and an applicable scan template (e.g. Full audit without Web Spider) set up, on the Site Configuration page click the "Credentials" link at the left and then the "New" button under the Credential Listing

Enter a name and (optionally) a description for the credentials in the General section of the Site Credential Configuration editor. Then click the Next button.

In the Account section of the Site Credential Configuration editor, choose "Oracle" as the Service, fill in the appropriate SID for your database, and the user name and password you created earlier. Check that the credentials are valid by clicking on "Test Credentials," entering the host name and port, and then clicking the "Test credentials" button.

If all goes well an "Authentication succeeded" dialog will appear. Click "OK" on it and then click "Save" on the Site Credential Configuration editor. The new credentials should now appear in the Site Configuration. Click "Save" again.

Any Oracle Database installations in the site for which these credentials are valid will now be accurately fingerprinted, and any missing Critical Patch Updates will show up under the asset's vulnerability listing.

Unauthenticated Scans

Without database credentials, Nexpose is only able to determine version information up to the "patch set" level -- that is, the fourth part of the version string (see below). In older checks, Nexpose attempts to trigger error conditions in order to look for the presence of specific vulnerabilities, for example by attempting buffer overflows or SQL injections. Other checks, which rely on version numbers to determine vulnerabilities, are classified as "potentials" and will not run unless explicitly enabled in a scan template. If potential checks are enabled and no valid credentials are available, an Oracle Database scan may result in many false positives.

Oracle Database Versions

Why does Nexpose need access to system tables to achieve accurate results? Oracle Database versions follow a five-part versioning scheme A.B.C.D.E, where A is the major release, B is the maintenance release, C is the application server release number, D is the patch set, and E is the patch set update number. For example, an Oracle Database at version 11.2.0.3.10 is interpreted as an 11_g_R2 database, at patch set 11.2.0.3, with update 10 applied. When connecting to a database server, only the first four parts are sent. Oracle's quarterly updates typically only affect the fifth part of the version (E), or in the case of Security Patch Updates (SPUs), not at all.

Oracle has a variety of types of patch releases, their terminology for which has changed over time:

  • Bundle Patch (BP) - An iterative, cumulative patch that is issued between patch sets. Bundle patches usually include only fixes, but some products may include minor enhancements. Examples are the Database Windows Bundles and SOA Bundle Patches.
  • Critical Patch Update (CPU) - Oracle's program for quarterly release of security fixes. Patches released as part of this program may be Patch Set Updates, Security Patch Updates, and Bundle Patches. Regardless of the patch type, the patches are cumulative. Previously, CPU was also the term used for Oracle's security-only patches (now known as SPUs).
  • Interim Patch - A patch containing one or more fixes made available to customers who cannot wait until the next patch set or new product release to get a fix.
  • Patch Set - An integrated, cumulative, fully tested collection of fixes issued in between major product releases. Patch sets may include minor enhancements. Fourth part of the version string.
  • Patch Set Update (PSU) - A quarterly patch that contains the most critical fixes for the applicable product, allowing customers to apply one patch to avoid many problems. Fifth part of the version string.
  • Security Patch Update (SPU) - An iterative, cumulative patch consisting of security fixes. Formerly known as Critical Patch Update. Does not affect version string.

Nexpose will fingerprint the most recently applied PSU, SPU, or BP. To see the patch level a database is at, find the "Oracle TNS Listener" under the Service Listing of an asset, and click it.

Any discovered configuration items will be shown, including the update type and version:

In this case, you can see that the Security Patch Update (spu) from January 2014 (2014-01) has been applied. If the Patch Set Update had been applied, as opposed to the SPU, the version would be 11.2.0.4.1 and the updateType would be "psu." In the case of a database running on Windows, the version would be 11.2.0.4.BP1 (Bundle Patch 1) and the updateType would be "winbundle."