Copy Link
Add to Bookmark
Report
BFi numero 12 file 07 French
-[ 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 <tleil4x@tiscali.it>
------------------------------------------------------------------------------
==============================================================================
-------------------[ 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 <xenion@antifork.org>
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 ]------------------------------------
==============================================================================
