Fortinet bezeichnet es nicht so, hat aber einen Patchday im April veranstaltet: Das Unternehmen veröffentlicht 18 Sicherheitswarnungen zu diversen Produkten gebündelt an einem Tag. Einige davon stuft Fortinet als kritisches Risiko ein.

Eine unzureichende Filterung von Elementen, die in einem Befehl ans Betriebssystem von FortiSandbox verwendet werden, ermöglicht Angreifern ohne Authentifizierung das Ausführen von nicht autorisiertem Code oder Befehlen mittels manipulierter HTTP-Anfragen (CVE-2026-39808, CVSS 9.1, Risiko „kritisch“). Zudem können bösartige Akteure an einer Path-Traversal-Schwachstelle in der JRPC-API von FortiSandbox ansetzen, um mit sorgsam präparierten HTTP-Anfragen die Authentifizierung zu umgehen (CVE-2026-39813, CVSS 9.1, Risiko „kritisch“). Betroffen sind die FortiSandbox-Versionszweige 4.4 und 5.0, die Fassungen 4.4.9 sowie 5.0.6 oder neuere bessern die Schwachstelle aus.

Fortinet: Auch hochriskante Sicherheitslücken entdeckt

In FortiDDoS-F 7.2.1 und 7.2.2 können angemeldete Angreifer eine SQL-Injection-Schwachstelle zum Einschleusen beliebiger SQL-Befehle mit manipulierten HTTP-Anfragen missbrauchen (CVE-2026-39815, CVSS 7.9, Risiko „hoch“). Version 7.2.3 und neuer korrigieren das. Angreifer aus dem Netz können außerdem ohne vorherige Authentifizierung mit speziell präparierten Anfragen im oftpd-Daemon von FortiAnalyzer Cloud und FortiManager Cloud 7.6 einen Heap-basierten Pufferüberlauf provozieren und in dessen Folge Schadcode oder beliebige Befehle einschleusen (CVE-2026-22828, CVSS 7.3, Risiko „hoch“). Die Version 7.6.5 oder neuere bessern das aus.

FortiClient EMS filtert bestimmte Elemente, die in SQL-Befehlen genutzt werden, unzureichend und reißt damit eine SQL-Injection-Lücke auf. Das können authentifizierte Angreifer zum Absetzen beliebiger SQL-Abfragen mit manipulierten Anfragen missbrauchen (CVE-2026-39809, CVSS 7.1, Risiko „hoch“). FortiClient EMS 7.0 muss zum Schließen der Lücke auf unterstützte Softwarestände migriert werden, die Fassungen 7.2.13 sowie 7.4.6 und neuere stopfen das Leck.

Fortinet hat noch zahlreiche weitere Sicherheitslücken in mehreren Produkten geschlossen. Deren Risiko stuft das Unternehmen jedoch als mittel oder niedrig ein. Admins mit Fortinet-Produkten in ihrer Umgebung sollten prüfen, ob sie verwundbare Softwarestände einsetzen, und die bereitstehenden Updates anwenden.

Die Fortinet-Patchsammlung im März versorgte ebenfalls 18 Sicherheitslücken mit Softwareflicken. Der höchste Schweregrad war da jedoch das Risiko „hoch“.

(dmk)

Die Entscheidung im Bundeskabinett fiel am Mittwoch ohne großes Aufsehen, doch die Tragweite für den Datenschutz und die globale Menschenrechtslage ist groß. Die Bundesregierung hat offiziell grünes Licht für die Unterzeichnung des seit Jahren umstrittenen Übereinkommens der Vereinten Nationen gegen Computerkriminalität gegeben. Damit bekennt sich Deutschland zu einem Regelwerk, das die internationale Zusammenarbeit bei der Bekämpfung von IT-Straftaten auf eine neue Ebene heben soll.

Im Kern geht es Berlin um einen verbesserten Austausch von Beweismitteln in elektronischer Form (E-Evidence), um bei schweren Straftaten schneller und grenzüberschreitend agieren zu können. Doch was technisch sinnvoll klingt, betrachten zivilgesellschaftliche Organisationen als sicherheitspolitisches trojanisches Pferd.

Schon im Oktober, bei der Unterzeichnung in der vietnamesischen Hauptstadt Hanoi, schlugen Bürgerrechtsorganisationen Alarm. Ihre Sorge gilt dem ersten globalen Abkommen dieser Art, das unter dem Kürzel UNCC (United Nations Convention against Cybercrime) firmiert. Sie sehen darin weniger ein Instrument für mehr Cybersicherheit als einen rechtlichen Rahmen, der grenzüberschreitende Menschenrechtsverletzungen durch Kooperationspflichten begünstigt. Die Staatengemeinschaft betont die Notwendigkeit, der organisierten Kriminalität im Netz Herr zu werden. Die NGOs verlangen indes ein Ende des Ratifizierungsprozesses oder zumindest Nachbesserungen, um elementare Grundrechte zu wahren.

Zwischen Diplomatie und Datenschutz-Sorgen

Das Bundesjustizministerium verteidigt das Mitziehen. Ein Sprecher sagte heise online, dass Deutschland gemeinsam mit der EU und anderen gleich gesinnten Staaten nachdrücklich für die Gewährleistung von Menschenrechtsstandards und entsprechenden Schutzgarantien gekämpft habe. Es seien „entsprechende Mechanismen vorgesehen, um diese bei der Strafverfolgung und der internationalen Zusammenarbeit zu gewährleisten“. Insbesondere gebe es im Rahmen der Kooperation spezifische Zurückweisungsgründe, falls Standards nicht eingehalten werden. Die Bundesregierung bleibe diesem menschenrechtlichen Ansatz auch künftig verpflichtet.

Dennoch richtet sich die Kritik vor allem gegen den fast uferlosen Geltungsbereich der UN-Konvention. Sie beschränkt sich nicht auf klassische Cyberangriffe wie das Knacken von Datenbanken oder das Lahmlegen kritischer Infrastrukturen. Stattdessen verpflichtet sie die Teilnehmer zu einer umfassenden elektronischen Überwachung und zur Kooperation bei einer Vielzahl von Delikten, die oft keinen direkten Bezug zu Informationssystemen haben. Als schwere Straftat wird jedes Delikt eingestuft, das nach jeweiligem nationalem Recht mit mindestens vier Jahren Freiheitsentzug geahndet werden kann.

Ein Erbe von Russland und China

Diese vage Definition öffnet die Tür für Missbrauch. Was in einer Demokratie als legitimer Protest oder investigativer Journalismus gilt, kann in autoritären Regimen als schwere Straftat ausgelegt werden. Aktivisten befürchten, dass die Konvention zur Kriminalisierung von Regierungskritikern und Whistleblowern umgedeutet wird. Da das Abkommen Regierungen dazu auffordert, ohne ausreichende Schutzmechanismen digitale Beweise zu sammeln und diese mit ausländischen Behörden zu teilen, droht das Vertrauen in sichere Kommunikation untergraben zu werden. Die Kritiker warnen auch vor einer Kriminalisierung schutzbedürftiger Gruppen in repressiven Staaten.

Der Vertrag geht auf eine Initiative von Russland und China zurück. Dass ihn nun auch westliche Staaten unterstützen, empfinden Bürgerrechtler als fatale Weichenstellung. Das Justizressort verweist dagegen auf den formalen Charakter der aktuellen Entscheidung: Es handele sich „um einen üblichen vorbereitenden Schritt für die Unterzeichnung eines internationalen Abkommens“. Die eigentliche Ratifizierung werde später erfolgen.

(cku)

OpenSSL 4.0.0 ist erschienen und bringt tiefgreifende Änderungen an der weitverbreiteten Kryptobibliothek. Das Open-Source-Projekt entfernt veraltete Protokolle wie SSLv2 und SSLv3, schafft das Engine-Konzept ab, führt neue Datenschutzfunktionen im TLS-Handshake ein und erweitert die Bibliothek in Richtung Post-Quantum-Kryptografie. Gleichzeitig bereinigen die Entwickler die API und verschärfen sicherheitsrelevante Prüfungen.

OpenSSL gehört zu den zentralen TLS/SSL-Implementierungen und steckt in Webservern, Betriebssystemen, Netzwerkgeräten und unzähligen Anwendungen. Änderungen an der Bibliothek wirken sich unmittelbar auf die Absicherung von Netzwerkverbindungen, Zertifikatsprüfungen und kryptografische Operationen in großen Teilen der IT-Infrastruktur aus.

Neue Kryptografie: ECH, Post-Quantum und mehr

Zu den wichtigsten Neuerungen gehört die Unterstützung für Encrypted Client Hello (ECH) nach RFC 9849. ECH verschlüsselt Teile des TLS-Handshake – insbesondere die Server Name Indication (SNI). Bislang konnten Dritte wie Netzbetreiber anhand der SNI erkennen, welche Domain ein Client ansteuert. ECH verbirgt diese Information und verbessert so den Datenschutz auf Transportebene deutlich.

Neu sind außerdem hybride Schlüsselaustauschverfahren wie curveSM2MLKEM768. Sie kombinieren klassische elliptische Kurven mit Post-Quantum-Algorithmen und sollen Verbindungen schon heute gegen künftige Angriffe durch Quantencomputer absichern: Selbst wenn ein Angreifer eines der beiden Verfahren bricht, schützt das andere weiterhin die Verbindung.

Die Bibliothek ergänzt mehrere kryptografische Primitive und Standards. Dazu zählt die cSHAKE-Funktion nach SP 800-185 – eine flexiblere Variante von SHA-3, die domänenspezifische Hash-Berechnungen erlaubt. Hinzu kommen Unterstützung für den Signaturalgorithmus ML-DSA-MU sowie SM2/SM3 nach RFC 8998, die unter anderem in regulatorischen Kontexten eine Rolle spielen. Zudem führt OpenSSL 4.0.0 Key-Derivation-Funktionen (KDFs) für SNMP und das Secure Real-time Transport Protocol (SRTP) ein, die in Netzwerkmanagement- und VoIP-Szenarien zum Einsatz kommen. Für TLS 1.2 unterstützt OpenSSL nun außerdem standardisierte Finite-Field-Diffie-Hellman-Gruppen (FFDHE) gemäß RFC 7919. Das verbessert die Interoperabilität und vermeidet unsichere oder proprietäre Parameterwahl beim Schlüsselaustausch.

Strengere Validierung und FIPS-Anpassungen

Die Zertifikatsvalidierung wird an mehreren Stellen strenger. Im Strict-Modus prüft OpenSSL nun zusätzlich die Authority Key Identifier (AKID), und auch die CRL-Prüfung erhält weitere Checks. Im FIPS-Modus erzwingt die Bibliothek jetzt Mindestanforderungen bei PBKDF2 – etwa bei der Zahl der Iterationen –, um schwache Konfigurationen zu unterbinden.

Neu ist außerdem die Möglichkeit, FIPS-Selbsttests verzögert auszuführen. Das ist vor allem in containerisierten Umgebungen nützlich.

Entfernte Protokolle, APIs und Altlasten

Mit Version 4.0 räumt OpenSSL konsequent auf. Neben SSLv2 und SSLv3 fällt auch das Engine-Konzept weg. Hardwarebeschleunigung und externe Kryptomodule laufen künftig ausschließlich über die Provider-Architektur, die Engines bereits seit OpenSSL 3.0 ablöst. Ebenfalls entfernt: feste TLS-Versionsmethoden, ältere elliptische Kurven, diverse Low-Level-Funktionen und das Skript c_rehash. Stattdessen sollen Nutzer openssl rehash verwenden.

Bei der API gibt es mehrere Änderungen, die Anpassungen im Anwendungscode erfordern können. Zahlreiche Funktionssignaturen tragen jetzt const-Qualifier, der Datentyp ASN1_STRING ist nun vollständig gekapselt – Zugriff auf seine internen Felder ist nur noch über Zugriffsfunktionen möglich. Auch die Ausgabe von Hex-Dumps wurde standardisiert: Signaturen werden in 24-Byte-Blöcken dargestellt, alle anderen Daten in 16-Byte-Blöcken. Das soll die Lesbarkeit verbessern und die Ausgabe konsistenter machen. Und veraltete Funktionen zur Zeitprüfung von Zertifikaten weichen der neuen Funktion X509_check_certificate_times(). Auch beim Laufzeitverhalten gibt es Änderungen: OpenSSL verzichtet künftig auf automatisches Aufräumen globaler Daten über atexit() und setzt stärker auf Standardfunktionen der C-Laufzeitbibliothek, etwa bei snprintf.

Für Entwickler und Betreiber bedeutet das Release mehr Sicherheit und modernere Kryptografie – bei gleichzeitig erhöhtem Migrationsaufwand. Anwendungen, die direkt auf OpenSSL-APIs zugreifen oder ältere Funktionen nutzen, müssen angepasst werden. OpenSSL 4.0 legt damit die Grundlage für den Übergang zu post-quantenresistenten Verfahren und besseren Datenschutz im TLS-Handshake. Details zum neuen Release finden sich auf der zugehörigen GitHub-Projektseite.

(fo)