News Log4Shell: Sicherheitslücke in log4j für Java hält die IT-Welt in Atem

[zEtTlAh]

@Jan
"Wie es scheint, ist unser Setup ohnehin nicht verwundbar..."

Das ist der beste Satz, den ich in über 20 Jahren IT Laufbahn gelesen habe... Oder war das eine Aufforderung euer System einem unfreiwilligen Pen Test zu unterziehen ?

 

[DaysShadow]

@zEtTlAh Der Satz stand im Kontext zu dieser Sicherheitslücke und nicht als allgemeine Aussage, oder nicht?

 

[25Plus]

Mein Computer hängt am Netzwerk und läuft mit aller Software, die ich irgendwann in den letzten 10 Jahren für notwendig erachtet habe. Mein Firmenrechner läuft mit aller Software, die mein Arbeitgeber für notwendig erachtet.

Mit den Fachbegriffen in der News und hier im Forum kann ich überhaupt nichts anfangen. Aber da "alle" davon reden, wie kritisch das Problem ist und Sonderschichten schieben, wird das schon gutgehen. 99% der restlichen Nutzer irgendwelcher Geräte haben das gleiche Vertrauen. Immer.

PS: Wenn es dann doch nicht mehr funktioniert, kennt man jemanden, der sich darum kümmern soll.

 

[polyphase]

Auf den ComputerBase-Servern kommen Java und log4j übrigens ausschließlich für das Such-Backend Elasticsearch zum Einsatz, welches sowohl das CMS als auch die Forumsoftware XenForo nutzen. Die empfohlenen Maßnahmen gegen die log4j-Sicherheitslücke habe ich am frühen Samstagmorgen umgesetzt. Es gibt keine Anzeichen dafür, dass die Sicherheitslücke auf ComputerBase ausgenutzt wurde.

Man vermutet aktuell, dass unser Setup ohnehin nicht verwundbar ist, weil Nutzer und somit auch ein potenzielle Angreifer auf Elasticsearch nicht direkt zugreifen können, sondern dies nur indirekt über die Suchfunktionen des CMS oder XenForo geschieht (Ankündigung von XenForo).

Ich finde es super, wie offen du damit umgehst 👍

So geht Transparenz!

 

[[wege]mini]

Es soll tatsächlich Menschen geben

Prinzipiell gebe ich dir Recht.

Es soll aber angeblich sogenannte Extremsituationen geben, in denen der verständliche Wunsch auf Erholung dem Gemeinwohl entgegen steht.

Ich muss dann immer an den alten Asterix Trickfilm denken, in dem sich die Engländer über das unerhörte Verhalten der Römer aufgeregt haben, die einfach während der "Tea Time" angegriffen haben. Böse Römer.

Wenn dieses Jahr zu XMAS in den Ämtern wieder keiner arbeitet und man alles laufen lässt, bekomme ich einen Schreikrampf und die Kameraden werden die Türen aufbrechen, um zu arbeiten und das Volk zu schützen.

Letztes Jahr war eine Schande. Die Uniformierten standen vor verschlossenen Türen, da die Damen und Herren vom Gesundheitsamt ihren Urlaub brauchten und die Uninformierten gingen demonstrieren.

btt:

Eigentlich sollte man solche Dinge erst veröffentlichen, wenn brauchbare Gegenmaßnahmen ergriffen werden können. Sonst zieht man nur Trittbrettfahrer an.

mfg

 

[polyphase]

Soweit ich das jetzt verstanden habe interpretiert der Logger eventuell ein nachladen von bösem Code aus dem Internet.
Doch wenn das System nicht direkt am Internet hängt muss man sich, wie immer, erstmal was einfangen damit das ausgelöst wird.

Ich nehm jetzt Mal als Beispiel mein Netzwerk:
Da habe ich Geräte drin, die zwar Zugriff auf das Netzwerk haben, aber nicht auf das Internet.

D.h. wenn jetzt ein Gerät jetzt mit dieser Lücke über einen String aufgefordert wird (z.B. von einem anderen Gerät aus dem Netzwerk), Teile aus dem Internet nachzuladen, kann es das nicht.

Da meine Firewall so konfiguriert ist, alle Pakete die von diesem Gerät (das mit der Lücke) aus und ins Internet gehen, sofort zu verwerfen.

Also es kommt insgesamt darauf an, wie das ganze Netzwerk konfiguriert, bzw. abgesichert ist

 

[killian464]

Unser Geschäftsführer wollte mit einfachen Worten wissen was los ist.

Habe gesagt er soll sich unsere IT als Roman vorstellen und es ist bekannt geworden,dass das Wort "der" angreifbar ist. Er hat's verstanden.

 

[conspectumortis]

Man man man, das war gestern ein Stress bei der Arbeit ^^ Erst nach der Arbeit habe ich dann die Nachrichten gesehen, bzw. hier gelesen, was überall sonst los ist

 

[Inxession]

Bahnhof für mich ...

Interessant aber allemal.

Trotzdem bleiben meine Fragen ...

• bin ich als "Standard" user betroffen, wenn Ja, welche Software?
• Reicht es, wenn ich Java deinstalliere?
• Muss ich den Rechner "offline" nehmen?
• Betrifft es auch Hardware wie Router etc, die evtl ein Java basiertes OS haben?

Sorry für diese Laien Fragen, aber alle Beiträge die man so finden kann, sind gespickt mit massig Fachkompetenz und das schreckt mich als Normalo irgendwie ab.

Nicht das mich die Hintergründe nicht interessieren würden.
Aber wichtiger wäre für mich zu wissen, was ICH aktiv tun kann, um MICH zu schützen.

Fast wie die COVID Impfung.

 

[nospherato]

Wer noch nicht weiß, ob genutzte Applikationen betroffen sind, hier eine (unvollständige!! auch wenn sie lang ist) Liste: https://github.com/NCSC-NL/log4shell/tree/main/software
@Jan vielleicht magst du die ja noch in deinem Artikel unterbringen, die ist etwas übersichtlicher als die bereits verlinkte

Würde ich mich nicht drauf verlassen. Der Tivoli Storage Manager z.B. ist auch betroffen je nach Version. Findet sich aber nicht in der Liste bisher.
Da ist es deutlich sicherer mit externem Scanner und direkt auf den Servern noch mal zu schauen... Auch wenn das teilweise etwas viel Arbeit ist.

 

[BeBur]

Betrifft es auch Hardware wie Router etc, die evtl ein Java basiertes OS haben?

Ja.

bin ich als "Standard" user betroffen, wenn Ja, welche Software?

Ja. Jede Software, die Java verwendet könnte betroffen sein.

Reicht es, wenn ich Java deinstalliere?

Nein.

Muss ich den Rechner "offline" nehmen?

Nein. Die meiste Software kommuniziert nicht mit unbekannten im Internet. Prominente Ausnahmen sind dein Browser und dein E-Mail Programm. Ich kenne jedoch kein E-Mail Programm oder Browser, dass Java verwendet.
D.h. das Haupteinfallstor wie du schon erkannt hast wäre dein Router, da könntest du mal schauen, ob du was findest.

ImHo, vllt korrigiert mich ja jmd, da Java wegen der notwendigen VM Umgebung einen relativ großen Overhead hat wird Kleinhardware wie Router normalerweise nicht mit Java programmiert.

 

[borizb]

Ihr hättet auch einfach den Workaround nutzen können Nutzt Confluence nicht wie jira eh nur log4j 1.x und ist dann nur verwundbar wenn man nen JMS Appender (was kaum jemand macht) nutzt?

Wir sind heute wieder on gegangen, unsere Confluence Version war nicht betroffen.
Zumindest gestern stand auf der Seite von
Atlassian noch keine definitive Aussage.
Bin mal gespannt was da noch rauskommt.

 

[ComputerJunge]

Bei den Kollegen findet sich eine etwas ausführlichere Beschreibung: https://www.golem.de/news/log4j-lue...lich-ist-und-was-nicht-hilft-2112-161757.html

 

[Piktogramm]

Unser Geschäftsführer wollte mit einfachen Worten wissen was los ist.

Habe gesagt er soll sich unsere IT als Roman vorstellen und es ist bekannt geworden,dass das Wort "der" angreifbar ist. Er hat's verstanden.

Bei der Erklärung kann er garnix verstanden haben o.O
"Fremde Leute können beliebig Code auf unseren Kisten ausführen, BSI sagt 4 von 4"

 

[cmi777]

@Jan bzw. @Steffen

Wie es scheint, ist unser Setup ohnehin nicht verwundbar, weil Nutzer und somit auch ein potenzieller Angreifer auf Elasticsearch nicht direkt zugreifen können, sondern dies nur indirekt über das CMS oder XenForo geschieht

Wir haben eine ähnliche Konstellation im Büro. Elasticsearch selbst schätzt sich als "sicher" ein, allerdings ist "keine direkte Erreichbarkeit" (mMn) kein Sicherheitskriterium. Wichtig ist ja nach meinem Verständnis nur, dass die Payload "irgendwo" mit einer verwundbaren Log4J-Version geloggt wird (und dieser Server dann eine Verbindung nach außen aufbauen kann).

Beispiel:

1. Reverse-Proxy schreibt access.log (default mit Useragent, deswegen wird das so gern genutzt, ebenso wie GET-Parameter)
2. access.log wird von Drittsystemen (Beispiel: Filebeat -> Elasticsearch) verarbeitet/gespeichert.

Wird bei Punkt 2 noch mal mit einer verwundbaren Log4J-Version ein relevanter Teil des Eintrags im Logfile geloggt, greift die Lücke "trotzdem".

(Im konkreten Fall sollte das safe sein (Filebeat ist in Go geschrieben, Elasticsearch ist (trotz Java) lt. Elastic auch safe, ebenso Logstash (mit einem "aber")). Mir ging es mehr um die Aussage "nicht direkt erreichbar -> alles gut".)

 

[SheepShaver]

Genau deswegen sollte man auf native Anwendungen setzen statt Java zu nutzen. Ich sage schon seit Jahren, dass man im Serverbereich von Java weg kommen muss. Das war früher mal wichtig mittlerweile gibt es bessere Anwendungen vor allem sicherer und schneller.

Ach genau, weil es NATÜRLICH am Tech-Stack liegt, wenn Entwickler Mist bauen. Und von Java wird man so schnell nicht wegkommen. Dazu basieren zu viele essenzielle Projekte darauf, die man im Enterprise Umfeld einfach braucht.
Irgendwann mal gibt es hoffentlich genügend Alternativen aus dem Go-Ökosystem, aber da sind wir noch weit von entfernt (wenn ich allein schon an Kafka denke).

 

[MadCat[me]]

Ja, hat heute bei der Arbeit auch gut für Beschäftigung gesorgt, und ja, Spring-Boot-Starter ist in der Tat nervig,
da hier eine gepatchte Variante ( = die 2.15.0 mitbringt ) erst am 23.12. erscheinen soll.

Muss man also in so einer Umgebung selber Hand anlegen ... wie potentiell gefährlich und irgendwie übers Ziel hinaus dieser Mechanismus eines Loggers ist, remote Code zu laden und auszuführen - nun ja, darüber braucht man nicht weiter sprechen.

@lugge

Hast du den Thread / das Forum verfehlt? Scheint mir so ...

Wobei Spring Booter Starter erstmal nur via Spring Boot Starter Logging slf4j mitschleppt, dass dann auch noch log4j mitbringt, aber standardmäßig benutzt Spring Boot logback. Damit log4j verwendet wird, muss man das explizit so konfigurieren. Siehe https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot und https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.logging.log4j

Ich habe bei uns aber auch sicherheitshalber schon am Freitag manuell die Versionen hochgezogen und inzwischen via Exclusion in Maven log4j komplett rausgeschmissen.

 

[foo_1337]

Würde ich mich nicht drauf verlassen. Der Tivoli Storage Manager z.B. ist auch betroffen je nach Version. Findet sich aber nicht in der Liste bisher.

Daher schrieb ich ja absichtlich unvollständig mit 2 Ausrufezeichen

 

[BrollyLSSJ]

Also mein Kollege hat seinen Scanner über den Haufen geworfen und verweist auf diesen hier: https://github.com/hillu/local-log4j-vuln-scanner

Hab ein tolles tool gefunden. Wie das genau funktioniert ist mir noch nicht ganz klar aber auf alle Fälle hilfreich. (In einem Fall findet er erst etwas in der fat jar)
https://github.com/anchore/grype

Wenn man die executeable hat einfach grype path/to/project/or/jar machen

Danke euch beiden für die Links. Mal gucken, wie ich damit einfach unter Windows alles abscannen kann.

 

[PHuV]

Wir haben eine ähnliche Konstellation im Büro. Elasticsearch selbst schätzt sich als "sicher" ein, allerdings ist "keine direkte Erreichbarkeit" (mMn) kein Sicherheitskriterium.

Schenkelklopfer, die sind genaus betroffen.

Nur mal so, unsere Firma beschäftigen uns seit gestern intensiv damit. Hier mal ein sehr übersichtliches Bild, wie ein Angriff läuft.
Quelle:
https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Unser Fazit: Eine Katastrophe, weil Log4j in zig Paketen und Paketen von Paketen versteckt ist. Prüfung mit
https://github.com/mergebase/log4j-detector bringt einige Erhellung.