-Premier problème, si tu envoies un paquet avec une IP source différente de la tienne, alors la réponse ira à l'autre, et pas à toi. Donc tu n'as jamais aucune réponse.
Tu peux envoyer en aveugle, ceci dit.
-Deuxième problème: Si l'autre que tu usurpes, voit arriver des paquets, alors il enverra un paquet TCP Reset pour signifier que bah non, il ne comprend pas ce que sont ces paquets et qu'il faut clore la connexion.
Effectivement tu peux faire un DOS sur la machine usurpée.
-Troisième problème: Tu as envoyé ton SYN, la machine attaquée renvoit un SYN-ACK, il faut que tu envoies un ACK pour ouvrir la connexion TCP. Mais la machine qui envoie le SYN-ACK a aussi ajouté un numéro de séquence TCP.
Solution: il faut prédire le numéro de séquence TCP. La, ça devient ardu. Néanmoins, Mitnick a réussi, car à l'époque les piles TCP avaient un séquencement prévisible.
Arrivé à ce niveau, Mitnick peut envoyer un peu de données, dans le paquet ACK.
Enfin, qu'envoyer comme données? Bin là, il s'est appuyé sur le fait que la machine visé utilisait rhosts. Il a juste fait une commande rhost qui disait:
echo "+ +" > ~/.rhosts
Et pour ceux qui connaissent le rhosts, cela signifie que tout le monde peut se connecter depuis n'importe quelle IP :)
Ceci est possible car l'hôte usurpée avait les droits de passer des commandes de type 'r' en root. Suite à ça, il fait un simple rlogin en root, et hop pour lui. le spoof TCP n'a servi que comme approche initiale, pas en permanence.
Aujourd'hui, il parait difficile de lancer une connexion spoof TCP:
-il faut flooder une machine, c'est ardu.
-il faut envoyer en aveugle (faisable)
-il faut trouver le bon numéro de séquence (très ardu)
-il faut envoyer en un paquet la charge utile, typiquement, si la machine attaquée répond encore un paquet, il faudra connaitre sa taille pour répondre en aveugle le bon numéro de séquence encore une fois (car le numéro de séquence correspond au numéro initial + la quantité d'octets envoyés).
Donc bon, faire tout ça pour faire une trace dans un serveur web, ça parait chaud...
[^] # Re: Je trouve...Le fait de passer ce lien privé
Posté par octane . En réponse au journal OpenBSD et le piège à troll. Évalué à 10.
-Premier problème, si tu envoies un paquet avec une IP source différente de la tienne, alors la réponse ira à l'autre, et pas à toi. Donc tu n'as jamais aucune réponse.
Tu peux envoyer en aveugle, ceci dit.
-Deuxième problème: Si l'autre que tu usurpes, voit arriver des paquets, alors il enverra un paquet TCP Reset pour signifier que bah non, il ne comprend pas ce que sont ces paquets et qu'il faut clore la connexion.
Effectivement tu peux faire un DOS sur la machine usurpée.
-Troisième problème: Tu as envoyé ton SYN, la machine attaquée renvoit un SYN-ACK, il faut que tu envoies un ACK pour ouvrir la connexion TCP. Mais la machine qui envoie le SYN-ACK a aussi ajouté un numéro de séquence TCP.
Solution: il faut prédire le numéro de séquence TCP. La, ça devient ardu. Néanmoins, Mitnick a réussi, car à l'époque les piles TCP avaient un séquencement prévisible.
Arrivé à ce niveau, Mitnick peut envoyer un peu de données, dans le paquet ACK.
Enfin, qu'envoyer comme données? Bin là, il s'est appuyé sur le fait que la machine visé utilisait rhosts. Il a juste fait une commande rhost qui disait:
echo "+ +" > ~/.rhosts
Et pour ceux qui connaissent le rhosts, cela signifie que tout le monde peut se connecter depuis n'importe quelle IP :)
Ceci est possible car l'hôte usurpée avait les droits de passer des commandes de type 'r' en root. Suite à ça, il fait un simple rlogin en root, et hop pour lui. le spoof TCP n'a servi que comme approche initiale, pas en permanence.
Aujourd'hui, il parait difficile de lancer une connexion spoof TCP:
-il faut flooder une machine, c'est ardu.
-il faut envoyer en aveugle (faisable)
-il faut trouver le bon numéro de séquence (très ardu)
-il faut envoyer en un paquet la charge utile, typiquement, si la machine attaquée répond encore un paquet, il faudra connaitre sa taille pour répondre en aveugle le bon numéro de séquence encore une fois (car le numéro de séquence correspond au numéro initial + la quantité d'octets envoyés).
Donc bon, faire tout ça pour faire une trace dans un serveur web, ça parait chaud...