Seite 1 von 5 123 ... Letzte
  1. #1
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    6.080
    Thanked 9.118 Times in 2.995 Posts
    Blog Entries
    5

    Standard

    Jüngst wurde eine schwere Schwachstelle in Log4j bekannt, einer beliebten Bibliothek primär für Java-Anwendungen: In den Versionen 2.0 bis 2.14.1 kann man auf dem Zielsystem eigenen Programmcode ausführen, wenn es dem Angreifer gelangt, eine Zeichenkette in die Logs zu schleusen. Das ist schnell passiert, da Logs ja (v.a. in höheren Leveln) möglichst viele Informationen enthalten sollen. Beispielsweise kann ein User-Agent protokolliert werden, den der Client frei setzen kann. Die Lücke ist somit sehr trivial auszunutzen und wird daher auch bereits ausgenutzt. Erste Angriffsversuche konnte ich auf von mir betreuten Systemen bereits feststellen.

    Bekannte Kompromittierungen zielen laut Informationen des BSI vor allem auf Cryptominer ab, also relativ harmlos. Das kann sich natürlich ändern. Wer Log4j verwendet, sollte möglichst auf die neueste Version 2.15.0 aktualisieren. Alternativ kann log4j2.formatMsgNoLookups=true gesetzt werden. Entweder in der log4j.properties oder als JVM-Argument -Dlog4j2.formatMsgNoLookups=true bzw. Umgebungsvariable. Allerdings funktioniert dies erst ab Version 2.10. Alternativ lässt sich die verwundbare Klasse auch aus dem Jar-Archiv entfernen:
    Code:
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    Aktuell ist nicht abschließend geklärt, wer und was alles betroffen ist. Da es heutzutage nicht ünüblich ist, einen Haufen an Abhängigkeiten in Softwareprojekte zu packen, nutzt man möglicherweise log4j indirekt ohne es zu wissen. Auch wenn ein System nicht direkt übers Internet erreichbar ist, kann es indirekt möglicherweise über andere Schnittstellen verwundbar sein. Beispiel: Elasticsearch ist betroffen, läuft lokal, aber wird von einer Webanwendung genutzt, die übers Internet erreichbar ist. Dadurch ist ggf. Elasticsearch über diese Schnittstelle verwundbar. Weitere Informationen gibt es beim BSI.

    Ergänzung: Videobeitrag


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

    Darkfield (12.12.2021), Manipulate (12.12.2021)

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

    Standard

    Aufgrund der Schwere und der (bislang nicht vollständig erfassten) umfangreichen Auswirkungen habe ich einen ungeplanten Video-Beitrag dazu erstellt, der das Thema umfangreicher betrachtet:




    Zur Textversion: Schwere Sicherheitslücke „Log4Bash“ in Log4j erklärt: Zahlreiche Java-Anwendungen betroffen, u.a. Minecraft, Apple, Twitter, Tesla, Steam, Amazon und mehr.

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

    Standard

    Hallo!

    Sollte man auch auf dem Desktop verwendete Linux Systeme wie Linux Mint oder Ubuntu überprüfen, wenn man es nur für den Desktop nutzt, oder werden auf diesen Systemen die genannten sicherheitslücken nicht genutzt?



    Kommentar von Martin Barth-Engels.

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

    Standard

    Guten Abend,

    das kommt darauf an, was auf diesen Systemen so läuft und wofür sie eingesetzt werden. Prinzipiell können die Anwendungen dort auch verwundbar sein. Die Wahrscheinlichkeit ist bei reiner Desktop-Nutzung wohl eher gering, vor allem wenn das System nicht über das Internet erreichbar ist. Schaden kann es dennoch nicht. Lieber einmal zu viel geprüft als zu wenig.

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

    Standard

    Das grep nach JndiLookup liefert ein paar falsche Ergebnisse in Spring/C3P0 mit Klassen wie JndiLookupException die mit JndiLookup anfangen. Mit "grep JndiLookup.class" gabs keine Treffer =)


    Kommentar von Scriptease.

  7. The Following User Says Thank You to U-Labs YouTube For This Useful Post:

    DMW007 (12.12.2021)

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

    Standard

    Das ist eine sinnvolle Idee, habe ich im Portal-Artikel ergänzt. Danke für den Hinweis!

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

    Standard

    Danke für die schnelle Info, der abgesetzte Befehl lieferte tatsächlich ein zwei Ergebnisse.

    Was mich etwas verunsichert, ich erhalte eine lange Liste von Ergebnissen mit dem Muster: " find: '/proc/{pid}/map_files': Vorgang nicht zulässig

    Hast du hier irgendwelche Tipps?



    Kommentar von Z0mbiel0ne.

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

    Standard

    Hi, dir auch danke für das Feedback :)

    Dieser Fehler ist unbedenklich, da /proc ein spezielles (Pseudo) Dateisystem ist, um Kernelinfos bereitzustellen. Wenn der Befehl mit root Rechten läuft (also als root oder mit sudo), dann können diese Fehler mit 2>/dev/null ignoriert werden. Ich habe den Befehl im Portal-Artikel überarbeitet und mit einem Hinweis versehen.

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

    Standard

    Hallo,
    Klinkt alles sehr interessant was du erzählst aber ich verstehe nur Bahnhof.

    Wenn ich nur mit meinen MacBook im Internet surfe( Apple; Amazon; Oder Netflix schaue kann ich dadurch auch angegriffen werden ? Ich habe auch steam aber nicht geöffnet bzw irgendwas gespielt.
    Und wo kann ich diese Codes eingeben.

    Danke wenn du auf diese (aus deiner Sicht) blöde Frage antwortest.



    Kommentar von Steffan Leger.

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

    Standard

    Hi,
    sehe ich nicht als blöde Frage. Hauptsächlich sind zwei Gruppen betroffen: Primär jene, die mit Java irgendwelche Dienste über das Internet anbieten und dort die Bibliothek Log4j verwenden. Das sind die im Beitrag als Beispiel genannten Unternehmen. Aber eben teils auch Privatpersonen, beispielsweise weil diese einen Minecraft-Server oder andere Projekte betreiben, bei denen diese Technologie zum Einsatz kommt. Damit bist du in deiner Rolle als reiner Konsument schon mal raus, außer du betreibst irgendwelche Serverdienste. Für jene sind auch die Befehle aus meinem Beitrag gedacht, da (Linux-) Server hauptsächlich per SSH über die Konsole verwaltet werden. Gibt es unter MacOS auch, braucht jemand der das Gerät nur zum Konsumieren von Inhalten nutzt aber nicht, dafür reicht die grafische Oberfläche.

    Die andere Gruppe sind Nutzer, welche ein mit dem Internet verbundenes Gerät zuhause haben, dass entsprechend verwundbar ist. Das können zum Beispiel Netzwerkgeräte vom Hersteller Ubiquiti sein. Dort ist bisher bekannt, dass die Geräte durch diese Lücke verwundbar sind und der Hersteller hat Sicherheitsaktualisierungen veröffentlicht. In diesem Falle sollte man diese so schnell wie möglich einspielen. Eine große Gefahr sind Geräte, die am Internet hängen und vom Hersteller nicht mehr gewartet werden. Beispielweise (günstige) IOT-Geräte. Wenn man solche Geräte nicht verwendet, dann ist man auch hier aus dem Schneider.

    Ansonsten kann dir als Nutzer folgendes passieren: Du verwendest einen Dienst, der von dieser Lücke betroffen ist und beim Beheben geschlafen hat. Dann ist dieser Dienst verwundbar und das kann für dich negative Folgen haben, wie z.B. Datenmissbrauch. Netflix ist hier raus, weil die sehr schnell reagiert haben. Aber es könnte passieren, dass du Dienst X nutzt, der weniger Wert auf Sicherheit legt und gerade angegriffen wird. In diesem Falle bist du als reiner Nutzer jedoch recht machtlos und kannst diese Dienste bestenfalls nach Bekanntwerden meiden.

    Generell ist hier aber wichtig zu verstehen: Die Lücke ist recht frisch und v.a. übers Wochenende haben einige Hersteller noch nicht geprüft, ob sie betroffen sind. Alles was ich und auch andere Quellen sagen, sind daher Momentanaufnahmen. Ich würde damit rechnen, dass sich da in den nächsten Tagen weitere Informationen ergeben. Zumal alle Hinweise zeigen, dass derzeit umfangreichere Angriffsversuche laufen. Es ist daher nicht überraschend, wenn wir von weiteren betroffene Unternehmen/Projekte in einigen Tagen oder Wochen dadurch erfahren, dass diese erfolgreich angegriffen wurden.

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