Why we won’t scan /0 for log4shell issue

Written on 2021/12/14

Apache log4j logging system is affected by a critical issue impacting billions of devices or software stacks. That issue is described as CVE-2021-44228. After careful considerations, ONYPHE has decided not to scan the full IPv4 address space for this vulnerability. Here is our communication to explain our position.

UPDATE: 2021-12-15: added more dorks to detect other impacted products, scroll to the end of this blog post for the list.

There are some technical issues surrounding scanning for this vulnerability at scale. The first one is the number of requests required to check all potentially affected assets. According to our data, there are currently more than 183M+ services responding to HTTP requests, and that’s only for direct IP scanning (without using a virtual host HTTP header). By counting the number of unique domains known to our solution, we could add 160M+ domain names. To check to the maximum extent possible, we would have to send 2 requests for domain names: one with HTTP (port 80/tcp) and another one with HTTPS (port 443/tcp). In the end, this is 500M+ requests to send. By considering there are currently roughly 400M+ domain names registered, we should end up sending 1B+ requests. That’s not sustainable in a reasonable amount of time, and that is only by considering the HTTP protocol (other protocols are impacted as well).

Added to that, different applications will have a different path to exploitation, as we have to send the check to the correct target field (for instance, a login field, as the field has to be logged by the library to be exploitable). This 1B+ requests could end up being in the multi billion level. By not correctly checking for that issue, we could simply fail to effectively check for the existence or absence of this issue and finally give a false sense of patching, being totally counter productive. The gain for our customers is questionable.

Another aspect is the load implied with such scanning for cyber defense. Today, most companies have deployed methods to detect exploitation attempts. Sending billions of requests would generated a huge amount of alerts, putting unneeded pressure on cyber defense teams, and they don’t need that extra hassle now. We want to contribute in a positive way to the infosec ecosystem, not in a negative one.

Large scale vulnerability scanning considerations

We have always put forward our ethical way of doing active Internet scanning by using fixed IP addresses for all our scanners, publishing this list, setting a reverse DNS pointing to probe.onyphe.net domain name and answering all abuse requests by blocklisting networks when requested by legitimate owners. We want to be identified so as to let network owners know our intent, and give them tools to opt-out in the simplest way for them. Furthermore, by sending billions of requests, we will receive a huge amount of abuse requests, we will put pressure on cyber defense teams, and we will eventually have our scanners blocked by many entities, including our customers. That’s not a good thing to do neither for us, nor for our customers.

We have our ethical checklist considerations to decide when to include a test in our vulnscan category of information. We have created a simple checklist to help us decide, in a repeatable way, when to include (or not include) a check for a specific vulnerability. Our checklist is currently as follows:

Targeted checking: potentially vulnerable assets are tested, we don’t want to engage in the blind checking approach;
Innocuous tests: we don’t want to take the risk to crash or impact targets;
Least intrusive possible: usually checking by just connecting to a specific URL and analyzing HTTP response body;
Critical vulnerabilities: those exploited by cyber criminals to make profits.

The log4shell issue doesn’t meet point 1. However, specific product testing methods may pass our checklist and we could, in the future, write specific tests.

What we could do regarding that issue

With time, a more targeted list of products will emerge, with specific exploitation details. For instance, we know VMware vCenter (and some other VMware products) are impacted by this issue. That is more sustainable to only check these identified products as it then results in targeted checking, increasing the balance benefit/risk for our customers and the infosec ecosystem at large. As a security researcher pointed out:

“Let’s wait patiently for real unauthenticated RCEs targeting specific products.” — Felix Aimé.

https://twitter.com/felixaime/status/1470137122178879499

The best resource currently available to identify impacted products is the list from SwitHak researcher available at the following link:

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Another great resource is the one from NCSC NL:

https://github.com/NCSC-NL/log4shell/tree/main/software

We will update this blog post with ONYPHE dorks to allow our customers to identify their potentially impacted products. Once they have this list for their perimeter, they will be able to check the issue by themselves. That’s what we consider, today, the best way forward with this critical vulnerability that needs remediation as soon as possible.

Don’t hesitate to contact us at support[at]onyphe dot com should you have any question or suggestion regarding this matter.