Lade...
 

MorphIT Sicherheit

Konzepte und Überlegungen zur Sicherheit der MorphIT-Anwendung

1. Systemhärtung

Die für MorphIT benutzten Komponenten wurden additiv zusammengestellt. Es wurden also nur jene Funktionalitäten genutzt, welche auch für den Betrieb von MorphIT nötig sind.

2. Schutz von Daten und Informationen

2.1 Passwörter

Passwörter werden in der Datenbank nicht direkt hinterlegt, sondern ausschließlich deren Hash-Werte. Mit diesen ist eine zeitlich begrenzte Gültigkeit verknüpfbar. Beim Anlegen der Passwörter kann die Passwortstärke überprüft werden.

Bei der Eingabe von Passwörtern werden diese durch den Browser versteckt dargestellt.

2.2 Verschlüsselung

Der für MorphIT verwendete Web-Server kann so konfiguriert werden, dass dieser nur Kommunikation per TLS mit Server-Authentisierung und mit Verschlüsselung zulässt.

2.3 Sitzungssicherheit

Für MorphIT wurde entschieden, die Sitzungsverwaltung über WebSockets zu realisieren. Hierbei besteht eine ständige Verbindung zwischen Client und Server, so dass der Server schon aus der Information, über welchen WebSocket eine Nachricht geschickt wurde, die Sitzung zu dieser Nachricht zuordnen kann.

Hierdurch entfallen

  • Sitzungstokens und damit einhergehende Sitzungsübernahmen
  • Möglichkeiten zur Cross-Site-Request-Forgery
  • URL-Parameter mit potenziell sensiblen Informationen (Ausnahme: Direktlinks)

2.4 Caching

Um unnötiges Caching zu verhindern werden die folgenden Header gesetzt:

Pragma: no-cache
Cache-Control: no-cache, no-store
Expires
Date

2.5 Weitere sicherheitsrelevante Header

Folgende Header werden gesetzt, um die Sicherheit weiter zu erhöhen und ungewolltes Verhalten des Browser zu unterbinden.

Strict-Transport-Security:max-age=15552000; includeSubDomains
X-DNS-Prefetch-Control:off
X-Download-Options:noopen
X-Frame-Options:SAMEORIGIN
X-XSS-Protection:1; mode=block

2.6 Sicherheit im statischen Modus

Die Sicherheitsaspekte von MorphIT ohne stehende Websocket-Verbindung sind hier detailliert beschrieben.

2.7 Sensible Daten in Direktlinks

Direktlinks dienen dazu, beim Öffnen des Links direkt an eine bestimmte Stelle in ClassiX zu springen oder eine bestimmte Aktion auszuführen. Bei der Verwendung von Direktlinks werden folgende Richtlinien in ClassiX umgesetzt:

  1. Der URL-Parameter enthält nur ein Token und keine nutzer- oder aktionsspezifisichen, sensiblen Daten.
  2. Das Token ist zufällig generiert und lässt keine Rückschlüsse auf die damit verbundene Aktion zu.
  3. Falls das Token eine automatisierte Aktion ausführt, wird nur diese Aktion zugelassen und nach Ausführen der Aktion wird die ClassiX-Instanz beendet und die Client-Verbindung getrennt.
  4. Das Token ist nur einmalig gültig.

2.8 Schutz von sensiblen Assets

Die Herausgabe von sensiblen Assets kann so konfiguriert werden, dass:

  1. Der Zugriff nur nach dem Login mit entsprechendem Cookie möglich ist
  2. Die Pfade verschlüsselt sind, sodass man auch als eingeloggter Nutzer gültige Pfade nicht raten kann
  3. Der Zugriff über den Link nur solange möglich ist, wie die Instanz aktiv ist, die den Link generiert hat

Die technische Umsetzung dieses Konzepts ist unter "private Assets" dokumentiert.

3. Integrität und Injections

3.1 Angabe von MIME-Typen

Für vom Web-Server ausgegebene Dateien wird im Header steht der MIME-Typ und – soweit sinnvoll – das Encoding angegeben. Um dies zu unterstützen, wird der Header

 

X-Content-Type-Options:nosniff

 

gesetzt.

3.2 Säuberung von Benutzereingaben

Um Injection zu verhindern, werden grundsetzlich alle HTML-relevanten Metazeichen HTML-codiert. Ausschließlich statisch vorgegebene Elemente werden hiervon ausgenommen. Darüber hinaus gibt es keine direkte Möglichkeit, DOM-Strukturen zu manipulieren.

Auch bei der Zusammenstellung von Headern wird nicht auf Eingaben des Benutzers, sondern lediglich auf statische Inhalte zurückgegriffen.

4. Serverintegrität

4.1 Verbindungssicherheit

Der MorphIT-Server kommuniziert mit allen serverseitigen Prozessen über Websocket-Verbindungen, die optional über SSL abgesichert werden können. Durch die stehende Verbindung müssen Prozesse nicht für jede Anfrage authentifiziert werden und die Verbindung lässt sich nicht durch Dritte manipulieren.

4.2 Launcher

Der Launcher wird als vom Server unabhängiger Dienst eingerichtet. Somit muss sich dieser nicht besonders beim Server authentifizieren. Der Server akzeptiert eingehende Launcher-Verbindungen, die das Registrierungsprotokoll kennen. Eine Prüfung würde bedeuten, dass der Server die Kontrolle über den Startvorgang des Launchers-Prozesses haben muss, um ihm ein gemeinsames Geheimnis mitzugeben. Da die Launcher-Dienste zur Skalierung auf mehrere Rechner verteilt sein können, ist dies nicht möglich. Hierdurch lässt sich zudem zur Laufzeit bei Bedarf die Anzahl der Launcher-Prozesse an die Last anpassen. Potenziell könnte sich ein Angreifer, der das Protokoll kennt als Launcher-Instanz ausgeben und auf Anfrage Prozesse starten.

Der Server lässt jedoch keine zwei Launcher-Instanzen von der gleichen IP-Adresse zu, da zwei Launcher-Prozesse auf einer Maschine keinen Sinn machen. 

4.3 ClassiX

Der Server unterscheidet zwischen zwei Arten von ClassiX-Instanzen: interaktiv & hintergrund.

Interaktive Instanzen werden hauptsächlich im Test- & Entwicklungsbetrieb verwendet und können sich ohne weitere Authentifikation am Server anmelden. In der Standardkonfiguration (ws.morphit.interactive.connect_to_morphit) werden eingehende MorphIT-Verbindungen jedoch nie mit interaktiven ClassiX-Instanzen zusammengeschaltet, sodass ein Angreifer, der sich als interaktive ClassiX-Instanz am Server anmeldet, keinen Zugriff auf die Client-Verbindungen erhält.

Hintergrund-Instanzen sind diejenigen, die der Server bei Bedarf selbst startet. Hierbei ist es nicht ohne weiteres möglich, dass ein Angreifer sich als Hintergrund-Instanz ausgibt. Dies wird dadurch sichergestellt, dass der Server zusammen mit jedem Startbefehl einen zufälligen Nonce-Wert generiert, der mit dem Start assoziiert wird und dem Launcher mitgegeben wird. Dieser Nonce-Wert wird vom Launcher als Umgebungsvariable im gestarteten Prozess gesetzt und der gestartete ClassiX-Prozess muss sich beim Server mit genau diesem Nonce-Wert beim Server anmelden. Der Nonce-Wert verliert nach der Anmeldung seine Gültigkeit. Sollte sich ein ClassiX-Prozess als Hintergrund-Instanz mit falschem Nonce-Wert anmelden, wird die Verbindung vom Server getrennt und der Prozess erhält keine Client-Verbindungen.

 

Ein Angriffsszenario müsste wie folgt ausshen:
Bedingung: Der Angreifer hat Zugrriff auf das Intranet, nicht aber auf den Server.

  1. Der Angreifer gibt sich als neuer Launcher-Prozess aus
  2. Der Angreifer wartet, bis eine neue ClassiX-Instanz gestartet werden muss (Startbefehl). Er kann sich nicht direkt als ClassiX-Instanz ausgeben, weil die Verbindung ohne den Nonce-Wert aus dem Startbefehl abgelehnt wird.
  3. Der Angreifer gibt sich mit dem Nonce-Wert aus dem Startbefehl als neu gestartete ClassiX-Instanz aus.
  4. Der Angreifer wartet, bis die ClassiX-Instanz mit einem MorphIT-Client verbunden wird.
  5. Der Angreifer kann den Client jetzt glauben lassen, er sei mit einer ClassiX Instanz verbunden und so sensible Daten abgreifen.

Zusammenfassend ist das Angriffsszenario sehr umständlich. Der Angreifer muss bereits Zugriff auf das Intranet haben und muss warten, bis eine Instanz gestartet werden muss und diese einen Client zugewiesen bekommt ohne während dieser Zeit entdeckt zu werden. Wenn ihm das gelingt, dann kann er keine Verbindung gezielt übernehmen, sondern erhält eine vom Server zugewiesene zufällige Verbindung. Damit der Angriff nicht auffällt und der Client dem Angreifer die Daten preisgibt, muss er das MorphIT-Protokoll vollständig implementieren und mit den korrekten Views auf entsprechende Anfragen reagieren.

4.4 Admin-Konsole

Die Admin-Konsole, die Zugriff auf den Status des Server bietet, den Server herunterfahren und in gewissem Rahmen auch steuern kann, verbindet sich aus Sicherheitsgründen nur auf die lokale Adresse und der Server lehnt alle Admin-Verbindungen von remote-Adressen ab. Über die Option (ws.admin.enabled) kann die Admin-Konsolebei Sicherheitsbedenken auch vollständig deaktiviert werden.

Da die Admin-Konsole für ein reibungsloses MorphIT-Update notwendig ist, gibt es auch die Möglichkeit über die Option ws.admin.allow_eval nur den eval-Befehl der Admin-Konsole zu deaktivieren, um eine mögliche Privilege Escalation durch eval zu unterbinden, falls sich ein Angreifer bereits User-Zugang zur Maschine verschafft hat, auf welcher der MorphIT-Server läuft und falls dieser mit höheren Rechten läuft.

4.5 WebWidgets

Die WebWidgets von MorphIT (Widgets, die ausschließlich als Web-Komponente implementiert sind) verwenden im regulären MorphIT-Betrieb den gleichen Kommunikationskanal, wie der restliche MorphIT-Client. Somit gibt es dabei keine Sicherheitsbedenken.

Arbeitet der Nutzer auf einem nativen ClassiX, dann können die WebWidgets auch verwendet werden, vorrausgesetzt das ClassiX hat eine bestehende Verbindung zu einem konfigurierten MorphIT-Server. Sollte der Client ein WebWidget öffnen, dann öffnet sich ein Browser, der zu dem Server eine Verbindung aufbaut, über die er mit genau einem Widget Kommunizieren kann. Der WebWidget-Endpunkt kann so konfiguriert werden, dass er auf einem anderen Port läuft als der MorphIT-Endpunkt. Hierdurch kann durch das Sperren des verwendeten Ports verhindert werden, dass jeder Client, der Zugriff auf MorphIT hat, sich auch als WebWidget-Client ausgeben könnte.

Bei mehreren offenen WebWidgets gibt es mehrere Browser, die jeweils eine Verbindung zum Server aufbauen. Der Server muss also mehrere WebWidget-Verbindungen mit einer ClassiX-Verbindung zusammenschalten. Hierzu benötigt der Server die ClassiX-ID (aufsteigende Zahl) und die Widget-ID. Beide Parameter werden beim öffnen des Browsers über die URL übergeben. Um zu verhindern, dass sich ein Angreifer auf die WebWidgets eines Nutzers schalten kann, indem er die ID seiner ClassiX-Instanz rät, muss beim Verbindungsaufbau zusätzlich eine, von der ClassiX-Instanz bei der Registrierung am Server zufällig generierte, Session-ID übergeben werden. Diese wird ebenfalls über die URL übergeben. Da es keine Möglichkeit gibt um sicherzustellen, dass eine URL von einem bestimmten Benutzer geöffnet wird (ohne diesen per Login explizit zu authentifizieren), ist dies die höchste Sicherheit, die man beim Verbindungsaufbau erreichen kann. Kennt jemand den Link, dann kann er sich auf das WebWidget auch draufschalten. Hierbei gibt es jedoch die Limitierung, dass pro Widget-ID nur eine Verbindung akzeptiert wird.

Um zu verhindern, dass sich ein Angreifer auf als WebWidget-Client auf die ClassiX-Instanz eines anderen MorphIT-Clients raufschalten kann, teilt der Server die ClassiX-Instanzen in zwei exklusive Modi ein. Ein ClassiX, das mit einem MorphIT-Client verbunden ist, kann nicht mit WebWidget-Clients verbunden werden und ein ClassiX, das mit WebWidget-Clients verbunden ist, wird nicht mit einem MorphIT-Client zusammengeschaltet.

Bei nativen WebWidgets leitet der Server nur Nachrichten vom Typ web_widget an das verbundene ClassiX weiter, alle anderen Nachrichten werden mit einer Fehlermeldung beantwortet. Zusätzlich verhindert der Server, dass ein WebWidget, das sich unter einer Widget-Id A registriert hat, WebWidget-Nachrichten an ein Widget mit der Id B senden oder empfangen kann.

InstantView®