In den letzten Tagen im Netz wurde viel über die Schwachstelle von Log4 gesprochenj, in dem verschiedene Angriffsvektoren entdeckt und auch verschiedene funktionale Exploits herausgefiltert wurden, um die Schwachstelle auszunutzen.
Der Ernst der Sache ist, dass dies ein beliebtes Framework zum Organisieren der Registrierung in Java-Anwendungen ist., die die Ausführung von beliebigem Code ermöglicht, wenn ein speziell formatierter Wert im Format "{jndi: URL}" in die Registry geschrieben wird. Der Angriff kann auf Java-Anwendungen ausgeführt werden, die aus externen Quellen erhaltene Werte protokollieren, beispielsweise indem problematische Werte in Fehlermeldungen angezeigt werden.
Und ist, dass ein Angreifer stellt eine HTTP-Anfrage an ein Zielsystem, das mit Log4j 2 ein Log generiert Das verwendet JNDI, um eine Anfrage an die vom Angreifer kontrollierte Site zu senden. Die Schwachstelle führt dann dazu, dass der ausgenutzte Prozess an der Site ankommt und die Nutzlast ausführt. Bei vielen beobachteten Angriffen ist der Parameter, der dem Angreifer gehört, ein DNS-Registrierungssystem, das eine Anfrage auf der Site registrieren soll, um anfällige Systeme zu identifizieren.
Wie unser Kollege Isaac bereits sagte:
Diese Schwachstelle von Log4j ermöglicht es, eine falsche Eingabevalidierung in LDAP auszunutzen, wodurch Remotecodeausführung (RCE) und Kompromittierung des Servers (Vertraulichkeit, Datenintegrität und Systemverfügbarkeit). Darüber hinaus liegt das Problem bzw. die Bedeutung dieser Schwachstelle in der Anzahl der Anwendungen und Server, die sie verwenden, darunter Unternehmenssoftware und Cloud-Dienste wie Apple iCloud, Steam oder beliebte Videospiele wie Minecraft: Java Edition, Twitter, Cloudflare, Tencent, ElasticSearch, Redis, Elastic Logstash und eine lange usw.
Apropos, vor kurzem die Apache Software Foundation veröffentlicht durch eine Veröffentlichung eine Zusammenfassung von Projekten, die eine kritische Schwachstelle in Log4j 2 beheben die die Ausführung von beliebigem Code auf dem Server ermöglicht.
Betroffen sind folgende Apache-Projekte: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl und Calcite Avatica. Die Sicherheitslücke betraf auch GitHub-Produkte, darunter GitHub.com, GitHub Enterprise Cloud und GitHub Enterprise Server.
In den letzten Tagen gab es einen deutlichen Anstieg der Aktivität im Zusammenhang mit der Ausnutzung von Sicherheitslücken. Beispielsweise, Check Point hat auf seinen fiktiven Servern rund 100 Exploit-Versuche pro Minute protokolliert seinen Höhepunkt erreicht, und Sophos gab die Entdeckung eines neuen Kryptowährungs-Mining-Botnets bekannt, das aus Systemen mit einer ungepatchten Schwachstelle in Log4j 2 besteht.
Zu den Informationen, die zu dem Problem veröffentlicht wurden:
- Die Schwachstelle wurde in vielen offiziellen Docker-Images bestätigt, darunter Couchbase-, Elasticsearch-, Flink-, Solr-, Storm-Images usw.
- Die Schwachstelle liegt im Produkt MongoDB Atlas Search vor.
- Das Problem tritt bei einer Vielzahl von Cisco-Produkten auf, einschließlich Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Advanced Web Security Reporting, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks usw.
- Das Problem tritt in IBM WebSphere Application Server und in den folgenden Red Hat-Produkten auf: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse und AMQ Streams.
- Bestätigtes Problem in Junos Space Network Management Platform, Northstar Controller/Planner, Paragon Insights/Pathfinder/Planner.
- Auch viele Produkte von Oracle, vmWare, Broadcom und Amazon sind betroffen.
Apache-Projekte, die nicht von der Log4j 2-Sicherheitslücke betroffen sind: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper und CloudStack.
Benutzern problematischer Pakete wird empfohlen, die veröffentlichten Updates dringend zu installieren Aktualisieren Sie für diese die Version von Log4j 2 separat oder setzen Sie den Parameter Log4j2.formatMsgNoLookups auf true (z. B. durch Hinzufügen des Schlüssels "-DLog4j2.formatMsgNoLookup = True" beim Start).
Um das System zu sperren, auf das es keinen direkten Zugriff gibt, wurde vorgeschlagen, den Logout4Shell-Impfstoff auszunutzen, der durch die Durchführung eines Angriffs die Java-Einstellung "log4j2.formatMsgNoLookups = true", "com.sun.jndi ." entlarvt .rmi.Objekt. trustURLCodebase = false "und" com.sun.jndi.cosnaming.object.trustURLCodebase = false "um weitere Manifestationen der Schwachstelle auf unkontrollierten Systemen zu blockieren.