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, 2025SSH 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 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.Nessus Adds EC25519 Support for SSH Local Checks Summary...
Nessus Adds EC25519 Support for SSH Local Checks Summary SSH local checks in the Nessus now support the lightweight and secure 25519 elliptic curve. This support includes all standard uses of the 25519 curve including host signature validation, authenticating clients to hosts, hosts to clients and Diffie-Hellman generation of shared secret keys for over the wire encryption. Notes All aspects of curve 25519 support for SSH in Nessus require Nessus 10.4 or higher. Key exchange using curve 25519 requires Nessus 10.5 or higher EC25519 keys for hosts and users must be created using the OpenSSH keygen tool. They must also be PEM formatted. The actual binary format of these keys is not PEM, however. It is an OpenSSH proprietary format that mimics the outward appearance of traditional PEM formatted keys by being base64 encoded and bounded by a text header and footer. Example The following command demonstrates the creation of an EC25519 public/private keypair for use in Nessus public key authentication: ssh-keygen -t ed25519 -m pem -f my_25519_ssh_keypair Target Release Date February 20, 2023Completing the Implementation of SSH Library Modernization
Completing the Implementation of SSH Library Modernization Change In mid-2017, ssh_get_info2.nasl was introduced, leveraging the sshlib library effort that streamlined new ssh connectivity for scan targets. The original SSH/RSH/RLOGIN connectivity plugin 12643 and associated ssh library had 13+ years of legacy connectivity plugins built on top of them. These legacy ssh library dependent plugins have been steadily migrated to the new ssh_get_info2 library as updates to the plugins have been needed. Over the past 12 months, there has been a push to port the few remaining plugins that rely on the legacy ssh_get_info library to the new ssh_get_info2 library and this effort will soon be complete. The current SSH detection plugin, ssh_get_info2 (97993), currently falls back to the legacy detection plugin, ssh_get_info.nasl (12634), if it encounters an error. After this change, that fall back will no longer happen. All plugin transitions from the legacy ssh_get_info to the new ssh_get_info2 calls have been thoroughly tested and closely watched via telemetry to ensure functionality has not been negatively impacted. Impact Ideally, there will be no noticeable impact from these changes. However, from time to time against certain targets the legacy library has been able to succeed in running commands and gathering results when the current library fails. Going forward, the failure of the current SSH library will appear as an error and plugins may fail to report when formerly they would succeed. Affected Plugins This change will happen for every Nessus plugin that runs SSH commands against a remote target. Compliance audits, Nessus agent scans and Tenable scans that use a sensor other than Nessus will not be impacted. Target Release Date November 27, 2023 Tenable Research Release Highlights are posted in advance of significant new releases or updates to existing plugins or audit files that are important for early customer notification.
Wallix SSH Key Authentication Summary SSH key support has...
Wallix SSH Key Authentication Summary SSH key support has been added to the Wallix Bastion Privileged Access Management (PAM) integration. When configuring SSH credentials in Wallix Bastion, customers can now choose to use either a password or an SSH key to authenticate to target hosts. Change This does not change the user interface for the Wallix integration. If a private key is configured for a device’s account in Wallix, then the integration will use the private key to authenticate. Impact Current configurations will not change. The new authentication method can be used if desired. Target Release Date Changes are active now
New plugins to detect weak SSH servers Rationale Tenable is...
New plugins to detect weak SSH servers Rationale Tenable is publishing three new plugins to help users detect SSH servers using cryptographic algorithms that may be considered weak. Because SSH requires both the server and the client to use an agreed-upon encryption scheme, customers may have a business justification for using outdated or weak SSH cryptographic algorithms. These three plugins will allow our users to identify the servers in their environments that employ weak cryptographic algorithms. They are then enabled to make informed risk decisions about upgrading, retiring or strengthening protections around these SSH servers with a defense in depth architecture. KEX SHA-1 for SSH - The first is a Low severity plugin to detect SSH servers that are configured to allow weak (SHA-1 based) key exchange algorithms. This is based on the IETF draft document "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)" which can be viewed at https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-20. Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST NOT be enabled. These are all SHA-1 based algorithms and include diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1, gss-gex-sha1-*, gss-group1-sha1-*, gss-group14-sha1-*, and rsa1024-sha1. RSA shorter than 2048 - Next is another Low severity plugin to detect SSH servers that are configured with an RSA host key that is shorter than 2048 bits. This is based on the recommendations in "NIST Special Publication 800-57 Part 3 Recommendation for Key Management" which can be viewed at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf. SHA-1 based MAC - The third is an Informational severity plugin that will detect SSH servers that are configured to allow a SHA-1 based message authentication code (MAC). This is not actually considered weak, but is being made available for users that wish to identify these servers. This plugin has already been published and is currently in the plugin feed. Impact Plugin 153953 "SSH Weak Key Exchange Algorithms Enabled" - Tenable Research has identified that approximately 60% of SSH servers are likely to have weak key exchange algorithms enabled. This will manifest in a new Low severity plugin firing for the majority of users scanning SSH servers. Plugin 153954 "SSH Host Keys < 2048 Bits Considered Weak" - Tenable Research has identified that approximately 2% of SSH servers are likely to have host keys that are shorter than 2048 bits. This will manifest in a new Low severity finding for users scanning these servers. Plugin 153588 "SSH SHA-1 HMAC Algorithms Enabled" is Informational only and is already in the plugin feed. New Plugins 153953 SSH Weak Key Exchange Algorithms Enabled | CVSSv2 2.6 (Low) | CVSSv3 3.7 (Low) 153954 SSH Host Keys < 2048 Bits Considered | CVSSv2 2.6 (Low) | CVSSv3 3.7 (Low) 153588 SSH SHA-1 HMAC Algorithms Enabled | CVSSv2 N/A (Info) | CVSSv3 N/A (Info) Target Release Date Wednesday, October 13th, 2021SSH 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 2022Delinea 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 Center