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.

Sicherheitslücke durch Unwissenheit?

Was da gerade bei den Freien Wählern in Bayern passiert ist, sind gleiche mehrere kapitale Fehler, die entweder durch Schlamperei oder einfach durch Unwissenheit entstehen konnten. Wie heise security am 16.10.2018 berichtete, kam es auf der Webseite der Freien Wählern zu einer Überlastung durch zuviel Besucher nach der Landtagswahl. In Folge wurde die maximal mögliche Anzahl der Datenbankverbindungen erreicht, so dass das Content Management System Typo3 nur noch eine Fehlerseite für neue Besucher zeigte. Verhängnisvollerweise waren auf dieser aber die Zugangsdaten zur MySQL DB zu sehen, was Angreifern Tür und Tor öffnete.

https://api.heise.de/svc/embetty/tweet/1051507700616650753-images-0

Bei näherem Hinsehen wurden gleich mehrere Fehler gemacht, die das Ausmaß der Katastrophe unnötig erweitert haben. So wurde zunächst nicht auf den aktuellen Stand der Software geachtet, so dass anscheinend veraltete und ungepatchte Versionen von PHP, Typo3 und MySQL eingesetzt wurden. Dies allein ist eine Sicherheitslücke, die in den OWASP Top-10, der am meisten ausgenutzten Schwachstellen auf Platz 9 gelistet sind. “Using Components with Known Vulnerabilities” heißt dieser Punkt, der darauf hinweist, dass man stets darauf achten sollte, keine Komponenten mit bekannten Schwachstellen zu verwenden. Öffentlich verfügbare Exploits machen es Angreifern sehr leicht, diese Schwachstellen auszunutzen.

Der weitaus schlimmere Fehler war aber der, dass die Betreiber der Webseite den Debugmodus bei Typo3 aktiv gelassen haben, was dazu führe, dass die Zugangsdaten zur Datenbank in der Fehlermeldung veröffentlicht wurden. In den OWASP Top-10 wird dieser Fehler auf Platz 6 gelistet unter dem Titel “Security Misconfiguration”. Der Debugmodus ist ausschließlich für Testumgebungen gedacht und darf auf keinen Fall auf einer Produktivumgebung aktiv sein. Mit Kenntnis der Zugangsdaten zur Datenbank können mit etwas Geschick alle Daten der Webseite ausgelesen und auch manipuliert werden.

Was aber dann noch oben drauf kommt ist der kapitale Fehler, dass diese veröffentlichten Zugangsdaten nicht nur für die Datenbank gültig waren, sondern auch für das Content Management System, so dass sich jeder, der die Administrations-Seite findet, dort einloggen und bequem sämtliche Inhalte verändern und manipulieren kann, sowie auch in nicht öffentliche Bereiche vordringen kann und Zugriff auf geheime Informationen hat. Dies ist ein Verstoß der Sicherheitsregeln, die in den OWASP Top-10 auf Platz 2 gelistet sind mit “Broken Authentication”. Es ist leider eine sehr verbreitete Praxis, dass man Zugangsdaten wie Benutzername und Passwort nicht nur exklusiv für ein System verwendet, sondern gleich für mehrere Systeme. Die große Gefahr dabei ist, dass wenn diese Zugangsdaten veröffentlicht werden, nicht nur das eine System kompromittiert ist, sondern auch die anderen, auf denen sie gelten.

Folgende Fehler wurden nach den vorliegenden Informationen mindestens gemacht:

  • Veraltete, ungepatchte Software (PHP, Typo3, MySQL)
    • hat in diesem Fall nicht direkt zu dem Angriff beigetragen, ist aber immer eine angreifbare und oft ausgenutzte Schwachstelle
  • Debugmodus aktiv bei Typo3
    • dadurch Preisgeben von geheimen Informationen, in diesem Fall der Zugangsdaten zur DB, nach Eintreten eines Fehlerfalls über die Fehlermeldung
  • Verwenden der gleichen Zugangsdaten für CMS und DB
    • dadurch Kompromittierung nicht nur der Datenbank, sondern auch des CMS Systems – obwohl dies eh als kompromittiert gilt, sobald dessen DB kompromittiert ist. Aber Dadurch ist die Webseite noch um einige Faktoren leichter zu manipulieren, insbesondere für unerfahrene Angreifer.

Webanwendungen abzusichern ist nicht immer einfach. Durch die öffentlich zur Verfügung stehenden Informationen und Checklisten kann man aber durch relativ wenig Aufwand zumindest einen passablen Grundschutz erreichen. Organisationen wie die OWASP-Stiftung helfen den Entwicklern und Betreibern von Webseiten sehr. Voraussetzung dabei ist, dass man die Gefahren kennt – und auch die Abwehrmaßnahmen.

Für Softwareentwickler biete ich bei meinem Arbeitgeber EXXETA auf Basis der OWASP Top-10 eine zweitätige Secure Coding Schulung an, bei der wir ausführlich jeden einzelnen der 10 Punkte besprechen, Übungen dazu durchführen, sowie deren Präventionen erläutern, damit Fälle wie dieser nicht passieren, zumindest nicht an der eigenen Webanwendung. Darüber hinaus bieten wir an, unser Wissen im Feld der IT-Security zu teilen, um Anwendungen auf ihre Sicherheit hin zu überprüfen, sowie nachhaltige Sicherheit in den Softwareentwicklungsprozess zu bringen.