techjourno-perlen

Techjourno-Perlen und Anderes, Teil 8

Weil auf der ganzen Netzwelt so viel passiert, und wir nicht alles gleichzeitig verarbeiten, verarzten und verkommentieren können, empfehlen wir hin und wieder ein paar Artikel aus der Netzwelt, mit Lob, mit Kritik und auch Ergänzungen. Einfach und simpel Meta. Ausserdem nutzen wir das Format für Kurzeinordnungen und -erklärungen zu brandaktuellen Tech-News.

Der BAKOM-Bericht zu Plattformen („Intermediäre“)

Und wieder veröffentlichte die Bundesverwaltung einen umfassenden Bericht, dieses Mal zum Thema Plattform-Regulierung. Eine Journalistin kann nicht dankbar genug sein für die geleistete Recherchearbeit. Und auch wenn uns die meisten Sachverhalte bekannt sind, so stiessen wir dabei auf ein paar wahrhaftige „Gold Nuggets“. Etwa: dass das Bundesamt für Polizei (fedpol), der Israelische Gemeindebund oder das IKRK als „Trusted Flaggers“ qualifiziert sind für Youtube und Facebook. Sie gelten also als vertrauenswürdige Hinweisgeberinnen und helfen der Plattform ihre Community-Richtlinien besser durchzusetzen. Sie melden dabei mit einem speziellen Tool Inhalte wie „Terrorismuspropaganda“ oder weitere strafrechtlich relevanten Content wie Kinderpornographie.

Allgemein fällt auf: während Deutschland, EU, Frankreich viele Gesetze verabschieden, die spezifisch die Plattformen in die Pflicht nehmen in Sachen Hassrede und Fake News, ist die Schweiz im Dauerbeobachtungsmodus und gibt kaum Vorgaben vor, wie die AutorInnen immer wieder anmerken. Straftatbestände existieren zum Thema Hassrede, zu Falschinformationen gibt es nichts Spezifisches (ausser es geht in Richtung „Verleumdung“), was per se nicht schlecht sein muss. Was aber definitiv fehlt: Gesetze, die die Plattformen in Sachen Durchsetzung und Sorgfalt in die Pflicht nehmen und Transparenz einfordern (wie es der derzeit debattierte „Digital Services Act“ der EU künftig tun wird).

Die AutorInnen sind zurückhaltend mit regulatorischen Empfehlungen, dennoch ist die Stossrichtung des Berichts klar, wie folgender Abschnitt andeutet:

„Es ist breit anerkannt, dass es für Demokratien problematisch ist, wenn die neue Kommunikationsinfrastruktur weniger Intermediäre einer gesellschaftlichen Kontrolle entzogen bleibt. Verschiedene vom BAKOM in Auftrag gegebene Studien kommen zum Schluss, dass die Bevölkerung auf einen effektiven Schutz vor illegaler Hassrede und Desinformation Anspruch hat, sowie dass die Rechte der Nutzerinnen und Nutzer gegenüber den Intermediären besser geschützt werden müssten.

BAKOM-Bericht „Intermediäre und Kommunikationsplattformen“

Recently uncovered software flaw ‘most critical vulnerability of the last decade’

In der in praktisch allen Java-Applikationen eingesetzten Logging-Library Log4j wurde ein Fehler gefunden, welcher es Angreifern erlaubt, beliebigen Code ausführen zu lassen. Besonders gefährlich ist diese Lücke vor allem, weil sie problemlos „von aussen“ (d.h. bei Web-Applikationen aus dem Internet heraus) ausnutzbar ist, der Angreifer muss weder einen Account auf dem angegriffenen System haben noch überhaupt gross mit dem System interagieren. Wenn eine Webseite zum Beispiel standardmässig die erhaltenen HTTP-Requests ins Logfile schreibt (um zB Fehler nachvollziehen zu können), reicht ein manipulierter Request um eigenen Code einzuschleusen (ein Angreifer kann beispielsweise die bei jedem HTTP-Request mitgeschickten Metadaten, in denen üblicherweise Informationen wie Cookies, erwartete Dateiformate, erwartete Sprachen etc stehen, um einen Eintrag erweitern der, falls geloggt, die Lücke ausnutzt). Eine schlimmere Lücke zum Angreifen von Systemen kann man sich eigentlich gar nicht vorstellen. Wie @chvancooten auf Twitter berichtete, reicht es sogar, den Namen des eigenen iPhones passend zu ändern um die Lücke auf Apples Servern auszunutzen.

Technisch gesehen ist die Lücke vergleichbar mit SQL-Injections. Während bei diesen Benutzer-Eingaben vor der Weiterverwendung nicht auf allfällige SQL-Befehle und Sonderzeichen überprüft werden und man so (je nach Umfeld) SQL-Befehle zur Datenbank-Manipulation einschleusen kann, wird bei der Log4j-Lücke der ins Logfile geschriebene Text ungenügend validiert. Der Effekt ist derselbe: Auf dem Server läuft anschliessend ein Stück Code, welches von aussen eingeschleust wurde und über welches der Angreifer volle Kontrolle hat.

Den Entwicklern und Betreibern der betroffenen Systeme bleibt kaum anderes übrig als Systeme kurzfristig stillzulegen, ihre Firewalls umzukonfigurieren oder möglichst schnell einen Update einzuspielen (der entweder Log4J durch eine sichere Version ersetzt oder zumindest die Funktion ausschaltet mit welcher beim Schreiben von Logs auf Drittsysteme zugegriffen wird).

Schutz- und Lösungsmöglichkeiten (rot) (aus https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/)

Die Lücke zeigt aber wieder mal anschaulich, wie schwierig es ist, wirklich sichere Software zu schreiben und wie gross die Abhängigkeiten von Basiskomponenten sind:

  • Auch wenn für viele Grundfunktionen (wie zB Logging) verschiedene Komponenten verfügbar sind, wird gerne mal überall dieselbe eingesetzt (sei es weil sie schlicht die beste ist, sei es weil sie halt standardmässig schon vorhanden ist, sei es weil der Entwickler sie halt schon kennt).
  • Jede Kette ist so stark wie ihr schwächstes Glied, jede Web-Applikation so sicher wie ihre unsicherste Komponente. Und selbst bei rigorosen Sicherheitschecks in der eigenen Applikation denken die wenigsten daran, auch alle verwendeten Komponenten in jeder Version erneut auf Herz und Nieren zu prüfen.
  • Der grosse Vorteil von Open Source-Software („given enough eyeballs, all bugs are shallow“) nützt nichts, wenn niemand genau genug hinschaut, um einen potentiellen Fehler überhaupt zu erkennen (oder, wie in diesem Fall, die Auswirkungen eines neuen Features abzuschätzen). Nicht jeder Software-Entwickler hat das Wissen und die Erfahrung, um die sicherheitsrelevanten Aspekte einer Funktion erkennen und beachten zu können, nicht jede sicherheitstechnisch heikle Funktionalität kann ohne weiteres ausgebaut werden (vor allem nicht wenn die Software weltweit im Einsatz ist). Dies gilt grundsätzliche für sämtliche Software, bei Basiskomponenten ist die Breitenwirkung halt deutlich grösser. Oder, wie es einer der Log4J-Entwickler auf Twitter formulierte,

Diese Problematik der Abhängigkeit von Basis-Komponenten hat das Web-Comic XKCD schon vor einiger Zeit thematisiert.

PS: Wer selber auf Lücken-Suche gehen will, kann sich bei CanaryTokens ein Log4jShell-Token generieren und dieses dann auf beliebigen Input-Formularen im Web probehalber eingeben. Falls die jeweilige Webseite über die Log4j-Lücke angreifbar ist, erhält man anschliessend eine Mail zugeschickt.

Commission makes software available to all to benefit businesses, innovators and areas of public interest

Die EU-Kommission hat ihre Regeln in Bezug auf das Publizieren des Quellcodes der eigenen Software angepasst. Neu soll es für den Entwicklern der EU Kommissions-eigenen Software einfacher sein, den Quellcode für alle interessierten Kreise zugänglich zu machen. Insbesondere braucht es keinen Entscheid der Kommission mehr, um Software unter eine Open Source-Lizenz zu stellen.

Als Beispiele werden angeführt:

eSignature, a set of free standards, tools and services that help public administrations and businesses accelerate the creation and verification of electronic signatures that are legally valid in all EU Member States.

LEOS, (Legislation Editing Open Software), the software used across the Commission to draft legal texts.

Zumindest die neue deutsche Regierung hat ebenfalls angekündigt, dem Thema „Public Money, Public Code“ mehr Beachtung zu schenken. Es ist zu hoffen, dass den Ankündigungen auch Taten folgen (und dass das Thema auch in der Schweiz Fahrt aufnimmt).

Teile Diesen Beitrag

Share on twitter
Share on linkedin
Share on facebook
Share on email

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.