dariusiakabos/log4jRaccolta OSINT curata su Log4Shell (CVE-2021-44228) che copre metodi di rilevamento, superficie di attacco, passaggi di mitigazione e indicatori di compromissione per la risposta agli incidenti.
Compilazione dei risultati OSINT su log4j, inclusi Rilevamento, Superficie di Attacco, Mitigazione, IoC.
Questa vulnerabilità consente a qualsiasi attaccante che possa iniettare testo nei messaggi di log o nei parametri dei messaggi di log nei log del server di caricare codice da un server remoto. Il server preso di mira esegue quindi quel codice tramite chiamate alla Java Naming and Directory Interface (JNDI).
JNDI si interfaccia con una serie di servizi di rete:
Al 13.12.2021, gli attacchi finora osservati erano principalmente cryptominer e botnet automatizzate (Mirai, Tsunami e Kinsing)
La soluzione migliore è aggiornare alla versione patchata, ma la sfida è individuare dove log4j è stato distribuito come componente e/o attendere che il vendor applichi la patch.
A breve termine:
A lungo termine:
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ - di @TychoTithonus (Royce Williams).
Una compilazione di esempi di exploit. https://github.com/YfryTchsGD/Log4jAttackSurface
Risorse di Florian Roth (anche la sezione commenti contiene informazioni utili) https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
/.({|%7B)[Jj][Nn][Dd][Ii]./
https://twitter.com/ThinkstCanary/status/1469439743905697797 Puoi utilizzare un canarytoken point & click da https://canarytokens.org per aiutare a testare il problema #log4j / #Log4Shell.
Dettagli sulla loro pagina https://log4shell.huntress.com/
"Come rilevare se si è affetti: avvia netcat in parallelo alla tua app: "nc -lp 1234", poi digita quanto segue nell'app dove viene registrato nei log (ad es. la stringa di query della tua ricerca): "${jndi:ldap://127.0.0.1:1234/abc}" Se poi vedi spazzatura/emoji nella console di netcat sei vulnerabile!"
"Ho scritto un semplice programma Java (cioè standalone, senza dipendenze) che applica una patch a JndiLookup.lookup() per restituire una stringa fissa e non analizzare i suoi argomenti. Questo dovrebbe risolvere CVE-2021-44228 (cioè RCE in Log4j) senza riavviare il processo JVM." https://github.com/simonis/Log4jPatch "Questa è una POC di un semplice strumento che inietta un agente Java in un processo JVM in esecuzione. L'agente applicherà una patch al metodo lookup() di tutte le istanze caricate di org.apache.logging.log4j.core.lookup.JndiLookup per restituire incondizionatamente la stringa "Patched JndiLookup::lookup()". Questo dovrebbe risolvere la vulnerabilità di esecuzione remota del codice CVE-2021-44228 in Log4j senza riavviare il processo Java. Attualmente è stato testato solo con JDK 8 e 11!"
Fonte: Greynose.io
API Community https://docs.greynoise.io/reference/get_v3-community-ip
Chiamata API: curl -X POST https://threatfox-api.abuse[.]ch/api/v1/ -d '{ "query": "taginfo", "tag": "log4j" }
"Si prega di trovare di seguito i payload grezzi CVE-2021-44228 Log4J / Logshell che GreyNoise ha rilevato finora." https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890
"Osservato 45[.]155[.]205[.]233 eseguire la scansione iniziale con una stringa codificata in base64. Una volta decodificata, tenta di eseguire curl wget bash ecc....per impostare una shell. Visti anche gli stadi 2, 3 e 4 con i payload finali: malware nspps/Kingsing tramite i seguenti IP 44.240.146.137 45.137.155.55 185.154.53.140 185.191.32.198"
45.155.205.233 - IP russo osservato mentre sfruttava la vulnerabilità. https://twitter.com/VessOnSecurity/status/1469950517010968582 https://twitter.com/entropyqueen_/status/1469961345848299520
