Kategorie Sicherheit

HomeOffice, aber sicher!

Von in Sicherheit Schlagwort , , ,
Sicherheit im Heimnetz

Die Arbeit im HomeOffice läuft normalerweise zunächst mal über das heimische Netzwerk ab, das nicht so gut überwacht und abgesichert ist wie das Netzwerk in der Firma. Deshalb ist es wichtig, dass man möglichst immer das Firmen-VPN verwendet, um die geschäftliche Kommunikation gut zu verschlüsseln. So können andere Geräte, die auch am heimischen Netzwerk hängen, die Kommunikation nicht im Klartext mitverfolgen. Falls sich dort ein Spion befindet, dann könnte das der Fall sein. Und Spione gibt es immer wieder, beispielweise in Form von allzu neugierigen Apps oder Assistenten.

Verschlüsselte Kommunikation ist zwar eh mehr und mehr der Standard, aber es gibt auch immer wieder Ausnahmen. Beispielsweise verwenden immer noch nicht alle Webseiten das verschlüsselte HTTPS, sondern noch HTTP, was eine unverschlüsselte Kommunikation darstellt. Angreifer könnten hier also mitlesen, wenn sie sich im Heimnetz befinden.

Außerdem gibt es weitere unsichere Protokolle, wie FTP für Dateiübertragung, SMB für freigegebene Order und Drucker. Auch die E-Mail Protokolle POP3, SMTP und IMAP, die in den 1980ern spezifiziert wurden, sind per se nicht abgesichert. Insbesondere ist standardmäßig die Authentifizierung unverschlüsselt, so dass Benutzername und Passwort im Klartext zum Mailserver übertragen werden. Es sein denn, die Option TLS ist im Mailclient aktiviert, was oft nicht der Fall ist.

Tipps für sichere Mailserver:

  • Um Angreifern den Zugriff auf die Mailserver zu blockieren, sollten sorgsam konfigurierte Firewall-Regeln verwendet werden.
  • Für Zugriffe aus der Ferne sollte eine Multifaktor-Authentifizierung aktiviert werden.
  • E-Mail-Dienste müssen so eingerichtet werden, dass nicht-authentifizierte Zugriffe aus der Ferne nicht möglich sind. 
  • Um zu verhindern, dass die Multifaktor-Authentifizierung umgangen werden kann, sollte IMAP dafür deaktiviert werden. IMAP unterstützt dies nicht.
  • Falls es Mitarbeiter geben sollte, die dadurch auf keine Mails mehr zugreifen können, weil sie Legacy-Mail-Dienste verwenden, können diese dann immer noch per Webclient und HTTPS auf ihre Mails zugreifen. Das wäre dann auch die richtige Gelegenheit, unsichere und veraltete Mailclients in den Ruhestand zu verabschieden.

Im Firmennetzwerk sind solche unsicheren Protokolle zumindest noch durch Firewalls und Gateways gesichert, aber im Heimnetzwerk ist das oft nicht der Fall, es sei denn, das VPN ist aktiv, so dass der komplette Traffic übers Firmennetzwerk geht.

Der aktuelle Boom der HomeOffice-Arbeit bringt aber die Kapazität vieler Firmen-VPNs an ihre Grenzen, so dass bei der IT hier dringend aufgerüstet werden muss, um diese große Last zu bewältigen. Deshalb aktivieren viele Mitarbeiter im HomeOffice das VPN erst gar nicht, so dass damit eine grosse neue Angriffsfläche entsteht. Ob diese vermehrt ausgenützt wird, werden wir wohl erst in ein paar Wochen oder Monaten erfahren, wenn es zu spät ist.

Um die genannten Spione zu bändigen, hier weitere Tipps für mehr Sicherheit und weniger Angriffsfläche im Heimnetz:

  • Alle Geräte im Heimnetz sollten mit den neuesten Sicherheits- und Firmware-Updates versorgt sein. Dies ist ein Problem für viele Geräte im LAN wie Spielekonsolen, Smartphones, TV, etc. Wenn diese veraltete Firmware haben, sind diese sehr oft angreifbar. Insbesondere der Router – das Herz Ihres LANs – muss immer aktuell sein.
  • „Tote Geräte“, die nicht mehr versorgt werden mit Updates, sollten unbedingt aus dem Heimnetz verbannt werden.
  • Standardbenutzername und das Standardkennwort müssen geändert werden. Dies ist das erste, was ein Angreifer ausprobiert, wenn er versucht anzugreifen. Die Web-Interfaces dieser Geräte sind häufig anfällig für schwerwiegende Sicherheitslücken, selbst wenn es sich um ein „dummes“ Produkt wie einen Satellitenempfänger oder eine Netzwerkfestplatte handelt. Von dort aus wird ein Angreifer den Rest des LANs inspizieren.
  • Die Verschlüsselung sollte auch auf dem privaten Netzwerkspeichergerät (NAS) aktiviert sein. Falls dabei kein Zugriff auf ein Verschlüsselungstool besteht, können die Dateien auch einfach in eine kennwortgeschützte ZIP-Datei eingefügt werden. Das ist immer noch besser, als überhaupt nichts zu tun.
  • Die meisten Heimrouter und Switches haben die Möglichkeit, mehrere verschiedene DMZ / VLAN einzurichten. Dies bedeutet, dass ein eigenes „privates“ Netzwerk für die Netzwerkgeräte einrichten werden kann, wodurch der Netzwerkzugriff auf und von diesem Gerät eingeschränkt wird.

Es hilft an dieser Stelle, den gesunden Menschenverstand zu bemühen und zu verstehen, dass ALLES gehackt werden kann, auch Ihre Hardwaregeräte. Wirklich paranoide Menschen können den ausgehenden Netzwerkverkehr ihrer Geräte jederzeit überwachen, um festzustellen, ob etwas Seltsames vor sich geht. Dies erfordert jedoch einige technische Kenntnisse. 

Ein weiterer guter Tipp ist, Netzwerkgeräte daran zu hindern, auf Websites zuzugreifen, auf die sie nicht zugreifen sollen, und ihnen nur das Abrufen von Updates und sonst nichts zu erlauben. Dazu kann man im Router meist die integrierten Firewallregeln anpassen.

Neues Video – Unzureichendes Logging und Monitoring

Von in Secure Coding, Sicherheit Schlagwort , ,

Den meisten Webanwendungen fehlt ein effektives und nachhaltiges Monitoring, über das man Angriffe erkennen kann. Und wenn man Angriffe nicht erkennt, dann kann man auch nicht darauf reagieren.
In meinem 10. Video der Secure Coding Reihe sprechen wir über dieses Thema, und was das in der Folge für Probleme mit sich bringt.

Talk „Hack me if you can“ auf der JAX2019

Von in Allgemein, Secure Coding, Sicherheit Schlagwort

Auf der diesjährigen JAX in Mainz (6.-10. Mai 2019), der Konferenz für Java, Architektur- und Software-Innovation, habe ich am 8. Mai den Talk „Hack me if you can – Sicherheit in Webanwendungen“ gehalten. Inhaltlich habe ich dabei herausgearbeitet, wie wichtig die Berücksichtigung von Sicherheitsschwachstellen ist, bzw. dass man diese konsequent und strategisch vermeidet. Die richtige Vorgehensweise ist dabei, zunächst die Angriffe zu verstehen, damit man eine wirksame Verteidigung aufbauen kann.

Es gibt viel zu viele Webanwendungen, die zu einfach zu hacken sind. Der Grund ist fast immer, dass sich die Entwickler während der Implementierung keine Gedanken über die Sicherheit machen – weil sie die Angriffe nicht kennen. Deshalb ist es eine Grundvoraussetzung für sichere Software, dass man die Grundlagen sicherer Software kennt.

Den Vortrag habe ich aus diesem Grund in 4 Teile aufgeteilt:

  1. Einleitung: Warum das Ganze?
  2. Wie man hackt
  3. Wie man sich schützt
  4. Wie man sich wehrt

In der Einleitung geht es darum, zu zeigen, dass man sich aktiv um die Sicherheit kümmern muss. Man muss die Angriffe verstehen, um wirksame Verteidigung aufbauen zu können. Ich erläutere, dass viele Basics nicht berücksichtigt werden können, wenn das Know-How bei der Entwicklung nicht vollständig vorhanden ist.

Im 2. Teil „Wie man hackt“ zeige ich die Vorgehensweise von Hackern, so wie man es auch in Hacker-Kursen lernt. Der Grund dafür ist, damit ein Verständnis aufgebaut wird, wie man eine Anwendung angreift, bzw. von der anderen Perspektive aus gesehen, wie man angegriffen wird. Dadurch kann dann im 3. Teil besser verstanden werden, welche Maßnahmen man treffen muss, damit diese offenen Flanken nicht mehr bestehen.

Der 4. Teil beschäftigt sich dann mit der angemessenen Reaktion auf Angriffe. Denn niemand muss für eine Anwendung hinnehmen, dass sie durch Angriffe lahmgelegt wird. Es gibt hier Verteidigungsmaßnahmen, die das unterbinden können. Dabei stelle ich Tools vor, die eine Schaltzentrale für Sicherheitsmonitoring bieten, damit man Angriffe auf seine Anwendungen in Echtzeit verfolgen kann, und den Abwehrmaßnahmen live bei Ihrer Arbeit zuschauen kann.

Anbei die Folien zum Vortrag als PDF
EXXETA@JAX_Hack-me-if-you-can-lowqHerunterladen

Statische Codeanalyse mit Xanitizer

Von in Sicherheit Schlagwort , , ,

Wenn man eine Webanwendung nach Sicherheits-Schwachstellen untersuchen will, dann bietet sich neben der dynamischen Analyse – Pentesten – vor allem die statische Codeanalyse an. Doch was steckt hinter den beiden Ansätzen und worin unterscheiden sie sich?

Pentesten ist eine Black-Box Analyse, bei der man die Interna der Anwendung nicht kennt. Man greift die Anwendung so an, wie es ein Angreifer auch tun würde tut. Auch wenn diese Methodik seine Berechtigung hat und wichtiger Bestandteil der Sicherheitsanalyse ist, gegenüber der statischen Codeanalyse hat sie einige Nachteile, denn viele Schwachstellen sind nicht so einfach zu erkennen. Oft ist es sogar Glücksache bzw. eine Frage des Geschicks des Pentesters, ob gut versteckte Schwachstellen in all ihren speziellen Bedingungen auch gefunden werden.

Bei der statischen Codeanalyse benötigt man den Quellcode der Anwendung. Es kann auch reichen, die Binaries der Anwendung zu haben und diese zu dekompilieren. Der Quellcode der Anwendung wird dann gezielt nach Schwachstellen untersucht, und zwar zunächst an den Stellen, wo sie üblicherweise auftreten: bei der Authentizitierung, dem Berechtigugsmanagement, und den nach außen exponierten Schnittstellen.

Die statische Codeanalyse ist also eine White-Box Analyse, bei der man sich die Logik des Programms anschauen kann. Dort gefundene Schwachstellen könnten dann in Kombination mit den Pentests viel effektiver gefunden werden. Ich empfehle sogar, beide Techniken zu kombinieren, aus mehreren Gründen:

  • Beweisführung
    • Beweisen der Gültigkeit des Findings
    • False Positives werden dadurch aussortiert (fälschlich gefundene Schwachstellen)
  • Nachvollziehbarkeit
    • Das Dev-Team kann dadurch besser nachvollziehen, dass diese Codestelle eine Schwachstelle ist
    • Die Wirksamkeit von Patches vom Dev-Team kann dadurch bewiesen werden

Tools

FindSecBugs

Es gibt verschiedene Tools für die statische Codeanalyse. Am einfachsten sind Pattern-basierte Tools wie FindSecBugs – einem Plugin für das weit verbreitete SpotBugs. Die Ergebnisse sind ganz ordentlich.

Xanitizer

Weit mehr Abdeckung kann man mit einer gezielteren Datenflußanalyse erreichen, wie es mit Xanitizer möglich ist. Man hat damit mehr Aufwand, als nur einen Scanner über den Code laufen zu lassen, aber auch bessere Resultate. Die Idee dahinter ist, dass sämtliche Benutzereingaben simuliert und durch den Code verfolgt werden. Benutzereingaben müssen generell als Gefahrenpotential, als böse eingestuft werden. Werden diese nicht gefiltert und damit neutralisiert, dann muss davon ausgegangen werden, dass dies ein Einfallstor für Angriffsvektoren ist.

Die verschiedenen Stationen, die die Benutzereingaben, in der Anwendung durchlaufen, werden von Xanitizer in 3 Kategorien eingeteilt:

  • Sources
  • Sinks
  • Sanitizer

Als Source wird die Station bezeichnet, wo Daten von außen ins System eindringen. Also Schnittstellen aller Art, sowohl von der Benutzerschnittstelle her, als auch technische Schnittstellen, beispielsweise bei einem Web-Service. Daten die hier ankommen, werden als tainted bezeichnet, also als schmutzig, die noch „gewaschen“ werden müssen.

Sinks sind die Datensenken, wohin die Daten letztendlich wandern. Wenn die Daten immer noch tainted sind, wenn sie bei den Sinks ankommen, dann ist dies ein Finding und wird im Report als Schwachstelle angezeigt.

Damit die Daten „gewaschen“ werden, braucht es die genannten Filter, die Sanitizer, die die potenziell schadhaften Daten neutralisieren. Angriffsvektoren die solche Schwachstellen ausnutzen, werden von den Sanitizern sozusagen außer Gefecht gesetzt.

Von Haus aus erkennt Xanitizer bereits viele dieser Elemente im Quellcode vollautomatisch, allerdings muss meist auch noch nachjustiert werden, damit insbesondere Sourcen erkannt werden. Sie sind die wichtigsten Elemente bei der Datenflußanalyse, da sie die Eintrittspunkte ins System repräsentieren.

Insgesamt wird eine gute Analyse durch Xanitizer ermöglicht, die allerdings einiges an Aufwand mit sich bringt. Belohnt wird man aber durch brauchbare Ergebnisse und das gute Gefühl, die Sicherheit in seiner Anwendung deutlich zu verbessern.

Wie man genau mit Xanitizer arbeitet und ihn in den Software-Development-Life-Cycle (SDLC) einbindet und so automatisiert und regelmäßig Sicherheitsanalysen durchführen kann, werde ich in weiteren Blogbeiträgen zeigen.

Neues YT-Video: Broken Authentication

Von in Secure Coding, Sicherheit Schlagwort ,

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.

UPnProxy – oder zu was Plug and Play/Pray noch so alles missbraucht werden kann

Von in Allgemein, Sicherheit

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.

Secure Coding

Von in Sicherheit Schlagwort , ,

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?

Von in Sicherheit Schlagwort , , ,

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.