Wenn Sie ein Plugin oder Ihr CMS aktualisiert haben, nachdem Sie einen meiner Sicherheitshinweise erhalten haben: gut. Das war der wichtige Schritt, und für viele Websites ist es der einzige nötige Schritt.

Ein Update schließt die Lücke von jetzt an. Es kann Ihnen nicht sagen, ob jemand die Lücke gefunden hat, bevor Sie sie geschlossen haben. Diese Seite ist eine praktische Selbstprüfung von etwa 30 Minuten, mit der Sie diese Frage selbst beantworten können, geschrieben für Website-Betreiber ohne Sicherheitshintergrund und ohne Sicherheitsbudget. Es sind allgemeine Hinweise, keine Feststellung über Ihre Website: von außen kann ich sehen, welche Softwareversion eine Website meldet, und sonst nichts.

Schritt 1: Prüfen Sie, was die Schwachstelle tatsächlich bewirken kann

Nicht jede Schwachstelle verdient dieselbe Reaktion. Suchen Sie Ihren Hinweis auf der Seite für Website-Betreiber und sehen Sie nach, in welche Klasse er fällt (jede Hinweisseite nennt das weiter oben):

  • Kontoübernahme oder Codeausführung (ein Angreifer könnte Administratorzugang erlangen oder eigenen Code ausführen): arbeiten Sie die vollständige Checkliste unten durch.
  • Lesen von Daten (ein Angreifer könnte Informationen aus Ihrer Datenbank lesen, Ihre Website aber nicht verändern): konzentrieren Sie sich auf die Schritte 2 und 5. Die Frage ist, welche Daten gespeichert waren, nicht ob Ihre Website verändert wurde.
  • Engere Probleme (Schwachstellen, die eine bestimmte Konfiguration voraussetzen oder die nur eine Administrationsseite erreichen): die Hinweisseite zu Ihrer Komponente sagt, was gegebenenfalls zu prüfen ist. Oft genügt das Update allein.

Schritt 2: Bestimmen Sie Ihren Zeitraum der Gefährdung

Zwei Daten begrenzen den Zeitraum, auf den es ankommt:

  1. Wann die Lücke auf Ihrer Website entstand. Üblicherweise an dem Tag, an dem Sie die betroffene Version installiert haben. Wenn Sie das Datum nicht kennen, ist das Datum des CVE-Eintrags aus dem Hinweis (von jeder Hinweisseite verlinkt) ein brauchbarer Ersatz: ab der Veröffentlichung wussten auch Angreifer Bescheid.
  2. Wann Sie aktualisiert haben. Der Tag, an dem Sie die Lücke geschlossen haben.

Alles Weitere bezieht sich auf diesen Zeitraum. Ist er kurz, haben Sie also etwa innerhalb von ein oder zwei Tagen nach dem Eintrag aktualisiert, ist Ihr Risiko real, aber klein. Erstreckt sich der Zeitraum über Monate, nehmen Sie die Checkliste ernst.

Schritt 3: Sehen Sie nach, wer auf Ihre Website zugreifen kann

Ein Angreifer, der hineingekommen ist, verschafft sich fast immer einen Weg zurück. Prüfen Sie der Reihe nach:

  • Administratorkonten. In WordPress: Benutzer, dann nach Administrator filtern. In Joomla: Benutzer, dann Benutzerverwaltung. Achten Sie auf jedes Konto, das Sie nicht selbst angelegt haben. Einschränkung: manche Schwachstellen (etwa die bei Simple Membership) erlauben es einem Angreifer, ein bestehendes Konto zu übernehmen, statt ein neues anzulegen. Diese Prüfung allein beweist also nichts. Genau deshalb ist der Wechsel der Zugangsdaten in Schritt 4 auch dann wichtig, wenn die Benutzerliste sauber aussieht.
  • Kürzlich hinzugefügte Plugins, Themes oder Erweiterungen, die Sie nicht installiert haben.
  • Geplante Aufgaben (in WordPress zeigt das Plugin WP Crontrol sie an; viele Hintertüren installieren sich über eine geplante Aufgabe selbst wieder).
  • Anwendungspasswörter (WordPress: Benutzer, Profil, Anwendungspasswörter), ein unauffälliger Weg, den API-Zugang auch nach einem Passwortwechsel zu behalten.

Schritt 4: Wechseln Sie die Zugangsdaten

Wenn Ihr Hinweis in die Klasse Kontoübernahme oder Codeausführung fiel und Ihr Zeitraum der Gefährdung länger als ein paar Tage war, wechseln Sie die Zugangsdaten auch dann, wenn Schritt 3 nichts ergeben hat:

  • Die Passwörter aller Administratorkonten.
  • Die Geheimschlüssel und Salts in wp-config.php (WordPress). Damit werden alle abgemeldet, auch ein Angreifer mit einer gestohlenen Sitzung; der offizielle Generator liefert frische Werte. In Joomla ist das Gegenstück der Wert $secret in configuration.php.
  • Die Passwörter für Ihr Hosting-Panel und FTP/SFTP, falls sie mit anderen geteilt werden oder alt sind.

Das kostet zehn Minuten und schließt die Tür für gestohlene Sitzungen und geknackte Passwort-Hashes, ganz gleich ob es einen Einbruch gab.

Schritt 5: Scannen und Dateien prüfen

  • Lassen Sie den Malware-Scan Ihres Hosting-Anbieters laufen, falls das Panel einen anbietet (die meisten Shared-Hosting-Anbieter tun das), oder einen seriösen kostenlosen Scanner. Für WordPress vergleicht der kostenlose Scan von Wordfence Ihre Dateien mit den offiziellen Kopien.
  • Sehen Sie sich kürzlich geänderte Dateien rund um den Beginn Ihres Zeitraums der Gefährdung und danach an, insbesondere PHP-Dateien in Upload-Verzeichnissen. Dort sollte praktisch nie PHP liegen.
  • Wenn Ihr Anbieter Zugriffsprotokolle aufbewahrt, überfliegen Sie den Zeitraum nach Anfragen an die verwundbare Komponente von Adressen, die Sie nicht kennen. Dass sich dort nichts findet, sagt wenig aus, da Protokolle rotieren, aber ein Treffer ist eindeutig.

Wenn die Selbstprüfung etwas zutage fördert

Löschen Sie noch nichts. Erstellen Sie zuerst eine vollständige Sicherung, Dateien und Datenbank, damit sich das Geschehene noch untersuchen lässt. Dann, nach Aufwand geordnet:

  1. Ihr Hosting-Anbieter. Die meisten haben einen Dienst zur Malware-Bereinigung oder bestätigen zumindest, was ihre eigenen Scanner sehen. Für die meisten kleinen Websites ist das die richtige erste Anlaufstelle.
  2. Eine Fachkraft. Wenn die Website Kundendaten oder Zahlungen verarbeitet oder der Scan eine Hintertür gefunden hat, lohnt es sich, jemanden dafür zu bezahlen festzustellen, worauf zugegriffen wurde; das Datenschutzrecht hängt vielerorts an dieser Antwort.
  3. Die radikale Lösung, die immer funktioniert: stellen Sie eine Sicherung wieder her, die vor dem Zeitraum der Gefährdung liegt, oder installieren Sie CMS und Plugins neu aus offiziellen Quellen und übernehmen nur Ihre Inhalte. Aktualisieren Sie danach alles und wechseln Sie alle oben genannten Zugangsdaten.

Wenn Sie nicht sicher sind, was Sie da vor sich haben, können Sie auch einfach auf die Hinweis-E-Mail antworten. Ich lese jede Antwort, und jemanden in die richtige Richtung zu weisen gehört zu den Gründen, warum ich diese Hinweise überhaupt verschicke. Ich verkaufe keinen Bereinigungsdienst, und diese Seite ist kein Verkaufsangebot; siehe die Offenlegungsrichtlinie.

Wenn Sie schon vor meiner E-Mail aktualisiert hatten

Es gilt dieselbe Logik: der Hinweis bedeutet, dass Ihre Website vor Kurzem eine betroffene Version gemeldet hat, es gab also einen Zeitraum der Gefährdung, auch wenn er inzwischen vorbei ist. Die Schritte 2 bis 4 beantworten weiterhin die Frage, auf die es ankommt.