IT-Sicherheitsforscher haben aus ihrem Honeypot Exploit-Code gefischt, der offenbar eine bislang unbekannte Sicherheitslücke in Fortinet-Web-Application-Firewalls angreift. Die attackierte Schwachstelle erinnert an eine, die Fortinet bereits 2022 mit einem Update geschlossen hatte.

In einem Blog-Beitrag auf pwndefend erörtert der Autor, dass er zusammen mit einem befreundeten IT-Sicherheitsforscher Daten aus einer neuen Honeypotumgebung ausgewertet und dabei Schadcode, der gegen FortiWeb-Firewalls wirkt, bemerkt hat. Erste Untersuchungen ergaben laut einem X-Beitrag von dem Freund, dass der Schadcode auf Virustotal von keinem Malware-Schutz erkannt wurde. Es scheint sich um eine Schwachstelle des Typs Path Traversal zu handeln. Sie erinnert die IT-Forscher an die Fortinet-Schwachstelle CVE-2022-40684 (CVSS 9.8, Risiko „kritisch„), bei der Angreifer die Authentifizierung auf dem Admin-Interface umgehen und mit manipulierten Anfragen ansonsten Admins vorbehaltene Aktionen ausführen können.

Angriffe im Netz

Zum Schutz potenzieller Opfer will der Autor nicht zu sehr in die Details der entdeckten Payload gehen. Die Angreifer senden den Schadcode mittels HTTP-Post-Anfrage an den Endpunkt „/api/v2.0/cmdb/system/admin%3F/../../../../../cgi-bin/fwbcgi“. Darin eingebettet ist eine Befehlssequenz zum Anlegen eines Nutzerkontos. Im Blog-Beitrag liefert der Autor noch Indizien für eine Kompromittierung (Indicators of Compromise, IOCs); die Liste umfasst IP-Adressen, von denen beobachtete Attacken ausgingen, sowie einige Usernamen- und Passwort-Kombinationen, die die analysierte Malware anlegen wollte.

Die IT-Forensiker von watchTowr zeigen auf X in einem kurzen Film, wie der Exploit gegen eine FortiWeb-Firewall ausgeführt wird und dabei ein Admin-Konto anlegt. Sie bestätigten damit die Funktionsfähigkeit des Zero-Day-Exploits. Außerdem haben sie ihn ihrem ‚Detection Artefact Generator‘ hinzugefügt. Von Fortinet gibt es bislang noch keine Hinweise – das letzte Sicherheitsupdate für ein Produkt datiert auf der Webseite auf den 3. November. Als Gegenmaßnahme sollten Admins von FortiWeb-Firewalls sicherstellen, Zugriffe zumindest vorerst auf vertrauenswürdige IP-Adressen zu beschränken, insbesondere dann, wenn das Admin-Interface im Netz zugänglich sein sollte.

(dmk)

Nach dem Bündnis „Offene Netzwerke“ hat nun auch die Agora Digitale Transformation ein Policy Paper veröffentlicht und empfiehlt mehr Investitionen in und Projekte für offene Plattformen. Europas digitale Öffentlichkeit hänge heute an der Infrastruktur weniger globaler Plattformkonzerne. Was als Komfort begonnen habe, sei längst ein sicherheits-, wirtschafts- und demokratiepolitisches Risiko geworden. Deswegen bestehe Handlungsbedarf, um die digitale Souveränität zu stärken. Der Zeitpunkt für die Veröffentlichung ist bewusst gewählt, denn am 18. November findet in Berlin der „Gipfel zur Europäischen Digitalen Souveränität“ des Digitalministeriums statt.

Grundidee der Empfehlungen ist, dass „bestehende, funktionierende Lösungen aus der Nische in den Mainstream“ geführt werden sollen. Die bestehenden „Nischen-Plattformen“ könnten aufgrund einer Reihe von Mängeln und Herausforderungen ihr Marktpotenzial nicht verwirklichen. Dazu gehören laut dem Papier (PDF) unter anderem Design, Produktentwicklung, Rechtssicherheit, Skalierbarkeit oder auch der Schutz vor Desinformation.

Geld für Entwicklung

Die Agora zählt sowohl das Fediverse wie auch das auf dem AT-Protokoll aufbauende BlueSky zu den offenen Plattformen. Um diese zu fördern, seien mehrere Schritte nötig. Dazu zählt der Thinktank Innovationsförderung und Wissensaustausch. Zur Koordination des Themengebietes empfehlen die Autor:innen die Gründung einer „Agentur für resiliente Kommunikation (ARK)“, diese könne Synergien mit der Bundesagentur für Sprunginnovationen SPRIND und der ebenfalls dort angesiedelten Sovereign Tech Agency (STA) nutzen.

Bei der Innovationsförderung sollen konkrete Verbesserungen offener Plattformen bei der Nutzbarkeit oder der Produktentwicklung angeschoben werden, ebenso sollen Ressourcen für den Aufbau eigener Plattform-Instanzen öffentlicher und zivilgesellschaftlicher Träger bereitgestellt werden.

Beim Thema Rechtssicherheit erwarten sich die Autoren unter anderem Rechtshilfe für Startups im Bereich der offenen Plattformen, ebenso wie eine Art Open-Source-Datenbank zur Erkennung von Darstellungen sexualisierter Gewalt gegen Kinder sowie die Anerkennung der Gemeinnützigkeit des Unterhalts offener Plattforminfrastruktur.

Mehr öffentliche Inhalte auf offene Plattformen

Gleichzeitig solle zu den offenen Plattformen geforscht werden. Hierbei stellt sich Agora unter anderem Potenzialanalysen vor, die Chancen und Bedarfe gemeinwohlorientierter Plattformen und Protokolle für Wirtschaft, Sicherheit und Demokratie in Deutschland und Europa konkret aufzeigen und identifizieren.

Auf der Inhaltsebene empfehlen die Autor:innen, dass öffentlich-rechtliche Inhalte nicht nur über die Mediatheken, sondern auch über offene Plattforminfrastrukturen zugänglich gemacht werden. Wie auch das Bündnis „Offene Netzwerke“ fordert Agora die Einführung des „+1-Prinzips“. Dieses zielt auf die Bundesregierung, Behörden sowie öffentliche Institutionen ab, die öffentliche Mittel nutzen, um auf kommerziellen Plattformen zu kommunizieren.

Sie sollen mindestens eine gemeinwohlorientierte Plattform gleichwertig aktiv bespielen müssen. Nutzer:innen, die auf dem Laufenden bleiben möchten, wären damit nicht gezwungen, Accounts bei kommerziellen Plattformen anzulegen. Gleichzeitig könne das „+1-Prinzip“ dezentrale Netzwerke zusätzlich beleben und stärken, so die Hoffnung.

JFrog hat auf der Kundenkonferenz SwampUp Europe in Berlin (12. bis 14. November 2025) eine MCP Registry gezeigt, mit der Entwicklungsteams KI-Quellen über das Model Context Protocol (MCP) sicher in ihre Developer- und Build-Umgebung einbinden.

Mit der Registry, die im ersten Quartal des nächsten Jahres verfügbar sein soll, lassen sich lokale und externe MCP-Quellen an zentraler Stelle in der JFrog-Plattform verwalten, hinzufügen oder sperren. Dabei können Admis Richtlinien aufstellen, nach denen Entwicklerinnen und Entwickler Quellen einbinden und verwenden dürfen. Das geht hin, bis zu einzelnen Funktionen eines Servers: Im auf der Konferenz von JFrog gezeigten Beispiel konnte ein Admin beim MCP-Server von GitHub den Entwicklern beispielsweise verbieten, Repositories anzulegen oder zu löschen.

Die Registry blockiert nicht nur bekannte schädliche Quellen, sondern Admins können Meta-Bedingungen festlegen, beispielsweise, dass eine Quelle nur Open Source sein darf oder einen bestimmten Reifegrad erreicht haben muss: Developer dürfen dementsprechend einen Server erst dann verwenden, wenn er beispielsweise bereits seit vierzehn Tagen verfügbar ist. Letzteres sorgt dafür, dass kurzfristig gehackte und hochgeladene Versionen blockiert sind.

JFrog prüft auch sämtliche Abhängigkeiten von Servern in Containern oder Paketen wie npm. Darüber hinaus dient die Registry als MCP-Gateway, das den Austausch zwischen den IDEs der Entwicklerinnen und Entwicklern sowie der externen Quelle kontrolliert. Die Policies können unternehmensweite Geltung besitzen oder einzelnen Projekten zugeordnet sein.

MCP bedeutet für Unternehmen ein Sicherheitsrisiko, weil Antworten der angebundenen Server lokale Aktionen über KI-Agenten anstoßen können – auch solche mit Lösch-, Spionage- und sonstigem Schadpotenzial.

Schatten-KI finden und regulieren

MCP Registry funktioniert ähnlich wie der von JFrog im September vorgestellte AI Catalog für KI-Modelle. Auch für diesen gab es auf der SwampUp eine Neuankündigung: Das Tool sucht nun gezielt KI-Modelle und -Komponenten im Repository sowie auch in den abhängigen Paketen und Bibliotheken. Diese Modelle sind dann den gleichen Richtlinien unterworfen, die die Verwalter im AI Catalog festgelegt haben. Der AI Catalog dient ebenfalls als Proxy und bietet Monitoring über die KI-Nutzung.

(who)