Ceci n'est pas un tutoriel sur les exploits. C'est simplement une simple 
description de comment crire des exploits comme modules pour le metasploit 
framework.

Ce document ressemble  un tutoriel car nous pensons qu'un exemple est la meilleure 
manire d'apprendre comment crire pour le Metasploit. Ces exemples sont seulement 
un petit aperu de ce qui fonctionne et de ce qu'il est possible de faire. La meilleure 
manire pour apprendre des capacits plus avances est de lire le code de nos modules, 
le code du framework, et de nous mailer des questions (dans cet ordre ;)). Par exemple, 
si vous crivez un exploit de force brute linux, chercher dans nos exploits et trouver 
quelquechose de similaire. Vous pourrez ainsi non seulement voir comment nous l'avons 
fait, mais aussi remarquer notre norme de nommage des options, nos techniques, etc.

Commenons avec un exemple simple de dpassement de tampon en rseau. C'est un 
dmon simple qui n'coute qu'une seule connexion, la lit, et s'interrompt.

[ code source dans vuln1.c ]

Vous pouvez voir que nous avons un dpassement de tampon quand on envoie plus de
64 caractres de donnes. La stratgie (du fait que c'est un coup en un), est 
d'envoyer un gros nopsled, et de retourner directement dans la pile. Nous allons 
commencer un nouveau module d'exploit Metasploit, remplir les informations, et 
utiliser quelques routines de dveloppement pour trouver l'offset d'EIP.

[ code source dans vuln1_1.pm ]

Il y a beaucoup de commentaires dans le module d'exploit. Pour notre premier 
exemple, nous crivons un exploit simple sans support de cible ou de payload. 
Nous voulons seulement rassembler quelques informations gnrales sur le bogue, 
et les utiliser pour crire notre exploit. Nous rcoltons quelques meta donnes 
sur l'exploit, comme le nom, les auteurs, les architectures/systmes d'exploitation 
supports, etc. Nous crons la mthode Exploit, le code qui sera appell par le 
framework quand l'utilisateur choisira d'excuter vos modules d'exploit.

msf > use vuln1_1 
msf vuln1_1 > show options 

Options de l'Exploit
====================

  Exploit:    Nom       Dfaut    Description
  --------    ------    -------    ------------------    
  requis	  RHOST                L'adresse de la cible
  requis	  RPORT     11221      Le port cible
  
  Cible: Exploit sans cible

msf vuln1_1 > set RHOST 127.0.0.1
RHOST -> 127.0.0.1
msf vuln1_1 > exploit

.... Dans une autre fentre ....
Program received signal SIGSEGV, Segmentation fault.
0x63413563 in ?? ()
(gdb) 

# perl sdk/patternOffset.pl 0x63413563
76

Nous utilisons l'outil patternOffset.pl pour trouver l'offset d'EIP (76). Nous
utilisons galement gdb pour extraire la valeur d'esp (0xbffffa30) sur notre 
systme.

[ code source dans vuln1_2.pm ]

Nous avons maintenant assez d'informations pour commencer  crire un exploit.
Nous ajoutons la Cible (seulement une pour mon systme), et indiquons aussi au 
Framework de permettre l'utilisation avec un payload.

Nous pouvons utiliser cette information et commencer  crire un exploit 
fonctionnel (pour notre systme). Nous ajoutons une entre Payload, indiquant au 
Framework de demander un payload  l'utilisateur, et nous permettre d'utiliser 
ce payload depuis l'entre EncodedPayload que le Framework prpare dans l'
environnement.
EncodedPayload est un objet, et nous appellons simplement la mthode Payload.

Nous prparons des options Avances pour quelques dtails de notre exploit.
C'est surtout pratique pour le dveloppement, ou d'autres chercheurs travaillant 
avec vos exploits. Ce ne sont pas des options qu'un utilisateur standard changera, 
mais j'ai trouv qu'ajouter des options comme celles-ci est trs utile.

Il est important de noter que vous appeller GetLocal pour les Options Avances!
La rgle gnrale est d'appeller GetLocal pour les Options avances, et 
GetVar pour tout le reste. La diffrence principale entre les deux est que GetLocal 
ne va pas regarder dans l'Environnement Global (pas totalement vrai, mais assez quand 
mme).

Nous avons fini le module, et il fonctionne!

msf vuln1_2(linx86_reverse) > show options 

Exploit and Payload Options
===========================

  Exploit:    Nom       Dfaut       Description
  --------    ------    ---------    ------------------    
  required    RHOST     127.0.0.1    L'adresse de la cible
  required    RPORT     11221        Le port cible
  
  Payload:    Nom       Dfaut       Description
  --------    ------    ---------    -----------------------------------    
  required    LHOST     127.0.0.1    Adresse locale pour recevoir la connexion
  required    LPORT     12322        Port local pour recevoir la connexion
  
  Cible: Slackware Linux

msf vuln1_2(linx86_reverse) > set
LHOST: 127.0.0.1
LPORT: 12322
PAYLOAD: linx86_reverse
RHOST: 127.0.0.1
TARGET: 0
msf vuln1_2(linx86_reverse) > exploit
[*] Starting Reverse Handler.
[*] Got connection from 127.0.0.1:32896

id
uid=1000(spoonm) gid=1000(spoonm) groups=1000(spoonm)


[ code source dans vuln1_3.pm ]

Ce programme exploitable aura le socket ouvert lorsque nous gagnerons le contrle 
d'excution. Cela nous permet de supporter les payloads findsock, permettant la 
rutilisation de la connexion initiale que nous avons faite au service.


Nous informons le Framework que nous supportons les payloads marqus avec le mot 
cl findsock, en l'ajoutant  notre liste de cls de payload supports (avec le 
+findsock). Avec le support de findsock, nous devons galement mettre l'option 
CPORT en dehors de l'environnement. CPORT est utilis par les payloads findsock du 
genre srcport, permettant  l'exploit et aux payloads de connaitre tous les deux 
le srcport avec lequel la connexion sera faite (utilis pour identifier le socket 
dans le shellcode). L'option CPORT est ajoute dans UserOpts par le Payload, et 
est uniquement ncessaire du ct utilisateur en utilisant un payload findsock du 
genre srcport. Du point de vue de l'exploit, vous devez savoir que cette option 
doit tre configure, et la passer  la mthode de cration du socket, crant le 
socket avec le srcport spcifi (si fourni).
Si un utilisateur n'utilise pas un payload findsock du genre srcport, CPORT sera 
non dfini et le socket sera cr avec un port source alatoire. Penser au srcport 
est trs important, quelquefois il est ncessaire pour patienter un peu entre des 
tentatives de force brute pour permettre  l'ancien socket d'tre libr, ainsi vous 
pourrez rutiliser le port source. Il est galement important de raliser que vous 
ne pouvez pas avoir plusieurs connexions concurrentes avec le mme srcport, ainsi 
CPORT doit seulement tre pass sur la connexion comme pour avoir le shell (cad, 
vous aviez un exploit qui ncessitait que plus d'une connexion soit faite).

Nous ajoutons quelques bonnes fonctionnalits  l'exploit, affichant des informations 
sur la cible qu'il est en train d'essayer, informant l'utilisateur que des choses 
se passent.

Voici une dmonstration d'un findsock fonctionnant (du genre tag recv, pas CPORT).

msf vuln1_3(linx86_findrecv) > show options 

Exploit and Payload Options
===========================

  Exploit:    Nom       Dfaut       Description
  --------    ------    ---------    ------------------    
  required    RHOST     127.0.0.1    L'adresse de la cible
  required    RPORT     11221        Le port cible
  
  Payload:    Nom       Dfaut       Description
  --------    ------    -------      -----------    
  
  Cible: Slackware Linux

msf vuln1_3(linx86_findrecv) > set
PAYLOAD: linx86_findrecv
RHOST: 127.0.0.1
TARGET: 0
msf vuln1_3(linx86_findrecv) > exploit
Trying Slackware Linux - 0xbffffa60
[*] Findsock found shell...

id
uid=1000(spoonm) gid=1000(spoonm) groups=1000(spoonm)


Au lieu d'crire une dmonstration plus complique d'un programme vulnrable 
(comme un qui fait une fourche), j'ai document le module svnserve_date. Ce 
module exploite le dmon subversion svnserve, et dmontre un exploit de force 
brute avec les deux cibles linux et freebsd, et le support findsock.

[ code source dans svnserve_date.pm ]

Ce document devrait suffir pour avoir les pieds sur terre et tre famillier avec 
l'aspect dveloppement du Metasploit Framework. Les choses ncessaires pour les 
exploits requirent vraiment souvent et grandement des fonctionnalits spcifiques 
et le support de la part du Framework. Nous avons crit un grand nombre de modules 
diffrents qui sont avantags par diffrentes parties du framework, et suggrent 
d'tre lus pour devenir un dveloppeur de module plus avanc.

Merci de ne pas fumer, et amusez-vous bien.
