Nous continuons la conversation pour des cas intéressants dans le travail des pentesters. Dans le dernier
article, nous avons parlé des tests de pénétration externe, nous parlerons aujourd'hui des pentests internes les plus intéressants que nous avons mis en œuvre récemment. Leur essence est que nous devrions, étant dans le périmètre interne du client, recevoir le maximum de privilèges dans le domaine et accéder à toutes les données importantes. C'est arrivé à être surpris. Mais tout d'abord.
Cas 1. Le gestionnaire de mots de passe est bon, mais ils doivent pouvoir utiliser
Nous avons effectué des tests de pénétration interne pour un gros client qui avait déjà des administrateurs système formés et un service SI. Au cours du travail, nous avons reçu plusieurs comptes avec lesquels nous pouvions déjà aller sur le réseau et nous connecter aux machines des autres utilisateurs. À un moment donné, ils se sont installés dans la voiture de l'un des administrateurs système et y ont trouvé un eldorado. L'administrateur système a utilisé des mots de passe vraiment complexes (il serait difficile d'en trouver) et les a même stockés dans keepass. Mais voici la malchance: le gestionnaire de mots de passe lui-même n'a jamais été bloqué - pas après 15 minutes, ou au moment du verrouillage de l'écran. Avec ce bonus, nous avons obtenu des droits administratifs sur les systèmes clients critiques sans bruit ni poussière.
Un autre client avait un cas similaire. Mots de passe aussi compliqués, aussi keepass, bien qu'il y ait toujours un verrouillage automatique après 15 minutes. Comment pourrions-nous l'utiliser? Ils ont attendu que l'administrateur verrouille le bureau et soit parti (pour le déjeuner?). Puis ce fut une petite affaire.
Si vous utilisez des gestionnaires de mots de passe, utilisez-les judicieusement - activez l'option de verrouillage avec un écran de verrouillage et en l'absence d'activité pendant 1 à 5 minutes.
Cas 2. Employés licenciés
Très souvent, lors des pentests internes, nous y accédons en sélectionnant des mots de passe - les utilisateurs sont généralement trop paresseux pour trouver des combinaisons complexes, en particulier lorsque la politique de mot de passe nécessite de les mettre à jour tous les mois. Souvent, les chiffres changent simplement - ainsi, superpassword_03.2019 un mois plus tard se transforme en superpassword_04.2019 et plus bas dans la liste.
Mais parfois, les clients semblent tout à fait à l'improviste. Ainsi, en menant une attaque par pulvérisation de mots de passe dans l'une des sociétés, nous avons obtenu un certain nombre de comptes et l'un d'eux était particulièrement intéressant pour nous: elle avait des droits assez larges, mais pas des droits d'administrateur. Un mot de passe facile a été défini pour elle (qaz12345), et les commentaires sur cette entrée dans AD indiquent que l'employé a été licencié - à en juger par la date, il y a presque un an. Autrement dit, après le licenciement, le compte n'a pas été bloqué, mais il suffit de réinitialiser le mot de passe à «par défaut» et de définir l'option «changer le mot de passe lors de la première connexion». Pour le bonheur du client, nous avons été les premiers invités à le faire.
Cas 3. Des correctifs? Non, non
La partie la plus difficile du pentest interne est d'obtenir le premier compte. Il existe de nombreux outils et moyens de le faire, à commencer par un défilé de mode d'espionnage au bureau à la recherche d'autocollants chéris avec des mots de passe et d'attraper les affligés avec une connexion Wi-Fi de bureau clonée, se terminant par des attaques sur Kerberos et le piratage de mots de passe de comptes. Mais parfois, même avec l'analyse initiale, vous pouvez trouver un logiciel que personne n'a mis à jour depuis dix mille ans (pourquoi s'embêter à mettre à jour le logiciel dans l'infrastructure interne?).
Dans un de ces projets, ils sont tombés sur le logiciel de gestion de HP, dans lequel RCE a été trouvé sans authentification - ils en ont obtenu une partie des comptes.
¯ \ _ (ツ) _ / ¯
Il semblait que tout serait encore plus simple - Mimikatz, et la chose est dans le chapeau, mais il s'est avéré que les comptes reçus ne possédaient pas les privilèges dont nous avions besoin. Comme ils le disent, notre force réside dans la préparation au cloud: en utilisant la magie de nmap et le script smb-enum-share, nous avons découvert que l'un des comptes avait des droits d'administrateur local sur le serveur de test, auquel les administrateurs de domaine étaient activement impliqués à ce moment =).
Cas 4. Serrures
Enfin, parlons un peu du blocage possible de l'accès. Travaux sur la "vnutryanka" que nous réalisons le plus souvent à distance. Le schéma ressemble à ceci: nous nous connectons au VPN, nous obtenons l'adresse interne, puis nous nous accrochons à la machine allouée pour nous via RDP. Et avec cette machine, nous commençons déjà à effectuer des travaux, mais pour cela, nous devons en quelque sorte transporter nos outils. Beaucoup de nos clients utilisent des serveurs proxy avec des listes blanches de sites, parfois même avec des listes blanches de ports, pour accéder à Internet (par exemple, vous pouvez vous connecter à un site Web avec le port 80, mais vous ne pouvez plus vous connecter au 8081). Cela rend vraiment le travail un peu plus difficile, surtout si le copier-coller via RDP est interdit.
Mais où dans nos affaires sans nuances. Un client avait des règles très strictes et nous n'étions pas autorisés à remplir nos outils de manière officielle, pour ainsi dire, ils ont empêché la pénétration par «l'entrée principale». Comme, voici une machine virtuelle et des droits minimaux pour vous - souffrez comme de vrais pirates.
Je n'ai pas eu à souffrir longtemps. Le proxy a vraiment beaucoup bloqué, il n'était même pas possible de se connecter simplement à son serveur http (il n'est pas dans les listes blanches), le copier-coller était interdit, le navigateur refusait d'aller n'importe où sauf http (80 / tcp) et https (443 / tcp), et ailleurs que sur des portails internes. Nous avons essayé wget via powershell - cela ne fonctionne pas non plus, il ne va pas sans proxy, et les proxy interdisent. Mais l'utilitaire FTP intégré de Windows a bien fonctionné - il n'y avait pas de règles sur le pare-feu qui bloqueraient un tel trafic. Nous avons donc traîné tous nos outils à l'intérieur du périmètre et avons pu faire un excellent travail.
En fin de compte
Je vais répéter les recommandations de la partie précédente, car la répétition est la mère des enseignements du
bégaiement . Effectuez des tests de pénétration périodiques - ils vous aideront à trouver des endroits délicats dans votre défense, comme, par exemple, dans le cas 3. Vous pouvez considérer qu'il n'est pas nécessaire de patcher les systèmes dans le périmètre interne, mais cela entraîne parfois de graves conséquences.
Construisez un système de gestion des correctifs - éliminez non seulement les vulnérabilités «de haut niveau» (comme EternalBlue ou BlueKeep), mais aussi moins connues, mais non moins dangereuses dans le cas de leur fonctionnement (comme c'est le cas avec HP AM). Bref, gardez une trace de tous vos systèmes.