Dit is helaas niet afdoende en ik raad ten zeerste af deze methode te gebruiken als je verantwoordelijk bent voor andermans data. Repository checks zijn handig voor als je nooit iets customs hebt geinstalleerd maar zo vendor check beperkt zich tot hun eigen lijst. Canonical geeft dit zelf ook aan
The widespread use of the Apache Log4j 2 package, as well as the Java platform’s packaging conventions, have made addressing that vulnerability (by the security industry as a whole) non-trivial. The reason is that this software is not only present in Ubuntu as a packaged component, but separate copies of this software are also often bundled directly in popular applications. In particular, the latter is what makes the task of determining whether a particular application or system is vulnerable quite difficult.
Teams have to examine each application individually to find whether applications are vulnerable by “unbundling” them, or by using software bills of materials and manifests. Just updating the Ubuntu packaged version of this software component is likely not sufficient to ensure that all applications which use Apache Log4j 2 are remediated.
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Hier staan regular expressions voor exploitatie detectie CVE-2021-44228.
Let op exploitatie detectie wil niet zeggen dat enige poging gelukt is maar je moet wel alle entries reviewen om zelf tot een conclusie te daarin te komen. Cross check middels netwerklogs
Verder naar onder zie je detectie methode van nog aanwezige log4j componenten middels ps aux, find, lsof, grep
Kom je enige entry tegen dan zul je moeten kijken wie de vendor is en of het een kritiek onderdeel is van je infra.
Er zijn ook tig scanners nu op de markt maar om nu betrouwbaarheid van die tools te moeten gaan testen of blind gebruiken is ook hartstikke onverstandig .Beperk je tot de lijst van bekende firma's tenzij je tijd hebt voor een volle software analyse.
https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md