Die N-central-Schwachstelle zeigt das Risiko für MSPs auf: Was der N-able-Vorfall für Ihre RMM-Sicherheit bedeutet?

Ihr RMM-System verfügt über administrativen Zugriff auf jedes von Ihnen verwaltete Gerät und das unbeaufsichtigt, rund um die Uhr und in allen von Ihnen betreuten Kundenumgebungen. Dieser Zugriff ist keine Funktion. Er ist das Produkt. Und genau deshalb gehört die Wahl Ihres RMM-Anbieters zu den folgenreichsten Entscheidungen in Ihrem gesamten Tech-Stack. Der Grund sind nicht die Folgen eines reibungslosen Ablaufs, sondern die Folgen eines nicht reibungslosen Ablaufs.

Am 1. August veröffentlichte N-able die CVE-2026-18577, eine kritische Sicherheitslücke in N-central, der RMM-Plattform, die tausende MSPs für das zentrale Patchen und den Remotezugriff auf jedes verwaltete Gerät bei ihren Kunden einsetzen, durch die Angreifer die Technikerkonsole ohne gültige Anmeldedaten administrativ übernehmen konnten. Nachdem sie sich Zugriff verschafft hatten, nutzten die Angreifer die integrierte Fernsteuerungsfunktion von N-central, um auf verwaltete Endpunkte in mehreren Unternehmen zuzugreifen – darunter auch Domain-Controller. N-able stellte am 2. August einen Hotfix bereit (Der Vorfallbericht von Huntress enthält den vollständigen Ablauf). Noch in derselben Woche nahm die CISA die Schwachstelle in den Katalog der bekannten, aktiv ausgenutzten Schwachstellen auf und verpflichtete US-Bundesbehörden dazu, innerhalb weniger Tage einen Patch einzuspielen.

Als ich von dieser Schwachstelle erfuhr, musste ich an die Gespräche zurückdenken, die wir 2021 bei der Entwicklung von LogMeIn Resolve geführt hatten. Das war kurz nach einem groß angelegten und viel beachteten Lieferkettenangriff. Einer unserer leitenden Ingenieure sagte damals mit Nachdruck voraus, dass solche Angriffe weiter zunehmen würden und wir einen anderen Ansatz brauchten, um unsere Kunden zu schützen. Genau das haben wir getan: Mit der Zero-Trust-Architektur von Resolve und zusätzlichen Sicherheitskontrollen, die verhindern sollen, dass eine einzelne Kompromittierung auf der Managementebene Auswirkungen auf alle nachgelagerten Systeme hat, also auf jede verwaltete Umgebung, für die ein MSP verantwortlich ist.

Die Architektur von Resolve basiert auf der Annahme, dass der Server irgendwann kompromittiert wird. Die Frage, die wir uns gestellt haben, ist dieselbe, die ich heute jedem RMM-Anbieter stellen würde: „Was kann ein Angreifer tatsächlich tun, wenn die Infrastruktur kompromittiert wurde?“ Bei LogMeIn Resolve lautet die Antwort: Er kann nicht auf Ihre Endgeräte zugreifen. Der Zero-Trust-Signaturschlüssel verhindert, dass Angreifer privilegierte Aktionen auf verwalteten Endgeräten ausführen können, da niemand, nicht einmal der Anbieter, über diesen Schlüssel verfügt.

Die Architektur ist eine der wichtigsten Überlegungen, aber nicht die einzige. Es gibt noch weitere Aspekte, die Sie berücksichtigen sollten. Bevor Sie also Ihr nächstes Verlängerungsgespräch führen oder eine neue Plattform evaluieren, finden Sie hier sechs Fragen, die Sie Ihrem RMM-Anbieter stellen sollten.

Die meisten MSPs, mit denen ich spreche, betrachten ihr RMM-Bereitstellungsmodell als reine IT-Frage. Tatsächlich ist es jedoch eine Sicherheitsentscheidung, die viel zu selten auch als solche behandelt wird.

Bei On-Premises-Geräten gibt es ein unterschätztes Problem: Es handelt sich um Server, die gepatcht, gehärtet und durch Endpunktschutz abgesichert werden müssen. In der Praxis werden sie jedoch selten entsprechend behandelt. Sie sind keine Workstations, weshalb EDR-Lösungen sie häufig nicht abdecken. Sie sind aber auch kein Cloudservice, sodass niemand außer Ihnen den Sicherheitsstatus überwacht. Gleichzeitig befinden sie sich in Ihrem Netzwerk und verfügen über weitreichende Zugriffsrechte auf jedes von Ihnen verwaltete Gerät.

Der Vorfall bei N-able hat dieses Muster nahezu exakt bestätigt: Die N-central-Appliance läuft auf einer speziell abgesicherten Linux-Version und verfügt laut externen Incident-Response-Teams in der Regel nicht über eine EDR-Lösung, da sie wie eine Appliance und nicht wie ein Server verwaltet wird.

Bei einer Cloud-nativen Bereitstellung übernimmt der Anbieter diese Verantwortung. Ob das tatsächlich einen Unterschied macht, hängt vollständig davon ab, wie gut der Anbieter diese Infrastruktur abgesichert und geprüft hat. Genau darum geht es in den Fragen 3 und 6.

Fragen Sie Ihren Anbieter: „Wenn ich Ihr Produkt On-Premises betreibe, welche Verantwortung trage ich für die Absicherung des Servers? Wird EDR darauf unterstützt und empfohlen?“

Das ist wohl die wichtigste Architekturfrage in dieser Liste. Sie sollte bei Gesprächen mit einem Anbieter ganz oben auf der Agenda stehen. Die Antwort verrät Ihnen nahezu alles, was Sie über die Architektur eines Anbieters wissen müssen.

In einer herkömmlichen Architektur mit serverbasiertem Vertrauensmodell ist der Server ein vertrauenswürdiger Knoten. Erlangt ein Angreifer administrativen Zugriff darauf, übernimmt er auch dieses Vertrauen, einschließlich der Möglichkeit, Befehle, Skripte und Remotesitzungen an jedes damit verbundene verwaltete Gerät zu senden. Das Backend ist der Schlüssel zum gesamten System. Genau das zeigte sich beim N-able-Vorfall: Nachdem Angreifer die Konsole kompromittiert hatten, haben sie deren integrierte Remotesteuerungsfunktion genutzt, um auf verwaltete Endpgeräte zuzugreifen. Darunter befanden sich auch Domain-Controller in mehreren Unternehmen. Genau dieses Architekturmodell soll der Zero-Trust-Ansatz von LogMeIn Resolve überwinden.

Eine Zero Trust-Architektur funktioniert nach einem anderen Prinzip. Jeder an einen verwalteten Endpunkt gesendete Befehl wird mit dem privaten Schlüssel des Technikers signiert. Das ist ein Schlüssel, der das Gerät des Technikers niemals verlässt. Der Endpunkt überprüft die Signatur, bevor ein Befehl ausgeführt wird. Ein kompromittierter Backend-Server kann daher keine schädlichen Befehle senden, da er von vornherein nicht über den privaten Schlüssel verfügt. Im Backend liegt ausschließlich der öffentliche Schlüssel, aus dem sich der private Schlüssel nicht ableiten lässt. Jeder Befehl, der die Signaturprüfung nicht besteht, wird direkt auf dem Gerät verworfen, anstatt ausgeführt zu werden.

David Bisztrai, VP of Engineering für die LogMeIn-Produktlinie bei GoTo, beschreibt es so: „Stellen Sie sich einen großen Tresor in einer Bank vor. Bei einem herkömmlichen System graben sich Angreifer einen Tunnel hinein und finden, sobald sie drinnen sind, den eigentlichen Schatz: die Endgeräte. Das Backend kommuniziert mit dem Gerät, das Gerät vertraut ihm und führt jeden empfangenen Befehl aus. Unsere Zero-Trust-Architektur geht von derselben Annahme aus, nämlich dass irgendwann jemand einen Tunnel zu unserem Tresor findet. Dort angekommen ist jedoch kein Schatz auffindbar. Stattdessen gibt es Tausende kleiner Schließfächer, die jeweils nur mit einem Signaturschlüssel geöffnet werden können, der sich in den Händen des Kunden befindet, nicht in unseren. Selbst wenn Sie den Tresor erreichen, können Sie nichts öffnen.“

Dies ist eine Frage des Designs, nicht des Patchings. Kein Hotfix kann nachträglich ändern, auf welchem Architekturmodell der Anbieter seine Lösung aufgebaut hat.

Fragen Sie Ihren Anbieter: „Wenn Ihre Infrastruktur vollständig kompromittiert wäre: Was würde einen Angreifer daran hindern, Ihre Plattform zu nutzen, um auf meine verwalteten Endpunkte zuzugreifen?“

Geschwindigkeit ist entscheidend. Vollständigkeit ist noch wichtiger. Das sind zwei unterschiedliche Fragen und genau in diesem Unterschied liegt das eigentliche Risiko.

Ein Patch, der den gemeldeten Angriffsvektor schließt, während ein angrenzender Angriffsvektor offen bleibt, kann ein trügerisches Gefühl der Sicherheit vermitteln. Nachfolgende Patches für RMM-Schwachstellen sind in der gesamten Branche keine Seltenheit, und der N-able-Vorfall ist nur ein Beispiel dafür. Angreifer haben einen neuen Angriffsvektor genutzt, der mit dem vorherigen Fix zusammenhing.

Angreifer müssen keine neue Schwachstelle finden. Es reicht, wenn der Patch des Anbieters unvollständig ist.

Die Frage lautet nicht nur: „Wie schnell implementieren Sie einen Patch?“ Sondern auch: „Wie stellen Sie sicher, dass der Fix tatsächlich vollständig ist?“

Fragen Sie Ihren Anbieter: „Wann haben Sie zuletzt einen Folge-Patch für eine Schwachstelle veröffentlicht, von der Sie dachten, sie sei bereits behoben? Was hat Ihr Testverfahren beim ersten Mal übersehen?“

Dies ist eine logistische ebenso wie eine sicherheitsrelevante Frage. Es ist die Frage, die die meisten MSPs erst stellen, wenn ein Patch bereits seit einer Woche verfügbar ist und die Hälfte der selbst gehosteten Server weiterhin exponiert bleibt.

Bei cloudbasierten Bereitstellungen verteilt der Anbieter Sicherheitskorrekturen zentral. Viele Benutzer merken nicht einmal, dass ein Patch veröffentlicht wurde. Bei lokalen Bereitstellungen liegt diese Aufgabe bei Ihnen.

Der N-able-Vorfall brachte konkrete Zahlen zu dieser Lücke. Laut der Telemetrie von Huntress waren in der eigenen Partner- und Kundenbasis am ersten Tag nach Veröffentlichung des Hotfixes durch N-able noch mehr als die Hälfte der erreichbaren cloudgehosteten N-central-Server ungepatcht. Beim nächsten Update war das Patchen der Cloudsysteme weitgehend abgeschlossen. Bei den erreichbaren selbst gehosteten Servern waren jedoch noch immer fast drei von zehn ungepatcht.

„Ein Patch-Rückstand in der Praxis ist kein Rundungsfehler. Es sind die langsamsten zehn oder zwanzig Prozent der Geräte, die den Anschluss nie ganz schaffen. Und genau auf diesen Teil haben es Angreifer abgesehen“, so Steve Shattuck, Vice President of Global Partner Ecosystems bei GoTo.

Fragen Sie Ihren Anbieter: „Wie viele Ihrer Kunden verwenden bei einem kritischen Sicherheits-Hotfix 48 Stunden nach dessen Veröffentlichung typischerweise noch eine verwundbare Version? Und woher wissen Sie das tatsächlich?“

Verschlüsselung ist ein grundlegender Standard. Entscheidend ist vielmehr, ob die Plattform Berechtigungskontrollen durchsetzt, einen lückenlosen Audit-Trail führt und Endanwender echte Kontrolle über ihre eigenen Geräte gibt. Was Anbieter wirklich voneinander unterscheidet, sind die Funktionen, die über die grundlegende Verschlüsselung von Sitzungen hinausgehen.

Besondere Aufmerksamkeit verdient dabei der unbeaufsichtigte Zugriff. Wie wird er eingerichtet? Wer genehmigt ihn? Wer kann ihn widerrufen? Diese Fragen bestimmen, welchen Risiken Sie selbst ausgesetzt sind und ob Sie Ihren Kunden nachvollziehbar erklären können, wie tatsächlich auf ihre Systeme zugegriffen wird.

Fragen Sie Ihren Anbieter: „Kann ein Benutzer den unbeaufsichtigten Remotezugriff selbst widerrufen, ohne sich dafür an den MSP wenden zu müssen? Wo ist diese Funktion dokumentiert und für die Benutzer sichtbar?“

Es macht einen Unterschied, ob ein Anbieter sagt: „Sicherheit hat für uns höchste Priorität“, oder ob er Zertifizierungen vorweisen kann, für deren Erlangung eine Überprüfung durch einen unabhängigen Prüfer erforderlich war. Das Erste ist eine Aussage. Das Zweite ist ein Nachweis.

Nach diesen Zertifizierungen sollten Sie fragen: ISO/IEC 27001:2022, SOC 2 Type II und BSI C5. Jede davon steht für eine externe, auditierte Überprüfung von Sicherheitskontrollen und nicht für eine interne Bewertung, die der Anbieter selbst vorgenommen hat. Externe Penetrationstests durch unabhängige Drittanbieter bieten darüber hinaus eine zusätzliche, wertvolle Sicherheitsebene, auf die viele Anbieter verzichten.

Fragen Sie Ihren Anbieter: „Welche Zertifizierungen besitzen Sie und wann wurden diese zuletzt auditiert? Führen Sie externe Penetrationstests durch und können Sie den Umfang dieser Tests offenlegen?“

Kein Anbieter kann eine Zukunft ohne Vorfälle versprechen. Das gilt auch für uns. Die Frage war nie: „Hatte dieser Anbieter schon einmal ein Sicherheitsproblem?“ Sie lautet vielmehr: „Wie begrenzt die Architektur des Anbieters den Schaden, wenn etwas schiefläuft?“

Ein Zero-Trust-Modell, das den Zugriff auf Endpunkte kryptografisch von einer Kompromittierung des Backends isoliert, ist strukturell widerstandsfähiger. Nicht, weil es jeden Angriff verhindert, sondern weil es verhindert, dass sich eine bestimmte Angriffsklasse zu einer katastrophalen Kaskade ausweitet. Das ist eine Eigenschaft der Architektur. Sie ist entweder vorhanden oder nicht.

LogMeIn Resolve wurde auf diesem Modell aufgebaut, weil unser Engineering-Team frühzeitig davon ausging, dass RMM-Plattformen zu wertvollen Zielen für Lieferkettenangriffe werden würden. Der jüngste Vorfall bei N-central unterstreicht, warum dieser architektonische Ansatz so wichtig ist.

Wenn Sie derzeit ein RMM-System nutzen, das auf einem herkömmlichen serverbasierten Vertrauensmodell basiert, sollten Sie diese sechs Fragen noch diese Woche stellen und nicht erst bei Ihrer nächsten Vertragsverlängerung.