No change after 6.6.120. Scanned all Windows assets and 0 were flagged by the remote check. I had one getting flagged this morning but it must have been a false-positive since all scans have since been clear.
Iāve even got linux scanners that have the firewall turned off, no networking to block the connection that I know of, and the remote check still fails. Now maybe thatās because the apps using apache have things blocked enough to not allow the exploit, or maybe itās because the check isnāt working properly. Right now I have zero confidence.
1 Like
Iām still so disappointed that a remote check only is considered acceptable to Rapid7. The only certain way of knowing if you are potentially vulnerable or not is knowing if the binary exists.
Same here. 
Even then, many patches or fixes are just mitigating by changing settings. So the version check as well as the remote check functioning are both required. Based on this post over the last several days Iām pretty sure the remote check only works in very specific cases. My assumption is that a lot of customers are just trusting that the check works, seeing zero instances, and calling it good. Which frankly is a concerning thought.
2 Likes
100% agree. And in my opinion, remote checks should be done by scanners that specialize in web applications. I suspect that the current remote check for InsightVM attempts via common methods, such as exploits in the User-Agent and other headers, or directly in the URL itself. There are a lot of different attack vectors when it comes to web application scanning, each unique to the specific web application. Unless this is crawling the web application and finding all injection points and attempting the exploits at all injection points, this test cannot guarantee your application is not vulnerable. And my web application logs tell me that this isnāt happening.
This remote check is giving a lot of people a false sense of security.
I agree with that. Iām almost thinking this check needs to be removed from the system and R7 needs to just say this is something that InsightVM canāt check for. I hope the AppSec product is able to test for this. Iād rather they say they canāt do it comprehensively with InsightVM so I can relay that to my company rather than just having to āknowā that weāre blind to this problem.
Currently weāre almost 100% remediated for this vulnerability and as far as external exposure our firewall is blocking any attempts, and has from the start. All good things. My concern is if somehow some system re-introduces this problem in a year and Iām completely in the dark because the remote check doesnāt work.
4 Likes
Iāll speak out in opposition: I ask that requests not be made to remove capabilities from those of us that want this available to augment our other work just because it doesnāt fit your use cases. If this wasnāt present I would just have to go implement the same thing myself. I would rather understand the limitations of the check than push to have it removed. Rabble rabble, shakes fist at cloud.
Hello. Is it necessary to have this port, 13456, open even when doing internal scanning? Thank you.
Point well taken. From my perspective, my vulnerability scanner is unable to scan for this vulnerability. Iād rather it either work the way it should, or get removed. As it is my environment has never had this vulnerability according to InsightVM. Except I know for a fact weāve remediated it on tons of systems. That said I also understand where youāre coming from.
Any updates from Rapid7 today regarding the ongoing issues with this detection? Iām being asked for some sort of status update as to why we are not able to get good vulnerability results for this particular item as Iām sure a lot of you are.
Iāve been having those conversations as well. Very frustrating.
Ironically, listening to the Rapid7 call " Apache Log4j Vulnerability: What You Need to Know and Mitigation Guidance" and they are actively going over how web applications are far from the only attack vector for this vulnerability. Again, this emphasizes the importance of knowing every system that has a vulnerable binary on it. Remote checking only services fingerprinted as HTTP/S is not fully detecting this vulnerability, per the experts on the call right now.
A direct quote from the presentation: āYou need to physically go hunt for these .jar files and class files in your environment.ā
āWindows, Linux, Mac, it doesnāt matter. Thereās not a single platform that is safe from this.ā So why does only Unix-like systems have direct .JAR checks?
And now, the security expert is saying how performing these remote checks are often dangerous even in āsafeā methods because older applications may react different, which can cause them to break or go down at any time.
2 Likes
InsightVM doesnāt do product checks for products known vulnerable to CVE-2021-44228 according to support. For example, assets that have VMware products installed and are listed in their security advisory are showing no vulnerabilities in InsightVM.
So far InsightVM has proven unuseful for determining exposure to CVE-2021-44228. I shouldnāt need to use a second tool to match vulnerable products on assets.
2 Likes
Iām also listening to that call, and honestly pretty frustrated. The speakers clearly understand the urgency and how tough it is to find this stuff and arenāt giving us the tools to do it.
Also a big deal. Our folks have squared away VMWare very quickly but again, I have zero visibility.
Weāve been keeping in touch with the team, and today weāre continuing to do research and development regarding these checks. I definitely hear the frustrations shared here regarding the remote check, and understand wanting an authād check for Windows. Weāve shared this and the team is considering it alongside other factors.
Since this is such an evolving effort, I donāt have specifics to share at this moment regarding additional updates to these checks, but your feedback is completely valid and I appreciate folks following along here. Right now our engineers are tackling some big challenges regarding these checks, so again no specifics at the moment, but Iāll keep posting info here as we have it.
Thatās right, youāll still want to allow inbound traffic to port 13456, in this case.
Weāre currently monitoring these other vendors as they release security advisories, and we do plan to add checks for products that are on our recurring coverage list. Many of them currently donāt have remediations available, but this is something on our radar as they continue to make updates and provide details on affected/fixed versions.
2 Likes
Agreed. Iāve tried lots of hosts which other tools suggest are vulnerable and they consistently come back with nothing.
That content update number doesnāt seem to coincide with what Iām seeing. Mine says: Content: 601424885 (2021-12-15)
Hi R7 team. Can we only have 2.16 as the ONLY solution option? This is misleading. Just wanted to send this up the chain, if possible.
