ssh(1) erhält Verschleierung des Tastenanschlag-Timings

 (undeadly.org)
3 Punkte von GN⁺ 2023-08-30 | 1 Kommentare | Auf WhatsApp teilen
  • Damien Miller hat eine Verschleierungsfunktion in den ssh(1)-Client eingebracht, die Zeitinformationen zwischen Tastenanschlägen verbirgt
  • Bei interaktivem Traffic mit wenig zu sendenden Daten wird eine Übertragung in festen Intervallen verwendet, das Standardintervall beträgt 20 ms
  • Nach dem letzten echten Tastenanschlag werden für eine zufällige Zeit gefälschte chaff-Tastenanschläge gesendet, um das Timing-Muster weiter zu verwischen
  • Das Verhalten wird über das neue ssh_config-Schlüsselwort ObscureKeystrokeTiming gesteuert
  • Für die Implementierung wird eine neue PING/PONG-Erweiterung der SSH-Transportschicht verwendet, die später über openssh-portable auch auf andere Systeme kommen könnte

Verbergen des Tastenanschlag-Timings im ssh(1)-Client

  • Damien Miller hat Support für Verschleierung des Tastenanschlag-Timings in ssh(1) eingebracht
  • Diese Funktion versucht, interaktiven Traffic mit wenig ausgehenden Daten in festen Intervallen zu übertragen, um die Zeitabstände zwischen Tastenanschlägen zu verbergen
    • Das Standard-Übertragungsintervall beträgt 20 ms
    • Nach dem letzten echten Tastenanschlag werden für eine zufällige Zeit gefälschte chaff-Tastenanschläge übertragen
  • Das Verhalten wird über das neue ssh_config-Schlüsselwort ObscureKeystrokeTiming gesteuert

SSH-Protokollerweiterung und Ausrollpfad

  • Die Implementierung verwendet zwei neue Nachrichten der SSH-Transportschicht, die dem SSH-Protokoll hinzugefügt wurden
    • SSH2_MSG_PING
    • SSH2_MSG_PONG
  • Diese Nachrichten verwenden den Nummernraum für lokale Erweiterungen und werden mit der ext-info-Nachricht "ping@openssh.com" sowie der String-Version "0" angekündigt
  • Die Änderung wird als Beispiel für „security by trickery“ vorgestellt und als Grund genannt, sich auf das nächste OpenBSD-Release zu freuen
  • Andere Systeme könnten diese Funktion bald über openssh-portable erhalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-30
Meinungen auf Hacker News

  • Tastatureingabe-Timing war bei Terminal-Ein-/Ausgabe schon seit den 1980er-Jahren ein Thema; selbst damals wurde in frühen verschlüsselten Umgebungen wie stelnet oder Kerberos bereits darauf geachtet.
    Die meisten Terminal-Apps verwenden für Passworteingaben gepufferte Ein-/Ausgabe, und das ist weiterhin ein wichtiges Sicherheitsfeature.
    In diesem Modus wird nichts an die Gegenseite übertragen, bevor der Nutzer Enter drückt; mit Padding kann ein Man-in-the-Middle-Angreifer daher kaum einmal die Passwortlänge ableiten.
    Eine Zeit lang waren Apps, die Passwörter im ungepufferten Modus entgegennahmen, um bei jeder Eingabe ein * anzuzeigen, ein dankbares Ziel.
    Das sieht zwar gut aus und gibt Feedback, leakt aber genau die Tippgeschwindigkeit, die man bei der Passworteingabe am stärksten verbergen sollte.
    Ich hoffe, dass bei der Passworteingabe weiterhin gepufferte Ein-/Ausgabe beibehalten wird; ich halte diesen Ansatz für so viel besser, dass selbst SSH-Obfuskation da schwer mithalten kann.
    Trotzdem ist es gut, dass SSH diese Funktion ergänzt hat; sie hilft beim Schutz von Inhalten, die sich nicht puffern lassen, etwa Eingaben in Shells oder Editoren.

    • Die heute verwendete Methode, unabhängig von der Passwortlänge eine feste Anzahl von Sternchen anzuzeigen, ist für Nutzer ziemlich verwirrend.
      Sie könnten denken: „Die Länge stimmt nicht, also ist es wohl falsch“, und damit den Vorteil gespeicherter Passwörter zunichtemachen, indem sie erneut versuchen, das „richtige“ Passwort manuell einzugeben.
      Früher gab es wohl auch Ansätze mit visuellen Hashes, etwa zweistelligen Hashes und Smileys; gegen Shoulder-Surfing-Angriffe kann das allerdings sogar hilfreich sein.
    • In den 1990ern konnte ein Visual-Basic-basiertes AI-Add-on schon nach wenigen Minuten Tippen allein anhand des Tippmusters erkennen, wer gerade die Tastatur bedient; damit wurde der Login-Prozess praktisch sinnlos.
      Heute ließe sich das auch auf Touchscreen-Logins anwenden, indem Fingerdruck, Kontaktfläche und Form einem Nutzer zugeordnet werden.
      Wenn man sogar Swipes oder Mausbewegungen in den Kontext von Desktop-OS einbezieht, wären Sicherheits-Apps möglich, die das System sperren, wenn jemand ein Gerät oder Konto nutzt, das nicht ihm gehört.
      Zumindest ließe sich protokollieren, wann die Partnerin oder der Partner mein Handy durchsucht hat.
    • Passwortbasierte SSH-Authentifizierung sollte man so gut wie nie verwenden.
    • Ich frage mich, ob es SSH-Clients gibt, die Eingaben zeilenweise puffern.
      Also eine Methode, bei der das Eingegebene erst übertragen wird, wenn man Enter oder einen Senden-Button drückt.
      In meiner aktiven MUD-Zeit habe ich solche Telnet-Clients verwendet, aber bei später genutzten SSH-Clients habe ich das nie gesehen.
      Als Schutz gegen SSH-Leaks beim Tastatureingabe-Timing klingt das brauchbar und könnte in manchen Nutzungsszenarien besser sein als der im Artikel beschriebene Ansatz mit 20 ms Verzögerung.
      Wenn ich darüber nachdenke, wäre es allerdings ideal, wenn auch ein Tab-Druck für die Autovervollständigung in Linux-Shells übertragen würde.
    • Wenn „die meisten Terminal-Apps für Passworteingaben gepufferte Ein-/Ausgabe verwenden“, frage ich mich, ob die Existenz dieses Patches bedeutet, dass OpenSSH sich nicht so verhält.

  • Das erinnert mich an professionelles Bridge.
    Man trennt die Teams durch eine Wand und reicht die Karten gleichzeitig durch eine Öffnung, um Kommunikation über Timing zu verhindern.
    https://youtube.com/watch?v=RVZLNRmO3vo

    • Trotzdem wird über die Screens geschummelt.
      https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an...
      https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca...
      https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s...
      Und das sind nur die Fälle, von denen wir wissen.
      Ich habe Bridge früher einmal tatsächlich in einem Vorstellungsgespräch angewendet.
      Im Bridge gibt es die Active-Ethics-Regel: Wenn der Partner einem auf anderem Wege als durch das Bieten einen Hinweis gibt, muss man, sofern logisch möglich, zwingend die entgegengesetzte Richtung wählen.
      In einem Debugging-Interview versuchte der Interviewer, mich viel zu offensichtlich zur Lösung zu führen; bevor ich tat, was er gesagt hatte, hielt ich inne und überprüfte alles, was mir einfiel.
      Nach dem Gespräch erklärte ich, warum ich das getan hatte, und sagte, falls mehr Erklärung nötig sei, solle man Active Ethics nachschlagen.
      Und ich bekam die Stelle.
    • Wenn Menschen einfach nur wie menschliche Zustandsmaschinen einen vorgegebenen Automaten ausführen sollen und bei Abweichungen Strafpunkte bekommen, kann man den Gewinner auch per Münzwurf bestimmen und das Spiel ganz weglassen.
      Das ist ungefähr so, als würde man sagen, ein Catcher dürfe dem Pitcher keine Signale geben.
      Informationsübermittlung ist eine menschliche Fähigkeit, die dem Spiel eine weitere Dimension gibt; man sollte einfach die gewinnen lassen, die sie am besten beherrschen.
    • Aus Red-Team-Sicht gibt es hier viel zu viele menschliche Unregelmäßigkeiten, die sich ausnutzen lassen.
      1 bis 2 Bit Information weiterzugeben, scheint nicht besonders schwer zu sein.
    • Bridge ist wirklich ein seltsames Spiel.
      Geheime Kommunikation mit dem Partner ist zentral, aber diese Kommunikation darf nicht geheim sein.
      Man darf kommunizieren, soll aber nicht kommunizieren – das ist schon sehr eigenartig.
    • Es scheint immer noch Möglichkeiten zu geben, Informationen zu übertragen.
      Man könnte zum Beispiel einen kleinen Tisch über die Barriere hinweg kurz anstoßen oder langsam schieben, um etwas zu signalisieren.
      Die Person oben rechts im Video hat ihn beim ersten und zweiten Mal so hinübergeschoben.

  • Es gibt einen Artikel von 2008 über ein Paper von 2001 zu solchen Timing-Angriffen: https://lwn.net/Articles/298833/
    Das zitierte Paper heißt „Timing analysis of keystrokes and timing attacks on SSH“ und analysiert, dass Timing-Informationen von Tastatureingaben Informationen über die eingegebene Tastenfolge leaken.
    Eine detailliertere Analyse kommt zu dem Schluss, dass pro Tastaturpaar etwa 1 Bit Information über den Inhalt durchsickert; da Passwortentropie ungefähr 4 bis 8 Bit pro Zeichen beträgt, kann diese Information ziemlich relevant sein.
    Ich dachte, das sei längst behoben worden, und meinte, dass um 2012 herum ein Fix eingeflossen sei; daher überrascht es mich ziemlich, dass das noch nicht gelöst ist.

  • Irgendwann muss man vielleicht mit Zufallsdaten vorab gefüllte Pakete verwenden, um Tastatureingaben zu verbergen.
    Das ist zwar keine Steganografie, kommt dem aber ziemlich nahe, und es ließe sich wohl auch nutzen, um Traffic-Analyse deutlich schwieriger oder unmöglich zu machen.

    • Die NSA und andere nutzen solche Verfahren schon seit Jahrzehnten.
      Bei einer dedizierten Leitung ist es nicht besonders schwierig, die Leitung ständig mit maximaler Auslastung vollständig verschlüsselt zu befüllen und nur bei Bedarf echte Daten daraufzulegen.
    • Mit diesem Ansatz ist auch Steganografie möglich.
      Es gibt Forschung dazu, harmlosen Cover-Text von einem Sprachmodell umschreiben zu lassen, dabei aber die für das Wort-Sampling verwendete Wahrscheinlichkeitsverteilung durch eine aus dem Schlüssel abgeleitete Verzerrung mit minimaler Entropie zu ersetzen.
      Auf Empfängerseite kann man mit demselben Modell und Schlüssel den Cover-Text wieder in Chiffretext decodieren; das funktioniert auch bei Bildern.
      https://openreview.net/forum?id=HQ67mj5rJdR
    • Das erinnert an Zahlensender.
      Sie senden fortlaufend Zahlen in die ganze Welt, und Bedeutung entsteht erst dann, wenn diese Zahlen für jemanden relevant sind.
      Und das, obwohl völlig klar ist, dass die Nachrichtendienste weltweit mithören.
    • Einige Messaging-Protokolle funktionieren so.
    • SSH-Traffic ist verschlüsselt, daher sehen die Pakete für Beobachter ohnehin bereits wie Zufallsdaten aus.

  • Das erinnert an moderne Terminal-Emulatoren wie Warp auf macOS.
    Ich frage mich zum Beispiel, ob sie alle Eingaben lokal entgegennehmen und dann als einen Block an den Remote-Host senden.
    Dadurch könnten bestimmte auf dem Remote-Host ausgeführte Raw-Mode-Eingaben zwar kaputtgehen, aber man könnte solche Situationen erkennen und dann auf einen rohen Tastatureingabe-Stream umschalten.
    [1]: https://warp.dev

    • Im Allgemeinen ist bei einer SSH-Verbindung die Verbindung selbst immer im Raw Mode, und der Remote-Host verarbeitet das pty auf die übliche Weise.
      Das entfernte pty kann zeilenorientiert oder im Raw Mode sein.
      Terminals mit spezieller Shell-Integration benötigen normalerweise, dass diese Integration auch auf dem Remote-Host installiert ist; manche erledigen das recht transparent.
      Deshalb kann sich mosh auf Verbindungen mit höherer Latenz besser verhalten als reines SSH.
      Diese Funktion wird allerdings wohl nicht für mosh gelten.
    • Ich kann mir kaum vorstellen, dass eine App, die sich als „AI for the terminal“ vermarktet, sicherer und privater sein soll als Standard-Unix-Tools.
      Bei bestimmten Sicherheitsfunktionen, etwa Schutz vor Timing-Angriffen, können neue Tools besser sein, und alte Standard-Tools haben sie vielleicht nicht.
      Aber es ist viel wahrscheinlicher, dass bei neuen Tools andere Sicherheitsfunktionen fehlen, und wenn man „AI“ hinzufügt, wächst auch die Angriffsfläche erheblich.
      Die Datenschutzbehauptungen von Warp finde ich ehrlich gesagt schwer zu glauben.
      Heutige Natural-Language-Processing-Tools tendieren fast immer zu Cloud-Lösungen, und dann sinkt die Chance auf Datenschutz praktisch sofort gegen null.
    • Wenn etwas dafür ausgelegt ist, Daten mit einer bestimmten Baudrate zu empfangen, würden dann nicht auch als Block gesendete Eingaben entsprechend dieser Rate eintröpfeln?

  • Ich frage mich, welche Bedrohung dadurch abgeschwächt wird.

    • Ein Lauscher kann den Inhalt der Tastatureingaben nicht sehen, konnte aber bisher sehen, wann jede einzelne Tastatureingabe übertragen wurde.
      Wenn man das Tippmuster der Zielperson kennt, kann man aus diesen Daten den Inhalt rekonstruieren.
      Man kann die Zielperson in einem Browser mit aktiviertem JavaScript auf einer von mir kontrollierten Website tippen lassen oder die Tippgeräusche aufzeichnen, um das Muster zu sammeln.
      In letzter Zeit wurden einige Online-Streamer sogar mit Angriffen konfrontiert, bei denen Passwörter mithilfe von AI-Modellen gestohlen wurden, die auf Tastaturgeräusche trainiert waren.
    • Wenn ich mich richtig erinnere, gab es um 2005 herum ein Paper, in dem man Paket-Timing in verschlüsselten SSH-Sessions mit gesammelten Statistiken menschlichen Tippens korrelieren konnte, um die Eingaben herauszufinden.
      Diese Funktion scheint Rauschen hinzuzufügen, um genau das zu verhindern.
    • Die ursprüngliche Sorge bei der Schwachstelle betraf die Verwendung des Viterbi-Algorithmus.
      http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf [2001]
      Durch den Einsatz von Machine Learning ist die Genauigkeit beim Decodieren von Audio deutlich besser geworden; an physisch unsicheren Orten sollte man daher eine leise Tastatur verwenden.
      https://arstechnica.com/gadgets/2023/08/type-softly-research...
    • Im Grunde kann man durch Analyse der Tippgeschwindigkeit einige Rückschlüsse ziehen.
      Zum Beispiel tippen Nutzer Passwörter meist schneller als andere Eingaben, sodass man bei Vorgängen wie sudo aus der Anzahl der auf einmal übertragenen Tastatureingaben die Passwortlänge abschätzen kann.
    • Vor Kurzem gab es Forschung, die Nutzer anhand von Tastatureingabe-Timing und Deep Learning wie mit einem Fingerabdruck identifiziert und in diesem Paper zur Authentifizierung einsetzt: https://www.usenix.org/system/files/usenixsecurity23-piet.pd...
      Der Anwendungsfall des Papers selbst ist keine Sicherheitsbedrohung, kann aber als Informationsleck interpretiert werden.

  • Ich frage mich, wie viel Latenz dadurch hinzukommt.
    Besonders unvorhersehbare Verzögerung ist einer der größten Stressfaktoren bei Softwareentwicklungsarbeit.

    • Das steht direkt im Text.
      Wenn nur kleine Datenmengen übertragen werden, wird interaktiver Traffic in festen Intervallen gesendet; der Standardwert liegt bei 20 ms.
    • Die obige Latenz-Diskussion scheint sich auf Verzögerung in der User Experience zu beziehen, also auf die Zeit vom Tastendruck bis zur sichtbaren Ausgabe.
      [1]
      Tools wie Mosh helfen ziemlich gut dabei, die wahrgenommene Latenz zu reduzieren.
      Mosh zeigt Nutzereingaben sofort an, sobald sie lokal registriert werden, und stellt sie ausgegraut dar, um zu signalisieren, dass der Roundtrip noch nicht abgeschlossen ist.
      So war es zumindest, als ich es zuletzt gesehen habe; vielleicht war es auch unterstrichen.
      Sobald der Roundtrip abgeschlossen ist, wird das Zeichen normal angezeigt.
      [1] Wenn die größte Stressquelle in der Softwareentwicklung die Verzögerung bei Tastatureingaben ist, klingt das nach ziemlichem Glück.
      [2]: https://mosh.org
    • Ist diese Verzögerung nicht per Design vorhersagbar?

  • Tatsächlicher Commit-Link: https://github.com/openssh/openssh-portable/commit/7603ba712...

  • Manche scheinen per Messung des Paket-Timings Hands-on-keyboard-Shells im Netzwerk zu erkennen; ich frage mich, wie sehr diese Änderung eine solche Erkennung behindern wird

    • Solche Ansätze sollten hoffentlich denselben Weg gehen wie andere unternehmerische Versuche, Verschlüsselung im Namen der „Sicherheit“ aufzubrechen oder Backdoors einzubauen
      Als Ansatz für Sicherheit halte ich das für wirklich falsch
      Es wäre zwar nützlich zu wissen, ob ein Automatisierungsskript sich auf einem Gerät einloggt, aber mit einem besseren Design könnte man dafür sorgen, dass diese Information nicht wichtig ist
    • Welche nicht bösartigen Anwendungsfälle gäbe es dafür?