log4j-Sicherheitslücke [Archiv]

Sephiroth

2021-12-12, 23:19:29

Doch und auch verfügbar.
https://logging.apache.org/log4j/2.x/security.html

Fixed in Log4j 2.15.0

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1

Descripton: Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

Mitigation: In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

References: https://issues.apache.org/jira/browse/LOG4J2-3201 and https://issues.apache.org/jira/browse/LOG4J2-3198

Cyv

2021-12-12, 23:20:41

Klar. Wenn du das System selbst betreibst kannst die lib updaten oder entsprechende jvm-Parameter setzten. Aber viel Spaß wenn du komplexe Webanwendungen hast, wo jeder Entwickler seine libs selbst mitbringt. Auch bei Appliances wirst du in die Röhre gucken und auf einen Patch warten müssen. Da werden einige Betreiber noch Wochen zu tun haben…

Als Privatperson kann man glaub wenig machen derzeit.

Joe

2021-12-12, 23:22:09

Na,

wer von euch macht seit Freitag Überstunden?:freak:

https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen-6292863.html

https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j

Erst seit heute.
Ohne Zustimmung der Kunden kann man ja nicht viel tun und versuch mal an nem WE die Geschäftsführer ans Rohr zu bekommen.
Hab aber jetzt eigentlich alles durch.

Proaktiv erst mal jeden Server, der Internetseitig offene Ports hat abgeschaltet. Hab aufgehört zu zählen. Mindestens 200.
Zum Glück in 95% der Fälle nur unwichtige Sekundärdienste.

Morgen schauen wir mal in Ruhe weiter. Hoffe es gibt bald paar gute Tools zum Testen. Auf so vielen Kisten läuft so viel Rotze, unmöglich zu sagen ob diese Bibliothek da irgendwo mit rumschwirrt.

Sephiroth

2021-12-12, 23:25:15

Aber viel Spaß wenn du komplexe Webanwendungen hast, wo jeder Entwickler seine libs selbst mitbringt.
Da kann man ja die Sys Property setzen.

Außerdem braucht es eine verdammt alte Java 8 Version (< 8u121), welche es überhaupt zulässt, remote code nachzuladen und auszuführen - stichwort "com.sun.jndi.ldap.object.trustURLCodebase". Oder man hat die Property explizit auf true gesetzt.

java 8u121 ... released 17.1.2017 (!)
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html
Improved protection for JNDI remote class loading

Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:

com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebase

Cyv

2021-12-12, 23:26:37

Erst seit heute.
Ohne Zustimmung der Kunden kann man ja nicht viel tun und versuch mal an nem WE die Geschäftsführer ans Rohr zu bekommen.
Hab aber jetzt eigentlich alles durch.

Proaktiv erst mal jeden Server, der Internetseitig offene Ports hat abgeschaltet. Hab aufgehört zu zählen. Mindestens 200.
Zum Glück in 95% der Fälle nur unwichtige Sekundärdienste.
:freak:
Morgen schauen wir mal in Ruhe weiter. Hoffe es gibt bald paar gute Tools zum Testen. Auf so vielen Kisten läuft so viel Rotze, unmöglich zu sagen ob diese Bibliothek da irgendwo mit rummschritt.

Ja, ich bin auch froh heute vor 12 ins Bett zu kommen.
Offene Ports abschalten nutzt euch vermutlich wenig. Der Payload ist entweder schon im Get-Request drin oder wird per Ldap nachgeladen. Wenn ihr könnt Lib updaten oder die JVM-Parameter setzen. Selbst für WAFs gibts schon nen Bypass. Das Ding ist echt hässlich:freak:

@Sephiroth: Das kommt auf die Komplexität der Webanwendungen an. Neben der Java-Version ist auch die log4j-Version relevant, wenn ichs verstanden hab. Die sind stellenweise über zig Server verteilt, jeder Entwickler kann die Libs irgendwo mitbringen. Bis das alles angepasst und deployed ist…

Ich bin mal schwer gespannt was wir die Woche noch so erfahren. Die Liste der betroffenen Hersteller wächst auch langsam. Cisco prüft derzeit noch, stellenweise triffts sogar Telefonanlagen.

Sephiroth

2021-12-12, 23:33:51

ne WAF ist ja auch nur zum gut fühlen und macht nichts sicherer ... gibt immer einen bypass und/oder die WAF ist so streng eingestellt, dass die geschützte app nicht mehr sinnvoll nutzbar ist.

sinnvoller, neben patchen, ist outbund traffic zu sperren und mit allow-listen zu arbeiten. gilt auch für externen DNS-traffic ... damit landet der server mit der anfälligen app erst gar nicht auf der liste der attacker und eine DNS shell ist dann auch hinfällig.

p.s.
Neben der Java-Version ist auch die log4j-Version relevant, wenn ichs verstanden hab.
ja, die property hilft erst ab log4j version 2.10.0

Cyv

2021-12-12, 23:40:18

ne WAF ist ja auch nur zum gut fühlen und macht nichts sicherer ... gibt immer einen bypass und/oder die WAF ist so streng eingestellt, dass die geschützte app nicht mehr sinnvoll nutzbar ist.

sinnvoller, neben patchen, ist outbund traffic zu sperren und mit allow-listen zu arbeiten. gilt auch für externen DNS-traffic ... damit landet der server mit der anfälligen app erst gar nicht auf der liste der attacker und eine DNS shell ist dann auch hinfällig.

Exakt. Wie gesagt bei großen Anwendungen oder Umgebungen echt eine Mammut-Aufgabe.

myMind

2021-12-12, 23:47:16

Da kann man ja die Sys Property setzen.

Außerdem braucht es eine verdammt alte Java 8 Version (< 8u121), welche es überhaupt zulässt, remote code nachzuladen und auszuführen - stichwort "com.sun.jndi.ldap.object.trustURLCodebase". Oder man hat die Property explizit auf true gesetzt.
So wie ich das hier verstehe:
https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/
stopfen neuere Java-Versionen nur einen Weg (remote classloading). Es gibt aber noch andere Möglichkeiten, z.B. via RMI (zweite Hälfte oben verlinkten Artikels).

Auch das system property hilft nicht in allen Fällen.
https://www.heise.de/forum/heise-online/Kommentare/Kritische-Zero-Day-Luecke-in-Log4j-gefaehrdet-zahlreiche-Server-und-Apps/formatMsgNoLookups-true-hilft-nicht-bei-selbst-implementierten-logevents/posting-40125237/show/

Unübersichtlich. Ich hoffe das arbeitet jemand mal in der Summe auf.

Borbarad

2021-12-13, 07:38:11

Na,

wer von euch macht seit Freitag Überstunden?:freak:

Log4j war mein Tag, meine Nacht, bis in meine Träume hinein... Jetzt bräuchte ich spontan Urlaub. ;)

Joe

2021-12-13, 10:04:16

Hab leider noch kein vernünftiges Test tool gefunden.

Bei 200+ Servern will ich jetzt nicht auf jeder Maschine rummachen.
Ich hätte gern was, das von remote aus auf basis von url / ip / Port und ggf. Benutzerkontext durch crawled und nach der Lücke sucht.

Es gibt wohl ein Burp Plugin aber Burp ist halt wieder die nukleare Option.

Annator

2021-12-13, 10:40:42

Gibt es schon einen einfachen Windows Scanner für Leien? Finde nur welche für Linux auf Github.

Cyv

2021-12-13, 10:56:49

Bei Windows wird ja häufig der gesamte Container geliefert, da würde ich in jedem Fall mal Kontakt mit dem Hersteller/Entwickler aufnehmen. Ich bin auhc noch auf der Suche nach einem Tool, was man einfach Leuten in die Hand drücken kann...

Mdk

2021-12-13, 11:04:44

Gibt es schon einen einfachen Windows Scanner für Leien? Finde nur welche für Linux auf Github.

https://github.com/fullhunt/log4j-scan

Python...

mfg
mdk

nalye

2021-12-13, 11:37:15

Haben auch erstmal unsere Cluster mit Ansible Ad Hoc gepatched. Ein Hoch auf Namespaces in Openshift. Die Projekte sollen sich selbst kuemmern und sind seit Freitag schon fleissig dabei.

Joe

2021-12-13, 11:42:02

https://github.com/fullhunt/log4j-scan

Python...

mfg
mdk

Das braucht pycrypto was wiederum ne komplette Visual Studio Installation braucht :frown:

Cyv

2021-12-13, 11:49:28

Annator

2021-12-13, 12:22:26

https://github.com/fullhunt/log4j-scan

Python...

mfg
mdk

Dafür brauche ich eine kostenpflichte Software oder? Ist nicht gut für Leien. ;)

Mdk

2021-12-13, 12:54:55

Dafür brauche ich eine kostenpflichte Software oder? Ist nicht gut für Leien. ;)

Hm? Für Windows Download unter [1] (oder direkt im WSL ab Windows 10), dann noch ein

pip3 install pycryptodome in der Eingabeaufforderung, fertig ist die Laube.

mfg
mdk

[1] https://www.python.org/downloads/

Opprobrium

2021-12-13, 14:07:26

Die Lücke selbst betrifft mich nicht wirklich, aber ich stelle fest, daß sich meine fail2ban Liste für meinen kleinen virtuellen NextCloud Server im Verlaufe des Wochenendes deutlich gefüllt hat.

Neben den Administratoren scheinen auch die Cracker Sonderschichten zu schieben...

Joe

2021-12-13, 14:30:24

Wir haben jetzt schon ziemlich viel Audit gemacht. Ca 66% sind wieder online.
Ging relativ schnell, weil viele Kunden identische Software einsetzen.
Bisher war noch kein Server betroffen.

Wos uns recht hart erwischt hat war Unify Produkte, die fast alle Kunden nutzen. Da muss die Unify Networks Firmware auf 6.5.54 hoch. Ging aber bis jetzt in allen Netzten Problemlos.

Alles wo vmware drauf steht ist wohl auch betroffen. Die Kisten präsentieren sich aber nicht WAN-Seitig und sind bei uns immer in eigenen VLANS. Also nicht so kritisch.

Asaraki

2021-12-13, 15:06:50

Sorry für "Offtopic", aber sind da Consumerprodukte von Unify auch betroffen? Dann müsste ich mal ein paar Freunden helfen ^^

Und viel Erfolg euch allen, hoffe ihr habt's bald wieder ruhiger.

Fusion_Power

2021-12-13, 15:08:47

Asaraki

2021-12-13, 15:11:58

Ich hab jetzt mehrere Meldungen über den Log4j Vorfall gelesen aber weiß immer noch nicht, was genau "Log4j" eigentlich ist und macht. Ist wohl ehr was spezielles mit dem ich als "Normalo" nicht direkt Berührungspunkte habe, außer bei Minecraft Vielleicht. ^^"

Es ist ein Framework, welches von vielen (nicht allen) Javaapplikationen verwendet wird. Je nach Version und Applikation kann die Lücke ausgenutzt werden um Schadcode auszuführen und z.B. Daten abgegriffen werden.

Angenommen du bist irgendwo angemeldet und sie setzen Log4J ein, dann sind deine Daten gefährdet. Insofern sind wir 'alle' betroffen. Aber bei dir zu Hause wirst du nichts 'tun müssen'.

sven2.0

2021-12-13, 15:16:14

Joe

2021-12-13, 15:22:03

Sorry für "Offtopic", aber sind da Consumerprodukte von Unify auch betroffen?

Ja.

sei laut

2021-12-13, 15:25:56

Ist eigentlich inzwischen klar, ob der Payload in jedem Fall nachgeladen wird? Ich hab jetzt schon gelesen, dass der Payload auch direkt im Get-Request üebrmittelt werden kann. Dazu finde ich aber keine konkrete Erläuterung oder Poc.

Falls jemand dazu was neues hat, bitte einfach hier rein:)
Das hängt von der Implementierung ab.
Wenn GET Aufrufe als Logmeldungen weg geschrieben werden, ist das sicherlich möglich. Auch als User Agent sehr beliebt.

Ist aber nur ungekochtes Halbwissen. Wir mussten hier bislang nur wenig abdichten, fahren aber auch kaum Java Anwendungen.

Kann ich als Privatperson aktiv etwas tun?
Wenn du gläubig bist, guter Zeitpunkt für Gebete. Gerade was deine Daten anbelangt, die du in der Cloud hast. Aber ansonsten eher nicht. Klar können deine Comsumer Produkte anfällig sein, da solltest du dich nach neuer Firmware umschauen (oder 'produktname log4j', bzw. 'produktname log4shell' suchen und schauen, ob es Hinweise auf die Lücke gibt) und diese rasch einspielen.

Fusion_Power

2021-12-13, 15:38:23

Es ist ein Framework, welches von vielen (nicht allen) Javaapplikationen verwendet wird. Je nach Version und Applikation kann die Lücke ausgenutzt werden um Schadcode auszuführen und z.B. Daten abgegriffen werden.

Angenommen du bist irgendwo angemeldet und sie setzen Log4J ein, dann sind deine Daten gefährdet. Insofern sind wir 'alle' betroffen. Aber bei dir zu Hause wirst du nichts 'tun müssen'.
Ja, selbst im Minecraft-Launcher wird gerade davor gewarnt. Habs mir mal durchgelesen, die haben immerhin flugs nen Update bereit gestellt und somit sollte der Launcher und das Spiel angeblich sicher sein. Mehr fällt mir nicht ein was ich selber an "Java Sachen" habe, den Rest müssen wohl die Hoster und Webseiten Betreiber regeln.

https://www.heise.de/ratgeber/Schutz-vor-schwerwiegender-Log4j-Luecke-was-jetzt-hilft-und-was-nicht-6292961.html

Gute Erklärung
Danke.

Cyv

2021-12-13, 16:06:34

1.x scheinbar auch betroffen. Bisher hab ich dazu aber noch keinen POC gesehen.

https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301

Aber ich weiß nicht wo großflächig der JMS-Appender eingesetzt wird. Wer den nicht nutzt, sollte auch mit einer alten Version vor dieser Lücke erstmal safe sein.
Die 1.X haben dafür einige andere Lücken ;)

Joe

2021-12-13, 17:16:34

Bei Uns in der TUM ging ne ganz gute Zusammenfassung rum heute:

Hintergrund:
Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Sie dient der performanten Aggregation von Protokolldaten einer Anwendung.
Das Blog eines Dienstleisters für IT-Sicherheit berichtet über die Schwachstelle CVE-2021-44228 in log4j in den Versionen 2.0 bis 2.14.1, die es Angreifern gegebenenfalls ermöglicht, auf dem Zielsystem eigenen Programmcode auszuführen und so den Server zu kompromittieren. Diese Gefahr besteht dann, wenn log4j verwendet wird, um eine vom Angreifer kontrollierte Zeichenkette wie beispielsweise den HTTP User Agent zu protokollieren.
Ein Proof-of-Concept (PoC) der Schwachstelle wurde auf Github veröffentlicht und auf Twitter geteilt. Neben dem PoC existieren auch Beispiele für Skripte, die Systeme stichprobenartig auf Verwundbarkeit hin untersuchen. Skripte solcher Art können zwar Administratoren keine Sicherheit über die Verwundbarkeit geben, aber erlauben Angreifern kurzfristig rudimentäre Scans nach verwundbaren Systemen.

Einschätzung:
Diese kritische Schwachstelle hat demnach möglicherweise Auswirkungen auf alle aus dem Internet erreichbaren Java-Anwendungen, die mit Hilfe von log4j Teile der Nutzeranfragen protokollieren.
Im MWN wurde bisher 1x Kompromittierung eines System im Zuge dieser Schwachstelle durch das Security-Monitoring erkannt und das System befindet sich im Remediation-Prozess.
Das BSI vergibt eine „rote“ IT-Bedrohungslage (Stufe 4) [3].

Durchgeführte Erstmaßnahmen:
Seit Bekanntwerden der Schwachstelle registrierten wir einige Exploit-Versuche im Security-Monitoring von MWN-externen IP-Adressen.
Insgesamt wurden bisher ca. 2.500 MWN-Systeme mit CVE-2021-44228 Exploits gescannt.
Diese Ziel-Systeme wurden von uns erneut mit einem log4j-scan [4] von fullhunt.io gescannt. Bei keinem der Systeme konnte laut Scanergebnis die Lücke erfolgreich ausgenutzt werden.

Empfehlungen/Handlungsanweisungen:
1. Verschaffen Sie sich einen Überblick, welche der von Ihnen eingesetzten log4j-Systeme von dieser Lücke betroffen sind.
Hier finden Sie eine Übersicht anfälliger Produkte mit Patch-Status
• https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
• https://github.com/NCSC-NL/log4shell/tree/main/software
• https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
2. Das BSI beschreibt Mitigationsmaßnahmen, die bei anfälligen log4j-System umgesetzt werden sollten [3] (Abschnitt – Maßnahmen).
3. Bei Verdacht auf eine Ausnutzung der Schwachstelle können mit untenstehenden Tools lokale Untersuchungen bei log4j-Systemen durchgeführt werden:
• https://github.com/logpresso/CVE-2021-44228-Scanner
• https://github.com/Neo23x0/log4shell-detector
• https://github.com/hillu/local-log4j-vuln-scanner
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Wird von uns eine weitere erfolgreiche Kompromittierung eines MWN-Systems festgestellt, werden die betroffenen Systemverantwortlichen selbstverständlich zeitnah und
umfassend informiert.
Weitere Details können den Referenzen entnommen werden.

Mit freundlichen Grüßen
MWN/LRZ Abuse Response Team
[1] https://nvd.nist.gov/vuln/detail/CVE-2021-44228
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
[3] https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=6
[4] https://github.com/fullhunt/log4j-scan

littlejam

2021-12-13, 20:15:04

Hat mir auch die Tage versüßt.
Hätte gut Potenzial für große Schäden weltweit ;(

Alles wo vmware drauf steht ist wohl auch betroffen. Die Kisten präsentieren sich aber nicht WAN-Seitig und sind bei uns immer in eigenen VLANS. Also nicht so kritisch.
Nicht WAN/Nicht öffentlich ist leider nur eine trügerische Sicherheit.
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=77707&stc=1&d=1639422359
Ersetze Web server mit VHost und Customer database mit VMWare logging und schon gäbe es möglicherweise Zugriff auf VSphere.
Schon sehr spezielles Beispiel und nicht unbedingt realistisch, aber nicht zu 100% auszuschließen.

Logstash z.B. ist üblicherweise nicht öffentlich, aber auch anfällig.

Grüße
77707

Joe

2021-12-13, 21:17:41

Für interne Dienste haben wir das Szenario am Papier durchexerziert was passiert wenn sich ein User auf seiner Workstation irgend ne Schadsoftware einfängt, die versucht dann diesen Exploit im LAN mit seinen Rechten zu nutzen.

Aber wie gesagt, ich sehs nicht. Anderes Subnetz, anderes VLAN, kein Routing für normale User zwischen den Netzen und vmware weder aus dem Internet erreichbar noch hat es selbst WAN Zugriff abseits von sehr speziellen Firewall regeln für spezifische DNS und NTP Server und noch paar Kleinigkeiten.

Was mir noch bisschen Bauchschmerzen macht sind paar so Appliance Systeme die traditionell schlechte IT machen.
So was wie GIRA Homeserver, Heizungssteuerung / BHKW, PV Datenlogger, EMA und Brandschutz.

So was ist bei Uns eigentlich auch immer in einem speziellen VLAN nur für diesen Dienst mit eigenen Firewall Regeln. Aber bisschen mulmig ist einem Schon, wenn man nicht drauf schaun kann und der Lieferant nicht mal weiß was Du eigentlich jetzt von Ihm willst...

Exxtreme

2021-12-13, 21:55:36

Ja, diese Sicherheitslücke ist echt heftig. Zum Glück verwenden wir keine Uraltversionen von log4j 2. Habe allen Tomcats und dem Payara Server "–Dlog4j2.formatMsgNoLookups=true" verpasst.

Edit: Übrigens, hier gibt es einen Dienst mit dem man die eigenen Anwendungen testen kann:
https://canarytokens.org/generate

Oben Log4Shell auswählen, dann eine E-Mail-Adresse eintragen an die eine Meldung geschickt wird wenn ein Dienst verwundbar ist und dann noch einen Bemerkungstext. Dann bekommt man einen Token mit einer speziellen URL. Diese URL dann nutzen um zu schauen ob etwas verwundbar ist.

Opprobrium

2021-12-14, 10:36:19

Bei Uns in der TUM ging ne ganz gute Zusammenfassung rum heute:
Hui, danke für den Link.

Dadurch konnte ich nachvollziehen, daß es tatsächlich eine ganze Reihe von Angriffsversuche selbst auf meinen kleinen, obskuren Root Server gab :eek:

Soweit ich das nachvollziehen kann bin ich aber wenn dann nur über meinen Hosting Anbieter betroffen, und sensible Daten lagere ich da auch nicht...

Joe

2021-12-14, 11:12:35

Noch eine interessante Konstellation die wir heute hatten:

Webservice läuft auf IIS aber die Apps (iOS und Android) für die Nutzung sind wohl nach ersten Informationen des Herstellers betroffen :freak:

Opprobrium

2021-12-14, 11:31:28

Meine Android App "Box To Go" hat mir gestern folgenden Hinweis gegeben:

erlgrey

2021-12-14, 12:17:38

beim selber testen (egal ob canary token oder eigener dns mit logging) halt bedenken, dass man nicht nur die idp testen sollte. :D

Annator

2021-12-14, 12:26:14

Sorry für "Offtopic", aber sind da Consumerprodukte von Unify auch betroffen? Dann müsste ich mal ein paar Freunden helfen ^^

Und viel Erfolg euch allen, hoffe ihr habt's bald wieder ruhiger.

Der Controller ja. Da müsstest ein Update instalieren. Steht aber schon bereit.

Lurtz

2021-12-14, 16:00:27

Benutzername

2021-12-15, 02:43:05

Kann ich als Privatperson aktiv etwas tun?

Betroffene Software erstmal nicht benutzen ist das einzige, was man tun kann wenn man die Software nur benutzt.

-----------------------------

Finde es interessant, dass wegen dem Ding alle Führungskräfte bei uns durchdrehen, und plötzlich sogar mit strengen Verfügbarkeitsauflagen belegte Systeme Richtung Telematik-Infrastruktur abgeschaltet werden, während es sonst keinen juckt wenn sämtliche CVE-Scans rot sind :rolleyes:

Die CVE Meldungen sind aber nicht in der Tagesschau. Log4j ist ja überall auch auf weniger technischen Seiten. Wenn man log4j einfach mal in die Suchmaschine der Wahl tippt, wirft die dann haufenweise Meldungen raus, die auch ein Manager nicht übersehen kann, weil sie überall sind auch außerhalb der normalen CVEs.

zum Bleistift: https://www.tagesschau.de/inland/bsi-schadsoftware-101.html

oder wie schon erwähnt sogar im Radio.

Bis zum nächsten Mal dann, ist nur eine Frage der Zeit, und gefühlt werden die Abstände immer kürzer...

WIrd es ja auch. software wird immer mehr aus Bausteinen zusammengestöpselt und dann handelt man sich auch alle Fehler ein, die sich in den Bibs befinden. Um das dann abzufangen noch ein Framework oben drauf...

aber hey, Softwarefehler, da kann man nichts machen. Wie bei einem Wirbelsturm. ;)

=Floi=

2021-12-15, 06:47:18

Wobei die grundsätzliche software und hardware immer besser wird. In dem bereich wird schon viel gemacht.

#44

2021-12-15, 07:09:02

Finde es interessant, dass wegen dem Ding alle Führungskräfte bei uns durchdrehen, und plötzlich sogar mit strengen Verfügbarkeitsauflagen belegte Systeme Richtung Telematik-Infrastruktur abgeschaltet werden, während es sonst keinen juckt wenn sämtliche CVE-Scans rot sind :rolleyes:
Absolut. Die 3 Jahre alte Version des DBMS, die wir ausliefern? Wayne.
Win10 Standardinstallationen die wir mit unserem Produkt nicht administriert ins Kundennnetz bringen? Industriestandard.
Die 1-2 Dutzend anderen Libraries? Nie von gehört.

Aber log4shell -> Panik.

Achja. Wir entwickeln .Net Software :rolleyes:

Generell ist IT-Security kein Thema das irgendwie bedacht wird. Nicht einmal die Betriebssicherheit des Produkts ist sichergestellt. Die MA des Kunden könnten theoretisch Doom auf dem Rechner der zum Produkt gehört installieren und zocken und damit die Hauptanwendung in die Knie zwingen - was mindestens zu Serviceaufwand bei uns führen würde. Juckt keinen.

Mein persönlicher Favorit: Unvalidierten Input von Barcodescannern direkt in die DB schreiben. Per String-Konkatenation.
Hab mir erstmal ein paar "'; Drop table XXX"-Barcodes erstellt, als ich das gesehen habe.
Ein bösartiger Akteur könnte damit Millionenschäden beim Kunden verursachen. Im Vorbeigehen.

sei laut

2021-12-15, 09:09:41

Wobei die grundsätzliche software und hardware immer besser wird. In dem bereich wird schon viel gemacht.
Nein. Komplexer wird sie. Bitte nicht mit besser gleichsetzen. ;)
Je länger es Computer gibt, desto größer der Müllberg an Programmcode, der längst entsorgt gehört.

lumines

2021-12-15, 09:17:27

Dadurch konnte ich nachvollziehen, daß es tatsächlich eine ganze Reihe von Angriffsversuche selbst auf meinen kleinen, obskuren Root Server gab :eek:

Sollte nicht überraschen, bei solchen Lücken grasen Angreifer einfach den gesamten IPv4-Adressraum und interessante Ports ab. Was auch immer exploitbar ist, wird exploitet werden. Da spielt es keine Rolle, ob man ein großer oder kleiner Fisch ist.

Joe

2021-12-15, 16:40:51

Wir haben einen neuen Log4J König :ubeer:

Ein DMS System das Kunden häufig im Einsatz haben und dessen Namen ich nicht nennen will, weil mir schon mit Klage gedroht wurde hat heute seine Rundmail rausgehauen. Ja heute.

Insgesamt an 5 Modulen ist der Exploit nutzbar.
Natürlich direkt im Anmeldefeld vom Web Interface.
In der Volltextsuche
In der Anmeldung für den Java Client
In der Anmeldung für die Mobile Apps
Und als absolute KRÖNUNG(!) im Massenimport / Verschlagwortung.

Soll heißen: Workflow hohl sich Daten von SMB/FTP/POP3/IMAP/WEBDAV oder sonst was und wenn da irgendwo ausführbarer Code drin ist, rennt der.

Ich kann eine E-Mail an e-rechnung@.... schreiben - Wird ausgeführt
Ich kann eine E-Mail mit PDF das Ausführbaren Code enthält an e-rechnung@ schreiben - Wird ausgeführt
ich kann eine E-Mail mit einem PDF dass einen QR Code enthält Schreiben - Wird ausgeführt
Ich kann ein Papier mit QR Code Scannen - Wird ausgeführt
Ich kann eine TXT auf eine SMB Freigabe legen - Wird ausgeführt

Am liebsten würd ich den ganzen Saftladen da anzünden!

Tangletingle

2021-12-15, 16:56:07

Openscape tk Anlagen und der ganze anhängende Collaborationwarerotz nutz auch viel Java. Hab für die Anlagen bisher noch keine Nachrichten gefunden. Unify/Atos ist eh der größte Drecksladen den es gibt. Nicht zu verwechseln mit unifi von ubiquiti.

Ahhh: haben doch vorgestern Nacht noch was veröffentlicht.

Hipath DS-Win 4 R6.29.0 and higher (fixed in V4 R6.31.0 / available)
Atos Unify OpenScape UC V10.2.9.0 and higher (fix planned for V10.3.10)
Atos Unify First Response OpenScape Policy Store (fix planned for 01/2022)
Atos Unify OpenScape Voice (simplex deployments, fix for embedded OS UC planned for V10 R2)
Atos Unify OpenScape Contact Center V9 and higher
Atos Unify OpenScape Contact Media Service V9 and higher

Der drops ist gelutscht.

Leonidas

2021-12-16, 16:40:03

https://pbs.twimg.com/media/FGqJogPWUAE-PdT.jpg

Matrix316

2021-12-17, 09:38:04

Interessanter Artikel:

https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Über den Java-Slogan "Write Once, Run Everywhere" wurden schon viele Witze gemacht. Den log4j-Exploit behandeln viele nun wie einen Bug – aber das ist er nicht.

Exxtreme

2021-12-17, 11:16:21

Interessanter Artikel:

https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html

Weil der Autor recht hat. Ein Bug ist dann ein Bug wenn das Verhalten eines Programms vom Soll-Zustand abweicht. Das ist aber nicht der Fall bei log4j2. Dieses Feature ist exakt so gewollt worden und es funktioniert auch so wie sich die Autoren das gedacht haben. Die wollten halt, dass log4j bei einem Logging-Ereignis eine Ressource per jndi aufruft wenn es im Log-Text eine jndi-Adresse findet. Die haben halt nicht weiter gedacht als von der Wand bis zur Tapete.

lumines

2021-12-17, 15:15:28

Die haben halt nicht weiter gedacht als von der Wand bis zur Tapete.

Das gesamte Java-Ökosystem denkt allerdings so.

StevenB

2021-12-17, 18:14:29

Wir haben einen neuen Log4J König :ubeer:

Ein DMS System das Kunden häufig im Einsatz haben und dessen Namen ich nicht nennen will..

Na ja besser als ein Kunde wo sich die eigene IT nicht im klaren war welche Version sie denn einsetzen - blöd nur das die Kollegen immer wieder auf "Alle Antworten" geklickt haben, dass lässt tief Blicken.. wir konnten alles mitlesen.

Offline genommen haben wir das Projekt dennoch für den Zeitraum der "Prüfung".

myMind

2021-12-17, 21:02:47

Das gesamte Java-Ökosystem denkt allerdings so.
Das ist aber ein sehr harsches Urteil.

So wie ich das sehe ist das log4j Problem eher Featuritis. Und die ist nicht auf Java beschränkt. In Kombination mit Geltungsbedürfnis (per Default aktiviert).

Klar, Java ist schon speziell. Sehr geil neulich in einem Thread bei Heise: AbstractSingletonProxyFactoryBean (https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html). Da kommt man doch aus dem Lachen nicht mehr heraus. Es gibt einfach nichts, wo man in Java nicht noch einen Wrapper, nicht noch eine Abstraktionsschicht drum herum bauen würde. Insofern teile ich den kritischen Blickwinkel.

Anderseits muss man auf der Habenseite auch anerkennen, dass es in anderen Sprachen für bestimmte komplexe Problemstellungen mit Wunsch nach transaktionaler Sicherheit, praktisch keine Alternativen gibt. Zumindest keine, bei denen ich persönlich ruhig schlafen könnte.

Anders gefragt: Was wäre denn besser? Und warum?

lumines

2021-12-18, 11:56:22

Na ja besser als ein Kunde wo sich die eigene IT nicht im klaren war welche Version sie denn einsetzen - blöd nur das die Kollegen immer wieder auf "Alle Antworten" geklickt haben, dass lässt tief Blicken.. wir konnten alles mitlesen.

Du interpretierst da einiges rein. Es ist tatsächlich nicht ganz trivial rauszubekommen, welche Version benutzt wird, wenn man die Library nicht selbst verwendet und sie als transitive Abhängigkeit indirekt über z.B. ein Framework importiert hat. Bei größeren Projekten kann das schnell zu einem Problem werden, das man manuell nur schwierig überblicken kann.

Eine einfache Lösung ist das Vergleichen der Hashwerte betroffener Libraries, z.B. wie dieser Scanner es macht: https://github.com/hillu/local-log4j-vuln-scanner

Kannst du dir aber sicher sein, dass nicht irgendein Projekt eine selbstkompilierte und eventuell modifizierte Version verwendet, bei der dieser Scanner dann fehlschlägt? Bei Logging-Libraries würde mich das nicht überraschen, auch wenn ich es selbst so nicht gesehen habe.

Anders gefragt: Was wäre denn besser? Und warum?

Es geht nicht darum, dass irgendeine konkrete Technologie besser ist, sondern dass speziell in der Java-Welt unüberblickbare Abstraktionen verwendet werden, welche die darunterliegende Komplexität nur verschleiern, aber nie komplett verbergen können. Das kann gut gehen, wenn diese Abstraktionen gut verstanden und gepflegt werden. Man kann natürlich real davon profitieren und das ist ja auch genau der Grund, warum es gemacht wird. Gerade in der Java-Welt funktioniert es aber nicht so gut, wie man es sich wünschen würde. Ganz vorsichtig gesagt.

Ich sehe hier aber auch das Problem, dass viele Unternehmen blind für Komplexität und falsche Abstraktionen sind. Generell hat das Wort "Komplexität" für viele Unternehmen im Kontext von Software nicht einmal eine klare Bedeutung.

StevenB

2021-12-18, 12:16:49

Du interpretierst da einiges rein. Es ist tatsächlich nicht ganz trivial rauszubekommen, welche Version benutzt wird, wenn man die Library nicht selbst verwendet und sie als transitive Abhängigkeit indirekt über z.B. ein Framework importiert hat. Bei größeren Projekten kann das schnell zu einem Problem werden, das man manuell nur schwierig überblicken kann.

In meiner Aussage war vielleicht etwas zu viel Frust enthalten. Die Erfahrung der letzten Jahre mit dem Kunden waren aber von einem ähnlichen Chaos geprägt.

Vielleicht war aber auch meine Erwartungshaltung zu hoch angesetzt. Namen darf ich natürlich nicht nennen, aber von einem Konzern in der Größe habe ich tatsächlich eine schnellere Reaktion sowie gute Doku erwartet.

Sephiroth

2021-12-18, 14:31:46

Du interpretierst da einiges rein. Es ist tatsächlich nicht ganz trivial rauszubekommen, welche Version benutzt wird, wenn man die Library nicht selbst verwendet und sie als transitive Abhängigkeit indirekt über z.B. ein Framework importiert hat. Bei größeren Projekten kann das schnell zu einem Problem werden, das man manuell nur schwierig überblicken kann.

Da empfiehlt sich der Einsatz von Analyse-Tools wie CycloneDX software bill of materials (https://cyclonedx.org/). Die Ergebnisse kann man dann in Systeme wie Dependency-Track (https://dependencytrack.org/) hochladen und man bekommt eine Übersicht verwendeter Abhängigkeiten und von welchen bekannten Schwachstellen man betroffen sein könnte - auch nachträglich, weil diese täglich aktualisiert wird. Gibt natürlich auch andere wie zum Beispiel Snyk (https://snyk.io/) oder JFrog Xray (https://jfrog.com/de/xray/).

lumines

2021-12-21, 09:48:52

Da empfiehlt sich der Einsatz von Analyse-Tools wie CycloneDX software bill of materials (https://cyclonedx.org/). Die Ergebnisse kann man dann in Systeme wie Dependency-Track (https://dependencytrack.org/) hochladen und man bekommt eine Übersicht verwendeter Abhängigkeiten und von welchen bekannten Schwachstellen man betroffen sein könnte - auch nachträglich, weil diese täglich aktualisiert wird. Gibt natürlich auch andere wie zum Beispiel Snyk (https://snyk.io/) oder JFrog Xray (https://jfrog.com/de/xray/).

Ja, normalerweise würde ich auch davon ausgehen, dass die meisten großen Unternehmen alleine aus Selbsterhaltungszwecken ihre Abhängigkeiten so tracken. Wenn man aber danach geht, wie verbreitet log4j 1.x noch ist, kann das entweder nicht der Fall sein oder es wird zwar getrackt, aber niemand kümmert sich darum, dass die Abhängigkeiten auch tatsächlich gepflegt werden.