Veröffentlicht am
Heute haben rbb24 und Süddeutsche Zeitung über einen Datenskandal beim Deutschen Roten Kreuz (konkret: Bei einem Kreisverband aus Brandenburg) berichtet. Wir selbst haben von diesem Vorfall am Abend des 31.01.2020 durch die Journalisten dieses Beitrags erfahren und in der gleichen Nacht noch die betroffenen Webseiten gesperrt.
Vorab: Das Wichtigste für alle anderen DRK-Gliederungen
Im Artikel ist von einem "schlecht gesicherten Server" die Rede, im TV-Beitrag sieht man im Hintergrund typische DRK-Webseiten. An dieser Stelle möchten wir Sie beruhigen: Die Formulierung ist denkbar schlecht gewählt, nicht die Server (in Form unseres Webhostings) waren schlecht gesichert, sondern die Server-Software (also das vom DRK im Raum Brandenburg genutzte CMS eines dortigen Entwicklers).
Auch die Bildschirm-Ausschnitte, die auf DRKCMS-Webseiten hinweisen, sind irreführend: Keine DRKCMS-Webseite war jemals von dem Problem betroffen. Die entsprechenden DRK-Gliederungen nutzten überhaupt kein DRKCMS, sondern ein eigenes, selbst geschriebenes (unsicheres) CMS. Lediglich der Landesverband Brandenburg setzte beides ein, eine DRKCMS-basierte Webseite (die ist im TV zu sehen) und davon völlig unabhängig ein Ausbildungsportal auf Basis der unsicheren Software (das war angreifbar, aber wurde nicht im Beitrag gezeigt).
Was ist genau passiert?
Der besagte Kreisverband hat (wie auch einige andere in Brandenburg) ein sog. Content-Management-System (CMS), also eine Software zur Bearbeitung der Webseite eingesetzt. Dieses war aufgrund von Programmierfehlern anfällig für sog. SQL-Injections.
Über eine solche SQL-Injection wurde einerseits der Einbruch in das CMS nachgewiesen, andererseits wurden auch Daten aus einer daneben liegenden Einsatzdatenbank abgegriffen. Diese hatte möglicherweise mit dem CMS gar nichts zu tun, nutzte aber das gleiche Datenbank-Passwort (d.h. der Angreifer auf das CMS hatte auch darauf Zugang).
Ebenfalls konnten über dieses CMS auch Kursangebote gebucht werden. Da, wo das der Fall ist, hätten über diese SQL-Injection auch Teilnehmerdaten abgefragt werden können. Ob das passiert ist, wissen wir nicht.
Wie funktioniert (für Nicht-Techniker) eine SQL-Injection?
Zur Erklärung schauen wir uns mal einen Telefonstreich des jungen Bart Simpson an (Video):
- Bart Simpson ruft in Moes Taverne an und bittet, darum Herrn Reinsch sprechen zu dürfen
- Moe legt den Hörer zur Seite und ruft in seine Bar: "Hört mal her: Gibt es hier jemanden, der Reinsch heißt?"
- Die Gäste verstehen etwas anderes und lachen Moe aus.
Das ist das Grundprinzip einer SQL-Injection: Sie bringen das CMS "Moe" dazu, intern eine Frage zu stellen, die er für harmlos hält, die aber vom Empfänger (den Gästen, im realen Angriff: der Datenbank) anders aufgefasst wird.
Nun erscheint das nicht sofort gefährlich. Aber fragen wir nach dem gleichen Muster mal, ob Herr "Dasfin Anzamtbesch" da ist. Moe wird auch diese Frage an seine Gäste weitergeben, und sie werden hören: "Ist hier jemand, der das FinAnzamt bescheißt?".
Das gefährliche an diesem Angriff ist, dass die Gäste ja nicht wissen, dass die Frage von draußen von einem Fremden kommt. Sondern Moe stellt sie ihnen - und sie vertrauen Moe, werden ihm also antworten.
Wenn Sie sich das ganze noch als humorlose Software-Produkte vorstellen, dann wird bei einer Frage nach dem Finanzamt auch niemand lachen, sondern die Gäste geben Moe die ehrliche Antwort, und Moe gibt sie am Telefon weiter – der Angreifer erfährt, wer von Moes Gästen beim Finanzamt schummelt, obwohl er das nie hätte erfahren dürfen.
Übrigens könnte Bart Simpson am Telefon auch nach Herrn "Müller heißt? Alle anderen trinken bitte, bis Ihr in die Hosen sch" fragen. Der Moe aus der Serie würde spätestens dann stutzig werden. Ein schlecht programmiertes CMS aber würde auch diese Frage dann an die Datenbank stellen: "Hört mal her: Gibt es hier jemand, der Müller heißt? Alle anderen trinken bitte, bis Ihr in die Hosen scheißt" – und damit, jetzt wird es richtig gefährlich, kann ein Angreifer auch Moe dazu bringen, seinen Gästen Anweisungen zu erteilen.
Bezogen auf IT-Sicherheitslücken heißt das: Man nutzt z.B. die Suchfunktion eines CMS, um dort – getarnt als Suchbegriff – weitere SQL-Kommandos für den Datenbank-Server einzubauen (zu injizieren).
Was kann man gegen SQL-Injections tun?
Es gibt verschiedene Ansätze, SQL-Injections zu erkennen und/oder zu vereiteln. Aber die Haupt-Arbeit für den Entwickler ist: Validierung der Eingaben. Die wichtigste Regel, die ein Web-Entwickler beherzigen muss, ist: Traue niemals einer Information, die vom Browser (also dem Anwender) kommt.
Wenn man vom Browser eine Id (für eine aufzurufenden Datensatz) bekommt, dann darf man natürlich nicht direkt mit dieser Id in der Datenbank den entsprechenden Eintrag suchen. Sondern man muss prüfen (oder durch Umwandlung erzwingen), dass diese Id nummerisch ist. Besser noch wäre zu prüfen, ob es eine Zahl ist einem Bereich ist, der als Id in Frage kommt.
Wenn ein Benutzer ein Formular ausfüllt, in dem er seinen Namen und seine Mail-Adresse angeben muss, dann muss man überprüfen, ob das ein plausibler Name ist – nicht zu lang, nicht zu kurz, nur Buchstaben, Bindestriche und maximal eine Handvoll Leerzeichen. Und die Mail-Adresse sollte eine Syntax haben, die zu einer Mail-Adresse passt. Dann, und auch nur dann, darf man davon ausgehen, dass das wirklich ein Name oder eine Mail-Adresse ist und entsprechend weiter-verarbeiten.
Das ist aufwendig. Das ist wartungsintensiv – ein vergessener Accent, Ø oder ç führen zu notwendiger Nacharbeit, und wenn eine neue stylische Domain-Endung auf den Markt kommt, entpuppt sich vielleicht auch Deine Syntax-Prüfung der Mail-Adressen als veraltet. Aber nur so kann man wirkungsvoll verhindern, dass im Feld Name etwas anderes eingeschleust wird als der Name.
Wer trägt in diesem Fall die Schuld?
Es ist nicht unsere Aufgabe, den Fall juristisch aufzuarbeiten. Vertraglich lagen die betroffenen Webseiten alle im sog. klassischen Webspace, bei dem wir lediglich den Speicherplatz auf unseren Servern bereitstellen. Die Entscheidung für eine bestimmte Software, für deren Wartung und Sicherheitsupdates, sowie für notwendige Server-Einstellungen rund um diese Software trägt der Kunde.
Um bei Moes Taverne zu bleiben: Wir sind lediglich der Vermieter der Räumlichkeiten. Die Entscheidung, dort einen Barkeeper ans Telefon zu lassen, der so dumm ist und auf Telefonstreiche reinfällt, trägt der Pächter (in diesem Fall der DRK-Kreisverband).
Tatsächlich haben die Kreisverbände wohl dem regionalen Dienstleister vertraut, der ihr CMS programmiert hat.
Zum Vergleich: Wie sicher ist das DRKCMS?
Einhundertprozentige Sicherheit gibt es nie. Mit entsprechend großem Werkzeug wird man irgendwann auch auf unsere Server und aktuelle TYPO3s hacken können.
Dennoch genießen Sie beim aktuellen DRKCMS ein deutlich höheres Sicherheitsniveau:
- Wir kümmern uns im Hintergrund zeitnah um notwendige TYPO3-Updates. Alleine dieses Jahr haben wir schon mehr Sicherheitsupdates für das DRKCMS eingespielt, als der Entwickler des Brandenburger CMS während der kompletten Vertragslaufzeit.
- Das TYPO3 selbst hat einen sehr ordentlich programmierten Kern. Wir durften einen Blick in den Quellcode des betroffenen CMS eines Brandenburger Kreisverbandes gucken, da fielen andere Worte.
- Erweiterungen im TYPO3 werden in einer Art und Weise programmiert, die SQL-Injections nahezu unmöglich machen. Das gilt sowohl für den Umgang mit Benutzereingaben, als auch für die Art und Weise, wie Datenbank-Abfragen zusammengebaut werden müssen. Das minimiert das Risiko, versehentlich doch mal eine Lücke zu lassen, erheblich.
Ich nutze auch den klassischen Webspace - was kann ich tun?
Bei Benutzung des klassischen Webspaces beherzigen Sie bitte die folgenden Tipps:
- Räumen Sie regelmäßig auf. In vielen Kunden-Webpaketen finden wir alte Versionen (z.B. vorheriges CMS), die über eine Subdomain wie alt.meine-webseite.de auch noch aufrufbar sind. Wenn diese Software Sicherheitslücken hat, kann ein Einbrecher damit auf Ihren Webspace zugreifen und auch die Live-Seite möglicherweise kompromittieren!
- Löschen Sie "phpinfo.php"-Dateien. Viele Kunden oder Entwickler legen sich in den Webspace eine Datei, die phpinfo() ausführt und zahlreiche Informationen preisgibt. Diese Informationen helfen nicht nur Ihnen, sondern auch einem Einbrecher! Löschen Sie entsprechende Dateien oder Anweisungen daher, wenn Sie sie nicht mehr benötigen.
- Deaktivieren Sie PHP-Fehlermeldungen! Standardmäßig sind bei uns die Fehlermeldungen deaktiviert, im Fehlerfall erhalten Sie nur eine weiße Seite. Im Kundenmenü unter Produkte/Webspace/PHP-Version können Sie auch eines der debug-Profile aktiveren, in denen die Fehlermeldungen aktiviert sind. Deaktivieren Sie diese unbedingt, wenn Sie mit der Entwicklung/Fehlersuche fertig sind – ein Angreifer könnte sonst Fehler provozieren und aus den Fehlermeldungen wichtige Angaben rauslesen
- Setzen Sie bei internen Tools einen IP-Filter oder einen Passwortschutz, z.B. per .htaccess-Datei. Insbesondere der Login in eine Administrations-Oberfläche kann sehr oft zusätzlich abgesichert sein – ein solcher Schutz würde auch eine angreifbare Login-Seite aus der Schusslinie nehmen
- Arbeiten Sie mit Datenbank-SQL-Benutzern. Unter Produkte/Webspace/Datenbanken können Sie zu jeder SQL-Datenbank ein eigenes Passwort anlegen, dessen Benutzer hat dann nur Zugriff auf diese eine Datenbank (wohingegen Ihr erstmalig angelegter Kunden-Benutzer Zugriff auf alle Datenbanken hat). Im Brandenburger Schadensfall hätte es vielleicht schon geholfen, wenn das kompromittierte CMS nur Zugriff auf seine CMS-Daten gehabt hätte und nicht auch noch die ganze Einsatzverwaltung abfragen durfte.
- Halten Sie die Software aktuell. Für so ziemlich jede im Internet einzusetzende Software gibt es regelmäßige Sicherheitsupdates. Beim klassischen Webspace sind Sie für deren Installation selbst verantwortlich. Eine Software jahrelang ohne Updates zu betreiben, ist fahrlässig.
- Hinterfragen Sie das Knowhow Ihres Dienstleisters. Wir betreuen seit über 15 Jahren DRK-Kreisverbände und sehr oft kann man bereits aus Support-Anfragen zumindest eine erste Einschätzung bekommen, ob der Gegenüber fachlich Ahnung hat. Es gibt ganz viele gute IT- oder Web-Dienstleister, die wir im Laufe der Zeit kennengelernt haben. Aber es gibt auch Fälle, wo wir Ihnen ganz ehrlich am Telefon unsere Meinung verraten würden – wenn Sie uns denn fragen.