Danke Danke:  0
Dislikes Dislikes:  0
Ergebnis 1 bis 10 von 10

Thema: Gefälschte Pakete in eine TCP/IP Verbindung einschleusen

  1. #1

    Registriert seit
    14.11.17
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    3

    Standard Gefälschte Pakete in eine TCP/IP Verbindung einschleusen

    Anzeige
    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?

  2. #2
    Moderator Avatar von Chromatin
    Registriert seit
    30.06.08
    Danke (erhalten)
    34
    Gefällt mir (erhalten)
    857

    Standard

    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.?
    Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

    Habo Blog - http://blog.hackerboard.de/

  3. #3

    Registriert seit
    14.11.17
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    3

    Standard

    Zitat Zitat von Chromatin Beitrag anzeigen
    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.


    Zitat Zitat von Chromatin Beitrag anzeigen
    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.
    Geändert von markb1980 (09.08.18 um 12:25 Uhr)

  4. #4
    Moderator Avatar von Chromatin
    Registriert seit
    30.06.08
    Danke (erhalten)
    34
    Gefällt mir (erhalten)
    857

    Standard

    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
    Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

    Habo Blog - http://blog.hackerboard.de/

  5. #5

    Registriert seit
    14.11.17
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    3

    Standard

    Zitat Zitat von Chromatin Beitrag anzeigen
    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.
    Geändert von markb1980 (09.08.18 um 14:08 Uhr)

  6. #6
    Moderator Avatar von Chromatin
    Registriert seit
    30.06.08
    Danke (erhalten)
    34
    Gefällt mir (erhalten)
    857

    Standard

    Willst du Pakete in eine (TCP/IP) Session einbringen, muss du auch zwischen(in) der Session sitzen -> man in the middle.
    Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

    Habo Blog - http://blog.hackerboard.de/

  7. #7

    Registriert seit
    14.11.17
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    3

    Standard

    Zitat Zitat von Chromatin Beitrag anzeigen
    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!

  8. #8
    Moderator Avatar von Chromatin
    Registriert seit
    30.06.08
    Danke (erhalten)
    34
    Gefällt mir (erhalten)
    857

    Standard

    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.
    Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

    Habo Blog - http://blog.hackerboard.de/

  9. #9

    Registriert seit
    25.12.09
    Danke (erhalten)
    2
    Gefällt mir (erhalten)
    31

    Standard

    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.
    "There are only 10 types of people in the world: Those who understand binary, and those who don't."

  10. #10

    Registriert seit
    14.11.17
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    3

    Standard

    Anzeige
    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.
    Geändert von markb1980 (14.08.18 um 08:37 Uhr)

  11. Gefällt mir @night@, bitmuncher liked this post

Ähnliche Themen

  1. Woher weiss ich ob ich eine VPN verbindung auf dem Router habe??
    Von teli im Forum Network · LAN, WAN, Firewalls
    Antworten: 3
    Letzter Beitrag: 29.08.12, 20:30
  2. Antworten: 8
    Letzter Beitrag: 27.01.12, 21:28
  3. 1 Mio. gefälschte CPUs von AMD im Umlauf?
    Von magic im Forum News & Ankündigungen
    Antworten: 0
    Letzter Beitrag: 03.01.05, 22:05
  4. Antworten: 1
    Letzter Beitrag: 15.08.04, 18:40
  5. Antworten: 2
    Letzter Beitrag: 25.11.02, 21:17

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •