Le premier trimestre de 2020, j'ai consacré du temps à la préparation de l'examen OSCP. La recherche d'informations sur Google et les nombreuses « tentatives à l'aveugle » ont occupé tout mon temps libre. Il s'est avéré particulièrement difficile de comprendre les mécanismes d'élévation des privilèges. Le cours PWK accorde une grande importance à ce sujet, mais il manque toujours de matériel didactique. Il existe de nombreux manuels en ligne avec des commandes utiles, mais je ne suis pas partisan de suivre aveuglément les recommandations sans comprendre les implications.
Je souhaite partager avec vous ce que j'ai pu apprendre lors de ma préparation et de ma réussite à l'examen (y compris mes incursions occasionnelles sur Hack The Box). J'ai ressenti une immense gratitude pour chaque bribe d'information qui m'a aidé à suivre le chemin Try Harder de manière plus consciente, et maintenant il est temps pour moi de rendre hommage à la communauté.
Je veux vous donner un manuel sur l'élévation des privilèges sous OS Linux, qui examine les vecteurs les plus courants et des astuces connexes qui vous seront certainement utiles. Souvent, les mécanismes d'élévation des privilèges en eux-mêmes ne sont pas très complexes, les difficultés se présentent lors de la structuration et de l'analyse de l'information. C'est pourquoi j'ai décidé de commencer par une « visite d'ensemble » et d'examiner chaque vecteur dans un article séparé. J'espère ainsi vous faire gagner du temps pour étudier ce sujet.
Alors, pourquoi l'élévation des privilèges est-elle possible en 2020, alors que les méthodes sont bien connues depuis longtemps ? En réalité, lorsqu'un utilisateur interagit correctement avec le système, il n'est effectivement pas possible d'élever les privilèges. Le principal problème global qui crée de telles opportunités réside dans une configuration non sécurisée. La présence de versions de logiciels obsolètes contenant des vulnérabilités est également un cas particulier de configuration non sécurisée.
Élévation des privilèges par une configuration non sécurisée
Tout d'abord, examinons la configuration non sécurisée. Commençons par le fait que les professionnels de l'IT utilisent souvent des manuels et des ressources comme Stack Overflow, dont beaucoup contiennent des commandes et des configurations non sécurisées. Un exemple frappant est le fait que le code le plus copié de Stack Overflow contenait une erreur. Un administrateur expérimenté remarquera la faute, mais c'est dans un monde idéal. Même des spécialistes compétents peuvent en trébucher sous une charge de travail élevée ils peuvent commettre des erreurs. Imaginez qu'un administrateur s'occupe de la préparation et de l'approbation de la documentation pour un nouvel appel d'offres, tout en se familiarisant avec la nouvelle technologie qui doit être mise en œuvre au cours du prochain trimestre, tout en résolvant périodiquement des problèmes d'assistance aux utilisateurs. Et là, on lui demande rapidement de créer quelques machines virtuelles et d'y déployer des services. Quelle est, selon vous, la probabilité que l'administrateur ne remarque tout simplement pas une erreur ? Ensuite, les spécialistes changent, mais les rustines restent, alors que les entreprises cherchent toujours à minimiser les coûts, y compris pour les professionnels de l'IT.
Pseudo-shell et jailbreak
Un shell système obtenu en phase d'exploitation est souvent limité, surtout si vous l'avez obtenu via une faille dans le web serveur. Par exemple, les restrictions du shell peuvent empêcher l'exécution de la commande sudo, entraînant l'erreur suivante :
sudo: aucun tty présent et aucun programme askpass spécifiéAprès avoir obtenu le shell, je recommande de créer un terminal complet, par exemple avec Python.
python -c 'import pty;pty.spawn("/bin/bash")'Vous vous demandez : « Pourquoi ai-je besoin de mille commandes si je peux en utiliser une seule, par exemple pour transférer des fichiers ? » La réalité est que les systèmes peuvent être configurés différemment, un hôte donné peut ne pas avoir Python installé, mais posséder Perl. L'important est d'être capable de réaliser des tâches habituelles dans le système sans les outils habituels. Une liste complète des possibilités peut être trouvée .
Un shell à faibles privilèges peut être obtenu en utilisant et (il est surprenant même que GIMP).
Consulter l'historique des commandes
Linux enregistre l'historique de toutes les commandes exécutées dans le fichier ~/.bash_history. Si le serveur est activement utilisé et que son historique n'est pas nettoyé, il y a de fortes chances de trouver des identifiants dans ce fichier. Il est ennuyeux de nettoyer l'historique. Si l'administrateur doit choisir parmi des commandes longues, il lui sera évidemment plus pratique d'appeler cette commande depuis l'historique plutôt que de la taper à nouveau. De plus, beaucoup ne connaissent pas ce « hack ». Si des shells alternatifs comme Zsh ou Fish sont présents dans le système, ils mènent leur propre historique. Pour afficher l'historique des commandes dans n'importe quel shell, il suffit de taper la commande history.
cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_historyIl existe un hébergement partagé où le serveur est utilisé pour héberger plusieurs sites. Habituellement, dans cette configuration, chaque ressource dispose de son propre utilisateur avec un répertoire personnel séparé et un hôte virtuel. En cas de configuration incorrecte, il est possible de découvrir un fichier .bash_history dans le répertoire racine de la ressource web.
Recherche de mots de passe dans le système de fichiers et attaques sur des systèmes voisins
Les fichiers de configuration de divers services peuvent être accessibles en lecture par votre utilisateur actuel. On peut y trouver des identifiants en clair — mots de passe pour accéder à la base de données ou à des services connexes. Un même mot de passe peut être utilisé pour accéder à la fois à la base de données et à l'authentification de l'utilisateur root (credential staffing).
Il arrive que les identifiants trouvés appartiennent à des services sur d'autres hôtes. L'extension de l'attaque sur l'infrastructure via un hôte compromis n'est pas moins grave que l'exploitation d'autres hôtes. Des systèmes voisins peuvent également être trouvés en recherchant des adresses IP dans le système de fichiers.
grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Trouver la chaîne password (sans cs) dans ces répertoires
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs dans les logsDans le cas où un web applicatif disponible sur Internet se trouve sur l'hôte compromis, il est préférable d'exclure ses logs de la recherche d'adresses IP. Les adresses des utilisateurs du service sur Internet sont peu susceptibles de nous être utiles, tandis que les adresses du réseau interne (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) et les endroits où ils se connectent, selon les logs, peuvent être intéressants.
Sudo
La commande sudo permet à l'utilisateur d'exécuter une commande dans le contexte de root en utilisant son propre mot de passe ou sans l'utiliser du tout. De nombreuses opérations sous Linux nécessitent des privilèges root, mais travailler sous root est considéré comme une très mauvaise pratique. Il est préférable d'appliquer une autorisation sélective pour l'exécution de commandes dans le contexte de root. Cependant, de nombreux outils Linux, y compris des standard comme vi, peuvent être utilisés pour élever les privilèges par des moyens tout à fait légitimes. Pour rechercher un moyen approprié, je recommande de consulter. .
La première chose à faire une fois que vous avez accès au système est d'exécuter la commande sudo -l. Cela affichera les autorisations d'utilisation de la commande sudo. Si un utilisateur sans mot de passe est obtenu (comme apache ou www-data), le vecteur d'élévation de privilèges via sudo est peu probable. En utilisant sudo, le système demandera un mot de passe. La commande passwd ne permettra pas non plus de définir un mot de passe, car elle demandera le mot de passe actuel de l'utilisateur. Mais si sudo est disponible, il faut essentiellement chercher :
- tous les interpréteurs, chacun peut générer un shell (PHP, Python, Perl);
- tous les éditeurs de texte (vim, vi, nano);
- tous les visionneurs (less, more);
- toutes les possibilités de travailler avec le système de fichiers (cp, mv);
- des outils ayant accès à bash, de manière interactive ou en tant que commande exécutable (awk, find, nmap, tcpdump, man, vi, vim, ansible).
Suid/Sgid
Il existe de nombreux manuels sur Internet qui conseillent de rassembler toutes les commandes suid/sgid, mais peu d'articles donnent des instructions concrètes sur la manière de traiter ces programmes. Des options d'élévation de privilèges, sans tenir compte de l'utilisation d'exploits, peuvent être trouvées . De plus, certains fichiers exécutables ont des vulnérabilités spécifiques à la version du système d'exploitation, .
Dans un monde idéal, tous les paquets installés devraient passer au moins par searchsploit. En pratique, il est judicieux de le faire avec les programmes les plus populaires comme sudo. Il existe également la possibilité d'utiliser et de maintenir le développement d'outils automatisés qui mettront en évidence des fichiers exécutables intéressants du point de vue de l'élévation de privilèges, avec des bits suid/sgid définis. Je fournirai une liste de ces outils dans la section correspondante de l'article.
Scripts accessibles en écriture, lancés par Cron ou Init, dans le contexte de Root
Les tâches cron peuvent s'exécuter dans le contexte de différents utilisateurs, y compris root. Si une tâche cron fait référence à un fichier exécutable, et qu'il est accessible en écriture pour vous, il est facile de le remplacer par un fichier malveillant et d'exécuter une élévation de privilèges. Par défaut, les fichiers des tâches cron sont accessibles en lecture à tout utilisateur.
ls -la /etc/cron.d # montrer les tâches cron Il en va de même pour init. La différence est que les tâches dans cron s'exécutent périodiquement, alors qu'init s'exécute au démarrage du système. Pour l'exploitation, il faudra redémarrer le système, et certains services peuvent ne pas se lancer (s'ils n'ont pas été enregistrés au démarrage automatique).
ls -la /etc/init.d/ # afficher les scripts d'initialisation Vous pouvez également chercher des fichiers qui sont accessibles en écriture par tout utilisateur.
find / -perm -2 -type f 2>/dev/null # trouver des fichiers accessibles en écriture par tousCette méthode est assez connue, les administrateurs système expérimentés utilisent la commande chmod avec précaution. Cependant, sur Internet, la plupart des manuels décrivent la définition des droits maximaux. L'approche des administrateurs système inexpérimentés du type « tant que ça fonctionne » crée des occasions d'élévation de privilèges. Si possible, il vaut mieux rechercher dans l'historique des commandes l'utilisation non sécurisée de chmod.
chmod +w /path
chmod 777 /pathAccéder aux consoles d'autres utilisateurs
Regardons la liste des utilisateurs dans /etc/passwd. Nous prêtons attention à ceux qui ont un shell. Nous pouvons essayer de brute forcer ces utilisateurs - il est possible qu'à travers cet utilisateur, nous puissions finalement élever nos privilèges.
Pour améliorer la sécurité, je recommande toujours de suivre le principe du moindre privilège. Il est également judicieux de prendre le temps de vérifier les configurations non sécurisées qui pourraient rester après le dépannage - c'est une « dette technique » pour l'administrateur système.
Code personnalisé
Il est important de jeter un œil aux fichiers exécutables dans le répertoire personnel de l'utilisateur et du serveur web (/var/www/, si aucun autre n'est spécifié). Ces fichiers peuvent représenter une solution complètement non sécurisée et contenir des contournements incroyables. Bien sûr, si vous avez un framework dans le répertoire du serveur web, il n'est pas utile de chercher un zero-day dans le cadre d'un pentest, mais il est conseillé de trouver et d'examiner les modifications personnalisées, les plugins et les composants.
Pour améliorer la sécurité, il est préférable de ne pas utiliser d'informations d'identification dans des scripts personnalisés, ainsi que d'éviter les fonctionnalités potentiellement dangereuses, telles que la lecture de /etc/shadow ou les manipulations avec id_rsa.
Élévation de privilèges via l'exploitation de vulnérabilités
Avant de essayer d'élever les privilèges par l'exploitation, il est important de comprendre le transfert de fichiers vers l'hôte cible. En plus des moyens habituels comme ssh, ftp, http (wget, curl), il existe tout un .
Pour améliorer la sécurité du système, mettez-le régulièrement à jour vers des versions stables versions, et essayez d'utiliser des distributions conçues pour l'Enterprise. Sinon, il arrive rarement que la commande apt upgrade rende le système inutilisable.
Exploitation des services exécutés dans le contexte de l'utilisateur root
Certains services Linux fonctionnent avec les privilèges de l'utilisateur root. Vous pouvez les trouver avec la commande ps aux | grep root. Dans ce cas, le service peut ne pas être annoncé sur le réseau et être accessible localement. S'il possède des exploits publics, vous pouvez les utiliser sans hésitation : une panne du service en cas d'échec est beaucoup moins critique qu'une panne du système d'exploitation.
ps -aux | grep root # LinuxLe cas le plus réussi serait le fonctionnement d'un service compromis dans le contexte de l'utilisateur root. L'exploitation du service SMB donne un accès privilégié SYSTEM sur les systèmes Windows (par exemple, via ms17-010). Cependant, cela est rare dans les systèmes Linux, donc vous pourriez passer beaucoup de temps à élever vos privilèges.
Exploitation des vulnérabilités du noyau Linux
C'est la dernière option à envisager. Une exploitation infructueuse peut entraîner un arrêt du système, et lors d'un redémarrage, certains services (y compris ceux par lesquels vous avez initialement obtenu le shell) pourraient ne pas se lancer. Il arrive que l'administrateur ait simplement oublié d'exécuter la commande systemctl enable. De plus, cela suscitera beaucoup de mécontentement face à votre travail si l'exploitation n'a pas été convenue.
Si vous décidez d'utiliser les codes sources depuis exploitdb, assurez-vous de lire les commentaires au début du script. Entre autres, il est généralement indiqué comment compiler correctement cet exploit. Si vous n'avez pas envie de le faire vous-même ou si les délais exigent « hier », vous pouvez chercher des dépôts avec des exploits déjà compilés. . Cependant, il faut comprendre que dans ce cas, vous obtiendrez un chat dans un sac. D'autre part, si un programmeur comprenait jusqu'au byte comment fonctionne l'ordinateur et les logiciels qu'il utilise, il n'écrirait pas une seule ligne de code de sa vie.
cat /proc/version
uname -a
searchsploit "Linux Kernel" Metasploit
Pour capturer et traiter une connexion, il est toujours préférable d'utiliser le module exploit/multi/handler. L'essentiel est de définir le bon payload, par exemple, generic/shell/reverse_tcp ou generic/shell/bind_tcp. Le shell obtenu dans Metasploit peut être amélioré en Meterpreter en utilisant le module post/multi/manage/shell_to_meterpreter. Avec Meterpreter, vous pouvez automatiser le processus de post-exploitation. Par exemple, le module post/multi/recon/local_exploit_suggester vérifie la plateforme, l'architecture et les entités nécessaires à l'exploitation, et propose des modules Metasploit pour l'élévation de privilèges sur le système cible. Grâce à Meterpreter, l'élévation de privilèges se résume parfois à exécuter le bon module, cependant, le piratage sans comprendre ce qui se passe en coulisse n'est pas « vrai » (vous devez encore rédiger un rapport).
Outils
Les outils d'automatisation de la collecte d'informations locales vous feront gagner beaucoup d'efforts et de temps, mais ne peuvent pas à eux seuls révéler complètement le chemin de l'élévation de privilèges, surtout en cas d'exploitation de vulnérabilités du noyau. Les outils d'automatisation exécuteront toutes les commandes nécessaires pour collecter des informations sur le système, mais il est également important de savoir analyser les données obtenues. J'espère que mon article vous sera utile à cet égard. Bien sûr, il existe beaucoup plus d'outils que ceux que je vais mentionner ci-dessous, mais ils font tous à peu près la même chose — il s'agit plutôt d'une question de goût.
Un outil assez récent, le premier commit date de janvier 2019. Actuellement, c'est mon outil préféré. L'idée est qu'il met en évidence les vecteurs d'élévation de privilèges les plus intéressants. Convenez qu'il est plus pratique d'obtenir une évaluation d'expert à ce niveau que de déchiffrer des données brutes monolithiques.
Mon deuxième outil préféré, il collecte également et systématise les données obtenues lors de l'énumération locale.
Cet exploit analysera le système à la recherche de conditions appropriées pour les exploits. En gros, il fera le même travail que le module Metasploit local_exploit_suggester, mais proposera non pas des modules Metasploit mais des liens vers le code source d'exploit-db.
Ce script collectera et systématisera par sections un grand nombre d'informations qui peuvent être utiles pour former un vecteur d'élévation de privilèges.
Une autre fois, je passerai en revue en détail .
Source : habr.com
