Woran und warum Websicherheit scheitert

Vorwort

Ich, ein regelmässiger Leser von diversen Online-Magazinen und Zeitungen, wundere mich oft darüber, weshalb viele Menschen so erstaunt scheinen, wenn wieder mal eine Fluggesellschaft, Klinik, Uni, ein privates Unternehmen gehackt wurde. Ganz ehrlich: Früher, als ich in den Informationssicherheitszweig dieser Branche einstieg, war ich selbst noch oft erstaunt und schockiert. Inzwischen reicht es nicht mal mehr für ein "Tja" oder Schulterzucken. Es überrascht mich inzwischen überhaupt nicht mehr, dass ständig Server kompromittiert werden.

Früher habe ich die Schuld komplett den Administratoren und Entwicklern zugeschoben. Inzwischen ist mir bewusst, dass Manager/Leiter bzw. Auftraggeber eine grosse Teilschuld tragen. "Hauptsache möglichst günstig. Am besten kostenlos. Für Sicherheit haben wir momentan kein Geld." Und dann haben die Leiter noch den Mut zu schreien: "Fachkräftemangel!" Das finde ich schon grotesk.
Für den Datenschutz und die Sicherheit kümmert man sich meistens recht spährlich und erst wenn's knallt und das Kind bereits in den Brunnen gefallen ist.

Früher war ich auch gegen böse Hacker. Inzwischen bin ich für sie. Wer nicht hören will muss fühlen, sonst wird sich nie etwas ändern. Manche Menschen lernen eben nur durch Schmerz (Operante Konditionierung nach B. F. Skinner).
Ein Psychologe würde sagen: Der Leidensdruck ist zu niedrig um eine Veränderung herbeizuführen. Wenn man also eine Veränderung herbeiführen will, muss der Leidensdruck erhöht werden. Um langzeitig ein gewünschtes, stabiles Ergebnis herbeizuführen, muss das Informationssicherheitsverhalten des Menschen unregelmässig bzw. periodisch und nicht kontinuierlich verstärkt konditioniert werden.

Das heisst für Nicht-Psychologen: Ist ein Unternehmen regelmässig von Hacks und Leaks betroffen, wird es ziemlich schnell Massnahmen dagegen ergreifen (vorausgesetzt der Leidensdruck ist ist hoch genug). Aber sobald die Hacks und die Leaks aufhören, verschwindet das Sicherheitsbewusstsein ziemlich schnell wieder.

Wird jedoch ein Unternehmen in unregelmässigen Zeitabständen bzw. periodisch gehackt, geht es zwar länger, bis die Unternehmensleitung schaltet, dass sie ihre Informationssicherheit erhöhen sollten, dafür wird es aber etwas länger gehen, bevor sich das Sicherheitsbewusstsein verflüchtigt.

Wenn wir also die Sicherheitsawareness an die Spitze treiben wollen, müssen wir den Leidensdruck (auf Unternehmen, Kliniken, Unis, Kraftwerke, usw.) massiv erhöhen. Zuerst möglichst schnell (instabil), dann unregelmässig um zu stabilisieren. Zuerst möglichst viele Hacks und Leaks auf einmal, was das Zeug hält und dann in unregelmässigen Zeitabständen hier und da mal ein Hack und einen Leak (um zu stabilisieren).

Aber EliteHacker, wie erhöht man denn den Leidensdruck? Ganz einfach: Wähle mit deiner Brieftasche! Boykottiere Unternehmen, welche ständig deine Daten leaken und an hunderte Dritte weitergeben. Boykottiere Unternehmen, welche Paypal als einzigen Zahlungsdienstleister anbieten. Hier eine Übersicht mit wem PayPal deine Daten teilt. Einzelne Punke anklicken um auszuklappen. Verklage sie! Stelle einen Strafantrag oder melde einen DSGVO-Verstoss usw. Wenn sie keine Kunden mehr haben, erhöht sich der Leidensdruck automatisch.

Verwendung von Frameworks und Programmbibliotheken

Viele Entwickler greifen voreilig zu Frameworks und Libraries. Das ist einer der Gründe, weshalb man soviel Sicherheitslücken in seiner Software hat. Die Software wird einfach eingebunden und verwendet, ohne vorher den Code auf Sicherheitslücken zu auditen, geschweige die Sicherheitsinfos und Rezensionen durchzulesen. Codeschnippsel werden einfach blind kopiert, ohne zu hinterfragen, was der Code denn genau tut.
Da platzt der Manager herein: "Seid ihr schon fertig?! Der Kunde wartet schon! Sicherheit, das machen wir später!". Da liegt der Hund begraben.

Security Schlangenöl

Verwendung von CAPTCHAs

Die meisten CAPTCHAs können heute von intelligenten Bots gelöst werden und bieten somit keinen wirksamen schutz mehr. CAPTCHAs nerven einfach nur und verärgern und verscheuchen potenzielle Kunden. CAPTCHAs erhöhen die Sicherheit der Website praktisch gar nicht, sondern sind einfach dazu da, den Chef zu beruhigen.
Der Besucher der Website wird praktisch versklavt irgendwelche Bilder zu klassifizieren. Zusätzlich werden Daten an einen Drittanbieter gesendet, was den Datenschutz des Besuchers gefährdet. CAPTCHAs werden nur von Websites eingesetzt, welche ihre Besucher hassen.

WAFs (Web Application Firewalls) und Clownflare

Warum fallen Administratoren und Entwickler ständig auf dieses Buzzword herein? WAFs sind meiner Meinung nutzlos, so ähnlich wie Virenscanner heute auf Heimanwender-PCs.


Clownflare ist ein SPOF (Single Point of Failure) und zentralisiert somit das Web. Auf Deutsch: Einzelner Punkt des Versagens. 20% des weltweiten Webtraffics fliesst durch Clownflare und wird entschlüsselt. Das kann doch nicht wahr sein. Wie blöd kann man als Admin eigentlich sein? Falls mal Clownflare mal ausfällt sind viele wichtige Websites nicht mehr erriechbar. Zudem ist Clownflare praktisch ein MITM (Man in the Middle) und bricht die TLS-Verschlüsselung auf.

Tor-Nutzer werden gesperrt und somit diskriminiert. Ich dachte immer alle wären gegen Diskriminierung... Hmm, welch eine Doppelmoral. Versucht mal mit dem Tor-Browser im Web zu surfen. Praktisch unmöglich, jede zweite Website versteckt sich hinter Clownflare. Clownflare ist der Traum der NSA. Es ist schon ziemlich naiv anzunehmen, dass die NSA hier die Finger nicht im Spiel hat.

Unmengen an privaten, streng vertraulichen Daten fliessen über Clownflare. Auch Gesundheitsdaten, Banken und Pornowebsites verwenden Clownflare. Somit ist es für Clownflare ein leichtes Spiel. Clownflare bricht die TLS-Verschlüsselung auf und hat euer Passwort. Wenn da mal was passiert, sind alle Daten öffentlich. Ich habe schon mal davor gewarnt, damals haben mich die Menschen für einen Spinner gehalten und etwa drei Monate später ist genau das eingetroffen, was ich befürchtet habe: Clownbleed. Aber viele Admins fallen darauf rein auf den Honigtopf. Hört endlich auf Clownflare zu verwenden, es wird euch auf die Füsse fallen. Schützen tut es euch erst recht nicht. Eine dumme WAF kann schlechte Programmierung nicht heilen. Sichere Programmierung würde eine WAF unnütz machen.

Die Menschen lernen einfach aus ihren Fehlern nicht. Der Leidensdruck ist einfach zu niedrig.

Damit euch das nicht passiert, hier eine Anleitung, wie man es halbwegs richtig macht.
Folgende Anleitung ist nicht erschöpfend. Man kann natürlich immer noch mehr Sicherheit hinzufügen. Aber dies sollte eine Anleitung für Sicherheitsanfänger sein und nicht für die Experten unter uns. Aber ich schätze, bereits mit dieser Anleitung, ist eine Website, welche wie folgt konfiguriert wird, was das Sicherheitsniveau angeht, weit über dem Durchschnitt. Viel Erfolg!

Theorie & Praxis

Wir installieren Debian 11 (Bullseye) als Serverdistribution. Die neuste Stable. Wir achten darauf, dass wir möglichst wenig Müll installieren. Je weniger Packete wir installieren, desto weniger potenzielle Sicherheitslücken! Der Kernel befindet sich auf der Version 5.10. Sehr gut!

Webserver absichern

Wir sehen zu, dass unser Webserver auf dem neusten Stand ist und alle Sicherheitslücken geschlossen wurden, ansonsten brauchen wir hier an dieser Stelle nicht weiterzulesen:


Der Port 22 ist für SSH offen. Schaut also zu, dass ihr dass auch absichert, sonst geht der Angreifer einfach über den Port 22.
Wir verifizieren die hörenden Ports mit und schauen zu, dass nur die folgenden 3 Einträge zu sehen sind, ansonsten können wir nochmals von Vorne beginnen:


Ein Webserver bietet seine Dienste standardmässig über Port 80 und 443 an.
Wir können einen eifachen Webserver über Port 80 betreiben. Für das Beispiel nehme ich den guten alten Apache.

So sieht es dann im Webbrowser aus:


Wunderschön, nicht wahr? Habe selten eine Website gesehen, welche so schnell lädt.

Das Problem dabei ist, die Verbindung ist nicht verschlüsselt. Das bedeutet die Verbindung über HTTP bietet weder Vertraulichkeit, noch Integrität oder Authentizität der Daten, welche übertragen werden.

Richtig konfiguriert, bietet HTTPS bzw. TLS theoretisch gesehen relativ starke Sicherheit.
Das Problem: Viele Admins fürchten sich davor, Kryptografie einzusetzen. Es macht ihnen Angst.
Jeder gute Admin sollte grundlegende Informationssicherheitskenntnisse besitzen. Tun sie aber nicht. Deswegen werden sie ständig gehackt.

Ich gehe stark davon aus, dass der durchschnittliche Endbenutzer den Unterschied zwischen HTTP und HTTPS nicht erklären kann, ohne dabei das Wort "sicher" zu verwenden.

HTTPS ist eigentlich nichts anderes als HTTP innerhalb von TLS.

HTTPS ist keine Ende-zu-Ende-Verschlüsselung, sondern eine Transportverschlüsselung.

Es ist ein Irrtum anzunehmen, dass die lokale Fussballvereinswebsite oder die lokale Gottesdienstwebsite kein HTTPS benötigt, weil da "angeblich" keine sensible Daten übertragen werden.

Die Websicherheit scheitert meiner Meinung nach an grundlegenden Punkten, wie einer fehlenden Organisationsstruktur und fehlender Rollenverteilung.Wer ist der zuständige Admin der Website, der Webmaster? Wer ist der Entwickler? Wer ist der Auftraggeber? Mindestens Admin und Entwickler der Website müssen ernannt werden, von mir aus können auch aus Datenschutzgründen Pseudonyme verwendet werden. Der Admin und Entwickler können auch die gleiche Person sein, aber es muss eindeutig festgelegt werden, bevor eine Website ins Web gestellt wird, ansonsten ist es zum Scheitern verurteilt!

Beispiel:


Erst jetzt sollte man mit beginnen die Website ins Web zu stellen. Vorher nicht!

So, um die Website über HTTPS erreichbar zu machen, brauchen wir dafür ein gültiges Zertifikat (und einen zugehörigen private Key). Das holen wir uns von Let's Encrypt. Zertifikate sind seit 2014 kostenlos, hört auf euch von diesen Scharlatanen und Quacksalbern übers Ohr hauen zu lassen. Ist ja krank, wer gibt 80 Geld für ein Zertifikat aus, dass man kostenlos haben kann?

• Privaten Schlüssel offline generieren (3072 Bit sind angesagt, 2048 Bit ist Schnee von Gestern). Böse Zungen behaupten, wird der Schlüssel auf Windows generiert, bekommt Microsoft eine Kopie.
• CSR-Datei generieren. Die könnt ihr euren Feinden schicken. Die können nichts damit anfangen. Genauso wie das Zertifikat kann es öffentlich sein. Das einzige, das ihr mit eurem Leben beschützten müsst ist der private Schlüssel.
• Dann schickt ihr der CA eure CSR-Datei und bekommt ein Zertifikat ausgestellt.

So einfach ist das.

Wir verwenden die DNS-01-Challenge, um uns ein Zertifikat mit einer Wildkarte ausstellen zu lassen. Wer die HTTP-01-Challenge verwendet, hat die Kontrolle über seine Infrastruktur verloren. Die anderen zwei Challenges braucht kein Mensch.

Vorsicht: Wildkartenzertifikate sind zwar bequem, können aber zum Verhängnis werden, wenn der dazugehörige Schlüssel kompromittiert wird. Dann sind nämlich alle Domains in Gefahr, welche durch das Zertifikat abgedeckt wurden.

Jetzt habt ihr einen private Key und ein gültiges Zertifikat in der Hand. Beides wird jetzt im Webserver installiert und fertig ist die Laube.


Ok, geschafft! Wir haben nun eine leere Website vor uns! Sie ist nun endlich über HTTP und HTTPS erreichbar!

Uralte TLS-Versionen deaktiveren

TLS 1.3 (2018) ist das neuste und sicherste Protokoll.
TLS 1.2 (2008) ist der Vorgänger und ist je nach Konfiguration noch heute ausreichend sicher.
TLS 1.1 (2006) gilt als veraltet und sollte nicht mehr verwendet werden.
TLS 1.0 (1999) gilt als veraltet und sollte nicht mehr verwendet werden.
SSL 3.0, SSL 2.0 und SSL 1.0 gilt als veraltet und sollte nicht mehr verwendet werden.

Wir editieren die Apache-SSL-Konfigurationsdatei:



und lesen die Konfigurationsdatei neu ein:


Nun ist unser Webserver nur noch über TLS 1.3 erreichbar. Downgrade-Angriff sind Geschichte.

Falls es doch mal ein Scriptkiddie versucht, wird der Besucher folgendes sehen:


Wenn der Besucher noch so blöd ist und den blauen Knopf drückt:


Also nein, da kommt nichts durch.

Wer auf der sicheren Seite sein will, aktiviert nur TLS 1.3. Das kann allerdings dazu führen, dass manche Geräte nicht mehr auf eure Website zugreifen können, weil die Hersteller wieder mal 4 Jahre geschlafen haben. Wer Abwärtskompatibilität braucht aktiviert zusätzlich zu TLS 1.3 noch TLS 1.2:


Im nächsten Schritt deaktivieren wir die Verschlüsselung die nichts kann:


Übrig bleiben nur noch die Sicheren.

Sehr gut! Jetzt müssen wir nur noch den Schlüsselaustausch absichern. Wir werden jetzt unseren netten Kollegen bei der NSA und beim BND einen dicken Strich durch die Rechnung machen:


Die NSA hasst diesen Trick!

Alle anderen Kurven könnten von der NSA verseucht sein. Die Algorithmen könnten manipuliert worden sein. Die Kurven beinhalten Zahlen, dessen Ursprung sich nicht erklären lassen. Sehr verdächtig. Lasst also die Finger davon, wenn ihr sicher sein wollt, dass die NSA oder ein anderer Hacker, der weiss, wie man die "Hintertüre" ausnutzt, eure Daten nicht entschlüsseln kann.

Falls ein Angreifer passiv auf der Leitung mitlauscht und mitschneidet, könnte er die Daten im Nachhinein entschlüsseln. Damit dies nicht passiert verwenden wir ja schliesslich nur Verschlüsselung mit AEAD und PFS, als wir die Taugenichts-Verschlüsselung deaktiviert haben. Aber wir kennen ja die heutigen Admins und Entwickler. Hauptsache schnell muss es sein! Aber je schneller, desto unsicherer!

Deswegen empfehle ich die Sitzungsfortsetzung vollständig zu deaktivieren. Ja, die Verschlüsselung braucht nun minimal mehr Zeit, dafür kann da nichts mehr passieren, wenn die NSA oder sonstige Feinde eure Server kompromittieren, dann gucken sie in die Röhre:


Jetzt werden wir noch OCSP-Stapling aktivieren. Jaja, ich weiss. Zertifikatswiderruf im aktuellen Web ist Schrott, aber was willste machen. Ich warte ab, bis unsere Kollegen was Besseres gefunden haben:


Jetzt müssen wir den Endnutzer immer auf HTTPS umleiten, wenn er HTTP verwendet!
Und schon tappt der Admin in eine weitere Falle. Er verwendet den HTTP-Response-Code 302 statt 301.
Um von HTTP auf HTTPS zu wechseln, muss immer 301 (Permanent Redirect) verwendet werden. 302 (Temporär) ist kreuzfalsch.
Die nächste Falle bahnt sich schon an.

Der Admin will die Subdomain www erzwingen und leitet von http://webserver.elitehacker direkt auf https://www.webserver.elitehacker um. Das ist ebenfalls falsch. Korrekt wäre: http://webserver.elitehacker --- 301 --> https://webserver.elitehacker --- 301 --> https://www.webserver.elitehacker.
Wieso? Wir müssen den Nutzer zuerst an unsere "oberste" Domain schicken, damit wir ihm eine HSTS-Richtlinie aufzwingen können, welche im besten Fall für alle Subdomains gilt und eine Lebensdauer von ein bis zwei Jahren besitzt.



und noch ein paar Response-Headers zur Sicherheit einfügen:


So Server neustarten und geniessen:


System weiterhin auf dem neusten Stand halten und "monittern".

Wer Verbesserungsvorschläge hat, immer her damit. Ich füge es ein.

Wer gehackt wird ist (eigentlich) selbst schuld. Ich wünsche euch ein schönes Wochenende. Ich bin raus.