Gerade eben habe ich mein neues YouTube-Video veröffentlicht. Es ist aus der Secure Coding Reihe zum Platz 2 der OWASP-Top10 „Broken Authentication – Fehler in Authentifizierung und Session-Management.
Mich würde sehr interessieren, was Ihr darüber denkt. Konstruktive Kritik oder auch nur kurzes Feedback ist also willkommen. Entweder hier, oder auch bei YT als Kommentar.
Als Benutzer werden wir dazu erzogen, komplexe Passwörter zu verwenden. Aus gutem Grund werden zu einfache Passwörter zumeist abgelehnt, da Passwörter die in einem Wörterbuch vorkommen, innerhalb weniger Sekunden geknackt werden können durch einen sogenannten Wörterbuch-Angriff. Auch ein „123“ davor oder dahinter bringen da nicht viel, da man solche Varianten dabei gleich mit prüft.
Wenn nicht mindestens Gross- und Kleinbuchstaben, sowie Zahlen und Sonderzeichen verwendet werden, kommt man bei immer weniger Systemen weiter bei der Passwortauswahl. Leider wird oft auch nur ein roter Balken angezeigt, zusammen mit einer Warnung. Passwörter mit weniger als 12 Zeichen gelten aber auch als unsicher, wenn sie diese Kriterien erfüllen.
Lang soll es also sein. Mehr als 12 Zeichen. Und es darf nicht in Wörterbüchern vorkommen.
Alles Nutella?
Nutella findet es anscheinend sicher genug, ein 7-stelliges Passwort zu verwenden. In einem Tweet rufen sie dazu auf, mit „Nutella“ seine Geheimnisse zu sichern. Ein schlechter Scherz, dem leider vermutlich zu viele folgen:
Die am häufigsten verwendeten Passwörter sind eine Katastrophe. Mehr als 5 Millionen gekaperte Passwörter wurden durch SplashData statistisch ausgewertet. Zum fünften Mal in folge wurde „123456“ als das am meisten verwendete Passwort des Jahres ermittelt, gefolgt von „password“.
Hier die aktuelle Top-10 Liste:
Den meisten Benutzern ist anscheinend nicht klar, dass sie durch derartigen Leichtsinn riskieren, Opfer von automatisierten Angriffen zu werden. Es kann sehr schnell passieren, dass ein Erpressungs-Trojaner dann die Dateien auf dem eigenen PC verschlüsselt, so dass sie nicht mehr zu lesen sind. Nur durch Zahlung von einigen tausend Euro bekommt man seine Dateien dann wieder entschlüsselt, zusammen mit dem unguten Gefühl, nicht mehr Herr seiner Privatsphäre zu sein.
Doch was tun, wenn man sich für unzählige Konten Passwörter merken muss, die man dann auch noch regelmäßig ändern soll? Auf gar keinen Fall sollte man übrigens das gleiche Passwort für mehrere Konten verwenden, denn ist eines der Konten kompromittiert, haben die Angreifer dann auch gleich Zugriff auf die anderen Konten, wo das gleiche Passwort gilt. „Credential Stuffing“ nennt man einen solchen Angriff, bei dem bekannt gewordene Zugangsdaten bei anderen Webseiten ausprobiert werden. Die Erfolgsrate ist dabei relativ hoch.
Was also tun?
Solange wir uns mit Benutzernamen und Passwörtern authentifizieren müssen, sollten wir Passwortmanager-Programme verwenden. Dort werden die Passwörter sicher verwaltet, und durch Copy&Paste in die Webanwendung übernommen. Das hat den Vorteil, dass wir sehr lange und komplexe Passwörter verwenden können, die kein Mensch von Hand eintippen möchte. Es spricht also nichts dagegen, ein 100-stelliges Passwort zu verwenden, wenn das von der Webanwendung unterstützt wird. Ein Brute-Force-Angriff wird das nicht so schnell knacken können, so dass die Angreifer weiterziehen werden, und es mit anderen Opfern probieren wird, die es noch nicht kapiert haben.
Folgende Passwortmanager-Programme sind gängig:
Sichererer?
Noch besser als sehr gute Passwörter zu verwenden ist, wenn man neben diesen auch noch ein weiteres Merkmal verwendet, wir ein Token, das z.B. über eine Authenticator-App generiert wird. Multifakor-Authentifizierung ist der Fachbegriff dafür. Dadurch ist es für Angreifer nicht mehr möglich, durch abgefischte Passwörter den Account zu übernehmen. Im Online-Banking Bereich setzt sich das mehr und mehr durch, auch wenn viele Banken nach wie vor SMS als 2. Faktor verwenden. Dass das nicht sicher ist, darüber habe ich in einem vorigen Post berichtet.
Wer erinnert sich noch an „Universal Plug and Play“? Es wurde von Microsoft in den 90ern erfunden, um die lästigen Treiber-Installationen unter Windows zu vereinfachen. Die Idee dabei war, dass sich Geräte über Port 1900 von ganz alleine finden können, und der Benutzer gar nichts mehr tun muss, um beispielsweise seinen neuen Joystick zu verwenden. Also Einstecken und Spielen. Die Idee dahinter war also wie so oft eine Gute, aber in der Praxis lief das nicht immer (um nicht zu sagen selten) reibungslos, so dass sich schnell der Begriff „Plug and Pray“ verbreitete, der dieses Protokoll verspotten sollte.
Da dieses Protokoll keinerlei Sicherheit beinhaltet, da ihm Authentifizierung und Autorisierung fehlen, ist es ausschließlich für das interne LAN gedacht. UPnP darf also unter keinen Umständen ins offene Internet exponiert werden, denn dann werden Tür und Tor geöffnet für Neugierige und Angreifer. „Hey, kommt in mein LAN, ich zeige Euch gerne alles was ich habe“ – das wäre die native Botschaft von einem ins Internet losgelassene UPnP.
Man sollte meinen, dass es deshalb klar sein sollte, dass UPnP niemals ins Internet losgelassen werden sollte, da es so ganz ohne Sicherheitsmechanismen nur für absolut vertrauenswürdige Umgebungen gemacht ist. Leider, leider… ist dem nicht so. Im Gegenteil. Viele namhafte Hersteller von Routern bieten ein „Feature“ an: „Expose UPnP to WAN“. Gemäß einer Analyse von Akamai sind bis zu 4,8 Millionen Geräte betroffen.
Ein nicht-versierter Heim-Admin, der dieses Feature aktiviert, würde damit das Unvernünftigste tun, was in der heutigen Zeit in der Internet-Welt denkbar ist. Aber er wird noch schlimmer: Einige der Hersteller haben dieses Feature standardmäßig auch noch aktiviert. Das ist wirklich das Allerletzte – beim Schreiben dieser Zeilen fehlen mir vor lauter Entsetzen fast schon die Worte. Also am besten gleich den eigenen Router zuhause checken, ob dieser ein solches Feature hat und sicherstellen, dass es inaktiv ist.
Die Folge eines über UPnP ins Internet exponierten Routers ist, dass dieser zunächst für Brute-Force-Angriffe auf die Admin-Oberfläche erreichbar ist. Was vorher nicht der Fall war. Es ist nur eine Frage der Zeit und der Qualität des verwendeten Passworts, wie lange dieses dem Brute-Forcing standhält. Üblicherweise nicht besonders lange. Es kommt dann wie es kommen muss: der Router wird übernommen und von den bösen Buben geentert und missbraucht. Für Botnetze und andere Schweinereien.
Ein neuer Trend der kriminellen Machenschaften im Zusammenhang mit Botnetzen ist UPnProxy. Dazu wird einer der Millionen verwundbaren privaten Heimroutern für zur Verschleierung von Angriffen missbraucht, in dem er als Proxy fungiert. Wenn ein Opfer bzw. eine Strafverfolgungsbehörde versucht, einen Angreifer zurückzuverfolgen, dann führt die Route dadurch nicht direkt zum Angreifer, sondern über die verwendeten Proxies, die die Route dadurch zu verschleiern versuchen. UPnProxy ist damit ein weiteres wichtiges Instrument der organisierten Kriminalität, Angriffe noch schwerer zurückzuverfolgen.
Einmal mehr zeigt sich hier, wie ein zunächst gut gemeintes Feature (bzw. Protokoll) missverstanden wird, und durch Unwissenheit und Ignoranz zum Desaster der Internet-Sicherheit wird.
Mehr zu diesem Thema bei Bleeping Computer.
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.
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.
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.
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?
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.
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.
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.
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.
„Hack me if you can“
Am 15. November 2018 findet in Stuttgart bei EXXETA ein Meetup zum Thema „Sicherheit in Web-Anwendungen“ statt, bei dem ich einen Einblick in aktuelle Gefahren und Verwundbarkeiten biete. Ich werde versuchen anhand einiger Beispiele deutlich zu machen, wie wichtig es ist, sich um Sicherheit Gedanken zu machen. Außerdem zeige ich eine Möglichkeit, wie man in einem Projekt, bei dem man bisher nicht auf Sicherheit geachtet hat, diese sukzessive einführt.
Interessierte werden gebeten sich über Meetup.com anzumelden
Wer im schwarzen Hoodie kommt, bekommt Freibier!
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.
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:
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.
