Neben dem URL-Kürzer und zwei Apps lief eine ganze Serie von Code-Reviews quelloffener Software. Neun Projekte parallel, am Ende fünf echte Funde, jeder vertraulich über den passenden Kanal gemeldet. Ein Überblick, was dabei herauskam, warum der richtige Meldeweg zur Recherche gehört und was die Funde über Standardeinstellungen und doppelte Prüfung lehren.
Ein einzelner Fund ist eine Geschichte. Eine ganze Runde auf einmal zeigt das Muster dahinter. Parallel zu den bereits beschriebenen Fällen habe ich eine Reihe quelloffener Projekte systematisch durchgesehen, neun davon gleichzeitig, jedes mit derselben Methode: erst die Stellen suchen, an denen fremde Daten in heikle Funktionen fließen, dann den Verdacht dynamisch bestätigen, statt ihn nur zu vermuten, und bei einem echten Fund gleich einen Patch und einen Meldetext bauen.
Ehrlich zur Ausbeute, denn das gehört dazu: Von neun Projekten lieferten vier einen echten Fund, dazu kam einer aus einer eigenen Prüfung. Zwei hatten nur Kleinigkeiten, zwei gar nichts, eine Prüfung schlug fehl und musste neu angesetzt werden. Das ist normal. Wer ehrlich sucht, findet nicht überall etwas, und das ist die bessere Nachricht.
Die Funde, im Prinzip erklärt
Ohne Schritt-für-Schritt-Anleitung, denn die Meldungen sind noch in Arbeit. Es geht um die Art des Fehlers, nicht um eine Vorlage.
- Eine verbreitete Bibliothek zum Erzeugen und Lesen von Office-Dokumenten. Ein präpariertes Dokument mit einer externen Bildverknüpfung bringt den Server, der das Dokument öffnet, dazu, beim Einlesen selbst eine Anfrage an eine beliebige Adresse zu schicken. Das trifft interne Dienste oder Cloud-Metadaten, ein klassischer Server-Side Request Forgery zur Parse-Zeit. Ehrlich eingeordnet ist das kein ganz neuer Bug, sondern der Rest einer schon vor Jahren gemeldeten Lücke: Das externe Nachladen ist bis heute in der Voreinstellung aktiv. Deshalb habe ich es nicht als dramatisches neues Advisory gemeldet, sondern als Härtungsvorschlag im Sinne von sicher per Voreinstellung, mit Nachweis und Patch.
- Eine weit verbreitete Bibliothek für den Versand von E-Mails. In einem bestimmten Versandmodus lässt sich über den Anzeigenamen ein zusätzlicher Empfänger einschleusen. Gegen einen echten Mailserver bestätigt, als Advisory gemeldet, Schwere moderat. Ein offener Punkt bleibt: Die Testsammlung des Projekts lief in der Prüfumgebung nicht vollständig durch, das ist im Meldetext vermerkt.
- Eine Oberfläche für KI-Chats. Beim Anmelden über einen externen Identitätsanbieter lädt die Anwendung das Profilbild nach. Genau an dieser einen Stelle fehlte die Sperre für interne Adressen, die der Rest des Programms längst hat. Das ergibt einen blinden Server-Side Request Forgery. Bestätigt, der Fix ist eine einzige Zeile, als Advisory gemeldet und inzwischen in Bearbeitung beim Projekt.
- Eine Newsletter-Software. Über die frei ausfüllbaren Felder eines Abonnenten lässt sich Schadcode hinterlegen, der später über eine öffentliche, nicht angemeldete Archivseite ausgeführt wird, ein gespeichertes Cross-Site-Scripting. Bestätigt, Meldung vorbereitet.
- Eine Client-Bibliothek für eine Such- und Analysedatenbank. Eine Dokumentkennung aus zwei Punkten verwandelt das Löschen eines einzelnen Dokuments in das Löschen des ganzen Datenbestands, dazu landet ein Passwort im Info-Protokoll. Ehrlicher Vorbehalt: Dieser Fund ist noch nicht gegen einen echten Server dieser Art verifiziert, deshalb liegt er zurück, bis das steht.
Der richtige Kanal ist nicht immer der naheliegende
Ein Fund ist nur die halbe Arbeit. Er muss dorthin, wo er gehört, und das ist von Projekt zu Projekt verschieden. Die meisten dieser Projekte nehmen Funde vertraulich über die Sicherheitsfunktion ihrer Code-Plattform an, das private Melden direkt am Projekt. Einer der Funde bekommt keinen neuen Alarm, sondern einen Härtungsvorschlag, weil der Kern schon als ältere Lücke bekannt ist und doppelte Meldungen niemandem helfen. Und bei einer Client-Bibliothek zeigt sich, dass der offizielle Weg manchmal ein Umweg ist: Gerade die Client-Bibliotheken werden über das Bug-Bounty-Programm des Herstellers ausdrücklich nicht angenommen, also läuft die Meldung per Direktmail an die Sicherheitsadresse. Den letzten Schritt, das tatsächliche Absenden, gibt jeweils ein Mensch frei. Eine Maschine füllt das Formular, ein Mensch entscheidet über die Offenlegung.
Was man mitnehmen kann
- Die Voreinstellung ist der häufigste Fund. Nicht die raffinierte Kette, sondern der unsichere Standard. Externes Nachladen an, Protokollierung zu gesprächig, eine fehlende Sperre an genau einer Stelle. Prüfe, was passiert, wenn niemand etwas umstellt.
- Verifizieren statt melden. Mehr als eine Spur sah nach einem Fund aus und war bei genauem Hinsehen harmlos, ein hartverdrahteter Wert hier, eine schon bekannte Lücke dort. Jeder Verdacht wurde bestätigt, bevor daraus eine Meldung wurde. Das verhindert Fehlalarme und bewahrt die Glaubwürdigkeit.
- Eine Sperre, die fast überall sitzt, ist genau da gefährlich, wo sie fehlt. Bei der KI-Chat-Oberfläche war der Schutz gegen interne Anfragen fast vollständig, die eine Lücke saß an der unscheinbarsten Stelle.
- Der Meldekanal gehört zur Recherche. Wer einen Fund hat, aber nicht weiß, wohin damit, hat die Arbeit nur halb gemacht.
- Gefunden heißt nicht gepostet. Erst vertraulich melden, dem Projekt Zeit geben, dann reden, und auch dann ohne Anleitung, solange nichts behoben ist.
Aus neun parallelen Durchsichten wurde so ein kleiner Beitrag zur Sicherheit von Software, die viele einsetzen, meist ohne zu wissen, dass sie sie einsetzen.
Weiterlesen: Wenn der Angreifer ein LLM ist · Punkte ohne Wissen: eine Lernplattform im Test · Ein Token, der überall funktioniert: eine Mobilitäts-App im Test