TCP IP Paket einschleusen

Hallo.

Ich habe einen relativ einfachen Server und einen kleinen Sniffer geschrieben, der auf die Pakete lauscht und dann ein weiteres Paket nachschieben soll. Soweit sogut... Es klappt und auch in Wireshark sieht alles richtig aus (Sequenznummer, ACK-Nummer, etc.)

<bound method Packet.show of <Ether  dst=40:f0:2f:c7:90:20 src=00:1f:5b:34:45:3c type=0x800 |<IP  version=4 ihl=5 tos=0x0 len=43 id=59649 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=1273911837 ack=3316335839 dataofs=5 reserved=0 flags=PA window=8192 chksum=0x839b urgptr=0 options= |<Raw  load='bla' |>>>>>  

Sent 1 packets.
<bound method Packet.show of <Ether  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=59649 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=1273911840 ack=3316335933 dataofs=5 reserved=0 flags=PA window=8192 chksum=0x839b urgptr=0 options= |<Raw  load='close' |>>>>>  

Das Problem ist nur, dass Win 10 nicht auf das Paket reagiert... ich bekomme kein ACK oder sonstwas... Woran kann das liegen?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 382598

Url: https://administrator.de/contentid/382598

Ausgedruckt am: 13.11.2024 um 12:11 Uhr

10 Kommentare

Neuester Kommentar

Firewall vermutlich?

Nein, glaube ich nicht sonst wären die Pakete ja garnicht erst angekommen. Aber auch das testweise deaktivieren der Win-Firewall hat nichts gebracht.

Hier nochmal 2 Pakete:

Original

###[ 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        = 17627
     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       = 1273911848
        ack       = 3316336534
        dataofs   = 5
        reserved  = 0
        flags     = PA
        window    = 8192
        chksum    = 0x839a
        urgptr    = 0
        options   = 
###[ Raw ]### 
           load      = 'la'  

Gefälschtes Paket

Sent 1 packets.
###[ 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        = 17627
     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       = 1273911862
        ack       = 3316337185
        dataofs   = 5
        reserved  = 0
        flags     = PA
        window    = 8192
        chksum    = 0x4afb
        urgptr    = 0
        options   = 
###[ Raw ]### 
           load      = 'close'  

Die ID-Nummer von IP ist ident - da könnte eventuell das Problem sein.

Schick doch mal ein Paket an einen Port von dem du weisst das da ein Dienst dahinter lauscht - weil 49710 kling random

Auf diesem Port empfängt das Script ja die ganze Zeit Daten...
Wenn ich im Client was eingebe wird das ganze Verarbeitet und das läuft auch über diesen Port.
Wenn ich ein Paket selber erstelle dann kommt das auch an wird aber nicht mit ACK bestätigt oder an das Script weitergereicht...

SYN Bit im TCP Header hast du gesetzt beim Verbindungsaufbau ?
https://de.wikipedia.org/wiki/Transmission_Control_Protocol#Verbindungsa ...
bzw.
https://de.wikipedia.org/wiki/Transmission_Control_Protocol#Aufbau_des_T ...

Hi. Ich glaube Ihr versteht nicht was ich zu tun versuche...

Ich will in eine bestehende Verbindung eingreifen und ein Paket einschleusen. Die Kommunikation zwischen Server und Client läuft problemlos ab...

Ich fange dann einen Paket mit einem Befehl ab, kopiere es, warte auf das nächste ACK-Paket um Sequensznummer und ACK-Nummer für den nächsten regulären Befehl abzufangen, manipuliere das Paket und den Inhalt und sende dann mein gefälschtes Paket mit dem close-Befehl...

Das ganze hat nichts mit Verbindungsaufbau, etc. zu tun - ich will mitten in der offenen TCP/IP Verbindung ein gefälschtes Paket einschleusen.

Server und Client kommunizieren die ganze Zeit völlig problemlos seit mehr als 20h mit der offenen Verbindung und trotz dutzender Versuche empfängt der Rechner das gefälschte Paket, reagiert aber nicht darauf. (Kein ACK von Server, keine Verarbeitung des Befehls)

Der nächste reguläre Befehl vom legitimen Client wird in Wireshark sogar als Retransmission erkannt und komischerweise verarbeitet... Also ACK vom Server, Verarbeitung des Befehls, Antwort vom Server und ACK vom Client

manipuliere das Paket und den Inhalt und sende dann mein gefälschtes Paket mit dem close-Befehl...

Aber mit der gleichen IP Adresse und auch der gleichen Mac ?
https://security.stackexchange.com/questions/181669/what-does-it-really- ...
Ansonsten scheitert das Prinzipien bedingt.

Ja natürlich. Ich fange sogar die nächste Sequenznummer und ACK-Nummer ab und verwende diese.

Mittlerweile habe ich sogar für das IP-Headerfeld ID-Nummer eine Zufallszahl generiert und verwendet damit diese auch nicht mehr ident sind. Langsam gehen mir die Ideen aus. Sogar die Checksummen sind angepasst und neu berechnet.

Schau bitte bei den 2 Paketen, die ich angehängt habe...
1 = Original dann kommt "Sent 1 packets." und 2 = gefälschtes Paket
... Ich schreib es nochmal drüber...

Kann auch gerne eine PCAP-Datei zur Verfügung stellen wenn Ihr wollt...

Hat sich erledigt... Ich hatte die TCP-Header Prüfsumme neu generiert aber vergessen auch die IP Header Prüfsummen neu zu generieren. Daher wurde das Paket nicht verarbeitet!

Warum allerdings in der Ausgabe 0x0 stand anstatt der eigentlichen Prüfsumme ist eine andere Frage - scheinbar ein kleiner Bug in dieser Version von Scapy!

Dem ist sicher so !
0x0 steht da immer wenn die Prüfsumme OK ist. Sie wird nur ausgewiesen wenn sie NICHT OK ist, also ein Fehler vorhanden ist.
Solltest du mal einen Bug Report bei Scapy öffnen