[Security Solution] [Ops Mgr 2007] Be careful to not be catched!

Operations Manager (Ops Mgr) est l’outil de supervision proposé par Microsoft. Anciennement appelé MOM (pour Microsoft Operations Manager), cette nouvelle version propose des fonctions de sécurité dont le chiffrement de bout en bout. Si cette solution est capable d’auditer des événements de toute nature, l’article focalisera sur les aspects sécurité.

Etape 0 : Définition du traitement de l’information

Afin de cadrer notre sujet, il est important de distinguer les différentes étapes du traitement de l’information :

• La collecte qui consiste à récupérer les informations par des agents généralement.
• L’agrégation qui consiste à rassembler les informations et de les transférer vers un composant d’exploitation des données.
• La consolidation qui consiste à exploiter les informations (statistique, reporting, …) qui sont rassemblées et enregistrées dans une base de données associée ;
• La corrélation qui consiste à exploiter l’information de manière intelligente, basée sur des règles et une intelligence artificielle. Cela permet par exemple de déterminer une attaque grâce à la corrélation de plusieurs alertes.

En l’occurrence, la supervision d’un Système d’Information va de la collecte des données à leur consolidation.


Etape 1: Classification des données

Ce sont les données auditées qui détermineront la suite, c'est-à-dire le choix de l’outil, l’architecture, l’installation des composants et les configurations par exemple. Les questions suivantes devraient aiguiller le choix de l’entreprise :

• Quel est le but de la collecte ? (détection d’attaque, statistiques, reporting, …) ;
• Quel est l’existant de l’entreprise ? (solution de supervision déjà mise en place, logs déjà centralisés, alertes déjà remontées, incidents déjà traités, …) ;
• L’entreprise est-elle exposée ? (accès Internet, serveurs applicatifs en frontal, accès VPN, …) ;
• L’entreprise est-elle ciblée ? (peu ou de nombreux incidents ont-il été détectés ? Quelle est la criticité de ces incidents ?) ;
• Quelles sont les moyens mis à disposition ? (Espace disque, bande passante, et autre performance matérielle) ;
• Quelle est la nature des données transitant sur les réseaux de l’entreprise ? (informelle, critique, top secret, …) ;
• Etc.

La liste établie, l’étape suivante consiste à déterminer des catégories d’information comme :

• Les contrôles d’accès (ex : les tentatives de connexion) ;
• La sécurité de l’administration des serveurs (ex : gestion du domaine) ;
• La sécurité des ressources (ex : l’accès aux données sensibles) ;
• La sécurité des traces (ex : les règles de traçage) ;
• Etc.

Pour terminer, nous classons l’information par criticité :

• Le niveau critique qui demande une action urgente pour éviter un risque de compromission et de propagation ;
• Le niveau intermédiaire pour les évènements à traiter dès que possible et les preuves dans le cadre d’une investigation ;
• Le niveau basic pour les évènements additionnels qui nous apporterons des éléments nécessaires pour une action de forensics ou d’incident sécurité général.

Etape 2: Le choix de l’architecture

Nous supposons maintenant que le choix de la solution est Operations Manager 2007 qui nous servira donc d’exemple dans le reste de cet article. En voici les composants de sécurité :

• Le Root Management Server (RMS) : ce rôle est indispensable. C’est le point central de l’architecture et d’où seront déployées les configurations ;
• Le Management Server (MS) : rôle intermédiaire entre le RMS et les agents (ou le rôle Gateway Server). Il a le rôle de consolidation des informations ;
• L’Audit Collector Server (MS-ACS) : il s’agit d’un MS particulier chargé de traiter les informations de sécurité. Ils sont reliés à une base de données dédiées aux évènements de sécurité, l’Audit Database ;
• Le Gateway Server : ce rôle est une passerelle qui permet notamment de traverser des zones réseaux en assurant la sécurité des communications. A ce niveau, nous parlons d’agrégation de l’information ;
• Les Agents : ils ont pour but de superviser les serveurs ou les postes de travail. Ils ne sont pas indispensables car il existe un mode sans agent mais cela n’est pas recommandé d’un point de vue sécurité. Une fois l’agent installé sur une machine, nous pouvons configurés des Management Packs (MP), c'est-à-dire des modules dédiés à la supervision de machines particulières. Par exemple, il existe un MP Exchange 2007.

Etape suivante, le design de l’architecture. Il dépend de l’existant et des besoins de l’entreprise mais voici des principes de bonnes pratiques :

• Installer un rôle ACS par chaque zone cloisonnée du périmètre pour assurer que tous les évènements souhaités sont remontés ;
• Relier chaque ACS à une base Audit Database dans le même sous-réseau ;
• Installer chaque ACS sensible en cluster ;
• Relier les ACS à un RMS, le dernier devant être dans une zone sécurisée puisqu’il contient l’ensemble des informations de l’entreprise ;
• Installer le rôle Gateway Server avant de traverser un pare-feu. Ainsi, une seule connexion est à ouvrir entre les deux zones ;
• Installer des agents sur les serveurs et machines à auditer. En effet, le mode sans agents utilise des flux RPC et DCOM non protégés ;
• Eviter au mieux le déplacement d’information sensible ;
• Eviter au mieux la transmission d’information sur des réseaux externes ou non sécurisés (cas des entreprises internationales).

Etape 3 : Sécuriser les échanges

Par défaut, les authentifications reposent sur le protocole Kerberos v5. Cependant, il est possible de mettre en place une authentification mutuelle basée sur SSLv3.
Dans le cas où les agents et le MS ne sont pas installés sur le même domaine, l’authentification via Kerberos n’est plus possible. Par conséquent, seul SSL peut apporter la sécurité suffisante. A noter que l’exemple donné entre les agents et le MS est valable aussi entre les agents et un Gateway Server, deux MS dans un même domaine ou un MS et un RMS par exemple.
Si l’entreprise fait le choix de mettre en place une authentification avec SSL, il est recommandé d’utiliser les certificats de la PKI groupe de la compagnie.

Une fois les composants authentifiés, la communication repose sur la même sécurité que le protocole d’authentification, c'est-à-dire Kerberos ou SSL. En général, il est recommandé de mettre en place SSL dans les cas suivants :

• les données traversent deux zones et/ou deux domaines différents ;
• les données traversent une zone externe (comme l’Internet) ou non de confiance.

Etape 4 : La gestion des rôles, des comptes et des droits

Etape 4.1 : Au niveau de l’agent

L’agent doit disposer de droits suffisants pour récupérer les évènements de sécurité (notamment les Event logs de Windows par exemple). En fait, l’application des droits se fait sur un compte de service nommé agent action account. Pour fournir un minimum de droit, nous devons lui attribuer un compte de domaine avec les droits suivant uniquement :

• Membre du groupe Local Users ;
• Membre du groupe Performance Monitor Users ;
• Attribuer le droit Allow log on locally.

S’il s’agit des droits minima requis, en réalité, les droits nécessaires dépendent aussi des Management Packs déployés et des politiques de sécurité de l’entreprise.

Quant au déploiement des agents, ils requièrent des droits administrateurs via un compte dédié. Ce dernier peut ensuite être supprimé. En pratique, le déploiement pourra être réalisé par un outil tel que SCCM.

Etape 4.2 : Au niveau des serveurs

En premier lieu, un compte de service est aussi activé sur chaque composant de la solution de supervision. Les droits à attribuer sont similaires, la contraintes des Managements Packs en moins.

Ensuite, le rôle des administrateurs doit être défini pour chacun afin de lui attribuer l’un des rôles fournis par Ops Mgr. Il est important de profiter de la granularité des profiles proposés par la solution. Les rôles en question sont : Administrator, Author, Advanced Operator, Operator, Read-Only Operator et Report Operator.

Conclusion

La supervision sécurité est un sujet indispensable pour se prémunir des attaques informatiques. Autant se faire attaquer peut être grave pour l’entreprise, autant se faire attaquer et ne pas le savoir n’est pas concevable. Aussi, il est important de savoir que la supervision demande un travail en amont (la classification des informations) et en aval (comme la corrélation et la détection d’attaque) afin que le projet fournisse un réel bénéfice à l’entreprise.

NB : Bientôt, vous trouverez sur Internet une version plus longue ... patience et bonne recherche cher agent ;)

[Security Solution] [MAIL] Exchange 2007

Exchange 2007 est la nouvelle solution de messagerie proposée par Microsoft. En comparaison avec la dernière version, datant de 2003, de nombreuses fonctionnalités ont été apportées, notamment en termes de sécurité. En tant qu’agent, vous pouvez être amenés à auditer la messagerie de l’entreprise. Alors pour avoir tous les atouts de votre côté, mieux vaut connaître l’outil et trouver les pistes d’exploitation au fur et à mesure de la lecture de cette nouvelle mission. En six étapes, nous allons étudier les points de sécurité que nous pouvons rencontrer, qu’il s’agisse d’une attaque interne ou externe. Dans la situation inverse, s’il s’agit de votre messagerie, vous connaîtrez ainsi les points qui devraient être sécurisés.

Etape 1: La sécurité de l'architecture

Exchange 2007 est constitué de cinq rôles qui sont appliqués sur les serveurs lors de l’installation. Puisqu’ils peuvent être mutualisés, prendre la main sur un rôle pourra nous donner des droits sur un autre rôle installé sur le même serveur physique. Plus précisément, ces rôles sont :

• Rôle Mailbox : Normalement placé dans le LAN interne de l’entreprise car ces serveurs hébergent les bases de données contenant les emails et les profils utilisateurs et donc les données sensibles. C’est pour cela que pour des raisons de disponibilité du service de messagerie, des clusters devraient être installés. Sinon, ils pourraient être sensibles à des attaques de type DoS. A savoir : les serveurs Mailbox sont directement et étroitement liés aux serveurs AD… Dans le pire des cas, supprimer un compte de messagerie supprime un compte AD et la création d’un compte de messagerie ? Concernant les droits des administrateurs, ils ont été séparés les droits entre la messagerie et l’AD … depuis cette version d’Exchange seulement …;
• Rôle Hub Transport : Connecté aux serveurs Mailbox, ces serveurs doivent être séparés par un pare-feu. Ils représentent en fait les relais SMTP. En général, le serveur Hub Transport est installé par domaine. Attention, mal configurés, ils peuvent être reliés directement à l’Internet … ;
• Rôle Client Access Server (CAS) : Connecté aux serveurs Mailbox, ce serveur fournit les fonctionnalités de messagerie à distance (cf. Etape 3). Selon que le rôle Edge Transport est installé ou non, le CAS est le plus exposé à l’Internet et y est installé un serveur IIS. Nous devrions donc vérifier qu’il n’existe pas de faille sur le serveur WEB ;
• Rôle Edge Transport : Rôle non obligatoire. Il sert de sas entre l’Internet et le CAS. Il sera alors placé dans une DMZ. Un grand nombre de propriétés de sécurité sont définies ici tandis qu’elles seront configurées sur le Hub Transport s’il n’est pas prévu d’utiliser le rôle Edge Transport
• Rôle Unified Messaging : Ce type de serveur a surtout pour objectif d’apporter des fonctionnalités liées à la messagerie unifiée tel que la vidéo-conférence ou la synchronisation avec la VoIP par exemple. Avis aux experts !

Etape 2: La sécurité des serveurs de messagerie

Chaque rôle devrait avoir subi un hardening. Quelque soit le rôle traité, seuls les services nécessaires devraient être lancés et seuls les programmes nécessaires devront être installés. Cela peut être fait avec le Security configuration Wizard (SCW) de Windows. Ensuite, des ACL devraient être imposées sur les dossiers créés et notamment les dossiers publiques sur les serveurs Mailbox tandis qu’ils devraient être déconnectés, ils devraient ...
Pour tous les serveurs, une politique de rôles d’administration devraient être appliquée en appliquant une gestion des droits. Six profiles différents sont prédéfinis nativement dans Exchange 2007, le but étant d’appliquer le principe de « moindre privilège ». Ici, il faut miser sur des rôles attribués de manière trop laxiste.

Ensuite, nous un antivirus dédié et une solution anti-spam devraient être installés. Qu’il s’agisse de la solution Forefront Security for Exchange proposée par Microsoft ou non selon ses besoins, les solutions retenues utilisent normalement une architecture 64bits et proposent des protections adéquates pour ce système de messagerie. Il faudra donc identifier la présence puis la nature de ces solutions si nous avons besoin de les contourner.
Pour terminer sur la partie serveur, ces derniers devront bénéficier d’une solution de backup, de monitoring et de haute disponibilité. Si ce n’est pas le cas, il sera plus facile de ne pas laisser de traces pour l’attaquant.


Etape 3: La sécurité des clients de messagerie

Les clients de messagerie sont Outlook 2007 (client lourd), OWA (Webmail) et Outlook Anywhere (Outlook avec accès distant).

Etape 3.1 : Authentification

Exchange 2007 peut bloquer les communications entre un serveur Mailbox et une version d’Outlook autre que 2007. Ensuite, il faut savoir que les fichiers personnels de l’utilisateur, et donc sensibles, sont présents sur chaque poste client mais non chiffrés … La solution proposée par Microsoft est d’utiliser le chiffrement EFS ou BitLocker.

Concernant OWA, l’authentification par défaut s’effectue via un mot de passe et utilise le protocole Kerberos ou NTLM en cas d’échec. Il se trouve que des outils comme rozntlm permettent de tester les connexions NTLM … Il est cependant possible d’utiliser une authentification forte reposant sur des Smart Cards avec code PIN pour chiffrer les communications via SSL.

Quant à Outlook Anywhere, l’authentification se fait par mot de passe (via NTLM ou le mode Basic) puis les flux peuvent être chiffrés avec SSL. Pour cela, il conviendra de configurer un serveur IIS sur les serveurs Edge Transport (ou les CAS si non installés).

Etape 3.2 : Limitation des risques de propagation virale et de spams

Outlook et OWA sont capables de filtrer les emails en fonction des extensions des pièces jointes. Plusieurs niveaux de blocage peuvent être configurés.

Les fonctionnalités d’anti-spam proposées reposent des listes (blanches et noires), le contenu des messages (à base de mots clés) et un filtre comportemental.

Enfin, l’Object Model Guard a pour but de vérifier qu’un programme illicite n’essaie pas d’atteindre le carnet d’adresses ou d’envoyer un email avec le profil de l’utilisateur.

Etape 4: La sécurité des communications

Etape 4.1 : La sécurité des communications serveur <-> serveur

La grande nouveauté d’Exchange 2007 est la possibilité de chiffrer les communications en utilisant le protocole SSL/TLS avec authentification mutuelle entre les serveurs via certificats. Si par défaut Exchange propose l’installation de certificats auto-signés il est recommandé de mettre en place des certificats générés par la PKI de l’entreprise et les faire signer par l’autorité de certification racine. Il est aussi possible d’utiliser IPSec à la place de ou en plus de SSL/TLS.

Etape 4.2 : La sécurité des communications serveur <-> client

Autre nouveauté d’Exchange 2007, le chiffrement des communications entre Outlook 2007 et les serveurs Exchange (les serveurs Mailbox pour être précis). Côté client, cette option devraient être appliquée et imposée au client par GPO. Si cela n’est pas le cas, nous pourrons sur le poste client désactiver les options de sécurité en nous baladant dans les menus d’Outlook.

Etape 5: Renforcer le niveau de sécurité

Etape 5.1 : Appliquer les restrictions

Pour des raisons de performance, la taille des emails entrants et sortant et le nombre de destinataires sont certainement limités. Ces restrictions peuvent être contrôlées à plusieurs niveaux : au niveau de l’entreprise, du périmètre Exchange 2007, des connecteurs, des serveurs ou des utilisateurs.

Dans un deuxième temps, il est possible que des listes d’expéditeurs soient paramétrées. Si l’expéditeur fait partie de la liste, plusieurs actions pourront de dérouler : accepter le message, refuser le message ou demander à ce que tous les expéditeurs soient identifiés.

Etape 5.2 : Le filtrage des emails

Avec Exchange 2007, il existe de nombreuses méthodes pour filtrer et/ou traiter les messages à implémenter sur les serveurs Hub Transport pour être sûr que chaque email est traité :

• Le blocage des emails selon l’extension ou le contenu d’un fichier de type MIME ;
• Le filtrage des expéditeurs qui se fait sur l’analyse du contenu du champ MAIL FROM.
• Le filtrage des destinataires dont l’analyse porte sur le contenu du champ RCPT TO ;
• Identification du serveur SMTP expéditeur : Il s’agit de vérifier que le serveur SMTP envoyant le message appartient bien au domaine auquel il prétend ;
• Evaluer la réputation de l’expéditeur : grâce à un algorithme, il s’agit d’attribuer à l’expéditeur un niveau de réputation ;
• Le postmark : Il s’agit d’un marqueur qui est placé dans l’entête de l’email envoyé pour s’assurer qu’il ne s’agit pas d’un courrier indésirable ;
• Le blocage de l’affichage des images ;
• La classification des messages : l’expéditeur peut attribuer une classe à son message (ex : « confidentiel »). En fonction de cette classe, une action pourra être exécutée.

Etape 6 : La maintenance du niveau de sécurité

Selon que l’entreprise met en place ou non des actions de maintenance en termes de sécurité, il sera plus ou moins facile pour l’attaquant de percer la sécurité de la messagerie dans le temps :

• Les outils de vérification tels que Microsoft Exchange Best Practices Analyzer, MBSA, IIS Lockdown tool devraient être lancés régulièrement (ou les contrôles de SCCM) ;
• La sécurité devraient être évaluée grâce à des tests de vulnérabilité sur les serveurs de messagerie et des audits de configuration sur les serveurs et les clients ;
• Une gestion des mises à jour devrait assurer que les serveurs ne sont pas exploitables par les nouvelles failles ;
• Une gestion des traces pour des raisons légales, pour la gestion des incidents et le recouvrement des emails devrait être configurée.

Pour plus d’information, je vous laisse trouver dans quelques jours, sur Internet une version (plus !) longue de ce Post.

[PENTESTING] [VULNERABILITY ASSESSMENT] Nessus Reloaded

Le scanner le plus connu vient de sortir une nouvelle version hier : nous parlons de Nessus 3.2 ! Il aurait donc été dommage de ne pas en parler ici mais en tant qu'agent entrainé, nous allons voir l'aspect sécurité de ce scanner ... de sécurité ;) Ensuite, nous ferons un tour d'horizon de cette nouvelle version.


I - Installation ... et sécurité !


I.1 - Installation de la solution

Pour commencer, NESSUS 3.2 est téléchargeable ici. Les nouvelles fonctionnalités proposées sont énumérées (brièvement...) ici. Choisissez votre plate-forme et c'est parti. Si vous l'installez sur une machine Windows, l'installation se résumera ni plus ni moins à du "next" :). Vous remarquerez que plus de 20.000 plugins seront téléchargés . La base continue à s'alimenter et c'est l'une des grandes forces de NESSUS. Une fois l'installation terminée, deux modes d'authentification sont possibles.

I.2 - Authentification et communication

NESSUS a déjà été abordé lors d'un précédent [post]. Une des idées à retenir est que cet outil fonctionne en mode client / serveur.
Il existe deux méthodes d'authentification avec NESSUS :

• Une authentification basique par login / mot de passe ;
• Une authentification mutuelle via certificats entre le serveur et le client NESSUS.

Il faut savoir que par défaut, une authentification basique est mise en place avec un compte par défaut dont le login est localuser et le mot de passe ... nessusdPwd ! Pour trouver ce mot de passe, il y a plusieurs pistes mais la plus simple se trouve certainement sur cet autre [post] ;). Afin d'éviter que votre serveur NESSUS fasse partie d'un botnet, il vaudrait supprimer ce compte. En effet, un scan horizontal sur le port 1241 et utiliser ce compte pourrait éviter à certains hacker d'avoir à installer NESSUS et d'utiliser votre bande passante.
A moins que vous soyez aussi généreux :), quelques actions devraient être prises en compte :

• Utiliser l'authentification par certificat si votre serveur NESSUS est installé sur une machine distante. Cela apportera bien sûr une meilleure authentification et le chiffrement des communications entre le serveur et le client NESSUS grâce aux protocoles SSL/TLS. Cela se fera grâce au gestionnaire de comptes : %system%\Tenable\Nessus, lancer UserMgmt.exe, puis add pour ajouter un nouvel utilisateur;
• S'il s'agit d'une installation en local ou que vous ne pouvez employer l'authentification par certificat pour une certaine raison, il vous faudra renforcer autant que possible l'authentification basique :
1. Changer le port d'écoute par défaut (pour éviter les scans horizontaux sur le port 1241);
2. Créer un compte pour chaque utilisateur (question de traçabilité et de non-répudiation). Pour cela, cette opération se fait via le gestionnaire de compte encore une fois;
   
3. Supprimer le compte par défaut déjà évoqué. Pour cela, supprimer le répertoire localuser qui se trouve dans %system%\Tenable\Nessus\users\. C'est ici que se trouve les logins et hashs des mots de passes. Aussi, supprimer les infos relatives aux comptes inscrites dans le fichier Connections.xml situé dans le répertoire du profile utilisateur : %profile%\Local Settings\Application Data\Tenable\Nessus client.
   

Maintenant que vous avez sécurisé la solution, que vous avez un compte, il est temps de tester cette nouvelle version !


II - Lancement immédiat !

Ce qui fait la force de NESSUS en plus de son architecture client / serveur, ce sont ses possibilités de configuration. Ainsi, nous pouvons être sûr qu'il saura s'adapter à vos besoins et apportera des résultats pertinents et moins (la perfection n'existe pas ;) de faux-positifs. Et cette version 3.2 ne me contredira pas car les options sont plus nombreuses et les résultats plus précis.

II.1 - Configuration

Toute la configuration se fait via le client NESSUS. Il nous suffit de lancer ce module pour commencer cette phase. En premier lieu, il nous faut choisir la cible sur laquelle nous allons travailler :

La configuration peut être évitée grâce aux deux polices proposées par défaut. L'une permet de vérifier le niveau de patchs d'une machine Windows est l'autre propose un scan dit "standard". Allons au fond des choses et créons nous-même un police. A travers les fonds d'écran suivant, vous verrez un exemple de configuration. En réalité, le but est de vous donner un aperçu des panneaux de configuration et des fonctionnalités offerte par NESSUS 3.2.







Après avoir sauvegardé cette "policy", nous lançons le scan. Une fois terminé, nous obtenons un rapport.
Sur la colonne de gauche, les services trouvés apparaissent avec des couleurs différentes. Le rouge signifie que la vulnérabilité la plus importante concernant le service en question est de niveau critique. En cliquant dessus, nous apercevons, dans la fenêtre droite, que de nombreuses failles ont été trouvées dont des vulnérabilités critiques comme une version de JRE non mise à jour vulnérable à une attaque de type Buffer overflow :


Je n'ai plus qu'une dernière chose à vous dire : have fun!

[PENTESTING] [DNS] Look for subdomains

Lors de notre dernière mission, nous avons étudié un outil permettant de trouver les domaines pertinents comme les entreprises en relation avec notre cibles. Une fois cette liste en notre possession, nous allons essayer pour chaque élément d'aller aussi loin que possible. Pour cela, le DNS sera notre arme pivot. pour l'exploiter, nous utiliserons le couteau suisse pour ce genre d'attaque, dnsenum.

I - Installation de l'outil

Tout d'abord, téléchargez l'utilitaire ici. Il s'agit donc d'un script PERL. Avant de pouvoir l'installer, il nous faut installer un certain nombre de modules comme indiqué dans le fichier README.txt :

• Net::IP
• Net::DNS
• Net::Netmask
• Net::Whois::IP
• HTML::Parser
• WWW::Mechanize
• threads
• threads::shared
• Thread::Queue

Les modules peuvent être installés de deux manières (exemple avec Net::IP) :

1ère méthode : manuellement

A noter que les modules perl se trouvent sur le site http://www.cpan.org/modules.

1. Télécharger le tarball ici ;
2. Le décompresser :

1. $ tar -zxvf Net-IP-1.25.tar.gz

3. Installer le module :
   

$ cd Net-IP-1.25/
$ perl Makefile.PL
$ make
$ make install

A noter si vous rencontrez des problèmes pour installer le module HTML::Parser (comme moi ;)), vérifier que le gcc est à jour et/ou que libc-dev est installé et à jour (sur Debian) :

$ dpkg -l | grep gcc
$ dpkg -l | grep libc-dev

Et éventuellement :

$ apt-get install gcc libc-dev

2e méthode, l'installation automatique :

$ perl -MCPAN -e 'install "Net::IP"'

II - Utilisation de l'outil

Nous sommes prêts ! L'outil va étudier la cible en plusieurs étapes. Ce que nous allons voir tout de suite.

Lancement de l'attaque :

Pour utiliser toutes les possibilités, nous utiliserons la commande suivante :

$ perl dnsenum.pl -v -f dns.txt domaine_cible

avec :

• -v : verbose ;
  
• -f : bruteforce. Le fichier peut être dns.txt - fourni avec l'outil mais qui devrait être personnalisé - contient un dictionnaire de noms DNS probables comme dns1. Le but est de trouver de nouveau sous-domaines ;
• domaine_cible : par exemple, google.com
  

Déroulement de l'attaque :

Comme nous allons le voir, la plupart des étapes pourraient être effectuées manuellement. Nous en verrons donc les commandes (certainement déjà connues) ainsi que le résultat pour chacune. Pour exemple, notre "cible" sera lemonde.fr.

1 - Obtention de l'adresse IP

Commande manuelle équivalente ?

$ dig lemonde.fr

Résultat ?

lemonde.fr. 550 IN A 195.154.120.129

2 - Trouver les serveurs DNS primaires (champs NS)

Commande manuelle équivalente ?

$ dig NS lemonde.fr

Résultat ?

$ ns2.te-dns.net. 304 IN A 62.210.64.52
$ ns1.te-dns.net. 304 IN A 212.83.156.82

3 - Trouver les serveurs de messagerie (champs MX)

Commande manuelle équivalente ?

$ dig MX lemonde.fr

Résultat ?

smtp0.lemonde.fr. 600 IN A 194.3.81.5
smtp1.lemonde.fr. 600 IN A 194.3.81.6

4 - Trouver les transferts de zones (champs AXFR)

Commande manuelle équivalente ?

$ host -l lemonde.fr ns1.te-dns.net
$ host -l lemonde.fr ns2.te-dns.net

Résultat ?

Transfer failed

Les transferts de zone ne sont donc pas autorisés pour ce domaine...

5 - Google-scrapping

Commande manuelle équivalente ?

N/A

Résultat ?

N/A


6 - Trouver des sous-domaines supplémentaires par Brute Force (option -f )

Commande manuelle équivalente ?

$ dig .lemonde.fr

Avec , un des mots de la liste contenue dans dns.txt (par exemple).

Résultat ?

blog.lemonde.fr. 241 IN A 195.15.120.132
forum.lemonde.fr. 600 IN CNAME forums.lemonde.fr.
forums.lemonde.fr. 600 IN A 195.154.120.161
...
ftp.lemonde.fr 257 IN A 194.3.81.226
...

Nous pouvons voir certain service dès cette étape très intéressant dans le cadre d'un pentest comme FTP en plus d'un serveur mail (étape 3).

7 - Enumérer les plages d'adresses de classe C et lancer des requêtes WHOIS

Commande manuelle équivalente ?

$ whois lemonde.fr

Résultat ?

194.3.81.0/24
195.154.120.0/24

8 - Lancer des requêtes reverse lookups sur les plages d'adresses récupérées en 8 -, ainsi que les adresses récupérées via WHOIS (toujours en 8 -)

Commande manuelle équivalente (en testant toutes les adresses IP obtenues en 8 -) ?

$ nslookup

Résultat ?

135.120.154.195.in-addr.arpa. 600 IN PTR cacheman.lemonde.fr.
140.120.154.195.in-addr.arpa. 600 IN PTR pan.lemonde.fr.
...

9 - Ecrit l'ensembles des adresses dans un fichiers de type domaineclible_ips.txt

Commande manuelle équivalente ?

N/A

Résultat ?

$ cat lemonde.fr_ips.txt
195.154.120.135/32
...
195.154.120.168/30

[PENTESTING] [Information gathering] Find the relevant information

La mission du jour, cher agent, est de vous former à la récupération d'information. En effet, cette étape est cruciale lors d'un test d'intrusion. C'est même la première à considérer et celle qui pourra faire la différence par la suite. Vous connaissez certainement des pistes pour trouver sur Internet des informations sur votre cible: bases WHOIS, annuaires et moteurs de recherche, newsgroups, etc...

Mais saurez vous trouver les portes plus cachées ? La porte d'entrée ouverte d'une filiale qui vous facilitera certainement grandement la tâche ... A vous de jouer !

Automatisation des recherches

L'information que l'on recherche se trouve très certainement sur Internet mais il s'agit clairement, la plupart du temps, de chercher une aiguille dans une botte de foin ! Alors dans ce cas, brûlons le foin me direz-vous ! Notre "brûleur" pourrait très bien être la suite BiLE car cet outil a pour objectif de trouver les liens entre les sites de manière automatique et, dans notre cas, les sociétés qui pourraient être en rapport avec notre cible. De plus, cette suite est capable de noter la pertinence des résultats trouvés. Voici un bon départ pour notre test ! Alors passons à l'action !

Installation de la solution

Pour récupérer la solution, il suffit de ce rendre sur le site de Sensepost et après enregistrement, on obtient la suite BiLE. Nous décompressons le fichier obtenus pour récupérer les fichiers Perl qui nous intéresse. Aussi, nous avons besoin de httrack (aspirateur de site WEB). Voilà, nous sommes prêts !

Exécution des scripts

Notre recherche va s'effectuer en deux étapes en exécutant l'un après l'autre les scripts suivants:

• BiLE.pl pour trouver les liens avec notre cible;
• BiLE-weigh.pl pour pondérer les résultats trouvés avec BiLE.pl.

Le premier script se lance de la manière suivante (ex avec www.blackhat.com):

perl BiLE.pl www.blackhat.com blackhat_1.txt

Une fois terminé, le script génère un fichier *.mine. En l'ouvrant, on obtient ce genre de résultats :

site1:site2

Les relations sont donc établies. Le deuxième script va nous permettre de pondérer ces liens:

perl BiLE-weigh www.blackhat.com blackhat_1.txt.mine

Cette fois, nous obtenons un fichier *.mine.sorted:

Pour comprendre la pondération attribuée, il faut juste savoir que plus le nombre est important, plus la relation entre les deux sites est forte. Nous obtenons de nombreux résultats mais peu en réalité avec une pondération pertinente. Quoiqu'il en soit, voici des pistes qui nous seront certainement bien utiles ;)

Comment ça marche ?

Nous allons expliquer ici en quelques mots le fonctionnement des deux scripts utilisés.

Le script BiLE.pl

Ce premier script repose sur deux choses :

• HTTRACK ;
• GOOGLE.

Le premier permet de récupérer les pages du site cible et de lire ainsi les liens qui figure dans le code sources de celles-ci. Quant à Google, il joue son rôle de moteur de recherche pour savoir à qui correspond chaque lien récupéré. Les relations entre sites sont ainsi établies.

Le script BiLE-weigh.pl

Ce second script ajoute une pondération donc. Pour cela, plusieurs critères sont à retenir :

• Les liens "entrants";
• Les liens "sortants";
• Les relations entre les liens.

Concernant les liens entrants, ce sont les sites qui contiennent un lien vers notre cible. On comptera donc le nombre de liens entrants. Mais si un site ne contient qu'un seul lien et que celui ci est notre cible, alors, il aura plus de poids que s'il contenait une centaine de lien dont un vers la cible. Voici un extrait du code concernant les liens entrants avec ws, weight-source et wd, weight-destination):

if ($src eq ){
$newsites{$dst}=$newsites{$dst}+($sites{$src}*(1/$ws));
}

Quant aux liens sortants, il s'agit d'énumérer les liens du site cible vers les autres sites en relation. De le même façon que pour les liens entrants, si un site de notre cible ne contient qu'un seul lien vers un certain site relation, ce lien aura plus de poids que si le site cible en contient une centaine vers différents site en relation. Voici un extrait du code concernant les liens sortants :

if ($dst eq @ARGV[0]){
$newsites{$src}=$newsites{$src}+($sites{$dst}*(0.6/$wd));
}

Pour terminer, les occurrences entre les sites en relations sont étudiés. Notamment, si nous trouvons de nombreux liens vers notre cible ET vice-versa, ces deux sites sont certainement étroitement liés.
Enfin, un ratio est appliqué en faveur des liens vers la cible (6:10) que nous avons pu noter plus haut déjà. Ces deux lignes de code nous le montrent entre deux sites relevés :

$newsites{$dst}=$newsites{$dst}+($sites{$src}*(1/$ws));
$newsites{$src}=$newsites{$src}+($sites{$dst}*(0.6/$wd));

Voilà qui devrait nous faire gagner du temps pendant nos recherches. Cela tombe bien, le temps vous est compté cher agent !

Pour aller plus loin [PDF].

[PENTESTING] Be careful about clear text protocol...

Un serveur sécurisé, c'est bien mais l'utilisation d'un protocole en clair peut anéantir les efforts de sécurisation. En effet, les protocoles comme FTP, Telnet, Rlogin et bien d'autres fonctionnent avec une méthode d'authentification faible, c'est-à-dire un couple mot de passe / login mais pire, le mot de passe est transmis en clair, ainsi que les communications. Une solution qui vous vient certainement est de sortir votre sniffer préféré (ex : wireshark). Bonne idée ! Surtout si la machine cible est sur le même réseau que le votre. Sinon, nous allons voir une autre méthode qui pourra s'avérer plus simple dans le cas d'une machine cible distante.

Contexte de l'attaque

Nous effectuons un test d'intrusion sur un serveur qui utilise un protocole en clair. Nous utiliserons pour exemple Telnet qui est - malheureusement - bien trop utilisé ... Le but de la mission est de localiser l'Agent J et de prendre possession de son compte ... Prêt à relever le défi ?

Première chose, la machine est-elle vulnérable ?

$ nmap -sS -sV -p 23,79 192.168.0.102

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-02-16 16:03 EST Interesting ports on 192.168.0.102:
PORT STATE SERVICE VERSION
23/tcp open telnet Linux telnetd
79/tcp open finger Debian fingerd Service
Info: OS: Linux
Nmap finished: 1 IP address (1 host up) scanned in 6.250 seconds

Les deux démons dont nous avons besoin sont présents et actifs sur le serveurs cible : telnet et finger. Ce dernier n'est pas obligatoire mais nous facilitera la tâche comme nous le verrons dans le paragraphe qui suit.

Déroulement de l'attaque

Pour obtenir l'accès sur la machine, nous avons besoin dans un premier temps du login. Il peut être obtenu de plusieurs manières. Si par social engineering ou en sniffant cela n'a pas été possible, un autre possibilité est le démon finger s'il tourne sur la machine distante. C'est notre cas !

$ finger @192.168.0.102
[192.168.0.102]
Login Name Tty Idle Login Time Office Office Phone
agentJ secret *:0 Feb 16 15:47
root root pts/1 Feb 16 15:48 (:0.0)

Nous avons franchi la première étape en découvrant le login de l'utilisateur cible ! Il s'agit d'agentJ.

Maintenant, il nous reste à trouver le mot de passe. Pour cela, nous allons sur le site de packetstormsecurity pour y trouver :

• Un fichier contenant des mots de passe (prenez le fichier qui vous semble le plus pertinent);
• Un script perl pour casser le mot de passe de la session telnet.

Un peu de préparation ...

Pour que tout puisse fonctionner correctement, il faut décompresser le fichier contenant les mots de passe :

uncompress <fichier>

Dans le même répertoire, décompresser le fichier contenant le script perl (Telnet_crack.pl).

tar -xzvf Telnet_crack.tar.gz
cd Telnet_crack
tar -xvzf Net-Telnet-X.XX.tar.gz (avec X.XX, le numéro de la version)
cd Net-Telnet-X.XX
perl Makefile.PL
make
make install

Voilà, vous êtes prêt !


Crackage du mot de passe

Il nous suffit de lancer la commande suivante :

perl Telnet_Crack.pl -h 192.168.0.102 -u agentJ -P <fichier_mdp>

Pour obtenir :


Trouvé ! Le mot de passe est donc Missi0n_/\ccomplished.

Vérifions tout de suite notre résultat :



Nous nous sommes bien connecté avec le compte de la victime ...


Conclusion

Nous venons de voir un exemple de prise de contrôle d'un serveur via un service utilisant les texte en clair. A noter que d'autres outils existent pour cracker Telnet et les protocoles non chiffrés en général comme Brutus par exemple. Heureusement, des méthodes de sécurisation existent ! Par exemple, le service Telnet, quitte à être utilisé, aurait dû être "wrappé" pour en limiter l'accès. Mieux mais peu connu, il existe l'outil telnet-ssl où les communication sont chiffrées avec SSL comme son nom l'indique. Encore, mieux, utiliser des protocoles plus sûr comme SSH qui ont aussi l'avantage de permettre l'utilisation d'un authentification plus forte via des clés asymétriques. Cependant, pour des raisons "historiques" ou pour ne pas empêcher le fonctionnement de script sur des serveurs en production, le service Telnet est toujours utilisé...

[INFORMATION GATHERING] Are you a fashion victim?

Aujourd'hui, une idée m'est venue (hé oui !?). Toute bête en soi mais tout de même, elle amène la réflexion. Pour aller droit au but, je ne sais pas si vous avez remarqué, mais vous êtes pistés ! Attention cher agent, notre agence déniera tout lien avec les services secrets en cas de problème !

Au départ, un effet de mode ...

Vous avez certainement fait l'objet d'une invitation de site de "rassemblement". Pis, vous vous y êtes incrits vous-mêmes ! ;) Que ce soit professionnel avec des sites comme linkedin ou personnel comme facebook, l'homme aime faire partie d'un groupe et se fait entourer de ses collègues ou ses amis. Que ce soit pour des opportunités de travail ou tout simplement pour ne pas perdre contact avec des collègues ou amis, le profil de chacun est inscrit quelque part sur le net. Bref, un simple effet de mode !

... Sauf que ...

Sauf qu'à force d'être inscrit partout, il devient de plus en plus facile de recouper les informations ! et là, "c'est le drame !" En effet, maintenant, si vous avez le "malheur" de poser un question sur un forum, de poster un article dans un blog ou dans un newsgroup, nous remarquons une chose : le WEB évolue, prend de l'ampleur - avec des moyens d'expression comme le blog - et nous y la faisons de moins en moins attention à ce que nous laissons comme traces et informations. A la base, les informations ne sont pas forcément pertinentes. Sauf que, à force de multiplier les sources, le recoupement se fait de plus en plus facilement. En effet, cette méthode de recherche d'information est connue de tout pentester et de tout curieux, mais ce que nous notons, c'est que c'est de plus en plus valable avec le temps ...

Si certaines personnes vont penser à faire attention à ne pas divulguer de renseignements sensibles dans un post, vont-elles penser dans le même temps qu'elles ont dit il y a quelques mois avoir qu'elle travaille pour telle ou telle société ? Déjà, vous commencez à comprendre ...

L'illustration par l'exemple

EXEMPLE 1:

Par exemple, imaginez une personne qui écrit dans un forum pour signaler, en tant qu'administrateur système, qu'il ne connaît pas les moyens pour sécuriser son serveur DNS (problème de transfert de zone). Si la personne n'a pas déjà donné son nom, il pourra certainement être retrouvé dans son profil (quitte à s'incrire avec un compte bidon sur ce même site). Au pire, quelques recherches Google feront le lien entre le pseudo et le nom. Ensuite, le nom en poche, il suffit de se rendre sur un site comme linkedin et là, vous retrouverez le profil professionnel de la personne cette fois. Bingo, vous savez où elle travaille, dans la société CompagnieSecrete.

(Par exemple, allez faire un tour dans la partie "Experience" de linkedin d'une personne).

Quoi, l'administateur a dit avoir rencontré des problèmes de transfert de zones sur son serveur DNS ? Mais mes mains s'agitent déjà, elles tapent des DIG NS CompagnieSecrete.com ?!? Oh non, maintenant, elles se mettent à écrire des host -l !!!

Oups, je crois que l'on ne retrouvera jamais le corps de cette personne.

Et vous, cher agent lecteur, on ne peut rien apprendre de vous ? Rien de compromettant ? Sûr ???

EXEMPLE 2:

Même pas peur ? Alors je vois que vous avez de l'entraînement mais là, nous allons voir vos limites. Par exemple, a tout hasard, prenons le profil de ... Jérôme KERVIEL (non non, nous n'en avons pas assez parlé ;). Savez-vous que son profil est disponible sur le site linkedin ? Maintenant, savez-vous que nous pouvons y retrouver ses contacts ??? Hé bien j'espère ne pas vous y retrouver ! Vous pourriez être dans de sals draps ! Mais ??? c'est qu'il EST dans mes contacts !

Finalement, le recoupement d'information n'est même pas obligatoire. Ces sites "à la mode" nous donnent déjà du fil à retordre à eux seuls.