log4j CVE-2021-44228 Infos und Fragen

[NorbertFe 2.045]

Hi,

 

hier rotieren sicherlich schon einige und sammeln die Infos bei den Herstellern und anderen Quellen.

Deswegen gern hier auch noch eine Sammlung von Links und Infos zu obiger Lücke, die grad Kreise zieht:

Offizielle Stellungnahme des BSI zum Thema

https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=3

 

Liste von Herstellerstatements:

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

Die ist bei weitem nicht vollständig, wie mir der Blick auf diverse Kundenumgebungen so zeigt.

 

Ich bin aktuell selbst noch auf der Suche nach einer Aussage von APC/Schneider Electric, falls also jemand was weiß, gern her damit. Egal ob Patch, Workaround oder "gar nicht betroffen". :)

 

Bye

Norbert

[NorbertFe 2.045]

Von Kemp (neuerdings ja Progress) gibts inzwischen einen entsprechenden Link:

https://support.kemptechnologies.com/hc/en-us/articles/4416430695437-CVE-2021-44228-Log4j2-Exploit

We have validated that the vulnerability does not exist in the following products:

• LoadMaster
• LoadMaster GEO
• Kemp 360 Central
• Kemp 360 Vision

[Dalmatinac 11]

Moin Norbert,

 

wir sind auch schon Ordentlich am rotieren.

 

Ich habe noch eine interessante Seite gefunden für Detections und skripte.

 

Ich poste die mal hier.

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

 

Ich hoffe die Seite hilft mit Ihren Informationen weiter. Bin noch am testen und schauen.

[djmaker 95]

Netapp:

 

https://security.netapp.com/advisory/ntap-20211210-0007/

[zahni 554]

VMWare https://www.vmware.com/security/advisories/VMSA-2021-0028.html

Websphere Application Server:  https://www.ibm.com/support/pages/security-bulletin-vulnerability-apache-log4j-affects-websphere-application-server-cve-2021-44228

Alle Produkte, die Elastic-Search mitbringen.

bearbeitet 13. Dezember 2021 von zahni

[testperson 1.680]

DATEV: Log4-J Schwachstelle - DATEV-Community - 258147

 

Zitat

... Generell lässt sich sagen, dass bei standardmäßiger Installation von DATEV on premises Anwendungen kein erhöhtes Risiko ausgeht. Dennoch stellen wir morgen und übermorgen Hotfixes zur Verfügung, die umgehend nach Veröffentlichung installiert werden sollten. ...

Log4-J Schwachstelle - DATEV-Community - 258147

bearbeitet 13. Dezember 2021 von testperson

[daabm 1.356]

...und für die private IT: https://community.openhab.org/t/log4j-vulnerability/129863/1

[Marco31 33]

Eine Frage dazu; wenn ich mal die Anwender im lokalen Netzwerk als potenzielle Angreifer ausklammere, bin ich vor der Schwachstelle sicher wenn meine Applikationen nicht aus dem Internet erreichbar sind?

[cj_berlin 1.323]

vor 26 Minuten schrieb Marco31:

Eine Frage dazu; wenn ich mal die Anwender im lokalen Netzwerk als potenzielle Angreifer ausklammere, bin ich vor der Schwachstelle sicher wenn meine Applikationen nicht aus dem Internet erreichbar sind?

Nein, weil ein Angreifer die Lücke ausnutzen könnte, indem er einem User scheinbar harmlosen Code unterschiebt, der ein anfälliges Gerät anspricht. Klar, weniger wahrscheinlich und ungleich komplexer als ein direkter Angriff aus dem Internet, aber "sicher"? Nein.

[Marco31 33]

Ja, "Sicher" war ja in der heutigen Zeit eh schon falsch ausgedrückt... Ein möglicher Angriffsvektor ins interne Netz wäre dann z.B. entsprechender Code per Email als Dateianhang oder kompromittierte Websites, die Geräte im internen Netz nach der Schwachstelle scannen und dann über diese Code ausführen?

Da bleibt bis zum patchen der betroffenen Anwendungen wohl nur die Hoffnung, dass Applocker und blocken von ausführbaren Dateianhängen den Worstcase verhindern... 

[MrCocktail 192]

Hi,

 

sicher ist momentan keiner, wir haben gestern in einer Demo Umgebung nachgewiesen, dass die folgende Kombination greift:

 

• Mail mit entsprechendem Betreff über unsere Gateways an Exchange
• Exchange mit Logshifting in einen ELK Stack der angreifbar ist
• auf dem ELK Stack wird unsere Payload nachgeladen

also haben wir überall unser Logshifting ausgeschaltet.... und ich will nicht wissen, wo sowas überall intern benutzt wird, weil ist ja schön einfach.

 

Gruß

J

 

[cj_berlin 1.323]

...da sollte man sich im Nachhinein aber schon fragen, warum ein Tier 0-System etwas "nachladen" darf  

[testperson 1.680]

Betroffene HPE Produkte: Document - HPESBGN04215 rev.1 - Certain HPE Products using Apache Log4j2, Remote Code Execution | HPE Support

 

 

[MrCocktail 192]

vor einer Stunde schrieb cj_berlin:

...da sollte man sich im Nachhinein aber schon fragen, warum ein Tier 0-System etwas "nachladen" darf  

 

Das war erst einmal unsere Testumgebung, also keine Produktion und ja, die Firewall Regeln sind da etwas einfacher, sprich von innen nach aussen komme ich in Test, für uns war es einfacher im ersten Schritt einfach das Logshifting auszuschalten als die Produktion zu prüfen

[cj_berlin 1.323]

IGEL UMS:

https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html