[WEB PENTESTING] SSL Capture Password

Nous nous mettons dans le cas d'un audit d'un site WEB utilisant le protocole SSL. Alors que la plupart des internautes y voient une sécurité certaine, l'utilisateur averti connaît les faiblesses de ce protocole quand il est mal configuré. Ce post commencera par évaluer la robustesse de la sécurité de la communication. Dans un second temps, nous exploiterons le protocole s'il peut être affaibli (ou s'il l'est déjà ...).

1 - Quelques informations nécessaires.

Le protocole SSL existe en plusieurs versions. Vous trouverez sur Internet toutes les informations nécesaires. Pour commencer, Wikipédia est certainement un bon début grâce à l'article dédié à ce protocole [ici].

Mais pour la suite, nous avons juste besoin de savoir que nous trouvons principalement sur le WEB :

• CAS 1 : Des serveurs WEB reposant sur un certificat SSLv2 vulnérable à des attaques de type Man-in-the-Middle ;
• CAS 2 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 mais supportant aussi le protocole SSLv2. Ils deviennent alors eux aussi vulnérables au mêmes type d'attaque ;
• CAS 3 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 et ne supportant que ce protocole. Ces serveurs ne sont pas vulnérables sauf si la clé de chiffrement est faible.

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

2 - Le serveur audité est-il vulnérable ?

Pour résumer la première partie, la réponse sera "oui" s'il supporte le protocole SSLv2 et/ ou s'il supporte des algorithmes de chiffrement basée sur une clé trop faible.

Pour effectuer nos tests, nous allons étudier l'outil SSLDigger de Foundstone [télécharger].

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

Après avoir lancé l'outil et entré l'adresse du site, appuyez sur le bouton "GO". De suite, nous voyons que le certificat repose sur un algorithme RSA et une clé de chiffrement de 1024 bits : c'est bon ! De plus, nous remarquons qu'il est signé par une entité reconnue.

Mais supporte-t-il aussi des protocoles faibles ? Pour cela, SSLDigger lance automatiquement les tests si vous avez cliqué sur sur "oui" sur la popup apparue à l'ouverture de l'outil. Sinon, vous trouverez un bouton "SSL test" sur l'interface.

Une fois les tests terminés, cliquez sur "oui" pour enregistrer et voir le rapport. En l'occurrence, nous voyons que des protocoles faibles sont supportés (3 exactement) :

Le détails de ces protocoles est donné plus loin dans le rapport. Il est donc techniquement possible de casser la clé de chiffrement après s'être connecté avec l'un des algorithmes comportant une clé de longueur trop faible. Cela se fait à l'aide d'OpenSSL notamment mais ce n'est pas cette voie que nous allons détailler.

Nous allons néanmoins de suite utiliser cette commande pour voir si le site audité supporte le protocole SSLv2 :

openssl s_client -ssl2 -connect www.cible.com:443

Bingo ! Nous nous connectons au serveur en SSLv2. (NB: avec le protocole DES-CBC3-MD5, l'un des protocoles repérés par SSLDigger).

Alors nous pouvons passer à la suite !

3 - Lancement d'une attaque de type Man-in-the-Middle

3.1 - Préparation

Pour mener l'attaque, nous aurons besoin d'un seul outil, Ettercap [télécharger].

Configuration (si vous utilisez ipchains/iptables) :

1. Ouvrir etter.conf ;


2. Décommenter les lignes :
   
   
   
   1. redir_command_on
   
   
   2. redir_command_off
   
   
   
   

Le scénario est le suivant :

• 1 serveur qui correspond à nos critères de la phase 2 ;
• 1 machine victime qui se connecte vers se serveur après authentification ;
  
• 1 machine pirate qui se placera entre les deux machines pour mener une attaque de type MiTM.

3.2 - Lancement de l'attaque

On commence par vérifier que toutes les machines sont localisées (en ligne de commande "T", sur l'interface eth0 "i") :

ettercap -Tqi eth0 // //

On devrait voir l'adresse de la victime et celle du routeur commun (cadre rouge) alors que l'adresse du pirate apparaît en haut (cadre vert) :

L'attaque se lance avec la commande suivante :

ettercap -Tqi eth0 -M arp -l mission /adresse-routeur/ /adresse-victim/

Vous capturerez le compte dès que la victime se connectera sur le site avec son couple login/mot de passe.

Par la suite, nous pouvons retrouver les résultats en lisant le fichier de capture :

etterlog mission.eci

The account is owned! Have fun! :)

[SECURITY] Datacenter

Lors d'un pentest pour une entreprise, vous devrez certainement vous attaquer à un Datacenter car c'est bien là que sont installés les serveurs et équipements réseau du SI de la compagnie. De suite, nous comprenons l'enjeu de sécuriser le Datacenter ... Dans ce post, nous ne verrons qu'un seul aspect de la sécurité, les contrôles logiques.

1 - Apporter et maintenir le niveau de sécurité

1.1 - Application des bonnes pratiques systématique :

Un Datacenter "vit" et même sécurisé, le moindre changement peut ébranler son niveau de sécurité. Par exemple, dans le cas de l'installation d'un nouveau serveur, les principales mesures à prendre en compte sont :

• le système d'exploitation du serveur doit être "masteriser" avec les seules applications nécessaires et une sécurisation en amont si possible ;
• seuls les comptes nécessaires doivent être autorisés à se connecter à la machine que ce soit localement ou à distance ;
• seuls les services utiles doivent tourner. De plus, ils ne doivent être lancés "automatiquement" que si cela est nécessaire pour le bon fonctionnement du serveur et des applications hébergées. Sinon, une activation "manuelle" et un service arrêté au démarrage du système est préférable. Enfin, un compte de service avec des droits restreints doit être accordé au service ;
• la configuration des modules systèmes et des applications doit être travaillée. Par exemple, seules les communications sécurisée via SSH sont autorisées. Cela passe par la configuration du service de même nom via des fichiers de configuration comme sshd_config.

1.2 - Renforcement de la sécurité d'un système

Pour assurer tous les piliers de la sécurité à une machine, il nous faudrait installer idéalement :

• un agent de sauvegarde pour la disponibilité des données ;
• un agent chargé de surveiller l'intégrité des informations (ex : Tripwire) ;
• un agent chargé de tracer les évènements pour la non-répudiation des actions (ex : Syslog) ;
• le chiffrement des disques pour la confidentialité.
  

Dans la réalité, la société devra étudier et classer ses serveurs selon sa criticité (en général, en fonction de son exposition et des données contenues). Alors, la sécurité apportées doit être en adéquation avec le niveau de criticité attribué à la machine.


2 - La gestion des incidents

Personne n'est à l'abri d'un incident. Et lorsque cela arrive, il faut être en mesure de :

• le repérer. Cela peut se faire idéalement à l'aide d'un SOC et d'une équipe de monitoring pour l'animer. Ce SOC devrait reposer sur une solution de corrélation de logs (ex : OSSIM) ;
• le cerner. L'incident peut être de nature diverse. Ensuite, il peut être plus ou moins prioritaire. Mais avant tout, il faut être sûr qu'il ne s'agit pas d'un faux positif. Il faut donc vérifier la pertinence de l'alerte reçue. Si l'alarme est justifiée, l'incident doit être signalé à toutes les personnes impliquées ;
• l'analyser et le traiter. Un incident reconnu doit être pris en charge par l'équipe sécurité. Celle-ci entame alors une investigation pour déterminer la nature exacte de l'attaque, sa provenance, ses conséquences / actions et les actions à prendre en compte dans l'immédiat pour éviter une propagation par exemple et à échéance pour éviter le reproduction d'un incident de même nature.
  

Diverses mesures permettent d'obtenir une gestion d'incident efficace. Pour citer quelques exemples, une solution éprouvée doit être mise en place pour repérer les incidents avec fiabilité, une procédure détaillée doit être instaurée pour s'assurer qu'un incident sera traité de bout en bout et les moyens doivent être mis à la disposition des opérationnels sécurité pour mener à bien la phase d'investigation.

3 - Pérennisation de la sécurité logique

Pour faire face aux menaces continues des attaquants et pour se préparer contre les nouveaux vecteurs d'attaques. Pour cela, voici un résumé des recommandations qui peuvent être mises en place :

• une gestion des mises à jour rigoureuse. En plus du déploiement d'une solution telle que SCCM pour le déploiement des mises à jour, la compagnie devrait s'abonner à une liste de veille sécurité. Ainsi, les équipes sécurité seront au courant des menaces en quasi temps réel. Alors, en cas d'attaque critique (e.g. Ver), une procédure d'urgence d'application de patch doit être déroulée ;
• effectuer un audit de configuration. Pour s'assurer que les recommandations sécurité sont appliquées correctement, des audits de configuration avant la mise en production et régulièrement devraient être planifiés. Par exemple, il pourrait s'agir de vérifier qu'une application WEB et les client autorisés ne communiquent qu'en TLSv1 pour assurer l'intégrité et la confidentialité des données échangées ;
• effectuer des audits de vulnérabilité (ou mieux, des tests d'intrusion). Pour s'assurer de la robustesse d'un équipement du Datacenter, le mieux est d'effectuer un test d'intrusion sur cet élément ou à défaut, un test de vulnérabilité. Effectués régulièrement, ils permettent de s'assurer de la sécurité de la machine dans le temps. Evidemment, cela suppose que les actions correctives sont apportées concernant les failles trouvées pendant l'audit...
  

Finalement, toutes les mesures à prendre en compte ont pour objectif de garantir la concordance entre le niveau de sécurité des équipements et la politique de sécurité de l'entreprise.

Conclusion

Le post a présenté les aspects logique en termes de sécurité IT d'un Datacenter. Cependant, les mesures apportées ne seront efficaces que si elles sont accompagnées d'une sécurité organisationnelle et physique. A quoi bon blinder ses serveurs s'il est possible d'accéder facilement à la salle contenant les machines ? A quoi bon prévoir des solutions de sécurité drastiques si elles ne sont pas (ou mal) appliquées grâce à des procédures précises et connues par les personnes impliquées ? C'est pourquoi, pour aller plus loin et aborder ces autres aspects de la sécurité, je vous propose la lecture de l'article sur la sécurisation des datacenters paru dans Hakin9 de nov/déc 2008. Vous verrez, l'auteur est très sympa ;)