pd.edv
Aug 07, 2018, updated at Aug 13, 2018 (UTC)
view3213
view10
0
Goto Top

TCP IP Paket einschleusen

GermansolvedQuestionLAN, WAN, WirelessNetworks
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?
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 382598

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

Printed on: April 19, 2024 at 10:04 o'clock

10 Comments
Latest comment
Goto Top
Member: falscher-sperrstatus
falscher-sperrstatus Aug 07, 2018 at 23:20:19 (UTC)
Goto Top
Firewall vermutlich?
Member: pd.edv
pd.edv Aug 07, 2018, updated at Aug 08, 2018 at 10:51:37 (UTC)
Goto Top
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.
Member: NetzwerkDude
NetzwerkDude Aug 08, 2018 at 07:20:40 (UTC)
Goto Top
Schick doch mal ein Paket an einen Port von dem du weisst das da ein Dienst dahinter lauscht - weil 49710 kling random
Member: pd.edv
pd.edv Aug 08, 2018 at 07:59:06 (UTC)
Goto Top
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...
Member: aqui
aqui Aug 08, 2018 at 10:15:22 (UTC)
Goto Top
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 ...
Member: pd.edv
pd.edv Aug 08, 2018 updated at 10:48:27 (UTC)
Goto Top
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
Member: aqui
aqui Aug 08, 2018 at 10:48:12 (UTC)
Goto Top
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.
Member: pd.edv
pd.edv Aug 08, 2018 updated at 11:08:32 (UTC)
Goto Top
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...
Member: pd.edv
pd.edv Aug 13, 2018 updated at 20:28:37 (UTC)
Goto Top
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!
Member: aqui
aqui Aug 16, 2018 at 08:38:11 (UTC)
Goto Top
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 face-wink
GermansolvedQuestionLAN, WAN, WirelessNetworks
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 3 CommentsAlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment