12.12.2021, aktualisiert am 15.12.2021

16197

Log4j Sicherheitslücke kleiner V2.15 Kategorie 4 CVE-2021-44228

Hallo zusammen,

die Versionen von Log4j < 2.15 sind gegen eine Schwachstelle vulnerabel. Das BSI hat die Sicherheitslücke als Kategorie 4 eingestuft. Sie ist sehr leicht ausnutzbar.

Hier noch ein paar Links dazu:

cve.mitre.org CVE-2021-44228

CVE-2021-44228 Log4J-Lücke bedroht Minecraft und viele weitere Anwendungen
Warnstufe Rot: Log4j-Zero-Day-Lücke bedroht Heimanwender und Firmen
Schutz vor schwerwiegender Log4j-Lücke - was jetzt hilft und was nicht

lg
Theo

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-Key: 1611160059

Url: https://administrator.de/contentid/1611160059

Ausgedruckt am: 20.04.2024 um 08:04 Uhr

72 Kommentare

Neuester Kommentar

<satire>Dann können wir ja mal davon ausgehen, dass es im medizinischen Bereich schnellstens Update geben wird. Also in ca. 6-8 Monaten.</satire>

Danke für den Post. Ich kam leider noch nicht dazu. Die Lücke fackelt schon seit zwei Tagen fleißig im Netz und es ist eine Fülle von Diensten betroffen (Stand jetzt). Das Ausmaß ist noch gar nicht abzusehen.

Hier mal ein kurzer Überblick, welche - prominenten - Dienste schon jetzt bekannt sind:

https://github.com/YfryTchsGD/Log4jAttackSurface#the-list

Für die Kollegen, die VMWare einsetzen, dürfte ein bisschen Arbeit anstehen...

Stay tuned!

Viele Grüße, commodity

Ich freu mich. Weihnachten gerettet

Und wenn man noch bedenkt, wie wie viele Apaches auf „irgendwelchen“ Firewalls/ UTMs zum Einsatz kommen…

Nein, der Webserver Apache ist nicht betroffen. Bitte erst die Feeds lesen, dann klagen

Aber das, was betroffen ist, dürfte für die nächsten Wochen reichen.

Viele Grüße, commodity

Moin,

Nein, der Webserver Apache ist nicht betroffen. Bitte erst die Feeds lesen, dann klagen

face-wink

Wer sagt, dass @em-pie den Apache HTTP Server meint?

Der HTTP Server ist ja nur ein Produkt von vielen von der Apache Software Foundation.
Und von der Lücke sind einige Apache Produkte betroffen. Insofern hat er da durchaus recht.

MfG

Zitat von @commodity:

Danke für den Post. Ich kam leider noch nicht dazu. Die Lücke fackelt schon seit zwei Tagen fleißig im Netz und es ist eine Fülle von Diensten betroffen (Stand jetzt). Das Ausmaß ist noch gar nicht abzusehen.

Hier mal ein kurzer Überblick, welche - prominenten - Dienste schon jetzt bekannt sind:

https://github.com/YfryTchsGD/Log4jAttackSurface#the-list

Für die Kollegen, die VMWare einsetzen, dürfte ein bisschen Arbeit anstehen...

Stay tuned!

Viele Grüße, commodity

Ich frage mich ernsthaft, in welchem dunklen Szenarien VMware Hosts / VCenter Appliances von solchen Angriffen betroffen sein könnten. (?)

Natürlich sollten die Patches schnellstmöglich eingespielt werden, das steht außer Frage.
Ich bin dennoch der Meinung, dass das Risiko schwindend gering ist, wenn alle anderen Maßnahmen umgesetzt sind (Netztrennung, Isolierung, 802.1x, etc. pp.). Den ausgebrannten und bereits gekündigten Administrator mit 2 Häusern und 15 Kindern lasse ich als inneren Angreifer jetzt mal außen vor.

Gibt es Angriffsmöglichkeiten die ich evtl. nicht bedacht habe?

Zitat von @148848:
Wer sagt, dass @em-pie den Apache HTTP Server meint?

... von der Lücke sind einige Apache Produkte betroffen.

In einem Forum kann man natürlich faktenfern bleiben. Wenn Techniker über Sicherheit reden, finde ich das aber bedenklich. Wenn Du die Liste der betroffenen Apache-Software gelesen/verstanden hättest, würdest Du nicht so einen oberflächlichen Nonsens schreiben. Keine der betroffenen Apache-Software - Apache Solr, Apache Druid, Apache Flink oder Apache Struts2 sehe ich auf einer Firewall. Webserver hingegen alle Tage. Geht das nur mir so? Was also wird der Kollege @em-pie gemeint haben? Ist doch auch gar nicht schlimm. Ist ja Sonntag.

Ich mag mich irren. Korrigier mich gern, wenn Du einen Anwendungsfall für eine Firewall kennst. Ich lerne immer gern dazu. Aber bitte nicht faktenfrei

Ist zwar derzeit modern, hat aber in der IT nichts zu suchen. Voodoo ist woanders.

Viele Grüße, commodity

Tatsächlich hab ich fälschlicherweise den Webserver im Kopf gehabt. Muss aber zu meiner „Verteidigung“ sagen: den Artikel hatte ich bereits weit vor diesem Thread gelesen und mir scheinbar nur „Apache“ behalten.

Asche auf mein Haupt. Ich werd besser mal zum Hausmeister umschulen

Lass mal em-pie, ich hab es auch erst auf den Apache Webserver bezogen und dann nochmal schnell den Betreff geändert 😁

Weil es nicht in der Liste ist... es betrifft zum Beispiel auch Kommerzielle Asterisk Voip anlagen ;)...

Moin,

VMWare hat hier u.a. einen Workaround für das vCenter veröffentlicht :
https://kb.vmware.com/s/article/87081?lang=en_US

Gruß

Looser

Edit:

Hier noch die Liste von der HP von vmware:
https://www.vmware.com/security/advisories/VMSA-2021-0028.html

Zitat von @themuck:

Weil es nicht in der Liste ist... es betrifft zum Beispiel auch Kommerzielle Asterisk Voip anlagen ;)...

Zumindest 3CX sagt "Nein, kein Java und deshalb auch kein log4j"

Manuel

Unifi hat bereits ein Update veröffentlicht für die betroffene Controller-Software.

Zitat von @themuck:

Weil es nicht in der Liste ist... es betrifft zum Beispiel auch Kommerzielle Asterisk Voip anlagen ;)...

Bitte präziser. Diese Info, selbst wenn es zutreffen würde, viel zu pauschal.

- Fundstelle?
- Kontext?

Starface prüft gerade, ob deren Anlagen in den unterschiedlichen Versionsständen betroffen sind.

Zitat von @commodity:

Zitat von @themuck:

Weil es nicht in der Liste ist... es betrifft zum Beispiel auch Kommerzielle Asterisk Voip anlagen ;)...

Bitte präziser.

- Fundstelle?
- Kontext?

Viele Grüße, commodity

https://www.pascom.net/forum/t/official-information-on-log4j-security-vu ...

Zitat von @em-pie:
Asche auf mein Haupt.

Quatsch, passiert doch jedem hier mal auf die schnelle. Wollte nur vermeiden, dass sich Panikmeldungen verbreiten.

Viele Grüße, commodity

Zitat von @themuck:

Zitat von @commodity:

Zitat von @themuck:

Weil es nicht in der Liste ist... es betrifft zum Beispiel auch Kommerzielle Asterisk Voip anlagen ;)...

Bitte präziser.

- Fundstelle?
- Kontext?

Viele Grüße, commodity

https://www.pascom.net/forum/t/official-information-on-log4j-security-vu ...

Das betrifft aber erstmal nur deren Anlagen und sollte nicht verallgemeinert werden. Die anderen Hersteller werden sich schon noch äußern.

Zitat von @themuck:
https://www.pascom.net/forum/t/official-information-on-log4j-security-vu ...

Danke, ich sehe allerdings nur eine Anlage. Mehr?

Anmerkung: Es wird noch ganz viel hochkommen. Pauschale Posts bringen nichts. Arbeiten können wir nur mit präzisen Infos.

Viele Grüße, commodity

Ergänzung zur obigen Liste: Die auch bei Heise verlinkte advisory-list (wird fortlaufend aktualisiert):

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Viele Grüße, commodity

Zitat von @commodity:

Anmerkung: Es wird noch ganz viel hochkommen. Pauschale Posts bringen nichts. Arbeiten können wir nur mit präzisen Infos.

Viele Grüße, commodity

Das ist mir schon klar... ich wollte eigentlich nur dazu anregen das Leute die so eine Anlage betreiben einfach nach schauen was ihr Anbieter dazu sagt... Eventuell hat man sowas ja nicht sofort auf dem Schirm.

ElasticSearch ist im übrigen dahingehend "interessant", da es die erweiterte Suchfunktion vieler Wikis ist.

Zumindest bin ich in dem Kontext auf ElasticSearch aufmerksam geworden, bin mir aber ziemlich sicher, dass es nicht nur in den verschiedenen Wikis zum Einsatz kommt.

Also auch eine Auge auf die Systeme haben, die zwar nicht direkt irgendwo gelistet werden, aber aufgeführte Dienste als Bausteine "unter der Haube" einsetzen...

Hallo,

angeblich ist ES nicht bedroht.
https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vul ...

Zitat von @StefanKittel:

Hallo,

angeblich ist ES nicht bedroht.
https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vul ...

Mal im Auge behalten...

@all.
Hier noch ein Dokument des BSI
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/202 ...

Also ich weiß ja was hier so im Netzwerk werkelt und das hänge ich zur Not einfach vom Internet ab bis es gepatcht ist bzw. gar nicht erst ans Internet dran, wie sich das gehört. Aber sagt mal was macht ihr mit euren "Cloud Services" die ihr irgendwo einkauft, schreibt ihr die alle an? Ist ja nicht so das ich da einfach den Stecker ziehen könnte bis ich weiß was Sache ist und noch hat sich keiner meiner Anbieter bei mir gemeldet.

Stellungnahme Lancom

https://www.lancom-systems.de/service-support/soforthilfe/allgemeine-sic ...

Hallo Zusammen,

ich denke die wenigsten hier werden direkt von der Lücke betroffen sein. Mich würde aktuell besonders interessieren wie schätzt ihr die Gefahr ein, indirekt betroffen zu sein... z.B. wenn einer eurer Anwender/Clients eine Web-Application auf einem externen kompromitierten Server nutzt und sich über diesen indirekten Weg mit was auch immer infiziert??

Grüße I.

groß. Wie Kollege @StefanKittel oben schon schrieb: Bei der Arztsoftware ist in einigen Monaten mit einer Reaktion zu rechnen... Lob aber an CGM-Turbomed: Die haben auf konkrete Anfrage binnen kurzer Zeit eine Zwischennachricht gesendet. Alle anderen Angefragten: Schweigen im Walde.

Und ich war auch schon direkt betroffen. Aber nur der Minecraft-Server für die Kids

Freitag Abend schon geschlossen.

Viele Grüße, commodity

Die größte Gefahr war/ist für uns WebEx. Wird viel genutzt und soweit ich herausgefunden habe bereits gepatched. Alle anderen Dienste sind intern.

Gruß Looser

Alle anderen Dienste sind intern.

Glück gehabt.

Keine Update-Server?

Viele Grüße, commodity

Keine Update-Server?

Zumindest keine, die bislang auf irgendwelchen Listen stehen.

Habt ihr den VCenter Workaround schon implementiert? Läuft danach noch alles?
VCenter einfach abschalten ist jetzt nicht das was ich unbedingt will. Es läuft dann einfach auch kein Backup mehr.

Unser VCenter ist natürlich nicht von außen erreichbar. Auch ist auch sonst kein Server mehr von außen erreichbar.
--> Was wäre denn ein mögliches Szenario?

Ich habe den Workaround am vCenter gemacht. Bisher läuft alles noch.

Hi,

Zitat von @IceAge:
ich denke die wenigsten hier werden direkt von der Lücke betroffen sein. Mich würde aktuell besonders interessieren wie schätzt ihr die Gefahr ein, indirekt betroffen zu sein...

Wie seht ihr das? Server hinter firewall die nicht betroffen ist.
Intene User könnten durchaus probieren.
Bzw. Server der aus dem Internet Daten abfragt.

Sg Dirm

Zitat von @Dirmhirn:
Wie seht ihr das? Server hinter firewall die nicht betroffen ist.
Intene User könnten durchaus probieren.
Bzw. Server der aus dem Internet Daten abfragt.

Jo, stimmt. Muss man wohl im Moment am Schutzlevel ausrichten. Ich verkaufe ner 20-m/f/d-Bürobutze jetzt keinen Hochsicherheitsbereich mit internem Layer7-Filtering (was auch nur sehr begrenzt hülfe). Im vertretbaren Rahmen Schutzlevel hochfahren, ansonsten beobachten (lassen). Und Backup, Backup, Backup. Dennoch kein gutes Gefühl. Aber bange machen bringt auch nichts.

Was sagen denn die teuren UTM-Hersteller? Das wäre doch mal ein usecase...

Viele Grüße, commodity

Was sagen denn die teuren UTM-Hersteller? Das wäre doch mal ein usecase...

Lancom s.o.

Zitat von @Looser27:
Lancom s.o.

Nee, das hast Du falsch verstanden. Die sollen nicht (nur) sagen, ob oder dass sie (nicht) betroffen sind,
die sollen beschützen.
Ist doch ihre Aufgabe. Oder hab ich da was verwechselt und es geht mehr ums Kassieren als ums Beschützen?

Viele Grüße, commodity

Heißt das Vorhandensein eines entsprechenden Codestrings, dass der Versuch erfolgreich war, oder dass es ein Versuch war. Ist eine Spielmaschine, gut abgesichert, und nach aktuellem Stand nicht mit gefährdeter Software bestückt.

"Experten warnten, dass nicht nur Online-Systeme gefährdet seien. Auch etwa ein QR-Scanner oder ein kontaktloses Türschloss könnten angegriffen werden, wenn sie Java und Log4j benutzten, betonte Cloudflare."

Tagesschau.de

Ja das ist mir bekannt, es gibt 10000 offene Tore.

Wie erkenne ich aber, ob es nur ein Scan oder tatsächlich erfolgreich war... s. Frage

Zitat von @IceAge:

Hallo Zusammen,

ich denke die wenigsten hier werden direkt von der Lücke betroffen sein. Mich würde aktuell besonders interessieren wie schätzt ihr die Gefahr ein, indirekt betroffen zu sein... z.B. wenn einer eurer Anwender/Clients eine Web-Application auf einem externen kompromitierten Server nutzt und sich über diesen indirekten Weg mit was auch immer infiziert??

Grüße I.

Die indirekte Betroffenheit wird sich wahrscheinlich nicht sofort zeigen. Das BSI rechnet aber z.B. damit, dass riesige Botnetze gespannt werden. Die Angriffe die dann folgen, werden wahrscheinlich eklig (Spam und Ransomware Wellen, DDoS, etc.)

Die ersten Angriffe sind bei mir gestern schon verzeichnet (aber durch IPS geblockt) worden - also am Sonntag - denkbar schlechte Ausgangssituation für andere Netzwerke.

Moin,

Hier mal ein aktualisierter Überblick vom NL-NCSC. Software von A-Z

:

https://github.com/NCSC-NL/log4shell/tree/main/software

Viele Grüße, commodity

Hat schon jemand Informationen von APC erhalten? Deren VM-Appliance läuft mit v2.13.
Ist bei uns zwar hinter der Firewall, aber man weiß ja nie.......

Auf deren Homepage steht bis dato nichts.

Verbiete ihr einfach das Connecten nach außen, dann sollte die bestehende Verwundbarkeit kein Problem sein (solange der Angriff nicht von innen kommt). Aber in Dein Management-Lan kommt ja auch keiner so ohne Weiteres.

Viele Grüße, commodity

Zitat von @Looser27:

Starface prüft gerade, ob deren Anlagen in den unterschiedlichen Versionsständen betroffen sind.

Moin,

gibt's hierzu was Neues?

SQL Server 2019, hier gibt es auch die Version 1.2.17...

Hier gefunden:
S:\Program Files\Microsoft SQL Server\150\DTS\Extensions\Common\Jars

Kommt da noch was?

Zitat von @SirEistee:

Zitat von @Looser27:

Starface prüft gerade, ob deren Anlagen in den unterschiedlichen Versionsständen betroffen sind.

Moin,

gibt's hierzu was Neues?

Im Support Forum von Starface ist zu entnehmen, dass deren Anlagen (Cloud und onPremise) nicht betroffen sein sollen.

Zitat von @leon123:
Kommt da noch was?

nein

ELO nimmt für sich in Anspruch auch nicht betroffen zu sein, weil noch Log4j Version 1 genutzt wird. Will aber auch Änderungen vornehmen und die Sache beobachten.

Die Quelle sollte über jeden Zweifel erhaben sein

Zumindest geht näher dran nicht.

Viele Grüße, commodity

Moin,

Igel hat soeben auch Feedback gegeben (per E-Mail):

ISN 2021-11: UMS Log4j vulnerability

====================================

First published 13 December 2021

CVSS 3.1 Base Score:10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Summary
-------
A critical vulnerability, also known as Log4shell, has been found in the Log4j logging library. This affects the following IGEL products (other IGEL products are not affected)
  * IGEL UMS

Details
-------
The versions 2.0-beta9 up to 2.14.1 of the Log4j library are vulnerable to Remote Command Execution (RCE). This means that a remote attacker can execute commands over the network on software that contains the vulnerable Log4j versions. IGEL UMS and the Elasticsearch engine in the IGEL Web App are affected.
Exploit code is already available, and the issue is being actively exploited on the Internet. Therefore, IGEL strongly recommends applying the mitigations below and updating UMS installations as soon as a fixed version is available.
In a typical UMS installation, this issue is mitigated by the fact that UMS is not reachable from the Internet.

Update instructions
-------------------
  * A fixed version of UMS is in preparation. This document will be updated when it is available.

Mitigation
----------
UMS Server (Tomcat)
- - - - - - - - - -
On Windows
  1. Open Windows Explorer and navigate to {installation_path}/rmguiserver/bin
  2. Run editTomcatService.bat
  3. Click on the "Java" tab and add a new line in the text field "Java Options:": 
     -Dlog4j2.formatMsgNoLookups=true
  4. Click "OK" to save and close settings
  5.Run "services.msc", locate and restart "IGEL RMGUIServer"

On Linux
  1. Open UMS server service file, e.g.: vim /etc/systemd/system/igel-ums-server.service
  2. Find the line beginning "ExecStart=" and move forward to the line with
     -Dcatalina.home=${RM_HOME}/rmguiserver \
  3. Insert a new line after this line and add the following text:
     -Dlog4j2.formatMsgNoLookups=True \
  4. Make sure the line ends with a space followed by a backslash 
     The final lines should look like this:
     -Dcatalina.home=${RM_HOME}/rmguiserver \
     -Dlog4j2.formatMsgNoLookups=True \
     -Djava.io.tmpdir=${CATALINA_HOME}/temp \
  5. Save and exit the file
  6. Reload services: sudo systemctl daemon-reload
  7. Restart UMS server: sudo systemctl restart igel-ums-server

Elasticsearch (if UMS Web App is installed)
- - - - - - - - - - - - - - - - - - - - - -
  * Open elastic search jvm.options  at {installation_path}/elasticsearch/config
  * Insert a new line at the end and add the following text: 
    -Dlog4j2.formatMsgNoLookups=True
  * Save and exit the file
  * Restart the elasticsearch service
    * On Windows: run “services.msc”, locate and restart “IGEL Search Indexer”
    * Linux: sudo systemctl restart igel-elasticsearch

References
  * CVE-2021-44228: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
  * BSI-Cyber-Sicherheitswarnung (in German only): https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf 

--------------------------------------------------------------------------------
IGEL Technology is represented by the IGEL Technology GmbH.
Head Office: IGEL Technology GmbH, Hermann-Ritter-Str. 110, 28197 Bremen, Germany
Tel: +49 421 52094 0, Fax: +49 421 52094 1499, Email: info@igel.com mailto:info@igel.com

Managing Directors: Matthias Haas, Anja Schulz Amtsgericht Bremen: HRB 20636, VAT: DE 219524359, WEEE-Reg.-No. DE 79295479 © 2021 IGEL. All rights reserved. All trademarks are the property of their respective owners.
If you no longer wish to receive marketing emails from IGEL, please click  here http://marketing.igel.com/acton/rif/34989/s-0d99-2112/-/l-0f7f:15bf/l-0f7f/zout?sid=TV2%3ACOeKvA5Hi

Im LanSweeper lässt sich ein Report zur Schwachstelle erstellen, der dann potenzielle Software aufzeigt.

LanSweeper Beitrag
Report zum Kopieren

Hi,

FlowChief Prozessleitsystem, QNAP QTS System und Aagoon Client Manager sind nicht betroffen

Zitat von @commodity:

Zitat von @leon123:
Kommt da noch was?

nein

Danke, das BSI hat mich dahingehend nur etwas beunruhigt.

Entgegen der anderslautenden ursprünglichen Annahme ist Berichten zufolge die Programmbibliothek auch
in den Versionen 1.x verwundbar. In diesen Fällen sei die Verwundbarkeit jedoch nur über eine schadhafte
Programmkonfiguration ausnutzbar, sodass eine Ausnutzung weit weniger wahrscheinlich erscheint. [GIT2021d

Hier noch die Stellungnahme zu Kerio Connect:

https://www.brainworks.de/log4j-exploit-kerio-connect-workaround/

https://techtalk.gfi.com/impact-of-log4j-vulnerability-on-gfi/

und die Stellungnahme von Mailstore:

https://www.mailstore.com/de/blog/mailstore-schwachstelle-log4shell-betr ...

Hat den hier schon jemand gepostet? https://log4j-tester.trendmicro.com/

Der Disclaimer ist zwar sinngemäß "Wenn du hier was sieht schau genauer nach. Und wenn nicht schau trotzdem nach." Es kann aber ja auch nicht schaden seine externen Dienste einfach mal damit abzuklopfen.

Manuel

heise.de

Neue Probleme - Log4j-Patch genügt nicht
Version 2.15.0 von Log4j sollte die Log4Shell-Sicherheitslücke schließen. Das reichte jedoch nicht. Log4j 2.16.0 behebt nun noch eine weitere Schwachstelle.

https://www.heise.de/news/Neue-Probleme-Log4j-Patch-genuegt-nicht-629534 ...

Hier ist mal der Ablauf/ Prozess ein wenig beschrieben:

https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-libr ...

Es gibt für den Unifi Controller ein weiteres Update, welches installiert werden sollte.

Hier wird log4j dann auf Version 2.16 gepatched.

Bobby Tables 2.0 sozusagen

Hier sind übrigens noch ein paar interessante Links.

Ursprünglicher JNDI resource lookup Thread
https://issues.apache.org/jira/browse/LOG4J2-313

EDIT:
Zitat: "JNDI lookup in it self is not a problem, problem is that user input is not sanitised and can include templates which can have JNDI lookup in them. I would expect user input with {} template symbols to be escaped and not evaluated."
Quelle aus interessanter Diskussion: https://news.ycombinator.com/item?id=29507357

Nachfrage nach Disable Lookup in Messages (2015 ganz unten)
https://issues.apache.org/jira/browse/LOG4J2-905

Entstehung log4j2.formatMsgNoLookups
https://issues.apache.org/jira/browse/LOG4J2-2109

Hier ist jemand schon mal über das Problem gestolpert
https://www.tasktop.com/blog-under-construction/log4j-2-the-ghost-in-the ...

Mahlzeit.

Hier mal wieder eine Liste (CISA) möglicher Weise betroffener Software. Sieht eindrucksvoll aus.

https://github.com/cisagov/log4j-affected-db

und vorsorglich auch nochmal die oben bereits verlinkte Liste des NCSC, die auch noch gewachsen ist.

https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

Beide sind nicht deckungsgleich.

Wer hat da kein Mitgefühl mit den Kollegen/Entwicklern, die das alles patchen dürfen. 8 Tage vor Weihnachten wünscht man sich sicher was anderes.

Viele Grüße, commodity

Beeindruckend, in der Tat.

Elasticsearch ist somit doch betroffen.
Und die Siemens-Software hatte ich gar nicht auf dem Schirm

Update bei Igel:

Achtung! Diese Nachricht stammt von einem externen Absender!
** Dear IGEL customer, following our previous communications regarding the Log4j vulnerability in IGEL products, please find updated information below on affected products and versions. **

[Updated] ISN 2021-11: UMS Log4j vulnerability
====================================

Updated 16 December 2021 (added affected versions, corrected mitigation for Elasticsearch on Windows)
First published 13 December 2021

CVSS 3.1 Base Score:10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Summary
-------
A critical vulnerability, also known as Log4shell, has been found in the Log4j logging library. This affects the following IGEL products (other IGEL products are not affected)
 * IGEL Universal Management Suite (UMS), all versions since 5.09.100

Details
-------
The versions 2.0-beta9 up to 2.14.1 of the Log4j library are vulnerable to Remote Command Execution (RCE). This means that a remote attacker can execute commands over the network on software that contains the vulnerable Log4j versions. IGEL UMS and the Elasticsearch engine in the IGEL Web App are affected.
Exploit code is already available, and the issue is being actively exploited on the Internet. Therefore, IGEL strongly recommends applying the mitigations below and updating UMS installations as soon as a fixed version is available.
In a typical UMS installation, this issue is mitigated by the fact that UMS is not reachable from the Internet.

Update instructions
-------------------
 * A fixed version of UMS is in preparation. This document will be updated when it is available.

Mitigation
----------
UMS Server (Tomcat)
- - - - - - - - - -
On Windows
 1. Open Windows Explorer and navigate to {installation_path}/rmguiserver/bin
 2. Run editTomcatService.bat
 3. Click on the "Java" tab and add a new line in the text field "Java Options:": 
    -Dlog4j2.formatMsgNoLookups=true
 4. Click "OK" to save and close settings
 5.Run "services.msc", locate and restart "IGEL RMGUIServer"

On Linux
 1. Open UMS server service file, e.g.: vim /etc/systemd/system/igel-ums-server.service
 2. Find the line beginning "ExecStart=" and move forward to the line with
    -Dcatalina.home=${RM_HOME}/rmguiserver \
 3. Insert a new line after this line and add the following text:
    -Dlog4j2.formatMsgNoLookups=True \
 4. Make sure the line ends with a space followed by a backslash 
    The final lines should look like this:
    -Dcatalina.home=${RM_HOME}/rmguiserver \
    -Dlog4j2.formatMsgNoLookups=True \
    -Djava.io.tmpdir=${CATALINA_HOME}/temp \
 5. Save and exit the file
 6. Reload services: sudo systemctl daemon-reload
 7. Restart UMS server: sudo systemctl restart igel-ums-server

Elasticsearch (if UMS Web App is installed)
- - - - - - - - - - - - - - - - - - - - - - 
On Windows
 1. Open command prompt as Administrator
 2. Navigate to {installation_path}/elasticsearch/bin
 3. Execute "elasticsearch-service-mgr.exe //ES//igel-elasticsearch"
 4. Click on the "Java" tab and add a new line in the text field "Java Options:":
    -Dlog4j2.formatMsgNoLookups=true
 5. Click "OK" to save and close settings
 6. Run "services.msc", locate and restart "IGEL Search Indexer"

On Linux
 1. Open elastic search jvm.options  at {installation_path}/elasticsearch/config
 2. Insert a new line at the end and add the following text: 
    -Dlog4j2.formatMsgNoLookups=True
 3. Save and exit the file
 4. Restart the elasticsearch service:
    sudo systemctl restart igel-elasticsearch

References
 * CVE-2021-44228: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
 * BSI-Cyber-Sicherheitswarnung (in German only): https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf 

--------------------------------------------------------------------------------
IGEL Technology is represented by the IGEL Technology GmbH.
Head Office: IGEL Technology GmbH, Hermann-Ritter-Str. 110, 28197 Bremen, Germany
Tel: +49 421 52094 0, Fax: +49 421 52094 1499, Email: info@igel.com
mailto:info@igel.com

Managing Directors: Matthias Haas, Anja Schulz
Amtsgericht Bremen: HRB 20636, VAT: DE 219524359, WEEE-Reg.-No. DE 79295479
© 2021 IGEL. All rights reserved. All trademarks are the property of their respective owners.
If you no longer wish to receive marketing emails from IGEL, please click  here
http://marketing.igel.com/acton/rif/34989/s-0da1-2112/-/l-0f7f:15bf/l-0f7f/zout?sid=TV2%3AZuSRhbNH4
.

Für Docusnap u.a. gibt es ein Workaround wie man betroffene Systeme finden kann

https://www.docusnap.com/it-dokumentation/log4j-luecke-was-macht-sie-so- ...

Zitat von @commodity:

Hier mal wieder eine Liste (CISA) möglicher Weise betroffener Software. Sieht eindrucksvoll aus.

https://github.com/cisagov/log4j-affected-db

und vorsorglich auch nochmal die oben bereits verlinkte Liste des NCSC, die auch noch gewachsen ist.

https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

Beide sind nicht deckungsgleich.

Wer hat da kein Mitgefühl mit den Kollegen/Entwicklern, die das alles patchen dürfen. 8 Tage vor Weihnachten wünscht man sich sicher was anderes.

Viele Grüße, commodity

Oha, richtig .. da wird @aqui viel zutun haben seine ganzen Ubiquiti UniFi Network Controller zu patchen

ELO schreibt jetzt etwas konkreter:

Sehr geehrte ELO Kunden,

eine kürzlich bekannt gewordene Sicherheitslücke in der Java-Bibliothek Log4j gefährdet weltweit Millionen Onlineanwendungen. Die Schwachstelle CVE-2021-44228 für die Protokollierung von Ereignissen kann zur Remote-Ausführung von Code durch Dritte führen.

Von ELO entwickelte Server-Dienste, die u. a. unsere öffentliche API bereitstellen und potenziell im Internet verfügbar sind, setzen Log4j in der Version 2 nicht ein und sind somit nicht betroffen. Leider ist jedoch die aktuelle ElasticSearch-Version (ab ELO 10), der ELO Java Client (ab ELO 10) sowie ELO BLP in Version 5.2 potenziell betroffen.

Sicherheitsexperten weltweit arbeiten gerade mit Hochdruck an der Analyse. Wir empfehlen daher in jedem Fall, auf die von uns bereitgestellten, aktuellen Versionen zu aktualisieren und unsere Handlungsempfehlungen, die auch Ihrem Business Partner vorliegen, umzusetzen.

Bitte kontaktieren Sie daher umgehend Ihre interne IT und das betreuende ELO Systemhaus. Weitere Hinweise finden Sie auch hier.

Mit freundlichen Grüßen
ELO Digital Office

Jetzt geht's lohos! (log4j noch nicht bestätigt):

Ransomware bei CGM

Viele Grüße, commodity

Kam gestern von GFI bzgl. Kerio Connect:

 
We are pleased to announce that Kerio Connect 9.3.1p2 is available. This security release addresses the vulnerability related to Log4j, formally known as CVE-2021-44228.

Release notes: 
 
 	• Apache log4j2 library upgrade to version 2.16.0 (fixing CVE-2021-44228 vulnerability)

The new version can be downloaded from the GFI Upgrade Center. 

We recommend that all Kerio Connect customers install version 9.3.1p2 as soon as possible. 
 
Once Kerio Connect 9.3.1p2 is deployed, the chat function can be safely re-enabled. 

GFI Software

Heute morgen eingespielt.

Moin,

um das Thema auf dem Laufenden zu halten -> Log4j-core 2.16.0 ist auch anfällig; wird in CVE-2021-45105 dokumentiert.

UniFi hat noch kein Controllerupdate rausgegeben, die manuelle Updateanleitung gibts hier https://think.unblog.ch/en/how-to-fix-unifi-controller-log4j-vulnerabili ...

Wenn man schon auf Controller v6.5.55 ist, einfach die Stellen im Skript mit "2.13.3" mit "2.16.0" ersetzen.

VG

Zitat von @chgorges:

Moin,

um das Thema auf dem Laufenden zu halten -> Log4j-core 2.16.0 ist auch anfällig; wird in CVE-2021-45105 dokumentiert.

UniFi hat noch kein Controllerupdate rausgegeben, die manuelle Updateanleitung gibts hier https://think.unblog.ch/en/how-to-fix-unifi-controller-log4j-vulnerabili ...

Wenn man schon auf Controller v6.5.55 ist, einfach die Stellen im Skript mit "2.13.3" mit "2.16.0" ersetzen.

VG

2.16 auch?
Man dachte, man wäre mit 2.15 (halbwegs) auf der sicheren Seite.

Information Webserver Linux

Mehr von theoberlin

Problem SAP Druckerumzugtheoberlin - 3 Kommentare

Windows 11 Druckerfehler "Drucker wird gerufen"theoberlin - 7 Kommentare

Microsoft Slim Pen 2 lädt nicht in ladeschaletheoberlin

Icingaweb2 Notification Mails laufen nichttheoberlin

Heiß diskutiert