Log4j CVE-2021-44228

InsightVM
42

Hello all.

We are encountering the same issue, with zero findings on our network.

Version: 6.6.119 , engine/console restarted and bi-directional communication is working properly.

43

Same as everyone else, Linux scan works fine as it is just using ā€˜findā€™ to locate the log4j jar but for Windows it is not working, systems with no Firewalls between the scanner and the host are reporting false negatives. All on the correct version of content and engine.

44

Any update on Windows Agents ability to detect Log4J

Tenable seem to be able to do itā€¦

1 Like
45

Hello,

We have also updated our console and scan engines to the latest version but we are not able to detect anything by an authenticated scan (with a privileged user) or by a remote check.

46

Has anyone confirmed if the remote check is working on Linux systems?

47

Hiā€¦ in our case we have Windows systems which cannot be scanned by remote scan engines, so we need to be able to rely on a local Windows agent to detect the issue.

48

Just adding my .02, I stacked up scans last night to hit our entire server environment (windows shop) and didnā€™t detect a whisper of this CVE on systems that I know have the vulnerability, and can communicate unhindered with my scan engines. This check is not working, even with NMAP service detection turned on which was another change I made.

Edit: and we have the agent deployed everywhere. Nothing.

49

Yup, exactly the same scenario here.

50

same here

51

Also same here.

52

Here is a great summary of all the requirements and an instruction on how to configure a specific scan template for CVE-2021-44228:

(Please be aware of the correct port. See post below)

53

Thanks everyone for the feedback regarding the remote check. With some of the reports coming in that this check isnā€™t succeeding, we put up a more comprehensive blog post that further details its inner workings. You can see it here:

Some things to note from that post:

  1. Scan targets will attempt to open a connection to the engine on port 13456. This port number was previously miscommunicated, so apologies for that.
  2. The engine does not open a TCP listener but does a packet capture to identify connection attempts against 13456/TCP.
  3. This approach relies on bi-directional networking and requires the scan engine and scan target to be able to talk to each other. If thereā€™s a VPN, NAT, or firewall, then this required networking may not be available.

Thereā€™s the potential that firewalls that arenā€™t configured to allow traffic on port 13456 are (partially) the culprit here, so that would be a good next step to confirm in your environment. And Iā€™ll continue to share any more info from the team as we investigate further.

54

Hi Thanks for the guide - but I am confused, why canā€™t we rely on the Windows Agent to detect this? Is there an ETA?

55

The last I knew, and Iā€™m hoping to be wrong at some point, is that the windows agent doesnā€™t detect it yet. But the agent detects it on *nix devices.

56

Hi Holly,

No Firewall in between my devices Iā€™m testing and no host firewall either, Windows authenticated checking simply doesnā€™t work and cannot be relied upon unfortunately. I realise finding log4j*.jar files on windows hosts is very difficult as you have to trawl the entire filesystem and it could be anywhere. I note you are only looking for log4j-core..jar, you might want to look for log4j.jar to get full coverage here as older jars are named differently and some core files are named log4j-core.jar, your check will miss these and they may also have the jndilookup.class compiled in them depending on how the vendor implemented log4j.

Edit for some reason the asterisk are not showing correctly in the filenames Iā€™m trying to give examples on.

57

Hi Holly - Iā€™ve confirmed with my networking team that thereā€™s nothing stopping our windows servers (known to have this vulnerability) from communicating with my scan engines. Iā€™d also like to make it clear that the agent detecting this on windows servers would solve this issue almost 100% for us. Perhaps making that happen or detecting this vulnerability in a different way vs. trying to run the exploit would be a better approach. Especially because your firewall or network segmentation blocking the vulnerability is a mitigation, not a remediation of the vulnerability. In my opinion, authenticated scanning on the inside of your network is intended to show you the vulnerabilities you have even if you have them blocked by networking controls.

Otherwise weā€™d all be performing un-authenticated external scans and calling it good when they come back empty-handed.

2 Likes
58

Confirmed there is nothing in between our scan engines and Windows Servers that would block this activity

59

Hello Holly,

As reported by other people, weā€™re having the same issue. I just followed the video shared in previous comment, and no finding yet, but I know that some machines are vulnerable.

Linux/windows authenticated scan not working properly .

Version : 6.6.119 , restarted engine/console, no firewall blocking any ports

60

Are we sure the port is correct? Iā€™m reviewing the scan data log and port 13456 is not there. 12345 is though

61

One Rapid7 rep told me 12345 and the blog post says 13456. I was also told to not expect an authenticated check ā€œanytime soon.ā€