Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Alarmstufe Rot ausgerufen und auch das Schweizer Cybersicherheitszentrum hat dringende Empfehlungen herausgegeben. Sogar Massenmedien haben bereits über die Schwachstelle berichtet: Log4j, das weit verbreiteten Logging-Framework für Java, weist eine kritische Sicherheitslücke auf, die bereits aktiv ausgenutzt wird. Ein Großteil aller in Java geschriebenen Anwendungen und APIs sind potentiell gefährdet. Java’s Erfolgsfaktor „Write once, run everywhere“ wird nun zum Bumerang. Ein Kommentar von Dani Estermann, Produktmarketing Manager bei Airlock, einer Security Innovation der Ergon Informatik,.
Das Problem ist aus zwei Gründen gravierend: Erstens ist Log4j ein weit verbreitetes Logging-Framework für Java und wurde auch in diverse andere Programmiersprachen übersetzt. Weltweit dürften deshalb Millionen von Systemen verwundbar sein, auch prominente Hersteller wie Google, Apple oder Tesla sind betroffen. Und zweitens lässt sich mit wenig Aufwand viel Schaden anrichten: Gefahr besteht dann, wenn Log4j verwendet wird, um eine vom Angreifer kontrollierte Zeichenkette wie beispielsweise den HTTP-User-Agent zu protokollieren. Mit einer einfachen Zeichenkette lässt sich Log4j dazu bewegen, zusätzlichen Programmcode von einem Server im Internet nachzuladen. Ein Angreifer kann also beliebigen Schadcode injizieren und so Firmen von innen angreifen.
Application-Security-Testing reicht nicht aus
Immer mehr Entwickler prüfen ihren eigenen Code und fremde Bibliotheken (wie Log4j) automatisiert auf Schwachstellen. Das ist ein großer Schritt vorwärts für die Anwendungssicherheit, weil es das Problem an der Wurzel anpackt. Es ist allerdings trügerisch, sich auf eine Datenbank von bekannten Schwachstellen zu verlassen. Application-Security-Testing hilft zwar bei der Erkennung einer möglichen Schwachstelle, schützt aber nicht davor. Wenn ein solches Tool Alarm schlägt, dauert es oft Tage oder Wochen, bis die Korrektur ausgerollten werden kann. Manchmal ist es gar unmöglich, alle betroffenen Systeme zu patchen.
Verschaffen Sie sich Zeit mit Virtual-Patching
Eine saubere Lösung benötigt Zeit. Natürlich sind alle Javaprogrammierer bereits daran, auf die neuste Log4j-Version umzustellen. Das größere Problem dürfte jedoch sein, alle betroffenen Systeme erst mal zu identifizieren. Abhängig von der Java-Version kann diese Log4j-Lücke über eine zusätzliche Option beim Start der Javaumgebung geschlossen werden. So oder so dürften noch mehrere Wochen vergehen, bis alle betroffenen Systeme geschützt sind.
Jetzt in Panik auszubrechen wäre aber kontraproduktiv. Denn es gibt eine wirksame Sofortmaßnahme, um Zeit zu gewinnen: Virtual-Patching. Eine vorgeschaltete Application-Firewall (WAF) bzw. ein API-Gateway erkennt die gefährlichen Inhalte und blockiert sie, noch bevor sie auf das verwundbare System treffen. Damit hat man die Wahrscheinlichkeit eines erfolgreichen Angriffs stark reduziert und die IT kann in Ruhe die betroffenen Systeme patchen. Auch das Nationale Cyber Security Center empfiehlt, die Sicherheitsregeln einer WAF falls notwendig zu aktualisieren.
Gehärtete Sicherheitsregeln dank Bug-Bounties
Die Herausforderung einer WAF besteht darin, nicht nur die offensichtlichen Formen eines Angriffs zu erkennen, sondern eine ganze Klasse von komplexen Abwandlungen. Das setzt voraus, dass die Filterregeln einer WAF kontinuierlich weiterentwickelt und gehärtet werden. Bei Airlock-Gateway setzen wir dafür auf ein Bug Bounty Programm. Gutmütige Hacker aus aller Welt dafür bezahlt, die Filterregeln von Airlock zu umgehen. Wer es schafft, die Schutzmechanismen auszutricksen, erhält eine attraktive Belohnung (Bounty). Einer der Hacker machte uns in diesem Zuge ein Kompliment: Im Gegensatz zu anderen Produkten habe er sich bei Airlock die Zähne ausgebissen.
Tägliches Brot für Sicherheitsprofis
Die Airlock-Engineers sind es sich gewohnt, dass regelmässig neue Sicherheitslücken auftauchen, auch wenn viele davon in der Presse keine große Beachtung finden. Nur schon die heiklen Schwachstellen in der Transportverschlüsselung TLS füllen mehrere Bildschirmseiten. Es ist Teil unseres Jobs, auf neue Bedrohungen zu reagieren und künftige Angriffsszenarien so weit wie möglich zu antizipieren. Und so haben wir auch diese Schwachstelle analysiert und alle nötigen Anpassungen in Airlock vorgenommen.
Fazit
- Die Anwendungssicherheit sollte in allen Phasen des Software-Lebenszyklus adressiert werden: Schon in der Entwicklungsphase kann Application-Security-Testing potenzielle Probleme aufzeigen. Und vom Testing bis zum Betrieb sorgen WAFs und API-Gateways für einen zusätzlichen Schutz zur Laufzeit.
- Professionelle Web-Application-Firewalls und API-Gateways können sogar Angriffe abwehren, die noch nicht bekannt sind. Voraussetzung ist natürlich, dass die Schutzmechanismen von Beginn weg aktiv sind. Eine
- Airlock schützte schon vor dieser Schwachstelle, bevor sie bekannt wurde. Andere Hersteller haben ihre Sicherheitsregeln erst nach Bekanntwerden der Schwachstelle angepasst, um die Backende-Anwendungen ausreichend zu schützen.
- WAF-Regeln müssen von Sicherheitsprofis entwickelt und kontinuierlich überprüft werden, damit die Schutzmechanismen von erfahrenen Angreifern nicht umgangen werden können. Dafür sorgt zum Beispiel unser Airlock-Bounty-Programm, in dem Hacker aus aller Welt versuchen, Lücken im Schutzschild Airlock zu finden.
#Airlock
