Moin!
Ich bin eben über folgenden Artikel gestolpert: https://www.lunasec.io/docs/blog/log4j-zero-day/
TL;DR: Wenn man log4j2 benutzt, und irgendwelche Sachen loggt, die ein potentieller Angreifer gesendet hat, dann sollte man dringend auf Version 2.15.0 updaten oder eine der angegebenen Mitigations anwenden.
Das könnte einen signifikanten Anteil aller in Java geschriebener Server-Software betreffen.
Grüße, Jan
Am 10.12.21 um 12:14 schrieb Jan Niehusmann:
Moin!
N'abend!
Ich bin eben über folgenden Artikel gestolpert: https://www.lunasec.io/docs/blog/log4j-zero-day/
TL;DR: Wenn man log4j2 benutzt, und irgendwelche Sachen loggt, die ein potentieller Angreifer gesendet hat, dann sollte man dringend auf Version 2.15.0 updaten oder eine der angegebenen Mitigations anwenden.
Das könnte einen signifikanten Anteil aller in Java geschriebener Server-Software betreffen.
Nach dem, was man mittlerweile so liest, stimmt das. Und: die gaaanz Großen sind dabei, nicht nur die "Excellenz" ;-)
Leider sind tatsächlich auch Systeme bei uns betroffen und ein prominentes haben wir temporär aus der Schußlinie genommen.
Insgesamt ist die Bedrohungssituation aber überschaubar.
Weltweit wird ca. von 150 scannenden Systemen berichtet, der hier gesehene Anteil liegt derzeit bei <50 Angreifern, dies Gesamtzahl gesehener "Events" ist auch noch <100.
Dazu muß man folgendes anmerken:
a) wir sehen nur HTTP, also keine Angriffe auf HTTPS, da wir derzeit nur 1 (in Worten: eins) System haben, beim dem HTTPS in der Firewall deep inspected werden kann.
b) wir sehen es überhaupt, weil unser Firewallhersteler gegen 14:00 begann, entsprechende Signaturen ("Situations") bereitzustellen (es gab noch zwei Updates danach)
c) neben dem oben erwähnten "prominentem" System gehen wir von einer größeren Zahl dem IT Center nur teils bekannter Systeme in der RWTH aus
Es wurde folgendes umgesetzt:
Systeme, die die Signaturen triggern, werden für einen Tag geblacklistet.
Die bisher gesehene IP der "ldap URL", die zum Code Nachladen benutzt wird, ist für eine Woche auf der Blacklist.
Grüße, Jan
Gruß, Jens
<private>wann gehen wir zwei endlich mal wieder ein Bierchen trinken?</private>
Hallo zusammen,
kann hier jemand sagen, ob auch die LibLog4Shib2, also eine C++ Implementation welche sich stark an der LibLog4J orientiert und in der Shibboleth Anbindung eingesetzt wird (vermutlich häufiger in der RWTH) auch von der Lücke betroffen ist. Hier haben wir nämlich aktuell ein Fragezeichen im Gesicht...
Mit besten Grüßen,
Andre
-----Ursprüngliche Nachricht----- Von: Jens Hektor hektor@itc.rwth-aachen.de Gesendet: Samstag, 11. Dezember 2021 00:05 An: rwth-security@lists.rwth-aachen.de Betreff: [rwth-security] Re: RCE-Lücke in Log4j <2.15.0
Am 10.12.21 um 12:14 schrieb Jan Niehusmann:
Moin!
N'abend!
Ich bin eben über folgenden Artikel gestolpert: https://www.lunasec.io/docs/blog/log4j-zero-day/
TL;DR: Wenn man log4j2 benutzt, und irgendwelche Sachen loggt, die ein potentieller Angreifer gesendet hat, dann sollte man dringend auf Version 2.15.0 updaten oder eine der angegebenen Mitigations anwenden.
Das könnte einen signifikanten Anteil aller in Java geschriebener Server-Software betreffen.
Nach dem, was man mittlerweile so liest, stimmt das. Und: die gaaanz Großen sind dabei, nicht nur die "Excellenz" ;-)
Leider sind tatsächlich auch Systeme bei uns betroffen und ein prominentes haben wir temporär aus der Schußlinie genommen.
Insgesamt ist die Bedrohungssituation aber überschaubar.
Weltweit wird ca. von 150 scannenden Systemen berichtet, der hier gesehene Anteil liegt derzeit bei <50 Angreifern, dies Gesamtzahl gesehener "Events" ist auch noch <100.
Dazu muß man folgendes anmerken:
a) wir sehen nur HTTP, also keine Angriffe auf HTTPS, da wir derzeit nur 1 (in Worten: eins) System haben, beim dem HTTPS in der Firewall deep inspected werden kann.
b) wir sehen es überhaupt, weil unser Firewallhersteler gegen 14:00 begann, entsprechende Signaturen ("Situations") bereitzustellen (es gab noch zwei Updates danach)
c) neben dem oben erwähnten "prominentem" System gehen wir von einer größeren Zahl dem IT Center nur teils bekannter Systeme in der RWTH aus
Es wurde folgendes umgesetzt:
Systeme, die die Signaturen triggern, werden für einen Tag geblacklistet.
Die bisher gesehene IP der "ldap URL", die zum Code Nachladen benutzt wird, ist für eine Woche auf der Blacklist.
Grüße, Jan
Gruß, Jens
<private>wann gehen wir zwei endlich mal wieder ein Bierchen trinken?</private>
Moin,
On Mon, Dec 13, 2021 at 06:01:07AM +0000, Stollenwerk, André wrote:
kann hier jemand sagen, ob auch die LibLog4Shib2, also eine C++ Implementation welche sich stark an der LibLog4J orientiert und in der Shibboleth Anbindung eingesetzt wird (vermutlich häufiger in der RWTH) auch von der Lücke betroffen ist. Hier haben wir nämlich aktuell ein Fragezeichen im Gesicht...
Ich kann im Quellcode keinerlei Anzeichen finden, dass dort ein ähnlicher Mechanismus implementiert ist, der angreifbar sein könnte.
Insbesondere ist der Umgang mit einem %m-Pattern ziemlich einfach gehalten:
struct MessageComponent : public PatternLayout::PatternComponent { virtual void append(std::ostringstream& out, const LoggingEvent& event) { out << event.message; } };
Also nichts von wegen JNDI, kein Replacement irgendwelcher Pattern im zu loggenden Event - schaut sauber aus.
(Das soll keine Aussage zur Sicherheit dieser Library insgesamt sein - ich kenne sie einfach nicht und habe mir nur diese eine Stelle angeschaut.)
Grüße, Jan
Hallo,
es gibt auch die Shibboleth Announcement Mailing Liste (announce@shibboleth.net).
Auf dieser gab es folgende Meldung:
We’re getting a lot of noise about this, just trying to save more emails here.
Shibboleth does not use log4j. We ship a bridge for it to slf4j but that's not vulnerable, the bug is in log4j itself. We allow (in theory) the IdP to be manipulated to log to log4j through the slf4j API but we don't ship that or provide any code or examples for doing that.
The Jetty on Windows package is equipped with logback for logging, not log4j.
Otherwise, we have nothing to do with the servlet container configuration and logging choices you yourselves may or may not have made, or any other packaging of our software that may include log4j from other sources, that's outside our scope as a project.
-- Scott
Viele Grüße
Frank
On 13.12.21 07:29, Jan Niehusmann wrote:
Moin,
On Mon, Dec 13, 2021 at 06:01:07AM +0000, Stollenwerk, André wrote:
kann hier jemand sagen, ob auch die LibLog4Shib2, also eine C++ Implementation welche sich stark an der LibLog4J orientiert und in der Shibboleth Anbindung eingesetzt wird (vermutlich häufiger in der RWTH) auch von der Lücke betroffen ist. Hier haben wir nämlich aktuell ein Fragezeichen im Gesicht...
Ich kann im Quellcode keinerlei Anzeichen finden, dass dort ein ähnlicher Mechanismus implementiert ist, der angreifbar sein könnte.
Insbesondere ist der Umgang mit einem %m-Pattern ziemlich einfach gehalten:
struct MessageComponent : public PatternLayout::PatternComponent { virtual void append(std::ostringstream& out, const LoggingEvent& event) { out << event.message; } };Also nichts von wegen JNDI, kein Replacement irgendwelcher Pattern im zu loggenden Event - schaut sauber aus.
(Das soll keine Aussage zur Sicherheit dieser Library insgesamt sein - ich kenne sie einfach nicht und habe mir nur diese eine Stelle angeschaut.)
Grüße, Jan _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Hallo zusammen,
wenn ich das richtig sehe, ist der Backup-Client auch betroffen:
rpm -qlp TIVsm-BA.x86_64.rpm |grep log4j
/opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-api-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-core-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-jcl-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-slf4j-impl-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j.properties
Sollte ich mir deswegen Sorgen machen, oder ist das unproblematisch, weil der eh nur mit den ITC-Servern spricht? Irgendwie habe ich das Problem noch nicht mit all seinen Facetten verstanden.
Generell wird als Mitigation empfohlen, die Systemeigenschaft "log4j2.formatMsgNoLookups" auf “true” zu setzen, aber wo mache ich das in dem Fall?
Danke und Grüße, René
[1] https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/cli...
Am 11.12.21, 00:05 schrieb "Jens Hektor" hektor@itc.rwth-aachen.de:
Am 10.12.21 um 12:14 schrieb Jan Niehusmann: > Moin!
N'abend!
> Ich bin eben über folgenden Artikel gestolpert: > https://www.lunasec.io/docs/blog/log4j-zero-day/ > > TL;DR: Wenn man log4j2 benutzt, und irgendwelche Sachen loggt, die ein > potentieller Angreifer gesendet hat, dann sollte man dringend auf > Version 2.15.0 updaten oder eine der angegebenen Mitigations anwenden. > > Das könnte einen signifikanten Anteil aller in Java geschriebener > Server-Software betreffen.
Nach dem, was man mittlerweile so liest, stimmt das. Und: die gaaanz Großen sind dabei, nicht nur die "Excellenz" ;-)
Leider sind tatsächlich auch Systeme bei uns betroffen und ein prominentes haben wir temporär aus der Schußlinie genommen.
Insgesamt ist die Bedrohungssituation aber überschaubar.
Weltweit wird ca. von 150 scannenden Systemen berichtet, der hier gesehene Anteil liegt derzeit bei <50 Angreifern, dies Gesamtzahl gesehener "Events" ist auch noch <100.
Dazu muß man folgendes anmerken:
a) wir sehen nur HTTP, also keine Angriffe auf HTTPS, da wir derzeit nur 1 (in Worten: eins) System haben, beim dem HTTPS in der Firewall deep inspected werden kann.
b) wir sehen es überhaupt, weil unser Firewallhersteler gegen 14:00 begann, entsprechende Signaturen ("Situations") bereitzustellen (es gab noch zwei Updates danach)
c) neben dem oben erwähnten "prominentem" System gehen wir von einer größeren Zahl dem IT Center nur teils bekannter Systeme in der RWTH aus
Es wurde folgendes umgesetzt:
Systeme, die die Signaturen triggern, werden für einen Tag geblacklistet.
Die bisher gesehene IP der "ldap URL", die zum Code Nachladen benutzt wird, ist für eine Woche auf der Blacklist.
> Grüße, > Jan
Gruß, Jens
<private>wann gehen wir zwei endlich mal wieder ein Bierchen trinken?</private>
Hallo,
aufgrund einer von log4j unabhängigen Lücke werden die TSM Server gerade gepatcht. Genauso gibt es eine Update Empfehlung der Clients auf die Version 8.1.13 wegen eines anderen Issue (https://www.ibm.com/support/pages/node/6524706?myns=swgtiv&mynp=OCSSEQVQ...) Unabhängig davon haben wir eine Anfrage zu Thema log4j an IBM gestellt, da es zur Zeit noch keine Warnung (aber eben auch keine Entwarnung) von IBM gibt. Wir werden uns Auf jeden Fall hier noch einmal melden, wenn es Neuigkeiten zu dem Thema gibt.
Gruß
Hallo Zusammen,
wir haben die TSM-Pakete in unserem Repo [1] entsprechend aktualisiert. Diese stehen jetzt zum Update bereits. Falls unser Repo nicht bekannt ist, haben wir unter [2] alle Informationen zusammengestellt. Seit einiger Zeit stehen auch Bullseye-Quellen zur Verfügung.
Viele Grüße Hinrikus Wolf
[1] https://repo.fsmpi.rwth-aachen.de [2] https://wiki.informatik.rwth-aachen.de/doku.php?id=it_best_practise:backup:d...
On 13.12.21 11:21, Jansen, Jonas wrote:
Hallo,
aufgrund einer von log4j unabhängigen Lücke werden die TSM Server gerade gepatcht. Genauso gibt es eine Update Empfehlung der Clients auf die Version 8.1.13 wegen eines anderen Issue (https://www.ibm.com/support/pages/node/6524706?myns=swgtiv&mynp=OCSSEQVQ...) Unabhängig davon haben wir eine Anfrage zu Thema log4j an IBM gestellt, da es zur Zeit noch keine Warnung (aber eben auch keine Entwarnung) von IBM gibt. Wir werden uns Auf jeden Fall hier noch einmal melden, wenn es Neuigkeiten zu dem Thema gibt.
Gruß
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
Hi,
auf github gibts eine Übersicht über betroffene Systeme nach Herstellern sortiert:
https://github.com/cisagov/log4j-affected-db
Ist als "work in progress" gekennzeichnet.
Die Scans danach (zumindest via HTTP) haben deutlich abgenommen und haben vor allem keine richtig hohe Intensität.
Ein Großteil der Scans fällt aus TOR Exitnodes, insbesondere aus deutschen bei Artikel 10 e.V. :-/
Gruß, Jens Hektor
Hallo zusammen,
mittlerweile gibt es ein Stellungnahme von IBM inwiefern Spectrum Protect aka TSM von dem Log4j Problem betroffen ist [0]. Glücklicherweise ist nach aktuellen Erkenntnissen nur der Webclient (neben den Komponenten zur direkten VMware Sicherung), der sehr wenig genutzt wird, betroffen. Im Link findet sich eine Anleitung um die Library auszutauschen. Ich empfehle dies auch zu tun, wenn der Webclient nicht aktiv genutzt wird.
[0] https://www.ibm.com/support/pages/node/6527080
Gruß
rwth-security@lists.rwth-aachen.de
-
admin (Frank Knoben) -
Hinrikus Wolf -
Jan Niehusmann -
Jansen, Jonas -
Jens Hektor -
Stollenwerk, André -
Xhonneux, René