Seite 2 von 5 Erste 1234 ... Letzte
  1. #11
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    Wow super Video, habe den Channel erst gerade entdeckt. Like und Abo sind drin. Als Entwickler kann ich es bestätigen das zu leicht mit Drittanbieter Software gearbeitet wird, z.B. nutze ich viele Librarys in meinem Programmen welche ich mir vorher nicht genau angeschaut habe. Ich bin selber mit eigenen Minecraft Servern betroffen und daher sehr interessiert daran diese Schwachstelle zu beheben, also danke für dein Video


    Kommentar von Forest Cast.

  2. #12
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    leider wurde mein microsoft account gehackt. das ist sehr frustrierend, werde wohl meinen pc komplett resetten. danke fürs video!


    Kommentar von PlayLikeMaxi.

  3. #13
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    Es sind nicht nur Java Applikationen betroffen. JVM Application ist wohl ein wenig spezifischer. Scala und Kotlin sind also auch betroffen.


    Kommentar von Christian Köberle.

  4. #14
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    Also ich finde, dass "CVE-2021-44228" wesentlich einfacher auszusprechen ist als "log4bash".


    Kommentar von Nachname Vorname.

  5. #15

    Registriert seit
    14.12.2021
    Beiträge
    2
    Thanked 0 Times in 0 Posts

    Standard AW: Schwere Lücke in log4j (CVSS 10/10): Zahlreiche Java-Anwendungen betroffen, u.a. Apple, Steam, T

    Danke für Artikel und Video. Sehr instruktiv, und eigentlich hands-on.

    Ich hab trotzdem Probleme, weil die Hersteller bei uns eingesetzter Software bei dem Thema lieber verdienen wollen, statt gezielte Fragen zu beantworten, die mich selbst zur konfigurativen Lösung befähigen würden.

    So wie ich das verstanden habe, braucht es außer dem Vorhandensein der Klasse in einem beliebigen .jar einen aktiven log4j-Logger, oder? Kann ich den sicher an Einträgen z.B. in der side-by-side-config (Windows) erkennen? Oder durch welchen Grep / Select-String am besten?

    Das JndiLookup.class enthaltende .jar ist in einem .ear. Es wurde nicht ein log4j-core-*.jar paketiert, sondern die Klasse direkt in ein .jar-Paket eingebunden. (Sorry, wenn das Wording merkwürdig ist, bin kein Java-Entwickler.) Hab ich eine Chance, die Version anhand der entpackten .class-Datei zu ermitteln?

    Ob die JndiLookup.class gerufen wird innerhalb der Anwendung, kann mir nur der Hersteller beantworten? Oder gibt es typische Zeichenfolgen, die ich in .JARs, .EARs oder so mindestens finden müsste? Und wenn nicht, dann hängt die Klasse da einfach nur rum, und ich kann sie gefahrlos rauslöschen?

    Wie müsste ich zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class abändern, damit ich eine Klasse aus einem in ein .ear gehängtes .jar löschen kann? Ein Linux gibts immer, daran würde es nicht hängen. Wenn ich das .jar erst aus dem .ear entpacken muss, kann ich es dann mit zip wieder einsetzen, oder muss ich das .ear mit einem java-command neu erzeugen?

    Da das alles viele Wenns und Abers beinhaltet: Wie teste ich bei einer nicht-interaktiven Java-Anwendung, ob dieses "Schwachstelle" genannte Feature zur Verfügung steht? (Finde es ja per se OK, auch Code von irgendeinem internen Server zu holen. Der Fehler / die Lücke ist, diesen Lookup per Default auf true zu stellen, in einem Modul, das in der Regel einfach eingehängt und konsumiert wird.)

  6. #16
    Avatar von Bob Marley
    Registriert seit
    02.12.2011
    Beiträge
    54
    Thanked 24 Times in 18 Posts

    Standard

    Ja, der Logger muss aktiv genutzt werden und der Angreifer muss es schaffen, irgendwie Daten in Log4j zu injizieren. Wenn Log4j in einer Anwendung vorhanden ist (Core), dann würde ich aber davon ausgehen, dass das der Fall ist.
    Deine Erfahrungen mit den Herstellern ist leider nicht selten. Vor allem bei proprietärer Software sitzen die auch meiner Erfahrung nach auf einem hohen Ross und liefern Updates teilweise nur wenn man zahlt. Was ein Unding ist wenn man bedenkt, dass die Lücke ja bereits zum Kaufzeitpunkt vorhanden ist.

  7. The Following User Says Thank You to Bob Marley For This Useful Post:

    mupan (20.12.2021)

  8. #17
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    6.080
    Thanked 9.118 Times in 2.995 Posts
    Blog Entries
    5

    Standard

    Gerne :)
    Zu deinen restlichen Fragen:

    Zitat Zitat von mupan Beitrag anzeigen
    Es wurde nicht ein log4j-core-*.jar paketiert, sondern die Klasse direkt in ein .jar-Paket eingebunden.
    Autsch... da kannst du nur hoffen, dass beim Dekopilieren mit z.B. JD-GUI irgendwo eine Konstante mit der Version mitkopiert wurde. Mittelfristig ist das Murksen und Orakeln, da würde ich den in Haftung nehmen, der es Verbrochen hat. Ansonsten wird das nie besser. Leider gibt es derzeit wenig Anreiz für v.a. kommerzielle Unternehmen, Qualität abzuliefern, wie du dem Anfang deines Beitrages nach schon selbst leidhaft feststellen durftest. Grade bei proprietärer Software bleibt im Zweifel nur Abschalten. Klingt radikal, aber alles andere ist Orakeln und Hoffen. Außerdem bist du mit eigenen Bastelleien schnell in der Haftung, obwohl du nur helfen wolltest und der Hersteller für das Problem verantwortlich ist. Wenn das zu tief verwurzelt ist oder man sogar Klassen ohne Pakete hin- und her kopiert hat, wäre ich daher raus.

    Zitat Zitat von mupan Beitrag anzeigen
    Ob die JndiLookup.class gerufen wird innerhalb der Anwendung, kann mir nur der Hersteller beantworten?
    Nein, das ist eine Funktion von Log4j und wird vom Angreifer aufgerufen. Die Meisten die das nutzen wissen wahrscheinlich gar nichts davon und haben die Bibliothek mehr oder weniger blind in ihre Projekte eingebunden. Genau deswegen ist die Lücke ja auch so gefährlich: Über die Schwachstelle kann man die JdniLookup-Klasse verwenden, um unkontrolliert Code von fremden Servern auszuführen. Da muss der Entwickler der Anwendung, in der Log4j verbaut wurde, gar nichts aktiv zu beitragen. Deswegen ist der einzig wirksame Workaround das Löschen dieser Klasse, falls ein Update noch nicht möglich ist. Einziger Seiteneffekt den das hat ist, dass Java einen Fehler werfen wird, falls jemand JDNI nutzt. Das ist in den meisten Fällen ein Angreifer und damit vernachlässigbar.

    Zitat Zitat von mupan Beitrag anzeigen
    Wenn ich das .jar erst aus dem .ear entpacken muss, kann ich es dann mit zip wieder einsetzen, oder muss ich das .ear mit einem java-command neu erzeugen?
    Das kommt auf die Anwendung drauf an. Es gibt Java-Archive, die signiert sein müssen. Beispielsweise früher die Java-Applets im Browser. Dürfte aber eher die Ausnahme als die Regel sein. Würde es daher so versuchen wie du gesagt hast: Die ear entpacken (ist ebenfalls ein ZIP-Archiv), dann die JdniLookup-Klasse entfernen und entsprechend neu packen. Geht auch mit dem zip Befehl:
    Code:
    zip archiv.ear pfad/zur/aktualisierten/datei
    Da sollte dann "Updating" in der Ausgabe stehen. Dann hat er die Datei gefunden und ersetzt.
    Zitat Zitat von mupan Beitrag anzeigen
    Wie teste ich bei einer nicht-interaktiven Java-Anwendung, ob dieses "Schwachstelle" genannte Feature zur Verfügung steht?
    Heißt konkret? Du kannst natürlich Verwundbarkeitstests mit allen Schnittstellen machen, die diese Anwendung besitzt. Denn am Ende muss ja ein potenzieller Angreifer dort Zeichenketten hin senden können, um die Lücke auszunutzen. Dafür sollte man wissen, was die unter welchen Umständen protokolliert. Das kann alles mögliche sein, was man auch auf den ersten Blick nicht unbedingt auf dem Schirm hat: Wird z.B. eine HTTP-Anfrage an Drittanbieter gestellt, könnten Header oder Body geloggt werden, wenn ein Fehler auftritt - eventuell nur bei bestimmten Fehlern. Was du natürlich machen kannst ist, einen der Scanner wie local-log4j-vuln-scanner drüber laufen zu lassen. Aber der funktioniert halt nur bei offiziellen, bekannten Maven-Builds. Deine oben angesprochene Software, wo jemand per Copy & Paste die Klasse rüber kopiert hat, würde damit also beispielsweise nicht erkannt werden. Solche Werkzeuge würde ich daher bestenfalls als zusätzliche Info sehen, mich aber nie alleine darauf verlassen.

    Du siehst, das hängt sehr stark von der Anwendung ab. Die Beste und Sicherste Methode ist daher, zu schauen, was der Hersteller sagt bzw. dem Druck zu machen, falls der sich nicht vernünftig kümmert. Der sollte seine Software am besten kennen und Aussagen darüber treffen können, was unter welchen Umständen verwundbar ist. Und vor allem Updates bereitstellen sowie bis dahin im besten Falle akute Workarounds.

  9. The Following 2 Users Say Thank You to DMW007 For This Useful Post:

    Hase (22.12.2021), mupan (20.12.2021)

  10. #18
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    Hallo ich nutze sowohl Linux als auch Windows Rechner. Auf Linux weiß ich wie ich die Befehle anzuwenden habe, bei Windows kenn ich mich damit leider gar nicht aus. Kann mir da jemand weiterhelfen?


    Kommentar von Christine.

  11. #19
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    Betrifft das ausschließlich log4j oder auch andere libraries aus den apache logging services? Bspw log4net...


    Kommentar von Großer Gurken Bruder.

  12. #20
    Avatar von U-Labs YouTube
    Registriert seit
    30.09.2021
    Beiträge
    1.341
    Thanked 31 Times in 29 Posts

    Standard

    Danke aber geht es noch einfacher? Das ist immer noch zu sehr IT Sprech. Es gibt Leute die nicht viel Ahnung von IT und Technik haben. Danke.


    Kommentar von Liane Li.

Seite 2 von 5 Erste 1234 ... Letzte
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.