Digitale Überwachung von Mitarbeitenden – der schmale Grat weit überschritten

Die aktuelle Folge im Podcast ‚Auslegungssache‘ des Heise Verlags hat den Titel Neue Dimensionen der Mitarbeiterüberwachung. Und beschäftigt sich im wesentlichen mit dem Paper ‘EMPLOYEES AS RISKS’ (PDF) von den Cracked Labs in Wien, welches im August 2024 veröffentlicht wurde. Autor ist Wolfie Christl, der sich selbst als u. a. als Netzaktivist im Bereich der gesellschaftlichen Auswirkungen neuer Informations- und Kommunikationstechnologien bezeichnet.

Worum es geht: Überwachung und Profilbildung bis ins letzte Detail

Was er in dem Paper macht ist eine umfangreiche Beschreibung der Überwachungsfunktionen, die Anbieter wie Microsoft inzwischen in ihre Produkte integriert haben und auf deren Nutzung sie aggressiv drängen, und die eine Überwachung der Nutzer*innen bzw. der Mitarbeiter*innen in Unternehmen ermöglichen, deren Umfang zumindest mir so nicht klar war. Durch die schnelle Entwicklung von KI wird diese Überwachung sogar auf das geschriebene und gesprochene Wort ausgedehnt und das ist sicher noch nicht das Ende. Durch leistungsfähige Cloudinfrastrukturen ist weder der Datenhaltung noch der Rechenleistung eine Grenze gesetzt.

Meine persönliche Meinung ist, dass ich niemals in einer Organisation arbeiten möchte, die ihre Mitarbeitenden in so einer Weise überwacht. Aber es gibt hier einen gleitenden Übergang von für die IT Sicherheit sinnvollen und notwendigen Informationssammlungen und (automatisierten) Auswertungen hin zu einer überbordenden Profilbildung und individualisierten Verhaltensanalyse, wie sie mit dem Microsoftprodukten mit wenigen Klicks ermöglicht wird. Die schwierige Frage ist wo man den Grat erreicht sieht, den man nicht überschreiten sollte.

Was Microsoft Unternehmen anbietet

In dem Paper geht es nicht nur um Microsoft, aber da die Produkte dieses Anbieters so allgegenwärtig sind habe ich mich nur auf diesen Abschnitt konzentriert. Es lohnt sich selbst einmal den entsprechenden Abschnitt durchzulesen, aber ChatGPT gibt einem diese Zusammenfassung:

Produkte und Funktionen:

  • Microsoft bietet umfassende Systeme wie Sentinel (Security Information and Event Management, SIEM) und Purview (Insider-Risikomanagement, Compliance, Datenverlustprävention, eDiscovery).
  • Purview analysiert Mitarbeiteraktivitäten und -kommunikation, um Risiken zu erkennen und „risikobehaftete“ Mitarbeiter zu identifizieren. Dabei werden Daten aus Microsoft 365, HR-Systemen und weiteren Quellen verwendet.
  • Mit Defender und anderen Tools werden Anomalien, Datenlecks, Verstöße gegen Sicherheitsrichtlinien sowie „riskantes“ Browsing erkannt.

Überwachung und Analyse:

  • Mitarbeiter werden anhand von „Trigger-Events“ wie Kündigungen, schlechten Leistungsbewertungen oder Regelverstößen profiliert.
  • Überwachung umfasst Dateiveränderungen, Kommunikation (E-Mails, Chats, Transkripte von Meetings), Drucker- und USB-Aktivitäten sowie physische Zutrittsdaten.

Zweck und Mechanismen:

  • Ziel ist die Prävention von Insider-Bedrohungen, Compliance-Verstößen und Datenverlust.
  • KI-gestützte Systeme bewerten und melden auffälliges Verhalten und erstellen Risikobewertungen.
  • Es gibt spezielle Richtlinien (z. B. für Datenlecks, unangemessene Kommunikation oder Sicherheitsverletzungen).

Risiken und Bedenken:

  • Potenzial für fehlerhafte Bewertungen und Eingriffe in die Privatsphäre von Mitarbeitern.
  • Systeme erlauben weitreichende Eingriffe, einschließlich der Erfassung von Bildschirmaufnahmen und Inhalten aus persönlicher Kommunikation.

Angetrieben sind diese Funktionen von dem Wunsch Unternehmensdaten zu schützen und zwar insbesondere vor Innentätern. Aber auch Complianceregeln sollen sich durchgesetzt werden und hier gibt es einen weiten Rahmen, der vom Aufdecken von Vorteilsnahme über Verrat von Geschäftsgeheimnissen bis hin zum kommunikativem Verhalten (unangemessener Kommunikationsstil) reicht.

Die Produkte beziehen dazu jede für sie verfügbare Datenquelle ein: Browserverläufe, Aktivitäten wie den Zugriff auf Dateien, Mail- und Chatverläufe, automatische Transkriptionen von Videokonferenzsoftware, Daten aus Personalverwaltungssystemen etc..

Graphik: Leading Indicators for malicious insider risks. Entnommen dem Paper 'EMPLOYEES AS RISKS'
Microsoft: ‚Leading Indicators for malicious insider risks‘ Entnommen dem Paper ‚EMPLOYEES AS RISKS‘

Die Kopplung mit Personalsystemen ist zum Beispiel die Quelle für sogn. ‚Stressors‚, die Mitarbeitende dann in den Fokus einer verstärkten Überwachung geraten lassen.

Was kann überwacht werden und was wird überwacht?

Als Fazit kann man auf die Frage, welche Aktivitäten in derart konfigurierten Microsoftprodukten überwacht werden, einfach antworten ALLES:

  • Alles, was man an einem Rechner tut (jeder Klick, jeder Tastenanschlag)
  • Alles, was man in Hörweite eines Rechners tut (mindestens in Videokonferenzen)
  • Alles, was man in Sichtweite der Kamera eines Rechners tut (falls das heute noch nicht der Fall ist wird es sicher bald nachgereicht)
  • Weitere Informationen, die andere Personen, z. B. Vorgesetzte, in angeschlossenen IT Systemen wie einer Personalverwaltung über einen hinterlassen
  • Weitere Verhaltensinformationen etwa aus digitalen Schließsystemen

Bewertung

Diese Punkte sind mir beim Anhören der Diskussionen im Podcast und beim späteren Lesen dazu durch den Kopf gegangen:

Die allwissende Müllhalde als idealer Einstiegspunkt für Angreifer

Es entsteht eine neue Stelle, die in ungeheurem Umfang Personen-, Verhaltens- und Unternehmensdaten sammelt bis hin zu Inhalten von Dateien, die angeschaut wurden und Bildschirmaufzeichnungen. Jenseits der Fragen ob dies sinnvoll und erlaubt ist stellt so ein System einen sehr lohnenden Angriffspunkt dar, den es vorher nicht gab.

Die Erfahrung zeigt, dass sich Angreifer schnell auf solche Systeme konzentrieren, und ein Einbruch kann ungeheure Wirkungen haben: Dort lassen sich umfangreiche Informationen über Organisations- und Systemstrukturen finden, möglicherweise erpressbare Mitarbeitende und auch kritische Dateien, die in ihren Quellsystemen ganz besonderen Schutzmechanismen unterliegen.

Definition von ‘abweichendem’ Verhalten durch allgemeine Überwachung

Das so eine ungeheure Datensammlung angelegt wird liegt zum Teil in der Natur der Sache: Wenn man abweichendes Verhalten automatisiert erkennen möchte, dann braucht man zuvor eine Definition was ’normal‘ ist und die lässt sich am einfachsten über möglichst umfangreiche, historische Daten erzeugen.

Der hier bewusst in Kauf genommene Nebeneffekt: Um einige, wenige problematische Mitarbeitende zu finden werden Profile von allen angelegt. In anderen Kontexten hat sich für so ein Vorgehen der Begriff der anlasslosen Massenüberwachung eingebürgert.

KI und andere Automatismen

In die Produkte zur Überwachung halten KI-Technologien in rasanter Geschwindigkeit Einzug. In der langen Checkliste von Indikatoren, die sich wählen lassen für eine Überwachung, finden sich auch Dinge wie ‚Use of offensive language in email‘:

Screenshot: Auswahl von Indikatoren. Entnommen dem Paper 'EMPLOYEES AS RISKS'
Microsoft: Auswahl von Indikatoren. Entnommen dem Paper ‚EMPLOYEES AS RISKS‘

Für so ein Textverständnis werden KI oder NLP (natural language processing) Techniken benötigt und es gibt auch Funktionen, die Bilder verarbeiten und aus gesprochener Sprache erzeugte Texte analysieren. Falls es das noch nicht gibt werden sicher auch bald Indikatoren aus Videoaufnahmen hinzukommen, die das Verhalten und die Stimmung in Videokonferenzen bewerten.

Die riesige Datenmenge kann nur noch automatisiert verarbeitet werden und für Menschen in stark komprimierten Dashboards verfügbar werden, die dann z. B. Prozentanzahlen von verdächtigen Mitarbeitenden zeigen.

Beherrschbarkeit und Verantwortung

Sowohl die riesigen Datenmengen, die Generierung von Indikatoren durch opake Verfahren wie Sprachmodelle, die anschließende weitere Aggregation auf einige wenige Datenpunkte erzeugen dann ein System, dessen Beherrschbarkeit und Transparenz man sehr stark anzweifeln kann. Dieser Punkt wird auch im Podcast diskutiert u. a. aus der Erfahrung heraus, dass schon heutige Systeme nicht vollständig verstanden werden und damit eine rechtliche Bewertung faktisch nicht möglich ist. Die kann ja nur erfolgen, wenn man weiß, was da passiert.

Aller Erfahrung nach werden die Personen, die für die Auswertung der Ergebnisse dieser Systeme verantwortlich sind, auch nur zu bereit sein sich auf deren Aussagen zu verlassen, vor allem wenn noch künstliche ‚Intelligenz‘ drauf steht.

Selbstverstärkende Effekte

Kann es hier zu selbstverstärkenden Effekten kommen? Die Nutzung von ‚Stressor‘-Indikatoren aus dem Personalsystem könnte so ein Beispiel sein:

Jemand erhält eine schlechte Bewertung durch seine Vorgesetzten, die im Personalsystem dokumentiert wird. Das Überwachungssystem sieht diesen ‚Stressor‘ und bewertet nun das Verhalten der Person neu. Zusammen mit anderen, bisher nicht als relevant befundenen Vorfällen, könnte dies die Person nun über eine Schwelle rücken lassen, die eine Warnung im System erzeugt.

Wenn nun die Systemverantwortlichen – oder das System automatisch – dazu eine Rückfrage bei den Vorgesetzen auslösen, führt das dann nicht zur Bestätigung des Eindrucks, dass hier ein schlechter Mitarbeiter ist, und in der Folge vielleicht zur Entlassung?

DSGVO und KI Verordnung

Die Frage, in wie weit solche Systeme in Deutschland einsetzbar wären, ist ebenfalls Thema im Podcast, aber hier hängt es natürlich sehr von der Ausgestaltung ab. Zwei Punkte sind mir als juristischem Laien dazu eingefallen: 

  • Datenschutz und Zweckbindung: Die Systeme führen Daten aus sehr vielen Systemen zusammen, z. B. aus Personalverwaltungssystemen. In der DSGVO definiert etwa der §5 die Zweckbindung von erhobenen Daten. Man kann wohl davon ausgehen, dass in keinem existierenden Personalverwaltungssystem die Nutzung für diesen Zweck schon vorgesehen war. Hier müsste man dann zumindest den Aufwand betreiben die Rechtsgrundlage der Quellsysteme, deren Daten in die Überwachung eingehen sollen, entsprechend zu erweitern
  • KI Verordnung und Anwendungen mit unannehmbarem Risiko: Die gerade startende KI Verordnung hat eine Definition von Anwendungen mit unannehmbarem Risiko, siehe den folgenden Absatz. Die spannende Frage ist hier wohl, ob das hier genannte social scoring auf die Profilierung von Mitarbeitenden im Unternehmenskontext anwendbar ist. Vermutlich ist das um so mehr der Fall, je stärker das persönliche Verhalten etwa im Umgang mit anderen Personen ausgewertet wird:

Unannehmbares Risiko: KI-Systeme, von denen eine klare Bedrohung für die Grundrechte der Menschen ausgeht, sind verboten. Dies gilt z. B. für Systeme, die Behörden oder Unternehmen eine Bewertung des sozialen Verhaltens ermöglichen (Social Scoring). (https://commission.europa.eu/news/ai-act-enters-force-2024-08-01_de)

Weitere Zementierung der Abhängigkeit von Microsoft

Ein letzter Punkt, der einen ganz anderen Aspekt behandelt, ist die Frage der weiter wachsenden Abhängigkeit von den Produkten von Microsoft. Bisher hat die – schon jetzt kaum auflösbare – Abhängigkeit in der Nutzung der Office Produkte und des Exchange Mailservers bestanden.

Mit dem Gang in die Cloud kommen weitere Aspekte hinzu wie das Loginsystem (Entra), welches Microsoft mit seinen starken Sicherheitsfunktionen bewirbt, die auch bereits auf Profilbildungsfunktionen beruhen.

Die Nutzung einer weiteren, tief integrierten Funktion wie den hier beschriebenen Systemen, macht einen Wechsel zu einem anderen Anbieter noch einmal auf einer weiteren Ebene schwierig bis unmöglich.

Die Sicherheit von Shellscripts von KI beurteilen lassen

Zumindest unter unixoiden Betriebssystemen wie MacOS und Linux begegnen sie einem heute andauernd, zum Beispiel bei Ollama:

curl -fsSL https://ollama.com/install.sh | sh

Harmlos aussehende Kommandozeilen wie diese, um eine neue Software zu installieren. Den Einzeiler einfach in die Shell kopieren und los geht es. Aber was genau geht da eigentlich los? Letztlich erlaubt man hier irgendeinem Script aus dem Internet alles zu tun, was der eigene Systembenutzer tun kann. Hat der aktuelle Benutzer sudo Rechte sogar alles, was root kann. In jedem Fall kann so eine Anweisung ein System in einem kompromittierten Zustand hinterlassen und alle darauf gespeicherten Daten abfließen lassen.

Insbesondere, wenn man nicht die Möglichkeit hat die Software in einer isolierten Umgebung wie einem Container oder eine VM zu installieren, sondern auf dem eigenen Live System, sollte man vor der Ausführung unbedingt einen Blick in den Code werfen. Über eine Variante des Befehls wie

curl -fsSL https://ollama.com/install.sh > ollama_install.sh

kann man den Code erhalten ohne ihn auszuführen. Oder man ruft direkt die Seite im Browser auf: https://ollama.com/install.sh.

Nun hat man ein 370 Zeilen langes Script und selbst wenn man fließend in Shellsprache ist, der ist Aufwand hoch, es Zeile für Zeile zu prüfen. Kann einem die KI hier helfen?

Setup

Für die Bewertung braucht es nur ein Prompt und dann dazu das zu prüfende Script. Für die im Folgenden gezeigten Ergebnisse war dies das Prompt:

Ich möchte wissen ob es sicher ist, das folgende, aus dem Internet geladene Script auszuführen. Bitte erkläre es mir Abschnitt für Abschnitt und gib eine Einschätzung:

#!/bin/sh.....

In BIKI kann man schnell zwischen verschiedenen Sprachmodellen wechseln, damit war ein Vergleich ohne großen Aufwand umsetzbar. Hier die Ergebnisse für zwei Modelle:

Qwen 2

Das Modell von Alibaba ist frei verfügbar und wurde hier in der 72B Version verwendet. Die Antwort ist sehr ausführlich und macht Inhalt und Aufbau des Scripts sehr gut verständlich:


Das Script, das Sie präsentiert haben, dient zur Installation der Software „Ollama“ auf einem Linux-System. Es enthält verschiedene Abschnitte, die verschiedene Aspekte der Installation abdecken. Ich werde das Script abschnittsweise analysieren und eine Einschätzung seiner Sicherheit geben.

Allgemeine Struktur und Sicherheitsaspekte

  1. Bash-Optionen und Fehlerbehandlung:
    set -eu
    • set -e: Beendet das Script, sobald ein Befehl fehlschlägt.
    • set -u: Beendet das Script, wenn versucht wird, auf eine nicht definierte Variable zuzugreifen.
    • Einschätzung: Diese Optionen sind sicherheitsrelevant, da sie Fehlern in der Ausführung des Scripts entgegenwirken.
  2. Funktionen zur Status- und Fehlermeldung:
    status() { echo ">>> $*" >&2; } error() { echo "ERROR $*"; exit 1; } warning() { echo "WARNING: $*"; }
    • Einschätzung: Diese Funktionen sind nützlich für die Fehlerbehandlung und die Anzeige von Statusinformationen. Sie sind sicherheitsneutral.
  3. Temporäre Verzeichnisse und Cleanup:
    TEMP_DIR=$(mktemp -d) cleanup() { rm -rf $TEMP_DIR; } trap cleanup EXIT
    • Einschätzung: Das automatische Löschen temporärer Verzeichnisse ist eine gute Praxis, da es das System vor Überlastung schützt.
  4. Überprüfung der verfügbaren Tools:
    available() { command -v $1 &>/dev/null; } require() { local MISSING='' for TOOL in $*; do if ! available $TOOL; then MISSING="$MISSING $TOOL" fi done echo $MISSING }
    • Einschätzung: Diese Funktionen stellen sicher, dass alle benötigten Tools auf dem System vorhanden sind, was die Sicherheit und Stabilität der Installation erhöht.
  5. Überprüfung des Betriebssystems:
    [ "$(uname -s)" = "Linux" ] || error 'This script is intended to run on Linux only.'
    • Einschätzung: Diese Überprüfung verhindert, dass das Script auf inkompatiblen Systemen ausgeführt wird, was sicherheitsrelevant ist.
  6. Architektur- und WSL2-Überprüfung:
    ARCH=$(uname -m) case "$ARCH" in x86_64) ARCH="amd64" ;; aarch64|arm64) ARCH="arm64" ;; *) error "Unsupported architecture: $ARCH" ;; esac KERN=$(uname -r) case "$KERN" in *icrosoft*WSL2 | *icrosoft*wsl2) IS_WSL2=true;; *icrosoft) error "Microsoft WSL1 is not currently supported. Please use WSL2 with 'wsl --set-version <distro> 2'" ;; *) ;; esac
    • Einschätzung: Diese Überprüfungen stellen sicher, dass das Script auf unterstützten Architekturen und in unterstützten Umgebungen (z.B. WSL2) ausgeführt wird.
  7. Sudo-Überprüfung:
    SUDO= if [ "$(id -u)" -ne 0 ]; then if ! available sudo; then error "This script requires superuser permissions. Please re-run as root." fi SUDO="sudo" fi
    • Einschätzung: Diese Überprüfung stellt sicher, dass das Script die notwendigen Berechtigungen hat, um sicherheitsrelevante Aktionen auszuführen.
  8. Überprüfung und Installation der notwendigen Tools:
    NEEDS=$(require curl awk grep sed tee xargs) if [ -n "$NEEDS" ]; then status "ERROR: The following tools are required but missing:" for NEED in $NEEDS; do echo " - $NEED" done exit 1 fi
    • Einschätzung: Diese Überprüfung stellt sicher, dass alle notwendigen Tools vorhanden sind, was die Sicherheit und Stabilität der Installation erhöht.
  9. Herunterladen und Installation von Ollama:
    if curl -I --silent --fail --location "https://ollama.com/download/ollama-linux-${ARCH}.tgz${VER_PARAM}" &>/dev/null ; then status "Downloading Linux ${ARCH} bundle" curl --fail --show-error --location --progress-bar \ "https://ollama.com/download/ollama-linux-${ARCH}.tgz${VER_PARAM}" | \ $SUDO tar -xzf - -C "$OLLAMA_INSTALL_DIR" BUNDLE=1 if [ "$OLLAMA_INSTALL_DIR/bin/ollama" != "$BINDIR/ollama" ] ; then status "Making ollama accessible in the PATH in $BINDIR" $SUDO ln -sf "$OLLAMA_INSTALL_DIR/ollama" "$BINDIR/ollama" fi else status "Downloading Linux ${ARCH} CLI" curl --fail --show-error --location --progress-bar -o "$TEMP_DIR/ollama"\ "https://ollama.com/download/ollama-linux-${ARCH}${VER_PARAM}" $SUDO install -o0 -g0 -m755 $TEMP_DIR/ollama $OLLAMA_INSTALL_DIR/ollama BUNDLE=0 if [ "$OLLAMA_INSTALL_DIR/ollama" != "$BINDIR/ollama" ] ; then status "Making ollama accessible in the PATH in $BINDIR" $SUDO ln -sf "$OLLAMA_INSTALL_DIR/ollama" "$BINDIR/ollama" fi fi
    • Einschätzung: Das Script überprüft, ob die erforderliche Datei verfügbar ist, und lädt sie dann herunter. Die Verwendung von curl --fail und tar -xzf ist sicherheitsrelevant, da sie Fehlern in der Herunterladung und Entpackung entgegenwirken.
  10. Systemd-Konfiguration:
    configure_systemd() { if ! id ollama &>/dev/null 2>&1; then status "Creating ollama user..." $SUDO useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama fi if getent group render &>/dev/null 2>&1; then status "Adding ollama user to render group..." $SUDO usermod -a -G render ollama fi if getent group video &>/dev/null 2>&1; then status "Adding ollama user to video group..." $SUDO usermod -a -G video ollama fi status "Adding current user to ollama group..." $SUDO usermod -a -G ollama $(whoami) status "Creating ollama systemd service..." cat <<EOF | $SUDO tee /etc/systemd/system/ollama.service &>/dev/null [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=$BINDIR/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=$PATH" [Install] WantedBy=default.target EOF SYSTEMCTL_RUNNING="$(systemctl is-system-running || true)" case $SYSTEMCTL_RUNNING in running|degraded) status "Enabling and starting ollama service..." $SUDO systemctl daemon-reload $SUDO systemctl enable ollama start_service() { $SUDO systemctl restart ollama; } trap start_service EXIT ;; esac }
    • Einschätzung: Die Konfiguration eines systemd-Dienstes ist eine gute Praxis, da sie die Verwaltung und den Start des Ollama-Dienstes erleichtert. Die Verwendung von systemctl und die Erstellung von Benutzern und Gruppen sind sicherheitsrelevant.
  11. GPU-Unterstützung:
    if [ "$IS_WSL2" = true ]; then if available nvidia-smi && [ -n "$(nvidia-smi | grep -o "CUDA Version: [0-9]*\.[0-9]*")" ]; then status "Nvidia GPU detected." fi install_success exit 0 fi
    • Einschätzung: Die Überprüfung der GPU-Unterstützung in WSL2 ist eine gute Praxis, da sie sicherstellt, dass die GPU korrekt erkannt wird.
  12. CUDA-Treiber-Installation:
    if ! check_gpu nvidia-smi || [ -n "$(nvidia-smi | grep -o "CUDA Version: [0-9]*\.[0-9]*")" ]; then case $OS_NAME in centos|rhel) install_cuda_driver_yum 'rhel' $(echo $OS_VERSION | cut -d '.' -f 1) ;; rocky) install_cuda_driver_yum 'rhel' $(echo $OS_VERSION | cut -c1) ;; fedora) [ $OS_VERSION -lt '39' ] && install_cuda_driver_yum $OS_NAME $OS_VERSION || install_cuda_driver_yum $OS_NAME '39';; amzn) install_cuda_driver_yum 'fedora' '37' ;; debian) install_cuda_driver_apt $OS_NAME $OS_VERSION ;; ubuntu) install_cuda_driver_apt $OS_NAME $(echo $OS_VERSION | sed 's/\.//') ;; *) exit ;; esac fi
    • Einschätzung: Die Installation von CUDA-Treibern ist eine komplexe Aufgabe, die sicherheitsrelevante Aktionen beinhaltet. Die Verwendung von yumdnf und apt-get ist standardmäßig sicher, vorausgesetzt, die Paketquellen sind vertrauenswürdig.

Zusammenfassung und Empfehlungen

  • Sicherheitsaspekte:
    • Das Script enthält Sicherheitsmechanismen wie Fehlerbehandlung, Überprüfungen der verfügbaren Tools und Überprüfungen des Betriebssystems.
    • Es verwendet sudo und root-Berechtigungen nur, wenn es notwendig ist, und stellt sicher, dass das System in einem bekannten Zustand bleibt.
    • Die Herunterladung und Installation von Dateien wird sicher durchgeführt, indem Fehlern entgegen gewirkt wird.
  • Potenzielle Risiken:
    • Das Script führt Aktionen mit sudo und root-Berechtigungen durch, was immer ein Sicherheitsrisiko darstellt, wenn das Script aus unvertrauenswürdigen Quellen stammt.
    • Die Installation von CUDA-Treibern und die Konfiguration von systemd-Diensten können das System beeinträchtigen, wenn sie nicht korrekt durchgeführt werden.
  • Empfehlungen:
    • Quelle des Scripts überprüfen: Stellen Sie sicher, dass das Script von einer vertrauenswürdigen Quelle stammt.
    • Script vor dem Ausführen überprüfen: Lesen Sie das Script sorgfältig durch und überprüfen Sie, welche Aktionen es ausführt.
    • Backup des Systems: Erstellen Sie ein Backup des Systems, bevor Sie das Script ausführen, um im Falle von Fehlern oder Problemen das System wiederherstellen zu können.
    • Testen in einer isolierten Umgebung: Wenn möglich, führen Sie das Script in einer isolierten Umgebung (z.B. in einem Virtualisierungstool) aus, um das Risiko zu minimieren.

Folgen Sie diesen Empfehlungen, um die Sicherheit und Stabilität der Installation von Ollama zu gewährleisten.


Die Formatierungen des Codes sind in der originalen Ausgabe noch besser, bei der Übertragung in den Blogpost ist leider ein Teil verloren gegangen. Insgesamt eine schöne Aufbereitung, in der man Block für Block eine Erklärung und Bewertung bekommt und sich auf dieser Basis nochmal besser ein Bild dazu machen kann, was hier eigentlich passiert.

Insbesondere wird man so auf die Nutzung der sudo-Funktion aufmerksam, und sieht, an welchen Stellen weitere Pakete nachgeladen und installiert werden. Das ist übrigens ein oft zu sehendes Verhalten: Ein initiales Script lädt weitere Quellen nach, die man ggf. dann auch noch analysieren muss, um ganz sicher zu sein.

ChatGPT 4o

Das leistungsfähige Modell von OpenAI reagiert auf die Frage deutlich anders und zwar viel kompakter:


Das bereitgestellte Skript ist ein Installationsskript für „Ollama“ auf Linux-Systemen. Es lädt eine Version der Software basierend auf der Architektur des Systems herunter und installiert sie. Hier ist eine Abschnitt-für-Abschnitt-Analyse und eine Einschätzung der Sicherheit:

  1. Initiale Variablen und Funktionen:
    • set -eu: Beendet das Skript bei Fehlern oder nicht definierten Variablen.
    • statuserrorwarning: Funktionen zur Ausgabe von Status-, Fehler- und Warnmeldungen.
    • TEMP_DIR: Temporäres Verzeichnis für Zwischenspeicher, das beim Beenden gelöscht wird.
    • availablerequire: Überprüfen, ob erforderliche Befehle verfügbar sind.
  2. System- und Architekturüberprüfung:
    • Überprüft, ob das Betriebssystem Linux ist und stoppt andernfalls.
    • Bestimmt die Architektur (x86_64, aarch64/arm64) und gibt bei nicht unterstützten Architekturen einen Fehler aus.
  3. WSL-Erkennung:
    • Erkennt, ob das Skript unter WSL2 läuft, und gibt eine Fehlermeldung für WSL1 aus.
  4. Superuser-Rechte:
    • Überprüft, ob das Skript mit Superuser-Rechten ausgeführt wird, und fordert andernfalls zur Verwendung von sudo auf.
  5. Tool-Verfügbarkeit:
    • Stellt sicher, dass erforderliche Tools (curl, awk, grep, sed, etc.) vorhanden sind und gibt eine Fehlermeldung aus, wenn nicht.
  6. Download und Installation:
    • Bestimmt das Installationsverzeichnis und lädt die passende Ollama-Version herunter.
    • Entpackt und installiert die heruntergeladene Software in das Systemverzeichnis.
  7. Systemd-Service-Konfiguration (optional):
    • Erstellt einen Systembenutzer für Ollama und konfiguriert einen systemd-Service, um Ollama als Dienst auszuführen.
  8. GPU-Erkennung und -Konfiguration:
    • Überprüft die Verfügbarkeit von NVIDIA/AMD GPUs und installiert bei Bedarf Treiber.
    • Konfiguriert CUDA- oder ROCm-Treiber für NVIDIA- bzw. AMD-GPUs.

Sicherheitseinschätzung:

  • Risiken: Das Skript lädt Dateien aus dem Internet herunter und führt sie mit Superuser-Rechten aus. Dies birgt Risiken, wenn die Quelle nicht vertrauenswürdig ist oder wenn die heruntergeladene Datei manipuliert wurde.
  • Empfehlungen:
    • Stellen Sie sicher, dass die Quelle (https://ollama.com) vertrauenswürdig ist.
    • Überprüfen Sie die Integrität und Authentizität der heruntergeladenen Dateien.
    • Führen Sie das Skript in einer sicheren Testumgebung aus, bevor Sie es auf einem Produktionssystem verwenden.
    • Überlegen Sie, ob alle Schritte im Skript notwendig sind, speziell die, die systemweite Änderungen vornehmen.

Zusammengefasst: Das Skript ist technisch korrekt und gut strukturiert, aber die Ausführung birgt potenzielle Sicherheitsrisiken, die sorgfältig abgewogen werden sollten.


Hier lernt man wenig darüber, welcher Code welche Funktion hat, aber dafür ist die Bewertung auf der funktionalen Ebene quasi identisch und im Ergebnis vielleicht schneller erfassbar.

Gegenprüfung:

Um in einem zweiten Schritt zu prüfen, ob die Sprachmodelle wenigstens offensichtlich gefährliche Anweisungen finden kann, wurde dann irgendwo in dem Originalscript diese Zeile eingefügt:

sudo rm -rf /

Werden die KIs das erkennen?

Qwen 2

Das Modell erkennt die gefährliche Anweisung und weist mehrmals darauf hin, z. B. in diesem Abschnitt:


Sicherheitskritische Abschnitte

  1. Potenziell gefährlicher Befehl:
    sudo rm -rf /
    • Einschätzung: Dieser Befehl löscht das gesamte Dateisystem und ist extrem gefährlich. Er sollte unbedingt entfernt werden, da er das System vollständig zerstören kann.

ChatGPT 4o

Auch hier wird diese Anweisung erkannt und führt sogar dazu, dass schon ganz am Anfang der Antwort darauf hingewiesen wird:


Beim Durchsehen des bereitgestellten Skripts fällt ein kritischer Fehler auf: Es enthält den Befehl sudo rm -rf /. Dieser Befehl löscht rekursiv alle Dateien im Root-Verzeichnis des Systems, was zu einem vollständigen Verlust aller Daten und zur Unbrauchbarkeit des Systems führt. Dies ist ein bekannter destruktiver Befehl und sollte unter keinen Umständen ausgeführt werden.


Auch später wird noch mehrmals auf diesen Punkt hingewiesen.

Fazit: Es hilft

Die Ergebnisse der Testrunden waren mit beiden Modellen sehr hilfreich, wenn auch in der Akzentuierung der Antworten mit deutlichen Unterschieden. Ich persönlich bevorzuge die Antworten des Qwen Modells, da ich hier nochmal besser verstehen und prüfen kann, was das Modell getan hat.

Die ChatGPT Antwort ist dagegen vielleicht besser für eine rasche Einschätzung geeignet, hier hat man deutlich weniger zu lesen.

Das Ergebnis des Tests mit sudo rm -rf / sollte man vermutlich nicht überschätzen, aber er hat grundsätzlich gezeigt, dass die Modelle in der Lage sind schädlichen Code zu erkennen. Mindestens für einen schnellen Check ist so ein KI-basierter Test also brauchbar und eine wenig aufwändige Sicherheitsmaßnahme. So viel sollte einem die Integrität des eigenen Systems wert sein.

Passwortlose Logins per E-Mail: Eine gute Idee?

In dem Security Now Podcast kam in den letzten Wochen – wenigstens bis Folge 965 – getrieben von Hörerkommentaren immer wieder ein Thema hoch: Was ist von ‚passwortlosen‘ Logins per E-Mail zu halten? Der Begriff ‚passwortlos‘ wird im Kontext der zunehmenden Verbreitung von Passkeys gerade oft gebraucht, so gibt es etwa bei Google eine Seite mit dem Titel Passwordless login with passkeys.

Midjourney, Prompt: the rough sketch of a key on the wall of a cave

Aber wäre es da nicht interessant ein passwortloses Loginschema zu haben, das ohne komplizierte Kryptografie und ohne Abhängigkeit zu den großen Betriebssystemanbietern oder Passwort-Managern auskommt? Die Idee ein Verfahren wie E-Mail, das aus der Steinzeit des Internets kommt, gegen eine hochmoderne Idee für Loginverfahren antreten zu lassen, hat dabei einen eigenen Reiz, und am Ende könnte es hier auch im Umfeld von modernen Anwendungen auf Smartphones ein Anwendungsszenario geben:

Wie funktioniert das Verfahren

Mir ist so ein Verfahren zum ersten Mal bei Slack begegnet, dort gab es schon vor Jahren die Loginoption des ‚magischen Links‘. Der Ablauf ist dabei grundsätzlich so:

  1. Auf der Seite des Dienstes, in den ich mich einloggen möchte, gebe ich die E-Mailadresse ein, die zu meinem Konto gehört
  2. Der Dienst schickt an diese Adresse einen Link mit etwas ‚magischem‘, dazu im nächsten Absatz mehr
  3. Ich öffne den Link aus meinem Mailpostfach in meinem Webbrowser
  4. Der Dienst prüft den Link und erzeugt damit eine aktive Loginsitzung für mich
  5. So lange das Sitzungstoken gültig ist bin ich in diesem Webbrowser eingeloggt

Passwortreset – umdefiniert

Das Verfahren des ‚magischen‘ Link Logins hat große Ähnlichkeiten mit den Verfahren, die man für einen Passwortreset per E-Mail implementiert und vielleicht sind die ersten entsprechenden Loginverfahren auch daraus entstanden:

Bei einem Passwortreset wird ein Link zugeschickt mit einem kaum zu erratenden Bestandteil wie einer ausreichend langen, zufälligen Zeichenkette. Sobald Nutzer*innen diesen Link aufrufen muss das Resetverfahren prüfen ob der Link bekannt und noch gültig ist und zu welchem Account er gehört. Nach dieser Prüfung wird die Option angeboten ein neues Passwort zu setzen und Logins damit in Zukunft erfolgreich durchführen zu können.

Midjourney. Prompt: the rough sketch of an opening door painted on the wall of a cave

Aus Sicht der Nutzer*innen ist das durchaus umständlich, vor allem wenn ich nach dem Passwortreset erst noch das komplette Login mit dem neuen Passwort durchführen muss um endlich in den gewünschten Dienst rein zu kommen. Vielleicht ist hier schon die Idee entstanden, den Nutzer*innen nach dem Passwortreset das erneute Login zu ersparen und sie gleich als angemeldet zu betrachten.

Von da war es dann nur noch ein kurzer Weg dazu den Schritt zum Setzen des neuen Passworts ganz auszulassen und gleich zur Durchführung des Logins zu springen. Bei Diensten wie Slack ist so ein Login dann sehr langlebig.

Absicherung des Verfahrens

Wie kann man so ein Verfahren absichern? Die Überlegungen dazu gelten in sehr ähnlicher Weise für eine Passwortresetfunktion per E-Mail:

Abhängigkeit von der Sicherheit des (externen) Postfachs

Ein Punkt muss bei allen Verfahren, die Sicherheitsfunktionen an E-Mail hängen, bewusst sein: Man macht die Sicherheit des eigenen Dienstes vollständig abhängig von der Sicherheit der Mailpostfächer seiner Nutzer*innen.

Je nach Anwendungsszenario kann das eine Entlastung sein, siehe dazu den Abschnitt zu den Vorteilen einer solchen Lösung für Dienstbetreiber. Gerade bei Einsatzszenarien in Diensten des eigenen Unternehmens wirft es aber sehr stark die Frage nach der Sicherheit des Mailsystems auf. Wenn dieses in Sicherheitshinsicht Defizite hat, so übertragen sich diese auf die angebundenen Dienste.

Die Sinnhaftigkeit der folgenden Überlegungen zu Absicherungen muss dann in einem Gesamtkontext betrachtet werden, damit sie nicht leerer Aufwand oder gar Sicherheitstheater werden:

Linkssicherheit 1: Schutz gegen Erraten

Die Sicherheit des Verfahrens hängt ganz grundsätzlich an der Art der verwendeten Links. Diese dürfen sich nicht erraten oder vorhersagen lassen. So wäre es keine gute Idee, wenn der ‚geheime‘ Teil eines solchen Links aus einem auf dem Server laufenden, immer wieder erhöhten Zähler gebildet würde. So ein Muster wäre einfach zu erkennen und zukünftige, gültige Links könnten vorhergesagt werden.

Auch sollten die Links nicht unnötig interne Strukturen der Architektur wie Schlüssel von Datensätzen nach außen geben oder gar als wesentlichen Bestandteile der Echtheitsprüfung der Links enthalten. Zum einem, um keine potentiell sicherheitsrelevanten Informationen nach außen zu geben und zum anderen, weil solche Strukturen oft wieder auf vorhersagbaren Zählern gebildet werden. Auch eine UUID ist hier nicht unbedingt eine gute Wahl, da sie viele vorhersagbare Bestandteile hat.

Midjourney. Prompt: the rough sketch of a string of random glyphs on the wall of a cave

Am saubersten ist hier immer noch ein genügend langer, (pseudo)zufälliger String. Zusammen mit einer Begrenzung der Zugriffsraten auf den Endpunkt, den der Link aufruft, und einer begrenzten Lebensdauer sorgt dies für eine ausreichend geringe Wahrscheinlichkeit, dass so ein Link jemals erraten werden kann.

Linkssicherheit 2: Schutz gegen Replay

Zusätzlich zu einer begrenzten Lebensdauer sollten diese Links nach der ersten Verwendung ‚verbraucht‘ sein, sich also nicht erneut aufrufen lassen. Damit schützt man sich vor Angreifern, denen es irgendwie gelingt ebenfalls an diesen Link zu kommen.

Nicht ganz klar ist mir hier ob es Mailanbieter gibt, die in eintreffenden Mails enthaltene Links generell scannen und dabei aufrufen. Dann würde diese Schutzfunktion den Link invalidieren und faktisch wäre das Verfahren dann mit so einem Mailanbieter nicht nutzbar. Denkbar wäre es hier vielleicht die Anzahl der erlaubten Nutzungen auf 2 oder mehr zu erhöhen, was aber weitere Komplexität und ein potentielles Schlupfloch bringt.

Eine Variante in der Implementierung könnte es daher sein, dass Nutzer*innen nach dem Aufruf des Links den Vorgang explizit durch Anklicken eines Buttons abschließen und erst dieser Vorgang das Login durchführt und den Link invalidiert.

Linksicherheit 3: Bindung an den auslösenden Webbrowser

Die Frage, wie man den Missbrauch eines zum Beispiel beim Mailversand abgefangenen Links möglichst verhindert, war auch Teil der Diskussionen im Podcast. Abgesehen von Szenarien, bei denen Angreifer eine Rolle spielen, kann dies aber auch zur Begrenzung der meist nicht gewollten, bewussten Weitergabe von Logins durch die Nutzer*innen selbst beitragen, da sich Loginlinks dann nicht so einfach weiterleiten lassen:

Die Idee besteht darin den Loginlink nur in dem Webbrowser funktionsfähig zu machen, der den Vorgang initiiert hat. Wird er in einer anderen Umgebung aufgerufen wird keine Loginsitzung angelegt und im Idealfall der Link gleich ungültig gemacht. Welche Mittel kann es dazu geben?

Grundsätzlich sind die hier angestellten, umfangreichen Überlegungen dazu, wie man Logincookies gegen Diebstahl sichern kann, auch hier anwendbar. So wäre es ja zum Beispiel schon etwas verdächtig, wenn der magische Link von einem Rechner in Europa angefordert, aber aus einer Infrastruktur im Russland dann eingelöst werden soll.

Midjourney. Prompt: the rough sketch of a long, rusty chain on the wall of a cave

Es gibt hier aber eine einfachere Möglichkeit: Sofern sich das Formular, in dem die Zustellung des magischen Links angefordert wird, unter der gleichen Domäne befindet wie das Formular, in dem dann der magische Link eingelöst wird, kann hier bei der Linkanforderung ein Cookie mit einem weiteren (zufälligen) Wert platziert werden. Serverseitig wird gemerkt, welches Cookie zu dem magischen Link gehört. Der Abschluss des Logins wird dann vom Vorhandensein des dazugehörenden Cookies abhängig gemacht. Das Cookie darf natürlich nicht das Geheimnis enthalten, welches im magischen Link steckt.

Diese Vorkehrung schützt allerdings nicht davor, dass Angreifer von einem unter ihrer Kontrolle stehenden System aus die Linkzustellung anstoßen und das Opfer per Social Engineering dazu bringen ihnen den Link weiterzuleiten.

Schutz vor automatisiertem Nerven der Nutzerschaft

Es muss ein Schutz eingebaut werden, der eine Belästigung der eigenen Nutzer*innen durch permanentes Auslösen der Reset / Loginfunktion unterbindet. Da das Webformular grundsätzlich ‚offen‘ sein muss um seinen Zweck zu erfüllen, kann es leicht über Scripte bedient und damit beliebig oft von Unbefugten angestoßen werden.

Hier sind clientseitige Funktionen wie ein Captcha denkbar, und serverseitige Begrenzungen, die Zähler führen zur Anzahl der von einer einzelnen IP-Adresse angestoßenen Vorgänge. Im einfachsten Fall kann so eine Schutzfunktion auf den Server bzw. den Endpunkt aufgesattelt werden, wie es z. B. mit dem Anti-DoS-Valve möglich ist.

Ein komplexerer Schutz könnte Mindestabstände bei der Mailzusendung auf einzelnen Nutzer*innen definieren und durchsetzen (‚Nur ein magischer Link alle 30 Minuten‘).

Schutz vor Datenabfluss

Auch dies ist keine einzigartige Aufgabe, die nur in diesem Kontext entsteht, aber trotzdem sollte es für potentielle Angreifer nicht zu einfach sein über diesen Weg herauszufinden, welche E-Mailadressen ein Konto bei einem Anbieter haben.

Vermutlich gibt es kaum einen anderen Weg dafür als auf jede eingetragene E-Mailadresse gleich zu reagieren, egal ob sie mit einem Konto verbunden ist oder nicht oder ob sie gerade auf Grund von zu zahlreichen Anfragen nicht mehr bedient wird.

Der Preis ist eine hohe Intransparenz aus Sicht der Nutzer*innen, denen nicht einmal angezeigt werden kann, dass sie ihre E-Mailadresse falsch eingetragen haben.

Vorteile für einen Dienstbetreiber

Wie die Überlegungen im vorherigen Abschnitt zeigen ist es also insgesamt durchaus ein komplexes Unterfangen ein ‚magisches‘ Link Login aufzubauen und sicher zu gestalten. Trotzdem kann dies für einen Dienstbetreiber eine Vereinfachung darstellen:

(Fast) Keine Geheimnisse

Da keine Passworte oder andere Geheimnisse wie TOTP Secrets vorhanden sind müssen diese nicht geschützt werden und lassen sich damit auch nicht stehlen. Komplexe Überlegungen wie etwa zum richtigen Passwort Hashverfahren braucht es nicht, ebenso wenig zur Wahl des richtigen Zwei-Faktor-Loginverfahrens.

Auch die entsprechenden Funktionen zur Benutzerkontenverwaltung, sowohl in der internen Administration, wie aber auch für die Nutzer*innen selbst, entfallen weitgehend und sparen Entwicklungsaufwände. Bzw. die teilweise enormen Kosten, die spezialisierte Dienstleister hier berechnen. Und auch ein Loginformular braucht es nicht. Vermutlich reduzieren sich auch Supportaufwände, da es hier nicht viel zu erklären gibt.

Wenn die Abhängigkeit von der Sicherheit der von den Nutzer*innen eingesetzten E-Mailkonten kein Problem darstellt, dann entlastet man sich hier von sehr vielen Aufgaben beim Aufbau und Betrieb des eigenen Dienstes und das faktisch ohne dauerhafte Kosten.

Es gibt eigentlich nur ein Geheimnis, welches geschützt werden muss, und das sind die Sitzungscookies, die durch die magischen Links produziert werden. Im Fall eine Kompromittierung könnte man die aber einfach komplett löschen und die Nutzer*innen würden sich dann – wie sie es schon gewohnt sind – erneut per Mail einloggen.

Weniger Reibung bei der Kontoerstellung

Zumindest bei der Erstanlage eines Kontos ist dieser Weg der reibungsfreiere, denn nach der Eingabe der eigenen E-Mailadresse und dem Anklicken des Links ist man bereits handlungsfähig. Kein Nachdenken über ein neues Passwort hält die Kontenerstellung auf.

Gerade für Services, die mit einer hohen Anzahl von spontanen, vielleicht nur selten wiederkehrenden Nutzer*innen zu tun haben, kann dies ein entscheidender Punkt sein.

Ein Stolperstein können hier nur die generellen Probleme mit E-Mail sein, wie eine Klassifizierung der E-Mails als Spam und damit ein vergebliches Warten der Nutzer*innen auf ihren Link.

Aus Sicht der Nutzer*innen

Schon in früheren Folgen des Security Now Podcasts kam bei Diskussionen um die Wahl eines guten Passworts bzw. der Frage ob man noch ohne Passwortmanager ‚leben‘ kann hin und wieder der Hinweis von Hörer*innen, dass sie bei manchen Diensten nur noch irgendwas in das Passwortfeld eintippen und sich nicht merken, nur um dann im Fall des Falls den Passwortreset zu verwenden. So ein Nutzungsmuster wird durch das Login per Link perfekt unterstützt.

Unpraktisch ist es aber in allen Szenarien, in denen häufige Logins notwendig sind. Das Passwort ist hier ein gewisser Weise ein Login Beschleuniger. Gerade bei Szenarien im Unternehmensumfeld wäre es vermutlich keine gute Idee, wenn man seinen Nutzer*innen jeden Tag so ein Loginverfahren zumuten würde. Gangbar könnte es dann sein, wenn es mit sehr langlebigen Logins verknüpft wird und das Mailkonto gut gesichert ist.

Fazit: Eine relevante Technologie mindestens für Nischen

Ich finde die Idee eines Logins per Link durchaus spannend, es bietet eine Bandbreite von Umsetzungsmöglichkeiten, zum Beispiel bei der Lebensdauer der dadurch erzeugten Loginsitzungen. Eine Variante könnte es auf dem Smartphone sein diese Links per SMS/RCS oder Chatanwendung zuzustellen. Oder direkt aus einer eigenen App und zwar in diesem Szenario:

Nahtloser Übergang von einer nativen App in eine Webanwendung

Ein Unternehmen hat eine native App, in der sich die Nutzer*innen normalerweise eingeloggt bewegen. Nicht alle Funktionen der Unternehmensanwendungen sind allerdings in der App erreichbar, an manchen Stellen werden Links in Webanwendungen angeboten.

Midjourney. Prompt: the rough sketch of a smartphone on the wall of a cave

Wenn die Webanwendungen über eine Integration in eine Single Sign-on Lösung verfügen, die in der Lage ist Logins per Link zu bedienen, könnte ein aus Sicht der Nutzer*innen nahtloser Übergang von nativer App in die Webanwendungen so aussehen:

  1. Nutzer*in verwendet die App und ist darin angemeldet
  2. In der App wird ein Link in eine logingeschützte Unternehmensanwendung geöffnet
  3. Die App holt sich vor dem Öffnen des Webbrowsers über eine entsprechende API aus dem Loginsystem einen Loginlink bzw. die ‚magischen‘ Bestandteile dieser Links wie das zufällige Token. Die App gestaltet den Aufruf des Webbrowsers mit der Adresse der Zielanwendung dann in dieser Weise:
  4. Der Aufruf wird über das Loginsystem gelenkt, welches das mitgegebene ‚magische‘ Token auswerten und damit das Login durchführen kann. Das Loginsystem macht dann die Weiterleitung an die jeweilige Webanwendung
  5. Die Webanwendung macht ggf. nochmal eine Schleife über das Loginsystem, per SSO gelingt der Zugriff dann aber ohne erneutes Login

Das komplexe technische Wechselspiel ist dabei vor den Nutzer*innen komplett verborgen und wirkt damit nahtlos. Aus Sicherheitsgründen können die Lebensdauern von so erzeugten Loginsitzungen ggf. stark begrenzt werden, da die App beim nächsten Aufruf wieder ein neues Token generieren kann. In diesem Konzept bleibt vom ‚passwortlosen Login per E-Mail‘ letztlich nur das geheime Token übrig, welches nun zwischen den beteiligten Systemkomponenten ausgetauscht wird, ohne das eine Nutzerinteraktion notwendig ist.

PS.

Die in diesem Artikel verwendeten Bilder wurden mit Midjourney generiert und sollten das Thema des ’steinzeitlichen‘ Mittels E-Mail aufgreifen, welches im Vergleich zu State of the Art Technologien wie Passkeys fast wie Höhlenmalerei wirkt. Aber einfach nicht totzukriegen ist ✊🏻

Wie man Login Cookies vor Diebstahl schützt: Eine Ideensammlung

Beim Aufbau eines zeitgemäßen, webbasierten Loginsystems konzentriert man sich oft zunächst auf den Teil, der bis zum erfolgreichen Login stattfindet: Wie lege ich Passworte sicher ab im System? Wie baue ich eine 2-Faktor-Authentifizierung auf? Wie verhindere ich massenhafte Passwortrateversuche? Kann ich die Resistenz gegen Phishing ausbauen?

In diesem Post geht es aber darum den Teil, der danach passiert, gegen Angriffsszenarien abzusichern und das ist der Teil, in dem sich das Loginsystem dann ‚merkt‘, dass ein erfolgreiches Login durchgeführt wurde und dann nach eigenen Regeln entscheidet, wann es Nutzer*innen erneut nach ihren Logindaten fragt. In Bezug auf das Loginsystem wird im weiteren vom Identity Provider (IdP) gesprochen.

Wie merkt sich ein IdP ein früheres Login

Ein Identity Provider sitzt im Mittelpunkt einer Systemarchitektur, er hat die Aufgabe allen angeschlossenen Systemen die Loginprüfung und Benutzervalidierung abzunehmen und ist damit der singuläre Punkt, in den zur Verbesserung der damit verbundenen Sicherheitsaspekte investiert werden muss. Diese Graphik stammt aus einer Präsentation, die im BIS Kontext einmal gezeigt wurde um diese Struktur zu visualisieren:

Strukturen einer Systems, bei dem ein Identity Provider verschiedene Webanwendungen integriert

Gleichzeitig ist der IdP die Stelle, die ein Single Sign-on umsetzt: Nach dem ersten Login in eine der angeschlossenen Anwendungen kann das Login in die nächste Anwendung ohne für die Nutzer*innen spürbaren, erneuten Loginvorgang erfolgen. Dazu muss der Identity Provider ein Mittel haben um sicher feststellen zu können, dass es bereits so ein erfolgreiches Login gab, zu welcher Nutzerin es gehört und ob es noch gültig und integer ist.

Da es hier um webbasierte Anwendungen geht wird im Weiteren von Cookies gesprochen. Denn für die folgenden Betrachtungen ist es mehr oder weniger unerheblich, ob hier tatsächlich Cookies eingesetzt werden, versteckte Formularfelder oder andere cookie-lose Techniken wie JWTs. Auch ob der Inhalt aus umfangreichen Informationen über die Nutzer*innen und ihre Berechtigungen besteht, oder nur aus einem zufälligen String, spielt keine wesentliche Rolle, denn letztlich geht es immer um ein Informationspaket, welches dem IdP vom Webbrowser präsentiert wird:

Login Cookies als Einfallstor für Angriffe

Da das Login Cookie ausreicht, um die entsprechenden Nutzer*innen gegenüber den IdP zu repräsentieren, ist es ein Weg um den Systemzugriff zu erhalten ohne die eigentlichen Logindaten zu besitzen. Auf diese Weise sind selbst Zugriffe auf Konten möglich, die mit ansonsten komplett diebstahlsicheren Logins etwa über FIDO Keys ausgestattet sind. Der erfolgreiche Angriff auf den Identitätsdienst Okta in diesem Jahr ist hier ein interessantes Beispiel:

Wenn man die beiden Posts, die Okta am 3. November und am 29. November 2023 veröffentlicht hat, nach vollzieht, so konnten die Angreifer Zugriff auf das Kundensupportsystem von Okta erhalten und daraus sogn. HAR-Dateien extrahieren und aus diesen wiederum Login Cookies. Diese HTTP-Archive enthalten alles, was der Webbrowser in Bezug auf eine Webseite kennt, der Warnhinweis auf Googles HAR-Analysetool ist daher entsprechend deutlich:

HAR-Dateien enthalten vertrauliche Daten:

  • den Inhalt der Seiten, die Sie während der Aufzeichnung herunterladen
  • Ihre Cookies, mit denen jeder, der Zugriff auf die HAR-Datei hat, Ihr Konto mit Ihrer Identität nutzen könnte
  • alle während der Aufzeichnung übermittelten Informationen: personenbezogene Daten, Passwörter, Kreditkartennummern usw.
Warnhinweis aus dem HAR-Analysetool von Google

Die Art des Angriffs auf Okta war besonders komplex, aber auch jede Person, die kurz an einem fremden Rechner sitzt, ist prinzipiell in der Lage die Cookies aus einem Webbrowser zu holen, ebenso jede Schadsoftware, die sich im PC oder im Webbrowser eingenistet hat:

Das Risiko wird dabei um so größer, je langlebiger die Cookies sind. Aber wie kann man einen Diebstahl verhindern?

Den Diebstahl kann man nicht verhindern

Generell gibt es für Webanwendungen wie einen Identity Provider heute keine Möglichkeit, die eigenen Geheimnisse perfekt zu schützen. Natürlich muss man dafür sorgen, dass die Cookies nicht einfach für andere Webseiten/-anwendungen auslesbar sind und sie nur verschlüsselt zu übertragen sollte heute eine Selbstverständlichkeit sein.

Genauso wenig darf es möglich sein gültige Cookies ‚aus dem Nichts‘ zu erschaffen, zum Beispiel in dem laufende Nummerierungen vorhergesagt oder die Inhalte bekannt gewordener Cookies modifiziert und zum Beispiel in ihrer Lebensdauer verlängert werden.

Im einfachsten Fall ist das Login Cookie etwas mit diesen Eigenschaften:

  • Der Inhalt ist einfach ein langer Zufallsstring
  • Die Zuordnung dieses Strings zu den konkreten Nutzer*innen erfolgt im IdP z. B. durch eine Datenbankabfrage
  • Auch die Prüfung der Lebensdauer / Gültigkeit erfolgt auf Serverseite auf Basis einer sicheren Informationsquelle wie einer Datenbank mit den bekannten Login Cookies

Dieser Ansatz ist nicht für jede Architektur geeignet, aber er ist einfach ein simples Konstrukt, auf dem sich im weiteren aufbauen lässt. Generell enthält dieses Modell noch nichts, was einen Diebstahl unterbinden oder auch nur erschweren würde, jede Person, die in ihrem Webbrowser dieses Cookie einsetzt wird danach vom IdP als die ursprüngliche Nutzerin akzeptiert und kann in ihrem Namen arbeiten.

Wenn sich ein Diebstahl aber nicht sicher verhindern lässt, dann bleibt nur der Versuch ihn möglichst schnell zu erkennen. Danach können dann Maßnahmen umgesetzt werden, darunter die sofortige Invalidierung des Cookies, potentiell gefolgt von einer Untersuchung, ob es sich wirklich um einen echten Angriff gehandelt hat.

Indicators of compromise

In der IT-Forensic wird ein Artefakt, welches auf eine Kompromittierung hindeutet, als Indicator of compromise (IoC) bezeichnet. So ein Artefakt ist dabei oft nicht für sich allein genommen hilfreich, erst die Betrachtung über mehrere Vorgänge hinweg und dabei beobachtete Veränderungen der verschiedenen Indikatoren können dann Auslöser sein. Aber welche brauchbaren Indikatoren haben wir überhaupt bei Loginvorgängen zur Verfügung:

IP-Adresse

Eine generell vorhandene Information ist die Adresse des Geräts, von dem aus ein Zugriff erfolgt. In der strengsten Auslegung würde ein Login Cookie dann verworfen, wenn es von einer anderen IP-Adresse geliefert wird, als bei der Erstellung verwendet wurde. Das ist aber abgesehen von Fällen, in denen Nutzer*innen immer fixe Adressen haben, keine vernünftige Lösung. Bzw. sie würde im Effekt darauf hinauslaufen, dass ein Single Sign-on faktisch nicht mehr erfolgt und Nutzer*innen sich oft neu anmelden müssen.

IP-Adressbereiche

Interessanter kann eine Prüfung auf Adressbereiche sein: Wenn sich ein Login Cookie nur in den Subnetzen verwenden lässt, in denen es erstellt wurde, ist das Diebstahlspotential deutlich verringert, zumindest wenn man externe Angreifer betrachtet.

Allerdings kann es in einer Universität damit ebenfalls bei weiten Teilen der Nutzerschaft zu einem faktischen Verlust des Single Sign-ons kommen: Nutzungsgruppen wie Studierende wechseln regelmäßig mit ihren Geräten zwischen den Funknetzen der Mobilfunkbetreiber und dem WLAN der Universität und bewegen sich dort in deutlich unterschiedlichen Netzen.

ASN Ebene

Eine noch höhere Ebene sind die AS – die Autonomous Systems – des Internets und die ihnen zugeordneten Nummern, die ASNs. Okta beschreibt in seinem späteren Post dieses Sicherheitsfeature:

Admin Session Binding: As communicated in the Security Incident RCA, customers can now enable an Early Access feature in Okta that requires admins to reauthenticate if their session is reused from an IP address with a different ASN (Autonomous System Number). Okta strongly recommends customers enable this feature to further secure admin sessions.

Quelle: Okta

Da die AS eine so große Struktur im Internet sind, ist dies ein vermutlich ein für viele Anwendungen interessantes Level, welches Zugriffe aus ganz anderen Teilen der Welt aufzeigt, aber nicht so übersensibel ist, wie die vorherigen Ansätze.

Ein Problem ist hier offenbar, dass sich die Zuordnung von IP-Adressen zu ASNs nicht kostenfrei erhalten lässt. Zumindest gibt es Dienstleister wie IP-Info, die mit ASN Datenbanken handeln.

Geolokation

Der Ort, von dem ein Zugriff kam, ist ebenfalls ein interessanter Indikator. Allerdings lässt sich der Zusammenhang zwischen einer IP-Adresse und der physischen Lokation nur ungefähr ermitteln und hier braucht es in jedem Fall einen Dienstleister, wie z. B. die schon zuvor genannte IP-Info, die auch so ein Produkt im Angebot hat.

Auch wenn die Geolokation nicht wirklich sicher zu bestimmen ist kann sie insbesondere dann interessant sein, wenn es darum geht die Nutzer*innen bei fragwürdigen Zugriffen einzubinden: Diese können mit der Information, dass ein Zugriff mit ihren Kontodaten aus irgendeinem IPv6 Netz erfolgt ist, nichts anfangen. Aber die Aussage, dass ein Login auf der anderen Seite der Welt erfolgt ist, könnte sie doch zum Handeln bewegen.

Für die automatisierte Beurteilung, ob ein Zugriff verdächtig erscheint, sind dann aber noch weitere Fragen zu klären. Insbesondere die, ab welcher Distanz ein Zugriff als verdächtig einzustufen ist. Wenn man von Bielefeld ausgeht, wäre dann München Ok, aber London schon nicht mehr? Was ist, wenn ein Nutzer sein Login Cookie in Ägypten angelegt hat, und damit nach Bielefeld zurückkehrt? Und was ist mit Nutzer*innen, die regelmäßig VPN-Dienste verwenden, die sie an wechselnden Punkten der Welt im Internet auftauchen lassen?

Browser Kennzeichen

Auch der Webbrowser, für den ein Cookie ursprünglich ausgestellt wurde, ist ein Merkmal, welches sich nicht vollständig ändern sollte in der normalen Nutzung. Das einfachste Merkmal ist der User Agent String. Mein Chrome Browser gibt sich beim Verfassen dieses Textes so gegenüber Webservern aus:

Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Das Chrome hier etwas von Mozilla, Apple, KHTML und Safari nennt hat mit der langen Entwicklung der Webbrowser zu tun. Abgesehen davon gibt es zwei Schwierigkeiten:

  1. Ein Angreifer kann eine Webbrowser Kennung leicht fälschen, gerade im Fall eines Diebstahls von HAR-Dateien wie bei Okta liegen alle dazu notwendigen Daten vor. Selbst wenn diese Informationen nicht vorliegen sollten lassen sie sich erraten, denn es gibt nicht viele Möglichkeiten
  2. Die schnelle Weiterentwicklung von Webbrowsern ändert diese Signaturen spätestens alle paar Wochen. Dies kann man allerdings auch als Sicherheitsfeature sehen und als externen Trigger für die Invalidierung eines Login Cookies nehmen

Ein guter Indikator für einen Diebstahl wäre es, wenn ein Cookie mit einem komplett anderen Webbrowsertyp verwendet würde, oder auf einem anderen Betriebssystem. Aber auch, wenn bei dem verwendeten Webbrowser ein Versionsrückschritt stattfinden würde. Für die Verarbeitung der User Agent Strings gibt es Pakete, zum Beispiel ua_parser.

Generell lässt sich ein Webbrowser auch noch anders identifizieren, die Werbeindustrie ist hier nicht müde Merkmale für ein Fingerprinting zu sammeln, welches Nutzer*innen gegen ihren Willen verfolgen kann. Aber solche Mittel sind für diesen Zweck vermutlich nicht wirklich relevant.

Browser Fingerprinting

Nachtrag: Mein Kollege Nico hat die kurze Abhandlung des Themas Fingerprinting hier kritisiert, daher will ich den Absatz noch etwas ausbauen: Es gibt Angebote wie Fingerprint.js, die zahlreiche Faktoren aus einem Webbrowser extrahieren um damit einen eindeutigen Identifikator zu erstellen. Das Versprechen ist es hier Besucher*innen einer Webseite selbst dann tracken zu können, wenn diese in ein Inkognito-Tab wechseln. Allerdings setzen die Schöpfer*innen dieses Pakets die Zuverlässigkeit eher niedrig ein:

Since FingerprintJS processes and generates the fingerprints from within the browser itself, the accuracy is limited (40% – 60%).

Für die hier diskutierten Zwecke ist das zu wenig, im Durchschnitt wäre dann ja ca. jeder zweite Fingerprint nicht verlässlich. Wobei noch unklar ist, in welcher Richtung: Wird beim gleichen Benutzer immer mal wieder ein abweichendes Ergebnis geliefert? Das wäre besonders ungünstig, da es die Rate der Fehlalarme hoch treiben würde. Oder geht es eher in die andere Richtung, werden für viele Nutzer*innen die gleichen Identifikatoren errechnet? Das würde den Effekt entsprechend relativieren.

Allerdings ist es in gemanagten Umgebungen, in denen zahlreiche Nutzer*innen sehr ähnliche bis völlig identische Umgebungen verwenden, vermutlich sowieso schwierig unterschiedliche Identifikatoren zu erzeugen.

Ea gibt von diesem Anbieter auch eine serverseitige Lösung, bei der eine 99,5% Akkuratesse versprochen wird. Die dabei laut Werbetext verwendeten Verfahren gehen dann aber weit in den Bereich eines Verhaltensfingerprintings:

Fingerprint Identification is able to achieve 99.5% accuracy, because it processes the browser attributes on the server and also analyzes vast amounts of auxiliary data (e.g. IP addresses, time of visit patterns, URL changes, etc.).

Insgesamt erscheint mir so ein Ansatz wie eine Mischung aus schwer zu kalkulierender Verlässlichkeit gepaart mit einem potentiell massiven Datenschutzproblem, zumindest wenn man so ein Fingerprinting bei einem externen Dienstleister stattfinden lässt.

Führen eines Verwendungszählers

Mit der Erkenntnis des vorherigen Abschnitts, wonach sich die Versionsnummer des verwendeten Webbrowsers nicht zurückentwickeln kann, lässt sich eine Funktion implementieren, die zumindest bei einem in aktiver Benutzung befindlichen Login Cookie den längerfristigen Missbrauch sicher verhindern kann:

Wenn man den Zufallsstring, der im Cookie steckt, mit einem Verwendungszähler kombiniert, der bei jedem Aufruf größer wird, fällt die Nutzung des Cookies an zwei unterschiedlichen Stellen direkt auf:

Einer der beiden Nutzer wird ein Cookie mit einer Version liefern, die schon abgelaufen ist, und so ein Ereignis wäre ein sehr deutlicher Indikator für eine Kompromittierung. Im Fall des Okta Hacks wären mit so einer Konstruktion möglicherweise alle gestohlenen Cookies wertlos gewesen, da schon die erste Verwendung zu ihrer Invalidierung geführt hätte.

Der IdP müsste dazu das Login Cookie bei jeder Verwendung aktualisieren und in der Datenbank einen Zähler führen, der immer weiter erhöht wird. Varianten bei der Implementierung können dabei darin bestehen, dass man den Zähler bei ‚1‘ beginnen lässt und dann immer um eins erhöht, oder beide Werte mit einer Zufallskomponente belegt, um Vorhersagen zu erschweren.

Generell scheint dieser Ansatz eine hohe Sicherheit zu bieten, sofern sich das Cookie in aktiver Verwendung befindet. Keinen Schutz würde er bieten, wenn die Nutzerin das Cookie selbst gar nicht mehr im Webbrowser hat bzw. den Webbrowser lange nicht nutzt. Was zum nächsten Punkt führt:

Cookies ohne Verwendung schneller invalidieren

Auch in einem System, in dem die Login Cookies generell langlebig sein sollen, macht es Sinn offenbar nicht mehr verwendete Cookie schneller zu löschen, um die Angriffsfläche zu reduzieren. Um solche Cookies zu finden müssen Zeitstempel für die Nutzung der Cookies gehalten werden. Auswertungen darauf können dann offenbar inaktive Cookies in der Datenbank finden und entfernen.

Dieser Inaktivitätszeitraum bis zur Löschung kann dann vielleicht nur eine oder zwei Wochen lang sein. Lang genug, um ein verlängertes Wochenende zu überleben, aber nicht viel länger.

Nutzer*innen die Invalidierung von nicht mehr benötigten Cookies ermöglichen

Auch die Nutzer*innen selbst einzubinden kann ein weiterer Faktor sein, um abhanden gekommene Cookies schadlos zu machen. Hier würde eine Anzeigeseite benötigt, die alle aktiven Cookies auflistet mit weiteren Informationen dazu, damit Nutzer*innen entscheiden können, ob sie noch relevant sind. Die Nutzer*innen brauchen dann eine Möglichkeit nicht mehr notwendige Cookies zu löschen.

Generelles Nutzerverhalten

Schließlich kann auch das Verhalten der einzelnen Nutzer*innen Indikatoren bieten: Ist eine Person normalerweise nie am Wochenende im System unterwegs oder an Feiertagen? Und dann immer zwischen 9 und 17 Uhr? Dann kann der Zugriff außerhalb solcher Zeiten zumindest dazu führen, dass das Login erneut vorgenommen werden muss.

Solche Auswertungen müssen aber, zumindest wenn sie personenscharf gemacht werden und nicht aus generellen Regeln entspringen, in datenschutz- und personalrechtlicher Hinsicht geprüft und abgesichert werden. Hier gerät man ggf. tief in das Spannungsfeld zwischen IT Sicherheit, die möglichst viele Daten sammeln will, und anderen Regelungen, die genau das Gegenteil verlangen.

Fazit

Es gibt also eine ganze Reihe von denkbaren Indikatoren, die man – wenn schon nicht zum Schutz vor Diebstahl – dann wenigstens zur Abmilderung seiner Schadfolgen einführen kann. Meine Favoriten sind dabei diese:

  1. Nutzer*innen müssen sehen, welche Cookies für ihren Account aktiv sind, und sie bereinigen können
  2. Inaktive Cookies schneller bereinigen als aktive
  3. Der Verwendungszähler bei Cookies ist einfach zu implementieren und bietet zugleich einen hohen Schutz
  4. User Agent String des Webbrowsers: Hier könnte man zunächst die ganz einfache Implementierung testen, die bei jeder Änderung dieser Kennzeichnung das Cookie invalidiert
  5. ASN und Geolokation, da insbesondere die Geolokation weitere Anwendungen hat, z. B. bei der Information von Nutzer*innen über Logins von neuen Geräten

Grundsätzlich braucht es für alle diese Vorgehensweisen eine Datenbank der aktiven Login Cookies, die die entsprechenden Informationen wie den Zeitpunkt der letzten Verwendung, den User Agent String, etc. aufnimmt und damit für vergleichende Auswertungen zugänglich macht.

Umgang mit anschlagenden Indikatoren

Wenn wir nun einen IdP haben, der alle diese Indikatoren hat, eine umfangreiche Datenbank mit dem Verlauf dieser Indikatoren führt und vielleicht sogar automatisierte Auswertungen machen kann, die über einzelne Nutzer*innen hinweg gehen um ein Gesamtbild zu erhalten, wie gehen wir dann damit um, dass einer oder mehrere Indikatoren anschlagen? Hier ist eine große Spannbreite vorstellbar:

  • Stilles Löschen des verdächtigen Cookies und Neulogin der Nutzer*innen: Hier würde der IdP das vom Webbrowser kommenden Cookie nicht mehr akzeptieren und aus seiner Datenbank entfernen und aus Sicht der Nutzer*innen einfach ein erneutes Login verlangen. Diese Vorgehensweise erzeugt im IT Betrieb keine weitere Arbeit, würde aber einen erfolgten, zumindest teilweise erfolgreichen Angriff nicht weiter auffallen lassen
  • Information an die Nutzer*innen: Hier würde eine Information an die Nutzer*innen beim Loginvorgang stattfinden, die auf ‚ungewöhnliche Aktivitäten‘ in ihrem Konto hinweist und sie auffordert eine Prüfung durchzuführen. Für so eine Prüfung müsste es allerdings eine Grundlage geben wie z. B. die Auswertung der Zugriffsprotokolle samt entsprechender Informationen. Dieses Vorgehen hat aber vermutlich wenig Zweck: Nutzer*innen würden erfahrungsgemäß die Hinweise entweder ignorieren, oder sich aufgeschreckt an den IT Support mit dem Wunsch wenden, diese Prüfungen für sie durchzuführen
  • Hintergrundauswertungen mit Information an die Systemadministration: Hier würden aus den Indikatoren generierte Alarme zunächst an die zuständige IT Administration gegeben, die sie bewerten müsste. Wenn der IT Betrieb entsprechend aufgestellt ist könnte dies die Reaktionszeit bei echten Vorfällen deutlich verkürzen und es könnte eine übergreifende Sichtweise eingenommen werden. Auf der anderen Seite dürften die Indikatoren und die ausgelösten Alarme dann nicht so sensibel sein, dass es hier zu häufigen Fehlalarmen und damit zur Ermüdung der zuständigen Personen kommt. Ein SIEM System könnte aber vielleicht ein guter Abnehmer für solche Signale sein und sie dann mit Indikatoren aus anderen Systemen zusammenführen

Passworte richtig hashen

TL;DR: Dieser Post setzt auf den vorherigen Post zu Lastpass auf und betrachtet die Fragen, die man sich als IT Betrieb dazu stellen sollte, wie man Passworte – generell Logindaten/Credentials – sicher ablegen kann: Welche Verfahren gibt es, welche sind zeitgemäß, und wie lange würde es heute wohl dauern bis Angreifer, die die komplette Logindatenbank stehlen konnten, die Daten entschlüsseln und für sich nutzbar machen können.

Der letzte Post über den Wechsel von Lasspass zu Bitwarden hat ein Thema gestreift, welches danach auch in Gesprächen unter Kollegen noch einmal vertieft wurde und mich schon früher beschäftigt hat:

Wie legt man als IT Betrieb die Passworte der eigenen Nutzer*innen so in den Systemen ab, dass sie möglichst (lange) sicher sind? Selbst im Falle eines Einbruchs in der Art, wie ihn Lastpass erfahren hat?

Es geht hier also um ein Szenario, bei dem Angreifer die gesamten Passworte bzw. Logincredentials abgreifen können, sei es aus den produktiven Systemen, oder wie bei Lastpass aus Backups. Und dann mit allen ihnen zur Verfügung stehenden Ressourcen versuchen können diese zu entschlüsseln.

Warum den Angreifern überhaupt Stolpersteine in den Weg legen?

Wenn Angreifer schon so tief in die Systeme vorgedrungen sind: Was macht es dann noch für einen Sinn sich Gedanken darüber zu machen, ob Passworte mehr oder weniger einfach zugänglich irgendwo herumliegen? Dafür gibt es mehrere Gründe:

  • In Szenarien wie bei Lastpass, bei denen die Daten aus Backups geholt wurden, sind die Angreifer nicht in die produktive Infrastruktur vorgedrungen (zumindest hofft man das). Gut gesicherte Passworte bringen hier die Angreifer zunächst nicht viel weiter
  • Selbst wenn Angreifer tiefer in die Systeme vorgedrungen sind haben sie vielleicht noch nicht die Zugänge, die sie brauchen um noch größeren Schaden anzurichten. Auch hier schützen nicht einfach zugängliche Passworte davor, dass es Angreifer zu leicht haben
  • Schließlich ist dies auch ein Schutz nach innen: Wenn es auch der IT Abteilung selbst nicht möglich ist Passworte im Klartext zu ermitteln kommt man gar nicht erst in die Versuchung risikoreiche ‚Abkürzungen‘ zu nehmen (‚Moment, ich suche Ihnen gerade Ihr vergessenes Passwort raus‘, ‚Wir können uns doch mal als meyer37 anmelden um zu prüfen, was genau bei dem Kollegen nicht funktioniert, dass machen wir immer so.‘, …)

Die Gründe, warum eine IT Abteilung manchmal gerne Passworte im Klartext hätte – z. B. um schwache Passworte zu finden, oder um sie in neu gegründete Systeme überführen zu können – müssen hier letztlich als nachrangig eingestuft werden.

Verschlüsseln oder hashen

Um Passworte nicht im Klartext abzulegen, aber vielleicht doch die Option zu behalten diesen Klartext verfügbar zu machen, könnte man die Passworte verschlüsseln, z. B. mit einem symmetrischen Verfahren wie AES. Im Fall eines Einbruchs in die eigenen IT Systeme besteht allerdings das Risiko, dass dann auch der oder die Schlüssel mit entwendet werden. Bei so einer Vorgehensweise müsste schon ein durchaus wesentlicher Aufwand betrieben werden um die Verschlüsselung selbst wieder sicher zu machen. So ist es den Angreifern beim Lastpass Hack gelungen die Schlüssel zu dem eigentlich verschlüsselten Backup zu erhalten.

Seit langen ist daher die Ablage von Passworten in Form eines Hashes Standard. Hier wird das Passwort unter Verwendung eines Hashfunktion in ein Format – den Hashwert – überführt, welches sich durch diese Eigenschaften auszeichnet:

  • Aus dem Hashwert lässt sich der Originalwert – hier das Passwort – nur sehr schwer wieder ermitteln, im Idealfall nicht viel schneller als durch Durchprobieren aller möglichen Eingaben
  • Der Hashwert hat immer ein identisches Format z. B. mit der gleiche Länge, unabhängig davon wie der Eingabewert war

Zwei klassische Hashfunktionen sind MD5 und SHA-1. Das sind Beispiele für Hashwerte:

EingabewertMD5 HashSHA-1 Hash
abc900150983cd24fb0d6963f7d28e17f72a9993e364706816aba3e25717850c26c9cd0d89d
Der Hashwert hat immer ein identischen Format wie die gleiche Länge, unabhängig davon wie lang der Eingabewert war78eb98ec466e8b9dfd1ffcac23ccd690b5447826036922409c4f77f50ead0432fb5da892
Beispiele für Hashing

Bei einem Loginvorgang werden dann die von Nutzer*innen eingegebenen Passworte erneut durch die Hashfunktion geschickt und dann dieses Ergebnis mit dem beim Setzen des Passwortes erzeugten Hash verglichen. Bei so einer Vorgehensweise braucht es keine geheimen Schlüssel oder dergleichen, der Hash an sich ist ’sicher‘ genug. Wenn er denn richtig gewählt wird und um das schon vorweg zu nehmen: MD5 und SHA-1 sind heute nicht mehr sicher genug! Aber dazu kommen wir gleich, zuerst noch zwei Kochzutaten:

Den Regenbogen versalzen (und pfeffern)

Die Eigenschaft von Hashfunktionen, für die gleiche Eingabe immer zum gleichen Hashwert zu führen, hat bei der Verwendung zur Passwortsicherung zwei Nachteile

  1. Es ist für einen Angreifer, der eine große Menge von gehashten Passworten erhalten hat, direkt erkennbar welche Nutzer*innen identische Passworte nutzen. Hier kann man also mit einem erfolgreich entschlüsselten Passwort gleich mehrere Konten übernehmen
  2. Die Arbeit des Passwortbrechens kann schon vor dem Angriff geleistet werden, in dem man lange im Voraus für riesige Mengen von möglichen Passworten die Hashwerte berechnet und dann nur noch in einer Tabelle – für die sogar eine besonders effiziente Struktur mit dem Namen Rainbow Table entwickelt wurde – nachsehen, welcher Hashwert zu welchem Passwort gehört

Es gibt aber ein einfaches Mittel um Angreifern zumindest diese Abkürzungen zu vermiesen: Bevor das Passwort in die Hashfunktion gesteckt wird vermischt man es noch mit einem zufälligen Wert, der für jedes Passwort individuell erzeugt wird. Erst die Kombination aus diesem Zufallswert – für den sich der Name Salt eingebürgert hat – und dem Passwort wird in die Hashfunktion gesteckt. In der Passwortverwaltung speichert man dann das Salt zusammen mit dem Hashwert, da es für die Überprüfung eines beim nächsten Login eingegebenen Passworts benötigt wird.

Der Angreifer muss dann die Hashwerte für das jeweilige Salt berechnen und wenn dies groß genug ist lohnt sich kein Rainbow Table, da dieser die Kombinationen von allen Salts – wirklich allen, wenn es ein echter Zufallswert ist – und möglichen bzw. wahrscheinlichen Passworten enthalten müsste. Jedes Passwort muss also einzeln und mit entsprechendem Rechenaufwand ermittelt werden.

Eine weitere Ergänzung kann dann ein Pepper-Wert sein: Dieser funktioniert ähnlich wie das Salt, er ist also ein zufälliger Wert, der mit dem Passwort vermengt wird, er wird aber nicht zusammen mit dem Passworthash abgelegt, sondern zum Beispiel in der Konfiguration des Servers, der die Loginvorgänge abwickelt. Er ist also für alle Passworte identisch.

Wann bringt dies einen Schutz? Wenn ausschließlich die Datenbank mit den hashten (und gesalzenen) Passworten abhanden gekommen ist, aber nicht die Serverkonfiguration mit dem Pepper, dann kann ein Angreifer mit diesen Daten nichts mehr anfangen, da ihm ein entscheidendes Geheimnis fehlt um zu überprüfen, ob er ein Passwort richtig geraten hat.

Falls hingegen die Daten der kompletten IT Landschaft gestohlen wurden ist es nur eine Frage der Komplexität dieser Landschaft, ob es Angreifern gelingt zu verstehen wie das Ganze funktioniert und wo der Pfeffer wächst.

Gutes Hashen, schlechtes Hashen

Es gibt eine große Anzahl von Hashfunktionen und nicht alle sind gleich gut geeignet für die Erzeugung von Passworthashes. Tatsächlich sind die oben genannten Funktionen MD5 und SHA-1 nach heutigem Stand überhaupt nicht mehr geeignet, wie sich später in den Abschätzungen für die Entschlüsselungsdauern zeigen wird.

Warum sind sie nicht geeignet? Dieses Hashes wurden für andere Zwecke entwickelt und zwar zur Prüfung ob Dokumente bzw. Datenpakete unverändert sind. In dem ich ein PDF oder ein Softwarepaket durch so eine Hashfunktion schicke kann ich den erhaltenen Wert zur Prüfung mitgeben, ob das Dokument noch so ist, wie es ursprünglich einmal erzeugt oder verschickt wurde. Alle großen Softwarepakete – hoffe ich jedenfalls – bieten auf ihren Downloadseiten auch die Prüfsummen (Hashwerte) an – die der Hersteller selbst ermittelt hat. Wer es ganz genau nimmt erzeugt diese Prüfsumme nach dem Download auf seinem Rechner dann selbst und vergleicht. Nur wenn die Werte Zeichen für Zeichen übereinstimmen kann man sicher sein, dass die Datei noch so ist, wie sie vom Ersteller einmal produziert wurde.

Bei diesen Nutzungen von Hashfunktionen kommt es auf zwei Dinge an: Es muss sehr schwer sein für eine gegebene Prüfsumme ein anderes – gefälschtes – Dokument zu erzeugen, welches die gleiche Prüfsumme ergibt. Und zweitens: Performance. Diese klassischen Hashverfahren sollen möglich wenig Rechenzeit verbrauchen, damit sie auch bei hohen Durchsatzraten einsetzbar sind.

Performance ist genau das, was wir bei Passworthashes nicht wollen!

Die Möglichkeit eine Hashfunktion schnell auszuführen spielt beim Loginvorgang nur eine begrenzte Rolle, ob unsere Nutzer*innen bei diesem Schritt eine Sekunde warten müssen oder nicht werden sie kaum bemerken bzw. es bei diesem seltenen Vorgang akzeptieren. Für einen Angreifer, der Milliarden von Passworthashes erzeugen muss, macht es hingegen einen riesigen Unterschied, ob ein Hash sich in einer Microsekunde berechnen lässt, oder in einer Millisekunde.

Es gibt dabei die grundlegende Schwierigkeit, dass unsere eigenen Server, die die Logins verarbeiten und den Passworthash dabei erzeugen müssen, nicht so performant sein werden wie die spezialisierte Hardware, die Angreifer ggf. ins Feld führen können. Wir müssen also generell in Kauf nehmen, dass Angreifer in der Lage sein werden viel schneller Hashes zu erzeugen als wir selbst. Die Frage ist nur, wie viel schneller?

Die klassischen, performanten Hashfunktionen wie die SHA-2 Familie lassen sich eigentlich nur auf eine Weise für Passworthashes einsetzen: Durch Erhöhung der Rundenzahl. Damit ist gemeint, dass man den aus dem Passwort (und Salt und Pepper) berechneten Hash erneut in die Hashfunktion steckt. In dem Post zu Lastpass steckt dieser Aspekt in der Frage wie viele Runden im PBKDF2-Verfahren gemacht werden sollten. Hier geht es also ggf. um Millionen von Runden, bei denen der Hashwert immer wieder neu berechnet wird. Für ein produktives Loginsystem sind dabei vermutlich noch viel höhere Werte möglich, da man im Gegensatz zu einem Passwortmanager keine Rücksicht auf ggf. leistungsschwächere Smartphoneprozessoren nehmen muss.

Trotzdem bleibt hier das Grundproblem, dass eine Funktion verwendet wird, die letztlich performant sein soll. Aber es gibt heute Alternativen:

Unperformante Hashfunktionen: Bcyrpt, scrypt und Argon2

Das Design einer Hashfunktion, die eine ’schlechte‘ Performance zeigen soll, hat ihre eigene Komplexität und hier hat es immer neue Entwicklungen gegeben. Diese Funktionen sollen generell solche Eigenschaften haben:

  1. Sie müssen natürlich die gleichen Eigenschaften einer Hashfunktion haben, die zuvor genannt wurden
  2. Es soll auch mit spezialisierter Hardware nicht dramatisch viel einfacher sein diese Funktionen auszuführen als mit Standardhardware
  3. Im Algorithmus sind ‚Stellschrauben‘ vorhanden, die es erlauben den Rechenaufwand und bei neueren Funktionen auch den Speicherbedarf einzustellen. Je nach Verfahren in Abhängigkeit voneinander oder auch nicht
  4. Seitenkanalattacken sollen möglichst schwierig sein. Also Wege, bei denen sich z. B. über die Laufzeit des Algorithmus oder den Stromverbrauch der Hardware Informationen über das verarbeitete Passwort gewinnen lassen

Das sind die heute relevantesten Verfahren in der chronologischen Reihenfolge:

bcrypt

Diese Funktion wurde schon 1999 vorgestellt und verbessert die Passwortsicherheit im Vergleich zu den schnellen Hashes bereits deutlich. Sie verfügt über einen einstellbaren Kostenfaktor, den man an die Leistungsfähigkeit der eigenen Loginserver anpassen kann, um so einen Mittelweg zwischen der Wartezeite für die eigenen Nutzer*innen zu finden und dem Aufwand für Angreifer.

Bcrypt hat aus heutiger Sicht das Ziel nicht vollständig erreicht auch mit spezieller Hardware nicht deutlich schneller ausgeführt werden zu können: Gerade der eher geringe Speicherbedarf ermöglicht eine massive Parallelisierung der Hashwertberechnungen.

scrypt

Diese ca. 10 Jahre nach bcrypt vorgestellte Funktion ist bewusst mit einem ‚hohen‘, nicht reduzierbarem Speicherbedarf konzipiert worden. Dies verhindert den Einsatz von günstiger Hardware für massenhafte Berechnungen deutlich, während die eigenen Server damit normalerweise kein Problem haben.

Es kann sowohl der Rechnenzeit- wie auch der Speicherbedarf eingestellt werden, allerdings nicht unabhängig voneinander. Trotzdem gibt es Untersuchungen, bei denen scrypt in bestimmten Parametersetzungen schlechter – also effizienter ausführbar – abschneidet, als bcrypt. Auch gilt es aus kryptographischer Sicht immer noch als ‚junges‘ Verfahren und löst daher manchmal die Sorge aus, dass es vielleicht noch nicht erkannte Probleme hat.

Argon2

Dieses erstmals in 2014 vorgestellt Verfahren, welches dann noch Weiterentwicklungen erfahren hat, gewann in 2015 die sogn. Password Hashing Competition. Generell ist es damit das aktuellste der drei hier genannten Verfahren, mit den Vor- und Nachteilen, die das mit sich bringt:

Argon2 ist am flexibelsten bei den Einstellungen für Rechenzeit und Speicherbedarf und in Kenntnis der durch spezialisierte Hardware verfügbaren Rechenleistung entwickelt worden. Auf der anderen Seite in kryptographischer Sicht noch jünger und damit potentiell angreifbarer.

In OWASP Password Storage Cheatsheet werden konkrete Empfehlungen für die Parametrisierung dieser Funktionen gegeben.

Wie schnell lassen sich Passworte heute cracken

Es gibt Videos wie dieses, in dem man sich anschauen kann wie man hashcat, ein beliebtes ‚password recovery‘ Tool, einfach an den Start bringt. Aber die Rechenleistung des eigenen Rechners vermittelt einem nur ein ungenügendes Bild davon, was Angreifern potentiell zur Verfügung steht. Interessanter ist da der jährliche Password Table von Hive Systems (nicht zu verwechseln mit der Hive Ransomware Gruppe). Die folgenden Graphiken und Zahlen stammen aus dem Bericht 2022.

Hive Systems hat jeweils ermittelt wie viele Hashes in unterschiedlichen Hashverfahren mit damals verfügbaren Graphikkarten pro Sekunde berechnet werden können und auf dieser Basis geschätzt, wie lange es dauern würde die Hashes für alle denkbaren Passworte einer bestimmten Länge und Zusammensetzung zu berechnen. Und sie haben auch gleich verglichen welche Rechenleistung in der Cloud verfügbar wäre! Es gibt z. B. von Amazon kleine GPU Cluster, die man für überschaubare Kosten mieten kann.

Diese Graphik zeigt die Crackingdauern für Passworte im MD5 Hash mit dem größten damals in der Amazon Cloud verfügbaren Cluster mit 8 GPUs. Während die getestete Graphikkarte auf ca. 70 Milliarden MD5 Hashes pro Sekunde kommt, ist der Cluster in der Cloud in der Lage mehr als 500 Milliarden Hashes zu berechnen. Damit kommt Hive auf diese Tabelle:

Dauer zum Cracken von MD5 gehashten Passworten in der Amazon Cloud. Quelle: Hive Systems

Ein 8 Zeichen langes Passwort – wohlgemerkt jedes 8 Zeichen lange Passwort! – kann also in der Cloud in weniger als einer Stunde errechnet werden. Wenn man bedenkt, dass die meisten von uns keine wirklich zufälligen Passworte verwenden mit Groß- und Kleinschreibung und Zahlen und weiteren Zeichen, wird es meist noch viel schneller gehen. Daher sind auch Passworte mit mindestens 12 Zeichen, wie sie das BSI aktuell empfiehlt, nicht lange sicher, wenn sie als MD5 Hash gespeichert werden.

Der Artikel von Hive vergleicht dabei die in 2022 aktuellen Zahlen mit der vorherigen Auswertung in 2020. Und kann deutliche Rechenleistungssteigerungen zeigen. Ein Passwort, dass heute noch 5 Jahre zur Ermittlung brauchen würde, ist daher in einem Jahr vielleicht schon in der Hälfte der Zeit knackbar.

Und letztlich sind diese Zahlen bzw. die hier eingesetzte Hardware keine Obergrenze: Es gibt spezielle Hardware mit deutlich mehr Leistung und Software wie die von Elcomsoft, die in der Lage ist die Arbeit auf zehntausende von Rechnern zu verteilen.

In den weiteren Auswertungen zeigt sich dann der Vorteil von bcrypt. Diese Graphik basiert auf dem gleichen Hardwareszenario, nur dieses Mal mit bcrypt Hashes:

Dauer zum Cracken von bcrypt gehashten Passworten in der Amazon Cloud. Quelle: Hive Systems

Mit bcrypt ist die Anzahl der Hashes pro Sekunde im Amazon GPU Cluster auf eine Million zurückgefallen. Es geht aus dem Artikel leider nicht hervor, mit welchem Kostenfaktor die Hashes erzeugt wurden. Da die Erhöhung des Kostenfaktors um 1 die Rechenzeit für einen Hash in etwa verdoppelt ist es ein deutlicher Unterschied, ob der Faktor 1 oder 15 war.

In dieser Konstellation müssen Angreiferdeutlich mehr Hardware einsetzen, oder gut darin sein den Suchraum einzugrenzen, um in vernünftiger Zeit zu einem Erfolg zu kommen. Auch wenn bcrypt heute nicht mehr als das modernste Verfahren gilt, ist es weiterhin in der Lage Angriffe auf Passworthashes deutlich zu verlangsamen.

Und trotzdem: Es kommt weiterhin auf die Passwortqualität an

Man sieht an den Auswertungen deutlich, welche Verantwortung als IT Betrieb man bei der sicheren Ablage von Logindaten hat. Aber man sieht auch: Wenn die verwendeten Passworte schlecht sind – zu kurz, zu einfach, in vielen anderen Diensten verwendet – nutzt auch das beste Hashverfahren nichts.

Eine Absicherung der Infrastruktur muss also auf allen Ebenen zugleich erfolgen, damit sie auch in dem hier beschriebenen Szenario wirksam werden kann. Und eine 2-Faktor-Authentifizierung kann helfen den unmittelbaren Schaden eines Verlusts der Passworte zu begrenzen. Sofern die dafür notwendigen Geheimnisse nicht gleich mit gestohlen wurden.

Passwortmanager: Von Lastpass zu Bitwarden

TL;DR: In diesem Text geht es um meinen Wechsel des Passwortmanagers, nachdem sich Lastpass als zu unzuverlässig erwiesen hat. Vorangestellt werden ein paar Überlegungen dazu, warum man eigentlich einen Passwortmanager braucht und wie man ihn sicher nutzt. Abschließend geht es um die Frage, wie mit dem Datenverlust bei Lastpass umzugehen ist: Muss ich jetzt alle meine Passworte ändern?

Eine der wesentlichen Regeln der Passwortsicherheit ist die Verwendung von individuellen Logins für jeden Dienst und Zweck. Angesichts immer wiederkehrender Verluste von Logindaten bei erfolgreichen Angriffen auf Webdienste kann man nur so den Schaden auf den jeweiligen Dienst begrenzt halten. Es nutzt nichts ein einzelnes, super sicheres Passwort zu haben, welches man immer verwendet. Denn schon ein erfolgreicher Einbruch bei einem einzigen der Dienste, bei denen man das Passwort verwendet, wird dazu führen, dass die Angreifer danach auch die anderen Dienste mit den so gewonnenen Logindaten erfolgreich angreifen. Diese Art des Angriffs ist so häufig, dass sie einen eigenen Namen bekommen hat: Credential stuffing

Auch 2-Faktor-Authentifizierungen ändern daran erst einmal nicht grundsätzlich etwas, und bis wir überall Passkeys einsetzen und keine Passworte mehr brauchen wird es noch etwas dauern.

Ein Passwortmanager ist unverzichtbar

Zwar kann man so eine Vorgehensweise auch ohne digitale Unterstützung umsetzen, entweder mit einem Notizbuch für die Passworte, oder durch Schemata, bei denen man ein komplexes Grundpasswort nach eigenen Regeln jeweils individualisiert, aber die Verwendung eines Passwortmanagers macht diese Vorgehensweise erst in einer Weise handhabbar, die den digitalen Lebenswandel und Arbeitsalltag nicht so sehr erschwert, dass es nicht mehr praktikabel ist.

Auch bieten die gängigen Passwortmanager einige Vorteile im Vergleich zu manuellen Lösungen:

  • Generierung von Passworten: Es gibt üblicherweise Funktionen, um sich lange und zufällige Passworte mit vielen Zeichenvariationen mit einem Klick zu erzeugen. Zufällig generierte Passworte bieten den höchsten Schutz gegen Passwortrateversuche, selbst wenn Angreifer dabei sehr viel Zeit und sehr viel Rechenleistung zur Verfügung steht
  • Umgang mit sehr langen Passworten: Der Passwortmanager nimmt einem eventuell noch vorhandene Hemmungen sehr lange Passworte zu verwenden. Also Passworte mit Längen jenseits von 30 Zeichen, die man bei einer manuellen Handhabung wohl eher scheut
  • Schutz vor homographischen Angriffen: Wenn der Passwortmanager verwendet wird zum automatischen Ausfüllen von Logins in Webseiten kann man auf diese Art von Angriffen – bei denen sehr ähnliche oder gar völlig identisch aussehende Webadressen verwendet werden – nicht hereinfallen. Bzw. muss dann als Nutzer*in selbst aktiv die Logindaten eingeben und könnte sich bei der Gelegenheit wundern, warum der Passwortmanager das nicht tut

Aber es gibt natürlich auch Nachteile, gerade wenn es um die ganz besonders bequemen Passwortmanager mit einer Synchronisierung über die Cloud geht. Da heute nahezu jede*r mindestens 2 Geräte haben wird, auf denen man sich irgendwo einloggen will, muss man in der Lage sein die Inhalte des Passwortmanagers – nennen wir ihn den ‚Tresor‘ – sicher zwischen diesen Geräte zu transportieren.

Das kann man selbst machen, aber das ist mit einem gewissen Aufwand verbunden und braucht eine hohe Sorgfalt, damit keine Fehler beim Umgang mit diesen kritischen Daten passieren. Es gibt aber inzwischen eine Reihe von Anbietern, die die Passwortmanagerinhalte über die Cloud synchronisieren und dabei vor allem dies versprechen:

Zero Knowledge Architekturen

Mit dem ‚Null Wissen‘ ist dabei gemeint, dass der Anbieter des Passwortmanagers zwar die Inhalte in der Cloud speichert und so zwischen den Geräten synchronisieren kann, aber nicht in der Lage ist die Inhalte selbst zu sehen bzw. zu entschlüsseln. Das ist durch eine entsprechende Programmierung der Passwortmanagersoftware möglich, da die Entschlüsselung letztlich nur auf den Geräten der Nutzer*innen – also lokal und nicht in der Cloud – stattfinden muss.

Auf diese Weise lassen sich zwei Probleme lösen:

  1. Wie viel Vertrauen brauche ich in meinen Passwortmanageranbieter? Je weniger der Anbieter von meinen Daten sehen kann, desto weniger Vertrauen muss ich zu ihm haben. Ganz ohne Vertrauen geht es natürlich nicht: Da meist die Passwortmanagersoftware vom gleichen Anbieter kommt wie die Cloudsoftware, die die Daten synchronisiert, muss ich darauf vertrauen, dass die Software nicht doch mein Passwort direkt in die Cloud schickt. Oder die Inhalte meines Passworttresors im Klartext
  2. Was passiert, wenn meine ganzer Passwortschatz abhanden kommt? Da der Passwortmanager, wenn er richtig genutzt wird, der Schlüssel zum gesamten digitalen Leben ist, kann er in den falschen Händen maximalen Schaden anrichten. Dabei kann er sowohl vom eigenen Gerät entwendet werden, wie auch aus der Infrastruktur des Anbieters. Erfolgreiche Angriffe auf Clouddienste sind keine Seltenheit, dabei trifft es alle Ebenen: Vom grundlegenden Cloudserviceanbieter (Beispiel Rackspace) über die Softwareentwicklungsinfrastruktur (Beispiel Circle CI) bis hin zum IT Sicherheitsdienstleister selbst (Beispiel Okta). Im Idealfall könnte ich meinen verschlüsselten Passworttresor auch frei ins Internet stellen und niemand könnte mit einem vernünftigen Ressourceneinsatz meine Passworte daraus extrahieren, so dass ich mir selbst im Fall eines erfolgreichen Angriffs auf meinen Dienstleister keine (großen) Sorgen machen muss

‚Das letzte Passwort, das Sie jemals brauchen werden‘

Der Schutz des Passworttresors und seiner wichtigen Inhalte hängt nun von einer einzige Sache ab: Dem Passwort, welches man für den Passwortmanager verwendet. Dieses Passwort wird verwendet um den Tresor zu verschlüsseln und dann auch wieder zu ‚öffnen‘. Wer es besitzt hat damit die komplette Kontrolle über alle im Tresor gespeicherten Logindaten.

Im Idealfall ist es dann das ‚letzte‘ Passwort, welches man in dem Sinne braucht, dass man es sich merken und manuell eintragen muss. Produkte wie Lastpass oder 1Password verdanken dieser Idee ihre Namen. Oft wird dieses Passwort als das Masterpasswort bezeichnet

Da man dieses Passwort häufig benötigt um den Tresor zu entsperren ist es praktisch es sich merken zu können und so kann man ausgerechnet beim wichtigsten Passwort von allen kaum auf ein langes, zufällig generiertes Passwort setzen. Sondern muss sich für eine Vorgehensweise entscheiden um ein Passwort zu finden, welches auch in dem Fall, dass der damit verschlüsselte Tresor Angreifern in die Hände fällt, für eine ‚vernünftige‘ Zeit vermutlich nicht knackbar ist.

XKCD 936: Password strength

Die Ratschläge wechseln dabei mit der Zeit, die Vorgehensweise oben im Comic scheint heute immer noch aktuell, nur sind 4 Worte wohl nicht mehr genug. Hier ein paar Links dazu:

  • Tipps vom BSI – Wobei die Aussage, dass ein ‚gutes Passwort‘ mehr als 8 Zeichen haben sollte, für ein Masterpasswort viel zu schwach ist. Hier sollte man schon etwas jenseits von 15 Zeichen haben, besser noch mehr
  • Bitwardens Passwortstärkeprüfung: Diese Seite gibt einem ein Feedback dazu, wie sicher ein Passwort vermutlich ist. Hier kann man ein Gefühl dafür bekommen, wie Länge und verwendete Zeichenarten die Komplexität beeinflussen, und die steht wiederum im direkten Verhältnis zum Aufwand, den potentielle Angreifer zum Erraten betreiben müssen
  • Password Haystack von GRC: Diese etwas nerdige Seite von Steve Gibson (vom Security Now Podcast) kann einem ebenfalls ein Gefühl dafür geben, wie komplex ein Passwort ist und wie sich die Länge und weitere Zeichenklassen (Groß- und Kleinschreibung, Zahlen, …) auf die Anzahl der Passwortkombinationen auswirken, die ein Angreifer durchtesten müsste. Das ist kein völlig korrektes Maß für die sogenannte Entropie eines Passworts und die Zeiten, die dort prognostiziert werden um ein Passwort zu brechen, sind nicht mehr realistisch angesichts heute verfügbarer Hardware. Trotzdem vermittelt es einem ein Bild davon, wie sich Komplexität erzeugen lässt. So ist ein Passwort, in dem man irgendwo zehn ‚.‘ oder ähnliches eingefügt hat und welches dadurch auf eine enorme Länge kommt durchaus für Angreifer, die davon nichts ahnen, sehr schwer zu erraten
  • Have i been pwnd: Hier kann man prüfen, ob ein Passwort schon einmal in gehackten Konten vorkam. So ein Passwort sollte man in keinem Fall mehr verwenden

Generelle Hinweise:

  • Das Masterpasswort sollte keins sein, welches man vorher schon irgendwo verwendet hat. Und man sollte es dann auch für keinen anderen Zweck verwenden
  • Es gibt keinen Grund das Passwort regelmäßig zu ändern, es sei denn man möchte es noch länger / komplexer machen
  • Das Masterpasswort sollte man sich ggf. aufschreiben und an einem sicheren Ort verwahren. Gerade ein kompliziertes Passwort vergisst man nach einem langen Urlaub auch schon mal
  • Man sollte das Masterpasswort nur auf Geräten eintragen, die vertrauenswürdig sind. Vertrauenswürdig ist zum Beispiel sicher nicht ein Internetcafé am Urlaubsort, aber ggf. auch keine Geräte von Bekannten oder Freunden. Es ist für Besitzer*innen fremder Geräte einfach zu leicht eine Tastatureingabe mitzuschneiden und so an das Passwort zu kommen

Das Versagen von Lastpass

Ich habe mich vor Jahren für Lastpass als meinen cloud-basierten Passwortmanager entschieden und eine der kostenpflichtigen Optionen gewählt. Auf dieses Produkt bin ich denke ich durch den Security Now Podcast aufmerksam geworden, der ursprüngliche Entwickler von Lastpass hat sein Produkt damals für Steve Gibson geöffnet und dieser hat einen Review des Konzepts gemacht, welches zu dieser Zeit State of the art war. In den folgenden Jahren wurde Lastpass aufgekauft und der ursprüngliche Entwickler hat das Unternehmen schon lange verlassen. Aber aus Nutzersicht war und ist es ein Produkt, welches seine Aufgabe im Webbrowser und auf Android und iOS problemlos erledigt.

Auf Grund der Zero Knowledge Architektur war dann auch die Meldung von Lastpass Anfang Dezember 2022 (inzwischen aktualisiert) über einen Sicherheitsvorfall, bei dem die verschlüsselten Passworttresore gestohlen wurden, zunächst ärgerlich, aber noch nicht sehr besorgniserregend:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data. 

Quelle Lastpass Blog

Natürlich ist der Verlust der Informationen dazu, welche Webseiten ich nutze, schon ein durchaus heftiges Datenschutzproblem und eine ideale Grundlage für Phishingangriffe. Trotzdem war der Stand zunächst der, dass durch die Art und Weise, wie aus dem Masterpasswort die Verschlüsselung generiert wird, die wirklich wichtigen Daten geschützt sind. Der Blogeintrag bestärkt diesen Eindruck noch:

To further increase the security of your master password, LastPass utilizes a stronger-than-typical implementation of 100,100 iterations of the Password-Based Key Derivation Function (PBKDF2), a password-strengthening algorithm that makes it difficult to guess your master password. You can check the current number of PBKDF2 iterations for your LastPass account here

Quelle Lastpass Blog

Nun kommen aber die Erkenntnisse ins Spiel, die im Verlauf dieser Security Now Episoden stückweise ans Tageslicht kamen:

Das sind für mich insbesondere diese Punkte:

  1. PBKDF2 Iterationen: 5000! Der Schutz meiner von Lastpass gestohlenen Daten hängt nur daran, dass Angreifer mein Masterpasswort nicht knacken. Mein Passwort ist deutlich länger als die von Lastpass zu diesem Zeitpunkt empfohlenen 12 Zeichen. Aber Lastpass selbst kann die Sicherheit sehr einfach durch die Anzahl der Iterationen erhöhen, die beim PBKDF2 Verfahren verwendet werden. Und hier ist es eine schlichte Lüge, dass hier mehr als 100.000 Iterationen verwendet werden. Bei mir waren nur 5.000 eingestellt, da ich ein langjähriger Nutzer bin und offenbar noch die Einstellung habe, die bei meiner ersten Nutzung von Lastpass aktuell war. In der 905er Episode behandelt Steve Fälle, bei denen es gar nur 1 Iteration war! Wieso hat Lastpass uns bisher treue Altnutzer nicht automatisch umgestellt? Als ich das manuell gemacht habe musste ich mich einmal neu einloggen und ein paar Sekunden warten, dann war das erledigt. Das hätte Lastpass in den letzten Jahren einfach mal automatisch tun können
  2. ECB verschlüsselte Passworte: In alten Versionen von Lastpass wurden Passworte nach dem ECB Verfahren verschlüsselt. Auch wenn das eine sichere Verschüsselung ist hat sie den Nachteil, dass die gleiche Eingabe immer das gleiche Ergebnis erzeugt. Es ist also in den verschlüsselten Daten einfach erkennbar, wenn jemand ein Passwort mehrfach verwendet hat. Später hat Lastpass auf das CBC Verfahren umgestellt, welches dieses Problem nicht hat. Es aber auch hier versäumt die Altdaten komplett umzustellen. In dem Lastpass Extrakt, den man sich nach dem in Folge 904 vorgestellten Verfahren herausziehen kann, finde ich zahlreiche ECB-kodierte Passworte
  3. Kein Zwang zu guten Masterpassworten: Das Problem betrifft mich nicht, aber offenbar hat Lastpass nie seine eigene Vorgabe durchgesetzt mindestens 12 Zeichen lange Passworte zu verwenden. Sie haben ihre Nutzer*innen damit in unverantwortlicher Weise sich selbst überlassen
  4. Herunterspielen der Menge an unverschlüsselten Daten: Es scheint, also enthalte der gestohlene Datensatz eine Menge an unverschlüsselten Informationen, die Lastpass für den Betrieb seiner Services nicht benötigt. Diese Daten sind nun direkt für die Angreifer auswertbar und helfen ihnen mindestens bei der Priorisierung welche Passworte sie ggf. zuerst angreifen sollen
  5. Mangelhafte Kommunikation: Insgesamt macht es den Eindruck, dass es Lastpass eher darum geht den Vorfall herunterzuspielen und eventuelle Datenverluste den Kunden in die Schuhe zu schieben. Auch wenn sie es in der Hand gehabt hätten hier viel für die Sicherheit zu tun

Letztlich hat mich die Menge der Probleme und der unprofessionelle Umgang damit dazu veranlasst ähnlich wie Steve Gibson nun Abschied von Lastpass zu nehmen.

Bitwarden als neue Lösung

Trotz der Erfahrung, dass meine Passwortmanagerdaten einmal in der Cloud abhanden gekommen sind, bleibe ich beim Grundprinzip eines cloud-basierten Passwortmanagers. Alles andere ist einfach zu umständlich. Zum Glück gibt es einige Alternativen, die in Episode 904 auch kurz diskutiert werden. Von den da genannten Kandidaten Dashlane, 1Passwort und Bitwarden habe ich mich für letzteren entschieden.

Ein Grund ist, dass es sich hier um eine Open Source Lösung handelt, die aber zugleich ein Serviceangebot hat, welches man kaufen kann. So hat man zwar die Option eines selbstverantwortlichen Betriebs, aber wenn man das nicht kann oder möchte nutzt man den Service in der Cloud.

Kann man sicher sein, dass Bitwarden keine ähnlichen Probleme hat oder bekommt wie Lastpass? Letztlich nicht wirklich, allein das es sich hier um Open Source handelt ist keine Garantie dafür, dass komplexe Algorithmen korrekt implementiert sind, keine sonstigen Fehler in der Software sind und das der Betrieb der Cloudplattform kompetent erfolgt. Aber zumindest könnte man in einem vergleichbaren Fall einfach nachsehen wie die Software funktioniert, und müsste nicht herumraten, wie es bei Lastpass nun der Fall ist.

Die Migration an sich hat bei mir gut funktioniert, man nutzt entsprechend der Anleitung den Export von Lastpass und holt diese Daten dann nach Bitwarden.

Nach dem ersten Eindruck ist die Oberfläche etwas weniger gefällig, als die von Lastpass, aber nicht in einem für mich abschreckenden Maß. Etwas Feintuning kann man dann noch machen und die Anzahl der Iterationen für die Schlüsselableitung (KDF) erhöhen. Sie liegt per Voreinstellung bei 100.000, also auf dem Level, welches Lasspass bei neuen Nutzer*innen setzt. Aber man kann sie hochsetzen, und heutige Smartphones verkraften auch deutlich höhere Werte:

Bitwarden: KDF-Iterationen bearbeiten

Zur Erinnerung: Die Anzahl der Iterationen erhöht direkt den Aufwand, den Angreifer in einem Szenario wie dem Datendiebstahl bei Lastpass erbringen müssen und hier hat man neben der Komplexität des Masterpassworts noch eine weitere Stellschraube. Der Wert von mehr als einer Million scheint auf meinem Geräten keine Schwierigkeiten zu bereiten, auch auf dem alten iPad Mini als wohl leistungsschwächsten Gerät dauert das Öffnen des Tresors nur eine Sekunde.

Ich habe meinen Lastpass Account noch nicht gekündigt und werde noch ein paar Wochen beobachten, wie sich Bitwarden schlägt, aber Passwortänderungen werden nun nur noch über den neuen Passwortmanager gemacht.

Umgang mit den bisher bei Lastpass gespeicherten Passworten

Ich muss davon ausgehen, dass mein kompletter Passworttresor heute in den Händen von Kriminellen ist. Zusammen mit den Tresoren von Millionen von anderen Lastpass Nutzer*innen. Trotz der oben benannten kritischen Punkte bei der Verschlüsselung gehe ich nicht davon aus, dass meine Daten schon geknackt wurden. Aus diesen Gründen:

  1. Ich stelle vermutlich kein speziell interessantes Ziel dar, welches besondere Aufmerksamkeit und umfangreiche Investitionen an Rechenzeit rechtfertigt
  2. Bei einer opportunistischen Vorgehensweise der Angreifer – leichte Ziele vor schweren Zielen angehen – sind die Nutzer*innen, die eine noch kleinere Anzahl von PKDF-Iterationen hatten (vielleicht nur eine einzige!) wohl eher ‚dran‘ als ich. Allerdings gibt es keine vollständige Information darüber, in welchem Maße die schwachen Iterationszahlen vorhanden sind, wann ich nach dieser Logik als ‚dran‘ wäre
  3. Mein Masterpasswort war nicht schwach und erfüllte die oben von mir selbst aufgestellten Massgaben
  4. Ich habe bisher keine ungewöhnlichen Aktivitäten bei meinen diversen Konten bemerkt

Trotzdem…es wäre absurd zu glauben, dass nicht irgendwann die Daten meines Tresors zugänglich werden, sei es in ein paar Wochen, Monaten oder Jahren, die Logindaten müssen also geändert werden. Allerdings habe ich hunderte von Logins in meinem Tresor, es ist daher eine Priorisierung notwendig. Das ist meine Reihenfolge:

Priorität 1: Zentrale Mail- und Betriebssystemkonten

An wichtigsten sind die Google Konten. Nicht nur enthalten sie selbst jede Menge wichtige Daten, sie sind auch bei vielen Services als Adressen eingetragen für Passwortresets. Wer diese Konten kapert, der kann sich dann auch ohne gestohlenen Passworttresor den Zugriff auf viele Konten sichern.

In gewisser Weise gilt das auch für die Konten bei Microsoft und Apple, die den Zugriff auf die Betriebssysteme dieser Anbieter ermöglichen und ebenfalls zentrale Angriffspunkte sind.

Priorität 2: Finanzen und große Einkaufsplattformen

Danach kommen direkt die Konten bei Banken und Onlinefinanzdienstleistern. Ein Zugriff darauf kann unmittelbaren finanziellen Schaden erzeugen, auch wenn hier heute immer ein weiterer Faktor wie eine dynamische TAN benötigt wird. Auch Plattformen wie Amazon gehören für mich dazu, da hier ebenfalls das Potential zu wesentlichen finanziellen Schäden besteht.

Priorität 3: Eigene Webseiten und Social Media

Eine Übernahme meiner digitalen Identität im Netz würde über Jahre aufgebaute Repräsentationen zerstören und hat das Potential auch andere zu schädigen, falls Angreifer versuchen sollten sich auf diese Weise Vertrauen zu erschleichen.

Priorität 4: Der große Rest

Danach bleiben immer noch eine Menge von Konten, für die eine Lösung gefunden werden muss. Bei vielen wird sich eher die Frage stellen ob man sie nicht komplett aufgibt, statt das Passwort zu ändern. Denn jeder Service, der Daten von einem verwaltet, ist letztlich ein potentielles Angriffsziel, über das Daten abfließen können.

Leseempfehlung: ‚Countdown to Zeroday‘ von Kim Zetter

Es ist schon etwas Zeit vergangen seit der letzten Leseempfehlung hier, aber meine gerade beendete Urlaubslektüre hat sich für mich sehr gelohnt. Es ist Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon (ISBN 0-77043-617-X) von Kim Zetter. Zwar ist das Buch schon aus dem Jahr 2014 und angesichts der schnellen Entwicklungen im IT Bereich daher nicht mehr ganz up to date. 

Aber es ist trotzdem lesenswert, denn die Stuxnet Schadsoftware ist bis heute (2022) ein einzigartiges Beispiel für eine digitale Waffe, die auch zum Einsatz kam bzw. deren Einsatz entdeckt wurde.

Die Autorin nimmt auf den 500 Seiten alle Aspekte in Augenschein, vielleicht manchmal schon zu umfassend, darunter diese:

Die Sicht der Sicherheitsforscher

Die Personen, die mit der Analyse der ungewöhnlich komplexen Schadsoftware befasst waren, insbesondere bei Symantec und dem deutschen Unternehmen Langner, erfahren eine umfassende Porträtierung. Und die für sie neuen Fragestellungen:

  • Ist es insbesondere für ein US Unternehmen wie Symantec eigentlich opportun eine von der US Regierung beauftragte Operation zu (zer)stören?
  • Wie ist es mit den möglichen persönlichen Risiken, denen man sich dabei im Gegensatz zur Analyse irgendeiner beliebigen Virussoftware aussetzt?
  • Ist man in irgendeiner Weise mitschuldig, wenn der digitale Angriff aufgedeckt wird und die Geheimdienste ihre Strategie dann offenbar auf Mordanschläge umstellen?

Die Funktion der Waffe

Es gibt ein umfangreiche Beschreibung der ‘Nutzlast’ der Schadsoftware, sozusagen des digitalen Sprengkopfs. Dieser bestand aus auf die spezielle Steuerungssoftware von Siemens, die attackiert wurde, zugeschnittenen Elementen, die so ganz anders funktionieren als der Code, den Sicherheitsforscher im Umfeld gängiger Betriebssysteme wie Windows oder Linux gewohnt sind, was die Analyse sehr erschwerte.   

Das Ziel der Waffe

Die Schadsoftware richtete sich – das kann heute wohl als sicher gelten – gegen das iranische Nuklearprogramm bzw. den Teil, in dem die Urananreicherung mit tausenden von Zentrifugen erfolgt. 

Und war damit ein Teil eines über Jahrzehnte – bis heute – andauernden Konflikts zwischen dem Iran, der USA, Israel, aber auch weiteren Staaten. Hier rollt das Buch die verschiedenen Parteien auf, wobei es naturgemäß schwierig ist die eigentlich Verantwortlichen zum Reden zu bringen oder auch nur zu benennen.

Ein wesentlicher Teil des Buches befasst sich auch mit der Frage ob so eine Schadsoftware ein kriegerischer Akt ist. Das ist keine unwichtige Frage, denn die Alternativen aus Sicht der USA und Israels wären eindeutige kriegerische Akte wie Luftangriffe.

Und würden die USA – wenn sie in ähnlicher Weise angegriffen würden – so eine Attacke genauso einschätzen, wie sie es damals als Angreifer getan haben?

Was braucht es sonst noch um so eine Waffe zu entwickeln

Was in der Berichterstattung über Stuxnet oft zu kurz kam ist die Frage wie es überhaupt technisch möglich war eine Software zu entwickeln, die in offenbar sehr subtiler Weise komplexe Hardware – die Zentrifugen der Urananreicherung – beschädigen und in ihrer Leistung einschränken kann.

Hier wird klar, dass solche Angriffe kaum ohne einen umfangreichen Maschinenpark und langen Vorlauf realisierbar sind.   

War Stuxnet erfolgreich

Die Antwort auf diese Frage ist überraschend kompliziert und vielfältig. Da niemand der Personen, die es am besten wissen könnten, ein Interesse hat die tatsächlichen Fakten offenzulegen gibt es nur umfangreiche Indizien, die die befragten Expert*innen aber auch wieder ganz unterschiedlich auslegen.

Interessant ist auch die Frage ob die Autor*innen der Schadsoftware hätten aggressiver vorgehen sollen. Es wäre vermutlich ‘leicht’ gewesen tausende von Zentrifugen zu zerstören, aber damit hätte man die Iraner auch direkt darauf gestoßen, dass irgendetwas grundsätzlich nicht stimmt. 

Der Umgang staatlicher Stellen mit Zero Day Lücken

Stuxnet nutzte eine – zumindest für damalige Verhältnisse – ungewöhnliche große Anzahl von Zero Day Lücken – also vor ihrer Entdeckung in Schadsoftware zumindest bei den jeweiligen Softwareanbietern wie Microsoft unbekannte Lücken – aus. Insgesamt waren es 4.

Hier wird der Konflikt diskutiert den staatliche Stellen haben, die auf der einen Seite die Sicherheit ihrer Bürger und der Infrastruktur sichern sollen, aber auf der anderen Seite solche Lücken für Geheimoperationen in Reserve halten möchten. Teilweise sogar die gleichen staatlichen Stellen.

Seit damals hat sich einiges getan was Bug Bounty Programme angeht, aber der Markt für solche Lücken in wichtigen Systemen ist eigentlich nur noch größer geworden und die Preise viel höher, die Unternehmen wie Apple, Google oder Microsoft bieten müssen, damit sie halbwegs sicher sein können das Fehler in ihren global eingesetzten Produkten bei ihnen gemeldet werden, und nicht bei einer der vielen Plattformen, die sie an den Meistbietenden verkaufen.

Die Büchse der Pandora – geöffnet, aber nicht genutzt?

Das Ende des Buches wird die Metapher der Büchse der Pandora verwendet: Haben die Personen, die Stuxnet auf den Iran und letztlich auf die Welt losgelassen haben damit einen Präzedenzfall geschaffen, der sich nicht mehr ungeschehen macht? Ähnlich den Detonationen der ersten Atombomben?

Dieser Argumentation kann man sich kaum verschließen, aber es ist heute – 8 Jahre nach dem Erscheinen des Buches – festzustellen, dass vergleichbare Ereignisse seitdem nicht wieder bekannt geworden sind. Auch im aktuellen Angriffskrieg Russlands gegen die Ukraine scheinen solche Mittel eher nachrangig – wenn überhaupt – zum Einsatz zu kommen.

Tatsächlich kommen heute große Infrastrukturausfälle durch digitale Angriffe vor, siehe z. B. den Angriff auf die Colonial Pipeline, der zu massiven Störungen der Energieversorgung in den USA führte. Aber diese Angriffe werden von Kriminellen ausgeführt, denen es um Geld geht, nicht von Staaten oder Geheimdiensten. Und die viel simplere Sicherheitslücken ausnutzen und auf diese Weise teilweise überraschend tief in hochwichtige Systeme eindringen.

Das liegt vielleicht daran, dass sich eine digitale Waffe oft nur einmal einsetzen lässt, danach ist ihr Wirkmechanismus bekannt und kann abgestellt werden. Und der Angegriffene bekommt mit der Schadsoftware auch eine Blaupause dafür, wie diese Waffe funktioniert, und kann sie nachbauen. Das macht den Einsatz riskant und trotz der ‘Vorteile’ – hauptsächlich wie schwer es ggf. ist nachzuweisen, wer für einen Angriff verantwortlich war – nur für wenige Szenarien attraktiv. 

Empfehlung

Wer sich für IT Sicherheit interessiert, aber dabei nicht rein für die Bits und Bytes, der findet hier interessanten Lesestoff in einer Tiefe, die sich mir damals, als das Thema ganz aktuell war, so nicht erschlossen hat.

Und 8 Jahre später die Prognosen zur Ausbreitung und zum Einsatz von digitalen Waffen mit der Realität vergleichen zu können ist ebenfalls spannend.

Komplexität 🤜🤛 IT Sicherheit: 2 interessante Beispiele

Beschäftigt man sich regelmäßig mit IT Sicherheitsthemen – etwa in dem man jede Woche den Security Now Podcast hört – gibt es immer wieder Momente in denen man völlig davon überzeugt ist, dass das Internet nur von Kaugummi und Klebeband zusammengehalten wird. Aber oft sind es auch Themen, die tief in die unheimlich komplex gewordenen Infrastukturen und Technologien führen, mit denen wir täglich hantieren. Das sind zwei Beispiele aus den letzten Wochen, die ich besonders spannend fand:

Trojan Source – UTF-8 und Tricks mit dem bidi Encoding 🔀

Aus Security Now 843: Zwei britische Forscher haben ein spannendes Paper mit dem Titel ‚Trojan Source: Invisible Vulnerabilities‚ veröffentlicht, welches im Endeffekt diese Kernaussage hat:

Bei der Prüfung eines Programmcodes kann man nicht mehr davon ausgehen, dass der Code, den man vor sich auf dem Bildschirm sieht, der gleiche Code ist, der später vom Compiler ‚gesehen‘ und in ein Programm übersetzt wird

So wie das Trojanische Pferd auch nicht das war, was es zu sein schien…Wenn man darüber einen Moment nachdenkt zieht es einem nach und nach das Fundament unter dem Füßen weg, auf dem die Überprüfung von Softwarequalität und -sicherheit von jeher stand:

Ein Mensch schaut sich in einem Editor den Quellcode, den ein anderer Mensch – oder inzwischen auch eine Maschine – geschrieben hat, versucht ihn zu verstehen und vergleicht ihn mit der Funktion, die der Code laut Pflichtenheft oder Eigenbeschreibung oder Stack Overflow Kommentar haben soll.

Im Paper werden nun unterschiedliche Verfahren beschrieben, wie man in Quellcode, der als Unicode gespeichert ist, subtile Täuschungen einschmuggeln kann. Und dabei kommt die Komplexität moderner Zeichensatzcodierungen, die den Anspruch haben letztlich jedes relevante Schriftsystem der Welt – und möglicherweise auch extraterrestrische – korrekt darstellen zu können, uns die Quere:

Neben vergleichsweise simplen Ticks wie dem Einfügen von breitenlosen und damit unsichtbaren Leerzeichen (Zero Width Space ZWSP), die Stringvergleiche scheitern lassen können, oder der Verwendung von Homoglyphen, die etwa zur Einführung alternativer Methodenaufrufe genutzt werden können, sind es die Nutzungen der Bidirectional Commands und davon gibt es einen ganzen Block:

Tabelle mit den UTF-8 Zeichen für Richtungswechsel. Quelle: https://www.w3.org/International/questions/qa-bidi-unicode-controls

Die lassen sich sogar verschachteln und ähnlich wie bei einem Stack in der Programmierung gibt es POP Anweisungen um Verschachtelungen wieder zu beenden und damit eine Schachtelungsebene nach oben zu gehen:

Tabelle mit den UTF-8 Zeichen für Richtungswechsel. Quelle: https://www.w3.org/International/questions/qa-bidi-unicode-controls

Gerade mit dem Isolates, die komplette Gruppen von Zeichen als gemeinsames Element behandeln, und Kombinationen von BiDi Anweisungen lassen sich leicht Fälle konstruieren, bei denen etwas, dass im Quellcodeeditor so aussieht:

...
/* Wenn Sicherheitsprüfung bestanden, dann return; */
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

für den Compiler hingegen so erscheint:

...
/* Wenn Sicherheitsprüfung bestanden, dann */ return;
if (check == true) 
     return;
else 
     throw new Exception("Keine Berechtigung!");

Hier wird also aus dem scheinbaren Kommentar am Ende eine Programmanweisung, die die Logik komplett aushebelt. Das solche subtilen Änderungen manchmal weitreichende Probleme verursachen, dafür ist der goto fail;-Bug ein gutes Beispiel, den Apple vor Jahren in seinem Betriebssystem hatte. Hier sah der fehlerhafte Abschnitt so aus:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
	goto fail;

Richtig wäre aber diese Variante gewesen:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
goto fail;

Die dritte Zeile durfte also nicht eingerückt sein. Manchmal reicht schon ein TAB um den Unterschied zu machen und in diesem Fall gab es Vermutungen, dass vielleicht jemand dafür bezahlt worden sein könnte diesen subtilen Fehler an einer entscheidenden Stelle einzubauen. Das Risiko der Entdeckung wäre gering gewesen und man hätte sich leicht damit herausreden können, dass es sich um einen Tippfehler gehandelt hat. Mit Hilfe der BiDi-Trickserei wäre dieser Fehler nicht einmal bei einem sehr sorgfältigen Code Review sichtbar gewesen.

Da die Forscher bereits reale Beispiele für die Anwendung dieser Technik gefunden haben ist das keine rein theoretische Bedrohung. Da sich solcher Code sogar per Copy-and-Paste übernehmen lässt sind beliebte Vorgehensweisen in der modernen Softwareentwicklung ebenfalls gefährdet. Also noch mehr gefährdet, als sie es immer schon waren 🙈

Was kann man tun?

Grundsätzlich wird man wohl abwarten müssen bis die Werkzeuge wie Editoren, Compilier und vielleicht auch Linter sich dieses Problems annehmen. Bis dahin gibt es vielleicht diese Faustformeln:

  • Gerade in den Quellcode eingebrachte Texte wie Kommentare und Strings sind Einstiegspunkte für diese Art von Angriff
  • Die Auswirkung der bidi-Tricksereien enden beim nächsten Zeilenumbruch. Eine einheitliche Quellcodeformatierung, die z. B. eingebettete Kommentare nicht in der gleichen Zeile stehen lässt wie Code, kann ein paar Varianten vermutlich aushebeln
  • Bei der Nutzung von fremden Programmcodes muss man noch stärker als bisher schon auf deren Qualität achten. Was immer schon notwendig, und immer schon schwierig war

HTTP Request Smuggeling 🧱⛏️

Aus Security Now 846: Auch dieses Problem wird durch Komplexität verursacht, aber auf einer ganz anderen Ebene: Hier geht es darum, dass zwei oder mehr hintereinander geschaltete Webserver, die am Bedienen eines Webrequests beteiligt sind, das dabei verwendete HTTP Protokoll nicht einheitlich interpretieren.

Und im Endeffekt unterschiedliche Vorstellungen davon haben, welche Webrequests sie eigentlich gerade verarbeiten.

Dieses Problem ist kein ganz neues Problem, aber heute noch relevanter, da es inzwischen gängige Praxis ist, dass mehr als ein Server am Ausliefern einer Seite beteiligt ist:

  • Proxy Server werden vor den eigentlichen Applikationsserver geschaltet, um die Last zu verringern
  • Webserver wie Apache oder nginx liegen vor den Applikationsservern um TLS zu terminieren oder Loginfunktionen – z. B. Shibboleth – zu übernehmen
  • Loadbalancer sind Netzwerkkomponenten, die die Zugriffe auf nachgelagerte Server verteilen, um Lasten gleichmäßig verarbeitbar zu machen
  • Dienste wie Cloudflare bieten ihren Kunden durch vorschaltete Systeme Schutz vor Denial of Service Angriffen, die eigentlichen Server sind nicht mehr direkt erreichbar
  • Und alle denkbaren Kombinationen davon….

Für die effiziente Kommunikation zwischen diesen Servern werden verschiedene Webrequests gerne hintereinander gehängt, damit sie sich schnell über die gleiche Verbindung übertragen lassen.

Aber wie schafft man es dem einen Server etwas anderes vorzugaukeln, als dem später drankommenden Server? In dem man die zwei Optionen, die der HTTP Standard als Mittel bietet um die Länge eines Request zu definieren – und damit bei hintereinander gehängten Requests zu definieren, wo der eine aufhört und der andere beginnt – so trickreich nutzt, dass die beteiligten Server zu unterschiedlichen Ansichten darüber gelangen, wo die Grenze zwischen zwei Requests liegt. Auch wenn es laut dem Standard eigentlich klar wäre, wie vorzugehen ist:

“According to the HTTP/1.1 standards, if both Content-Length and Transfer-Encoding headers are passed, Transfer-Encoding takes precedence.”

Quelle auf Medium

Auf diese Weise kann es bei anfälligen Serverkombinationen – und laut diesem Paper sind das viele – gelingen einen Zugriff auf einen Backend Server abzusetzen, der eigentlich von den davor geschalteten Servern gefiltert werden sollte. Das kann insbesondere dann relevant sein, wenn die vorgeschalteten Server das Login- und Rechtemanagement übernehmen.

Für eine bestimmte Variante des Request Smugglings vulnerable Serverkombinationen laut diesem Paper

Auch hier ist es nicht leicht etwas zu tun. Wie immer muss man natürlich seine Server aktuell halten, so gibt es z. B. für Tomcat inzwischen einen Patch für CVE-2021-33037, der auch mit HTTP Request Smuggeling zu tun hat. Aber auf das Verhalten vieler Komponenten, wie z. B. Loadbalancer, hat man wenig bis keinen Zugriff.

Eine Lösung ist es vielleicht die kritischen Entscheidungen einer Applikation – also die Rechte- und Zugriffskontrolle – möglichst weit nach hinten zu verlagern, bis in die Applikationsserver. Das nimmt einem Optimierungsmöglichkeiten, aber dafür ist der Server, der am Ende die Requests verarbeitet, auch derjenige, der entscheidet welche Requests zulässig sind.

Hafnium im Gartenshop

Die wahlweise Hafnium oder ProxyLogon genannte Gruppe von Sicherheitslücken in Microsofts Exchange Servern dominierte in den letzten Wochen die IT Sicherheitsthemen. Und selbst wenn IT Profis wie die Kollegen in der Uni die Lücken schnell geschlossen haben kann einen das Thema betreffen. Daran erinnert diese Mail eines Webshops, bei dem ich vor Jahren mal etwas bestellt habe, und die gestern eintraf:

Screenhot einer Mail mit der Information darüber, dass der Exchange Server eines Webshops gehackt wurde

Nicht alle Admins von Exchange Servern waren schnell genug um den direkt nach Bekanntwerden der Lücke einsetzenden, massenhaften Scans nach verwundbaren Servern zuvor zu kommen. Vermutlich gibt es 10.000e von Systemen, die schon mit Webshells oder anderen Hintertüren ausgestattet wurden (Nachtrag: manche offenbar auch gleich mehrfach). Und ein reines Patchen der Exchange Lücken beseitigt diese Zugänge dann nicht mehr.

Die DSGVO zwingt nun die Betreiber zumindest im europäischen Raum dazu ihre Kund*innen über solche Vorfälle zu informieren. Und ich würde wetten, dass das nicht die letzte entsprechende Mail war, die ich bekommen werde. Natürlich nur, wenn gehackte Betreiber sich gesetzeskonform verhalten bzw. überhaupt entdecken, dass sie gehackt wurden.

Was kann man tun?

Bei der Gelegenheit die Erinnerung an den schönen Have i been pwned? Dienst:

https://haveibeenpwned.com/

Der benachrichtigt einen, wenn mit der eigenen Mailadresse verknüpfte Kontodaten irgendwo im (Dark)Web auftauchen, oft auch verbunden mit der Information von welchem Dienst diese Daten gestohlen wurden. Ich habe in den letzten Jahren schon mehrere entsprechende Meldungen bekommen und zum Glück hatte ich bei den jeweiligen Diensten schon individuelle, nur für den jeweiligen Dienst geltende Passworte verwendet, so dass mit den gestohlenen Zugangsdaten nicht noch weitere Konten von mir missbraucht werden konnten.

Was zum nächsten Tipp führt: Heute ist die Verwendung eines Passwortmanagers unumgänglich um

  • sehr sichere (also lange und komplett zufällige) und
  • für jeden Dienst einzigartige

Logindaten zu verwenden. Wer sich dabei nicht auf die in heutigen Webbrowsern eingebauten Passwortmanager verlassen möchte, der findet hier einen aktuellen Überblick.

Wie lang darf eigentlich ein class-Attribut sein?

Ich arbeite nicht erst seit gestern mit HTML, aber diese Frage habe ich mir nie gestellt. Der aktuelle Security Now Podcast (Folge #810) mit seiner Beschreibung der interessanten ‘Prime+Probe 1, JavaScript 0: Overcoming Browser-based Side-Channel Defenses’ Forschungsarbeit hat mich erst darauf gebracht: Darin geht es um einen Ansatz um Nutzer*innen im Webbrowser ganz ohne Javascript zu tracken und der trickreiche Ansatz um mal wieder Cache Timings als Seitenkanal zu nutzen verwendet – Achtung! – 2 Millionen Zeichen lange Klassennamen. Zitat:

CSS Prime+Probe Implementation. Figure 3 shows a code snippet implementing CSS Prime+Probe, using CSS Attribute Selectors to perform the attack. Specifically, Line 9 defines a div with a very long class name (two million characters).

Kann das sein? Warum sollte die HTML Spezifikation derart lange Namen erlauben? Hätte ich vorher darüber nachgedacht wäre mein Tipp vermutlich bei 1024 oder maximal 32.768 Zeichen gelandet. Das sollte auch für sehr sprechende und exzessive Anwendungen von CSS Klassennamen ausreichen, wie sie z. B. die BEM Vorgehensweise nahelegt.

HTML Code mit sehr langem class-Attribut

Aber die Antwort, warum die Spezifikation solche langen Namen erlaubt, scheint einfach zu sein: Sie macht hier überhaupt keine Vorgabe! Demnach setzen nur die konkreten HTML Implementierungen der Webbrowser Grenzen, schon um zu verhindern, dass solche absurden Inhalte den Speicher zum überlaufen bringen. Aber wenn es solche Grenzen gibt, dann liegen sie offenbar weit jenseits dessen, was sich ‘vernünftig’ anfühlt.

Ob die Browserhersteller angesichts solcher Tricksereien nun anfangen engere Begrenzungen zu definieren? In regulären Webanwendungen sind jedenfalls kaum Anwendungen vorstellbar, die mehr als 1024 Zeichen für Klassennamen verwenden. Oder?