Re: S/Key und ssh

Hallo Harold,

hm, warte mal.

>> Mein Vertrauen in die Sicherheit der ssh ist mit meiner
>> Bekanntschaft mit ettercap ( http://ettercap.sourceforge.net
>> )
>> massiv erschüttert worden.

> Eigentlich hilft SSH gegen genau das Problem.
> Das was du mit ettercap ansprichst, ist ja ein
> Man-In-The-Middle
> Angriff, ettercap gibt sich dem Client gegenueber als der
> Ziel-SSHD aus und dem Server gegenueber als der Client.

So ist es, genauer gesagt antwortet ettercap mit einem gefakten
Server-Key, so daß Du natürlich auch mit Deiner u.g.
Feststellung recht hast, daß ssh warnt, wenn sich der
Server-Key gegenüber einer vorher etablierten Session geändert
hat. Das einzige, woran ich bei einem solchen Phänomen immer
denke, sind die ganzen etwas, ahem, unbedarfteren Benutzer,
denen man nun mit Händen und Füßen eingebläut hat, daß sie ssh
statt telnet nutzen sollen und die nun, wenn das Ding
irgendetwas unerwartetes tut, einfach auf Enter hauen.

Aber das Problem gibt es natürlich immer, egal wie sicher die
Software ist.

> Zunaechst
> Mal moechte ich festhalten, dass du in diesem Fall beiden
> (Client
> und Server) vertraust, das Problem aber irgendwo auf der
> Leitung
> sitzt.

Na gut, wenn Du die beiden direkt mit einem Crossover-Kabel
verbindest, hast Du das Problem nicht.

> Solltest du dich mit diesem Client bereits einmal auf
> diesem Server eingelogt haben, so wird dir der Client einen
> solchen Angriff melden ("Host Key has changed") und du weisst,
> dass da was faul ist.

Jau, wüßte ich ;o)) ssh verweigert dann ja sogar den
Verbindungsaufbau, sofern man nicht händisch an den
gespeicherten Keys herumtampered, wenn ich mich recht
entsinne... insofern ist natürlich mein oben gemachter Kommentar
auch wiederum zu relativieren...

> Allerdings sehe ich da im Moment nicht direkt einen
> Zusammenhang
> zu S/Key...

Der Zusammenhang ist nur das 'level of trust' bei der
Authentifizierung selbst. Wenn man es (entgegen dem oben
geschilderten Szenario) hinbekommt, seinen ettercap-Host als
erstes seinen Key übermitteln zu lassen, wird der anfragende
Client diesen Key bis auf weiteres als legitim verstehen.

Wenn ich mich nicht gerade sehr irre (was bei mir immer sein kann
;o)), findet bei einer 'normalen' ssh-session (will meinen,
ohne explizit gespeicherte keys) erst der key exchange inkl.
Etablierung des Session-Keys statt und dann wird erst das
Paßwort abgefragt - wäre ansonsten ja auch etwas witzlos.

Damit kann der 'eavesdropper' Dein Paßwort schlichtweg mitlesen.
Benutzt Du s/key, nutzt ihm das für einen selbständigen
darauffolgenden Verbindungsaufbau gar nüscht.

>> Nun, mit ettercap kannst Du zumindest die Session in dem
>> Sinne
>> 'kapern', als daß 'character injection' möglich ist. Schaut
>> Euch
>> das Ding mal an, wer da nicht blaß wird, hat bessere Nerven
>> als
>> ich.
>
> Och, naja, oder man kennt die Ideen dahinter schon seit
> laengerer
> Zeit :).

Naja, die Geschichte mit der man-in-the-middle-attack bei ssh
wird ja nun seit längerer Zeit immer wieder aufgewärmt. Es macht
allerdings einen Unterschied (für mich zumindest), ob man ein
advisory liest, oder ein skript-kiddie-safe menübasiertes Tool
mit recht gelungenem curses-Interface vor der Nase hat.

> S/Key mag auf den ersten Blick wie eine Art One-Time-Pad fuer
> Passworte aussehen, es ist aber etwas ganz anderes, alleine
> schon
> dadurch, dass die S/Key-Schluessel *berechnet* werden (wenn
> auch
> auf eine solche Art, dass die Berechnung nur in umgekehrter
> Reihenfolge "einfach" moeglich ist, also das Passwort fuer den
> 1. Login sich relativ einfach mit Hilfe des Passwortes fuer
> den
> 2. Login berechnen laesst - umgekehrt ist das ganze ziemlich
> schwierig).

Gut, da war ich mal wieder begrifflich unpräzise, one time key
meinte ich, nicht one time pad ;o))

hast ja recht ;o))

>> solche zu verschlüsseln ist meiner Meinung nach auch dann
>> sinnvoll, wenn keine Paßworte mehr übertragen werden, da
>> ansonsten ein potentieller Angreifer sich Übersicht darüber
>> verschaffen kann, was man als Admin so treibt, welche tools
>> genutzt werden und wo sie liegen etc. pp.
>
> Ganz abgesehen davon dass wenn ihm die Session im Klartext
> vorliegt, er sie hijacken kann (naja, zumindest sofern nicht
> etwas ganz exotisches gemacht wird wie das Verwenden eines
> asymmetrischen Verschluesselungsverfahren, oder ein
> Verschluesseln nur in Richtung Client->Server und nicht
> umgekehrt).

Naja, wenn jemand die o.g. man in the middle attack erfolgreich
durchgeführt hat, ist für ihn die Verschlüsselung transparent,
d.h. er kann auch lustig in die aktive Session eingreifen.
 
>> Jedenfalls hatte ich alle Unix-Logins disabled - mit ssh
>> geht's
>> aber nach wie vor. Keine Ahnung, wie da die Verknüpfung mit
>> login, getpass etc. vonstatten geht, da kenne ich mich bis
>> dato
>> zuwenig aus...
>
> Ein Schuss ins Blaue - /etc/pam.conf?

Ja, hätte ich auch als erstes einmal angenommen, aber in der
Doku stand dazu nix, deshalb war ich erst einmal vorsichtig mit
solchen Behauptungen ;o))

Schönen Gruß auch,

Jan

-- 
Radio HUNDERT,6 Medien GmbH Berlin
- EDV -
j.muenther(at)radio.hundert6.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message