Wir hatten kürzlich zwei Meldungen über kompromittierte Discourse-Seiten, wahrscheinlich aufgrund schwacher Passwörter für Administratorkonten. Daher möchten wir dokumentieren:
- was im Falle einer Kompromittierung zu tun ist
- was wir tun können, um dies in Zukunft besser zu verhindern
Die Datenbank
Bitte beachten Sie, dass Discourse seit mehreren Jahren die folgenden Schutzmaßnahmen für die Seitendatenbank implementiert hat:
-
Links zum vollständigen Herunterladen von Datenbank-Backups werden nur an die gültige E-Mail-Adresse eines Seitenadministrators gesendet. Sie müssen also nicht nur angemeldet sein (durch Schulter-Surfen oder Vergessen des Abmeldens), sondern auch die Kontrolle über die E-Mail-Adresse eines Seitenadministrators innehaben. Und Sie haben 2FA für Ihre E-Mail eingerichtet, oder?
-
Um die E-Mail-Adresse eines Mitarbeiters zu ändern, müssen Sie die Kontrolle über sowohl die alte als auch die neue E-Mail-Adresse verifizieren – während ein normaler Benutzer nur die Kontrolle über die neue E-Mail-Adresse verifizieren muss. Dies macht es wesentlich schwieriger, die E-Mail-Adresse eines Mitarbeiters zu ändern.
-
Wenn Sie den API-Schlüssel der Geolocation-Datenbank konfiguriert haben (dieser ist kostenlos und erfordert eine Registrierung), werden Sie aktiv gewarnt, wenn sich Mitarbeiter von Orten anmelden, die physisch weit von ihrem letzten Anmeldeort entfernt sind.
-
Administratoren, die sich über ein Jahr lang nicht angemeldet haben, müssen ihre E-Mail-Adresse erneut validieren, um die Angriffsfläche zu reduzieren. Die Servereinstellung hierfür lautet
invalidate inactive admin email after days(inaktive Admin-E-Mail nach Tagen ungültig machen) und ist standardmäßig auf 365 eingestellt.
Trotzdem sollten Sie im Falle einer Kompromittierung immer davon ausgehen, dass ein betrügerisches Administratorkonto eine vollständige Kopie der Seitendatenbank/des Backups heruntergeladen hat.
Daher sollten Sie SOFORT alle Kontopasswörter mit dem folgenden Befehl zurücksetzen:
./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'
Zusätzlich müssen Sie alle Benutzer abmelden
./launcher enter app
rails r 'UserAuthToken.destroy_all'
Schließlich müssen Sie alle API-Schlüssel entfernen
./launcher enter app
rails r 'UserApiKey.destroy_all'
rails r 'ApiKey.destroy_all'
Kontopasswörter in der Datenbank
Gemäß unserer Sicherheitsdokumentation verwendet Discourse sehr starke, langsam zu knackende Hashes für in der Datenbank gespeicherte Passwörter:
Discourse verwendet den PBKDF2-Algorithmus, um gesalzene Passwörter zu verschlüsseln. Dieser Algorithmus wird von NIST empfohlen. Sicherheitsexperten im Web stimmen im Allgemeinen zu, dass PBKDF2 eine sichere Wahl ist.
Und die minimale Standardpasswortlänge beträgt 10 für Benutzer und 15 für Administratoren – was es schwierig macht, die Passwort-Hashes durch Brute Force umzukehren, um das Passwort zu erhalten. Dies verhindert jedoch nicht, dass Benutzer ein Passwort wie password1password1 oder etwas anderes Festgelegtes wählen, das selbst mit einem starken Hash trivial umzukehren ist.
E-Mails in der Datenbank
Der Angreifer kann alle E-Mail-Adressen aller Benutzer auf Ihrer Seite einsehen. Dies sind normalerweise vertrauliche Informationen, deren Anzeige selbst für Moderatoren einen Klick erfordert.
Nachrichteninhalt in der Datenbank
Da der Angreifer eine Kopie der Datenbank besitzt, kann er alle in allen Beiträgen gespeicherten Informationen einsehen.
-
Wenn Sie externe Passwörter oder Kontoinformationen in Ihren Antworten weitergegeben haben, ob privat oder öffentlich, sollten Sie diese Passwörter sofort ändern.
-
Wenn Sie sensible Informationen in Ihren Antworten haben, ob privat oder öffentlich, seien Sie sich bewusst, dass der Angreifer diese Informationen einsehen kann.
Verschlüsselte Nachrichten
Wenn Sie das Plugin Discourse Encrypt verwenden, werden verschlüsselte Nachrichten Ende-zu-Ende verschlüsselt. Das bedeutet, dass der Angreifer im Falle eines Datenbanklecks keinen Zugriff auf den Inhalt verschlüsselter Nachrichten erhalten kann.
Vorschriften
Stellen Sie sicher, dass Sie sich bezüglich Ihrer rechtlichen Verpflichtungen professionell rechtlich beraten lassen. Bestimmte Vorschriften wie die DSGVO (GDPR) und CCPA können eine Offenlegung vorschreiben.
Für die Zukunft
Möglicherweise möchten Sie eine Zwei-Faktor-Authentifizierung für Mitarbeiter erzwingen, wenn Sie Grund zu der Annahme haben, dass Ihre Seite angegriffen wird. Die Servereinstellung, die Sie benötigen, lautet „zweiten Faktor erzwingen“ („enforce second factor“)
zweiten Faktor erzwingen (enforce second factor)
Erzwingt, dass Benutzer die Zwei-Faktor-Authentifizierung aktivieren. Wählen Sie „alle“ („all“), um dies für alle Benutzer zu erzwingen. Wählen Sie „Mitarbeiter“ („staff“), um dies nur für Mitarbeiter zu erzwingen.