Gefälschte Pakete in eine TCP/IP Verbindung einschleusen

#1
Hallo,

ich habe einen Paketsniffer mit Python/Scapy gebaut - die Arbeitsweise ist wie folgt:

Paket vom Client an den Server abfangen und kopieren
Auf ACK-Paket nach der Serverantwort warten und daraus seq- und ack-Nummer extrahieren
Paketinhalt verändern, seq- und ack-Nummer einfügen und dann Checksumme aktualisieren
Dann das gefälschte Paket absenden

Hier die Pakete:

Code:
ORIGINAL-PACKET:

###[ Ethernet ]### 
  dst       = 40:f0:2f:c7:90:20
  src       = 00:1f:5b:34:45:3c
  type      = 0x800
###[ IP ]### 
     version   = 4
     ihl       = 5
     tos       = 0x0
     len       = 42
     id        = 34084
     flags     = DF
     frag      = 0
     ttl       = 64
     proto     = tcp
     chksum    = 0x0
     src       = 192.168.1.7
     dst       = 192.168.1.38
     \options   \
###[ TCP ]### 
        sport     = 4430
        dport     = 49710
        seq       = 1273911897
        ack       = 3316338221
        dataofs   = 5
        reserved  = 0
        flags     = PA
        window    = 8192
        chksum    = 0x839a
        urgptr    = 0
        options   = []
###[ Raw ]### 
           load      = 'oo'

ACK-PACKET:

###[ Ethernet ]### 
  dst       = 40:f0:2f:c7:90:20
  src       = 00:1f:5b:34:45:3c
  type      = 0x800
###[ IP ]### 
     version   = 4
     ihl       = 5
     tos       = 0x0
     len       = 40
     id        = 53843
     flags     = DF
     frag      = 0
     ttl       = 64
     proto     = tcp
     chksum    = 0x0
     src       = 192.168.1.7
     dst       = 192.168.1.38
     \options   \
###[ TCP ]### 
        sport     = 4430
        dport     = 49710
        seq       = 1273911899
        ack       = 3316338314
        dataofs   = 5
        reserved  = 0
        flags     = A
        window    = 8189
        chksum    = 0x8398
        urgptr    = 0
        options   = []


SPOOFED-PACKET:

###[ Ethernet ]### 
  dst       = 40:f0:2f:c7:90:20
  src       = 00:1f:5b:34:45:3c
  type      = 0x800
###[ IP ]### 
     version   = 4
     ihl       = 5
     tos       = 0x0
     len       = 45
     id        = 58454
     flags     = DF
     frag      = 0
     ttl       = 64
     proto     = tcp
     chksum    = 0x0
     src       = 192.168.1.7
     dst       = 192.168.1.38
     \options   \
###[ TCP ]### 
        sport     = 4430
        dport     = 49710
        seq       = 1273911899
        ack       = 3316338314
        dataofs   = 5
        reserved  = 0
        flags     = PA
        window    = 8192
        chksum    = 0x466d
        urgptr    = 0
        options   = []
###[ Raw ]### 
           load      = 'close'
Der Server empfängt das gefälschte Paket - reagiert aber nicht darauf...
Wenn der nächste legitime Befehl von Client kommt wird dessen Paket in Wireshark sogar als Retransmission gewertet - witzigerweise reagiert darauf der Server mit ACK und Antwort.

Was übersehe ich hierbei bzw. warum reagiert der Server nicht auf das Paket?
 

Chromatin

Moderator
Mitarbeiter
#2
Ein bisschen genauer musst du schon werden.
Was ist denn dein Plan? Den Stream bei einem bestimmten Paket "unterbrechen", das originale wegwerfen und das gefälschte stattdessen schicken?
Wie sieht dein aktuelles Setup dafür aus, womit baust die bridge usw.?
 
#3
Was ist denn dein Plan? Den Stream bei einem bestimmten Paket "unterbrechen", das originale wegwerfen und das gefälschte stattdessen schicken?
Jein... Es reicht mir mitzulesen bis ich die seq- und ack-Nummern hab und dann einen Befehl in einem gefälschten Paket zu senden. Im Grunde müsste ich nicht mal die Antwort sehen. Es geht quasi rein darum zu zeigen, dass es machbar ist ein gefälschtes Paket in eine stehende Verbindung hineinzuschmuggeln.


Wie sieht dein aktuelles Setup dafür aus, womit baust die bridge usw.?
Derzeit für den "Proof-of-Concept" nutze ich 2 Rechner - Server und Client wobei der Sniffer am Client mit läuft. Also baue ich derzeit auf der selben Kiste mit Scapy gefälschte Pakete von der auch die legitimen Befehle kommen würden.
 
Zuletzt bearbeitet:
#5
Du musst schon eine Bridge/Transparenten Proxy für sowas haben. Check mal diesen Artikel über Trudy: How to modify general TCP/IP traffic on the fly with Trudy
Ich modifiziere nichts on the fly... Ich warte bis ein Befehl abgearbeitet ist und sende dann ein Paket mit einem neuen Befehl so als würde der Client einen weiteren Befehl senden! Ich will weder die gesamte Kommunikation als Proxy durchschleusen noch irgendwie etwas darin verändern.

Einfach nur ein Paket mit einem weiteren Befehl senden bevor es der eigentliche Client macht...

Ich sehe jetzt keinen Grund warum dieser Ansatz nicht klappen sollte außer ich übersehe etwas. Falls ich was übersehe sagt mir bitte was genau.
 
Zuletzt bearbeitet:

Chromatin

Moderator
Mitarbeiter
#6
Willst du Pakete in eine (TCP/IP) Session einbringen, muss du auch zwischen(in) der Session sitzen -> man in the middle.
 
#7
Willst du Pakete in eine (TCP/IP) Session einbringen, muss du auch zwischen(in) der Session sitzen -> man in the middle.
Ich sitze ja ohnehin am Client und lese alles mit... Warum sollte ich also zusätzlich noch lokal einen Proxy oder sonstwas aufbauen? Und nein, ich will die Pakete nicht on the fly verändern nur dem legitimen Client zuvorkommen.

Nochmal ich bekomme die richtigen seq- und ack-Nummern und bau die in das Paket ein. Dennoch scheint etwas am Paket falsch zu sein und es wird nicht verarbeitet!
 

Chromatin

Moderator
Mitarbeiter
#8
Ich sage dass du zu wenig Input lieferst. Wenn die Session zwischen Client und Server schon beendet ist (RST), kannst du nicht einfach ein Paket hinterher schieben (aka anderen "Befehl") senden und davon ausgehen dass der Server das bearbeitet.
So interpretiere ich das. Wenn die Session noch lebt, sieht's anders aus.
Hilfreich wäre ein Dump der Kommunikation (ohne payload) vom Aufbau bis zum senden von deinem Paket.
 
#9
Mich wundert es ein bisschen, dass die Ethernet-Frames vom Daten- und Ack-Paket dieselben Adressdaten haben:
Code:
ORIGINAL-PACKET:

###[ Ethernet ]### 
  dst       = 40:f0:2f:c7:90:20
  src       = 00:1f:5b:34:45:3c
  type      = 0x800

...

ACK-PACKET:

###[ Ethernet ]### 
  dst       = 40:f0:2f:c7:90:20
  src       = 00:1f:5b:34:45:3c
  type      = 0x800
Das ACK-Paket sollte ja eigentlich vom Server kommen.
 
#10
Danke, hat sich erledigt... Ich hab die TCP-Prüfsumme gelöscht und neu berechnet aber die sch*** Prüfsumme vom IP-Protokoll übersehen. Bin am WE selber draufgekommen. Aber erst als ich im Wireshark-Dump Layer für Layer und Feld für Feld vergleichen habe.

Scapy scheint einen kleinen Bug zu haben. Im IP-Layer wird 0x0 für die Checksumme aufgezeichnet und angezeigt... Das Original-Paket enthält allerdings eine Checksumme und nicht 0x0! Wenn ich es aufzeichne dann geht die Checksumme verloren und das gespoofte Paket hatte somit auch 0x0 als Prüfsumme. Vergleicht man die Ausgaben von Scapy dann scheinen beide 0x0 zu haben in Wireshark sieht man, dass da nicht stimmt.

Eventuell hilft das jemanden weiter der das gleiche Problem mit Scapy hat...

Aber klar, die PCAP-Datei hätte ich von Anfang an anhängen können.

@night@

Klar und dann die Antwort und dann das ACK vom Client und das brauche ich.
 
Zuletzt bearbeitet:
Oben