Re: S/Key und ssh

On Fri, May 25, 2001 at 09:31:57AM -0000, jan(at)radio.hundert6.de wrote:
> Holla die Waldfee,
>
> da habe ich ja mal wieder was losgetreten.
> Der ursprüngliche Gedankengang war folgender:
>
> Zum einen habe ich ein generelles Problem damit, Paßwörtern zu
> vertrauen. Wenn beispielsweise der Client kompromittiert wurde
> (was man nicht immer unter Kontrolle hat, wie beispielweise in
> den von Euch bereits angebrachten Beispielen) oder irgendein
> Spaßvogel einen Keyghost dazwischengeschaltet hat, hat man
> schlichtweg verloren.
>
> Mein Vertrauen in die Sicherheit der ssh ist mit meiner
> Bekanntschaft mit ettercap ( http://ettercap.sourceforge.net )
> massiv erschüttert worden. Außerdem ist mit dem Ding
> ARP-cache-poisoning derartig einfach geworden, daß man sich den
> vermeintlichen Sicherheitszuwachs durch ein geswitchtes Netz
> endgültig an den Hut stecken kann.

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. Zunaechst
Mal moechte ich festhalten, dass du in diesem Fall beiden (Client
und Server) vertraust, das Problem aber irgendwo auf der Leitung
sitzt. 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.
Allerdings sehe ich da im Moment nicht direkt einen Zusammenhang
zu S/Key...

> > Programme, die Tastatureingaben mitloggen, gibt es diverse.
> > Genau gegen dieses Problem helfen OTP-Tools (z.B. s/key).
> >
> > Du hast insofern recht, als daß es nicht wirksam hilft,
> > wenn ein automatisiertes Programm _sofort_ das Paßwort
> > nimmt und einen Einlogforgang damit macht, bevor der eigene
> > abgeschlossen ist. So ein Programm ist mir allerdings
> > nicht bekannt -- das muß nicht heißen, daß es sowas nicht
> > gibt, aber auf jeden Fall dürfte sowas schonmal weniger
> > verbreitet sein.
>
> 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 :).

> > Klar, s/key ist ebensowenig ein Allheilmittel wie ssh,
> > aber beide haben ihre Existenzberechtigung.
>
> Außerdem erscheint mir nach wie vor die Kombination aus beidem
> Sinn zu machen: Ein one-time-pad ist, sagen wir mal, evident das
> sicherste, was kryptographisch machbar ist. Die session als

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).

> 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).

> 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?

bye,
  Harold

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 26 May 2001 - 02:45:15 CEST