Netzwerk-Analyse mit Wireshark: FTP unter der Lupe


    Tags: , ,

    FTP-Passwort in Wireshark auslesenAls Basis für diese Ana­lyse dient eine FTP-Sitzung, bei der wir be­wusst auf den ver­schlüssel­ten Modus ohne TLS oder SSH/Public-Key ver­zichten. Dies gibt uns Gelegen­heit zu demon­strieren, wie ein­fach Hacker mit Wireshark solche Infor­mationen ab­fangen und bei­spiels­weise an das FTP-Pass­wort ge­langen können.

    Bevor wir uns mit zweck­gebundenen Analysen befassen, bleiben wir vorerst noch bei der TCP-Fluss­steuerung, diesmal aber im Rahmen der Daten­übertragung. Da nun auch Daten transferiert werden, wird die Berechnung der Sequence- und Acknowledgment-Nummern mit realen 32-Bit-Werten aufwändiger.

    Berechnung von SEQ und ACK

    Wer deshalb Wireshark wieder auf relative Sequenz­nummern zurück­setzt, darf trotzdem nicht vergessen, dass Client und Server in Wahrheit mit zufälligen und daher nicht identischen Sequenznummern starten.

    Werfen wir jetzt ein Blick auf die weitere Entwicklung der Sequenz­nummer in Rahmen der Daten­übertragung. Grund­sätzlich gilt, dass sich die vom Client verwendete Sequence-Number zusammen­setzt aus der vorherigen Sequence-Number plus der Anzahl der vom Client im entsprechenden Abschnitt versendeten Daten-Bytes., also

    SEQ Client = alte SEQ Client + Anzahl Datenbytes Client

    Die Acknowledg­ment-Number des Clients errechnet sich dagegen aus der Sequence-Number vom Server plus der Anzahl der Daten-Bytes, die der Server versendet hat.

    ACK Client = SEQ Server + Anzahl Datenbytes Server

    Es handelt sich also bei der ACK-Nummer also um eine Art Prüfsumme, mit welcher der Server herausfindet, ob der Client tatsächlich alle vom Server gesendeten Daten empfangen hat.

    FTP-Mitschnitt untersuchen

    Überprüfen wir diesen Sachverhalt anhand des FTP-Mitschnitts und betrachten dazu die Zeilen 14 bis 17.

    Beginnen wir mit Zeile 14. Sie fragen sich, was davor passiert ist, also im Rahmen der Pakete 4 bis 13? Hier haben Client und Server erst einmal versucht, eine TLS-Verbindung auszu­handeln, was aber aufgrund der vor­bereiteten Konfi­guration von proftpd und Filezilla scheitern musste.

    Da wir den Mit­schnitt­filter zudem nur auf den Ziel-Host 192.168.1.24 und nicht explizit auf das FTP-Protokoll beschränkt hatten, konnten sich zudem noch einige andere Pakete dazwischen­mogeln. Im Vergleich zum bloßen Handshake ist schon in der zusammen­fassenden Zeilen­ansicht zu erkennen, dass das "Protocol" nun FTP ist.

    Im FTP-Mitschnitt ist der Name des Users erkennbar

    In Zeile 14 übermittelt der Client dem Server dann den gewünschten User-Namen für die Anmeldung: "USER ftpuser". Im Detail-Fenster ist außerdem zu erkennen, dass die Sequenz­nummer des Clients inzwischen 3759279698 ist.

    Die "Next sequence Number" hingegen ist 3842592692, da der Client 14 Byte übertragen hat, was das Len-Feld verrät.

    Wir können die Länge durch Subtrahieren der beiden Sequenz-Nummern überprüfen, schalten dazu aber wieder auf relative Sequenz­nummern um und rechnen 35-21=14, was exakt dem Feld "Len:"  für die Länge der Nutz­daten entspricht.

    Einstellung für relative TCP-Sequenz­nummern in Wireshark

    Diese Anzeige taucht noch einmal auf in der letzten Zeile des Detail­fensters bei "TCP payload (14 bytes)" auf. Markiert man im mittleren Teil an genau dieser Stelle den Payload-Teil, dann werden die Nutzdaten auch unten in der hexa­dezimalen Roh­daten­ansicht angezeigt und tatsächlich ist hier, wie zu erwarten, das über­gebene Passwort "ftpuser" zu erkennen.

    Aus der unverschlüsselten Verbindung lässt sich das FTP-Passwort auslesen.

    TCP-Flusssteuerung als Schema

    Hier das Prüfsummen-Szenario noch einmal in einer Schema-Ansicht mit ange­nommenen relativen Sequenz­nummern. Da wir uns jetzt nicht mehr in der Phase des Verbindungs­aufbaus befinden, reden wir auch nicht mehr explizit von Client und Server, sondern von Host A und B. Der linke Host A startet mit SEQ 101, der rechte Host B mit 201.

    Noch mal zur Erinnerung: Grundsätzlich ist

    • die SEQ-Number, die Host A nutzt, immer die vorherige SEQ-Nummer plus die Anzahl der versendeten Daten-Bytes
    • und die ACK-Nummer von Host A die SEQ-Number von B plus die Anzahl der von B versendeten Daten-Bytes.
    TCP-SEQ-1 Host A setzt seine SEQ auf 101, seine ACK auf 201, also der Wert, den er als nächsten vom Host B als SEQ erwartet, und sendet dann 100 Byte Daten. Zudem ist das ACK-Flag gesetzt, was Host B signalisiert, dass nun ein Wert kommt, den B überprüfen soll (Prüfsumme).
    TCP-SEQ-2 Host B verwendet nun, wie von A erwartet, die  SEQ 201, weil dies seine aktuelle SEQ ist. Zudem muss B nun seine ACK so setzten, dass sie die nächste erwartete SEQ von A enthält, also nach der Formel vorherige SEQ von A + Anzahl der von A gesendeten Datenbytes. Das sind 101 + 150 = 251. Das ist wiederum der Wert, den Host B als nächstes von Host A als SEQ erwartet. Host B sendet nun 200 Bytes Daten.
    TCP-SEQ-3 Dass Host B 200 Bytes Daten versendet, bedeutet, dass Host A nun als ACK die alte SEQ von B + die Anzahl der versendeten Bytes, also 201+200=401 verwendet. Die SEQ, die A nun verwendet, ist genau die, die er vorher als ACK vom Host B zurück­gespiegelt be­kommen hat, also 251, da ja Host B die 150 Bytes Daten korrekt erhalten hat. Nun sendet A seinerseits wieder 100 Bytes Daten.
    TCP-SEQ-4 Das wiederum hat zur Folge, dass Host B nun eine ACK von 251 (SEQ A) + 100 Byte = 351 verwendet. Da er seiner­seits vorher 200 Byte Daten versendet hat, setzt er seine neue SEQ auf SEQ B (alt) + 200 = 201 +200 = 401 und versendet wieder 200 Bytes an Daten.

    Keine Kommentare