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.