Eine Sicherheitslücke in einer Java-Logging-Software namens log4j gibt zu reden. So sehr, dass der Tagesanzeiger dem Vorfall Platz auf der Titelseite einräumt. Was ist denn genau passiert?
Softwaresysteme führen ein Logbuch über Ereignisse. Wir, die Software-Ingenieure, bestimmen, welche Ereignisse aufgenommen werden sollen. Damit messen wir die Leistung des Systems oder nehmen Fehler-Ereignisse auf. Der Inhalt des Logs enthält deshalb auch oft Daten, die durch den Benutzer verursacht werden, wie zum Beispiel den Web-Browser-Typ oder das Betriebsystem. Diese Datenpunkte ermöglichen uns, Fehler zu reproduzieren und effizient zu beheben.
Immer wenn eine Software Benutzerdaten entgegen nimmt, ist Vorsicht geboten. Es könnte sich um einen potentiellen Angriff handeln. Die Benutzerdaten könnten Schaden verursachen (z.B. per "SQL-Injection"). Deshalb sind Programmierer in der Pflicht, jegliche Daten vor der Verarbeitung zu bereinigen.
Mit der Sicherheitslücke in log4j war es nun eben möglich, über Benutzerdaten fremden Code in das Logging-System zu injizieren. Anstatt einem vordefinierten Verhalten (z.B. Datenpunkt loggen) fremden Code ausführen, das ist eine Remote Code Execution. Solche Attacken sind normalerweise ziemlich kompliziert auszuführen. Die in log4j ist es perfiderweise nicht: Es reichte schon, wenn Sie Ihren Web-Browser umbenennen würden zu "${jndi:ldap://127.0.0.1:1389/ badClassName}".
Unsere Kunden sind von dieser Sicherheitslücke verschont geblieben, da wir Java (nicht zu verwechseln mit JavaScript) bei der Renuo lediglich zur Android-App-Entwicklung einsetzen. Dort werden andere Logging-Mechanismen anstatt log4j eingesetzt. Die Reichweite der Sicherheitslücke ist aber gewaltig, da log4j ansonsten in der Branche der Standard-Mechanismus für Logs ist. Es geht soweit, dass sogar die Software des Mars-Helikopters verwundbar ist.
Und machen wir uns nichts vor: Es hätte uns genau so gut treffen können. Wir können lediglich versuchen, vorzubeugen. Dazu haben wir bei der Renuo folgende Massnahmen eingerichtet:
Wir setzen Open Source Software ein. Da werden Lücken eher gefunden und sie können zügig geschlossen werden.
Wir setzen Software-Bibliotheken ein, die eine gute Verbreitung und eine gute Testabdeckung haben. Das erhöht die Wahrscheinlichkeit, das die Qualität gut ist, ohne dass wir den Code auditieren müssen. Ein Audit ist enorm aufwendig und von unseren Kunden eigentlich nie gewünscht.
Wir spenden 5% unseres Firmen-Profits an von uns verwendete Open Source Software. Damit ermöglichen wir Bug-Bounty-Programme und bezahlte Audits.
