
Scanner per file JAR che potrebbero essere vulnerabili a CVE-2021-44228
Le applicazioni vulnerabili al problema log4j CVE-2021-44228 possono essere rilevabili mediante la scansione di file jar, war ed ear per cercare la presenza di JndiLookup.class.
A seconda della piattaforma che stai analizzando, può avere senso eseguire lo script PowerShell o Python3. In entrambi i casi, l'argomento opzionale è la directory di primo livello da cui desideri iniziare la ricerca.
Qualsiasi file scoperto merita un'indagine per determinare se l'applicazione che lo utilizza è vulnerabile. Per ogni JndiLookup.class presente, log4j include comunemente la versione nel nome del file jar. Ad esempio, un riscontro su log4j-core-2.14.1.jar sarebbe indicativo di un'applicazione vulnerabile. In alternativa, log4j-core-2.16.jar potrebbe anch'esso produrre un riscontro perché il codice JndiLookup è ancora presente nella versione 2.16 di log4j, ma è disabilitato per impostazione predefinita. Vedi VU#930724 per maggiori dettagli.
Ad esempio, ecco un'invocazione della versione PowerShell dello scanner:

Analogamente, ecco un'invocazione della versione Python3:

Infine, ecco un'invocazione della versione Bash:

Nota che le versioni Bash e Python di questo script, per progettazione, limiteranno le scansioni a un singolo filesystem.
Con la versione PowerShell, è possibile inviare tramite pipe le posizioni da scansionare allo script per avere il controllo su ciò che viene controllato. Ad esempio, per scansionare un elenco di percorsi contenuti in un file paths.txt:
get-content .\paths.txt | .\checkjndi.ps1
Diamo un'occhiata al primo riscontro nella nostra esecuzione di scansione su Windows:
WARNING: C:\tmp\2.15\log4j-core-2.15.0.jar contains org/apache/logging/log4j/core/lookup/JndiLookup.class
In base al nome del jar, si tratta di una libreria di log4j 2.15. Sebbene questa versione di log4j corregga CVE-2021-44228, conteneva ancora una falla descritta come CVE-2021-45046. L'impatto di CVE-2021-45046 è un denial of service solo per alcune applicazioni Java che utilizzano log4j 2.15. Per le applicazioni Java che utilizzano versioni di log4j precedenti alla 2.15 e che soddisfano anche i prerequisiti per l'applicazione di CVE-2021-45046, l'impatto è RCE.
Diamo un'occhiata al secondo riscontro:
C:\tmp\2.16\log4j-core-2.16.0.jar contains org/apache/logging/log4j/core/lookup/JndiLookup.class ** BUT APPEARS TO BE PATCHED **
Questo file jar contiene una versione 2.16 di log4j, che non è vulnerabile a CVE-2021-44228. Questo risultato viene riportato a scopo informativo e mostra che un fornitore ha corretto il proprio prodotto.
Diamo un'occhiata al terzo riscontro:
WARNING: C:\tmp\ghidra_10.0_PUBLIC\Ghidra\Framework\Generic\lib\log4j-core-2.12.1.jar contains org/apache/logging/log4j/core/lookup/JndiLookup.class
Qui possiamo vedere che Ghidra utilizza log4j versione 2.12.1, e pertanto dovremmo assumere che sia vulnerabile. E in effetti, le versioni di Ghidra precedenti alla 10.1 sono vulnerabili a CVE-2021-44228.
Dovresti indagare su qualsiasi riscontro segnalato da uno di questi script e confermare che la versione di log4j sia effettivamente la versione corretta 2.16, oppure contattare il tuo fornitore di software per ottenere una versione corretta del software. In alternativa, VU#930724 contiene informazioni su come JndiLookup.class può essere rimosso dai file jar vulnerabili.
La versione PowerShell dello scanner ha una segnalazione aggiuntiva di errori quando non è possibile analizzare file o directory. In particolare, eventuali errori Unable to scan che riportano UnauthorizedAccessException sono indicativi di un problema di autorizzazione nell'accesso a una directory e/o un file. Eventuali errori Unable to scan che riportano InvalidDataException sono solitamente dovuti a un archivio corrotto.