Am log4j pe Ubuntu 18.04.6?

Evident că sunt îngrijorat de această vulnerabilitate, dar mă întreb dacă am această bibliotecă pe mașina mea?

Mașina este un server web care rulează câteva nodul expresjs cadre peste nginx, plus a geoserver

Am corelat mașina azi cu sudo apt update && sudo apt upgrade: ubuntu-advantage-tools, openssl și libssl1.1 au fost modernizate.

Versiunea mea de java este: Versiunea openjdk „1.8.0_292” OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~18.04-b10) OpenJDK 64-Bit Server VM (build 25.292-b10, mod mixt)

The geoserver este v2.13.0, care cred că este singurul program care ar putea folosi log4j. Geoserverul meu este versiunea binară independentă de platformă (nu versiunea Tomcat), care folosește dig ca server web cred.

Cum pot afla dacă și ce versiune de log4j am?

ACTUALIZARE: 2021-12-18...

Nu uitați să verificați întotdeauna cele mai recente informații din resursele enumerate mai jos

CVE-2021-45105... 2.16.0 și 2.12.2 nu mai sunt remedieri valabile! Versiunile actuale de remediere sunt 2.17.0 (Java 8) și 2.12.3 (Java 7). Toate celelalte versiuni Java trebuie să adopte abordarea stop-gap (eliminarea/ștergerea fișierului JndiLookup.class din JAR-ul log4j-core.
Mi-am actualizat mesajul de mai jos în consecință.

Răspunzând direct la întrebare:
Mergi la Firul Reddit: log4j_0day_being_exploited și ctrl+f pentru .clasa si .jar vanator recursiv. Rulați programul acolo și, dacă găsește ceva, remediați.

Apoi accesați același site web și ctrl+f pentru Avizul vânzătorilor. Căutați acele liste pentru a vedea dacă rulați vreunul dintre software-urile afectate. Dacă sunteți și este disponibilă o actualizare, actualizați.

• Mai multe resurse
  • https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
    • Acesta are TONE de informații utile, inclusiv detectoare, chiar mai multe link-uri de resurse, pași de remediere foarte ușor de înțeles și multe altele
  • https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
  • https://github.com/cisagov/log4j-affected-db
  • https://logging.apache.org/log4j/2.x/security.html

Remediere:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
În timp ce majoritatea oamenilor care trebuie să știe, probabil, știu deja suficient pentru a face ceea ce trebuie să facă, m-am gândit că tot aș pune asta pentru orice eventualitate...

• Urmați îndrumările din acele resurse... se poate schimba, dar

Din 2021-12-18

Practic este

• Eliminați fișierele JAR log4j-core dacă este posibil
  • De la ambele mașini care rulează pentru reparare imediată ȘI
  • în fișierele dvs. de gestionare a codului sursă / codului sursă pentru a împiedica viitoarele versiuni / lansări / implementări să suprascrie modificarea
• Dacă acest lucru nu este posibil (din cauza unei dependențe), actualizați-le
  • Dacă rulați Java 8, atunci puteți face upgrade la log4j 2.17.0+
  • Dacă rulați Java 7, atunci puteți face upgrade la log4j 2.12.3
  • Dacă rulați o versiune mai veche de Java, trebuie să faceți upgrade la cea mai nouă versiune de Java și apoi să utilizați cea mai nouă versiune de Log4J
  • Din nou, aceste modificări trebuie să aibă loc atât pe mașina care rulează, cât și în cod
• Dacă niciuna dintre acestea nu este posibilă dintr-un motiv oarecare... atunci există decalajul fără remediere de a elimina fișierul JndiLookup.class din JAR-urile log4j-core.
  • Există o singură linie pentru opțiunea stop gap pe Linux folosind fermoar comandă care vine implicit împreună cu majoritatea distribuțiilor Linux.
    • zip -q -d „$LOG4J_JAR_PATH” org/apache/logging/log4j/core/lookup/JndiLookup.class
  • La momentul scrierii, majoritatea ghidurilor online pentru opțiunea de oprire pe Windows spun să faceți următoarele (din nou... presupunând că nu puteți face una dintre opțiunile de eliminare JAR sau de actualizare de mai sus):
    • Instalați ceva de genul 7-zip
    • Localizați toate fișierele dvs. JAR log4j-core și pentru fiecare faceți următoarele...
    • Redenumiți JAR în care să schimbați extensia .zip
    • Utilizați 7-zip pentru a dezarhiva JAR-ul (care acum are un .zip extensie)
    • Localizați și eliminați fișierul JndiLookup.class din folderul dezarhivat
      • Calea este \cale\la\unzippedFolder\org\apache\logging\log4j\core\lookup\JndiLookup.class
    • Ștergeți vechiul fișier JAR (care are acum extensia .zip)
    • Utilizați 7-zip pentru a re-zipa folderul
    • Redenumiți noul folder .zip pentru a schimba extensia .borcan
  • Există, de asemenea, câteva opțiuni pentru a utiliza Power Shell
    • Firul Reddit: log4j_0day_being_exploited
    • ctrl+f pentru „PowerShell”

Acest lucru este în regulă dacă aveți doar 1 sau 2 fișiere JAR de tratat și nu vă deranjează să instalați 7-zip sau aveți PowerShell disponibil pentru a face acest lucru. Cu toate acestea, dacă aveți o mulțime de fișiere JAR sau dacă nu doriți să instalați 7-zip și nu aveți acces la Power Shell, am creat un script VBS open-source care o va face pentru dvs. fără a fi nevoie să instalați orice software suplimentar. https://github.com/CrazyKidJack/Windowslog4jClassRemover

Citiți README și notele de lansare https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

Rețineți că doar log4j v2 are această vulnerabilitate. Log4j v1 mai vechi nu este afectat de această vulnerabilitate.

Important, nu îl veți găsi în lista dvs. de apt (așa cum este descris în răspunsul acceptat), deoarece de obicei nu ar fi instalat ca aplicație sau serviciu autonom. log4j este o bibliotecă de jurnalizare java folosită de aplicații și astfel ar fi instalată împreună cu o altă aplicație (Java).

Va trebui să căutați fișierul denumit log4jv2*.jar oriunde pe disc pentru a fi sigur. localiza va face acest lucru dacă este instalat altfel sudo find / -iname log4j2*.jar.

Rețineți că unele aplicații redenumesc și fișierele JAR log4j2.

De asemenea, vă rugăm să fiți conștienți de astăzi (2021-DEC-19) o altă vulnerabilitate a fost găsită cu Log4J v2, care ar putea permite refuzarea de la distanță a serviciului și toți cei care au corelat la v2.16 ar trebui acum să patcheze la v2.17.

https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105