SSH-Attacken: kann man Passwörter mitloggen

[Reks30]

Hallo,

wahrscheinlich kennt ja jeder von euch die SSH-Passwort-rate-Attacken. Ich habe um mal rauszufinden was so ein Angreifer nach erfolgreichen raten eines Passwortes so böses anstellen will, einen Honeypot aufgesetzt. Für den Honeypot habe ich ca. ein dutzend Useraccounts eingerichtet, die allesamt extrem leicht zu erratende Passwörter haben (meistens Username=Passwort). Bislang hat einmal kurz einer schon versucht reinzukommen, aber der hatte nur den Usernamen guest benutzt und einen solchen Account hatte ich noch nicht angelegt (jetzt schon, bitte komm wieder). Da die Logs aber leider keine Auskunft über die verwendeten Passwörter machen und ich es dem Angreifer so einfach wie möglich machen will, wollte ich fragen ob es eine Methode gibt, die verwendeten Passwörter herauszufinden?

Gruß
Reks30

 

[Benedikt]

Ich weiß es nicht, aber ich denke nein. Das würde doch den Sinn eines Passwortes rauben, oder nicht?

Warum kann man die Passwörter nicht im Klartext sehen? Richtig. Und ich denke nicht, dass eine solche Funktion vorgesehen oder zu finden ist, da der Root sich ohne Passwort als jeder Benutzer anmelden kann.

Ich denke also da wirst du nicht fündig werden. Aber wie gesagt, ich sage nur was ich vom Sicherheitsgedanken her annehme, wissen tu ich es nicht.

 

[moe]

Wenn ich das SSH-Protokoll richtig verstanden habe, ist nicht möglich das Passwort irgendwo zu "lesen", weil es schlicht nirgens im Klartext oder in entschlüsselbarer Form vorhanden ist.
Therothisch möglich wärs allerdings dass der sshd jede Benutzer/Passwort-Kombination akzeptiert, aber das wird bestimmt auch keine vorgesehene Option in sshd_config sein. ;-)

Gruss Maurice

 

[Reks30]

Wenn ich das SSH-Protokoll richtig verstanden habe, ist nicht möglich das Passwort irgendwo zu "lesen", weil es schlicht nirgens im Klartext oder in entschlüsselbarer Form vorhanden ist.

Da muß ich dich aber korrigieren: SSH verschlüßelt das Passwort während der Übertragung. Aber diese Verschlüßelung ist eine Ende zu Ende Verschlüßelung und auf dem Endpunkt (also dem Zielrechner) wird wieder entschlüßelt. Daher ist es durchaus auf dem Zielrechner im Klartext vorhanden (irgendwo im Ram), denn sonst könnte man es nicht mit dem in einem womöglich anderen Verschlüßelungsverfahren gespeicherten Passwort gar nicht vergleichen.

Therothisch möglich wärs allerdings dass der sshd jede Benutzer/Passwort-Kombination akzeptiert, aber das wird bestimmt auch keine vorgesehene Option in sshd_config sein.

Tja, dann müßt ich die sshd Quellen selber bearbeiten, ich kann aber kein C. Also fällt diese Möglichkeit sowieso weg.

Gruß
Reks30

 

[bsd5543]

Lass das Passwort doch leer. Im I-Net kursieren Passwort-Dictionaries, verwende PWs daraus oder nimm user test mit pw test.

cheers

 

[Dinh]

Da muß ich dich aber korrigieren: SSH verschlüßelt das Passwort während der Übertragung. Aber diese Verschlüßelung ist eine Ende zu Ende Verschlüßelung und auf dem Endpunkt (also dem Zielrechner) wird wieder entschlüßelt. Daher ist es durchaus auf dem Zielrechner im Klartext vorhanden (irgendwo im Ram), denn sonst könnte man es nicht mit dem in einem womöglich anderen Verschlüßelungsverfahren gespeicherten Passwort gar nicht vergleichen.

Bist du dir da sicher?
Ich dachte, selbst *BSD kennt die User-Passwörter nicht im Klartext, sondern nur als MD5 o.ä. Hash.

Vermutung: ssh könnte jetzt ja den Hash nochmals zusätzlich verschlüsseln, so dass selbst der ursprüngliche Hash (mit dem man sich ja authentifizieren könnte) nicht im Klartext vorhanden ist.

Wäre das sinnvoll bzw. entspricht das der Wahrheit?

 

[0815Chaot]

Das wäre nur praktikabel, wenn Client und Server exakt die gleichen Hash-Verfahren unterstützen würden. 3DES, MD5 und Blowfish sind zwar heute weit verbreitet. Aber was darüber hinaus geht ist Glückssache. Darauf kann man sich schlecht verlassen. Daher muß das Paßwort im Klartext durch den Tunnel gehen, der Server berechnet dann den Hash. Daher ist es auch technisch möglich, das Paßwort auszulesen. Verständlicher Weise ist diese Möglichkeit aber nicht von den Entwicklern implementiert worden.

 

[Reks30]

Bist du dir da sicher?

Ja, weil es technisch gar nicht anders möglich ist.

Vermutung: ssh könnte jetzt ja den Hash nochmals zusätzlich verschlüsseln, so dass selbst der ursprüngliche Hash (mit dem man sich ja authentifizieren könnte) nicht im Klartext vorhanden ist.

Wäre das sinnvoll bzw. entspricht das der Wahrheit?

Nein, das Problem an der Sache: Man kann sich nicht mit einem Hash authentifizieren, da aus dem mit dem man sich authentifizieren will immer ein Hash gebildet wird und der Hash eines Hashs ergibt nun mal einen anderen Hash. Man benötigt also immer irgendwann das Klartextpasswort. Bei einer Anmeldung mit SSH könnte das so aussehen:

Die SSH-Verbindung wird aufgebaut dazu wird zunächst ein asymetrischer Schlüssel benutzt (sehr sicher aber langsam). Nach dem Verbindungsaufbau mit einem asymetrisches Schlüssel wird sofort über diesen Kanal ein symetrischer Schlüssel ausgetauscht und die Verbindung wird dann mit diesem fortgesetzt (das geschieht aus Performancegründen asymetrische Schlüssel sind zu langsam). Nun wird sämtliche Kommunikation über diesen symetrisch verschlüsselten Kanal vorgenommen. das heißt mit anderen Worten: Was über den Kanal ausgetauscht wird geht in Klartext dadurch! Nur nach außen hin ist der Kanal natürlich verschlüßelt (eben mit dem symetrischen Schlüssel der vorher über einen sicheren asymetrischen Kanal ausgetauscht wurde). Am Ende der Leitung kommt dann alles wieder im Klartext an, auch das Passwort. Das Klartextpasswort wird dann mit dem auf dem jeweiligen OS vorgesehenen Verfahren gehasht (z. B. Blowfish bei OpenBSD, oder MD5 bei Linux, etc.) und mit dem gehashten gespeicherten Passwort verglichen.

Würde vorher ein gehashtes Passwort über den verschlüsselten Kanal gesendet werden, dann würde ja dieses gehashte Passwort nochmal vom OS gehasht werden und es würde ein falsches Passwort ankommen (2 mal gehasht ergibt nun mal was anderes).

Hoffe das war verständlich.

Gruß
Reks30

 

[moe]

Ja, weil es technisch gar nicht anders möglich ist.

Ich hab leider keine Infos finden können, wie OpenSSH das handhabt, aber dass estechnisch unmöglich ist, kann ich mir nicht vorstellen. Schliesslich weiß der sshd ja, welcher Algorithmus zum Hashen der Passwörter vom Betriebssystem verwendet wird, kann diesen dem Clienten mitteilen, und der erstellt dann vorher mit demselben Algorithmus einen Hash..
Der Sambaserver beispielsweise arbeitet ja nach dem Prinzip, nur das dort nur 2 Hash-Algorithmen erlaubt sind, und somit Server und Client nicht alle möglichen kennen müssen.

Sollte der sshd wirklich das Plaintext-Passwort wissen und ausgeben können, muss ich meine Sicherheitsstrategien überdenken. Ich logge mich häufig von aussherhalb auf meinem heimischen Rechner ein, und benutze dabei die normale Passwort-Authentifizierung, da ich einen Key nicht immer parat hätte.
Wenn nun mein heimischer sshd gerade vom Internet getrennt wurde (DSL-Zwangstrennung), und meine dyndns-Account noch auf die alte IP zeigt, diese aber schon einem anderen User gegeben wurde, wäre es ja möglich, das ein dort laufender sshd mein Passwort kennt und preisgibt.
Gleiches gilt natürlich, für Tippfehler beim Hostnamen usw., ich kann mir eigentlich nicht vorstellen, dass das vom OpenSSH-Team nicht bedacht und irgendwie verhindert wurde, konnte allerdings nichts finden, wo das genauer beschrieben steht.

Gruss Maurice

 

[Kamikaze]

Du würdest natürlich eine Nachicht bekommen, dass der SSH Server eine unbekannte Kennung hat (siest du immer wenn du dich zum ersten mal be einem Server einloggst). Die Passphrase wird natürlich erst übermittelt, nachdem du der Verbindung mit dem Server zustimmst.

 

[Reks30]

meine Sicherheitsstrategien überdenken. Ich logge mich häufig von aussherhalb auf meinem heimischen Rechner ein, und benutze dabei die normale Passwort-Authentifizierung, da ich einen Key nicht immer parat hätte.
Wenn nun mein heimischer sshd gerade vom Internet getrennt wurde (DSL-Zwangstrennung), und meine dyndns-Account noch auf die alte IP zeigt, diese aber schon einem anderen User gegeben wurde, wäre es ja möglich, das ein dort laufender sshd mein Passwort kennt und preisgibt.
Gleiches gilt natürlich, für Tippfehler beim Hostnamen usw., ich kann mir eigentlich nicht vorstellen, dass das vom OpenSSH-Team nicht bedacht und irgendwie verhindert wurde, konnte allerdings nichts finden, wo das genauer beschrieben steht.

Wie das Sicherheitsmäßig verhindert wird, das hat Kamikaze ja schon geschrieben (Hostschlüssel wird überprüft). Als Tip zum "SSHen" von unterwegs mit Schlüsseln: Erstelle dir einen Schlüssel den du (eventuell zusammen mit Putty) auf einen USB-Stick kopierst. Dann kannst du von unterwegs den Schlüssel vom USB-Stick benutzen.

Allerdings muß man auch dazu sagen, das wer Wert legt auf wirklich viel Sicherheit keine unbekannten Computer von unterwegs benutzen sollte. Den wer sagt mir den z. B. das der Computer im Internet Cafe nicht mit einem trojanischen Pferd infiziert ist, welcher mein Passwort mitloggt, bzw. meinen SSH-Schlüssel kopiert? Wirklich sicher ist man eben auch unterwegs nur mit eigenen Rechner (Laptop kaufen und für den Netzzugang eventuell noch UMTS/GPRS).

Ich hatte mal ein Internetcafe in den Niederlanden benutzt, auf welchen ich rechts unten das Icon von VNC erkennen konnte, wer garantiert mir nun das meine Sitzung nicht per VNC mitgeschnitten wurde?

Gruß
Reks30

 

[Reks30]

Honeypot

Falls jemanden das Ergebnis meines Honeypots interessiert: Es sind dann insgesamt 4 SSH-Passwortrateversuche an einem Tag erfolgreich gewesen. Das Script welches diese unternimmt loggt sich aber sofort wieder aus. Erstmal passiert dann weiter nichts. Leider passiert dann so lange nichts, das ich in der Zwischenzeit wieder eine neue IP bekommen habe und der (erfolgreiche) Angreifer mich sowieso nicht mehr finden wird.

Fazit: Hinter einer dynamischen IP läßt sich nicht sinnvoll ein Honeypot betreiben. Bis der Angreifer nach einem erfolgreichen Login wieder kommt vergeht mehr als ein Tag.

Falls noch jemanden mein Setup interessiert:

OpenBSD 4.0 in Standardinstallation ohne comp und games Pakete.

Zusätzlich als Pakete installiert waren: bash, vim, MySQL und PHP.

An Diensten waren SSH, Apache und MySQL aktiv.

Der Apache-Server war so präpariert, als wäre es ein vergessener Testserver mit PHP und MySQL (um den Eindruck beim Angreifer zu erwecken und um gleichzeitig etwas anzubieten)

Das ganze hinter einer OpenBSD Firewall in einem eigenen Subnetz in dem sich nur exklusiv dieser Rechner befand. Aus dem Internet wurden Verbindungen auf die beiden Ports 22 und 80 weiter an den Honeypot gereicht. Der Honeypot kam selber nur auf den Zielport 80, sowie über den ftp-proxy der Firewall für FTP-Verbindungen raus. Damit konnte er nicht selber sofort wieder SSH-Scans durchführen und auch keinen Spam an Port 25 rausschicken.

Es waren ungefähr 2 Dutzend Dummy-Accounts eingerichtet, bei denen fast bei allen Username = Passwort gesetzt war. Beliebt zum reinkommen, waren z. B. die Accounts test und sales.

Das Root-Passwort sowie das für meinen eigenen User waren die einzigsten schweren nicht erratbaren Passwörter. Keiner der Dummyuser war in der wheel Gruppe. Root-Login per SSH war abgeschaltet in der sshd_config. Falls ein Angreifer trotzdem Root-Rechte erlangen sollte, habe ich die Logfiles mit dem sappnd Flag geschützt (Für die FreeBSDler die dies nicht über OpenBSD wissen: OpenBSD läuft per default im Securelevel 1, das Flag läßt sich also auch mit Root-Rechten nicht wieder entfernen). Zusätzlich habe ich auch noch den Kernel, sowie alles in /bin und /sbin, sowie in /usr/lib und die /usr/libexec/ld.so, sowie noch einige weitere Binarys in /usr/bin (wie etwa netstat und last) per schg Flag geschützt.

Für alle Dummy-Accounts habe ich die Bash als Loginshell gesetzt und dann ebenfalls die ~/.bash_history auf sappnd gesetzt um alle Befehle nachverfolgen zu können (bei den erfolgreichen Logins wurde aber kein einziger Befehl abgesetzt).

Achja: So ein Honeypot ist übrigens Streß: Man darf nicht zu lange außer Haus sein, sonst sitzt einem immer die Sorge darum was für Blödsinn ein Hacker nun anstellen kann (vom eigenen Anschluß aus) immer im Genick.

Gruß
Reks30