Overview of Callbacks in Log4j Remote Detection Plugins The...
Overview of Callbacks in Log4j Remote Detection Plugins The following is an overview of callbacks in Tenable plugins for Log4Shell that perform remote detection 155998, 156014, 156016, 156017, 156035, 156056, 156115, 156132, 156157, 156158, 156162, 156166, 156197, 156232, 156256, 156257, 156258, 156375, 156445, 156559, and 156669. A HTTP request is sent by the scanner to the target being scanned with a benign payload containing a unique token. The target, if vulnerable, will act on the payload. Tenable tracks the target’s action on the payload via a callback to our hosted environment (plugins 156014, 156016, 156017, 156035, 156056, 156115, 156132, 156157, 156158, 156162, 156166,156197, 156232, 156256, 156257, 156258, 156375, 156445, 156559, and 156669) based on the unique token that was embedded in the initial request or via the LDAP connection callback to the scanner for plugin 155998. The callback is needed given the nature of the vulnerability as execution of the payload happens on the target being scanned. In plugin 155998, the callback happens to the scanner. This is the reason the plugin is not supported on Tenable.io cloud scanners In plugins 156014, 156016, 156017, 156035, 156056, 156115, 156132, 156157, 156158, 156162, 156166, 156197, 156232, 156256, 156257, 156258, 156375, 156445, 156559, and 156669 as part of execution of the payload, the target tries to resolve a domain owned by Tenable. While resolving the domain, Tenable is able to see the unique token that was sent in the initial request and thereby can track the callback. These plugins come with the major benefit that credentials are not required for scanning. However, the callbacks need to be successful for the plugin to be able to identify the exposure. Hence, communication between the target being scanned and the callback server must not be interrupted by intermediary devices. For more details: https://community.tenable.com/s/feed/0D53a00008E3hKzCAJ https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerabilityTenable Research Release Highlight Nessus Agent Reset...
Tenable Research Release Highlight Nessus Agent Reset Plugin and Scan Template Summary Tenable Research has released a Credentialed Scan plugin and Scan Template “Nessus 10.8.0 / 10.8.1 Agent Reset” in support of addressing the issues in the Nessus Agent 10.8.0 and 10.8.1. Change New Scan Template: “Nessus 10.8.0 / 10.8.1 Agent Reset” Pre-requisite: Ensure that the agent version is set to 10.8.2 or 10.7.x in Agent Profile (for TVM) and Nessus Manager (for TSC). This Scan Template and Credentialed Scan plugin will run OS specific scripts to remotely reset the agent plugins on Windows, Mac OS or ‘Nix based Nessus Agent host machines on 10.8.0 or 10.8.1. These scripts and the permissions level each script requires are detailed in the Nessus Agent 10.8.2 Release Notes (https://docs.tenable.com/release-notes/Content/nessus-agent/2025.htm#10.8.2) under the [Perform a plugin reset] section. Notes: The Nessus Agent Reset plugin will only run from the provided Scan Template and will not reset Nessus Agents when run from any other Scan Template. For Ubuntu/Debian Unix credentials, please ensure that only one set of privilege escalation credentials are provided with the required permissions level for the OS script to execute. 13 JAN 2025 UPDATE: Please note that triggering a plugin reset will result in a large spike in network traffic. Impact Without this script, customers would have to logon to each Nessus Agent host and run the appropriate Nessus Agent Reset script for that host OS. Using this Scan Template and Credentialed Scan plugin, customers can run the Nessus Agent Reset scripts on each updated Nessus Agent from a Remote Credentialed Scan, with the necessary credentials and permissions, using Nessus, Nessus Manager, T.VM, and T.SC (released 08 JAN). Target Release Date 07 JAN 2025
Security End of Life (SEoL) Plugin Conversions 2024 Q4...
Security End of Life (SEoL) Plugin Conversions 2024 Q4 Change In accordance with the SEoL framework published in April 2023, we are updating and/or deprecating the legacy “Unsupported <x>” plugins to conform to the new plugin specification. Only the Unsupported plugins listed in the “Deprecated Plugin” table below have been deprecated and replaced with SEoL plugins - all other plugins that detect Unsupported software remain in service. Impact Customers should anticipate the legacy “Unsupported” plugins to be deprecated and/or converted to their corresponding SEoL plugins. This may result in new findings and a more detailed picture of the exposure landscape associated with products in the SEoL state. Customer-created dashboards or reports that use the now-deprecated “Unsupported” plugins should be migrated to use the new SEoL plugins listed below. For additional details please see the SEoL FAQ knowledge base article from June 2023. This FAQ covers questions about SEoL plugin severity ratings, considerations for extended vendor support agreements, and future product coverage. Converted Plugins Deprecated Plugin: 55690; IBM DB2 Unsupported Version Detection New Plugin(s): IBM DB2 SEoL Deprecated Plugins: 40362; Mozilla Foundation Unsupported Application Detection, 56584; Mozilla Foundation Unsupported Application Detection (macOS) New Plugin(s): Firefox and Thunderbird SEoL Deprecated Plugin: 78675; WinZip Unsupported Version Detection New Plugin(s): Winzip SEoL Deprecated Plugins: 95258; Fortinet FortiClient Unsupported Version Detection (macOS), 93098; Fortinet FortiClient Unsupported Version Detection New Plugin(s): Fortinet Forticlient SEoL Deprecated Plugin: 56710; Wireshark / Ethereal Unsupported Version Detection New Plugin(s): Wireshark SEoL Consolidated List of Deprecated Plugins 55690, 40362, 56584, 78675, 95258, 93098, 56710 Target Release Date January 6, 2025 Additional Notes For a complete list of current SEoL plugin coverage, please visit https://www.tenable.com/plugins/search?q=%22SEoL%22. Additional coverage requests can be made via Tenable’s Suggestions Portal at https://suggestions.tenable.com.Nessus can now use Kerberos for DCOM Authentication Summary...
Nessus can now use Kerberos for DCOM Authentication Summary Nessus scans that are provided with Windows Kerberos credentials will now use the Kerberos protocol for authentication in plugins that use DCOM or WMI. Kerberos authentication has been available for a long time in Nessus for plugins that only use SMB. Prior to this change the DCOM/WMI plugins would authenticate using NTLM even if only a Kerberos credential was provided. Microsoft Windows is abandoning NTLM due to security concerns and has recommended host and domain configuration that excludes the use of NTLM. Change This implementation of Kerberos for DCOM/WMI only supports the packet integrity authentication level (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) which is the minimum required since Microsoft hardened DCOM to address CVE-2021-26414. If a server or service requires packet privacy (RPC_C_AUTHN_LEVEL_PKT_PRIVACY), Nessus will not be able to scan it. Following the deprecation of SHA1 hashes, Kerberos will slowly be updated to use SHA2 hashes on Windows and other platforms. At this time the Nessus implementation does not support SHA2 based checksums or encryption. Future Tenable plans include upgrading the Nessus DCOM implementation to use packet privacy and upgrading the Nessus Kerberos implementation to use SHA2 based cryptography. Target Release Date Immediate
New RedHat OpenShift Container Platform Plugin and Audit...
New RedHat OpenShift Container Platform Plugin and Audit files Summary Customers can now measure compliance against RedHat OpenShift Container Platform with new plugin ID 161406 on Tenable.io and Nessus. This plugin will be published with a new credential type: OpenShift Container Platform. This plugin retrieves target data using the RedHat OpenShift Container Platform API and will evaluate actual values against a given audit policy. All data retrieval and communication is via the RedHat OpenShift Container Platform API. Additional Notes Two CIS audits will be released along with the plugin: CIS RedHat OpenShift Container Platform 4 v1.2.0 Level 1 CIS RedHat OpenShift Container Platform 4 v1.2.0 Level 2 Example audit structure <check_type: "OpenShift"> <custom_item> type : REST_API description : "Minimize the admission of containers with allowPrivilegeEscalation" request : "getSecurityContextConstraints" json_transform : ".items[] | .spec.clusterID as $clusterID | .items[] | \"Cluster ID: \($clusterID), Name: \(.metadata.name), UID: \(.metadata.uid), Allow Privilege Escalation: \(.allowPrivilegeEscalation)\"" expect : "Allow Privilege Escalation: false" </custom_item> </check_type> The 'request' tag references specific API endpoints for data retrieval. The 'json_transform' tag selects specific parts of returned data. Regex and expect tags will further filter and evaluate the data for a passing or failing result. Target Release Date January 27, 2023Oracle JavaVM (OJVM) Detection Update Summary Authenticated...
Oracle JavaVM (OJVM) Detection Update Summary Authenticated scans launched against Oracle database hosts will no longer report Oracle JavaVM (OJVM) patches as missing if the OJVM component is not installed. Change A series of plugins are used to detect Oracle Database patch levels. With local checks enabled plugin 71644 gathers the patch information of the Oracle Databases detected. With remote checks enabled (i.e. authenticating into the Database without authenticating in the OS) it is plugin 45624 that will gather the patch information from the Database. While plugin 71644 alone cannot detect the presence of OJVM, users can leverage plugin 45624 to detect the installation status of that component.This limitation of 71644 results in Oracle CPU plugins reporting missing OJVM patches, despite OJVM not being installed. Although reporting these missing patches follows Oracle’s best-practice guidelines, numerous customers have requested the ability to silence these reports when enabling Oracle Database remote checks in the same scan. Following this update, scans will no longer report OJVM patches as missing if the component is not found as installed by plugin 45624. To achieve this result, scans need to be provided with both OS credentials and Oracle Database credentials, and successful authentication must occur with both sets of credentials. Impact In remote scans, Oracle JavaVM vulnerabilities will only be reported if Oracle JavaVM is installed when scanned with both OS and Oracle Database credentials. This change has no impact on Nessus Agent scans, as remote database connections are no possible. Impacted Plugins 45624 (Oracle RDBMS Host Name and Patch Info) All Oracle CPU plugins pertaining to Oracle Databases. Target Release Date Tuesday, September 19, 2023Windows Unmanaged Software Detection Include and Exclude...
Windows Unmanaged Software Detection Include and Exclude Filepaths Summary: Tenable has refined its Windows search functions many times over the years, to improve accuracy and also limit the amount of stress filesystem searches place on customer machines. The current iteration relies on Powershell searches, but cannot currently be fine tuned to specify to look only in specific directories, or exclude looking into specific directories. This is changing. Under the "Advanced" settings of Tenable scan policies, settings for "Windows file search Options" will soon exist. These two settings, for "Windows Include Filepath" and "Windows Exclude Filepath" will accept text lists of locations to check for software installs, and text lists of locations to exclude from these checks. In support of these new settings, we have refactored the commands that Tenable products issue to Windows machines to allow for the use of include and exclude paths We have also fine tuned the default exclusion paths, which should make Windows search functions run much faster. Please note: the products detected using Windows unmanaged software are provided as Dependents to plugin 152357 at https://www.tenable.com/plugins/nessus/152357/dependents. ** thorough checks need to be enabled Impact: These settings can be used to tweak the performance of Windows software detection across filesystem searches. By default, this change should make these searches for this plugin run much faster than before, depending on the size of the filesystems being scanned. Use of the include and exclude filepath settings in scan policies will allow customers and Technical Support to fine tune the paths being searched, and can be used to change the accuracy and speed of the search functions. Please reach out to Technical Support if there are any questions. Plugins: Detect Unmanaged Software Install Location (Windows) (152357) Scan Search settings (New) Target Release Date: February 06, 2023Support for Custom CA in SSL Libraries for upload to Tenable.
Support for Custom CA in SSL Libraries for upload to Tenable.io Summary Customer self-signed certificates can now be applied at the scan policy level in Tenable.io through the Advanced Scan Template. This support for assigning custom certificates to scan policies in T.io will allow customers to use self-signed certificates for SSL authentication without triggering plugin 51192 as a vulnerability in their environments. There is no change to the existing self-signed certificates functionality in Security Center, Nessus Manager or Nessus scanners by adding the certificates to the trusted list at the scanner level. This new functionality supports securely applying the certificate to an individual user’s scan policy, as opposed to the entire scanner. Individual customer certificates are encrypted in transit and live in memory while the scan runs, then purged when the task is complete for security. T.io users can configure custom certificates for a scan policy in the Settings >> Advanced >> General Settings >> Trusted CAs field by copying the custom CA text into the configuration setting. Please note, multiple certificates can be listed in this Trusted CAs field. Also, once the trusted CA gui element template update has been applied, it is available for the Scanner if accessed via API. Impact This will affect any customer who uses internally-signed certificates for SSL/TLS enabled services applied to scan target hosts inside their internal network and allow them to avoid triggering plugin 51192 on their T.io scans when using self-signed certificates on a scan policy. Changes T.io customers will have an additional Trusted CAs configuration setting to implement this feature. No changes to Security Center, Nessus Manager or Nessus scanners. Target Release Date Immediate
RHEL Detection Changes Enhanced Detection in Plugins...
RHEL Detection Changes Enhanced Detection in Plugins Targeting RHEL Systems Plugin Applicable “Red Hat Local Security Checks” family plugins. Target Release Date 23 Jan 2023 Change Today, our RHEL vulnerability detection plugins test for the presence of officially-supported repository labels to determine whether relevant repositories are installed on a system. While this approach follows Red Hat's guidance, it is not possible to rely on it in some cases, such as where Red Hat Update Infrastructure (“RHUI”) repositories are enabled. In collaboration with Red Hat, we have developed a new approach to capture the RHUI scenario accurately. Instead of just using repository labels in the /etc/yum.repos.d/redhat.repo file, we will now determine which repositories are in use by checking the repository URLs in any repo file within the /etc/yum.repos directory. Impact Checking enabled repositories is the most accurate way to determine which plugins should run against specific configurations. Before this change, this was only possible if the /etc/yum.repos/redhat.repo file contained default repository labels. Because of environmental configurations, many scans were not able to determine which repositories were enabled. Instead, they relied on basic rpm file version checking, which can produce inaccurate results due to Red Hat's rpm version numbering practices. Customers will now see more accurate findings in configurations where custom label names are used and/or when a different file(s) in /etc/yum.repos.d/ is used to store repositories. If an internal mirror uses the same URL structure as official Red Hat mirrors, more accurate findings may occur. Otherwise, there will be no change in behavior in configurations where repositories point to internal mirrors.
Host Credential Validation Scan Template Summary In an...
Host Credential Validation Scan Template Summary In an effort to simplify the process of diagnosing issues with scan credentials, Tenable Research is releasing a lightweight scan template which enables several informational plugins that report on the success of provided host (Windows / Unix) credential pairs. Change The complete list of plugins enabled by the scan template is available here. Impact Customers running Nessus & Tenable Vulnerability Management will be able to diagnose credential pair issues quickly by leveraging this new scan template. Target Release Date Nessus & Tenable Vulnerability Management: Immediate Tenable Security Center: TBD
