Hallo zusammen,
an dieser Stelle informieren wir über die log4j Sicherheitslücke:
pascom 19 und Teile von pascom 20 sind vom Problem betroffen, auch wenn sich die „üblichen“ Script-Angriffe wohl nicht auf unsere Systeme anwenden lassen.
Uns ist das Problem seit Freitagvormittag bekannt. Wir arbeiten an einem Patch für pascom 19 und halten alle in diesem Thread auf dem Laufenden. Unsere Cloud Systeme werden automatisch upgedatet.
LG
Mathias Pasquay
Zwischenbericht:
Für den Hauptangriffsvektor über LDAP sind wir ab der Version 19.17 und höher nicht anfällig, da wir aktuelle Java-Bugfixes mitliefern. Außerdem ist nur der XMPP-Server betroffen und nicht z.B. der Webserver. Somit müsste ein handgefertigter Angriff direkt mit unseren Protokollen erfolgen.
Damit schlagen die aktuell im Internet kursierenden Angriffe erst mal alle fehl.
Handlungsempfehlung für on-site Systeme: Wir sehen aktuell keine dringende Notwendigkeit, die Systeme offline zu nehmen. Ein entsprechendes Bugfix-Release im Laufe des Nachmittags zur Verfügung stehen.
Handlungsempfehlung für cloud Nutzer: Hier ist keine Aktion der Nutzer notwendig. Unsere Systeme werden bereits seit dem Wochenende gemonitort. Die Lücke wird mit einem Update heute Nacht gänzlich geschlossen.
Wir werden alle on-site Kunden informieren, sobald der Bugfix zur Verfügung steht.
Der pascom Server 19.20 mit den log4j Anpassungen steht jetzt zum Download zur Verfügung: https://download.pascom.net/release-archive/server/7.19.20/pascom_7.19.20.R.iso
Dazu habe ich eine kurze Frage:
Ihr schreibt, dass für Cloud-Nutzer die Lücke heute Nacht gänzlich geschlossen wurde.
Ist dies nun in einem Bugfix in der 19.19 enthalten oder wird die Lücke erst nach dem Update auf 19.20 geschlossen?
Gruß Marius
Hallo @stadt_ochtrup,
die Lücke ist in der Cloud geschlossen. Für onsite ist das erst mit einem 19.20 Update so. In der Cloud haben wir die 19.19 XMPP Server hotgepatched. Das ging wesentlich schneller. Ein Update unserer tausenden 19.19 Instanzen in der Cloud hätte eine Woche lang gedauert. War trotzdem noch genug Arbeit für eine Nacht ;).
LG
Mathias
Alles klar!
Vielen Dank für die Information und für euren Einsatz!
Gruß Marius
Schließe mich an, vielen Dank für die schnelle Reaktion!
Gruß,
Rapha
Welche log4j Version ist denn im aktuellen Image 7.19.20.R.iso enthalten? In unserer Installation kann ich (nach dem Update) per find nur eine log4j-1.2.17.jar finden. Diese Version wäre ja so alt, dass es damit überhaupt kein Sicherheitsproblem gäbe.
Welche Version kommt bei einem alten Pascom 17 Server zum Einsatz? Auch hier finde ich per find nur eine log4j-1.2.17.jar bzw. beim Jasperserver eine log4j-1.2.15.jar. Wie müssen diesen alten Server aus Gründen weiterhin betreiben, daher die Frage.
Hallo zusammen,
gibt es eigentlich ein Script um zu überprüfen, ob es einen erfolgreichen Angriff in der Vergangenheit gab ?
LG Maik
Man könnte die Logs analysieren, evtl. basiert auf diesen Vorschlägen (Abschnitt 4.1 Log Analysis)
Gruß,
Rapha
Hallo zusammen,
hier nochmals Feedback von uns zu Euren Nachfragen:
pascom 17 ist schon seit langem EOL. Hierzu gibt es von uns keine Aussagen.
In pascom 19.20 haben wir konkret folgende Schritte unternommen:
Wie bereits erwähnt hatten wir Java 11.0.11 auf diesem System welche nicht für den LDAP Angriffsvektor anfällig ist. Da wir die log4j Version wegen des XMPP Servers nicht ohne Weiteres anheben konnten, sind wir den Empfehlungen gefolgt und haben mittels “log4j2.formatMsgNoLookups=True” das betroffene Feature deaktiviert.
In pascom 20 (Cloud) haben wir zusätzlich die log4j Version auf 2.15.0 angehoben. Wir werden diese noch auf die heute aktuelle 2.16.0 upgraden, um dem möglichen DoS-Angriff vorzubeugen. Dieser CVE wird allerdings als niedrig eingestuft.
Wegen der Logs nochmals zum Verständnis: Der XMPP Server ist nicht per HTTPS direkt erreichbar. Klar kann es sein, dass Ihr dennoch in den Apache Logs Angriffsversuche finden werdet, diese sind aber bedeutungslos. Einen (sehr unwahrscheinlichen) handgemachten Angriff auf den XMPP Server Port 5222 würdet ihr im Journal des PBX-Containers in den XMPP Logs finden - außer der Angreifer hat das Log bereits gelöscht 
LG
Mathias