We depend heavily on Agents, since we employ CyberArk for privileged accounts and InsightVM and CyberArk don’t work as well as you would hope on Linux assets. In this Log4J situation, because the checks have to be performed through Manual Scans (i.e., there is no check yet for Agents), we are not able to effectively interrogate our Linux assets as Root.
That said, I find it incredibly negligent that no Agent check exists 5 days following the global explosion of this vulnerability. Where is Rapid7 Engineering and why can’t they seem to respond to their Customer’s needs? This is definitely going to impact my long-term relationship with Rapid7…
Yes, a single system and only detected by the unauthenticated remote check. I’m not convinced it’s not a false-positive at this point due to all the issues we’ve been having with this check but I am re-running scans on all Windows systems, which will take a while. It’s still not detecting systems as vulnerable that our vendors have confirmed are though.
Pardon my ignorance, but just wanting to be sure I’m correct in my thinking here. A Full Audit credential scan includes these vuln checks, correct?
I wasn’t 100% sure, so I created two passes (scans) - one being a Full Audit, and a custom template scan with both Log4j vuln checks. I’m sure the custom template was not needed, after the fact but just wanted to verify. I ran the custom Log4j vuln checks against a few Windows machines and it returned no vulns. Not sure how much I trust that though.
Hey folks, after talking to the team I wanted to give some clarification + an update with regards to the remote check for Windows. Appreciate everyone raising their concerns and being patient while we work through this.
We mentioned the bi-directional communication that’s required between the scan target and scan engine during this check. What we’re seeing most commonly is that traffic inbound specifically to port TCP/13456 using the LDAP protocol on the scan engine is not allowed. If this isn’t allowed in your network policy, the connection between the scan target and scan engine does not take place, resulting in a “not vulnerable” result. This is expected (and happens with some other remote checks, as well).
I know some folks mentioned that their network policy should already allow this, and that it can be difficult to tell if the check ran in the first place since there may not be logs indicating as such. We’re looking into what we can do to add more visibility so you can confirm whether the check ran (and returned a “not vulnerable” because it wasn’t able to actually be exploited) versus whether the check failed (because of a communication failure, or because of some other remote check issue). This should make it easier to determine the status of the remote check.
I definitely hear the frustration regarding the severity of this and wanting to get it detected + resolved as soon as possible. I know there was a request for releasing an update to the Windows agent as “unsafe”, and we’ve shared this with the team. They’re considering this along with other options that balance performance and reliability. And please know that our engineers and other researchers are continuing to delve into this as much as they can to provide the best updates and solutions.
Thanks for all the feedback so far, and for helping us along the way as we continue to work through this. Since this is still very much an active development effort, I can share more info as we have it.
a major +1 from me on this “unsafe checks” approach. I want to stress that my organization is running all sorts of crazy high-load, mass filesystem searches and queries to find this anyways, so we don’t mind if its the agent or the scan causing it. We are going to put some stress on systems looking for this so it might as well be R7 so we have the vuln data in our vuln tool and not in a couple hundred text files and csvs from disparate tools. We would opt in to this unsafe check in a heartbeat. Just my take, hope it helps.
How are you determining that the problem is commonly related to traffic over 13456 being blocked? There’s currently nothing in the logs that give any useful information for determining this so how is Rapid7 coming to this conclusion? I know it’s been pushed several times as the cause for the past couple days.
Correct, a full audit scan would include the checks for CVE-2021-44228 by default. You only need to add them manually if you’d like to do a targeted scan with just these checks for performance purposes.
That’s good to know. Thanks for adding some context there, it really helps. I’ll relay this so we can keep it in mind as we’re considering the best next steps.
You’re right, that’s a valid question. This is based on guidance from internal teams that have encountered similar issues or done troubleshooting for this remote check, as well as folks who are helping from the support side of things (say, working 1:1 with a user, or on a phone call with them, etc).
The lack of logs do make it more difficult, so it’s something we’re looking into. And we definitely intend to provide more guidance regarding usage of the remote check (beyond the 13456 port issue) as we have it.
@holly_wilsey - In our environment we have confirmed traffic is allowed from the Windows servers (with Log4j apps) to our security console over TCP/13456. My question is — How does the Windows server know to make contact with the scan engine? Is there a specific port Nexpose uses, and attempts to open a connection back to the scan engine over TCP/13456. Trying to communicate this to our engineers.
i think you need to make the port open on your scan engines, not the console. that way the scanned hosts can talk back to the scanners on that port 13456. see my post above if you scanners are linux.
There’s a bit more of an in-depth explanation on how the check works on the blog post under the “Remote scanning” section, but essentially what it does is:
Check to see if TCP ports 80, 443, 8080, or 8888 are open (or if NMAP service fingerprinting detects HTTP/HTTPS)
If so, the scan engine will attempt an exploit and have the scan target open a connection to the engine on 13456
So as @mfarrington said, you’ll want to allow traffic to the scan engine on TCP/13456 to enable that sequence to succeed and the check to fire.
Has anyone tested the remote check on their external ranges using the R7 hosted scan engine? I’m looking to put a change in place to allow DMZ servers outbound access on TCP/13456 to the R7 scan engine but was hoping someone could give the green light that they have had success with it?
Anyone had any luck after updating to 6.6.120? I just updated our console and all the scanners as well as made the recommended fire wall changes. waiting on scans to complete now.