Firewall detects traffic to recognition.lansweeper.com/3/devrecog as critical Log4j vulnerability

[daveb]

Hello,

Is the endpoint at recognition.lansweeper.com/3/devrecog using log4j?

Palo alto is classifying this traffic from our on-prem LS instance to the above endpoint as a critical vulnerability (2 threat IDs), and will be blocked once we turn up our vulnerability protection profile settings.  Any idea why Palo is seeing this outbound traffic as a threat?

thanks

[Obi_1_Cinobi · Accepted solution]

Hello there!

The Lansweeper services running locally on your Lansweeper server will not send out any Log4j-related traffic. We have thoroughly investigated our internal and customer-facing systems, the software we deliver, and its components and interactions. None are directly affected by the log4j vulnerability. Some of our cloud systems have been indirectly affected due to running on AWS, which AWS has since patched.

The URL in particular, https://recognition.lansweeper.com, is used by your scanning service in the context of credential-free device recognition (CDR): 

• https://www.lansweeper.com/knowledgebase/credential-free-device-recognition/

This endpoint does not use a log4j v2 library, LDAP auth, or the JNDI API. However, it has a component utilizing a log4j library of an unaffected version without calling any of the affected protocols, functions, or methods.  If you see a detection related to this URL, it can be deemed a false positive. 

It is essential to remember that if you're running external vulnerability scanners, these may currently be sending out test connections or even injecting strings into your ongoing connections to probe and check for the Log4Shell vulnerability. For example, we've had some reports from customers where their vulnerability scanner injected strings into their connections to external Lansweeper endpoints, causing their firewall to flag the connections as vulnerable and preventing them. In other words, vulnerability scans and probes from system A might cause security system B to detect them as a vulnerability.

Lastly, since your internal security equipment is blocking your scan server access to recognition.lansweeper.com, you might receive a notification in Lansweeper that CDR is not working/has no access to the internet.  To resume the functionality of CDR, you will need to allow traffic to the following endpoints:

• The recognition endpoint: https://recognition.lansweeper.com/3/devrecog
• The license authentication endpoint: https://authentication.lansweeper.com

[daveb]

I appreciate the info.  We arent scanning endpoints.  This is being detected in the outbound traffic flow from an on-prem instance of lansweeper to that internet based recognition endpoint.   we arent blocking the traffic yet, but it came up when auditing what traffic would be affected once we do turn up the vulnerability protection profile on our firewall.

it may be helpful to reach out to Palo Alto to figure out why their firewalls see this traffic as a critical severity vulnerability detection.  could possibly get an 'app-id' assigned to lansweeper traffic too.  🙂

thanks again!

[brianinca]

This was categorized by Fortinet's Web Filter as "adult materials" and the blocks showed up on our SIEM's console, didn't even know it was a thing. This was as of 5/7/24. Had to exempt in a custom category. Hah!