Man-in-the-Middle: Problem beim weiteren forwarden der Frames

[te one]

Hallo,

möchte gerade in meinem privaten Netzwerk eine Man-in-the-middle Attacke nachstellen.
Habe hierfür mal Cain&Abel ausprobiert.
Die fehlerhafte ARP-Eintragung klappt auch super. Aber das ganze funktioniert nur, solange ich mit dem Opfer-PC im internen LAN bleibe.

Habe die Frames mal mitgesnifft. Hier eine grobe Darstellung (Sniffer läuft auf dem Angreifer):
Ist jetzt einfach mal immer ein Ping.

Angreifer=Man in the middle
Opfer=Mein Testrechner (falsche MAC-Zuordnung des Standardgateways)
Ziel=beliebige IP zum anpingen

Ziel im internen Netz:

1. Ping Request (Opfer-IP zu Ziel-IP) (Opfer-MAC zu Angreifer-MAC)
2. Ping Request (Opfer-IP zu Ziel-IP) (Angreifer-MAC zu Ziel-MAC)
1. Ping Reply (Ziel-IP zu Opfer-IP) (Ziel-MAC zu Angreifer-MAC)
2. Ping Reply (Ziel-IP zu Opfer-IP) (Angreifer-MAC zu Opfer-MAC)

Das ganze funktioniert also.

Wenn das Ziel im Internet ist, sehe ich nur folgendes Paket:

1. Ping Request (Opfer-IP zu Ziel-IP) (Opfer-MAC zu Angreifer-MAC)

Das müsste doch normal dann auch gehen...Verstehe ich nicht so ganz?!
Schon der zweite Ping Request (von Angreifer zu Gateway) taucht nicht auf...

Jemand eine Idee woran das liegt?

 

[Mumpitzelchen]

Ich hab jetzt keine Ahnung von deinem Exploit, aber: ARP ist nicht routbar. Ein Exploit der auf ARP Poisoning beruht kann deswegen normalerweise nicht im Internet funktionieren. ARP ist im wesentlichen ein Layer 2 Protokoll.

 

[DonConto]

Dir ist klar, dass die Ziel-Mac das Default Gateway sein muss wenn das Ziel im Internet ist?

Edit: Die MAC Table vom Switch wäre jetzt interessant. Könnte es sein, dass dein Gateway dir dazwischen redet und deine gespoofte Adresse wieder "überschreibt"?

So aus dem Kopf ist das schwer nachzustellen

 

[te one]

@Mumpitzelchen:
Ein Routing von ARP ist ja garnicht nötig.
Das müsste ja so laufen:
Opfer fragt Angreifer
Angreifer fragt Gateway
Gateway fragt Internet/Webserver
--> Rückweg genau andersrum
Gateway muss dann also Angreifer das Paket schicken, bin mir nicht sicher ob das schon gehen würde. Lässt sich aber noch nicht testen, siehe unten beschrieben

@DonConto:
Ja, das ist mir bewusst.
Das erste Paket muss aber ja erstmal vom Opfer zum Angreifer. Das passt also.
Nun müsste aber wieder eines von Angreifer verschickt werden (ans Standardgateway). Nur da geht ja schon garkeines raus, weshalb ich auf ein Softwareproblem tippe...

Wenns gehen würde, müssten folgende 4 Pakete sichtbar sein:

1. Ping Request (Opfer-IP zu Ziel-IP) (Opfer-MAC zu Angreifer-MAC) //<<das hier geht ja noch
2. Ping Request (Opfer-IP zu Ziel-IP) (Angreifer-MAC zu Gateway-MAC) //<<das müsste die Software dann losschicken, geht schon nicht mehr
//Weg im Internet
1. Ping Reply (Ziel-IP zu Opfer-IP) (Gateway-MAC zu Angreifer-MAC)
2. Ping Reply (Ziel-IP zu Opfer-IP) (Angreifer-MAC zu Opfer-MAC)

Die MAC-Table vom Gateway wäre interessant, aber da selbst der zweite (gespoofte) Ping Request nicht rausgeht, kommt das Gateway ja normal garnicht zum Einsatz...Das bekommt ja nie ein Frame/Paket ab...

ARP-Table am Opferrechner hatte während der Tests immer die falsche MAC drin, das passt also (hab es auch mehrfach wiederholt)

 

[DonConto]

Stimmt, wenigstens das Ausgangspaket müsstest du sehen. Irgendwas scheint den Angreifer PC zu stören. Hast du mal ein anderes Protokoll ausprobiert?

Ich habe das bei mir nachgestellt. Da funktioniert es. Hmm...

Edit: Ich paste mal das was Wireshark mir erzählt hat:

73	4.011649	192.168.0.20	8.8.8.8			ICMP	74	AsustekC_b3:54:e6	Vmware_f5:28:10		Echo (ping) request  id=0x0001, seq=1740/52230, ttl=128
74	4.011796	192.168.0.20	8.8.8.8			ICMP	74	Avm_8b:21:d7		AsustekC_b3:54:e6	Echo (ping) request  id=0x0001, seq=1740/52230, ttl=128
75	4.029042	8.8.8.8			192.168.0.20	ICMP	74	AsustekC_b3:54:e6	Avm_8b:21:d7		Echo (ping) reply    id=0x0001, seq=1740/52230, ttl=55
76	4.029169	8.8.8.8			192.168.0.20	ICMP	74	Vmware_f5:28:10		AsustekC_b3:54:e6	Echo (ping) reply    id=0x0001, seq=1740/52230, ttl=55

Die Asus MAC ist der Angreifer. VMWare ist das Opfer (192.168.0.20). AVM ist das Gateway. Gepingt wird der Google DNS (8.8.8.8).

Edit2: Welches Ziel hast du denn in deinem ersten Versuch (im lokalen LAN) angepingt? War da auch eine dritte IP im Spiel oder hast du den Angreifer gepingt?

 

[te one]

Bis jetzt nur ICMP (Ping) im Wireshark... HTTP läuft aber auch nicht durch (wenn man halt ins Internet will...)
Ziel im lokalen Netz war (um es möglichst weit zu testen) das Standardgateway

Wenn es funktioniert sieht es bei mir so aus wie bei dir. Nur sobald ich ins Internet möchte, klappt es eben nicht. (Da sehe ich nur das erste Paket)
Meine externe IP zu pingen hab ich gerade auch probiert. Geht auch nicht.

Cain&Abel nochmal neu installieren? Denn normal ist ja jetzt die Software dran...

Wenn ich Cain starte (also den Sniffer) sagt er mir außerdem, dass "TCP Large/Giant Send Offloading" aktiviert ist. Aber das scheint nur bei SSL-Attacken Probleme zu machen (laut Beschreibung).

Was ich auch sehe (wo ich grad mal Wireshark offen habe): Immerzu Broadcasts...Eine IP (kA welches Gerät, antwortet nicht auf pings) sucht immer die 0.0.0.0...
Aber das ist ein anderes Problem.

Zurück zum Thema: Neuinstallation? Muss ja eigentlich so gehen...

 

[DonConto]

Hab ich jetzt auch keine Idee mehr. Wenn du sonst keine Auffälligkeiten im Sniffer siehst..mir fällt kein Grund ein warum dein PC nichts schickt. Außer er kennt das Gateway nicht, aber das kann ja nicht sein.

 

[te one]

Hab gerade nochmal folgendes probiert:
- Neuinstallation Cain&Abel auf Angreifer --> Half nicht
- Wireshark auf Opfer --> Er verschickt nur diesen einen Frame und der ist passend an den Angreifer addressiert (MAC)

Das einzige was mir wieder auffällt sind dubiose Broadcasts:
Der Angreifer sendet Broadcast-Frames (Quelle: Angreifer-MAC | Ziel: Broadcast-MAC).
Hierbei fragt er wo sich 0.0.0.0 befindet (und, dass dies an 192.168.178.11 gemeldet werden soll).

Ich glaube so langsam komme ich dem ganzen näher.
In Cain muss ich ja in Interface auswählen.
Dort habe ich die Auswahl zwischen einem mit der 192.168.178.11 (dort soll sich ja auch die 0.0.0.0 melden) und einem mit 192.168.178.100
Problem hierbei:
Die 192.168.178.100 ist mein WLAN-Interface. Das hab ich bei den Tests sowieso aus.
Mein LAN-Interface hat eigentlich die 192.168.178.25 (also LAN am Angreifer) und nicht diese dubiose 11.
Auf der 11 bekomme ich auch per Ping keine Antworten.
Irgendwann hat der wohl mal irgendwie die 11 gesagt bekommen...
Aber warum sucht er überhaupt einer einer Pseudo-0.0.0.0? Gateway für das Interface ist eingetragen und man sieht es auch in Cain

 

[DonConto]

Das sieht mir jetzt aber eher nach verwurschtelten Netzwerksettings bei dir aus. Passiert ja gerne mal wenn man viel experimentiert.

Noch eine Möglichkeit wieso das Szenario nicht funktionieren könnte wäre, dass dein Gateway nicht auf die GARP Messages (http://de.wikipedia.org/wiki/Address_Resolution_Protocol#Gratuitous_ARP) reagiert. Das somit nicht erfolgreiche Spoofing könnte Grund dafür sein, dass der Ping bei dir gar nicht erst raus geht. Denn ohne erfolgreiches Spoofing macht es ja keinen Sinn das Paket wieder zu versenden. Cain weiß ja nicht wohin.

Nur so als Anmerkung: Soweit ich mich erinnern kann werden GARP Pakete bei manchen Tools nicht immer als Broadcast gesendet sondern direkt an die Zieladresse. Das macht man damit andere im Netz nicht mitbekommen, dass da was nicht ganz sauber ist (würden sie ja bei einem Broadcast). Ob Cain das auch so macht weiß ich jetzt nicht. Da du ja was von einem Broadcast geschrieben hast, könnte es natürlich sein, dass Cain keine direkten GARP Pakete versendet. Vielleicht hilft dir die Anmerkung zum Troubleshooting.

Von welchem Hersteller ist das Gateway? Kann man da debuggen? So ganz "blind" ist die Fehlersuche recht mühsam

 

[te one]

Das Problem dritt doch schon vor dem Gateway auf. Die Paket wird nie am Gateway ankommen, da der Angreifer das erhaltene Paket nicht dorthin leitet. Der Fehler ist also noch vor dem Gateway zu suchen.

Habe auf dem Angreifer Win7 64Bit im Einsatz. Vielleicht muckt es deshalb!?

Werde das mit GARP nochmal überdenken, aber bin schwer der Meinung, dass das Problem noch davor liegt...
Gateway ist von AVM eine Fritzbox mit Standardfirmware. Große Debugmöglichkeit hat man also (meines Wissens nach) nicht.
Aber wie gesagt kommt ja noch nichtmal ein Paket zum Gateway. Die Suche dort wird also nichts bringen.

Zu meinen verwurschtelten Netzwerksettings: Ich wüsste mal gerne woher Cain die 192.168.178.11 bekommt, wenn die mein Angreifer doch garnicht hat!?
HA! Ich weiß wer die 11 in meinem Netz hat.
Ich habe einen alten Rechner, den ich gaaanz selten mal als Server anschalte (DER IST ABER NICHT AN!). Und der hat fest die 11 vergeben. Ursprünglich wollte ich ihn als Opfer nehmen, den hat Cain aber nicht im Netz gefunden...

Grad nochmal getest: Die Broadcasts mit dem "Who has 0.0.0.0? Tell 192.168.178.11" werden vom Angreifer verschickt, sobald ich das ARP-Posoning starte. Ich durchsuche jetzt mal die Registry und gucke ob ich irgendwie die 11 ändern kann. Denn die hab ich einfach nicht...

Ergänzung (30. März 2012)

Konnte das Problem eben lösen.
Und zwar war folgendes zur Lösung nötig:
Unter HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\{Interface-ID}\Parameters\Tcpip gibt es den Wert "IPAddress". Dort steht bei mir immer die zuletzt vergebene IP drin. Wenn ich die IP also z.B. von 192.168.178.99 auf 192.168.178.100 ändere, steht dort die 99 obwohl ich aktuell die 100 habe. Habe den dortigen Wert nun auf die wirklich aktuelle IP geändert. Schon gehts...

Habe noch einige TCP Retransmissions und DUP ACKs jetzt im Netz, aber zumindest läuft es erstmal.
Problem war also entweder Windows (weil er das dort nicht ändert) oder Cain, da er auf einen anderen Wert zugreifen müsste.