<

<

<

<

<

<

<

<

<

]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=49 http://www.randco.fr/?p=actualites&ID=49 http://www.randco.fr/?p=actualites&ID=49 <

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

<

]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=48 http://www.randco.fr/?p=actualites&ID=48 http://www.randco.fr/?p=actualites&ID=48 Dans le cadre de notre activité, un client, dont le serveur web semblait suspect, nous a demandé de réaliser une investigation de l'un de ces serveurs.

Description du système:

Le système analysé est un Linux  Ubuntu hébergant une application web accessible sur Internet et déployé via Apache. Le serveur est une VM hébergé sur un ESX 3.0, Quelques mois auparavant, nous avions procédé à un autre Forensic d'une de ces VMs (serveur), et nous avons découvert que le système était compromis, le Hacker a profité d'un phpMyAdmin ancien, accessible et non sécurisé, voir http://www.exploit-db.com/exploits/8921 .

 Malheureusement, notre client utilise le même mot de passe pour toutes les VMs présentes sur cet ESX, ce qui a certainement joué un rôle dans tout cela.

Travail sur un clone 

La machine compromise est installée sur un ESX, nous n'avions donc qu'à cloner cette VM pour l'analyser. Dans le cas contraire nous aurions été contraints de préparer une autre machine distante qui aurait reçu les résultats des analyses tout comme les fichiers corrompus.

En effet un rootkit ou des binaires modifiés (ls, cd, netstat...etc.) peuvent être présents, faussant ainsi les résultats. Dans notre cas nous pouvons travailler tranquillement à l'analyse sans nous soucier de modifier le système grâce aux snapshots

Les étapes d'un Forensic sont longues et dépendent du système à analyser. Nous allons dans cet article présenter les étapes les plus importantes.

Premières étapes

Premièrement, une analyse des logs et des fichiers clés nous permet de restreindre l’étendue des recherches et d’établir les premières pistes.

Voici quelques points qui pourraient vous être utiles :

• le fichier /etc/passwd contient une entrée laissant penser à l’infection du système par un bot IRC.
  

• Nous remarquons aussi que que le fichier log  /var/log/secure est très volumineux (700MB), son analyse révèle une attaque de type brute force sur ssh(22) et ftp(21).
• Autre point suspect, le fichier history du compte root est vide.

On peut vérifier alors le contenu de /var/log/auth, pour voir les dernières connexions. Cela dit, si l'intrus a pensé à effacer l’historique, il a certainement pensé aussi à effacer ses traces.

Nous n'avons pu trouver aucune trace dans les logs qui ont peut être été nettoyées par un éventuel pirate. Par conséquent, nous avons supposé la présence d'un rootkit sur le serveur.

Une étape nécessaire fut donc de passer cette Ubuntu aux analyseurs de rootkit et Antivirus connus à savoir : ·

• Chkrootkit
• Rkhunter
• ClamAV

L’exécution des ces « anti-rootkit » et Antivirus n'a pourtant rien donné. La détection de binaires modifiés reste une étape fastidieuse (c'est dans ces moments que nous nous apprécions l'importance des logiciels tel que Tripwire ou Samhain pour le contrôle d'intégrité des fichiers, et qui nous alertent lors de la modification de ceux-ci)

Nous avons poursuivi notre recherche via l’étude des différents processus. #netstat -lantp

A la vue de ce screenshot , l’application utilisant le port 22(ssh) est de toute évidence une piste à creuser à cause des caractères non imprimables affichés à l'écran.

La commande "lsof -in" révélait le même résultat, d'autant que l'emplacement du binaire était buggé/crypté. Il suffit alors de chercher le pid dans /proc/PID et exécuter ensuite "ls -al" pour avoir l'emplacement exacte.

La découverte

Le démon SSHd est probablemnt vérolé, mais nous devons le prouver !

Nous notons que la version affichée est : OpenSSH_4.3p2 Debian-8ubuntu1.1 .. ce qui est la plus récente sur cette plateforme à cette date

A notre connaissance, il n'existe pas de backdoor spécifique à cette version : il s'agit donc sans doute d'un "vieux" code source de Backdoor SSH, modifié pour inclure une bannière actuelle, et qui a ensuite été repackagé.

Nous remarquons que la taille du binaire (2.3M) est nettement supérieure à un sshd normal (~ 500k) obtenue sur une installation saine réalisée en laboratoire dans une version d'OS identique.

Les bibliothèques linkées sont ,elles aussi, différentes : ce sshd2 est certainement un binaire compilé (majoritaire statiquement) sur un autre système, que le hacker a juste déposé sur le serveur et a exécuté.

L'avantage ce cette méthode est qu'il n'a eu besoin sur la machine compromise ni d'un compilateur ni des librairies nécessaires : tout est dans le binaire ! (d'où le nom de kit)

L'inconvénient (pour le pirate) de cette méthode est un avantage pour nous : la taille du binaire a éveillé nos soupçons !

D'ailleurs nous ne sommes pas les premiers sur Internet à avoir remarqué cette anomalie (cf http://jhodges.co.uk/ssh-unknown-option-t/ ).

Detection des flux réseaux entrants et sortants

Supposant qu'il existe un canal de communication entre le serveur compromis et le pirate, nous commençons par mettre des règles iptables qui vont permettre de logger les nouvelles connexions qui pourraient éventuellement être établies, comme l'envoi des mots de passe des utilisateurs qui se connectent ou alors une simple notification.

(Nous observerons effectivement des paquets RST lorsque nous "killerons" le process SSHd, alors que cette connexion TCP n'était pas visible sur le système).

Chaque nouvelle connexion sera enregistrée dans le fichier /var/log/kern.log.

Analyse du Backdoor SSH

L'analyse d'un binaire est une étape délicate, qui prend du temps. Plusieurs types d'analyses peuvent être effectuées comme l'analyse de l'exécution du binaire en temps réel et voir comment il se comporte suivant différents évènements.

Dans notre cas nous avons commencer en analysant les chaînes de caractères présentes dans le binaire via la commande «strings». En effet, ayant déjà analysé quelques types de Backdoor SSH, nous savons par expérience que cette recherche pourrait donner des résultats probants.

Nous nous lançons donc dans la recherche des chaines de caractère suspectes. Deux chaînes (parmi les milliers de lignes présentes) attirent notre attention :

Nous consultons le contenu du fichier /etc/sinux  ...

Bingo ! Celui-ci est la liste de tous les utilisateurs qui se sont connectés sur le système (avec mot de passe, adresse IP source et heure de connexion).  

Par déduction, cela nous permet d'évaluer la date de compromission.

Le principe de la plupart des backdoor SSH est de permettre au hacker de se servir d'un mot de passe dit Magic (dans le cas présent "bluechamp1835"), qui lui permet de se connecter au serveur sans que son activité ne soit inscrite sur aucun des fichiers de logs mais aussi de cacher sa présence, et en la rendant indétectable via les commandes (w, who...etc.)

Effectivement le compte root/bluechamp1835 permet bien de se connecter en SSH...

Un md5sum du fichier binaire nous donne:

Au final, seul sshd et quelques autres fichiers (sftp...etc.) semblent avoir été modifiés. Malheureusement, nous ne pouvons pas en être certains. Le système a été compromis en tant que root, cela veut dire que le pirate a pu modifier n'importe quel binaire présent.

Nous recommandons, dans ce cas, la réinstallation du système du simple fait que l'analyse de tous les binaires prendrait beaucoup plus de temps/argent que sa réinstallation, mais elle est surtout plus sûre.

Conclusions

Le travail de forensic doit s’effectuer sur une copie du système (dd, ghost).

 Dans notre cas, l’utilisation d’une VM à été très utile. (Configuration d’un environnement similaire)

L’utilisation de scans (Anti-virus, anti-rootkit…) n’est qu’une première étape.

Une vérification manuelle, rapide et efficace est nécessaire. Avoir un contrôleur d'intégrité de type iWatch/Samhain/Tripwire qui surveillera les fichiers système et nous alertera en cas de changement devient de plus en plus important.

Cela révèle une fois de plus l’importance de l’association d’un firewall bien configuré à des mises à jour régulières.

L’OS dans notre cas présent n’était pas à jour et les règles iptables vides.

Derniers rappels, bien connus mais importants, 

• changer le port d'écoute de SSHd permet d’éviter les scans permanents,
• mettre en place un système anti brute-force (type fail2ban) qui élimine ce type d'attaque et facilite l’analyse des logs.
• utiliser des clefs RSA et désactiver l'authentification SSH par mot de passe

Enfin, de manière générale, on observe un recrudescence des attaques. Celle-ci a été faite par un pirate discret, qui n'a été detecté que parce qu'il utilisait un binaire générant des caractères à l'affichage...

La signature de ce binaire n'est pas présente sur Internet : le hacker a sans doute recompilé lui-même les sources en modifiant les paramètres importants (probablement le mot de passe Magic et le fichier de stockage des login/passwords interceptés). On n'est donc plus tout à fait dans le cas typique d'un script-kiddie...

On peut également imaginer les dégats si les mots de passe d'un utilisateur ayant des droits élevés sont repliqués sur plusieurs machines du même réseau...

Sans notre intervention, le hacker serait resté présent sur le système, qui aurait été inclus dans un botnet (réseau de machines zombies), dont l'usage est loué à toutes sortes d'activité illicites (DDOS, spam, etc..).

Cette prestation a été réalisée dans le cadre de notre offre Forensic , d'audit sécurité suite à une intrusion.

Par ailleurs nous avons formalisée nos offres de :

• l'interconnexion de sites en VPN IPSEC (point à point ou multi-points)
• l'interconnexion de sites en pont Hertzien (point à point ou multi-points)
• intervention après intrusion ou compromission de serveur(s)

Suivez donc notre tweet  !!

Cet article se trouve sur notre blog : http://blog.randco.fr/2009/09/17/debug-vpn-sous-checkpoint-secureplatform/ .

L'article se trouve sur notre blog : http://blog.randco.fr/2009/07/14/connaitre-la-version-de-son-linux/ .

L'article se trouve sur notre blog : http://blog.randco.fr/2009/07/20/copier-en-mode-non-interactif/

L'article se trouve sur notre blog : http://blog.randco.fr/2009/07/28/desactiver-la-methode-trace-sur-apache/ .

Cet article se trouve sur notre blog : http://blog.randco.fr/2009/09/04/support-du-ftp-passif-sur-un-serveur-protege-par-iptablesnetfilter/ .

L'article se trouve sur notre blog : http://blog.randco.fr/2009/09/16/activation-des-modules-apache-sur-ubuntu-8-0-4-server/ .

Les fonctions de hachage sont utilisées en cryptographie : initialement crées pour construire des signatures numériques afin d'assurer l'intégrité des messages, elles sont également utilisées dans le contrôle d'intégrité des données et des applications, l'authentification notamment dans HMAC (keyed-hash message authentication code),dans les protocoles IPSEC et SSL notamment.

<

<

<

<

<

<

• <

• <

• <

  <

  <

  <

  <

  <

  <

  <

  ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=38 http://www.randco.fr/?p=actualites&ID=38 http://www.randco.fr/?p=actualites&ID=38 Dans le cadre de notre développement, nous recherchons un guru Linux pour travailler principalement sur des sujets OpenSource dans le cadre de nos missions d'expertise sur le périmètre Infrastructure IT (systèmes, réseaux, sécurité et supervision bien sûr !!).
  
  Vous maitrisez parfaitement Linux (et un langague de script tel que Perl ou Python) et êtes capable de contribuer sur certains outils (Nagios, Cacti, Wireshark, Ntop, etc..)
  
  Doué techniquement, autonome, ayant envie d'apprendre et de relever le défi de l'expertise, vous serez intégré à notre équipe et pourrez exprimer votre plein potentiel dans une ambiance jeune et sympathique sur de courts projets très pointus (audit, troubleshooting, consulting, mise en oeuvre, etc..).
  
  Nous vous formerons sur les domaines connexes (notamment matériels et logiciels tels que Cisco, CheckPoint, VMware, etc..) et vous donnerons les moyens matériels et financiers d'atteindre vos objectifs.
  
  CDI basé à Paris.
  Pour poustuler , merci de remplir la fiche ici
  

  ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=37 http://www.randco.fr/?p=actualites&ID=37 http://www.randco.fr/?p=actualites&ID=37 <

  <

  <

  <

  <

  <

  <

  <

  <

  <

  <

  • <

  • <

    ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=36 http://www.randco.fr/?p=actualites&ID=36 http://www.randco.fr/?p=actualites&ID=36 Retrouvez ci-dessous le contenu de notre newsletter de Janvier 2008.

    Pour s'inscrire, voir ici .

    <

    <

    <

    <

    <

    <

    <

    <

    <

    <

    <

    <

    • <

    • <

      <

      • <

      • <

      • <

        <

        <

        <

        <

        <

        <

        <

        <

        <

        <

        <

        <

        • <

        • <

          <

          <

          <

          <

          • <

          • <
            • <

            • <
              • <
                • <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  <

                  ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=35 http://www.randco.fr/?p=actualites&ID=35 http://www.randco.fr/?p=actualites&ID=35 http://www.edge-security.com/wfuzz.php ) est un "Fuzzer".
                  
                  "Fuzzer" est une technique de test qualité qui consiste à injecter massivement et de manière automatisée des données aléatoires sans a priori (du "fuzz") en entrée d'un programme. Ainsi, si un crash intervient, le défaut peut être noté puis corrigé.
                  
                  En quoi cela peut-il nous être utile ? Dans nos activités de sécurité, ce type d'outil nous sert à "Brute-Forcer" un serveur Web, c'est à dire tester toutes les combinaisons possibles à partir soit d'un fichier dictionnaire ou bien d'un ensemble de caractères alphanumériques, ponctuation, etc.. .
                  Ci dessous quelques usages :
                  
                  - identifiant / mot de passe  ; exemple typique :
                  python wfuzz.py -c --ntlm "mon_domainemon_user:FUZZ" -z file -f wordlists/megabeast.txt --hc 401  http://mon_site.com
                  
                  - URL ; exemple typique d'attaque sur IIS :
                  python wfuzz.py -c -z file -f wordlists/vulns/iis.txt --hc 401,404 http://www.mon_site.com/FUZZ
                  
                  - variables dans une URL ; exemple typique :
                  wfuzz.py -c -z range -r 1-100 --hc 404 http://www.mon_site.com/list.asp?id=FUZZ
                  
                  Nous l'avons utilisé cette semaine lors d'un test d'intrusion (pentest) pour "brute-forcer" une authentification HTTP NTLM sur un serveur IIS.
                  
                  Attention , car notre distribution basée sur Debian ne possédait pas le package python "pycurl" supportant NTLM : nous avons donc dû recompiler libcurl puis pycurl à partir des sources :
                  
                  wget http://curl.haxx.se/download/curl-7.17.1.tar.gz
                  tar zxvf curl-7.17.1.tar.gz
                  cd curl-7.17.1/
                  ./configure
                  make
                  sudo make install
                  ldconfig
                  
                  wget http://pycurl.sourceforge.net/download/pycurl-7.16.4.tar.gz
                  tar zxvf pycurl-7.16.4.tar.gz
                  cd pycurl-7.16.4/
                  sudo python setup.py install
                  
                  On vérifie ensuite le support de NTLM dans pycurl ainsi :
                  
                  $ python
                  Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
                  [GCC 4.1.2 20060928 (prerelease)] on linux2
                  Type "help", "copyright", "credits" or "license" for more information.
                  >>> import pycurl
                  >>> pycurl.version_info()
                  (3, '7.17.1', 463105, 'i686-pc-linux-gnu', 540, 'OpenSSL/0.9.8b', 0, '1.2.3', ('tftp', 'ftp', 'telnet', 'dict', 'http', 'file', 'https', 'ftps'), None, 0, None)
                  >>>
                  
                  Une fois l'attaque achevée, on obtient le résultat suivant :
                  
                  Target: http://www.mon_site.com/exchange
                  Payload type: file
                  Total requests: 45463
                  ===========================================================
                  ID Response Lines Word Request
                  ===========================================================
                  00053: C=401 10 L 18 W "mon_domaineadministrateur:admin"
                  
                  On constate un code retour HTTP 401 (Accès non autorisé) : on ne gagne pas à chaque coup ... surtout quand les inconnues sont multiples : dans le cas présent non seulement mot de passe mais également identifiant et nom de domaine. ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=34 http://www.randco.fr/?p=actualites&ID=34 http://www.randco.fr/?p=actualites&ID=34 <

                  <

                  <

                  <

                  <

                  1. <

                  2. <
                     • <

                     • <

                       <

                       3. <

                          <

                          <

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=33 http://www.randco.fr/?p=actualites&ID=33 http://www.randco.fr/?p=actualites&ID=33 Retrouvez ci-dessous le contenu de notre newsletter de Novembre 2007.

                          Pour s'inscrire, voir ici .

                          ====================================================
                                        Newsletter RANDCO  Novembre 2007
                          ====================================================

                          
                          --[ Sommaire ]-------------------------

                                1. Actualités Société
                                2. Nouvel article "Un audit de sécurité WiFi"
                                3. Actualités Supervision
                                4. Vu sur le Net
                                5. L'outil du mois
                                6. Contact

                           

                          --[ 1. Actualités Société ]----

                           

                          Depuis la rentrée, de nombreuses actualités autour de RANDCO :

                           

                          - Deux nouveaux consultants nous ont rejoint depuis Octobre : un ingénieur réseau avec une spécialisation sécurité (notamment technologies anti-spam) et un consultant réseaux et systèmes pour l'administration de l'infrastructure d'un de nos clients, en mode contrat de service global.

                           

                          - A l'occasion d'une mission sur de l'expertise JBOSS, nous avions fait connaissance et sympathisé avec Jérôme MOLIERE, expert J2EE et auteur de livres sur ce sujet. Nous avons décidé d'un partenariat qui renforce nos compétences sur les domaines des infrastructures IT en y incluant les serveurs J2EE. Nous avons initié ce partenariat en organisant une formation JBOSS sur mesure pour l'un de nos clients.

                           

                          - Même si elles sont parfois décriées, nous croyons dans les certifications des éditeurs et des constructeurs afin de valider et de faire valoir nos compétences. Ainsi ce mois-ci, trois de nos consultants ont obtenu les certifications HP SAN , Cisco CCNA et Microsoft Windows 2003 Server.Nous reviendrons sur les cerifications SAN (stockage) dans notre prochain numéro.

                           

                          - RANDCO, en tant que spécialiste de l'intégration de plateformes de supervision OpenSource est cité par 01net : http://www.01net.com/editorial/357204/

                           

                          - Nous interviendrons, comme chaque année, à l'Ecole Nationale Supérieure d'Informatique pour l'Industrie et l'Entreprise (ENSIIE, http://www.ensiie.fr/ ) lors d'une conférence auprès des élèves ingénieurs sur le métier de consultant en Infrastructures IT, le vendredi 7 décembre 2007.

                           

                          --[ 2. Nouvel article "Un audit de sécurité WiFi" ]----

                           

                          Nous avons réalisé dernièrement, lors d'un test d'intrusion, un audit de sécurité WiFi dont les résultats se sont révélés assez typiques !

                          
                          Grâce à nos cartes munies du chipset Atheros et de la distribution en LiveCD Linux BackTrack, nous avons sniffé les communications Wifi et découvert que la sécurisation utilisée reposait sur le protocole propriétaire Cisco LEAP (LightWeight EAP)....

                           

                          La suite sur : http://www.randco.fr/?p=actualites&ID=32

                          
                          --[ 3. Actualités Supervision ]----

                           

                          L'actualité des outils de supervision Open Source est chargée en cette fin d'année :

                           

                          - Sortie de la beta Nagios v3.0b6 (http://www.nagios.org/) . Dès qu'une version stable 3.0 sortira, nous écrirons un article détaillant les nouveautés dont principalement un nouveau front-end de configuration, de meilleures performances et l'utilisation d'une base de données. La version stable connait également une nouvelle release mineure avec la version 2.10

                           

                          - Sortie de la v0.8.7 de Cacti (http://cacti.net/) qui apporte notamment une plus grande granularité des options (par équipement), une amélioration graphique (utilisation de fontes TruType par RRDtool), et la possibilité d'export des points de collecte en format CSV. La liste des plugins utilisables dans Cacti s'aggrandit régulièrement,et nous apportons (modestement) notre contribution à cette édifice en patchant le collecteur d'adresses MAC utilisé dans MACTRACK pour les équipements réseaux Foundry ( http://forums.cacti.net/viewtopic.php?p=116100#116100 ).

                           

                          --[ 4. Vu sur le Net ]----

                           

                          Comme beaucoup de professionnels de la sécurité nous lisons attentivement la newsletter de Bruce Schneier (http://www.schneier.com/crypto-gram.html ) qui regorge (trop ?) d'informations. Ce mois-ci nous avons décidé de nous attarder sur cette information : les CPU embarquées sur les cartes graphiques permettent de cracker les mots de passe 25 fois plus vite que la CPU "classique" d'un ordinateur récent !! (http://blogs.techrepublic.com.com/tech-news/?p=1433&tag=nl.e019)

                           

                          Cela est dû principalement aux capacités massivement parallèles des processeurs de carte graphique (GPU) et la taille de leur mémoire embarquée sans cesse grandissante.

                           

                          C'est une information intéressante car nous utilisons assez régulièrement ces technologies lors de nos audits de sécurité ou tests d'intrusion. Nous faisons appel à des Rainbow Table (listes de hashes de mot de passe déjà pré-calculés, cf http://en.wikipedia.org/wiki/Rainbow_table ) via des outils spécialisés tels que ophcrack (http://ophcrack.sourceforge.net/ ) ou Cain&Abel (http://www.oxid.it/cain.html ) . Les tables NTLM (mécanisme d'authentification moderne de Windows) pour les mots de passe jusqu'à 8 caractères sont ainsi publiées sous la forme de plusieurs fichiers de 650Mo. On peut ainsi casser tout mot de passe de cette longueur en moins de 10 minutes (temps de parcours des tables).

                           

                          Cependant l'utilisation appropriée, native sur certains systèmes d'exploitation (principalement les UNIX-like et GNU Linux), d'un SALT  (c-a-d un nombre aléatoire ajouté au mot de passe avant le hachage) les rend inéfficiente. Dans ces cas, l'utilisation de réseau type P2P ou Grid computing, tel que http://www.freerainbowtables.com/ , permet de bénéficier d'une puissance de calcul communautaire, sur le principe de gain/consommation de crédits.

                           

                          Quoiqu'il en soit, justifier l'achat d'une PlayStation3 à des fins de sécurité ne manque pas de sel  :)

                           

                          --[ 5. L'outil du mois ]----

                           

                          C'est un outil assez récent puisque publié le 18 Octobre 2007. Ecrit en python, "wfuzz" ( http://www.edge-security.com/wfuzz.php ) est un "Fuzzer".

                           

                          "Fuzzer" est une technique de test qualité qui consiste à injecter massivement et de manière automatisée des données aléatoires sans a priori (du "fuzz") en entrée d'un programme. Ainsi, si un crash intervient, le défaut peut être noté puis corrigé.

                           

                          En quoi cela peut-il nous être utile ? Dans nos activités de sécurité, ce type d'outil nous sert à "Brute-Forcer" un serveur Web, c'est à dire tester toutes les combinaisons possibles à partir soit d'un fichier dictionnaire ou bien d'un ensemble de caractères alphanumériques, ponctuation, etc.. .
                          Ci dessous quelques usages :

                           

                          - identifiant / mot de passe  ; exemple typique :
                          python wfuzz.py -c --ntlm "mon_domainemon_user:FUZZ" -z file -f wordlists/megabeast.txt --hc 401  http://mon_site.com

                           

                          - URL ; exemple typique d'attaque sur IIS :
                          python wfuzz.py -c -z file -f wordlists/vulns/iis.txt --hc 401,404 http://www.mon_site.com/FUZZ

                           

                          - variables dans une URL ; exemple typique :
                          wfuzz.py -c -z range -r 1-100 --hc 404 http://www.mon_site.com/list.asp?id=FUZZ

                          Nous l'avons utilisé cette semaine lors d'un test d'intrusion (pentest) pour "brute-forcer" une authentification HTTP NTLM sur un serveur IIS.

                           

                          Attention , car notre distribution basée sur Debian ne possédait pas le package python "pycurl" supportant NTLM : nous avons donc dû recompiler libcurl puis pycurl à partir des sources :

                           

                          wget http://curl.haxx.se/download/curl-7.17.1.tar.gz
tar zxvf curl-7.17.1.tar.gz
cd curl-7.17.1/
./configure
make
sudo make install
ldconfig

                          wget http://pycurl.sourceforge.net/download/pycurl-7.16.4.tar.gz
tar zxvf pycurl-7.16.4.tar.gz
cd pycurl-7.16.4/
sudo python setup.py install

                           

                          On vérifie ensuite le support de NTLM dans pycurl ainsi :

                           

                          $ python
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import pycurl
>>> >>> pycurl.version_info()
(3, '7.17.1', 463105, 'i686-pc-linux-gnu', 540, 'OpenSSL/0.9.8b', 0, '1.2.3', ('tftp', 'ftp', 'telnet', 'dict', 'http', 'file', 'https', 'ftps'), None, 0, None)
>>> >>>

                           

                          Une fois l'attaque achevée, on obtient le résultat suivant :

                           

                          Target: http://www.mon_site.com/exchange
Payload type: file
Total requests: 45463
===========================================================
ID Response Lines Word Request
===========================================================
00053: C=401 10 L 18 W "mon_domaineadministrateur:admin"

                           

                          On constate un code retour HTTP 401 (Accès non autorisé) : on ne gagne pas à chaque coup ... surtout quand les inconnues sont multiples : dans le cas présent non seulement mot de passe mais également identifiant et nom de domaine.

                           

                          --[ 6. Contact ]----

                           

                          RANDCO, SARL au capital de 30.000 Euros.
                          45 Avenue Hoche
                          75008 Paris
                          Contact Commercial : contact _chez_ randco.fr
                          Contact pour la Newsletter : newsletter _chez_ randco.fr

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=32 http://www.randco.fr/?p=actualites&ID=32 http://www.randco.fr/?p=actualites&ID=32 Nous avons réalisé dernièrement, lors d'un test d'intrusion, un audit de sécurité WiFi dont les résultats se sont révélés assez typiques !
                          

                          Grâce à nos cartes munies du chipset Atheros  et de la distribution en LiveCD Linux Backtrack , nous avons sniffé les communications Wifi et découvert que la sécurisation utilisée reposait sur le protocole propriétaire Cisco LEAP (LightWeight EAP).

                          Cisco décrit ainsi  la séquence d'authentification et d'échangede clés de la façon suivante :

                           

                          Cisco LEAP is based on a username/password scheme and uses the following basic authentication process:

                          1. A client connects to the wireless medium.

                          2. The client sends a start message to an AP (Access Point).

                          3. The AP sends an access request on behalf of the client to the authentication server.

                          Il est important de noter que le trafic réseau entre l'AP et le serveur d'authentification (en général RADIUS) sont réalisées sur le LAN et donc hors de portée des attaquants. Par ailleurs, et c'est d'ailleurs le cas là, le serveur RADIUS utilisé est parfois directement embarqué sur l'AP.

                          4. The client sends its username to the AP, which forwards it to the authentication server.

                          

                          5. The authentication server sends a challenge back.

                          6. The AP forwards the challenge to the client as an EAP message over 802.1X.

                          

                          Ci-dessus, on observe bien le nonce de 8 octets.

                           

                          7. The client runs the challenge through the Cisco LEAP algorithm, mixes challenge and user password together, and responds with a value, which the AP forwards to the authentication server.

                          

                          La réponse du client est générée ainsi : 3 copies du nonce sont chiffrées en DES par 3 clés distinctes : on les obtient en hashant le mot de passe (via MD4, produisant un aggrégat de 16 octets), en le concaténant avec 5 octets null, puis en le découpant en 3 séquences (clés) de 7 octets.

                           

                          Le client envoie alors le challenge-response de 24 (3x8) octets, que l'on peut observer dans la capture ci-dessus.

                           

                          La faiblesse de LEAP tient dans le fait que le clair est connu (pas de chiffrement du nonce) et que la 3ème clé DES est quasiment connue : les 5 derniers octets (sur 7!) sont "0" !

                          Il devient assez simple de lancer une attaque par dictionnaire ou brute force en utilisant cette optimisation.. pour chaque test de mot de passe, seul le 3ème et dernier bloc DES est généré : si celui-ci correspond à la capture, le second bloc est calculé. En cas de correspondance, le premier bloc est alors calculé : si de nouveau il y a correspondance , le mot de passe est trouvé !

                           

                          8. The authentication server runs the user password through the Cisco LEAP algorithm, which processes the challenge and client response, then compares its derived value with the value it received from the client. If the two values match, the authentication server sends a success message to the AP, which passes it to the client.

                          

                          9. Now, the client sends a challenge to the authentication server to authenticate the AP (the network), and proceeds through the reverse Cisco LEAP process.

                          On voit bien le client envoyer un challenge de 8 octets.....

                          

                          .. auquel l'Access Point répond par une donnée de 24 octets.

                          

                          Dans une seconde trame, l'AP envoie la clé de session :

                          

                           

                          10. If the network is successfully authenticated, the client passes a success message through the AP to the authentication server, which opens a port. The user is live on the network.

                          

                          11. Cisco LEAP RADIUS server a WEP key for that session and stores it in the AP.

                          12. The Cisco LEAP client locally derives the WEP key.

                           

                          Lors de notre audit, nous avons évidemment tenté (et réussi à casser le mot de passe) grâce à l'outil thc-leapcracker en mode brute force :

                           

                          

                           

                          La conclusion ? Une mauvais mécanisme de sécurité permet à un attaquant :

                          • d'obtenir en clair le login de l'utilisateur connecté
                          • d'obtenir le mot de passe chiffré (ou dérivé) attaquable en mode offline

                          Ce mot de passe est malheureusement celui du Wifi mais également celui du domaine, et de l'accès VPN !!! On comprend aisément les dégats..

                          C'est pourquoi nous préconisons :

                          • une politique de mots de passe forts et fréquemment changés qui reste la meilleure contre-mesure à la plupart des attaques. Si cette politique n'est pas applicable alors il existe des alternatives telles que l'authentification forte via des tokens (RSA, ActivCard, etc..) ou des certificats.
                          • une décorrelation des comptes (et des mots de passe) VPN, Domaine Active Directory,Wifi, Métier, etc...
                          • l'utilisation quasi systématique de VPN IPSEC même en mode WiFi
                          • une veille active autour de la sécurité (information, passage de patch, amélioration de la configuration ou des mécanismes de sécurité) lorsque de tels risques sont encourus. Dans le cas présent la mise en oeuvre de PEAP par l'établissement d'un tunnel SSL doublement authentifié (certificat serveur et client) permet d'assurer également une bonne sécurité (au prix d'un déploiement plus lourd sur les postes de travail).
                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=31 http://www.randco.fr/?p=actualites&ID=31 http://www.randco.fr/?p=actualites&ID=31 Les constructeurs de firewall se vantent  souvent d'implémenter des modules applicatifs. Ceci est nécessaire lorsque l'applicatif ouvrent des ports TCP/UDP dynamiquement.

                           

                          C'est typiquement le cas de la visioconférence IP lorsque celle-ci utilise H.323 (SIP est un autre concurrent ainsi que MGCP), qui "regroupe" de nombreux autres protocoles tels que H.245 et H.225.

                           

                          

                          Nous sommes intervenus récemment chez un client qui utilise des équipements de visioconférence TANDBERG pour des communications internationales traversant de nombreux firewall dont un Cisco PIX et un CheckPoint sur plateforme Nokia.

                           

                          Lors de l'initialisation de la connexion, un échange H.225 (protocole qui gère l'appel : établissement, contrôle et fin) a lieu puis le flux est diffusé (via H.245  pour la gestion des flux médias, RTCP et RTP) sur des ports négociés. Lors de cette investigation nous avons découvert que le flux vidéo était interrompue 1 heure après le début de l'appel.

                           

                          Nous avons tout d'abord soupçonné le PIX qui droppait silencieusement certains paquets H.245. Il faut dire que le TAC Cisco nous a conseillé de désactiver l'inspection protocolaire "fixup" H.323 et d'ouvrir les connexions TCP et UDP entre les équipements de Visio : ceci permet d'une manière assez brutal de s'assurer que le PIX ne bloquera aucun paquet de visioconférence !!

                           

                          L'analyse des logs CheckPoint ne donnera non plus aucune piste (rien dans la règle 0, celle des autorisation / refus implicites). Pourtant l'analyse du traffic (par port mirroring) met en évidence le comportement anormal du CheckPoint : le flux H.245 est "cassé" alors qu'il est actif en permanence !!

                           

                          En fait, c'est la session H.225 qui est inactive depuis une heure : déclenchant le "nettoyage" des règles négociées lors de l'appel H.323. Pourtant la documentation marketing détaille cette fonctionnalité (sic) "Enforce H.323 call duration limits".

                           

                          Un workaround pour éviter ce "bug" dans l'inspection protocolaire, consiste à augmenter le timer nommé "H.323 idle timeout" prolongeant d'autant la libre circulation des flux H.245.

                           

                          La conclusion de cette investigation est qu'il ne faut pas toujours de fier aux fonctions magiques (lire "applicatives") des firewalls et que souvent seule l'analyse du traffic avec un sniffer permet de mettre en lumière les dysfonctionnements d'un réseau.

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=30 http://www.randco.fr/?p=actualites&ID=30 http://www.randco.fr/?p=actualites&ID=30 Sur un de nos serveurs hébergés, nous devons installer et configurer rapidement un serveur FTP d'upload pour quelques-un de nos clients.

                          Notre plateforme de prédilection est désormais Ubuntu-Server étant donné le manque de visibilité de Mandriva. Voici décrites ci dessous les quelques étapes que nous avons suivi.

                           

                          Installation de proftpd.

                           

                          La distribution proftpd est contenu dans le repository universe d'Ubuntu que nous devons activer en décommentant dans le fichier /etc/apt/sources.list la ligne :

                          
                          deb http://fr.archive.ubuntu.com/ubuntu/ edgy universe
deb-src http://fr.archive.ubuntu.com/ubuntu/ edgy universe
                          

                           

                          Ensuite on effectue un classique :

                           

                          $ sudo apt-get update
$ sudo apt-get install proftpd

                           

                          Dans le menu proposé, on choisit l'installation en "standalone" plutot qu'avec (x)inetd.

                           

                          Configuration de proftpd.

                           

                          La configuration par défaut laisse à désirer notamment au niveau de la sécurité.

                          Nous modifions donc le fichier /etc/proftpd/proftpd.conf en ajoutant les lignes suivantes :

                          
                          
                          ## L'authentification s'appuye sur une liste explicite de comptes listés dans "/etc/proftpd/passwd"
AuthOrder mod_auth_file.c
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

## Les utilisateurs sont chrootés dynamiquement lors de la connexion : il ne peuvent remonter le répertoire parent
DefaultRoot ~

## On désactive la bannière founrissant des informations sur la version du serveur
ServerIdent off

## les utilisateurs FTP n'ayant pas besoin de se logger autrement sur le serveur, leur shell est fixé à "/bin/false". La directive ci-dessous est nécessaire pour accepter ce fonctionnement.
RequireValidShell off

## Controle d'accès : par défaut tout est interdit !!
< LIMIT ALL>
  DenyAll
< /LIMIT>


## Controle d'accès : les utilisateurs peuvent écrire et lire dans leur répertoire respectif
< Directory ~ >
  < Limit READ WRITE RNFRM >
   AllowAll
  < /Limit >
  < Limit STOR >
   AllowAll
  < /Limit >
< /Directory >

# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022  022



                          Création des comptes FTP

                           

                          Par défaut, tout compte déclaré dans le système et non  inclus dans le fichier "/etc/ftpusers" est apte à se connecter. Ce principe de black-list n'est évidemment pas acceptable au vu des risques encourus.

                          Nous préférons donc opter pour un système en liste blanche via les directives suivantes :

                           

                          AuthOrder mod_auth_file.c
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"
 

                          
                          

                          ll faut ensuite à la fois créer les comptes dans le système (avec la commande useradd , par exemple) et pour la partie proftpd avec la commande :

                           

                          /usr/sbin/ftpasswd --passwd --file=/etc/proftpd/passwd --name=mon_user --home=/home/mon_dir --shell=/bin/false --uid=1005

                           

                          On notera que le uid (user identification number) fourni (ici "1005") doit correspondre à celui indiqué dans le fichier système /etc/password. 

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=29 http://www.randco.fr/?p=actualites&ID=29 http://www.randco.fr/?p=actualites&ID=29 Les spams représentent largement plus de 50% du volume des e-mails.

                          L'ampleur ce phénomène est telle que des mesures gouvernementales  et judicaires  se mettent en place afin de criminaliser ces pratiques.

                          Chez nos clients, nous sommes fréquemment mis à contribution pour mettre en oeuvre des contre-mesures pour combattre ce fléau. Dans cet article nous verrons les méthodes anti-spams "génériques". Nous aborderons dans un prochain article la configuration pratique (notamment LDAP ) de 2 solutions commerciales que nous avons récemment évalué .

                           

                          Greylisting

                           

                          <

                          <

                          <

                          Challenge/Response

                          <

                          <

                          <

                          <

                          CallBacks

                          <

                          <

                          <

                          Filtres Bayesiens

                          <

                          <

                          <

                          <

                          Conclusion

                          <

                           

                          On comprend mieux pourquoi la plupart de ces solutions ne sont pas satisfaisantes pour un lutte centralisée et efficace contre le spam.

                          C'est pourquoi les acteurs commerciaux proposent des méthodes complémentaires :

                          • analyse heuristique (à l'instar des anti-virus)
                          • analyse à base de signatures
                          • liste d'adresse blanches et noires (white & black list) contenant les adresses IP des serveurs SMTP "légitimes" ou "spammeurs notoires"

                          D'autres fonctionnalités sont indispensables à une solution complète :

                          • accès par l'utilisateur à sa quarantaine (liste des e-mails bloqués et lui étant adressé, nommé en anglais User Quarantine)
                          • vérification en amont de l'existence de l'adresse mail du destinataire (en général par LDAP) avant d'accepter le contenu du mail
                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=28 http://www.randco.fr/?p=actualites&ID=28 http://www.randco.fr/?p=actualites&ID=28

                           

                          Dans certains cas, il est intéressant (voire nécessaire) d'implémenter un proxy SNMP afin de pouvoir interroger des équipements qui ne doivent (ou peuvent) pas joindre le serveur de supervision.
                          Dans ce cas nous utilisons un serveur relais (généralement un firewall Linux) possédant une interface sur chacun des réseaux et nous configurons son agent SNMP (la solution Open Source net-snmp anciennement ucd-snmp) afin d'agir comme proxy.
                          Suivant la communauté fournie, le proxy fera suivre la requête à des machines différentes.
                          Si on trouve quelques documents sur la configuration de cette fonctionnalité, la partie Contrôle d'Accès est en général omise, or elle est indispensable pour obtenir une solution qui fonctionne.
                          Nous reproduison donc ici l'intégralité du fichier /etc/snmpd/snmpd.conf :

                           

                          #COM1 est la communauté par défaut pour l'agent lui-même

                          rocommunity COM1


                          view all_view included .1 80

                           

                          # Les requêtes comportant le communauté COM2 seront affectées à l'utilisateur "USER1" et au contexte "CONTEXT1"  

                          com2sec -Cn CONTEXT1 USER1 default COM2

                          # L'utilisateur USER1 fait partie du groupe GROUP1

                          group GROUP1 v1 USER1

                           

                          #Le groupe GROUP1 a tous les droits en lecture

                          access GROUP1 CONTEXT1 any noauth exact all_view none none

                           

                          # Les requêtes appartenant au CONTEXT1 sont proxyées (?) vers la machine REMOTE1 avec la communauté REMOTECOM pour l'ensemble de la MIB (OID commençant par ".1.3")

                          proxy -Cn CONTEXT1 -v 1 -c REMOTECOM REMOTE1 .1.3

                           

                          Enfin, envoyons les requêtes :

                          # snmpwalk localhost -c COM1 system.sysName.0
SNMPv2-MIB::sysName.0 = STRING: "nom_machine_locale"

                          #snmpwalk localhost -c COM2 system.sysName.0
SNMPv2-MIB::sysName.0 = STRING: "nom_machine_distante"

                           

                          Si vous n'obtenez pas ces résultats, il est possible d'obtenir des traces en lançant le démon snmpd ainsi :

                          snmpd -f -Lsd -Dresult,proxy,vacm

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=27 http://www.randco.fr/?p=actualites&ID=27 http://www.randco.fr/?p=actualites&ID=27 accéleration en termes marketing), qualité de service, partage de charge, stockage, iPBX, détection si ce n'est prévention d'intrusion et maintenant même anti-spam !
                          
                          Le but de cet article est de revenir sur une de ces avancées qui bien qu'ancienne (elle date de 2000) reste peu connue et utilisée : Cisco NBAR (Network Based Application Recognition) est une fonctionnalité embarquée sur les routeurs Cisco récents permettant la reconnaissance des applications à partir de signatures et non plus uniquement sur des ports TCP/UDP.
                          En l'activant, on peut construire le boitier QoS du "pauvre" en ce sens qu'aucun équipement ou coût suplémentaire n'est nécessaire : l'expert réseau démontre sa plus-value !

                           

                          Evidemment, l'architecture doit être routée (ce qui élimine certaines topologies : les LANs étendus au moyen de liens Ethernet 802.1Q, qu'ils soient fournis par des opérateurs ou bien des fibres noires) et sous contrôle ( les routeurs ne doivent pas être gérés par un tiers, typiquement un opérateur ou un hébergeur). NBAR permet d'identifier les flux , à l'instar des ACLs, mais en utilisant des signatures pour détecter les applications utilisant des ports mouvants (par nature tels skype, h.323, ou par "accident"HTTP, Citrix,etc..) ou bien se camouflant (canaux cachés avec stunnel, protocoles P2P : kazaa, emule, winMX , etc..). Ces signatures, nommées PDLM, sont mises à jour régulièrement et téléchargeables sous forme de mises à jour sur le site web de Cisco (nécessite un accès CCO).

                          Certains flux utilisant des ports statiques généralement inchangés ou non modifiables (typiquement DNS, Exchange ou bien Netbios) sont définis comme tels dans NBAR (i.e sans signature applicative).

                           

                          Malheureusement, la plupart de ces signatures sont très orientées P2P (on trouve le même biais dans les boitiers de QoS des constructeurs Allot ou Packeteers) ou bien VoIP /ToIP. On peut imaginer que le marché entrevu par le filtrage à grande échelle des flux P2P par les FAIs a justifié ce positionnement.
                          Certaines signatures demandes à être testées : nous avons découvert début 2007 que la signature TFTP d'un des constructeurs majeurs de boitiers de QoS ne fonctionnait pas (TFTP utilise des ports UDP dynamiques négociés lors de la session de contrôle) : c'est très problématique surtout lorsqu'on sait que la plupart des IP Phones bootent en chargeant leur logiciel par TFTP. Comment ce trafic pourrait-il être protégé si il n'est pas reconnu correctement ?

                           

                          Revenons aux commandes Cisco : une fois le flux identifié, on applique les mécanismes de queueing classiques :

                           

                          RTR(config)class-map match-any bad_trafic

                          RTR(config-cmap)#match protocol edonkey

                          RTR(config-cmap)#match protocol napster

                          RTR(config-cmap)#match protocol fasttrack

                          [..]

                          RTR(config)policy-map kill_bad_trafic

                          RTR(config-pmap)#classmap bad_trafic

                          RTR(config-pmap-c)#drop

                           

                          Si on veut être moins dur (par exemple pour du traffic web à titre personnel), on limite le débit à 100 kbits/s :

                           

                          RTR(config)class-map match-any perso_trafic

                          RTR(config-cmap)#match protocol http url "*voila.fr*"

                          RTR(config-cmap)#match protocol http url "*youtube.com*" [..]

                          RTR(config)policy-map slow_perso_trafic

                          RTR(config-pmap)#classmap perso_trafic

                          RTR(config-pmap-c)#bandwidth 100

                           

                          Il existe des possibilités pour rendre la QoS récursive (en utilisant des service-policy à l'intérieur d'une policy-map) mais cela sera l'objet d'un autre article... Reste à l'appliquer sur l'interface Se0/0 vers Internet :

                           

                          RTR(config)#interface serial0/0

                          RTR(config-if)#service-policy input kill_bad_trafic

                          RTR(config-if)#ip nbar protocol-discovery

                           

                          La puissance de NBAR lorsqu'il est appliqué à HTTP tient à son caractère stateful ( gestion des état en français ?) : bien que ce soient les paquets sortants qui contiennent l'URL, les paquets entrants (c-a-d les données) seront classifiés dans le même flot et ainsi soumis à la politique de QoS (dans le cas présent limitation en téléchargement à 10Kbps -mot clé input).

                           

                          Enfin, NBAR permet d'obtenir des statistiques d'utilisation applicative en quasi temps réel : une fonctionnalité que nous utilisons assez souvent lors de nos audits réseau et que nous ne disposons pas d'outils de métrologie sur site.

                           

                          RTR#conf t

                          Enter configuration commands, one per line. End with CNTL/Z.

                          RTR(config)#int fa0/0

                          RTR(config-if)#ip nbar protocol-discovery

                          RTR(config-if)#^Z

                           

                          [10 min plus tard]

                          RTR#show ip nbar protocol-discovery stats bit-rate top-n 10

                          

                          On appréciera le fait que les statistiques concernent les paquets entrants et sortant de l'interface selectionnée. La période de référence (ici 5 min) est modifiable via la commande :

                           

                          RTR#int fa0/0

                          RTR(config-if)#load-interval ?

                          <30-600> Load interval delay in seconds

                           

                          Cette variable était déjà utilisé lors du calcul de la charge et de la fiabilité de l'interface :

                           

                          RTR#sho int fa0/0 FastEthernet0/0 is up, line protocol is up

                          Hardware is MV96340 Ethernet, address is 0019.56bc.1288 (bia 0019.56bc.1288)

                          Internet address is 172.31.252.31/24 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

                          reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set

                           

                          En ce qui concerne la partie monitoring à moyen et long terme, Cisco publie une MIB NBAR qui vise peut-être à concurrencer la norme IETF RMON2 qui n'a jamais vraiment décollé.
                          Des frameworks de monitoring tels que Cacti peuvent ainsi grapher les stats NBAR.
                          

                           

                           

                          Un dernier point : surveillez l'accroissement de CPU dû à NBAR. Ci dessous un extrait de la FAQ de NBAR:

                           

                          <

                          <

                          <

                          <

                           

                          Bonne découverte des flux de votre réseau !

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=26 http://www.randco.fr/?p=actualites&ID=26 http://www.randco.fr/?p=actualites&ID=26
                          Tout le monde connait l'analyseur réseau Ethereal et son successeur Wireshark. Une des nouveautés de la version 0.99.5 est le déchiffrement de flux SSL dans certaines conditions.

                           

                          Cette fonctionnalité est très intéressante car elle permet enfin de pouvoir analyser le trafic SSL à l'aide d'un sniffer que ce soit sur un serveur ( la plupart du temps HTTPS mais également LDAPS, POPS, SFTP, etc.. ) en production ou bien sur un port de recopie d'un flux (grâce à la fonction de mirroring d'un switch ou bien encore l'usage d'un tap physique).

                           

                          Au niveau du client, il existe d'autres possiblités en utilisant des proxy (tels que l'excellent outil WebScarab de l'OWASP) on bien du tunneling SSL (avec stunnel par exemple).

                           

                          Pour être tout à fait exhaustif, l'outil ssldump permettait déjà d'obtenir ce genre d'information, mais en shell. Son intégration à WireShark permet ainsi de suivre aisément et graphiquement les segments TCP, acknowledgements, retransmissions, etc..

                           

                          Pour mettre en pratique cette fonctionnalité nous allons déchiffrer le flux HTTPs d'un serveur de test. Tout d'abord créeons le matériel crypto :

                           

                          Nous générons un bi-clé RSA  de 1024 bits :

                           

                          # openssl genrsa -out server.key 1024

                          Generating RSA private key, 1024 bit long modulus

                          .......++++++ .++++++

                          e is 65537 (0x10001)

                           

                          Notez la valeur de "e" : pour rappel, on a "ed= 1 mod (p-1)(q-1)" avec p et q grands nombre premiers choisis aléatoirement .

                          La valeur "pq" est la clef publique et "d" la clef privée. Bien que théoriquement libre, la valeur de "e" choisie par la plupart des implémentations est 3 , 5, 17 ou bien 65537.

                           

                          # openssl rsa -in server.key -out server.pem

                           

                          Nous créeons maintenant le CSR (Certficate Signing request) :

                           

                          # openssl req -new -key server.key -out server.csr

                          You are about to be asked [..]

                          Country Name (2 letter code) [GB]:FR

                          State or Province Name (full name) [Berkshire]:Paris

                          Locality Name (eg, city) [Newbury]:75008

                          Organization Name (eg, company) [My Company Ltd]:RandCo

                          Organizational Unit Name (eg, section) []:IT

                          Common Name []:test.randco.fr

                          Email Address []:

                           

                           

                          Comme nous sommes dans un environnement de test, nous autosignons ce CSR pour obtenir le certificat :

                           

                          # openssl x509 -req -in server.csr -signkey server.key -out server.crt

                          Signature ok

                          subject=/C=FR/ST=Paris/L=75008/O=RandCo/OU=IT/CN=test.randco.fr

                          Getting Private key

                           

                          Nous obtenons ainsi une clé privée server.key et un certificat server.crt. Configurons ensuite Apache : nous ajoutons dans httpd.conf (au niveau du virtual host écoutant sur le port 443) ceci :

                           

                          DocumentRoot /usr/local/apache2/htdocs

                          ServerName test.randco.fr SSLEngine on

                          SSLCertificateFile /usr/local/apache2/etc/ssl.crt/server.crt

                          SSLCertificateKeyFile /usr/local/apache2/etc/ssl.key/server.pem

                           

                          Cependant SSL n'est pas supporté par la version du binaire httpd actuel :

                           

                          # httpd -l | egrep -i "(ssl|so)"

                          mod_so.c

                          #

                           

                          Etant donné que nous utilisons Apache2, nous devons donc juste le recompiler en activant l'option --enable-ssl (contrairement à Apache 1.3 pour lequel le module mod_ssl est distribué à part) :

                           

                          # ./configure --enable-ssl

                          # make

                          # make install

                          # httpd -l | egrep -i "(ssl|so)"

                          mod_ssl.c

                          mod_so.c

                          # apachectl -k restart

                           

                          Une fois que le flux HTTPs aura été capturé par Wireshark, regardons comment configurer le déchiffrement dans Wireshark :

                          dans le menu Edit > Preferences > Protocols > SSL , remplir les champs comme suit :

                          • RSA keys list : les champs séparés par une virgule sont l'adresse IP du server, port TCP, protocole applicatif sous-jacent , chemin vers la clé privée
                          • SSL debug file : chemin vers l'indispensable fichier de debug

                          

                           

                          En appliquant un "SSL follow", on peut suivre la session et récuperer le contenu de la session en clair :

                           

                          

                           

                          Pour tester à votre tour, voici la clé privée et le fichier de capture de la session HTTPS réalisée avec IE6. Les limitations de ssldump et de la méthode demeurent cependant :

                          • AES n'est supporté que dans la version CVS de ssldump (donc non intégrée à Wireshark)

                           

                          • tous les flux chiffrés avec des Cipher Suite mettant en oeuvre un échange de clé du type Diffie-Helmann Ephemere (DHE) (en opposition avec RSA et Diffie Hellman statique - DH) restent évidemment indéchiffrables ( ceci en est d'ailleurs le but : cet algorithme reste toutefois sensibles aux attaques Man in the Middle. C'est la méthode choisie par Webscarab ou d'autres proxy tels que Spike Proxy ou Burp Proxy. Evidement, ce genre de manipulation provoque une alerte SSL au niveau du client : "certificat invalide"  !).
                            
                            La capture précédente était réalisée avec MS IE 6 (à jour de patches), le Cipher Suite négocié était TLS_RSA_WITH_RC4_128_MD5. Si on utilise d'autres outils (notamment Open Source tels que Firefox ou lwp-request, basé sur Perl) des Cipher Suite beaucoup plus forts seront négociés automatiquement :

                           

                          # lwp-request -des https://localhost

                          200 OK

                          Connection: close

                          Server: Apache/2.0.53 (Unix) mod_ssl/2.0.53 OpenSSL/0.9.7a PHP/4.3.10 mod_perl/2 .0.1 Perl/v5.8.6

                          Content-Length: 2271

                          Content-Type: text/plain

                          Client-Peer: 127.0.0.1:443

                          Client-Response-Num: 1

                          Client-SSL-Cert-Issuer: /C=FR/ST=Paris/L=75008/O=RandCo/OU=IT/CN=test.randco.fr

                          Client-SSL-Cert-Subject: /C=FR/ST=Paris/L=75008/O=RandCo/OU=IT/CN=test.randco.fr

                          Client-SSL-Cipher: DHE-RSA-AES256-SHA

                          Client-SSL-Warning: Peer certificate not verified

                           

                          Ce qui donne avec ssldump (version CVS) et le fichier de capture obtenu via :

                           

                          # tcpdump -n tcp port 443 -i lo -w https2.cap -s 16436 &

                           

                          (remarquez la taille des paquets à capturer inhabituellement grande : le MTU de l'interface de loopback est de 16436 octets !) :

                           

                          # ./ssldump -r https2.cap -k server.key

                          New TCP connection

                          #1: 127.0.0.1(52260) <-> 127.0.0.1(443) 1 1 0.0004 (0.0004)

                          C>S SSLv2 compatible client hello Version 3.1 cipher suites

                          TLS_DHE_RSA_WITH_AES_256_CBC_SHA

                          TLS_DHE_DSS_WITH_AES_256_CBC_SHA

                          TLS_RSA_WITH_AES_256_CBC_SHA

                          TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

                          TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

                          TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL2_CK_3DES

                          TLS_DHE_RSA_WITH_AES_128_CBC_SHA

                          TLS_DHE_DSS_WITH_AES_128_CBC_SHA

                          TLS_RSA_WITH_AES_128_CBC_SHA SSL2_CK_RC2

                          TLS_DHE_DSS_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA

                          TLS_RSA_WITH_RC4_128_MD5 SSL2_CK_RC4 SSL2_CK_RC464

                          TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

                          TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA

                          TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5

                          TLS_DHE_RSA_WITH_DES_CBC_SHA

                          TLS_DHE_DSS_WITH_DES_CBC_SHA

                          TLS_RSA_WITH_DES_CBC_SHA SSL2_CK_DES

                          TLS_DHE_DSS_WITH_RC2_56_CBC_SHA

                          TLS_RSA_EXPORT1024_WITH_RC4_56_SHA

                          TLS_RSA_EXPORT1024_WITH_RC4_56_MD5

                          TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

                          TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

                          TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

                          TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

                          SSL2_CK_RC2_EXPORT40

                          TLS_RSA_EXPORT_WITH_RC4_40_MD5

                          SSL2_CK_RC4_EXPORT40 1 2 0.0205 (0.0201)

                          S>C Handshake ServerHello Version 3.1 session_id[0]= cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA

                           

                          Ce qui veut donc dire TLS (SSL v3.1) avec échange de clés Diffie Hellman Ephemere  , algorithme de chiffrement par bloc AES  256 bits et hashage par SHA 

                           

                          compressionMethod NULL 1 3 0.0205 (0.0000)

                          S>C Handshake Certificate 1 4 0.0205 (0.0000)

                          S>C Handshake ServerKeyExchange 1 5 0.0205 (0.0000)

                          S>C Handshake ServerHelloDone 1 6 0.0531 (0.0325)

                          C>S Handshake ClientKeyExchange

                          DiffieHellmanClientPublicValue[128]= 7d 96 7e c0 16 ff 1b 63 26 4d 5a 1a b6 0e 16 62 e9 8d dd d6 a0 45 07 d2 51 50 61 d9 26 14 3b 3f bd 77 c5 66 ba 99 26 7e dc 52 c5 1c f2 72 2c dc 24 17 1e 58 a8 45 0d 46 3e 42 da 45 ad 1a c2 e2 87 c3 b8 3b 0f cc 12 c6 6b 98 db 25 7f da 37 8d f7 02 06 95 64 54 94 ec 57 eb 82 e3 76 ab 80 2d a6 da a2 d8 b3 51 a8 29 65 9c 35 fb 81 91 6f 91 e7 ab a9 75 f4 55 b1 30 09 97 13 29 fb a0 a6 a4 1 7 0.0531 (0.0000)

                          C>S ChangeCipherSpec 1 8 0.0531 (0.0000)

                          C>S Handshake 1 9 0.0697 (0.0165)

                          S>C ChangeCipherSpec 1 10 0.0697 (0.0000)

                          S>C Handshake 1 11 0.0700 (0.0003)

                          C>S application_data 1 12 0.0700 (0.0000)

                          C>S application_data 1 13 0.0703 (0.0003)

                          S>C application_data 1 14 0.0705 (0.0001)

                          S>C application_data 1 0.0716 (0.0011)

                          C>S TCP FIN 1 15 0.0717 (0.0001)

                          S>C Alert

                           

                          Pour rappel, la valeur publique de l'échange Diffie Helman est "A = g^a mod p" avec un générateur "g" et un nombre premier "p" fixés suivant le groupe DH sélectionné. (dans le cas présent DHE - Diffie Hellman en mode éphémère - cette valeur publique est signée à l'aide du certificat serveur afin de se prémunir des attaques Man in the Middle)
                          Le nombre aléatoire "a" est seul connu de l'extremité qui publie A. Grâce à la théorie du logarithme discret, on sait qu' il est impossible (lire : long) connaissant "A","p" et "g" de déterminer "a".
                          Or "a" ( ou plus exactement "A^b mod p = B^a mod p") est utilisé pour construire la clé de session qui chiffrera le flux avec l'algorithme de chiffrement sélectionné (stream cipher RC4 ou bien block cipher AES dans les cas de ce présent article).

                           

                          Ceci explique que ssldump ne puisse obtenir la clé de session uniquement en observant le traffic et en connaissant la clef privée RSA si ce genre de Cipher Suite est utilisé.

                           

                          Le contenu de cet article est abordé en profondeur lors notre formation "Réseaux Privés Virtuels" . ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=25 http://www.randco.fr/?p=actualites&ID=25 http://www.randco.fr/?p=actualites&ID=25

                          Par construction, le PIX en version 6.3 ne permettait pas à un paquet entré par une interface de sortir par cette même interface. Ceci était particulièrement contraignant car empechait la construction de réseaux VPN architecturé en Hub and Spoke à l'aide de PIXs : la solution alternative était alors soit d'utiliser un routeur (ou un concentrateur VPN) sur le site central, soit de mettre en oeuvre une topologie complètement maillée (full mesh).

                          D'autres scénarios étaient également impossibles :

                          • client VPN connecté au site central en IPSEC et ayant besoin d'accéder à un site tiers relié en VPN à ce site central
                          • routage par rebond sur l'interface inside du PIX (ICMP redirect désactivé sur les firewalls
                          • etc..

                          A partir de la version 7.0, via l'utilisation de la commande "same-security-traffic permit intra-interface" le traffic IPSEC pouvait enfin entrer et sortir de la même interface, corrigeant ainsi ce manque de fonctionnalité concernant les topologies VPN de type Hub and Spoke .

                          La version 7.2 apporte une fonctionnalité intéressante : c'est maintenant le traffic clair comme chiffré qui peut "rebondir" sur le PIX. On peut ainsi permettre à un client VPN nomade de sortir sur Internet via le PIX (on utilisait jusque là généralement la focntionnalité de Split Tunneling).

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=24 http://www.randco.fr/?p=actualites&ID=24 http://www.randco.fr/?p=actualites&ID=24 Une des fonctionnalités les plus visibles des Load-Balancer est la façon dont il répartissent les flux vers les serveurs réels.

                          Tout d'abord soyons clair : la répartition (c-a-d le choix du serveur pour la connexion cliente) ne se fait qu'une fois : lors de l'ouverture de la connexion

                          (( Dans le cas spécifique de HTTP, on verra que les load-balancers gèrent les sessions et qu'ainsi une suite de connexions TCP HTTP sera bien gérée comme la session d'un utilisateur unique )) : les paquets appartenant à une session TCP déjà établie sont dirigés vers le serveur choisi pour cette connexion.

                          

                          Les algorithmes implémentés sont généralement :

                          • round robin : on répartit chaque nouvelle connexion sur un serveur différent
                          • least connections : on dirige la nouvelle connexion sur le serveur qui en compte le moins à ce moment précis
                          • bandwidth : on dirige la nouvelle connexion sur le serveur qui en utilise le moins à ce moment précis
                          • hashing (certaines variantes sont nommées minmisses ou phash): en effectuant une opération sur l'adresse IP du client (ou l'URL de la demande par exemple) , typiquement condensat, bit de parité,etc.. on détermine le serveur réel cible : c'est une méthode frustre qui présuppose une distribution répartie des adresses IP des clients (on verra que c'est rarement le cas). L'avantage de cette méthode est qu'elle rend le choix du serveur déterministe et permet ainsi nativement d'assurer la persistence.
                          • weighted : on applique une des méthodes précédentes en biaisant le poids des serveurs réels (intéressant lorsque la ferme est composée de serveur de puissance hétérogènes)
                          Le choix d'un méthode de répartition est , on le voit, assez structurant pour comprendre la façon dont la charge sera répartie sur les servuers réels. Dans un prochain article, on verra comment est assurée la persistence et quelles sont les réelles opérations bas niveau réalisées par le load balanceur (i.e delayed binding) ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=22 http://www.randco.fr/?p=actualites&ID=22 http://www.randco.fr/?p=actualites&ID=22 La nouvelle campagne publicitaire d’Apple, se moque gentiment d’un des nouveaux mécanismes de sécurité introduit dans Vista : UAC (User Access Control). Le but d’UAC¹ est de séparer les privilèges nécessaires à l’utilisation quotidienne (modification du fuseau horaire -mais pas de l’heure système-, configuration d’un accès Wifi, installation de programmes ou codes mobiles - i.e ActiveX- signés, etc..) de ceux relevant des prérogatives de l’administrateur système.

                          Si l’option “Administrator Approval Mode” est activée, d’incessants pop-ups demandent la confirmation des actions lorsque celles-ci ont un impact important sur le système (ouverture d’un mail piégé, installation d’un programme non signé,etc..).

                          On sait bien que ce genre de protection est complètement inéfficace à court terme : les utilisateurs répondent mécaniquement “Allow” ou bien désactivent cette option (ce qui est d’ailleurs réalisé par défaut). C’est ce comportment dont se moque la publicité d’Apple.

                          Aux sujets des nouveautés “néfastes” introduites dans Vista, je vous recommande d’ailleurs la lecture du très instructif “A cost analysis of Windows Vista Content protection“

                          ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=21 http://www.randco.fr/?p=actualites&ID=21 http://www.randco.fr/?p=actualites&ID=21 Nous intervenons fréquement dans des sociétés qui possèdent des Load Balancers (ex. Nortel Alteon, Cisco CSS, F5 BigIP, Radware Application Switch, etc..) qui sont au coeur de leur infrastucture Web.

                          Or, la plupart du temps, le potentiel énorme de ces équipements est inexploité. La fonction première de ces équipements est de "publier" des serveurs/services (( bien que majoritairement HTTP(s) on trouve également des architectures load-balancées de serveurs Citrix ou Microsoft Terminal Server, FTP, SMTP, POP, Firewalls, etc.. )) virtuels : les requètes à destination de ces derniers sont réparties sur des fermes de serveurs réels.

                          Pour parvenir à ce résultat, les load-balancers doivent integrer des fonctions de :

                          • commutation niveau 2 (incluant le support du Spanning Tree Protocol)
                          • routage IP (incluant le support des protocoles de routage dynamiques les plus courants ainsi qu'HSRP/VRRP)
                          • firewall (NAT et protection anti-DoS)
                          • commutation niveau 4+ ((abusivement appelée niveau 7)) : choix du serveur réel (en fonction de critères tels que l'URL et suivant différents algorithmes) et maintien de ce choix au long de la session (fonctionnalité appellée persistence)
                          • synchronisation des états de session entre boitiers primaires et secondaires
                          • Health check : vérification avancée de l'état de santé des différents serveurs réels afin de connaitre leur capacité à recevoir de nouvelles requetes
                          • terminateur SSL
                          Dans une suite d'articles à venir, nous allons explorer chacune de ces fonctions en détail. ]]> webmaster@randco.fr http://www.randco.fr/?p=actualites&ID=10 http://www.randco.fr/?p=actualites&ID=10 http://www.randco.fr/?p=actualites&ID=10 Ce court billet a pour but de faire découvrir un outil de mesure des débits réseaux sous Linux par l’intermédiaire de la ligne de commande .

                          Le but n’est évidemment pas de remplacer des plateformes de supervision (en général basées sur SNMP) mais simplement de donner en un court instant les débits réseaux vus par le système. En cherchant ce type d’outil, nous avons découvert cette excellente page présentant différents outils dont bmon et bwbar.

                          Sous Ubuntu, on installe bmon classiquement :

                          root@miniU:~# apt-get install bmon
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
bmon
0 upgraded, 1 newly installed, 0 to remove and 36 not upgraded.
Need to get 49.3kB of archives.
After unpacking 197kB of additional disk space will be used.
Get:1 http://fr.archive.ubuntu.com dapper/universe bmon 2.0.1-3 Fetched 49.3kB in 2s (16.9kB/s)
Selecting previously deselected package bmon.
(Reading database ... 85434 files currently installed.)
Unpacking bmon (from .../bmon_2.0.1-3_powerpc.deb) ...
Setting up bmon (2.0.1-3) ...

                          Nous pouvons ensuite lancer ce programme qui implémente une interface intuitive et graphique (grâce à libncurses) :

                          

                          On obtient un histogramme (en in et out), le détail de erreurs, etc.. Attention, cependant car les débits affichés sont en KiloByte/s et non KiloBit/s !!

                          L’outil bwbar permet de mesuer les flux réseaux et génère une barre graphique (format png) que l’on peut faire affciher sur une page web.

                          Après l’avoir installé avec un classique apt-get install bwbar , il reste à créer un script contenant les lignes suivantes :

                          #!/bin/sh -
killall bwbar
/home/admin/bwbar eth0 1000 -k -t 60 -x 100 -y 8 --png-file /var/www/html/images/ubar.png --text-file /var/www/html/images/ubar.txt &


                          Ce script, une fois exécuté, lance en fond de tache un process bwbar qui génère une image png de 100×8 pi, représentant le débit réseau sortant de eth0, sur une référence de 1Mbits/s avec un rafraichissement toutes les 60 secondes :

                          ]]>