Martins key.matiq-Blog
>> Zurück zum Artikelverzeichnis >>
Penetrationstests
Geschrieben: 25.02.2020
Letzte Überarbeitung: 24.05.2022
Stichwörter: Nähkästchen, Sicherheit, Überprüfungen und Tests
Man kann immer etwas lernen, wenn jemand anders auf das eigene Produkt schaut. Martin berichtet über die Durchdringungstests, mit denen die Firma Securai key.matiq geprüft hat.
Die Betriebsblindheit überwinden ...
... war unsere Motivation, gleich drei externe Expertisen einzuholen: IT-Rechtsanwalt Steinle baten wir, unsere Datenschutzhinweise zu überprüfen, die wir bei Inkrafttreten der DSGVO selbst angepasst hatten. (Damals waren sämtliche Experten auf Monate ausgelastet.) Mit dem Datenschutz-Experten Norbert Warga vereinbarten wir, einen DS-Audit durchzuführen und mit der Firma Securai, dass Sie Durchdringungstests gegen key.matiq fährt, um Schwachstellen aufzudecken.
Die Datenschutzhinweise sind inzwischen angepasst. Es waren kaum Änderungen nötig. Wir hatten uns offenbar gut in die DSGVO eingelesen.
Mit Norbert Warga sind wir die Audit-Fragen durchgegangen. Grundsätzliche Probleme sind nicht aufgetaucht. Es steht uns aber noch Dokumentationsarbeit bevor, um das Thema abzuschließen.
Schwieriger waren die Penetrationtests. Das Rechenzentrum, das unseren Server hostet, verweigerte die Zusammenarbeit. Nein, Durchdringungstests würden sie nicht zulassen. Also mussten wir eine neuen virtuelle Maschine aufsetzen, auf der wir key.matiq installierten und übertrugen diese über das Internet an Securai in Ingolstadt.
Securai
Christoph Haas, den Inhaber von Securai, kannte ich von einer Münchner Firma, bei der ich früher arbeitete. Er führte schon vor Jahren dort freiberuflich Durchdringstests gegen eine Web-Anwendung durch, die in Rechenzentren von Banken und Versicherungen eingesetzt wird. Später, da hatte er schon die Securai GmbH gegründet, traf ich ihn wieder bei einem Wiederholungtest.
Securai legt ihren Schwerpunkt auf die OWASP Top Ten. Dabei geht es um die zehn größten Sicherheitsrisiken für Web-Anwendungen. Aber wie ich später feststellen sollte, finden die Leute durchaus auch Schwachstellen, die nicht zu den "Top Ten" zählen.
Eine Woche Pentests
Christoph hat eine Mitarbeiterin auf key.matiq angesetzt, die ebenso hart das Prüfobjekt anging, wie sie zuvorkommend und freundlich im Umgang mit uns war. Am Ende sagte sie: "Sie haben es mir nicht leicht gemacht". Sie meinte damit die Widerstandsfähigkeit von key.matiq, aber sie hatte drei Schwachstellen der Kategorie "Hoch", vier in der Kategorie "Mittel" und zwei niedriger eingestufte gefunden und gratulierte uns doch dazu, dass sie keine einzige "kritische" Schwachstelle gefunden hatte.
Nun, wir hätten natürlich lieber gesehen, wenn sie auch keine Schwachstelle mit "hohem" Risiko hätte finden können. Da es diese aber nun einmal gab, waren wir jedenfalls froh, sie nun verstehen und ausmerzen zu können.
Immerhin: Securai wirbt mit dem Slogan "Wir hacken Ihre Software in 30 Minuten." Das haben sie bei uns nun nicht geschafft.
Injection
Die größte Schwachstelle war, dass über eine modifizierte URL ein JavaScript ausgeführt werden konnte, mit dem man z. B. hätte ein Cookie stehlen könnte. Um sie auszunutzen, hätte die Angreifer*in einer key.matiq-Nutzer*in eine gefälschte E-Mail mit einem Link zukommen lassen müssen. Wenn die Nutzer*in diesen Link geklickt hätte, hätte damit die Angreifer*in z. B. das "box_id"-Cookie und damit die Willkommensmeldung erbeuten können, die ja vor gefälschten Websites schützen soll.
Nun schreiben wir immer wieder, dass wir keine Links in E-Mails verschicken. Aber denkt im Ernstfall jede Benutzer*in daran? Sehr gut also, dass diese Schwachstelle erkannt wurde. Aber war sie wirklich die einzige ihrer Art?
Wir haben es überprüft. Überall folgen wir dem Prinzip, dass Benutzer*inneneingaben gefiltert werden müssen, damit diese immer nur als Daten, nicht aber als Skripte interpretiert werden. Bis auf einen einzigen Typ von Nutzer*inneneingaben: Der URL. Die mitgegebenen Parameter werden gefiltert, doch die URL als Ganzes wird an genau einer Stelle ungeprüft einem JavaScript übergeben. (Die Übergabe ist nötig, um feststellen zu können, in welchem Browser-Tab die Benutzer*in die Aktion angestoßen hatte.)
Und die Securai-Mitarbeiterin hat genau diese eine Schwachstelle gefunden, bei der eine sogenannte "Injection" möglich ist. Ein "Bravo" an sie!
Der Schleier
Lag bei der URL einfach ein einziges Versäumnis zugrunde, war für die nächste Schwachstelle reine Betriebsblindheit ursächlich. Wir hatten für die Benutzer*innenführung bei bestimmten Aktionen einfach alle anderen Eingaben gestoppt, bis die geforderte Eingabe erledigt war. Dazu legten wir auf die gesamte Ansicht einen undurchdringlichen Schleier und oben drauf die Eingabeanforderung.
Dies war ganz gut, wenn z. B. der Server neu gestartet worden war und die Nutzer*in eben mal das Hauptkennwort neu eingeben musste, damit sie wieder auf ihre Geheimnisse zugreifen konnte.
Irgendwann hatte ich die Idee, dieses Verfahren auch dafür zu nutzen, eine offene Sitzung zu sperren, anstatt sie zu beenden. Wenn man mal kurz rausging, um einen Kaffee zu kochen, aber kein andere*r in die Box greifen sollte.
Mir war damals schon klar, dass der Schutz, den der Schleier bot, nicht perfekt war. Wenn man die "Web Developer"-Erweiterung installiert hatte, war es für einen Unbefugten, der sich damit auskannte, ganz einfach, den Schleier zu lüften und in die Box zu schauen, ohne das Kennwort einzugeben.
Aber ich dachte wohl damals, so zu sperren sei besser als nichts. Woran ich aber nicht dachte: Andere Nutzer*innen würden dem "Sperren" vertrauen. Und dieses Vertrauen war so nicht gerechtfertigt. Was für die Nutzer*innenführung passt, reicht eben noch lange nicht für die Sicherheit!
Wie richtig war doch die Entscheidung gewesen, Securai auf key.matiq einen Blick werfen zu lassen!
Von der Kategorisierung "Kritisch" ist diese Schwachstelle nur verschont geblieben, weil ohne die Eingabe des Hauptkennworts sämtliche Kerngeheimnisse dennoch geschützt waren. Ohne das Hauptkennwort konnten sie schlicht nicht entschlüsselt werden. Immerhin hatten wir mit dieser Konstruktion ein Sicherheitsnetz gespannt, das im Gegensatz zum "Schleier" nicht so leicht zu zerreißen war.
Die Lösung war einfach: Eine eigene Sperr-Ansicht, ein Flag in den Sitzungsdaten, dass die Sitzung gesperrt ist, und bei allen Aktionen, die Inhalte (also auch Begleitdaten) der Box betreffen, dieses Flag abfragen.
Malware
Erstaunt war ich hingegen über die dritte als "Hoch" eingestufte Schwachstelle. Ich hatte überhaupt nicht daran gedacht, hochzuladende Dateien mit einem Virenscanner zu überprüfen. Schließlich waren das ja Dateien, die eine key.matiq-Nutzer*in selbst als geheim eingestuft hatte, und wir hatten gar nicht die Absicht, einen Blick darauf zu werfen.
Doch die Prüferin hatte Recht: Schließlich kann ja eine key.matiq-Nutzer*in Geheimnisse an andere Boxen übertragen. Zumindest diese müssen ja vor potentiellen Infektionen geschützt werden.
Die Lösung: Dateien, die als Begleitdaten in Geheimnissen (oder auch in Nachrichten) enthalten sind, werden immer auf Malware überprüft. Bei Dateien, die zu den Kerngeheimnissen zählen, kann die Besitzer*in entscheiden ob sie überprüft werden oder nicht. Überträgt sie sie aber an andere, können diese sie nachträglich überprüfen lassen (wenn sie wollen). Jedenfalls wird der Empfänger*in angezeigt, ob die Datei bereits gescannt wurde, und ggf. mit welchem Ergebnis.
Damit sind wir jetzt anderen Online-Passwortmanagern voraus, die eine solche Option nirgends anbieten.
Andere Schwachstellen
Da gab es noch Dinge, wo wir nicht mehr ganz up-to-date waren: So sehr wir selbst die Mozilla-Entwickler seinerzeit gedrängt hatten, TLS 1.2 zu unterstützen, so wollten wir doch kompatibel zu älteren Browsern bleiben und hatten Verbindungen mit solchen, die nur TLS 1.0 und 1.1 kannten, noch akzeptiert. Über die Jahre, in denen wir ständig an anderen Stellen key.matiq verbesserten, hatten wir nicht daran gedacht, diese Kompatibilität aufzuheben und damit key.matiq-Nutzer*innen zu drängen, aktuelle Browser zu benutzen.
Und uns war nicht aufgefallen, dass unser Ubuntu, das sich sonst so fleißig ohne unser Zutun mit Sicherheitsaktualisierungen versorgte, das bei unserem Webserver Nginx nicht tat. Der Securai-Mitarbeiterin ist es aufgefallen und nun wird auch Nginx regelmäßig aktualisiert.
Dankbar waren wir auch für die Hinweise auf einen neuen HTTP-Header und neue Cookie-Optionen, die die Sicherheit verbessern und die wir sogleich umsetzen konnten.
Nur eine Schwachstelle der Kategorie "Niedrig" und eine der Kategorie "Information" lassen sich nicht so einfach beheben und bedürfen einer längerfristigen Planung. Wir haben Sie in unsere TODO-Liste aufgenommen. Sie sind nicht gar so dringlich, weil eine Angreifer*in mit diesen beiden Punkten für sich genommen nicht viel anfangen könnte. Sie könnten ihr allerdings das Leben etwas erleichtern, sollte sie noch einen anderen, größeren Schwachpunkt finden.
Update 22.04.2021: Inzwischen ist die Schwachstelle der Kategorie "Niedrig", sie betraf die damals noch nicht implementierte "Content Security Policy", längst behoben. Die Schwachstelle der Kategorie "Information" wollen wir erst gleich nach der Implementation der client_seitigen Verschlüsselung (im Rahmen des "Cautiously Knowing Service") angehen, da letztere noch ein erheblich größeres Plus an Sicherheit bringen dürfte.