Google hat in der Nacht zum Donnerstag den Webbrowser Chrome aktualisert. Mit dem Update stopft der Hersteller auch eine bereits in freier Wildbahn attackierte Sicherheitslücke.

Das erklärt Google in der Versionsankündigung. „Google ist bekannt, dass ein Exploit in freier Wildbahn existiert“ schreiben die Entwickler dort und nennen zwar eine Issue-Nummer, halten sich mit etwaigen Details zur Lücke jedoch zurück. Lediglich die Einstufung des Risikos als „hoch“ nennen sie, jedoch nicht einmal die betroffene Komponente des Browsers. Eine CVE-Nummer gibt es offenbar ebenfalls noch nicht.

Insgesamt drei Sicherheitslücken

Zudem gibt es zwei weitere Schwachstellen, die das Release ausbessert. Angreifer können eine Use-after-free-Lücke im Passwort-Manager ausnutzen, was oftmals das Einschleusen und Ausführen von Schadcode ermöglicht. Das scheint jedoch aufgrund der Bedrohungseinschätzung nicht allzu leicht zu klappen (CVE-2025-14372, Risiko „mittel“). Außerdem können bösartige Akteure offenbar eine „unangemessene Implementierung“ in der Toolbar für nicht näher genannte schädliche Aktionen ausnutzen (CVE-2025-14373, Risiko „mittel“).

Chrome-Nutzer und -Nutzerinnen sollten sicherstellen, dass sie die neuen Softwareversionen einsetzen.

Software-Stand prüfen

Die Fehler bessert Google in Chrome 143.0.7499.109 für Android, 143.0.7499.109 für Linux sowie 143.0.7499.109/.110 für macOS und Windows aus. Zudem steht als Extended-Stable-Fassung der Build 142.0.7499.235 für macOS und Windows bereit. Auf der Chromium-Basis aufsetzende Browser wie Microsofts Edge dürften in Kürze ebenfalls in fehlerbereinigter Version vorliegen.

Ob die Software bereits auf aktuellem Stand ist, verrät der Versionsdialog. Der ist über das Browser-Menü, das sich in Chrome durch Klick auf das Symbol mit den drei aufeinander gestapelten Punkten rechts von der Adressleiste öffnet, und dem weiteren Weg über „Hilfe“ – „Über Google Chrome“ erreichbar.

Ist eine Aktualisierung verfügbar, startet das den Update-Vorgang und fordert im Anschluss zum nötigen Browser-Neustart auf. Unter Linux ist in der Regel der Aufruf der distributionseigenen Softwareverwaltung für die Aktualisierung nötig.

Zuletzt hatte Google Mitte November eine Schwachstelle in Chrome stopfen müssen, die bereits von Angreifern aus dem Netz attackiert wurde.

(dmk)

Der Begriff Cyber-Resilienz gerät vermehrt in den Fokus aktueller Projekte der IT-Sicherheit. So zielt die am 6. Dezember 2025 in Kraft getretene Netzwerk- und Informationssicherheitsrichtlinie NIS-2 explizit darauf ab, die Resilienz der Kritischen Infrastruktur zu erhöhen. Der Cyber Resilience Act (CRA), der in genau zwei Jahren am 11. Dezember 2027 vollumfänglich verpflichtend wird, trägt die Resilienz sogar im Namen. Dabei geht es eigentlich darum, Produkte im IT-Umfeld im weitesten Sinne sicher zu gestalten. Da geht es mit der Sicherheit und der Resilienz bereits munter durcheinander.

Überhaupt werden in der IT die Begriffe Security und Resilienz oft parallel oder sogar austauschbar verwendet. Dabei gibt es eigentlich eine klare Unterscheidung. Die IT-Sicherheit bezieht sich primär auf das Vorfeld möglicher Angriffe. Es geht vorwiegend darum, Angriffe zu verhindern oder zumindest deutlich zu erschweren. Resilienz hingegen kommt dann ins Spiel, wenn der Angriff bereits erfolgt ist und man den Betrieb trotzdem weiterführen oder zumindest möglichst schnell wieder aufnehmen muss. Dazu gehört insbesondere die Fähigkeit, sich auf Angriffe – oder auch Unfälle oder Naturkatastrophen – einzustellen.

Trotzdem!

„Cyber-Resilienz bedeutet, trotz Angriffen weiter arbeitsfähig zu bleiben“, erklärt Samira Taaibi vom Fraunhofer IEM. Taaibi leitet eine Studie zum besseren Verständnis von Resilienz und wie man sie erreicht. Eine ihrer ersten Erkenntnisse dazu ist es, dass es immer noch kein einheitliches Verständnis dessen gibt, was Cyber-Resilienz tatsächlich bedeutet und wie man sie aktiv verbessert. Da gibt es zwar die NIST-Definition, an der sich auch Fraunhofer IEM orientiert:

Die Fähigkeit, widrige Umstände, Belastungen, Angriffe oder Kompromittierungen von Systemen, die Cyberressourcen nutzen oder durch diese ermöglicht werden, zu antizipieren, ihnen standzuhalten, sich von ihnen zu erholen und sich an sie anzupassen.

Doch das hilft Unternehmen oder konkret Software-Entwicklern, die ihre Produkte resilienter machen wollen, wenig weiter. Kompakter formuliert, kann man Cyber-Resilienz so definieren:

Die Fähigkeit einer IT-Infrastruktur-Einheit, ihre Aufgabe trotz Störungen und Angriffen weiter zu erfüllen

Wie funktioniert Resilienz?

Man kann die Umsetzung von Resilienz dann in vier grundlegenden Bereiche unterteilen.

1. Antizipieren: Risiken und mögliche Angriffswege frühzeitig erkennen, sich auf Störungen vorbereiten und entsprechende Maßnahmen einplanen.
2. Widerstehen: Angriffe oder Störungen abfedern, sodass der Betrieb nicht oder nur eingeschränkt beeinträchtigt wird.
3. Wiederherstellen: Dienste nach einem erfolgreichen Angriff schnell und kontrolliert zurück in einen funktionsfähigen Zustand bringen.
4. Anpassen: Aus Vorfällen lernen und Systeme so weiterentwickeln, dass ähnliche Angriffe künftig schwerer erfolgreich sind.

Da wird bereits klar, dass es hier um keine statische Eigenschaft geht, die man einmal sicherstellt und dann vergessen kann. Während man einem Produkt die Widerstandsfähigkeit etwa im Rahmen von „Secure by Design“ mit auf den Weg geben kann, erfordert spätestens die Reaktion auf akute Vorfälle in der Regel auch Maßnahmen nach der Inbetriebnahme. Da braucht es dann etwa regelmäßig Mitigations oder Patches für neu entdeckte Sicherheitsprobleme. Und Anpassung benötigt einen Mechanismus, auf die Umgebung und deren Veränderungen so zu reagieren, dass das System insgesamt resistenter wird.

Doch darüber, wie Resilienz in der IT dann ganz praktisch funktioniert und vor allem wie man sie gezielt verbessert, gibt es noch keinen allgemeinen Konsens. An diesem Punkt ist noch Forschung nötig, um das Verständnis zu verbessern – wie Taaibis aktuelle Studie im Rahmen des Forschungsprojekts CyberResilience.nrw. In der geht es darum, wie es um die Cyber-Resilienz in deutschen Organisationen steht; Interessierte können daran übrigens noch bis zum 31.12.2025 teilnehmen.

(ju)

IT-Verantwortliche, die ihre IT mit Barracuda RMM – ehemals unter dem Namen Managed Workplace bekannt – verwalten, sollten schleunigst den bereitstehenden Hotfix 2025.1.1 installieren, sofern das noch nicht geschehen ist. Er schließt mehrere Sicherheitslücken, von denen gleich drei die Höchstwertung CVSS 10 erhalten und damit ein großes Risiko darstellen.

Barracuda selbst veröffentlicht ein PDF zur Ankündigung des Hotfixes und bleibt darin sehr nebulös. „Der Zweck dieses Hotfixes ist es, proaktiv Sicherheitsprobleme rund um Schadcode-Schmuggel und -Ausführung aus der Ferne anzugehen“ schreibt Barracuda und ergänzt: „Diese Schwachstellen wurden nicht missbraucht“. Man empfehle allen Nutzern, ihr Barracuda RMM mit dem Hotfix zu aktualisieren.

Sicherheitslücken mit höchster Risikoeinstufung

In der Nacht zum Donnerstag dieser Woche sind jedoch Schwachstelleneinträge zu den einzelnen Lücken erschienen. So überprüft Barracuda RMM vor der Hotfix-Version 2025.1.1 die URL in einer von Angreifern kontrollierbaren WSDL-Anfrage nicht, die später von der App geladen wird. Das kann zum Schreiben beliebiger Dateien und dem Ausführen beliebigen Codes über einen Webshell-Upload führen (CVE-2025-34392, CVSS4 10.0, Risiko „kritisch“). Außerdem prüft die Software den Namen von Angreifer kontrollierten WSDL-Diensten nicht, was zu unsicheren Reflexionen führen kann. Diese wiederum können zur Ausführung von Schadcode aus dem Netz führen durch das Aufrufen beliebiger Methoden oder der Deserialisierung unsicherer Datentypen (CVE-2025-34393, CVSS4 10.0, Risiko „kritisch“).

Barracuda RMM ermöglicht zudem Zugriff auf einen .Net-Remoting-Dienst, der unzureichend gegen die Deserialisierung beliebiger Datentypen gesichert ist. Auch das lässt sich zur Ausführung von Schadcode aus dem Netz missbrauchen (CVE-2025-34394, CVSS4 10.0, Risiko „kritisch“). Nicht angemeldete Angreifer können zudem eine Path-Traversal_Lücke zum Auslesen beliebiger Dateien in einem exponierten .Net-Remoting-Dienst missbrauchen – das Abgreifen von .Net-Maschinen-Keys ermöglicht das Ausführen von aus dem Netz eingeschleusten Schadcode (CVE-2025-34395, CVSS4 8.7, Risiko „hoch“).

Während Barracuda einen eher nichtssagenden Hinweis auf den Hotfix veröffentlicht hat, liefern die IT-Sicherheitsforscher von watchTowr ein amüsantes Lesestück zu der Grundlage zumindest einer der Schwachstellen bei der WSDL-Verarbeitung (CVE-2025-34392).

Mitte 2023 fiel Barracudas Email Security Gateway (ESG) durch Sicherheitslücken auf, die sich nicht ohne Weiteres schließen ließen. Die Appliances mussten komplett ausgetauscht werden.

(dmk)