Archive November 2018

Erste Geldstrafe in Deutschland für fahrlässige Sicherheit in Web-Anwendung

Erste Geldstrafe in Deutschland für fahrlässige Sicherheit in Web-Anwendung

Seit dem die DSGVO in Kraft ist, drohen Geldstrafen für Betreiber von Web-Anwendungen, die fahrlässig mit dem Thema Sicherheit umgehen. Wie heise Security berichtet, wurde deshalb gegen Knuddels.de eine Strafe von EUR 20.000 verhängt, weil Passwörter von Benutzern im Klartext gespeichert wurden. Dies ist nach den Untersuchungen herausgekommen, nachdem ein Hackerangriff erfolgt ist und analysiert wurde. Weitaus größer als die finanzielle Strafe dürfte jedoch die nun stark beschädigte Reputation von Knuddels.de sein, sowie das verlorene Vertrauen bei den 2 Millionen registrierten Usern.

Wie wichtig es ist, Passwörter sicher abzuspeichern, zeigt sich mustergültig an diesem Beispiel. Ist der Zugriff auf die unverschlüsselten Passwörter erst einmal möglich, dann sind zahlreiche Benutzer betroffen und damit kompromittiert. Da es von vielen Personen außerdem gängige Praxis ist, ein und das selbe Passwort auf mehren Portalen zu verwenden, sind durch einen solchen Raub gleich alle Accounts gefährdet, auf denen dieses Passwort gültig ist. Die Aufklärungsarbeit, die dazu bei den Anwendern gemacht werden muss, stößt oft auf taube Ohren. Aus Bequemlichkeit setzen sich Passwort-Management Programme wie KeePass oder LastPass nur sehr schleppend durch, aber sie scheinen der einzige Ausweg zu sein, um auf jeder Webseite ein eigenständiges, genügend komplexes Passwort zu haben.

Der einzig richtige Weg, wie ein Passwort abgespeichert werden muss, ist: überhaupt nicht. Zumindest nicht im Klartext – und auch nicht verschlüsselt. Verschlüsselte Passwörter können nämlich wieder entschlüsselt werden, was bei einer Passwortprüfung überhaupt nicht notwendig ist. Statt dessen sollte nur der Passwort-Hash abgespeichert werden, und zwar mit einem sicheren Hash-Algorithmus, z.B. PBKDF2 oder bcrypt. Die Prüfung, ob das vom Benutzer eingegebene Passwort dann das Richtige ist, findet folgendermaßen statt: Die Web-Anwendung, die die Benutzereingabe verarbeitet, hasht das Passwort ebenfalls und vergleicht dann nur noch den Hash mit dem Hash aus der Datenbank. Stimmen diese überein, wurde das Passwort richtig eingegeben.

Mehr Informationen über sichere Passwortverwaltung und sichere Programmierung finden sich auf den OWASP-Seiten, und können auch auf einer Secure Coding Schulung gelernt werden.

 

Multifaktor-Authentifizierung, bitte nicht mit SMS

Multifaktor-Authentifizierung, bitte nicht mit SMS

Die klassische Authentifizierung erfolgt üblicherweise mit Benutzername und Passwort. Da aber Passwörter gerne mal in die falsche Hände geraten, wie inzwischen zig fach bekannt, sei es durch Ausspähen auf dem Transportweg, durch Auslesen des Passwort-Speichers, oder durch Knacken mit Brute-Force-Tools, braucht es einen weiteren “Faktor”, der die Authentifizierung sicherer macht. Also eines weiteren Merkmals, das über einen alternativen Kanal abgefragt wird. Auch Multifaktor-Authentifizierung genannt.

In den letzten Jahren wurde vor allem im Banking-Umfeld die SMS verwendet, um neben dem Passwort oder der PIN, ein weiteres Merkmal des Benutzers abzufragen. Die Bank schickt also nach dem Login via Benutzername und PIN eine SMS an den Kunden, damit er sich durch Eingabe dieser gegenüber der Bank legitimiert. Dass aber SMS nicht sicher sind, zeigt sich vermehrt durch Bekanntwerden immer neuer Vorfälle. Wie das Magazin TechCrunch.com berichtet, wurde eine Datenbank des kalifornische Telekomanbieters Voxox kompromittiert, so dass Millionen gesendeter SMS Nachrichten für jedermann offen lesbar waren – und zwar in Echtzeit, so dass beispielsweise Passwort-Rücksetzungstoken einsehbar waren, quasi gleichzeitig zum Versand an den eigentlichen Adressat. Ganz abgesehen von privaten Daten und anderen geheimen Informationen. Mit solcherlei Pannen ist es also keine Hilfe, SMS als zweiten Faktor für die Sicherheit zu verwenden. Im Gegenteil.

Es stellt sich also die Frage, warum ein Telekomanbieter überhaupt versendete SMS abspeichern. Geht man dieser Frage nach, stellt man schnell fest, dass diese sogar dazu verpflichtet sind, SMS in ihren Datenbanken aufzubewahren, da es sich technisch gesehen dabei um ein Kommunikationsprotokoll handelt, für das Aufbewahrungspflicht besteht. Mindestens 10 Jahre müssten SMS gespeichert werden.

Was lernen wir daraus? SMS taugen nicht für die Multifaktor-Authentifizierung. Vielleicht sollte ich einer meiner Banken, die das immer noch praktiziert, mal deutlich sagen. Bei den meisten Banken wurde inzwischen umgestellt, was die TANs angeht, auf smartTAN bzw. pushTAN, oder wie auch immer die jeweilige Bank das Verfahren nennt, bei dem eine Smartphone-App zum Einsatz kommt.

Threat Modelling

Threat Modelling

Unter Threat Modelling versteht man das systematische Modellieren von Bedrohungen, wie sie in Web-Anwendungen vorkommen. Dabei wird betrachtet, welche Schnittstellen ein System nach außen hin hat, wie die Daten von vorne bis hinten durch System fließen, und an welchen Stellen kritische Übergänge stattfinden, an denen besondere Vorsorge getroffen werden muss.

Als Ergebnis der Bedrohungsanalyse soll eine gute Übersicht aller Bedrohungen herauskommen, die die Grundlage des Risk-Managements darstellt. Beim Risk-Management werden die Risiken bewertet und entsprechende Maßnahmen abgeleitet, je nach Situation und Kriminalität der Web-Anwendung.

Eine ausführliche Beschreibung dieser Thematik wurde hier veröffentlicht, mit ausführlichen Erklärungen und Beispielen.

Zur 9-teiligen Serie Threat Modelling – Bedrohungsanalyse gehts hier.

Secure Coding

Secure Coding

Unter Secure Coding verstehe ich Programmieren mit dem Wissen im Hinterkopf, dass die Anwendung sicher sein muss. Sicher in Hinblick auf folgende Kriterien: sie darf nicht kompromittiert werden können durch das Umgehen der Authentifizierung und Autorisierung. Vertrauliche Daten müssen vertraulich bleiben. Es darf keine Malware einschleusbar sein, die andere Benutzer bedrohen könnte. Und es darf keine Möglichkeit geben, Aktionen auszulösen, die später nicht eindeutig zu ihrem Verursacher zurück zu verfolgen sind.

Wenn ich all dies berücksichtigen will, dann muss ich mich zwangsläufig in die Rolle meines Gegenübers versetzen, in die Rolle eines Angreifers. Denn ich muss verstehen, wie ein Angreifer die Anwendung in die Mangel nehmen wird, um über eine Schwachstelle an die Kronjuwelen zu gelangen – was immer diese auch sein mögen in der Anwendung.

Stellen wir uns also folgende Frage: Wie gehe ich vor, wenn ich die Motivation habe, eine Webseite zu hacken?

Denken wie ein Hacker

Nehmen wir als Beispiel an, es gehe um die Adresse abc.de. Ich versuche als Hacker zunächst so viele Informationen wie nötig herauszufinden. Wer oder was ist abc.de? Wer oder was steckt dahinter? Ich verwende zum Beispiel die Suche verschiedener Suchmaschinen und andere Ressourcen im Internet, wie soziale Medien, um so viele Informationen wie möglich herauszufinden. Diese Phase nennt sich “Footprinting and Reconnaissance”.  

Ich suche dabei in allen möglichen, öffentlichen Bereichen nach Informationen, die mir später möglicherweise nützlich sein können. Wichtig ist dabei, diese Informationen systematisch abzulegen. Entweder durch Screenshots, oder sonst irgendwie. Vielleicht finde ich auch eine Web-Anwendung oder andere Schnittstellen die nach außen hin exponiert sind. Wenn ich so etwas finde kann ich mit einem Vulnerability Scanner versuchen so viel wie möglich Informationen über diese Schnittstelle herauszufinden. Solche Scanner gibt es viele am Markt, kommerzielle und auch aus dem Community-Umfeld. Der Vorteil solcher Scanner ist, dass sie sehr schnell eine Vielzahl an bekannten Schwachstellen automatisiert abprüfen können. Sollten beispielsweise Komponenten bei einer Webanwendung eingesetzt werden, die veraltet und verwundbar sind, dann existieren möglicherweise dafür bereits Exploits die man verwenden kann. Ein Exploit ist ein Software-Modul, das sich eine bekannte Schwachstelle zunutze macht, um in ein System eindringen zu können. Normalerweise ist es aber nicht ganz so einfach.

Wenn die Anwendung halbwegs sicher entwickelt wurde, muss ich zumindest ein Passwort ein geben, so dass ich ohne nicht weiter komme. Nun kann ich versuchen, einen Benutzernamen zu erraten und mit roher Gewalt das Passwort zu knacken. Einen Benutzernamen könnte ich erahnen, wenn ich in der ersten Recherche-Phase einige Namen herausfinden konnte, beispielsweise die Ansprechpartner, oder die Verantwortlichen der Firma. Auch für solche Passwort-Attacken gibt es Tools, die mit ganzen Bibliotheken von häufig verwendeten Passwörtern gefüttert werden. Oder auch einfach alle Kombinationen von Zeichen systematisch nacheinander durchgehen. Ist das Passwort kurz genug – z.B. nur 8 Zeichen – kann das sogar in kürzester Zeit gelingen.

Wahrscheinlich wird aber die Firewall oder das Intrusion Detection System (IDS) zuschlagen und mich blockieren, wenn bemerkt wird, dass ich ganze Salven an Authentifizierungs-Requests abfeuere. Wenn ich Pech habe, wird meine IP-Adresse gebannt und ich bin erst mal ausgesperrt. Alternativ finde ich Informationen über eine Person heraus, die diese Applikation verwendet und errate ein Passwort – oder ich kann eine E-Mail abfangen von einem schlecht gesicherten Mail-Account. Es ist oft nicht so schwierig einen gewissen Einstiegspunkt zu finden, wenn man beharrlich daran arbeitet und nicht locker lässt. Und auf einmal klappt es vielleicht sogar – ich finde eine Benutzernamen-Passwort-Kombination, die funktioniert. Ich bin drin. Sei es, weil ein überarbeiteter Kollege den Admin-Zugang nicht richtig gesichert hat, die Monitoring-Seite nicht richtig geschützt ist, oder was auch immer. Drin ist drin, oder?

Was ist aber, wenn ich einen Zugang gefunden habe, über diesen Zugang aber nicht wirklich weiterkomme? Ich bin z.B. auf einer Monitoring-Seite gelandet – na toll. Ich suche doch nach Informationen die mich weiterbringen, die ich zu Geld machen kann, oder sonst wie einsetzen kann. Mit dem gefundenen Account kann ich sie nicht bekommen, weil er nicht genügend Rechte hat. Ich habe nun also mit Glück einen kleinen Einstiegspunkt gefunden, komme aber nicht weiter. Da hilft nur eins: ich muss die Anwendung untersuchen, ob Sie weitere Schwachstellen hat – beziehungsweise überhaupt eine Schwachstelle, das Passwort war ja keine Schwachstelle. Eine gute Möglichkeit ist mit einem Scanner herauszufinden ob die Web Anwendungen Komponenten eingesetzt, die bekannte Schwachstellen haben. Wie zum Beispiel Bibliotheken die fast in jedem Projekt verwendet werden und oft vergessen werden zu patchen, wenn eine Schwachstelle und ein Update herauskommt. Wenn ich es schaffe meinen die gekaperten Account zu erweitern, so dass ich dann über mehr Rechte verfüge, im Optimalfall Administrationsrechte, dann komme ich eventuell tiefer ins System herein und eventuell sogar auf andere Anwendungen oder sogar Rechner für mehr Informationen. Von Interesse ist zum Beispiel ein Datenbankzugriff. Dafür suche ich in der Anwendung nach Injection Schwachstellen damit ich per SQL-Injection die Daten in der Datenbank durchsuchen kann. Oder noch besser: OS-Injection, damit ich aus der Anwendung heraus Betriebssystems-Befehle absetzen kann.

Die Strategie ist also, in der großen Festung einer IT Landschaft kleine Risse zu finden. Risse in der großen Mauer durch die man Stück für Stück weiter hinein kommt. Eine Firewall auszutricksen ist nicht ganz einfach, wenn es auch Hacker geben soll, für die das leicht ist. Eine Web-Anwendung dagegen, die nach außen hin exponiert Ist, ist allzu oft ein machbares Problem. Individuell erstellte Software ist oft schlecht gesichert und manchmal ist es möglich, über die Benutzerschnittstellen das System zu knacken. Man braucht aber in den meisten fällen viele Schwachstellen die man in Kombination nutzen kann. Jede noch so gute Festung wird durch eine schlecht gesicherte Webanwendung einnehmbar.

Aus dem Alltag eines Entwicklers – das Problem mit dem Termindruck

Als Programmierer denkt man sich möglicherweise oft, dass so eine kleine Schwachstelle doch eh von keinem gefunden wird. Termindruck lässt so manchen Entwickler leichtsinnig werden. “Ach, das findet doch eh keiner. Im Moment gehts nicht anders – das werde ich später dann besser und sicherer lösen.” So, oder so ähnlich, geht es vielen Entwicklern irgendwann einmal. Aber dies ist ein Irrtum. In vielen Fällen bleibt ein Provisorium für ewig bestehen, denn es tut ja. Der Kunde ist zufrieden und keiner denkt dann mehr ans Aufräumen. Zeit und Geld ist eh kaum vorhanden, und wenn, dann eher für weitere Features, anstatt den Code nochmals zu überarbeiten. Insbesondere viele kleine Schwachstellen machen eine große Schwachstelle daraus.

Die schlimmsten Sünden sind ungeprüfte Eingaben vom Benutzer (Injection), durch die man ein System knacken kann. Die Arbeit die es einem Entwickler macht, diese Schwachstellen zu vermeiden ist ziemlich groß. Insbesondere, wenn man sich mit Secure Coding nicht auskennt. Außerdem sind große Sünden: Cross-Site-Scripting (XSS) und schlecht gesichertes Session Management, durch das Browser-Sessions gekapert werden können, was von einer Firewall kaum erkannt werden kann.

Schwerwiegende Folgen

Wenn man in ein System eingedrungen ist, es bis auf die Datenbank geschafft hat und dort schlecht verschlüsselte Passwörter ergattern kann, dann kann man gleich sämtliche Accounts abziehen. Vielleicht sogar einfach alle Daten abziehen, nicht nur die aus der Datenbank, sondern die aller Systeme zu denen die gekaperten Zugänge passen. Es soll ja immer noch Leute geben, die nicht für jedes System ein eigenes Passwort verwenden, sondern eins für alles. Habe ich gehört… Die Katastrophe nimmt dann ihren Lauf. Je mehr Fehler, desto mehr Möglichkeiten.

Dies ist ein gutes Beispiel um zu zeigen dass auch Daten in einer gut gesicherten Datenbank verschlüsselt sein müssen. Denn wenn eine Anwendung auf diese Datenbank zugreifen kann, dann kann man es mit der geknackten Anwendung auch – mit allen Zugriffsrechten, die die Anwendungen eben hat. Webanwendungen sind also ein wunderbares Ziel für Hacker, da schlecht entwickelte Exemplare ein Einfallstor bis hinter alle Fronten sind. Ein Paradies für Hacker.

Secure Coding

Als Entwickler muss man also in jeder Schicht für Sicherheit sorgen, denn ein guter Hacker knackt ein System Schicht für Schicht, wie eine Zwiebel und oft findet sich in jeder Schicht eine Schwachstelle.