Cum verific dacă Log4j este instalat pe serverul meu?

Am citit despre vulnerabilitățile de securitate legate de Log4j.

Cum verific dacă Log4j este instalat pe serverul meu? Serverele mele specifice folosesc Ubuntu 18.04.6 LTS.

Am instalat multe pachete de la terți și poate că unele dintre ele le conțin.

Există o comandă de rulat pe serverul meu pentru a verifica dacă Log4j este instalat?

Nu există nicio comandă care să-ți spună cu siguranță asta. Unele aplicații livrează bibliotecile pe care le folosesc direct ca fișier jar, altele le vor conține într-o arhivă.

Și chiar și atunci nu știți ce versiune este livrată și cum este folosită. Singura modalitate de a fi sigur că atenuați CVE este să citiți anunțurile de securitate și notele de lansare ale aplicațiilor dvs. și să urmați recomandările acestora.

Încercați aceste comenzi:

• dpkg -l | grep liblog4j

• dpkg -l | grep log4

• găsi / -name log4j-core-*.jar

• localiza log4j | grep -v log4js

Am scris acest script Python pentru a găsi versiuni vulnerabile Log4j2 pe sistemul dvs.: https://github.com/fox-it/log4j-finder

Funcționează prin scanarea discului și în interiorul fișierelor Java Archive în mod recursiv și căutând fișiere defecte cunoscute.

log4jscanner

Publicat de Google sub licența Apache-2.0, log4jscanner este un scanner de sistem de fișiere cu vulnerabilități log4j și un pachet Go pentru analiza fișierelor JAR.

Cerându-mi scuze pentru referirea la material din exterior, sper că acest lucru va fi tolerabil în circumstanțele actuale.

Informațiile pe care Lunasec.io le-a publicat despre hash-uri ale fișierelor vulnerabile Java binare .class:

https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/constants/vulnerablehashes.go

Vezi si blogul lor: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

Ar trebui să ai ordonat hashe-uri (unul pe linie) ale claselor suspecte dintr-un fișier hashuri și au un fișier jar subiect.jar și au dezarhivați, găsi și sha256sum comenzi, apoi puteți face o comparație cu hashurile cunoscute cu:

JARFILE=subject.jar; DIROUT=$(mktemp -d); dezarhivați -qq -DD "$JARFILE" '*.class' -d "$DIROUT" && găsiți "$DIROUT" -type f -not -name "*"$'\n'"*" -name '*.class ' -exec sha256sum "{}" \; | tăiați -d" " -f1 | sortare | uniq > „$JARFILE”-hash-uri; rm -rf -- "$DIROUT"

comm -12 hashuri subiect.jar-hashes

Dacă com are ieșire, atunci există un hash potrivit.

Încerca syft. Acesta creează o listă de materiale software (SBOM), pe care apoi o puteți căuta versiuni vechi log4j (chiar funcționează cu imagini docker).

Ceva asemănător cu syft dir:/opt/foo-application | grep log4j căutări în implementări convenționale. syft dir:/ | grep log4j ar trebui să funcționeze pentru întregul tău server.

Transmiterea imaginilor docker funcționează și:

# syft -q jacobalberty/unifi:5.13.29 | grep log4j
log4j-api 2.12.1 java-archive
log4j-core 2.12.1 java-archive
log4j-slf4j-impl 2.12.1 java-archive
tomcat-embed-logging-log4j 8.5.2 java-archive

Crearea unui script pentru a transmite toate imaginile docker către syft nu ar trebui să fie prea grea, dar s-ar putea să găsiți ceva inspirație în acele scripturi ale mele: https://github.com/debuglevel/syft-grype-utils

John Hammond a publicat împreună cu alții un serviciu de redirecționare LDAP găzduit, astfel încât să puteți sări peste toate prostiile. https://log4shell.huntress.com/

Direcțiile sunt simple - generează un ID de client pentru dvs. (este în URL, precum și o parte din șirul de injectare) pe care îl puteți posta în orice formular/cerere/sau derivat al cererii web.

În general, dacă rulați ceva care „nu funcționează cu asta pentru că este acces local”, atunci ești bine oricum, deoarece nu există mijloace de redirecționare prin aplicația ta bazată pe Java.

De notat - cred că cea mai mare preocupare ar trebui pusă la hardware-ul de management al rețelei L2/L3; Mai ales dacă aveți de-a face cu un ISP sau conținutul dvs. este servit printr-un serviciu de găzduire.

Toate încercările aici de a aborda vulnerabilitățile din log4j sunt insuficiente. Nu te poți baza pe localiza comandă, deoarece arată doar într-un set de căi configurate (/etc/updatedb.conf pe Debian).

Software-ul se poate instala singur în locații care nu sunt configurate în updatedb.conf și să fie complet ratat de jobul cron care actualizează baza de date de localizare.

De asemenea, se descoperă că furnizorii de software (cum ar fi Elastic) au reambalat vulnerabilul JndiLookup.class (de exemplu: elasticsearch-sql-cli-7.16.1.jar) în locuri care nu erau cunoscute anterior, ceea ce lasă soluțiile incomplete care sunt construite în jurul hashurilor, numelor sau căilor de fișiere cunoscute.

@shodanshok este pe calea cea bună aici, dar mai degrabă decât să caute log4j în mod explicit, o privire în fiecare „.jar” de pe sistem este ceea ce este necesar.

Acesta este mai complet, necesită pachetul zip. și o extensie a răspunsului lui shodanshok. Aceasta va afișa doar locațiile în care JndiLookup.class codul este găsit. Ar putea fi adăugată o altă linie pentru a elimina aceste vulnerabilități, dar mai degrabă aș lăsa asta la discreția administratorului. Linkul elastic de mai sus arată cum:

pentru jar în $(găsește / -name '*.jar'); do
   dezarhivați -l „$jar” | grep 'JndiLookup.class' &>/dev/null && echo „Vulnerabilitate găsită în $jar”
Terminat

Exemplu:

# pentru jar în $(găsește / -nume '*.jar'); do
> dezarhivați -l „$jar” | grep 'JndiLookup.class' &>/dev/null && echo „Vulnerabilitate găsită în $jar”
> gata
S-a găsit o vulnerabilitate în /usr/lib/unifi/lib/log4j-core-2.13.3.jar
S-a găsit o vulnerabilitate în /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.2-SNAPSHOT/minecraft-server-1.15.2-SNAPSHOT.jar
S-a găsit o vulnerabilitate în /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.1-SNAPSHOT/minecraft-server-1.15.1-SNAPSHOT.jar
...

Aveți grijă când rulați acest lucru pe un sistem cu sisteme de fișiere de rețea montate, deoarece performanța poate fi afectată. În aceste cazuri, trebuie să rulați comenzile pe serverul de fișiere însuși.

Verificarea pachetelor instalate nu este suficientă log4j poate fi instalat manual de către alte aplicații.

Pentru serverele Linux folosesc următoarele: găsi / -iname „*log4j*.jar”

Pentru serverele Windows se poate folosi ceva similar cu asta: dir C:\*log4j*.jar /s (schimbându-se C: la D: și așa mai departe pentru alte discuri).

Numele de fișiere vor afișa în general versiunea bibliotecii, dar pentru a verifica de două ori puteți deschide fișierul manifest și puteți citi câmpurile versiune/implementare.

Vă rugăm să rețineți că cele de mai sus sunt nu e suficient a prinde încorporat log4j (ex: în alte fișiere jar). Pentru acestea, trebuie să grepți șirul relevant, dar acest lucru necesită destul de mult timp și resurse, așa că vă sugerez să mergeți cu căutarea fișierelor ca prim pas (dar incomplet).

lsof verifică fișierele deschise, postate de Florian Roth pe twitter:

ps aux | egrep „[l]og4j”
lsof | grep log4j

alte două comenzi, de asemenea, dar acestea sunt comenzile rezidente, de căutare în memorie