Pour un usage commun, l'intérêt est proche de 0. Aussi intéressant pour M. Tout le monde qu'une reverse backdoor via icmp ou un cover channel dans le padding ssh.
L'intérêt peut se présenter, par exemple, si l'on recherche un moyen de communication après intrusion. Un flux http VALIDE (à base de PUT et de GET, par exemple) depuis un port de la machine compromise vers un site web externe sur le port 80 ne semble pas illégal ou douteux et passera généralement à travers un firewall. Mais si segtunnel est utilisé, on a un intéressant moyen de réaliser le transfert de fichiers importants, ou le transfert de commandes entre le serveur web (qui doit donc être controlé par le pirate) et la machine compromise.
Exemple : une fois ma backdoor en place, elle initie une connexion vers http://www.truc.eu.org(...) (donc un handshake tcp valide pour les firewalls statefull) et commence à envoyer /etc/shadow ou la base SAM ou je ne sais quoi vers le site par l'envoi régulier de commande http GET HTTP/1.0 index.html et en ignorant ce qui est renvoyé (une pauvre page web vide, par exemple). Petit à petit, coté serveur le fichier est reconstitué et le flux tcp semble valide pour un firewall et pire, semble valide pour un analyseur de flux http ! Un défaut qu'a httptunnel, qui est incapable (sans patcher) de passer à travers un proxy/analyseur tel que WebSweeper.
Dans l'autre sens, si la backdoor entretient la connexion vers le serveur du pirate par l'envoi régulier de GET HTTP/1.0 / de temps en temps, le serveur peut envoyer des commandes en utilisant lui aussi segtunnel. Un pattern particulier dans la réponse au GET (qui est aussi une session tcp) et hop, la backdoor passe en mode réception de commande, les réponses au GET suivantes contenant la commande à exécuter. Quand l'envoi de la commande est fini, la backdoor commence à envoyer la réponse toujours par le même moyen.
Maintenant cette solution est bien joli mais est mise en défaut par un proxy non transparent sauf si c'est le proxy qui est compromis. Une autre solution pour mettre cela en défaut est par exemple pf avec son option (me souvient plus du nom) permettant de modifier le paquet tcp afin par exemple d'éviter l'énumération des machines natées derrière un firewall pf.
Mais reconnaissons que l'intérêt est négligeable devant le challenge :)
[^] # Re: Stegtunnel, la stéganographie appliquée au TCP/IP
Posté par AlphA . En réponse à la dépêche Stegtunnel, la stéganographie appliquée au TCP/IP. Évalué à 10.
L'intérêt peut se présenter, par exemple, si l'on recherche un moyen de communication après intrusion. Un flux http VALIDE (à base de PUT et de GET, par exemple) depuis un port de la machine compromise vers un site web externe sur le port 80 ne semble pas illégal ou douteux et passera généralement à travers un firewall. Mais si segtunnel est utilisé, on a un intéressant moyen de réaliser le transfert de fichiers importants, ou le transfert de commandes entre le serveur web (qui doit donc être controlé par le pirate) et la machine compromise.
Exemple : une fois ma backdoor en place, elle initie une connexion vers http://www.truc.eu.org(...) (donc un handshake tcp valide pour les firewalls statefull) et commence à envoyer /etc/shadow ou la base SAM ou je ne sais quoi vers le site par l'envoi régulier de commande http GET HTTP/1.0 index.html et en ignorant ce qui est renvoyé (une pauvre page web vide, par exemple). Petit à petit, coté serveur le fichier est reconstitué et le flux tcp semble valide pour un firewall et pire, semble valide pour un analyseur de flux http ! Un défaut qu'a httptunnel, qui est incapable (sans patcher) de passer à travers un proxy/analyseur tel que WebSweeper.
Dans l'autre sens, si la backdoor entretient la connexion vers le serveur du pirate par l'envoi régulier de GET HTTP/1.0 / de temps en temps, le serveur peut envoyer des commandes en utilisant lui aussi segtunnel. Un pattern particulier dans la réponse au GET (qui est aussi une session tcp) et hop, la backdoor passe en mode réception de commande, les réponses au GET suivantes contenant la commande à exécuter. Quand l'envoi de la commande est fini, la backdoor commence à envoyer la réponse toujours par le même moyen.
Maintenant cette solution est bien joli mais est mise en défaut par un proxy non transparent sauf si c'est le proxy qui est compromis. Une autre solution pour mettre cela en défaut est par exemple pf avec son option (me souvient plus du nom) permettant de modifier le paquet tcp afin par exemple d'éviter l'énumération des machines natées derrière un firewall pf.
Mais reconnaissons que l'intérêt est négligeable devant le challenge :)