Couper une connexion TCP qui ne m'appartient pas
Le
nospam
Bonjour,
J'essaye de faire un programme qui coupe la connexion tcp entre ma
machine et n'importe quelle autre, en me basant sur l'idée du "double
RST" du créateur de "TCP cutter" (http://www.lowth.com/cutter)
Le problème de base etant que n'etant pas "au milieu" de la session,
il faut s'envoyer un RST à soi même en usurpant l'identité de la
machine distante.
Mon problème est le suivant :
2 machines : Un EXPEDITEUR (qui veut mettre fin à la connection TCP
qu'il a avec la CIBLE) et la CIBLE
EXPEDITEUR : 192.168.1.3
CIBLE : xx.xx.xx.xx.
et voila le pb :
15:11:59.369482 192.168.1.3.33254 > xx.xx.xx.xx.imaps: F [tcp sum ok]
0:0(0) win 0 (DF) (ttl 253, id 0, len 40)
15:11:59.372507 xx.xx.xx.xx.imaps > 192.168.1.3.33254: . [tcp sum ok]
1589:1589(0) ack 461 win 6432 <nop,nop,timestamp 163410425 1403391>
(DF) (ttl 62, id 40208, len 52)
15:11:59.373290 192.168.1.3.33254 > xx.xx.xx.xx.imaps: R [tcp sum ok]
2365895080:2365895080(0) win 0 (DF) (ttl 253, id 0, len 40)
15:11:59.373699 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
15:12:06.073374 192.168.1.3.33254 > xx.xx.xx.xx.imaps: P [tcp sum ok]
461:490(29) ack 1589 win 8870 <nop,nop,timestamp 1406204 163410425>
(DF) (ttl 64, id 39495, len 81)
15:12:06.076633 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
decryptage ;)
1) envoi FIN pour trouver numéro de sequence :
15:11:59.369482 192.168.1.3.33254 > xx.xx.xx.xx.imaps: F [tcp sum ok]
0:0(0) win 0 (DF) (ttl 253, id 0, len 40)
2) reponse de la cible : ACK avec bon numéro de sequence :
15:11:59.372507 xx.xx.xx.xx.imaps > 192.168.1.3.33254: . [tcp sum ok]
1589:1589(0) ack 461 win 6432 <nop,nop,timestamp 163410425 1403391>
(DF) (ttl 62, id 40208, len 52)
3) envoi Reset à la cible (avec le bon numéro de sequence)
conséquence, la cible ferme le socket de son coté:
15:11:59.373290 192.168.1.3.33254 > xx.xx.xx.xx.imaps: R [tcp sum ok]
2365895080:2365895080(0) win 0 (DF) (ttl 253, id 0, len 40)
4) envoi FAUX reset à l'expéditeur (c'est l'expéditeur qui a forgé ce
packet et se l'est envoyé, grace aux Raw Sockets) (devrait fermer
le socket du coté de l'expéditeur, mais ca ne marche pas) :
15:11:59.373699 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
5) tentative du logiciel d'ecrire dans le socket (alors que le paquet
precedent aurait du lui faire comprendre que le socket etait mort):
15:12:06.073374 192.168.1.3.33254 > xx.xx.xx.xx.imaps: P [tcp sum ok]
461:490(29) ack 1589 win 8870 <nop,nop,timestamp 1406204 163410425>
(DF) (ttl 64, id 39495, len 81)
6) Cible répond que socket fermé et ferme donc le socket du coté
expéditeur:
15:12:06.076633 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
packet 4 = packet 6 non ? alors pourquoi le quatre ne ferme pas le
socket auprès du logiciel, alors que le 6 oui ?
détail ascii :
15:16:03.029155 192.168.1.3.33264 > xx.xx.xx.xx.imaps: F [tcp sum ok]
0:0(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4510 0028 0000 4000 fd06 3f8f c0a8 0103
E..(..@?..
0x0010 xxxx xxxx 81f0 03e1 0000 0000 0000 0000
QP+E
0x0020 5001 0000 ebd1 0000 P.
15:16:03.032450 xx.xx.xx.xx.imaps > 192.168.1.3.33264: . [tcp sum ok]
1547:1547(0) ack 432 win 6432 <nop,nop,timestamp 163434791 1428906>
(DF) (ttl 62, id 47958, len 52)
0x0000 4500 0034 bb56 4000 3e06 432d xxxx xxxx
E..4.V@.>.C-QP+E
0x0010 c0a8 0103 03e1 81f0 04bb 7c74 a601 53be
.|t..S.
0x0020 8010 1920 75f7 0000 0101 080a 09bd d127
.u.'
0x0030 0015 cdaa .
15:16:03.032751 192.168.1.3.33264 > xx.xx.xx.xx.imaps: R [tcp sum ok]
2785104830:2785104830(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4510 0028 0000 4000 fd06 3f8f c0a8 0103
E..(..@?..
0x0010 xxxx xxxx 81f0 03e1 a601 53be 0000 0000
QP+ES..
0x0020 5004 0000 f20e 0000 P.
15:16:03.032760 xx.xx.xx.xx.imaps > 192.168.1.3.33264: R [tcp sum ok]
79395956:79395956(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4510 0028 0000 4000 fd06 3f8f xxxx xxxx
E..(..@?.QP+E
0x0010 c0a8 0103 03e1 81f0 04bb 7c74 0000 0000
.|t.
0x0020 5004 0000 6a9f 0000 Pj
15:16:06.658510 192.168.1.3.33264 > xx.xx.xx.xx.imaps: P [tcp sum ok]
432:461(29) ack 1547 win 8870 <nop,nop,timestamp 1430262 163434791>
(DF) (ttl 64, id 40850, len 81)
0x0000 4500 0051 9f92 4000 4006 5cd4 c0a8 0103
E..Q..@.@.\..
0x0010 xxxx xxxx 81f0 03e1 a601 53be 04bb 7c74
QP+ES|t
0x0020 8018 22a6 9384 0000 0101 080a 0015 d2f6
..".
0x0030 09bd d127 1703 0100 1890 5710 c450 b838
'W..P.8
0x0040 697e b447 cbaa 576b 5725 6f31 267d 2e9e
i~.G..WkW%o1&}..
0x0050 73 s
15:16:06.661649 xx.xx.xx.xx.imaps > 192.168.1.3.33264: R [tcp sum ok]
79395956:79395956(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4500 0028 0000 4000 fd06 3f8f xxxx xxxx
E..(..@?.QP+E
0x0010 c0a8 0103 03e1 81f0 04bb 7c74 0000 0000
.|t.
0x0020 5004 0000 6a9f 0000 0000 0000 0000 Pj
la seule différence que je vois c'est le nombre de 0 à la fin mais
bon ca a pas géné la cible, elle s'est bien fermée, pourquoi ca
generait l'expediteur ?
Est ce que j'interprète mal qq chose ? une erreur de base ? qq'un a
une idée ?
Merci
Florent
J'essaye de faire un programme qui coupe la connexion tcp entre ma
machine et n'importe quelle autre, en me basant sur l'idée du "double
RST" du créateur de "TCP cutter" (http://www.lowth.com/cutter)
Le problème de base etant que n'etant pas "au milieu" de la session,
il faut s'envoyer un RST à soi même en usurpant l'identité de la
machine distante.
Mon problème est le suivant :
2 machines : Un EXPEDITEUR (qui veut mettre fin à la connection TCP
qu'il a avec la CIBLE) et la CIBLE
EXPEDITEUR : 192.168.1.3
CIBLE : xx.xx.xx.xx.
et voila le pb :
15:11:59.369482 192.168.1.3.33254 > xx.xx.xx.xx.imaps: F [tcp sum ok]
0:0(0) win 0 (DF) (ttl 253, id 0, len 40)
15:11:59.372507 xx.xx.xx.xx.imaps > 192.168.1.3.33254: . [tcp sum ok]
1589:1589(0) ack 461 win 6432 <nop,nop,timestamp 163410425 1403391>
(DF) (ttl 62, id 40208, len 52)
15:11:59.373290 192.168.1.3.33254 > xx.xx.xx.xx.imaps: R [tcp sum ok]
2365895080:2365895080(0) win 0 (DF) (ttl 253, id 0, len 40)
15:11:59.373699 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
15:12:06.073374 192.168.1.3.33254 > xx.xx.xx.xx.imaps: P [tcp sum ok]
461:490(29) ack 1589 win 8870 <nop,nop,timestamp 1406204 163410425>
(DF) (ttl 64, id 39495, len 81)
15:12:06.076633 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
decryptage ;)
1) envoi FIN pour trouver numéro de sequence :
15:11:59.369482 192.168.1.3.33254 > xx.xx.xx.xx.imaps: F [tcp sum ok]
0:0(0) win 0 (DF) (ttl 253, id 0, len 40)
2) reponse de la cible : ACK avec bon numéro de sequence :
15:11:59.372507 xx.xx.xx.xx.imaps > 192.168.1.3.33254: . [tcp sum ok]
1589:1589(0) ack 461 win 6432 <nop,nop,timestamp 163410425 1403391>
(DF) (ttl 62, id 40208, len 52)
3) envoi Reset à la cible (avec le bon numéro de sequence)
conséquence, la cible ferme le socket de son coté:
15:11:59.373290 192.168.1.3.33254 > xx.xx.xx.xx.imaps: R [tcp sum ok]
2365895080:2365895080(0) win 0 (DF) (ttl 253, id 0, len 40)
4) envoi FAUX reset à l'expéditeur (c'est l'expéditeur qui a forgé ce
packet et se l'est envoyé, grace aux Raw Sockets) (devrait fermer
le socket du coté de l'expéditeur, mais ca ne marche pas) :
15:11:59.373699 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
5) tentative du logiciel d'ecrire dans le socket (alors que le paquet
precedent aurait du lui faire comprendre que le socket etait mort):
15:12:06.073374 192.168.1.3.33254 > xx.xx.xx.xx.imaps: P [tcp sum ok]
461:490(29) ack 1589 win 8870 <nop,nop,timestamp 1406204 163410425>
(DF) (ttl 64, id 39495, len 81)
6) Cible répond que socket fermé et ferme donc le socket du coté
expéditeur:
15:12:06.076633 xx.xx.xx.xx.imaps > 192.168.1.3.33254: R [tcp sum ok]
3960647341:3960647341(0) win 0 (DF) (ttl 253, id 0, len 40)
packet 4 = packet 6 non ? alors pourquoi le quatre ne ferme pas le
socket auprès du logiciel, alors que le 6 oui ?
détail ascii :
15:16:03.029155 192.168.1.3.33264 > xx.xx.xx.xx.imaps: F [tcp sum ok]
0:0(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4510 0028 0000 4000 fd06 3f8f c0a8 0103
E..(..@?..
0x0010 xxxx xxxx 81f0 03e1 0000 0000 0000 0000
QP+E
0x0020 5001 0000 ebd1 0000 P.
15:16:03.032450 xx.xx.xx.xx.imaps > 192.168.1.3.33264: . [tcp sum ok]
1547:1547(0) ack 432 win 6432 <nop,nop,timestamp 163434791 1428906>
(DF) (ttl 62, id 47958, len 52)
0x0000 4500 0034 bb56 4000 3e06 432d xxxx xxxx
E..4.V@.>.C-QP+E
0x0010 c0a8 0103 03e1 81f0 04bb 7c74 a601 53be
.|t..S.
0x0020 8010 1920 75f7 0000 0101 080a 09bd d127
.u.'
0x0030 0015 cdaa .
15:16:03.032751 192.168.1.3.33264 > xx.xx.xx.xx.imaps: R [tcp sum ok]
2785104830:2785104830(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4510 0028 0000 4000 fd06 3f8f c0a8 0103
E..(..@?..
0x0010 xxxx xxxx 81f0 03e1 a601 53be 0000 0000
QP+ES..
0x0020 5004 0000 f20e 0000 P.
15:16:03.032760 xx.xx.xx.xx.imaps > 192.168.1.3.33264: R [tcp sum ok]
79395956:79395956(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4510 0028 0000 4000 fd06 3f8f xxxx xxxx
E..(..@?.QP+E
0x0010 c0a8 0103 03e1 81f0 04bb 7c74 0000 0000
.|t.
0x0020 5004 0000 6a9f 0000 Pj
15:16:06.658510 192.168.1.3.33264 > xx.xx.xx.xx.imaps: P [tcp sum ok]
432:461(29) ack 1547 win 8870 <nop,nop,timestamp 1430262 163434791>
(DF) (ttl 64, id 40850, len 81)
0x0000 4500 0051 9f92 4000 4006 5cd4 c0a8 0103
E..Q..@.@.\..
0x0010 xxxx xxxx 81f0 03e1 a601 53be 04bb 7c74
QP+ES|t
0x0020 8018 22a6 9384 0000 0101 080a 0015 d2f6
..".
0x0030 09bd d127 1703 0100 1890 5710 c450 b838
'W..P.8
0x0040 697e b447 cbaa 576b 5725 6f31 267d 2e9e
i~.G..WkW%o1&}..
0x0050 73 s
15:16:06.661649 xx.xx.xx.xx.imaps > 192.168.1.3.33264: R [tcp sum ok]
79395956:79395956(0) win 0 (DF) (ttl 253, id 0, len 40)
0x0000 4500 0028 0000 4000 fd06 3f8f xxxx xxxx
E..(..@?.QP+E
0x0010 c0a8 0103 03e1 81f0 04bb 7c74 0000 0000
.|t.
0x0020 5004 0000 6a9f 0000 0000 0000 0000 Pj
la seule différence que je vois c'est le nombre de 0 à la fin mais
bon ca a pas géné la cible, elle s'est bien fermée, pourquoi ca
generait l'expediteur ?
Est ce que j'interprète mal qq chose ? une erreur de base ? qq'un a
une idée ?
Merci
Florent
Poser une question
Whaou, c'est intéressant comme problème.
Au passage, c'est ta machine l'expéditeur ? ou une machine
quelconque ?
[snip]
Tu sniffes à quel niveau ?
Ca semble bizarre effectivement...
As-tu accès aux sockets des machines en cause ? pour pouvoir y placer
des codes d'erreur en fonction de ce qui est reçu ?
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
ravi de voir que ca interesse qq'un :)
Oui l'expediteur, c ma machine : elle a plein de sessions ouvertes
(imaginons par ex que j'ai un emule qui tourne...) et donc le prog
serait la pour killer une session a la demande.
Ma machine est donc A (l'expediteur des packets sensés killer la
session) et le vilain downloader serait B.
Bah je sniff avec un tcpdump donc au nivo de la libpcap.
Pour des tests, je peux avoir acces à A et B oui, mais les sockets
appartiennent a l'application qui les a lancé, donc je ne peux pas
faire bcp plus que lancer mes packets au milieu en esperant tromper
ces meme applis.
Une idée ? la j'avoue que je suis bien coincé.
Ok, je suis alle sur la page indiquee, si j ai bien compris, tu veux
faire pareil sans utiliser iptables ?
Ok.
L'ideal serait de lancer un client/serveur a ta sauce qui permettrait
de generer un code d erreur lorsque la trame en cause est recue.
Par contre, je ne sais pas comment exactement reagit la socket quand
elle recoit une info erronee. Je sais pas si ca remonte jusqu a l appli
ou si ca se limite au systeme d exploitation qui gere la socket...
Tcpdump ne met pas tous les champs des en-tetes. Il faudrait voir avec
ethereal ou un truc du genre si les champs sont bien identiques.
En fait, si je reviens a ton premier post:
En fait, tu dois creer tes trames avec raw ethernet access. Ca a
quelle tete ? tu dois entrer tous les champs des en-tetes ? avec un
certain codage ? et au niveau des donnees ?
As tu essaye de rajouter tous ces 0 en fin de trame pour voir si ca
faisait la difference ?
Ca pourrait ressembler a une sorte de bourrage ajoute pour faire en
sorte que la trame soit au bon format.
"Les octets de bourrage terminent l'en-tête TCP:
- de sorte que le nombre d'octet de celle-ci soit toujours multiple
de 4 (32 bits)
- de sorte que l'offset de données marqué dans l'en-tête corresponde
bien au début des données applicatives"
Par ailleurs, les deux trames ne semblent pas exactement identique:
0x0000 4510 0028 0000 4000 fd06 3f8f xxxx xxxx (Sur la premiere)
0x0000 4500 0028 0000 4000 fd06 3f8f xxxx xxxx (Sur la seconde)
Il faut regarder a quelle partie de la trame cela correspond...
Une derniere chose.
Si j ai bien compris, c est juste quand tu essaies d envoyer une trame
en local (d un socket distant spoofe vers un socket local) que tu as
l erreur. Alors que quand tu envoies une trame vers une autre machine,
ca semble marcher (premier FIN par exemple)
Ce qui voudrait dire que le passage par la carte reseau pourrait
changer quelque chose...
Il faut peut etre voir du cote de la doc de raw ethernet access pour
voir ce qui se passe quand ca reste en local.
Voila, pas d autre idee pour l instant...
A la limite, si tu m envoies le code, je pourrai tester de mon cote
si tu veux.
(mon adresse n est plus valide, je peux t en filer une valide si tu
veux)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
TCP Cutter n'utilise pas iptables. La diff que moi j'apporte c'est
qu'il n'est pas nécessaire d'être au milieu de la session (tcp cutter
est fait pour les firewalls).
Tu as tout dit, a ma connaissance l'appli ne voit pas les packets,
juste une api socket :) (peut etre que ca depend des applis, mais moi
je veux qq chose de général à toutes les applis
Bien vu :) mais g repompé le code de tcp cutter pour ca :)
Lee bourrage est au nivo ethernet (me dit ethereal), et ca ne fait
aucune difference, puisque meme sans ce bourrage mon 1er RST kille
bien la connection dans l'autre sens. Le problème vient bel et bien du
fait que je m'autosend un packet...
Le tos, pas de pb a ce nivo la, j'en ai essayé plusieurs
Bien vu, le pb que ethereal m'a montré est que j'avais pas fait
l'inversion des addresses mac au nivo deux (donc j'avais une mac
destination = machine distante). J'ai changé ca, mais c dur de se
binder a un socket en spoofant sa propre mac par une autre, alors pour
l'instant j'ai une trame ethernet qui dit qu'elle part de chez moi
pour aller chez moi aussi (ce qui est la pure vérité)
Mais ca ne change rien malheureusement, mon appli ignore toujours ce
packet.
C ce que je fais pour l'instant, j'essaye de reprendre le code de
tcpcutter un peu plus a fond, c compliqué ;)
Si ce problème t'interesse, tu es bien sur un collaborateur
bienvenu...
(et pi c interessant les raw sockets ethernet en C non ? ;) )
Arf, j'ai pas le temps de m'y plonger ce soir, mais je te fais une
réponse ce WE.
Oui, bien que mon niveau en C m'interdise de pouvoir m'y mettre
vraiment, mais je m'y remets depuis quelques semaines. Je vais voir
ce que je peux faire...
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG