Oracle RDBMS (Database and OJVM) Patch Mapping Improvements...
Oracle RDBMS (Database and OJVM) Patch Mapping Improvements Summary Improvements have been made to how Nessus plugins determine the active version of the Oracle RDMS’s Database and OJVM components. How Patch Mapping Works for Oracle Database Scans Prior to these improvements, the Database and OJVM versions were mapped from installed patches and their corresponding versions via a manually maintained mapping library, oracle_database_mappings.inc. Installed patches are enumerated in one of three possible ways: Linux Local Detections: oracle_enum_products_nix.bin (plugin ID 71642, requires SSH credentials) Windows Local Detections: oracle_enum_products_win.nbin (plugin ID 71643, requires SMB credentials) Direct connection to the Database via oracle_rdbms_query_patch_info.nbin (plugin ID 45642, requires Database credentials) The patch information is stored by the scanner in a temporary database known as the “scratchpad”, for later reference. Plugin ID 71644, "oracle_rdbms_patch_info.nbin", is then run and sets the patch level (version) by checking the detected patches against the mapping in "oracle_database_mappings.inc". Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As this mapping library is manually maintained, some patches were not mapped in time for vulnerability plugin releases, which is a semi-automated process. In the event that the target system has no patches installed that match a mapping from "oracle_database_mappings.inc", only the base version is reported (e.g 21.17.0.0.0), possibly resulting in False Positive findings. Improvements As we already have a complete list of installed patches and their descriptions stored in the aforementioned “scratchpad” we have added an additional layer of patch mapping over this. Plugin ID 71644, will now first attempt to parse the patch info directly from the scratchpad and map the installed patches to their corresponding versions based on the patch description. The existing mapping library is still checked, and a version comparison is performed to determine the highest patch level present. Plugin ID 71644 will now also report the patch levels (version) for the Database and OJVM components in its output. Expected Impact Improved accuracy in version detections for Oracle Database and OJVM resulting in less false positives in downstream vulnerability detection plugins Impacted plugins 71644, oracle_rdbms_patch_info.nbin 45624, oracle_rdbms_query_patch_info.nbin Targeted Release Date Monday, April 7, 2025
Netstat Portscanner Update to Use Sockstat (ss) Utility...
Netstat Portscanner Update to Use Sockstat (ss) Utility Summary The Netstat Portscanner plugin runs during credentialed scans to enumerate open ports. After authenticating to the scan target, the plugin will attempt to run the ‘netstat’ command to identify listening ports. Modern Linux and Unix distributions are providing the 'ss' utility and have removed 'netstat', while 'netstat' is still available on older distributions. The Netstat Portscanner will now attempt to use the ‘ss’ utility if the ‘netstat’ utility is not available. Thus, older distributions will continue to use the ‘netstat’ utility, while newer distributions that do not include ‘netstat’ will use the ‘ss’ utility. Impact Customers may notice credentialed scans identify additional open ports. They may also see additional vulnerability plugins and informational plugins triggered in these scans due to the newly identified open ports. Plugin Netstat Portscanner (SSH) (14272) Target Release Date April 25th, 2023
SSH Key Target Authentication: HashiCorp Vault Summary...
SSH Key Target Authentication: HashiCorp Vault Summary Tenable is announcing the release of updated functionality in regards to credential fetching in our HashiCorp Vault Integration. We have updated this integration to retrieve an SSH key for target authentication. This will expand functionality and usability for our customer’s use cases. Scope When using HashiCorp, customers can now retrieve an SSH key stored as a secret in their HashiCorp Vault. The customer can specify the SSH key using the same “Password Key” field in the User Interface. Previously this would only work for password authentication. Additionally, passphrase protected SSH keys can be specified with the appropriate “Password Key” and “Passphrase Key” specified. Impact There is no impact to existing scans. In Nessus and Tenable VM, a new Passphrase Key field will be present in credentials using HashiCorp Vault for SSH scans. Security Center will get the same field at a later date. If users encounter issues, please open a ticket with Technical Support. Release Date November 15th, 2024 - TVM, Nessus; TBD for Security Center.Delinea Secret Server functionality for on-premises and...
Delinea Secret Server functionality for on-premises and cloud Summary Tenable has verified that our existing PAM integration with Delinea Secret Server works with both the on-premises and cloud versions. Change Minor changes were made to our integration for added Secret Server cloud compatibility. More details may be found about this integration within the product documentation for Nessus (Windows, SSH), Tenable Vulnerability Management (Windows, SSH), and Tenable Security Center (Windows, SSH). Impact If customers encounter issues with this integration, please open a ticket with Technical Support. Tenable will engage with Delinea as needed to identify and resolve any issues. Release Date April 29, 2024 - TVM, Nessus, and Security CenterSSH Authentication - Target Priority Lists Summary Tenable...
SSH Authentication - Target Priority Lists Summary Tenable is updating many of their products to allow specific hostnames and IP addresses to be indicated for specific SSH credentials. Some customers wish to have numerous SSH credentials in a specific scan policy, against several target devices. Because of the way our SSH credential attempts were previously structured, they would each be tried in turn until a successful authentication with a credential was discovered. We have added a new field in SSH credentials for Nessus, T.io, and similar products (T.sc will add this later): a "Targets to prioritize credentials" field. Impact Any SSH credential may have a list of specific hostnames or IPs (comma or space separated) entered in this field. If any of the scan targets match a hostname or IP address within that field, then that credential will be bumped to the front of the list of credentials tried. If you have 100 credentials specified, and the successful one for a given target is the 59th set, but that credential has the target machine's hostname or IP in the targets “Targets to prioritize credentials" field, then that credential will be tried in front of every other credential that does not have that hostname or IP in that field. It could be the 59th credential specified, but it will be one of the first SSH credentials attempted against that target machine. This will save customers a lot of time if they would like credentials that they know work against a target machine to be attempted first for that machine. This feature will be available on any Tenable product that ties credentials to a specific scan policy. Products where the credentials can exist separately to the scan policy (T.sc) will have this feature implemented for those non-policy-attached credentials at a later time. Changes Any customers who have several SSH credentials and several scan targets in a single scan policy should consider entering the correct hostnames and IPs for their target machines into the appropriate SSH credential's "Targets to prioritize credentials" field to optimize their scans and make them run faster. Target Release Date Immediate
New Cisco Viptela SD-WAN Compliance Plugin and Audit Files...
New Cisco Viptela SD-WAN Compliance Plugin and Audit Files Summary Customers can now measure compliance against Cisco Viptela SD-WAN devices with new plugin ID 161408. This plugin retrieves target data via SSH using 'show' commands to evaluate actual values against a given audit policy. Four Tenable best practice audits are being released simultaneously with this plugin: - Tenable Best Practices Cisco Viptela vManage v1.0.0 - Tenable Best Practices Cisco Viptela vBond v1.0.0 - Tenable Best Practices Cisco Viptela vEdge v1.0.0 - Tenable Best Practices Cisco Viptela vSmart v1.0.0 These audits were developed against NIST 800-53 guidelines as well as Cisco documentation. They include checks that evaluate: - Reviewing user accounts - Login banners - Timeouts - Remote and disk logging - NTP - Backup settings - and more! Target Release Date The audits can be download from the Tenable Audits Portal on July 18, 2022 Additional Notes: Online (credentialed) and offline scanning is supported.SSH Debug Log Levels and Limits Summary Tenable products...
SSH Debug Log Levels and Limits Summary Tenable products have long been able to log the details (minus credentials) of SSH connections. Plugin debugging has been an optional setting for scans and scan policies allowing debugging logs to exist to help determine what causes issues. Since the adoption of our revised ssh library in the late 2010s, we have been logging a thorough and accurate amount of details. As more and more plugins leveraged SSH connectivity our logging has put a strain on scanner and scan target resources in some customer environments. In response to these issues, we have revised the logging on our sshlib, with new logging functions in debug.inc, new debug levels specified in the GUI, and have migrated both new and old ssh libraries to use the new logging setup. What does this mean to our customers? Any customer using plugin debugging will be able to select from debugging levels 1 through 4 in their scan configurations. By default, all policies where this value is not intentionally set higher will be set to 1, the lowest amount of detail. Customers can fine tune this setting themselves. Debugging level 1 represents the lowest amount of details, mostly for connections, commands and results, and automatically trims log messages greater than 500 bytes. Debugging level 2 represents a medium amount of details, including all debug messages from level 1, but also including more details on protocols being used, packet types, and slightly more esoteric logging information. It automatically trims log messages greater than 1000 bytes. Debugging level 3 represents a high amount of details, including all debug messages from levels 1 and 2, and including details on shell handlers, actual deep dives into packets received and sent, the works. It automatically trims log messages greater than 1500 bytes. Debugging level 4 represents a complete and unrestricted amount of details, including all debug messages from levels 1, 2, and 3, but with absolutely no log truncation. Our current logging setup effectively runs on level 4, and that's why we will occasionally see very large log files. Scanners configured to use debugging level 4 should be resourced to handle potentially large amounts of logging data. Any customer scans that do not have plugin debugging enabled will see no change in their scan output or performance. Change Tenable products will soon have the ability to specify debugging level when plugin debugging is enabled. By default, these will be set to 1, indicating a minimal amount of logging. Customers may choose to raise this level if they want to see some more or a lot more details in their plugin debugging logs. Customers who have been experiencing issues with the Debugging Log Report plugin not functioning correctly because of too much data will be well served by either leaving the plugin debugging level at 1 or 2. Additional detail can be gathered using level 3. Customers with these issues should avoid debugging level 4. Plugins: "Authenticated Check : OS Name and Installed Package Enumeration" (Plugin ID: 12634) "OS Identification and Installed Software Enumeration over SSH v2 (Using New SSH Library)" (Plugin ID: 97993) All plugins that leverage ssh connections (too many to list) Target Release Date 31 MAY 2022
Senhasegura Privileged Access Management Integration...
Senhasegura Privileged Access Management Integration Summary We are proud to announce that Tenable customers can now use the Senhasegura Privileged Access Management (PAM) Integration to gather credentials to be used for target authentication during a scan in Tenable.io and Nessus Manager, with tentative plans to release this feature in Tenable.sc 6.2. Senhasegura PAM integration supports SSH (with privilege escalation), SMB (Windows), and database target authentication. With this addition, customers will benefit from streamlined privileged access to use in credentialed vulnerability scans, providing a more comprehensive understanding of your cyber exposure. Supported Authentication Types SSH integration includes least privilege, privilege escalation, and SSH Key authentication. SMB (Windows) integration includes Domain configuration. Database integration includes the following database types: Oracle SQL Server MySQL Cassandra MongoDB PostgreSQL Sybase ASE DB2 Target Release Date March 7th 2023 https://senhasegura.com/OpenSSH Private Keys for Authentication Summary Nessus can...
OpenSSH Private Keys for Authentication Summary Nessus can now use OpenSSH formatted private keys for SSH authentication in local-checks scans. OpenSSH only supports the "SSH" standard format for ED25519 keys, so when Nessus introduced support for ED25519 keys for SSH authentication, it had to support the native OpenSSH key format. The change described here extends that support to private keys of the other SSH public key algorithm types. Impact Prior to this change, customers with RSA or ECDSA keys would either have to generate their key-pairs using "ssh-keygen -m pem" or use that command to convert existing OpenSSH private keys to use with Nessus SSH credentials. Now customers can generate SSH keys with either PEM or OpenSSH formatted private keys and use them with Tenable local-checks credentials for Nessus scans. Explanation SSH private keys are packaged on the file system as a base64 encoded block sandwiched inside of a text header and footer. This is a super-encoding called "PEM". OpenSSH's "ssh-keygen" command uses the labels "pem" or "pkcs8" to refer to the PKCS#8 binary encoding of data within the base64 encoded block. When "ssh-keygen" is used to create keypairs without a specified encoding or with the tag "rfc4716", the base64 encoded block is in the binary format defined by RFC4716. PKCS8 PEM encoded private keys have a header like "-----BEGIN RSA PRIVATE KEY-----" or "-----BEGIN EC PRIVATE KEY-----" with corresponding footers. RFC4716 PEM encoded private keys can be identified by a header that looks like "-----BEGIN OPENSSH PRIVATE KEY-----" with a corresponding footer. Release Date August 8, 2024
Arcon Network Device Support Summary Tenable has added...
Arcon Network Device Support Summary Tenable has added support for additional types of targets when using the Arcon integration. Change There is a new optional field, “Arcon Target Type”, which can be set to one of the following: windows linux networkdevices application Depending on the version of Arcon PAM, additional values may be allowed in this field. Please refer to the Arcon PAM specifications document for a full list of valid target types. When specified, scans using the Arcon integration will query accounts of the specified type. This enables the ability to integrate with, for example, accounts of network devices accessed via SSH. For example, see the following screenshot of a credential for a network device accessed via SSH. Impact There is no impact on existing scan credentials, because the new field is optional. When not specified, the behavior will remain the same. Release Immediate for Nessus and VM, TBD for SC.
