Log4j Vulnerability Update
The Log4j vulnerability is now 6 months old. Patches are now available for Java 7, Java 8 as well as Log4j component.
`The impact and mitigation strategies for the Log4j vulnerability have been discussed in our earlier blog post -Log4j vulnerability and its impact
If your IT / product team has fixed the vulnerability by patching Log4j component, or Apache or with a Java update on *all* instances of your application servers (test, staging, production, worker nodes behind an app or http load balancer, issued patch for your customer deployed products, all your 3rd party application servers, and many more), congratulations - the risk of Log4j exploitation on your application is much reduced.
However, many teams have only partially mitigated their products / IT infrastructure, by making code changes to handle references to Log4j; your systems may have log4j surprises hiding in plain sight.
Observation
If your product team has attempted to fix Log4j by disallowing JNDI lookup from your web / mobile APIs, it is likely that some of the APIs may have been missed in code update. The fix is likely to have been delegated to engineers not fully familiar with the product source code. As well, your QA test plan likely does not provide 100% coverage of the product functionality / APIs.
We recommend that Log4j discovery should be done all over again, and ensure all APIs are checked against Log4j.
Still in doubt? Mail us at contact@cybersecurist.com. We live by the belief that 100% coverage only will ensure no cracks.