4 www.hakin9.orghakin9 Nº 4/2006

hakin9

5www.hakin9.org hakin9 Nr 2/2006

ActusVous trouverez ici les nouvelles du monde de la sécu-rité des systèmes informatiques.

CD-ROMhakin9.liveNous vous présentons le contenu et le mode de fonc-tionnement de la version récente de notre principale distribution hakin9.live.

OutilsTTpU (TDFS's TCP/IP Packets Unlimited)Alberto Maria ScattoloTTpU est un outil capable de générer n'importe quelle sorte de paquets TCP/IP en permettant de spécifier un grand nombre d'options IP et TCP.

AmapKonrad KierysAmap est un outil, qui, contrairement aux autres scanneurs, identifie les démons de l'ordinateur donné d'après les réponses sur les paquets envoyés et non d'après les numéros de ports où ils sont lancés.

Interview On ne peut être jamais totalement sûrInterview avec dr Lars Packschies

DossierProtection réseaux grâce aux puits stationnaires et aux puits IP basés sur les évènementsVictor OpplemanRien n'est plus efficace que la présentation, même succincte, des techniques de protection des réseaux afin de mieux se défendre contre les attaques de déni de service ou attaques DoS.

FocusSécurité d'IPv6Rita PužmanováLe présent article est consacré à la sécurité intégrée, l'un des principaux avantages d'IPv6 par rapport à son prédécesseur IPv4. Nous comparerons aussi les deux protocoles en ce qui concerne la sécurité de la communication en tenant compte des failles de sécurité.

Virus ou pas virus ?Il n'y a pas si longtemps, le bruit avait couru que le premier virus agissant autant dans différentes versions de Windows que dans les systèmes Linux avait été créé. Pour rappeler (d'après Wikipédia) – Un virus informatique est un logiciel malveillant écrit dans le but de se dupliquer sur d'autres ordinateurs. [...]. Il peut se répandre à travers tout moyen d'échange de données numériques [...]. Comment, suivant les informations ci-dessus, comprendre la description de laquelle il résulte que pour activer le virus sous Linux, l'uti-lisateur doit télécharger l'archive, le compiler et exécuter le fichier binaire ? Pourquoi Kaspersky Lab – où certainement travaillent des spécialistes de ce domaine – a appelé si volontiers une application malicieuse un virus multiplatefor-mes et l'a nommé Virus.Linux.Bi.a/Virus.Win32.Bi.a, bien qu'à première vue, ce ne soit pas un virus ? Pourquoi (si c'est vrai) avec les noyaux plus récents de la série 2.6, est-il nécessaire d'appliquer un correctif écrit par Linus Torvalds pour faire fonctionner le virus ? Pourquoi a-t-on annoncé que l'apparition de ce programme termine l'époque où les systèmes avec un pingouin étaient sûrs, bien que ce ne soit qu'un POC (Proof of Concept), et les virus pour Linux (à présent, il en existe environ 40), MacOS (quelques dizai-nes) et systèmes commerciaux UNIX (quelques) étaient déjà conçus depuis longtemps ? Est-ce que – à la fin – ces faits sont liés aux tentatives de grands éditeurs des programmes anti-virus d'entrer sur le marché des systèmes Linux ?

La conviction de la résistance totale de Linux aux virus est erronée et on le sait depuis quelques temps. D'ailleurs, au fur et à mesure que ce système devient de plus en plus populaire non seulement dans les environnements indus-triels mais aussi dans les bureaux, la probabilité de conce-voir des programmes malicieux s'approchent de 1. Linux de bureau avec Firefox et Thunderbird n'atteindra jamais une telle vulnérabilité à tous les types de virus que Windows avec Internet Explorer et Outlook (à présent, il existe plus de 60 000 de ce type de programmes dont la plupart sont très destructifs et se répandent facilement).

Malgré tout, le comportement de Kaspersky Lab (qui à présent ne fournit pas des informations sur le virus détecté) m'étonne. Je suis curieux de savoir quand on commencera une promotion agressive des outils anti-virus pour Linux, qui d'ailleurs existent déjà.

Encore une explication de ce phénomène me vient à l’esprit : Microsoft avant la première de Windows Vista sur le marché veut discréditer Linux comme système sûr et con-vaincre les personnes qui voudraient passer à un système gratuit, que celui-ci est tout aussi vulnérable aux dangers provenant du réseau. Cette opinion certainement aiderait les utilisateurs à prendre une décision d'acheter une nouvelle version d'un système déjà connu au lieu de passer à un nou-veau système, difficile et aussi vulnérable aux attaques...

Il ne faut pas oublier une chose – même les programmes anti-virus très avancés ne sont pas capables de penser à la place des utilisateurs et des administrateurs. Le plus important est d'être conscient des dangers et de savoir où trouver les informations sur les méthodes de défense et de prévention. Ces informations – indépendamment du niveau de danger de la part de Virus.Linux.Bi.a/Virus.Win32.Bi.a – sont constamment fournies par le magazine hakin9.

Je vous invite à la lecture.Marek Bettman

12

14

16

06

10

13

30

4 www.hakin9.orghakin9 Nº 4/2006

hakin9

5www.hakin9.org hakin9 Nr 2/2006

Fiche techniqueAnalyse du trafic réseauBartosz PrzybylskiPcap est une des libraires les plus utilisées servant à chiffrer le trafic réseau. Elle offre un accès très détaillé aux couches ISO/OSI spécifiques.

PratiqueConstruction d'un désassembleur de taille orienté HookingRubén SantamartaLes différents domaines du reverse engineering se convergent dans un point. Nous présentons diffé-rentes techniques pour faciliter notre analyse des programmes malveillants.

Problèmes d'authentification HTTPEmilio CasbasLe protocole HTTP nous offre le mécanisme d'autori-sation de type requête-réponse qui peut être exploité par un serveur en réseau ou un proxy pour accepter ou refuser l'accès aux ressources du réseau.

AlentoursSocial engineeringTomasz TrejderowskiLa sociotechnique existe depuis le début de l'hu-manité, mais l'exploitation de ses règles pour les attaques vers les entreprises et les systèmes infor-matiques n'est présente que depuis quelques derniè-res années.

BibliothèqueAbsolument à lire : 19 Deadly Sins of Software security: Programming flows and how to fix them ;Network Security Bible ; Linux Server Security ; Intro-duction aux scripts shell.

Éditorial Où sont passés les anti-virus ?Konstantin Klyagin

Dans le prochain numéro :Les articles qui seront publiés dans le numéro de hakin9 à venir.

64

70

78

46

80

82

Le périodique hakin9 est publié par Software-Wydawnictwo Sp. z o.o.Piaskowa 3, 01-067 Varsovie, PologneTél. +48 22 887 10 10, Fax. +48 22 887 10 11www.hakin9.org

Directeur de la publication : Jarosław Szumski

Imprimerie, photogravure : 101 Studio, Firma Tęgi Ekonomiczna 30/36, 93-426 ŁódźImprimé en Pologne/Printed in Poland

Abonnement (France métropolitaine, DOM/TOM) : 1 an (soit 6 numéros) 38 €

Dépôt légal : à parutionISSN : 1731-7037Distribution : MLP Parc d’activités de Chesnes, 55 bd de la Noirée BP 59 F - 38291 SAINT-QUENTIN-FALLAVIER CEDEX(c) 2005 Software-Wydawnictwo, tous les droits réservés

Rédacteur en chef : Marek Bettman marekb@software.com.plRédacteurs : Aneta Cejmańska anetta@software.com.plEwa Dudzic ewal@software.com.plPréparation du CD : Aurox Core TeamMaquette : Anna Osiecka annao@software.com.plCouverture : Agnieszka MarchockaTraduction : Iwona Czarnota, Aneta Lasota, Marie-Laure Perrotey, Grażyna WełnaBêta-testeurs : Thomas Bores, Tony Boucheau, Pascal Foulon, Pascal Miquet, Romain Lévy, Augustin Pascual, Julien Poulalion, Alain Ribault

Les personnes intéressées par la coopération sont priées de nous contacter : cooperation@software.com.pl

Abonnement : abonnement@software.com.plFabrication : Marta Kurpiewska marta@software.com.plDiffusion : Monika Godlewska monikag@software.com.plPublicité : publicite@software.com.pl

Si vous êtes intéressé par l’achat de licence de publication de revues merci de contacter :Monika Godlewskae-mail : monikag@software.com.pltél : +48 (22) 887 12 66fax : +48 (22) 887 10 11

La rédaction fait tout son possible pour s’assurer que les logiciels sont à jour, pourtant elle décline toute responsabilité pour leur utilisation. Elle ne fournit pas de support technique lié à l’installation ou l’utilisation des logiciels enregistrés sur le CD-ROM. Tous les logos et marques déposés sont la propriété de leurs propriétaires respectifs.

La rédaction utilise le système PAO Pour créer les diagrammes on a utilisé le programme

Le CD-ROM joint au magazine a été testé avec AntiVirenKit de la société G Data Software Sp. z o.o.

La revue hakin9 est publiée en 7 versions :

FR PL CZ EN

IT DE ES

AVERTISSEMENTLes techniques présentées dans les articles ne peuvent être utilisées qu'au sein des réseaux internes.La rédaction du magazine n'est pas responsable de l'utili-sation incorrecte des techniques présentées.L'utilisation des techniques présentées peut provoquer la perte des données !

52

Actus

hakin9 Nº 4/2006 www.hakin9.org6

En bref

www.hakin9.org 7hakin9 Nº 4/2006

Failles dans MacOS XTom Ferris, spécialiste d'analyses de sécurité dans les systèmes informatiques, a publié les détails concernant les failles découver-tes dans le système d'exploitation Mac OS X. La plus importante faille se trouve dans le naviga-teur Safari. Elle permet à l'intrus d'installer n'importe quel code ou l'endommager. Une autre faille peut être utilisée à l'aide d'un fichier graphique au format TIFF, BMP et GIF. L'attaque efficace provoque la panne du programme qui a servi à ouvrir le fichier préparé. Une autre erreur se trouve dans la manière de gérer les fichiers compressés. Elle endommage l'application ou exécute n'importe quel code dans l'ordinateur attaqué.

La première de failles a été considérée par Ferris comme très importante, les autres étant moins menaçantes.

Les organisations spécialisées dans la sécurité informatique, comme SANS Internet Storm Centre, évaluent la menace comme critique car les failles permettent de lancer à distance n'importe quel code ou d'effectuer l'attaque DoS.

Attaques des anti-virusLes spécialistes de la sécurité informatique ont informé les internautes du courriel, déguisé en lettre d'un de producteurs de pro-grammes anti-virus, qui constitue une menace importante pour les systèmes informatiques.

Le faux courriel sert en réalité aux cyber-criminels à rendre impossible l'actualisation de logiciels anti-virus, installés sur l'ordinateur attaqué.

Le courriel informe que l'ordina-teur du destinataire a été infecté par le virus w32.aplore@mm. Il joint aussi un lien pour supprimer le virus. Après que l'utilisateur ait cliqué sur le lien, un code s'exé-cute et modifie la configuration de l'ordinateur de sorte que le logiciel anti-virus n'effectue plus les mises à jour.

Le faux courriel a d'abord été découvert en Asie qui a ensuite transmis les informations le concernant en Europe et en Amérique.

Les spécialistes de l'École Poly-technique de Wrocław (Polo-

gne) travaillant sous la direction du professeur Mirosław Kutyłowski ont découvert les failles de protocoles SSL/TLS et SSH, les protocoles les plus populaires garantissant une communication sécurisée sur Internet.

Lorsque le virus utilise le méca-nisme découvert et infecte les logi-ciels de l'utilisateur, il peut déchiffrer tous les messages envoyés et reçus par l'utilisateur à l'aide de ces proto-coles.

La nouveauté de l'attaque con-siste à avoir une sorte de monopole : même une information complète sur le virus (et le matériel cryptographi-que y compris) ne permet pas d'ef-fectuer l'attaque. Il est nécessaire

Failles en SSH et SSL/TLSde disposer des clés cryptographi-ques supplémentaires, connues au concepteur du virus. De plus, le programme infecté se comporte de la même manière que le programme sain.

La faille découverte dans les protocoles est très importante, vu la possibilité d'un espionnage éco-nomique potentiel, un accès non autorisé aux banques Internet, etc. Il est important d'avoir confiance en les producteurs qui fournissent des logiciels sans codes sources.

Les spécialistes ont aussi pro-posé des modifications de standards, permettant d'éliminer les menaces analysées. Ils ont mis au courant les organismes de sécurité et on va bientôt proposer une correction du standard international SSL.

Les ordinateurs produits par les producteurs chinois doivent être

dotés d'un système d'exploitation avant de quitter l'usine – c'est le décret officiel du gouvernement à Pékin. Cela doit résoudre le problème de piratage dans le pays et atténuer le conflit avec les États-Unis.

La Chine est un paradis pour les vendeurs de logiciels piratés. D'après l'agence Reuters, il est pos-sible d'acquérir la version piratée de Windows XP Professional pour 30 yuans. La version originale coûte environ 2 milles yuans (249 dollars).

On estime que neuf programmes informatiques sur dix en Chine sont des copies illégales. Les États-Unis n'aime pas ce fait car le pays est expéditeur de la plupart des logiciels. La question a été discutée pendant la récente rencontre du président de Chine Hu Jintao avec le président Bush.

Le décret concernant l'installa-tion en fabrique du système d'exploi-tation doit démontrer que la Chine se préoccupe sérieusement de la lutte contre les pirates. Ce n'est pas tout – l'action d'échange des logiciels piratés contre les logiciels légaux

Chine, piratage et Microsoftdans les administrations a déjà coûté 17,5 millions de dollars au gouverne-ment de Pékin.

Comme vous pouvez le consta-ter, Microsoft bénéficie de cette lutte contre les pirates ; cette semaine, l'entreprise a officiellement signé les contrats avec quatre producteurs d'ordinateurs pour vendre le système Windows. On prévoit que, Microsoft gagnera 1,6 milliards de dollars au cours de cette année.

Figure. Nouveau contrat ?

Actus

hakin9 Nº 4/2006 www.hakin9.org6

En bref

www.hakin9.org 7hakin9 Nº 4/2006

Actualisation de BagleLes ordinateurs infectés par le ver Bagle ont commencé récemment à télécharger la mise à jour, permet-tant d'équiper le ver de plusieurs nouvelles fonctions – informent les représentants de la société F-Secure. D'après leurs analyses, l'objectif principal de l'actualisation consiste à installer un nouvel outil plus performant pour envoyer les pourriels.

Selon Mikko Hypponen, chef du département d'étude de F-Secure, les concepteurs de Bagle ont com-mencé l'actualisation de leur ver. On ne connaît pas le nombre exact des ordinateurs, infectés par ce ver. Selon F-Secure, la mise à jour a été déjà installée sur des milliers d'ordinateurs.

Les entreprises, chargées de pro-duire les logiciels anti-virus, tentent d'arrêter le processus de mise à jour en bloquant les serveurs les pro-posant. Hélas, les concepteurs de Bagle travaillent aussi ; après qu'un serveur soit désactivé, l'actualisation apparaît sur un autre (les serveurs hôtes slovaques et américains ont pour l'instant été fermés).

Rappelons les faits : Bagle n'est pas destructif et sa présence sur l'ordinateur infecté est quasi invisi-ble (le ver infecte le système Win-dows). Il est toutefois dangereux car il permet aux utilisateurs non autorisés d'accéder à l'ordinateur infecté. Les programmes, comme Bagle, sont utilisés pour créer des botnets, réseaux d'ordinateurs contrôlés à distance, via lesquels les criminels envoient des pourriels ou effectuent des attaques DoS.

Oracle corrigeOracle a publié une actualisation collective de son logiciel (Oracle Critical Patch Update).

L'actualisation corrige 36 failles dans plusieurs produits, notamment Oracle Database, Oracle Applica-tion Server, Oracle Collaboration Suite, Oracle E-Business Suite and Applications, Oracle Pharmaceutical Applications et Oracle Enterprise Manager. De plus, il a publié une version actualisée pour vérifier les mots de passe par défaut dans les produits Oracle (Oracle Default Password Scanner).

Pour plus d'informations, visitez le site officiel http://www.oracle.com/technology/deploy/security/pdf/cpuapr2006.html

Un client polonais a trouvé une Land Rover de 1998, état

parfait, à 2900 euros (y compris le transport) sur un service d'enchères http://www.mobile.de. Une certaine Alexa Mangel voulait vendre cette voiture. Elle parlait de son divorce et de déménagement en Grande Bre-tagne dans ses courriels. Elle expli-quait que la voiture avait été achetée en Allemagne, ce qui lui posait des problèmes vu que le volant se trou-vait à droite et non à gauche.

La transaction devrait se dérouler via l'entreprise International Cargo Spedition (ICS).

Le scénario est suivant : Mangel livre la voiture à l'intermédiaire (ICS) et couvre les frais du transport. Dès que l'entreprise reçoit la voiture, elle contacte le client et lui demande de payer sous 24 heures.

Pour l'instant, rien n'est sus-pect : quand on achète des objets d'une grande valeur sur Internet, on s'adresse souvent aux services inter-médiaires (Escrow.com appartenant à eBay est le plus connu). Le client verse l'argent sur le compte bancaire de l'entreprise, le vendeur envoie la marchandise. Et lorsque le client confirme sa réception, l'argent est versé sur le compte du vendeur. Mais ici, le client devait payer à l'avance en espèces via Western Union à un des agents ICS à Londres.

Alexa Mangel soulignait que le client avait 10 jours pour tester la voiture et s'il ne l'aimait pas, il avait la possibilité de la retourner sans avoir des frais supplémentaires. Elle a même envoyé une liste de points de

Escrocs dans les enchèresservices près du domicile du client où il pourrait effectuer un virement.

Plusieurs jours plus tard, le client a reçu un courriel de ICS contenant le numéro du colis. Il a pu suivre son parcours via Internet mais il était méfiant : il a tapé le nom de l'entre-prise dans un moteur de recherche. Il s'est avéré qu'on parlait beaucoup de ICS sur les forums de discussion pour avertir des gens contre ces escrocs (notamment aux Pays-Bas, en Allemagne et en République Tchèque). L'entreprise existait sous des noms divers : World Shipping, International Cargo Spedition, Euro Parcel Distribution, etc. Elle changeait aussi les adresses Web toutes les semaines : il en existe plusieurs dizai-nes, comme autoscoutmarket.com, europe- transcont inentals .com, global-shipping.org, express-ic.com, international-cargo-express.com, cargo-worldwide.com, onlineshipping-worldwide.com, tt-transports.com. Tousles sites sont des vitrines profession-nellement préparées (actuellement, ils sont tous inaccessibles). Ces escrocs changent en revanche rarement les coordonnées téléphoniques (impossi-ble de les joindre) et les adresses du siège, souvent les mêmes.

Le mécanisme de l'escroquerie est simple : pas de voiture, le ven-deur et l'entreprise intermédiaire sont fictifs et servent à escroquer de l'argent.

Les faux intermédiaires sont apparus en 2002. En Europe, on a parlé des cas des personnes qui ont perdu des milliers euros à cause d'eux.

Figure. La vente par Internet – est-elle sécurisée ?

Actus

hakin9 Nº 4/2006 www.hakin9.org8

En bref

www.hakin9.org 9hakin9 Nº 4/2006

Le premier spammeur aus-tralien derrière les barreauxL'organisme australien ACMA (Australian Communications & Media Authority) a informé qu'il avait réussit à condamner la première personne, accusée d'après la loi anti-spam Australian Spam Act.

Wayne Mansfield a été reconnu coupable d'avoir envoyé 56 millions de courriels non sollicités. L'accusé expliquait que les utilisateurs de messageries électroniques avaient accepté de recevoir ces messages. Mansfield a également essayé de préciser que la liste d'adresses auxquelles il avait envoyé des pourriels avait été créée avant la mise en place de Australian Spam Act, l'argument qui a été rejeté par le juge Nicholson.

La cour fédérale n'a pas encore décidé de la sentence.

Cheval de Troie réclame de l'argentLe code nuisible Ransom.A crée des fichiers .exe sur le disque et en informe ensuite l'utilisateur ; les fichiers supprimés seront sauve-gardés dans un répertoire caché et récupérés lors du processus de désinstallation. Le cheval de Troie informe aussi qu'il supprimera un fichier toutes les 30 minutes.

Les images pornographiques s'affichent à l'écran de l'ordinateur infecté. Il y a aussi une information qu'à chaque démarrage de l'ordi-nateur, d'autres copies du cheval arrivent sur le disque et supprime-ront d'autres fichiers importants. En affichant le Gestionnaire de tâches, l'utilisateur verra des processus lancés par le troyen. Si l'utilisa-teur tente d'arrêter l'un d'entre eux, il verra s'afficher une image et un message : Nous ne mou-rons pas. Nous nous multiplions. Ctrl+Alt+Supp ne marche pas aujourd'hui, n'est-ce pas ?

Les concepteurs du code informent qu'il n'existe qu'une seule manière de se débarrasser du troyen. Il faut envoyer la somme de 10,9 dollars américains via le service Wes-tern Union et indiquer le numéro 4870930101308697 à la place du numéro d'utilisateur. Une fois la somme demandée versée, l'utilisa-teur reçoit une confirmation avec un numéro d'identification. Il faut saisir ce numéro sur l'ordinateur infecté pour désinstaller le cheval de Troie.

Après sept années de débats juridiques, la rencontre finale

entre Microsoft et la Commission Européenne va débuter.

Un procès-marathon commence à mi-avril ; l'entreprise américaine Microsoft veut essayer d'annuler les amandes pour l'abus apparent de la position sur le marché. C'est pro-bablement le procès anti-monopole le plus important dans l'histoire de l'Union Européenne. La plus grande entreprise informatique dans le monde demande que le Tribunal de Première Instance de l'union annule la décision bruxelloise d'il y a deux ans.

Le 24 mars 2004, la Commission Européenne a considéré que Micro-soft abusait de sa position dominante sur le marché et l'a condamné à une amende record s'élevant à 497 mil-lions euro. La commission a égale-ment demandé à Microsoft de changer sa stratégie commerciale et de vendre le système d'exploitation Windows en version dépourvue du lecteur multi-média Windows Media Player (WMP) et de partager avec les concurrents (contre un paiement) le savoir sur le fonctionnement du système d'exploi-tation Windows notamment.

Ces deux demandes ont fait le plus mal à Microsoft. Payer une amende aussi élevée ne posait pas de problème à une entreprise dont les bénéfices net de l'année fiscale dernière s'élevaient à 12,25 milliards dollars. La stratégie contestée par Bruxelles est une base de l'expansion de Microsoft. Profitant du fait qu'envi-ron 90 % des ordinateurs fonctionnant dans le monde est équipé du système Windows, Microsoft affaiblit lentement les concurrents dans d'autres seg-ments du marché.

En vendant le système d'exploita-tion avec WMP, Microsoft a miné les produits concurrentiels (par exemple RealPlayer de RealNetworks) car les consommateurs n'avaient pas besoin d'installer des applications concurren-tielles. De l'autre côté, les entreprises proposant les produits de gestion de serveurs y ont aussi perdu car Micro-

Microsoft contre la Commission Européenne

soft ne divulgue pas l'information sur la façon dont les serveurs communi-quent avec le système Windows. Pour cette raison, les programmes des con-currents sont moins efficaces.

Le géant de Redmond rejette les reproches et essaie de persuader que la décision de la Commission Européenne était injuste car blo-quait l'innovation. La question est de savoir si les entreprises peuvent améliorer leurs produits en y ajou-tant les nouvelles fonctionnalités et si l'entreprise, qui réalise des béné-fices, doit partager son savoir avec les concurrents est le véritable enjeu de ce procès – dit le communiqué officiel de Microsoft publié avant le débat en justice de lundi.

Ce sera en quelque sorte un spectacle. Cinq jurés (et non 13 comme d'habitude) entendront les parties ; ces jurés font partie de la Grande Chambre du Tribunal de Première Instance présidée par Bo Vesterdorf, président-juge de SPI. Les meilleurs avocats doivent repré-senter les deux parties. Le PDG de Microsoft, Steve Ballmer, suit de près le déroulement du procès.

La Commission Européenne est convaincue que son expertise de 2004 pourrait se défendre devant le tribunal. Nous avons de bons arguments, assure la commissaire à la concur-rence, Neelie Kroes. La coalition des entreprises, comme IBM, Nokia, Oracle et Sun Microsystems supporte la Commission Européenne.

L'enjeu du procès devient de plus en plus important car l'histoire peut bientôt se répéter. L'année prochaine, Microsoft a en effet prévu de publier un nouveau système d'exploitation, Vista. De nouvelles applications seraient y jointes : protection Internet, création et lecture des documents électroni-ques, etc. La commissaire Kroes a déjà annoncé que Vista (ou plutôt son contenu) inquiétait la Commission. Si toutefois le Tribunal de Première Ins-tance conteste son analyse et annule la décision de 2004, l'Union aura les mains liées.

Actus

hakin9 Nº 4/2006 www.hakin9.org8

En bref

www.hakin9.org 9hakin9 Nº 4/2006

Google achète un nouvel algorithmeL'étudiant israélien Ori Alon a vendu à Google les droits concernant le nouvel algorithme de recherche du texte sur les sites Internet. La technologie appelée Orion fait partie de sa thèse de doctorat sur laquelle Alon travaille à l'Université de la Nou-velles Galles du Sud en Australie.

Le concepteur du nouvel algo-rithme a avoué qu'il y travaillait toujours et la version finale devrait être disponible dans 18 mois. Les sources proches de Google ont en revanche annoncé que l'Isralélien avait déjà quitté l'université et avait été embauché dans la centrale principale de l'entreprise où il continuait les travaux sur la nouvelle techno-logie. Le rectorat de l'université de la Nouvelles Galles du Sud a informé que l'achat de l'algo-rithme Orion avait été également discuté avec Microsoft et Yahoo.

Internet Explorer dangereuxMichał lcamtuf Zalewski a décou-vert une faille importante dans le navigateur Internet Explorer, per-mettant probablement d'exécuter n'importe quel code.

La faille est liée à la gestion incorrecte des balises intégrées OBJECT. En téléchargeant une page préparée, il est possible de forcer le navigateur à gérer incorrectement la mémoire. Il est probable de choisir le code HTML, de sorte que le système exécute une suite d'instructions.

Pour se servir de la faille, l'utili-sateur doit ouvrir la page préparée dans le navigateur.

Salon de discussion !Un salon de discussion IRC (Tchat) pour les personnes désireux d’avoir de l’aide sur les différents tutoriels. Vous pourrez aussi poser vos questions directe-ment aux nombreux correcteurs/beta-testeurs présents sur le salon, partager vos idées et vos connaissances sur la sécurité IT. Nous espérons que vous serez nombreux !

Le salon se trouve sur le serveur Epiknet : irc.epiknet.org dans la salle #hakin9. Avec mIRC/XChat: „/server irc.epiknet.org” puis „/join #hakin9”. L’administrateur du salon est m0rtix.

Un virus est apparu sur Internet. Il infecte aussi bien le système

Windows que Linux.Les employés de Kaspersky

Lab l'ont découvert et lui ont donné le nom suivant : Virus.Linux.Bi.a/Virus.Win32.Bi.a.

Le code (car il ne s'agit pas d'un virus sensu stricte mais plutôt de proof of concept) ne fait pas de grands dommages et son fonction-nement est restreint. Il est incapa-ble de se propager, il n'infecte que les fichiers du répertoire où il a été installé. Pour qu'il infecte les fichiers, l'utilisateur doit le télécharger depuis Internet et le lancer.

La menace d'infection est donc minime, en particulier pour les ordi-nateurs équipés du système Linux car leurs utilisateurs utilisent rarement les droits d'administrateur et s'ils lancent les programmes externes, ils le font dans les répertoires créés spéciale-ment pour ces programmes.

Linux.Bi.a/Virus.Win32.Bi.a cons-titue une preuve en plus qu'il est possi-ble décrire un virus qui fonctionne sur deux plates-formes.

Il a été probablement créé par une personne de la vieillie école qui a démontré ainsi qu'elle était capa-ble d'écrire ce code. La plupart de logiciels nuisibles sont créés actuel-lement à la demande des groupes spécialisés pour lesquels infecter les ordinateurs est un moyen de faire des bénéfices. Plusieurs messages ont été trouvés à l'intérieur du virus : Greetz to: Immortal Riot, #RuxCon!

Virus multi plates-formesRuxCon est un e-zin distribué dans les années 90 par les spécialistes de la sécurité.

On analyse toujours le code de Linux.Bi.a/Virus.Win32.Bi.a. Grâce aux récents tests, on a découvert que le virus ne travaillait pas avec les versions les plus récentes de noyaux, série 2.6.

Après une comparaison à la série 2.4, il s'est avéré qu'à l'origine de cette incapacité de travail se trouvait l'utilisation manuelle dans l'assem-bleur de l'ancien appel système, une erreur minime du traitement de regis-tres par GCC et les modifications dans la configuration standard de noyaux 2.6.16.x. La personne qui a permis au virus de fonctionner dans les noyaux les plus récents est Linus Torvalds, auteur du correctif !

L'utilisation de l'appel du système, abandonnée depuis longtemps, dans le code du virus peut suggérer que Virus.Linux.Bi.a a été créé par un éditeur de logiciels anti-virus à des fins de marketing. Ces expériences peuvent avoir du sens lorsque les systèmes d'installation et de lance-ment de logiciels par les utilisateurs, par exemple Klik et FUSE seront plus répandus sous Linux.

Les spécialistes de Kaspersky Lab soulignent que le code Bi.a peut être utilisé pour créer des applica-tions plus malicieuses. Ils pensent aussi que le nombre de virus, capables d'infecter simultanément Windows, Linux et Mac OS X, aug-mentera dans le futur.

Figure. Site officiel de Kaspersky

CD-ROM

hakin9 Nº 4/2006 www.hakin9.org10

Le CD joint au magazine contient hakin9.live (h9l) en version 3.0-aur – une version bootable d'Aurox contenant divers outils, de la documen-

tation, des tutoriaux et les matériaux complémen-taires des articles. Pour commencer le travail avec hakin9.live, il vous suffit de démarrer l'ordinateur à par-tir du CD fournit. Après le démarrage du système, vous pouvez ouvrir la session en tant qu'utilisateur hakin9 sans mot de passe.

La structure des répertoires se présente comme suit :

• doc – la documentation au format HTML,• hit – à la une du numéro Safety Lab Shadow Data-

base Scanner – un scaner excellent de la sécurité des bases de données,

• art – matériaux complémentaires aux articles : lis-tings, scripts, programmes indispensables,

• tut – tutoriaux,• add – livres et autres documents au format PDF

(Linux IPv6 HOWTO, Securing Debian Manual, Snort Users Manual, SQL Injection Protection).

Les anciens outils se trouvent dans les sous-répertoires _arch, par contre les nouveaux –sont dans les répertoires principaux à l'image de la structure ci-dessus. Si vous parcourez le CD, cette structure est disponible dans le sous-répertoire /mnt/cdrom.

La version 3.0-aur h9l est basée sur la distribution Aurox Linux et les scripts générés automatiquement sur (http://www.aurox.org/pl/live). Les outils non dis-ponibles sur le CD joint au magazine sont installés à partir des paquets du répertoire d'Aurox à l'aide du répertoire yum.

hakin9.live

Il y a eu un ensemble de modifications par rapport à la version h9l 2.9.1-ng, tout d'abord la distribution a été changée ainsi que le passage de Fluxbox à l'environne-ment graphique KDE

Tutoriaux et documentationLa documentation contient, entre autres, les tutoriaux pré-parés par la rédaction avec les exercices pratiques pour les titres tel que : Problèmes d'authentification HTTP, Analyse du trafic réseau. Tours de passe-passe pour pare-feux sont conçus pour être utilisés sur hakin9.live. Grâce à cette solution, vous évitez tous les problèmes relatifs aux différentes versions de compilateurs, à la localisation de fichiers de configuration ou aux autres op-tions nécessaires pour démarrer les programmes dans un environnement donné.

Nous vous souhaitons un travail agréable avec hakin9.live et nous attendons vos suggestions. l

Rédaction de hakin9

Attention !Safety-Lab propose aux lecteurs du magazine Hakin9 la ver-sion complète de Shadow Database Scanner valable sur 2 adresses IP pendant 30 jours. Vous devez indiquer 2 adresses IP de serveur de base de données par email à l'adresse sui-vante : support@safety-lab.com.

La version complète sera valable pendant 30 jours dès réception des adresses IP. Pour recevoir dès à présent votre version, veuillez écrire à support@safety-lab.com en indiquant dans l'objet de votre message hakin9-safety-lab-offer. Offre valable jusqu'au 30 septembre 2006.

Figure 1. Bootez hakin9.live Figure 2. Écran de bienvenue

S’il vous est impossible de lire le CD, et que ce dernier n’est pas en-dommagé physiquement, essayez de le lire dans au moins 2 lecteurs différents.

En cas de problème avec votre CD, envoyez-nous un message à l’adresse suivante : cd@software.com.pl

12

Outils

hakin9 Nº 4/2006 www.hakin9.org 13hakin9 Nº 4/2006www.hakin9.org

Outils

La majorité des connexions sur un réseau repose sur les protocoles TCP (Transmission Control Protocol) et IP (Inter-net Protocol). Le protocole TCP définit comment établir et fermer une connexion, comment conserver les paquets dans le bon ordre et comment agir lorsque certains paquets manquent ou en cas d'erreurs. Le protocole TCP réalise toutes ces tâches en utilisant des options particulières, appelées drapeaux TCP, ainsi que les numéros de séquen-ces et d'accusés de réception. Ces opérations sont gérées par le système d’exploitation de sorte que les utilisateurs n'aient pas à s'en soucier. Et s'il était possible d'indiquer l'IP source et de destination, le port source et de destination, les numéros de séquences et d'accusés de réception, les drapeaux TCP, la taille des fenêtres et les données faculta-tives à envoyer avec les paquets ? TTpU peut s'en charger. Les possibilités sont réellement nombreuses. Un renifleur de réseau fonctionnant en mode espion doit, par exemple, pouvoir observer le trafic TCP. Grâce à TTpU, vous pouvez lancer de nombreux types de scans, comme par exemple les scans syn et connect.

Le concept du scan syn est très simple : un paquet marqué SYN est envoyé à l'hôte distant sur un certain port. Si le port est fermé, un paquet marqué RST et ACK sera retourné. Si rien n'est retourné, il est probable qu'un élément (un pare feu, par exemple) bloque ce paquet, ce qui signifie que le port est filtré. Si vous souhaitez lancer un scan de type connect, il faut essayer d'établir une con-nexion en envoyant un paquet SYN. Si le port distant est ouvert, un paquet SYN et ACK envoyé par l'hôte distant sera retourné. Voici la syntaxe des TTpU :

# ttpu <network interface> <source IP> <source port>

<destination ip> <destination port> <sequence number>

<acknowledgment number>

<urg> <ack> <psh> <rst> <syn> <fin> <window size> [data]

Supposons que vous souhaitiez scanner le port 80 sur l'hôte 192.168.0.94 ; le code sera le suivant :

# ttpu eth0 192.168.0.23 32456 192.168.0.94 80 3718131341 0

0 0 0 0 1 0 8192

Pour pouvoir injecter des données dans une connexion établie, il faut maîtriser quelques notions fondamentales. Chaque paquet TCP stocke deux numéros, le numéro de

séquence et celui de l'accusé de réception. Ces numéros sont utilisés afin de maintenir les paquets dans le bon ordre, de sorte que le système puisse déterminer leur traitement.

Supposons, par exemple, que le serveur cible soit 192.168.0.94:65534. Grâce à un renifleur de réseau, nous parviendrons à intercepter les informations sui-vantes : le client est 192.168.0.23:33128, le numéro de séquence, 1674837801, et le numéro d'accusé de récep-tion, 1682618503. Si nous envoyons un paquet avec les numéros de séquence et d'accusé de réception corrects, le serveur le validera. En revanche, si nous le marquons avec des drapeaux sans sens comme SYN PSH ACK, le serveur nous retournera un paquet RST et fermera la connexion.

# ttpu eth0 192.168.0.94 33128 192.168.0.23 65534 1674837801

1682618503 0 1 1 0 1 0 8192

Grâce à TtuP, il est possible de réaliser certaines actions permettant de tester les vulnérabilités de systèmes d'ex-ploitation à distance.

Certains systèmes d'exploitation sont connus pour être vulnérables aux paquets déclarant les mêmes hôtes et ports en tant que source et destination. Windows XP SP2 (sans pare feu) en fait partie. Supposons que 192.168.0.94 exécute un système vulnérable à ce genre d'attaques alors que le port 139 est ouvert.

# ttpu eth0 192.168.0.94 139 192.168.0.94 139 1674837801 0 0

1 1 0 1 0 8192

Sur un système Windows XP SP2, cette action produira en 15 secondes à peine un déni de services, avec une utilisation totale de l'unité centrale.

Il existe bien d'autres vulnérabilités pouvant être tes-tées grâce à TTpU. Il est ainsi possible d'inonder un ser-veur de requêtes de connexion, au moyen d'une attaque d'inondations SYN, en envoyant une grande quantité de paquets SYN à partir de différents hôtes et ports.

TTuP permet également de détecter un système d'ex-ploitation à distance. Chaque dispositif utilisant le protocole TCP pour communiquer avec d'autres dispositifs sur un réseau doit respecter la référence TCP. Vous trouverez de plus amples informations sur le site http://www.insecure.org/nmap/nmap-fingerprinting-article.html

Alberto Maria Scattolo

Système d'exploitation : LinuxLicence : distribution, téléchargement et utilisation libreApplication : générateur de paquets TCP/IPPage d'accueil : http://www.poetidistrada.com/ttpu/

TTpU est un outil capable de générer n'importe quelle sorte de paquets TCP/IP en permettant de spécifier un grand nombre d'options IP et TCP.

TTpU (TDFS's TCP/IP Packets Unlimited)

12

Outils

hakin9 Nº 4/2006 www.hakin9.org 13hakin9 Nº 4/2006www.hakin9.org

Outils

Démarrage rapide : Imaginez que vous avez besoin d'informations sur les services lancés sur un ordina-teur donné. Aussi bien Nmap, le plus populaire de scanneurs, que d'autres outils de ce type, scannent par défaut les ordinateurs sélectionnés d'après les ports ouverts. Ensuite, ils attribuent les services aux ports ouverts, d'après les schémas par défaut. C'est un mécanisme très simple qui n'analyse pas en fait les démons lancés sur le serveur mais les ports ouverts dessus. Chaque administrateur conscient peut alors se protéger facilement contre les résultats du scannage de ce type car il suffit de modifier le socket traditionnel où écoute chaque service. Que peut-on faire dans une telle situation ? Amap, l'outil de nouvelle génération de tests de pénétration vous vient en aide. Son fonction-nement consiste à envoyer les paquets spéciaux au port donné et à comparer les réponses qu'il reçoit à une liste spéciale. Grâce à cette technique, on vérifie les applications vraiment lancées sur le serveur et non les ports ouverts.

Il est possible de télécharger le programme depuis le site officiel. Ensuite, décompressez-le dans n'im-porte quel répertoire. Pour installer l'application, l'étape suivante consiste à donner trois commandes standards dans la console : ./configure && make && make install. N'oubliez pas que vous avez besoin de droits de root pour effectuer la dernière d'entre elles.

Il est temps de tester l'application en pratique. Imaginez que sur l'ordinateur à scanner fonctionnent le démon sshd sur le port 80 et le démon httpd sur le port 23. Si vous utilisez le programme Nmap, vous apprendrez que les ports sont ouverts et les services : http (80) et telnet (23) y fonctionnent. La réalité est toute autre.

Les valeurs de paquets spéciaux, envoyées par Amap, sont enregistrées dans le fichier appdefs.trig ; il se trouve dans le répertoire /usr/local/etc/ et il est fourni avec la distribution standard du programme. On compare les réponses reçues par Amap aux réponses enregistrées dans le fichier appdefs.resp, disponible par défaut dans le même répertoire. Il est également possible d'utiliser votre propre fichier avec les valeurs de paquets pour scanner le programme. N'oubliez pas toutefois de le préparer au préalable. Pour l'employez, optez pour le paramètre -D. Si vous voulez obtenir davantage d'informations, utilisez l'option -b. Une fois que le port, où par exemple sshd a été lancé, est véri-fié, cette option vous permettra d'obtenir l'information suivante : SSH-1.99-OpenSSH _ 3.9p1\n. D'après elle, la version du protocole SSH porte le numéro 1.99 et celle de OpenSSH - 3.9p1.

Vous pouvez enregistrer les résultats de l'analyse dans le fichier pour les analyser ultérieurement. Pour ce faire, lancez Amap avec l'option -o nomdufichier. Il est également possible de vérifier les services fonctionnant sur les ports appartenant au protocole UDP.Défauts : Amap n'identifie pas encore les réponses de services rarement rencontrés. Si vous rencontrez un résultat, inconnu à l'application, vous pouvez envoy-er un message à l'adresse de messagerie électroni-que de concepteurs. Ils pourront ainsi résoudre des problèmes existants.

Konrad Kierys

Système d'exploitation : *NIX, WindowsLicence : GPLObjectif : Identification de services fonctionnant sur les ports donnésPage d'accueil : http://thc.org/thc-amap/

Amap est un outil, qui, contrairement aux autres scanneurs, identifie les démons de l'ordinateur donné d'après les réponses sur les paquets envoyés et non d'après les numéros de ports où ils sont lancés.

Amap

Figure 1. Résultats de l'analyse par Amap Figure 2. Résultats de l'analyse par Nmap

www.hakin9.orghakin9 Nº 4/200614

Interview

Interview

H9 : Vous travaillez comme scientifique dans le Centre Régional de Calculs (RZZ) à l'université de Cologne ; vous avez publié aussi l'ouvrage Cryptographie pratique sous Linux. Est-ce que, selon vous, la conscience seule des choses suffit pour que les utilisateurs dans RRZ puissent se sentir sûrs ?

LP : Oui, on peut dire que la plupart des utilisateurs dans mon milieu se redent compte des problèmes généraux, surtout les problè-mes dans la communication via emails. Mais après plusieurs conversation j'ai constaté que même si plusieurs d'entre eux veulent utiliser le chiffrage, mais à vrai dire, ils ne savent pas par quoi commencer. Certains utilisateurs avouent qu'ils sont trop paresseux pour appliquer la clé GPG à laquelle ils ont accès. Quant aux autres, ils voudraient déchiffrer, mais ils ont du mal à en convaincre les autres. S'il s'agit de SSH dans mon milieu, les choses se présentent tout à fait autrement. Par exemple les utilisateurs d'ordina-teurs très performants ne peuvent disposer de SSH que s'ils s'enregistrent sur ces ordinateurs.

H9 : Selon vous, pourquoi la clé GPG est si peu utilisée dans la pratique ?

LP : En général, parce que les gens ne savent pas par quoi commencer. Si quelqu'un

a eu le courage de faire le premier pas et a généré une paire de clés ou un certificat, il se heurte à un autre obstacle – comment les utili-ser dans la pratique.

H9 : Est-il possible d'estimer approximati-vement quel pourcentage d'utilisateurs protè-gent leurs emails ou au moins se conforment aux principales règles de sécurité ?

LP : Les analyses d'Ostermann Research (http://www.ostermanresearch.com) de 2004indiquent que 20% des employés des gran-des entreprises sont des utilisateurs qui chiffrent souvent leurs emails, en admettant que l'employeur assure les solutions permet-tant le chiffrage. Je ne sais pas exactement comment cela se répartit entre OpenPGP, S/MIME et autres techniques. Dans les milieux universitaires, j'estime que ce pourcentage est plus élevé.

H9 : D'après vous, combien d'utilisateurs dans votre milieu sont sensibles à ces ques-tions ?

LP: Les utilisateurs d'ordinateurs très performants dans les universités ont souvent seulement un accès chiffré aux périphéri-ques, alors ils travaillent avec le matériel standard, mais doté d'une forte cryptogra-

On ne peut être jamais totalement sûrInterview avec dr Lars Packschies

Avec notre invité, docteur Lars Packschies, scientifique et administrateur des programmes et de la protection des données dans l'environnement Linux , SunOS/Solaris, IRX et AIX du Centre Régional des Calculs (Regionales Rechenzentrum, RRZ) à l'Université de Cologne, nous parlons sur l'utilisation de la cryptographie. Dr Packschies est auteur de l'ouvrage Cryptographie pratique sous Linux.

Interview avec dr Lars Packschies

hakin9 Nº 4/2006www.hakin9.org 15

phie. Ce qui est intéressant, la plupart d'eux ne se rendent pas compte qu'ils procèdent ainsi, pour l'uti-lisateur ordinaire cette technique est cachée. SSH est un exemple d'une technique de chiffrage qui a été implémentée dans l'environnement IT d'une façon complètement incohérente, et n'a pas été encore perçu ou considérée comme nuisible. On peut dire que c'est une situation idéale.

Ce qui paraît moins compliquée, c'est l'application de VPN qui est introduit par l'utilisateur à partir de la maison dans le réseau universitaire grâce à un tunnel crypto-graphique déprotégé. Ce tunnel doit être tout d'abord construit à l'aide des programmes clients spéciaux pour que les services universitaires particuliers puissent être envoyés à la maison. Et à ce moment, beaucoup d'uti-lisateurs se heurtent aux petits problèmes qui – pour eux – sont un obstacle sérieux. Nous montrons à nos clients la nécessité d'appliquer les moyens appropriés et ainsi la conscience dans ce domaine augmente. Et alors, l'accès aux emails sur notre serveur chiffré uniquement au moyen de SSL ou TLS n'est pas un problème. Cela concerne chaque utilisateur et tout le monde doit devenir de plus en plus conscient.

H9 : Et quoi concrètement, vous et votre centre, que faites vous pour sensibiliser les utilisateurs à cette ques-tion ?

LP: Nous offrons les formations spécialisées concer-nant ce sujet et qui sont destinés surtout aux débutants. Les formations avancées concernant Linux en général et l'email ou l'utilisateur de serveur abordent souvent ce sujet. Des informations claires sont très importantes pour les clients qui ne veulent ou ne peuvent pas participer à ces types de formations.

Par exemple, dans notre bulletin d'information, nous publions régulièrement les articles ou les nouveautés sur le chiffrage des emails ou l'accès sûr au serveur. Toutes les publications sont disponibles sur Internet.

H9: Est-ce que la paresse est un prétexte que tu acceptes ? L'utilisateur a-t-il toujours du mal à mettre la cryptographie en pratique ?

LP : Tout d'abord, il faut dire que les méthodes cryp-tographiques dans le trafic du courrier électronique sont optionnelles. Bien sûr, ces méthodes sont fortement recommandées. Si quelqu'un ne les souhaite pas, c'est bien. La paresse est parfois le voile qui couvre le vrai souci, si nous avons négligé nos devoir. J'essaie de ren-dre conscients les utilisateurs quelle est leur situation, de décrire les problèmes auxquels ils se sont heurté et de proposer la solution à ces problèmes. Et ainsi je les guide pas à pas vers la solution – une simple implémentation de la signature et au chiffrage par un clic ou un appui sur une touche. Mais je me préoccupe du respect des principales règles, ce qui permet de créer un environnement clair et compréhensible. Dans ces conditions, la paresse n'est en aucun cas un argument.

H9 : S'il s'agit des programmes du courrier électroni-que, beaucoup a changé du point de vue de l'utilité ?

LP : Depuis plusieurs mois, le développement va vers la simplification de la gestion. De bons exemples sont les projets Thunderbird, éventuellement Mozilla Mail avec Enigmail Plug-in, ainsi que le projet Kmail, qui offrent une excellente intégration avec les technologie de chiffrage. Il existe plusieurs autres clients de messagerie qui sont dotés de fonctions Open PGP et S/MIME. Pour plusieurs espaces utilisateurs, certains projets offrent directement les paramètres pour la génération et l'utilisation de la clé de GnuPG, par exemple Gnu Privacy Tray sous Windows ou Kgpg sous KDE. Il s'agit ici des programmes très clairs et simple d'emploi, grâce auxquels le travail avec le chif-frage est intuitif et facile.

H9 : D'après vous, comment faut-il procéder dans le travail quotidien du point de vue de la sécurité ?

LP : Consacrer un peu de temps et être prêt à résoudre les problèmes. Les questions importantes pendant le chiffrage du courrier électronique sont : savoir utiliser les clés, créer les certificats de retour et la connaissance des points faibles dans la chaîne des moyens assurant la sécurité, c'est-à-dire les phrases des mots de passe pour les clés privés et elles-mêmes. On pense très rarement, et je le rappelle souvent aux utilisateurs, que les méthodes de cryptographies se basent sur les hypothèses et la théorie. On ne peut être jamais totalement sûr. Par exemple, si nous trouvons une méthode très rapide de décomposition de grands produits de nombres premiers, certaines méthodes deviendront moins sûres. Jusqu'au moment où les ordinateurs quantiques deviennent la réalité. On oublie souvent qu'à ce moment, il sera possible de déchiffrer non seulement les messages chiffrés, mais aussi tous ce qui ont été créés par le biais de cette méthode. Il faut en être conscient pour savoir comment procéder avec ces machines puissantes.

Pour apprendre les bases, il suffit de quelques heu-res. La gestion des plug-ins des programmes de messa-gerie, l'intégration de SSH, SFTP ou SCP dans plusieurs produits, sont assez faciles, comme par exemple dans Konqueror (gestionnaire de fichiers du projet KDE).dans les dernières années, plusieurs choses sont devenues plus simples et il ne faut pas craindre les problèmes liés à la gestion. Si on a bien compris les problèmes, il est plus facile de les résoudre. La cryptographie est en pra-tique moins compliquée que l'on ne croît. En quelques étapes, il est possible de mettre en oeuvre les moyens de sécurité appropriés, et de convaincre les amis.

Une chose est sûre : il est possible de nous pénétrer de plusieurs manières, alors les agences d'assurance, les institutions d'état et les agences de publicité seront fortement intéressées par nos données confidentielles. Et nous, par quelques étapes simples, nous pouvons rendre notre communication plus sûre.

H9 : Merci beaucoup de votre entretien.

Interview faite par Ulrich Wolf et Heike Jurzik

www.hakin9.orghakin9 Nº 4/200616

Dossier

La technique des puits a été déployée par les fournisseurs d'accès à Internet de manière générale afin de protéger leurs

clients finaux. Comme nous allons l'expliquer dans le présent article, cette technique, connue sous le nom de puits ou sinkhole en anglais, permet également d'obtenir des informations intéressantes sur les menaces auxquelles est confronté votre réseau. En implémentant des puits, vous ajoutez une protection supplémen-taire à votre réseau tout en pouvant glaner des informations sur les menaces et certaines erreurs évidentes de configuration présentes dans votre réseau.

Destiné principalement aux utilisateurs de réseaux savvy, le présent article présentera les éléments suivants :

• Contexte et fonction des puits : brève ex-plication des puits IP et de leur installation réussie par un certain nombre d'organisa-tions.

• Déploiement de réseaux leurres : applica-tion des techniques de puits au moyen de réseaux invisibles et de réseaux de pots de miel, afin de piéger et d'analyser des scans malveillants, des tentatives d'infil-

tration, ainsi que d'autres évènements liés à la surveillance de votre réseau comme la détection d'intrusions.

• Protection contre les attaque de type DoS : comment certaines organisations et leurs fournisseurs d'accès à Internet ont déve-loppé un moyen de protection contre le déni de service au moyen de déploiements extensifs et basés sur les évènements.

• Rétrodiffusion et pisteurs : brève explica-tion de la rétrodiffusion et de l'utilisation du pistage afin d'identifier le point d'entrée des attaques DoS dans un réseau important.

Protection réseaux grâce aux puits stationnaires et aux puits IP basés sur les évènementsVictor Oppleman

Degré de difficulté

Rien n'est plus efficace que la présentation, même succincte, des techniques de protection des réseaux afin de mieux se défendre contre les attaques de déni de service ou attaques DoS. Nous vous présentons la technique connue sous le no sinkhole permettant d’obtenir les informations intéressantes sur les menaces auxquelles est confronté votre réseau.

Cet article explique...• Comment utiliser les techniques de puits (sin-

khole en anglais) afin de se protéger contre les attaques de type DoS.

Ce qu'il faut savoir...• Maîtriser le fonctionnement des attaques DoS.• Connaître les problèmes liés au trafic des

réseaux du côté des Fournisseurs d'Accès à Internet (abrégés ci-après en FAI).

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 17

Contexte et fonctionTout au long de cet article, le terme puits désignera un moyen géné-ralisé de rediriger un trafic réseau IP spécifique dans différents buts sécuritaires dont l'analyse et l'ex-pertise, la diversion des attaques, et la détection d'activités anormales. Les FAI tier-1 ont été les premiers à installer ce type de tactiques, afin de protéger leurs clients finaux contre les attaques. Depuis, les tech-niques ont été adaptées afin de col-lecter des informations intéressantes sur les menaces à des fins d'analyse sécuritaire. Afin de vous faire une idée de la forme la plus simple que peut revêtir un puits, nous prendrons l'exemple suivant.

Un trafic malveillant et dérangeant issu de divers réseaux est destiné au réseau 192.0.2.13, comme l'illustre la Figure 1. L'organisation ciblée par ce trafic utilise 192.0.2.0/24 en tant que bloc d'adresse de son réseau, lequel est acheminé par son FAI en amont. Cette attaque devient rapidement dangereuse en interrompant les ac-tivités de l'organisation ciblée et en augmentant considérablement ses coûts en raison d'une utilisation de la bande passante plus importante que de coutume. Le FAI est ainsi contraint au vu du trafic surchargé généré par l'attaque susceptible de déranger des clients adjacents sous forme de dommage collatéral.

Le FAI réagit en initiant tempo-rairement un puits de type trou noir. Il injecte pour ce faire un chemin de

cible plus spécifique (192.0.2.13/32) dans son ossature, dont l'attribut next-hop est une interface de sup-pression sur le routeur périphérique (également connu sous le nom de null0 ou bit bucket), comme l'illustre la Figure 2.

Cette tactique permet de re-diriger le trafic malveillant vers le puits du FAI sans lui permettre d'at-teindre sa cible originale. Ainsi, le temps que le puits entre en action, les clients adjacents du FAI ne se-ront probablement pas touchés par des dommages collatéraux (dans la mesure où le FAI aura prévu de concevoir ses propres puits de dé-fense), la cible visée par l'attaque aura retrouvé sa connexion Inter-net et son accès local au dispositif spécifiquement ciblé. Malheureuse-ment, une adresse (ou un dispositif)

IP plus spécifique attaquée ne peut entrer en relation avec aucun systè-me à distance sous Internet à moins de supprimer le puits (à priori une fois l'attaque éloignée). De toutes évidences, il est possible d'envoyer les services fournis originellement par le dispositif cible vers un autre dispositif sous une adresse IP diffé-rente, mais de nombreuses autres considérations doivent également être prises en compte en termes de délai d'expiration DNS TTL, et ainsi de suite.

Cet exemple décrit simplement un type de puits possible, généra-lement décrit comme un chemin menant vers un trou noir généré par le FAI. Vous voilà donc familiarisé avec le concept. Nous pouvons donc vous présenter divers autres usages des puits.

Utiliser les puits pour déployer des réseaux leurresUne utilisation bien plus innovante des puits consiste à déployer diver-ses sortes de réseaux leurres dans le but de piéger, d'exposer ou de rassembler des informations sur les attaques.

Leurre ou Decoy en anglais \De*coy"\, n. : tout dispositif destiné à conduire dans des rets ; leurre cen-sé tromper et induire en erreur sur le véritable danger, ou la puissance de l'ennemi ; appât.

Figure 1. Attaque sur l'adresse IP 192.0.2.13 (avant installation du puits)

Figure 2. Attaque de l'adresse IP 192.0.2.13 (avec mécanisme de protection du puits)

hakin9 Nº 4/2006 www.hakin9.org

Dossier

18

Nous allons présenter plus en détails deux types de réseaux leur-res : le réseau invisible et le réseau de pots de miel. Ces deux types de réseaux peuvent être utilisés pour glaner des informations sensibles, mais l'un d'entre eux est plus particu-lièrement utile dans le domaine des réseaux sécurisés.

Déployer des réseaux invisiblesEn règle générale, un réseau invisible désigne une partie d'es-pace IP acheminée et allouée, complètement dépourvue de ser-vice sensible. De tels réseaux sont

considérés comme “invisibles” en raison de l'apparente obscurité qui y règne. Toutefois, un réseau invisi-ble comprend en réalité un serveur, agissant comme un aspirateur de paquets. Ce serveur se charge de rassembler et d'organiser les paquets entrant dans le réseau invisible, et se révèle ainsi très utile pour des analyses en temps réel ou des expertises de réseaux post-évènements.

Il faut en effet savoir que l'intru-sion de paquets dans un réseau in-visible est a priori inattendue, dans la mesure où aucun paquet légitime ne doit apparaître dans un réseau

invisible. Donc, les paquets qui s'y retrouvent sont arrivés soit par er-reur de configuration, soit, et c'est le plus fréquent, par un scénario en-voyé par malveillance. Ce program-me malveillant, à la recherche de dispositifs vulnérables, va envoyer des paquets dans le réseau invisi-ble, et s'exposer ainsi au contrôle de sécurité administrative. Assez géniale, cette approche permet de détecter des vers ainsi que d'autres programmes malveillants. Excep-tion faite des fausses alertes, des signatures et des dispositifs d'ana-lyses statistiques complexes, tout administrateur de la sécurité ayant correctement déployé des réseaux invisibles pourra détecter des scans malveillants (tentatives lancée par un programme malveillant dans le but de découvrir des hôtes adja-cents candidats à la propagation) quelle que soit la taille du réseau. Il s'agit là d'un outil de sécurité réel-lement puissant. Par ailleurs, les paquets introduits dans le réseau invisible révèlent également des erreurs anodines de configuration dans le réseau dont les adminis-trateurs réseau apprécieront de se débarrasser. Bien évidemment, les réseaux invisibles multiplient les usages dans le domaine de la sécurité. Ils peuvent ainsi être uti-lisés pour héberger des collecteurs de flux de données, des détecteurs de rétrodiffusion, des renifleurs de paquets, et des systèmes de dé-tection d'intrusion. L'avantage du réseau invisible est qu'il permet de réduire considérablement le nom-bre de fausses alertes au moyen d'une simple diminution du trafic et ce, quel que soit le dispositif ou la technologie utilisée.

L'installation d'un réseau invisible est relativement simple. Il suffit en réalité de suivre cinq étapes fonda-mentales.

Commencez par sélectionner une ou plusieurs régions inutilisées dans l'espace de votre adresse IP à partir de votre réseau que vous acheminerez ensuite vers le réseau invisible. Il peut s'agir d'un préfixe /16 ou plus d'adresses, ou tous

Listing 1. Extrait de la configuration du protocole BGP

router bgp XXX

redistribute static route-map static-to-bgp

# La carte des chemins est un mécanisme stratégique

# permettant de modifier les attributs des préfixes, ou certaines

# politiques particulières de filtrage

route-map static-to-bgp permit 10

match tag 199

set ip next-hop 192.0.2.1

set local-preference 50

set community no-export

set origin igp

Listing 2. Configuration de base du côté des fournisseurs d'accès à Internet

router bgp XXX

# La carte des chemins est un mécanisme stratégique permettant de

# manipuler des informations sur le routage telles que

# le paramétrage de l'attribut next-hop

neighbor < customer-ip > route-map customer-in in

# La liste des préfixes est une liste statique de préfixes clients et de

longueur de masques autorisés.

# Les clients doivent pouvoir indiquer à un seul hôte leur(s) préfixe(s)

comme

# 172.16.0.1/32, par exemple.

neighbor < customer-ip > prefix-list 10 in

# ebgp-multihop est nécessaire car il permet d'éviter

# l'annonce continuelle de préfixes ainsi que leur

# retrait.

neighbor < customer-ip > ebgp-multihop 2

# Nous définissons désormais la carte des chemins pour la correspondance

entre politiques

# et paramétrons l'attribut next-hop des trous noirs.

route-map in-customer permit 5

# Le client règle cette communauté de son côté,

# et le FAI la fait corréler de son côté.

# XXXX représentera un client ASN,

# et NNNN un nombre arbitraire approuvé par

# le FAI et le client.

match ip community XXXX:NNNN

set ip next-hop < blackhole-ip>

set community additive no-export

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 19

hakin9 Nº 4/2006 www.hakin9.org

Dossier

20

les chemins menant à une seule adresse (/32). Plus vous sélection-nez d'adresses, plus la détection d'activités réseau non sollicitées sera pertinente d'un point de vue statistique. Il est recommandé de choisir plusieurs segments d'adres-ses, comme un /29 de chacun des réseaux internes à votre disposi-tion, et un /25 de votre allocation de réseau public (externe), par exem-ple. Rien ne vous empêche non plus de rendre invisible une région de votre espace interne d'adresses privées (comme par exemple, l'es-pace RFC 1918, 10.0.0.0/8, etc.). En sélectionnant des régions de votre réseau interne pour les ren-dre invisibles, vous serez capable de détecter des scans internes qui vous auraient échappé si seuls des segments de votre réseau externe (public) avaient été acheminés vers votre réseau invisible. Les organi-sations utilisant des routages parti-culiers pour leurs réseaux internes peuvent envisager une autre straté-gie fondée sur la règle du chemin le plus spécifique (généralement distribué selon certains protocoles de passerelles intérieures). Ainsi, si vous utilisez les réseaux 10.1.1.0/24 et 10.2.1.0/24 de manière interne, vous pouvez tout simplement ache-miner le réseau 10.0.0.0/8 entier vers votre réseau invisible. Si votre réseau est correctement configuré, votre réseau invisible recevra tout

le trafic de 10.0.0.0/8 exception faite des réseaux que vous utilisez/acheminez de manière spécifique (ces derniers sont probablement dotés d'entrées de routage stati-ques dans votre infrastructure de réseau).

Il faut ensuite configurer la to-pologie physique de votre réseau invisible. Pour ce faire, il vous fau-dra un routeur ou un commutateur (couche 3) chargé de transférer le trafic vers votre réseau invisible, un serveur à grande capacité de stoc-kage pour collecter vos données, et un commutateur Ethernet afin de connecter ces composants ainsi que des composants facultatifs ultérieurement comme un capteur IDS (système de détection d'intru-sion) ou un analyseur de protocole. Il est recommandé de choisir pour le routeur un dispositif de passe-relle existant interne ou externe (ou les deux à la fois, bien que cette solution reste à éviter). La plupart des réseaux invisibles “entreprise” (par opposition à ceux relevant du domaine des télécommunications) sont situés dans une des zones tampon ou DMZ de l'organisation et séparés du reste du réseau. C'est la raison pour laquelle vous devez uti-liser un pare feu pour réaliser cette tâche à la place de l'un de vos rou-teurs. Il est, toutefois, recommandé d'utiliser un routeur de passerelle externe pour vos réseaux invisibles

externes, et un commutateur interne de couche 3 pour vos réseaux invi-sibles internes. Quel que soit votre choix, l'essentiel est de configurer ce dispositif de routage de manière à ce qu'il transfère le trafic destiné au réseau invisible reçu en dehors d'une interface Ethernet de réseau invisible (grâce au commutateur) vers le serveur collecteur configuré pour accepter de tels paquets. Le serveur collecteur doit également être doté d'une interface spécifique de réseau invisible chargée de re-cevoir ces paquets. Au niveau de sa gestion, le serveur collecteur nécessitera également au moins une interface Ethernet supplé-mentaire (à placer sur un LAN de gestion indépendant). Veillez à bien respecter les consignes de sécurité édictées pour tous les dispositifs de votre réseau, car vous pouvez être sûr que toutes sortes de program-mes malveillants s'engouffreront très rapidement dans ce segment de réseau. Vous pouvez utilisez un commutateur de zone DMZ existant afin de connecter ces composants, à moins que la configuration du VLAN ne vous effraie nullement. Ainsi, aucun paquet largement diffusé n'entrera dans le réseau in-visible. N'oubliez pas qu'un réseau invisible est conçu pour piéger le trafic illégitime sans prendre le ris-que de voir les paquets légitimes de vos autres LAN empiéter sur la zo-ne de votre réseau invisible. Nous avons exposé dans la Figure 3un exemple de cette configuration. Dans les exemples suivants, nous utiliserons un routeur ou un commu-tateur chargés de faire fonctionner Cisco IOS avec une licence logiciel-le de couche 3, un serveur basé sur FreeBSD, et un commutateur d'ob-jets non gérés de couche 2 chargé de connecter les dispositifs.

Afin que votre serveur collecteur évite d'avoir recours au protocole ARP (Address Resolution Protocol) sur chaque adresse de votre espa-ce de réseau invisible, il vous faut configurer le routeur de manière à transférer le trafic destiné au réseau invisible vers une seule adresse IP

Figure 3. Topologie physique de référence pour les réseaux invisibles

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 21

finale sur l'interface Ethernet du réseau invisible de votre serveur. Pour ce faire, il est recommandé de consacrer un réseau /30 à ce transfert point par point entre le routeur et l'interface du réseau invisible, comme 192.0.2.0/30, par exemple. Ainsi, l'interface Ethernet de votre routeur prendra l'adresse 192.0.2.1/30 et le serveur collecteur pourra être atteint via 192.0.2.2/30. La configuration de l'interface dé-pend dans une large mesure des plate-formes sélectionnées. Nous supposerons donc que vous maî-trisez parfaitement ce sujet. Nous utiliserons dans les exemples Cisco IOS avec une licence logicielle de couche 3. Une fois cette tâche réa-lisée, il vous suffit d'entrer les dé-claration de routage correctes dans le commutateur afin de transférer l'ensemble du trafic de votre réseau invisible vers 192.0.2.2 dans le ser-veur collecteur, et de libérer votre espace personnel, de la manière suivante :

router#conf t

router(config)# ip route 10.0.0.0 §255.0.0.0 192.0.2.2

router(config)# ^Z

router# wr

Vous devriez ainsi recevoir le trafic du réseau invisible. Nous avons ex-posé dans la Figure 4 une topologie logique de référence.

Que faire de ce trafic une fois obtenu. Le serveur doit être confi-guré de manière à ne pas répondre à toutes les données qu'il reçoit sur son interface de réseau invisible. Bien évidemment, le serveur uti-lisera le protocole ARP pour son adresse configurée (192.0.2.2/30 uniquement) afin d'établir les communications nécessaires vers le routeur. En revanche, tous les autres paquets doivent être suppri-més au moyen de pares feu basés sur l'hôte. Comme nous l'avons mentionné plus haut, aucune sorte de gestion ne doit apparaître sur l'interface du réseau invisible. Vous devez configurer une autre inter-face Ethernet sur laquelle seront réalisées les tâches de gestion et d'administration. Le chemin par défaut menant vers le système doit être la passerelle vers l'interface de gestion. Le choix du pare feu nécessaire dépendra de la plate-forme que vous aurez sélectionnée pour votre serveur. Il est, toutefois, recommandé d'utiliser un système basé sur BSD et pf ou ipfw2 en tant que pare feu. Qu'il soit activé ou pas le journal du pare feu dépendra largement de l'utilisation que vous en ferez. Dans nos exemples, nous utilisons des outils d'analyse de fi-chier journal nécessitant d'être acti-vés (de manière à pouvoir analyser les journaux et générer des alertes si nécessaire). Toutefois, selon les

différents choix de matériel et de logiciel ainsi que la taille de votre réseau invisible, l'activation du jour-nal peut diminuer considérablement la performance de votre réseau invisible. Afin de compléter vos mesures de sécurité (les pares feu ne sont pas à l'abri de panne ou de déconnexion accidentelle), il peut s'avérer judicieux de transférer le trafic de votre réseau invisible vers une destination vide dans le cas où ce trafic passerait accidentellement sans avoir été préalablement filtré. Un tel exemple sous FreeBSD res-semblerait à ceci :

route add –net 10.0.0.0/8 §127.0.0.1 –blackhole

Votre réseau invisible est désormais fonctionnel et votre serveur collecteur protégé. Il vous reste à stocker les données dans un format lisible par vos outils d'analyse et d'expertise. Des fichiers formatés en pcap sem-blent assez évidents en raison de leur quasi universalité sur la plupart des applications d'analyse réseau pouvant travailler dessus. La méthode la plus simple et la plus répandue consiste à utiliser la fonctionnalité intégrée de pivotement du programme tcpdump proposé par le Groupe de Recher-ches en Réseaux du Laboratoire National Lawrence Berkeley. Afin de lancer la fonctionnalité de pivotement de journal en ligne de commande tcpdump, vous pouvez par exemple taper la déclaration suivante :

tcpdump -i en0 -n -w darknet_dump –C125

Dans cet exemple, nous ordonnons au programme tcpdump d'écouter l'interface en0. La résolution nom à nombre (DNS) est désactivée, et un fichier intitulé darknet_dumpN est rédigé tous les 125 millions d'octets, où chaque augmentation de N rend le nom des fichiers uniques. Là en-core, cette commande produira un fichier binaire formaté en pcap con-tenant le trafic du réseau invisible. Vous pouvez ensuite entrer ledit fi-chier dans votre logiciel d'analyse de réseau préféré, avec pour objectif de

Figure 4. Topologie logique de référence pour les réseaux invisibles

hakin9 Nº 4/2006 www.hakin9.org

Dossier

22

conserver une copie des données et d'utiliser un grand nombre d'outils dif-férents chargés de relire les fichiers ultérieurement à la recherche de caractéristiques pertinentes du trafic analysé. La règle générale veut que vous utilisiez un programme de type tcpdump combiné à une expression spécifique BPF (Berkeley Packet Fil-ter, ou filtre de paquets de Berkeley) afin de détecter des éléments dans ces fichiers. Comme cette tâche peut être lancée au moment de l'exécution (ou de la capture), en conservant un enregistrement de l'ensemble du trafic, vous pouvez utiliser différents outils ultérieurement sans prendre le risque de perdre des informations de grande importance.

Argus (Audit Record Generation and Utilization System) pour les réseaux développé par Qosient est un autre outil très utile capable de simplifier la visualisation des flux de données relatives au trafic. Bien que nous puissions exposé ici en détail la configuration complexe de cet outil, nous utilisons Argus régulièrement afin de détecter des flux de données intéressants dans nos réseaux invisi-bles. Argus propose une interface de résumé des flux de données agréa-ble censée vous aider à comprendre exactement ce qui se passe en ter-mes de trafics malveillants.

Afin de pouvoir visualiser le volu-me de trafic entrant dans votre réseau invisible, des outils de compteur d'in-terface comme MRTG (veuillez con-sulter le site http://www.mrtg.org/) de Tobias Oetiker devraient vous aider. MRTG vous permet de produire des graphiques lisibles du trafic de votre réseau invisible relativement illisible. Il existe également une douzaine d'autres outils capables d'analyser les journaux des pares feu, pouvant remplacer rapidement et facilement les outils d'analyse plus complexes basés sur le format pcap ou Argus. Il ne faut pas ignorer les problèmes que soulèvent les journaux du filtre des paquets au format texte et l'analyse supplémentaire que de tels fichiers exigent.

Vous pouvez utiliser au bas mot des douzaines d'outils sur votre

réseau invisible. Pour commencer, vous trouverez ci-après une liste de certains de nos outils :

• Capteur IDS (Bro, Snort, et al.).• Renifleur de paquet (tcpdump tel

que décrit plus haut).• Programme d'analyse des flux

de données (Argus, exportations des flux du réseau à partir du routeur, SiLK, outils de flux de données).

• Analyseur des fichiers journal de pare feu venant alimenter les bases de données RRD pour les graphiques.

• MRTG afin de représenter les compteurs de trafic sous forme de graphiques.

• p0f (par Michal Zalewski) afin de classer les plate-formes de dispositifs infectés ou servant à réaliser des scans malveillants.

Déployer des réseaux de pots de mielÀ l'instar d'un réseau invisible, un réseau de pots de miel désigne en général une partie d'espace IP acheminée et allouée. Toutefois, au lieu de fournir une destination vers laquelle les paquets vont s'échouer, ici la destination imite un service réel (ou plusieurs services), afin de permettre la connexion (poignée de mains), et d'établir un dialogue à deux sens. Un pot de miel ou honeypot en anglais, soit le système chargé d'imi-ter un service réel, désigne en réalité une ressource étroitement et réguliè-rement contrôlée destinée à tromper les programmes malveillants afin de les infiltrer et de les examiner. Quoi-que de différents types, l'objectif des pots de miel reste toujours le même : apprendre les tactiques et recueillir autant d'informations que possible sur le programme malveillant.

Pots de miel physiquesSont désignées par pots de miel phy-siques d'importantes machines resi-dant dans le réseau de pots de miel et dotées de leur propre adresse IP, de leur propre système d'exploitation et de leurs propres outils d'imitation de services.

Pots de miel virtuelsSont désignés par pots de miel vir-tuels des systèmes complets de pots de miel “sur le modèle logiciel” char-gés de reproduire des conditions en-vironnementales comme le système d'exploitation, la pile du réseau et les services fournis sous forme de leurres. Un serveur physique peut proposer un réseau de milliers de pots de miel virtuels.

Pots de miel à basse interactionLes pots de miels dits à basse inte-raction (type le plus répandu de pots de miel aujourd'hui) ont été conçus afin de tromper les programmes mal-veillants au moyen d'une ou plusieurs vulnérabilités supposées exploita-bles, d'établir avec ces programmes un dialogue, et de capturer les tout premiers paquets de communication avec le programme malveillant. De toutes évidences, le programme malveillant ou le logiciel malicieux autonome en conversation avec le pot de miel se rendra compte que sa cible ne peut être exploitée, mais avant de s'en apercevoir réellement, des informations de grande impor-tance peuvent déjà être exposées, comme la tactique d'exploitation ou la signature du logiciel malveillant. De tels pots de miel à basse inte-raction sont de nos jours utilisés afin de modéliser les tactiques d'attaque des polluposteurs (qui tentent de dériver les heuristiques comme les caractéristiques temporelles des transactions SMTP des pollupos-teurs, par exemple).

Il n'existe que très peu d'ins-tallations commerciales de cette technologie liée aux pots de miel, mais la plupart des implémentations les plus utilisées sont disponibles via un projet libre intitulé honeyd, dirigé par Niels Provos. Vous trou-verez plus d'amples informations sur l'obtention et la configuration d'ho-neyd à l'adresse suivante : http://www.honeyd.org.

Astuce : honeyd a été conçu sous forme de pot de miel/ réseau de pots de miel virtuel capable de simuler un certain nombre de

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 23

hakin9 Nº 4/2006 www.hakin9.org

Dossier

24

systèmes d'exploitation différents ainsi que des composants logiciels permettant d'attirer les programmes malveillants.

Il faut également noter une nou-velle forme de pots de miel à basse interaction fondée sur un nouveau concept élaboré par Tom Liston in-titulé LaBrea. LaBrea (ainsi désigné après la fonctionnalité tar pit) est un démon logiciel (service) capable de générer des réponses autono-mes à des requêtes de connexion au travers de blocs d'adresses IP éventuellement considérable. En bref, cet outil peut créer un envi-ronnement capable d'attirer des programmes malveillants de scan et/ou de propagation, mais présente toutefois un grave inconvénient. Dès que le programme malveillant tente de se connecter, LaBrea ralentit la pile réseau de l'émetteur, de manière parfois significative. Au sens figuré, la pile réseau du système infecté par le programme malveillant se retrouve coincée dans un tar pit. De ce fait, il n'y a plus d'interaction au niveau de la couche application, mais une interaction significative au niveau de la couche 4 lors des tentatives de connexion (TCP). LaBrea est même capable d'utiliser le protocole ARP sur l'ensemble des adresses IP virtuelles dans sa configuration sans les assigner aux interfaces du système hébergeur, ce qui facilite considérablement son réglage. Vous trouverez plus d'amples informations sur LaBrea à l'adresse suivante : http://labrea.sourceforge.net/labrea-info.html.

Remarque : plusieurs organis-mes de recherche sont parvenus à la conclusion que les pots de miel à basse interaction représentent une tactique viable contre la propagation extrêmement performante de vers en les ralentissant, ce qui permet de protéger les infrastructures du réseau. Certes, la configuration requise pour pouvoir tirer parti de cet avantage est au mieux obtuse. Toutefois, LaBrea et honeyd peuvent tout deux être configurés de sorte à créer un environnement hostile aux vers.

Pots de miel à haute interactionQuoique moins utilisés, les pots de miel à haute interaction se révèlent extrêmement utiles. Contrairement à la simple capture des toutes premières transactions dans un dialogue entre un programme mal-veillant et le pot de miel, le pot de miel dit à haute interaction autorise une attaque à infiltrer entièrement le système sur lequel il réside. Dans un tel cas de figure, les infor-mations utiles capturées compren-nent non seulement les techniques d'examen et le type d'exploitation utilisée, mais permettent également à l'administrateur de la sécurité de surveiller le programme malveillant une fois obtenu l'accès au système, exposant sans le vouloir ses inten-tions et ses outils.

Une organisation à but non lucra-tif connue sous le nom de Honeynet Project (veuillez consulter le site http://www.honeynet.org/) produit un grand nombre d'informations et d'outils faciles d'utilisation conçus pour permettre aux utilisateurs de déployer des pots de miel à haute interaction. Cette organisation pro-pose également des outils de type expertise chargés d'analyser les données collectées lors des infiltra-tions dans les pots de miel.

Astuce : le projet Honeynet (http://www.honeynet.org/ ) publie un certain nombre d'outils incroya-bles pouvant être utilisés pour déployer vos propres réseaux de pots de miel. Les outils intitulés Honeywall, Termlog, et Sebek sont plus particulièrement intéressants. Dans le même ordre d'idée, l'équi-pe du projet a également développé un excellent ouvrage sur la psycho-logie, les tactiques et les outils utilisés par les pirates, informations recueillies grâce à la technique des réseaux de pots de miel. Ce livre intitulé Know Your Enemy, déjà à sa seconde édition au moment de rédiger le présent article, est dispo-nible sur le site Web honeynet.org. L'argent récolté de sa vente sert à financer la recherche sur les ré-seaux de pots de miel.

Utilisation des réseaux de pots de miel Les pots de miel ne sont d'aucune utilité aux organismes de recher-che ou aux sociétés disposant de beaucoup d'argent et de temps à consacrer à la sécurité (en con-naissez-vous beaucoup ?). Il est toutefois déconseillé aux entreprises de tous les jours d'avoir recours aux pots de miel. En revanche, bien qu'inadéquat dans le cadre d'un usage quotidien, il est possible d'installer un réseau de pots de miel sur demande en cas d'apparition de programme malveillant que ni des outils d'expertise ni des renifleurs ne peuvent identifier ni aider votre admi-nistrateur à résoudre les problèmes. Ce réseau de pots de miel permet ainsi d'établir une communication en imitant le comportement de la cible visée par le programme mal-veillant, lequel exposera malgré lui un nombre d'informations suffisant à identifier correctement le type d'at-taque menée. Une autre utilisation sur demande consiste à contrôler des infiltrations suspectes. Le ré-seau de pots de miel constitue ainsi une autre arme à la disposition de l'administrateur de la sécurité.

Que dire enfin de cette instal-lation concrète chez l'un des plus grands fabricants de puces ? Ce fabriquant possède dans tout son réseau des serveurs Linux exécu-tant VMWare, sur lequel fonctionne quatre machines virtuelles, une pour chaque version les plus répandues du système d'exploitation Windows dans le monde des entreprises, NT, 2000, 2003, et XP. Chacune de ces machines est mise à jour grâce aux niveaux standards des programmes correcteurs de la société. Le systè-me d'exploitation Linux contrôle ces machines pour le trafic et les modifi-cations afin de détecter de nouveaux vers (ou autres menaces) suscepti-bles de circuler dans la réseau de la société. Ce fabriquant utilise essen-tiellement cet environnement sous forme de réseau de pots de miel combiné à un système de détection des intrusions de type vers. Vous trouverez plus d'amples informations

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 25

sur cette installation à l'adresse sui-vante : http://phoenixinfragard.net/meetings/past/200407hawrylkiw.pdf

Installer des puits pour se protéger contre les attaques DDoSRécemment la technique des puits connaît une nouvelle application sous forme de tactique de défense contre les attaques de déni de servi-ce (distribuées). Le premier exemple exposé dans la partie intitulée Con-texte et fonction illustrait la forme la plus simple que peut prendre cette nouvelle technique de réacheminer le trafic vers un trou noir. Une fois la cible exacte d'une attaque identifiée, l'adresse IP ciblée a été détournée vers l'interface de suppression si-tuée à la périphérie du réseau, avant de traverser le lien final vers la cible. Cette technique a permis d'éviter au réseau cible un arrêt total provoqué par la saturation du lien, sans toute-

fois protéger entièrement la perfor-mance de tout le réseau, notamment les clients adjacents partageant certaines parties de la topologie périphérique du transporteur sur le réseau cible. Aujourd'hui, les grands fournisseurs en télécommunications ont structuré leurs réseaux pour y inclure des versions sophistiquées de cette mesure de défense dans le cadre de leur politique de conception des réseaux. Dans de nombreux cas, ces fournisseurs sont désormais ca-pables d'utiliser une technique de pistage afin de localiser les points d'entrée de l'attaque et rediriger vers un trou noir les paquets de données malveillants (vers leurs propres points d'entrée), sans permettre au programme malveillant d'attaquer l'ossature du réseau jusqu'au lien du réseau ciblé. Cette technique de pistage demeure toutefois inutile bien souvent dans la mesure où les chemins conduisant aux trous noirs des fournisseurs sont habituellement

annoncés à l'échelle du réseau au moyen de leurs routeurs périphé-riques ayant recours au protocole BGP (Border Gateway Protocol). Le trafic malveillant est ainsi acheminé vers un trou noir à chaque point d'en-trée, lequel peut noyer les attaques dès leur arrivée et (dans la plupart des cas) éviter une congestion de l'ossature ainsi que des périphéries du réseau. Certains fournisseurs ont même étendu le contrôle et l'automa-tisation de cette technique au client final au moyen des dénommés trous noirs en temps réel amorcés par le client.

Declancher un routage vers un trou noirComme nous venons de le men-tionner plus haut, d'importants fournisseurs d'accès à Internet ont installé un système distribué et automatisé capable de declancher un routage vers des trous noirs sur des adresses IP ciblées. Ce déclanchement peut être provoqué par le fournisseur d'accès à Internet ou par les clients eux-mêmes, soit de manière manuelle soit automa-tiquement. Le routage provoqué vers un trou noir utilise la technique du simple puit évoquée plus haut dans la partie intitulée Contexte et fonction. Le puit peut être confi-guré sur tous les routeurs d'entrée (périphériques) au sein du réseau du fournisseur d'accès à Internet dans lequel celui-ci échange du trafic avec d'autres fournisseurs ou clients. Une fois la nature de l'atta-que dirigée contre le réseau ciblé identifiée, le fournisseur d'accès à Internet ou le client peut indiquer le préfixe attacked (ou un préfixe plus spécifique) dans la table de routage BGP. Le préfixe attaqué est marqué d'un attribut next-hop acheminé de manière statistique vers l'interface de suppression sur tous les rou-teurs périphériques, puis propagé dans le réseau du fournisseur d'ac-cès à Internet via un protocole BGP interne (ou iBGP). Ainsi, quelle que soit l'entrée des paquets destinés au préfixe attaqué dans le réseau du FAI (point d'entrée), ces derniers

Tableau 1. Paquets ICMP (Internet Control Massage Protocol)

Paquets ICMP Signification

3.0 Réseau inatteignable

3.1 Hôte inatteignable

3.3 Port inatteignable

3.4 Fragmentation requise

3.5 Echec du chemin source3.6 Erreur inconnue sur le réseau de

destination3.7 Erreur inconnue sur l'hôte de desti-

nation3.10 Hôte administrativement interdit3.11 Type de service réseau inatteigna-

ble3.12 Type de service hôte inatteignable3.13 Communication administrativement

interdite11.0 Expiration TTL lors du transit11.1 Réassemblage des fragment trop

long

Paquets TCP (Transmission Control Protocol)

Signification

RST bit set Redémarrage du protocole TCP

hakin9 Nº 4/2006 www.hakin9.org

Dossier

26

sont immédiatement envoyés vers l'interface de suppression du rou-teur le plus proche en indiquant le préfixe attaqué.

Les fournisseurs d'accès à In-ternet doivent généralement suivre les étapes suivantes afin de pouvoir

installer un mécanisme de trou noir distribué :

• sélectionner un préfixe routé de manière non globale, comme le Test-Net (RFC 3330) 192.0.2.0/24, de sorte à servir d'attribut

next-hop permettant d'acheminer vers un trou noir n'importe quel préfixe d'attaque. L'utilisation d'un préfixe de longueur 24 per-met d'avoir recours à plusieurs adresses IP différentes pour des types spécifique de routages vers des trous noirs. Il est en effet plus judicieux de différencier les chemins de trous noirs clients, internes ou externes.

• configurer un chemin statique sur chaque routeur d'entrée/interrogateur pour le préfixe 192.0.2.0/24, lequel pointe vers l'interface de suppression. Par exemple : ip route 192.0.2.0

255.255.255.0 Null0

• configurer le protocole BGP et la politique de cartes des chemins afin de mentionner les préfixes à diriger vers un trou noir, comme l'illustre le Listing 1.

Dans cet exemple de configuration, des chemins statiques sont redistri-bués dans le protocole BGP corres-pondant à la balise “tag 199” (voir ci-dessous), en paramétrant l'attribut next-hop sur une adresse IP achemi-née vers l'interface de suppression, et la préférence locale sur 50 (valeur la moins préférée). Il faut enfin veiller à ne pas laisser fuir ces chemins vers un de vos pairs externes (pas d'exportation).

Une fois cette configuration élé-mentaire réglée, le déclencheur peut être initié par le fournisseur d'accès à Internet. Il lui suffit d'entrer un chemin statique chargé de diriger le préfixe d'attaque (ou l'hôte) vers un trou noir, de la manière suivante, par exemple :

ip route 172.16.0.1 255.255.255.255

192.0.2.1 Null0 tag 199

Le chemin statique mentionné ci-dessus agit comme déclencheur chargé de lancer le processus de routage vers les trous noirs. Le rou-teur sur lequel est configuré ce che-min indiquera le chemin au moyen d'iBGP à l'ensemble des routeurs internes, y compris les routeurs pé-riphériques. Ainsi, tout routeur doté

Tableau 2. Récapitulatif des étapes clés

Étape DescriptionComprendre comment votre FAI peut vous aider en cas d'attaque DDoS.

Élaborer un plan d'actions à mener contre les attaques DDoS com-prenant des stratégies capable d'augmenter les capacités de votre FAI dans le domaine des trous noirs en temps réel. Amorcer le dialogue entre votre organisation et votre FAI afin de pouvoir créer des trous noirs en temps réel déclanchés par les clients dans le but de vous protéger sans perdre trop de temps dans leurs procédures d'intensification.

Envisager l'installation d'un réseau invisible interne.

Un réseau invisible vous permet d'attraper des vers avant l'anti-virus de votre fournisseur. De la même manière, ce type de réseau révèle des erreurs de configuration sur vo-tre réseau que vous serez heureux de connaître.

Envisager l'installation d'un réseau invisible externe.

Les réseaux invisibles externes peuvent vous permettre de connaî-tre la nature du programme dirigé contre votre réseau d'un point de vue extérieur et les outils pouvant être utilisés avec ce type de réseaux vous seront certainement plus lisibles que des journaux standards de pare feu. Les messages rétro-diffusés collectés à partir de votre réseau invisible externe peut vous fournir des informations précieuses sur le moment où votre réseau est impliqué dans une attaque sur une tierce partie.

Explorer le réseau au moyen de pots de miel si vous avez le temps et les ressources nécessaires.

Bien que la plupart des organisa-tions n'y voient que peu d'intérêt, l'installation d'un réseau de pots de miel peut se révéler fort utile pour les chercheurs en sécurité de l'information. Il peut être judicieux d'envisager cette solution au sein de votre organisation, sans oublier de tenir compte de la législation en vi-gueur sur l'exploration des données pouvant avoir une incidence sur votre décision.

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 27

d'un chemin statique vers l'interface de suppression pour 172.16.0.1/32 acheminera immédiatement le trafic local vers un trou noir.

Le fournisseur peut également créer un déclencheur automatisé grâce au protocole BGP, de manière à permettre à un client BGP de de-clancher le chemin vers le trou noir indépendamment de l'intervention du FAI. Il s'agit en réalité de l'aspect le plus puissant du routage vers les trous noirs. Du côté du fournisseur d'accès à Internet, la configuration est légèrement différente dans la mesure où il va utiliser les commu-nautés et les attributs ebgp-multihop afin de recevoir et de baliser correc-tement les chemins communiqués par les clients. Nous avons exposé dans le Listing 2 la configuration de base du côté des fournisseurs d'ac-cès à Internet.

Le fournisseur d'accès à Inter-net a déjà acheminé de manière statique le < blackhole-ip > vers les interfaces de suppression dans tout le réseau. Donc, dès l'annonce du client d'un préfixe à diriger vers un trou noir, le FAI le redistribue de manière interne et le trafic vers ce préfixe est acheminé vers un trou noir à la périphérie du réseau du fournisseur d'accès.

Nous avons exposé dans le Lis-ting 3 la configuration de base du côté du client.

Une fois la configuration du pro-tocole BGP en place, il suffit au client d'installer un chemin statique pour le préfixe # visé par l'attaque. Grâce

à une configuration très simple dans BGP, et l'aide de votre FAI, vous dis-posez désormais d'une méthode très rapide vous permettant de répondre aux attaques de type DoS menées sur un seul hôte, ou sur un préfixe entier.

Remarque : n'oubliez pas de tout contrôler avec le contact tech-nique de votre FAI avant d'installer votre solution de déclanchement de trous noir dans la mesure où les implémentations des FAI de ce con-cept diffèrent légèrement de l'une à l'autre.

Rétrodiffusion et pisteursCette partie est consacrée aux usages créatifs des réseaux leurres dans le but de détecter des attaques

et des arnaques tout en pistant le pirate malveillant.

RétrodiffusionIl serait insensé, après avoir évoqué les réseaux leurres et les attaques de type DdoS, de ne pas évoquer la notion de rétrodiffusion. Durant tout un semestre de ma première année de lycée, j'ai écrit des lettres (oui, oui, de véritables lettres en papier) à divers amis qui devaient déména-ger. Étant de nature assez étourdie, j'indiquais régulièrement sur mes enveloppes une fausse adresse de retour. J'avais en effet omis d'ins-crire mon numéro de chambre (je venais de découvrir la bière à cette époque). Il arrivait parfois que l'un de mes amis à qui j'avais écrit ait déménagé. La lettre m'était donc renvoyée avec la mention de la pos-te retour à l'expéditeur. Seulement, en raison de l'adresse incorrecte que j'avais indiquée, la lettre ne m'était pas directement retournée mais était renvoyée au bureau de la résidence du rez-de-chaussée qui m'appelait et m'informait de l'arrivée des lettres (en voyant mon nom bien sûr). Il ne me restait plus qu'à récu-pérer la lettre renvoyée. Ce retour à l'expéditeur n'est ni plus ni moins qu'une sorte de rétrodiffusion. Bien évidemment, le facteur indiquait au bureau de la résidence que j'avais envoyé une lettre (et à qui).

Listing 3. Configuration de base du côté du client

router bgp XXXX (customer’s ASN)

# Le client va installer un chemin statique,

# redistribué dans le protocole BGP,

# lequel redistribue la carte des chemins statiques vers bgp,

# à l'instar des FAI. Le client utilise la carte des chemins pour paramétrer

et faire correspondre

# les attributs de préfixes spécifiques.

route-map static-to-bgp permit 5

# Fait correspondre la balise arbitraire,

# préalablement approuvée par le client et le FAI

match tag NNNN

set community additive XXX:NNNN

# NNNN représente la balise, approuvée par le client et le FAI

ip route 192.168.0.1 255.255.255.255 Null0 tag NNNN

Figure 5. Exemple d'une rétrodiffusion lors d'une attaque DdoS

hakin9 Nº 4/2006 www.hakin9.org

Dossier

28

Sur Internet, lorsqu'une partie A tente de réaliser une attaque DoS contre une partie B, en souhaitant dissimuler son identité, elle écrit en règle générale une adresse source erronée sur les paquets de son at-taque (les en-têtes IP sont falsifiés de manière à donner l'impression de venir des parties A-Z, par exem-ple ; seul A-Z sous IPv4 correspond à des permutations 2^32). Lors de telles attaques, les routeurs et autres dispositifs du réseau ainsi que le chemin qui y mène renvoient inévitablement une variété de mes-sages allant du redémarrage de la connexion à des requêtes quench sur des notifications inatteignables. Dans la mesure où ces messages sont retournés à l'expéditeur, lequel est falsifié, l'ensemble des parties A-Z recevront ces messages qui les informera d'une attaque dirigée con-tre la partie B, à l'instar du bureau de ma résidence informé des lettres que j'envoyais. La Figure 5 illustre le mécanisme.

Dans le filtrage de paquets dé-sormais pratiqué, la plupart de ces messages renvoyés sont ignorés de manière silencieuse par les pares feu. En effet, ces messages sont considérés comme des réponses à des messages que nous n'avons pas envoyés. Toutefois, grâce à l'ins-tallation d'un réseau invisible externe expliquée plus haut, il est possible de retrouver ces paquets renvoyés afin de déterminer le moment où notre espace d'adresse est impliqué dans une attaque sur une autre partie. Les types suivants de paquets suscep-tibles d'apparaître dans un réseau invisible peuvent être définis comme rétrodiffuseurs et vous informent gé-néralement de l'implication de votre espace d'adresse (ou de réseau invisible) dans une attaque :

PistageVous connaissez désormais la tech-nique de rétrodiffusion, mais com-ment l'utiliser à bon escient ? Dans un réseau à plusieurs passerelles de transit Internet, il peut s'avérer utile de localiser le point d'entrée de ces mauvais paquets en cas d'attaque

particulièrement virulente. Cette technique connue sous le nom de pistage, ou traceback en anglais, est d'autant plus pratique qu'une fois le point d'entrée spécifique sur le ré-seau (ou le réseau du FAI) identifié, il est possible de lâcher le trafic à cet endroit et de réduire la charge sur les liens, en permettant éventuellement au bon trafic de passer (via des pas-serelles alternatives), contrairement à la tactique plus simple du trou noir DdoS, évoquée plus haut. Cette technique du pistage permet d'utili-ser les rétrodiffuseurs collectés dans le(s) réseau(x) invisible(s) comme moyen de recherche du point d'en-trée de l'attaque dans le réseau. Mal-heureusement, cette technique n'est véritablement viable que du côté des FAI ou sur les réseaux de données éloignés dotés de nombreuses passerelles Internet. Il faut en effet comprendre en plus de la présente

description certaines dépendances supplémentaires parmi lesquelles l'utilisation du mécanisme de défen-se des trous noirs à chaque passe-relle Internet. Dans la mesure où les FAI les plus importants procèdent de cette manière ainsi qu'une poignée de réseaux entreprise mondiaux, nous allons tout de même expliquer en quoi consiste ce processus.

Supposons que vous disposiez d'un réseau configuré comme décrit plus haut, vous pouvez alors réaliser un pistage au beau milieu d'une atta-que DoS. Il vous suffit de suivre les trois étapes suivantes :

• identifier la cible et contrôler que le trafic de l'attaque est bien falsi-fié (si tel n'était pas le cas, cette tactique de pistage deviendrait inutile).

• diriger vers un trou noir le chemin des hôtes spécifiques (vraisem-

Sur Internet• Extreme Exploits : Advanced Defenses against Hardcore Hacks, publié par

McGraw-Hill/Osborne, tous droits réservés 2005, http://www.amazon.com/gp/product/0072259558/

• RFC 3330 (adresses Ipv4 d'utilisation spéciale) et 3882 (configuration du protocole BGP afin de bloquer les attaques DoS) Internet

• Projet sur les réseaux invisibles de l'équipe Cymru, http://www.cymru.com/Darknet/

• Page d'accueil des outils tcpdump et libpcap, http://www.tcpdump.org/• Page d'accueil de l'outil ARGUS, http://www.qosient.com/argus/flow.htm• Page d'accueil de Honeyd, http://www.honeyd.org• Page d'accueil du projet HoneyNet, http://www.honeynet.org• Page d'accueil de l'outil p0f, http://lcamtuf.coredump.cx/p0f.shtml• Article de Chris Morrow et de Brian Gemberling sur les trous noirs des FAI et l'ana-

lyse de la rétrodiffusion, http://www.secsup.org/Tracking/• Présentation de Dan Hawrylkiw sur les réseaux de pots de miel, http://

phoenixinfragard.net/meetings/past/200407hawrylkiw.pdf• Questions les plus fréquentes sur le filtre de paquets OpenBSD, http://

www.openbsd.org/faq/pf/

À propos de l'auteurAuteur et orateur reconnu, M. Oppleman enseigne dans le domaine de la sécurité des réseaux tout en travaillant comme consultant auprès de sociétés parmi les plus prestigieuses au monde. Le logiciel libre élaboré par M. Oppleman a été distribué sur des centaines de milliers d'ordinateurs dans le monde entier. M. Oppleman dé-tient par ailleurs la propriété intellectuelle de certaines applications client sans fil et de routage adaptable distribué. Une grande partie du contenu du présent article est tiré du livre de M. Oppleman intitulé Extreme Exploits : Advanced Defenses Against Hardcore Hacks, publié par McGraw-Hill/Osborne (tous droits réservés 2005) et disponible en librairie.

Protection réseau

hakin9 Nº 4/2006www.hakin9.org 29

blablement de type /32) ciblés par l'attaque pour chacune de vos passerelles. La plus grande attention est requise en termes de transfert vers l'interface de suppression venant remplacer l'utilisation d'un filtre à paquets censé stopper les paquets de l'attaque. Cette opération de trou noir obligera le routeur de la passerelle concernée à générer des messages ICMP inatteigna-bles, retournés (ou tentés d'être retournés) vers les sources falsi-fiées des paquets de l'attaque.

• utiliser dans les réseaux invisibles des outils chargés de détecter le trafic de rétrodiffusion (vraisem-blablement sous la forme de messages ICMP inatteignables) à l'aide de l'adresse IP des rou-teurs de passerelles. Toutes les adresses IP des passerelles con-

sidérées comme sources des pa-quets rétrodiffuseurs valident le fait que ces passerelles sont en réalité des points d'entrée pour le trafic de l'attaque. Voilà ! Vous venez de trouver le point d'entrée de l'attaque dans votre réseau. Même si vous ne disposez pas d'outils de réseau invisibles sophistiqués, une simple liste d'accès appliquée à l'interface du routeur de votre réseau invisible suffira à faire le travail à votre place, de la manière suivante : access-list 105 permit icmp any

any unreachables log; access-

list 105 permit ip any any

Enfin, si vous entrez en mode con-trôle terminal dans cette liste d'accès (ou tout simplement si vous suivez le journal), vous obtiendrez un modeste rapport sur les rétrodiffuseurs dans

lequel vous pouvez cherchez les adresses IP de vos passerelles.

Cette tactique de pistage combi-née à une défense de type trou noir contre les attaques DDoS se révèle utiles dans des situations où les flux de trafics malveillants ont falsifié les en-têtes. Il s'agissait jusqu'à très ré-cemment de la forme la plus répan-due pour lancer ce type d'attaques. Toutefois, avec la prolifération des machines zombies et des réseaux de zombies, de nombreux pirates ont désormais cessé la falsification des paquets DdoS. En effet, nul be-soin de falsifier les en-têtes si votre armée de systèmes d'attaque se trouve partout. C'est la raison pour laquelle les administrateurs réseau observent une chute considérable des attaques DdoS falsifiées au pro-fit du large déploiement des uRPF et du filtrage de points d'entrée. l

P U B L I C I T É

www.hakin9.orghakin9 Nº 4/200630

Focus

Bien que la plupart des systèmes d'ex-ploitation d'aujourd'hui et des périphé-riques réseau supportent déjà IPv6

(Internet Protocol version 6), l'utilisation de ce protocole dans les réseaux n'est pas encore universelle. Cette situation est due aux plu-sieurs facteurs. Ce sont avant tout les coûts liés au passage d'IPv4 à IPv6 et le fait que les utilisateurs ne se rendent pas compte des avantages apportés par ce dernier. Le présent article est consacré à la sécurité intégrée, l'un des principaux avantages d'IPv6 par rapport à son prédécesseur IPv4. Nous comparerons aussi les deux protocoles en ce qui concerne la sécurité de la communication en tenant compte des failles de sécurité.

Sécurité dans IPv4La sécurité dans IPv4, de même que dans IPv6, est en développement permanent ce qui les expose à un certain risque. Certaines questions, telles que la sécurité des applica-tions mobiles ou multidiffusion (multicast) ne seront pas analysées car le sujet est trop large. Par contre, vous allez voir que la sécurité n'est qu'un des avantages dont nous bénéficierons après le passage au protocole de nouvelle gé-

nération. IPv6 offre des adresses uniques aux différents périphériques et senseurs. Il permet aussi la mobilité et une communication peer-to-peer effective.

La sécurité dans IPv6 est similaire à celle dans IPv4. C'est une nouvelle bonne et mau-vaise à la fois. Tout d'abord, grâce à la pro-tection réseau, nous voulons savoir qui nous envoie des messages, qui lit les messages que nous envoyons et que les messages ne sont pas modifiés lors de la communication. De plus, il est nécessaire que le réseau soit

Sécurité d'IPv6

Rita Pužmanová

Degré de difficulté

IPv6 est un protocole IP de nouvelle génération à côté duquel on ne peut pas passer avec indifférence. On ressent de plus en plus souvent la pression pour commencer à l'utiliser. Ce n'est pas étonnant car IPv6 possède beaucoup d'avantages par rapport à son prédécesseur. Ce protocole a non seulement un espace d'adresses plus large, mais il implémente aussi le support pour les solutions sans fil, les applications distribuées et la sécurité.

Cet article explique...• Comment évaluer les propriétés d'IPv6 et les

profits liés à son utilisation.• S'il faut l'utiliser.• Quels sont les principaux dangers d'IPv6 et

quels moyens de défense on peut appliquer.

Ce qu'il faut savoir...• Les notions de base de TCP/IP, notamment

l'adressage IPv4 (éventuellement Ipv6).• La sécurité dans les réseaux IP, surtout IPSec.

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 31

opérationnel et accessible à tous les utilisateurs autorisés et que nous ayons le contrôle sur notre périphéri-que connecté au réseau.

IPSec : architecture de sécurité IP du réseauTout d'abord, analysons l'architec-ture de sécurité utilisée par les deux protocoles. L'architecture de sécurité IP (IPSec, Internet Protocol Security Architecture, RFC 4301) est conçue pour donner une sécurité de haute qualité pour IPv4 et IPv6. En fait, l'architecture IPSec a été conçue justement pour IPv6 (RFC 1883). IPSec inclut l'intégrité, l'authentifica-tion et une certaine confidentialité au niveau des datagrammes. L'architec-ture se compose de quelques proto-coles servant à envoyer les données authentifiées ou chiffrées à travers les réseaux IP (Figure 1).

IPSec est placé dans la couche réseau – elle est donc une architec-ture transparente par rapport aux protocoles applicatifs qui possèdent leurs propres mécanismes de sé-curité, comme par exemple SSL ou PGP. Pourtant, ce n'est pas un seul protocole, mais un jeu de protocoles

offrant les services de sécurité. Ils se composent de protocoles de sécuri-té : Authentication Header (AH), En-capsulating Security Payload (ESP) et les mécanismes pour la gestion des clés de cryptage : IP Security Association and Key Management Protocol (ISAKMP), RFC 4306 et Internet Key Exchange (IKE). IPSec définit ce qu'on appelle le concept d'association de sécurité (SA , Se-curity Association) qui détermine la politique de sécurité entre deux parties de la connexion appliquée au datagramme en fonction de son ex-péditeur, son destinataire et de son contenu. Une SA est identifiée de

façon unique par trois variables : l'in-dex du paramètre de sécurité (SPI, Security Parameter Index), l'adresse IP destination, et l'identifiant du pro-tocole de sécurité (51 pour AH et 50 pour ESP). SPI est une valeur de 32 bits utilisée pour choisir parmi les différentes SA ayant la même desti-nation et utilisant le même protocole IPsec. SA ne contient pas d'identi-fication de l'adresse IP source car – pour assurer une communication bilatéralement sûre – encore une as-sociation de sécurité doit être créée (pour la direction inverse). IPSec admet qu'une SA existe déjà et ne protège que la création appropriée des datagrammes.

Chaque nœud IPSec maintient deux bases de données : la base de données de la politique de sécurité (SPD, Security Policy Database) et la base de données des associa-tions de sécurité (Security Policy Associations). Le jeu de paramètres pour chaque SA (SPI, protocole de sécurité, mode, algorithme de cryp-tage, clé et autres) est stocké dans la base de données SPA. La base de données SPD contient le sommaire des préférences de sécurité suivant l'ordre de leur utilisation dans le da-tagramme IP. Chaque entrée dans cette base se compose d'un sélec-teur et d'une action (utiliser IPSec, détruire le datagramme ou ne pas utiliser IPSec). Si un datagramme contient des valeurs correspondant au sélecteur enregistré, l'action qui y est associé est utilisée.

Quand le système envoie un pa-quet nécessitant une protection par-ticulière, il recherche dans la base de

Figure 1. Une communication à travers le réseau public avec IPSec

Figure 2. Le format de l'en-tête d'authentification (AH)

hakin9 Nº 4/2006 www.hakin9.org

Focus

32

données une association de sécurité, exécute les opérations appropriées et met le SPI de l'association de sé-curité dans l'en-tête du datagramme. Le récepteur, à partir de la com-mande du datagramme, retrouve la SA dans la base de données suivant l'adresse destination/SPI et réalise les opérations appropriées.

La gestion des associations de sécurité se fait à travers le proto-cole ISAKMP. Pourtant, ISAKMP ne définit pas son propre mécanisme d'échange des clés secrètes entre les récepteurs et les stations en-voyant les paquets avec ESP ou AH, c'est pourquoi, en cas d'un échange automatique des clés (l'échange manuel est compliqué), il faut utiliser Internet Key Exchange, qui est une composante du contenu concret de l'association de sécurité. On utilise ici les algorithmes d'échange des clés de type Diffie-Hellman en ad-mettant que les deux parties de la communication sont connues. Cet échange est assuré à l'avance par les mots de passe et les certificats numériques communs.

Pour la gestion des clés dans IPSec, une infrastructure d'authen-tification homogène PKI est néces-saire. Le développement IKE était très complexe et la spécification de

la meilleure version du protocole IKEv2 (RFC 4306) a été publiée à la fin de l'année dernière. Néanmoins, son implémentation est pour l'instant assez rare, bien que sans le protoco-le spécial permettant la distribution des clés il soit impossible d'utiliser IPSec...

Protocoles AH et ESPL'authentification et l'intégrité des messages IP sont assurés par un complément au datagramme IP sous forme d'un en-tête d'authentification (Authentication Header, RFC 4302) saisi à la place de l'en-tête IP orginal qui utilise le chiffrement à l'aide de la clé publique. Le chiffrement concer-ne toutes les partie du datagramme qui ne change pas. On utilise ici l'algorithme de chiffrement MD5. Le chiffrement se fait à la source avant la fragmentation du datagramme, et le déchiffrement est effectué après la réception par la station de desti-nation.

L'authentification AH se fait à l'aide de ce qu'on appelle code d'authentification de message (MAC, Message Authentication Code). Si l'on utilise le hachage à sens unique, on obtient HMAC (Hash-Based MAC) ; il est en fait le résultat de la combinaison d'une fonction de ha-

chage avec une clé secrète. Il est possible de hacher un texte quel-conque en obtenant en résultat un condensé d'une taille déterminée. À la différence d'une signature nu-mérique, pendant le cryptage du condensé, on se sert d'une clé privée de la même longueur. HMAC utilise l'algorithme MD5 (RFC 2085 et 2403) ou SHA-1 (RFC 4305), un algorithme plus fort et plus puissant. L'AH est une bonne méthode là où l'authen-tification de chaque datagramme à part est suffisant. L'AH possède un identifiant du protocole de sécurité, le numéro de séquence et la somme de contrôle (Figure 2).

Le second protocole d'IPSec, Encapsulating Security Payload (ESP, RFC 4303), assure la confi-dentialité des données en cryptant le contenu et l'en-tête du paquet. Il offre aussi les services d'authentification similaires à AH (la comparaison de l'AH et de l'ESP est présentée dans le Tableau 1). L'ESP convient mieux dans les cas plus sérieux, quand il est nécessaire d'authentifier et de chiffrer le contenu des data-grammes pour les protéger contre l'écoute ou les abus. L'ESP permet le chiffrement avec l'authentification (null encryption, RFC 2410). L'ESP définit le contenu possible du data-gramme IP. Il se compose d'un en-tête qui comprend les informations concernant la politique de sécurité (SPI), du numéro de séquence, et éventuellement spécifie l'algorithme de chiffrement (par exemple DES), voir la Figure 3. Les données sont chiffrées d'une façon appropriée, et à la fin, il y a la somme de contrôle qui permet de confirmer la validité du datagramme.

L'AH et l'ESP utilisent le hachage pour vérifier si lors de la communi-cation, un changement du paquet

Tableau 1. Comparaison des protocoles AH et ESP

AH ESPauthentification de la source du message

oui au choix

intégrité des données transférées oui (y compris l'en-tête) oui (excepté l'en-tête)protection contre le rejeu au choix ouichiffrement non oui

Figure 3. Le format de l'en-tête ESP

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 33

n'a pas eu lieu. Vu que pendant la transmission, l'en-tête change, les deux protocoles ajoutent la valeur du contrôle d'intégrité (ICV, Integrity Check Value) aux certains en-têtes appartenant aux couches supérieu-res.

Modes tunnel et transportL'association de sécurité fonctionne en deux modes : transport et tunnel (Figure 4). En mode transport, l'en-tête de sécurité est mis entre l'en-tête origine du datagramme IP et les données, tandis qu'en mode tunnel, un nouvel en-tête est créé pour le da-tagramme, après lequel vient encore l'en-tête de sécurité.

L'ESP en mode transport chiffre et authentifie les données trans-mises, mais n'authentifie pas de l'en-tête du datagramme. L'AH en mode transport authentifie authen-tifie les données transmises et les champs sélectionnés de l'en-tête du datagramme. En mode transport, le protocole ESP est identifié dans l'en-tête IP à l'aide de l'ID de protocole IP 50 et le protocole AH – 51. Les deux en-têtes contiennent aussi le champ identifiant le type de données que comprend la charge utile, com-me TCP ou UDP. Le mode transport convient pour les communications de bout en bout effectuées via un réseau externe (Figure 5).

Quant au mode tunnel, le data-gramme entier (intérieur) est encap-sulé dans un autre datagramme avec (c'est-à-dire, il sera chiffré avant l'en-capsulation) un en-tête non chiffré (datagramme extérieur) qui servira à tracer la route dans le réseau. Les adresses IP de l'en-tête IP extérieur représentent les points d'arrêt du tunnel, alors que celles de l'en-tête

IP encapsulé constituent les vérita-bles adresses source et de destina-tion. Ce mode est utile pour protéger le trafic entre les différents réseaux et fonctionne entre les routeurs et les systèmes terminaux. Les routeurs reçoivent uniquement les en-têtes des datagrammes extérieures. Le mode tunnel est utilisé par défaut pour la construction de VPN (Virtual Private Network, voir la Figure 6).

L'utilisation de l'ESP en mode transport et en mode tunnel – en fonction des parties du datagramme authentifiées et chiffrées – est pré-sentée sur la Figure 7.

Les mécanismes ESP et AH peuvent être exploités entre deux nœuds du réseau (entre les utilisa-teurs finaux ou entre les routeurs), en transmission multicast et unicast. Les mécanismes de protection peu-vent s'ajouter, ce qui veut dire qu'un datagramme peut contenir les deux en-têtes : AH et ESP. AH assure l'in-tégrité des données en mode sans connexion et l'authentification de la source IP des paquets, mais n'offre pas la confidentialité des données au moyen du chiffrement. L'ESP permet le chiffrement, mais ne pro-tège pas de nouveaux en-têtes IP du paquet origine encapsulé. Pour avoir une authentification puissante avec la confidentialité des informa-

tions transmises, il faut utiliser la combinaison de l'AH avec l'ESP en deux modes : aussi bien en mode transport que tunnel.

Translation des adresses : NATLa translation des adresses (NAT, Network Address Translation; RFC 3022) est souvent utilisée dans la pratique. Dans Ipv4, il y a deux rai-sons principales : limiter le nombre d'adresses IP uniques nécessaires pour les réseaux privés et amélio-rer la sécurité de la communication entre les réseaux privés et Internet. La NAT a été mise au point pour répondre au manque d'adresses IP dans le protocole dû au fait que l'es-pace adressable n'est pas utilisé de manière optimale - une adresse est définie seulement sur 32 bits. Cette situation provisoire durera jusqu'au moment du passage à la nouvelle sixième version du protocole IP, per-mettant l'adressage unique du plus grand nombre de nœuds du réseau. Maintenant ces adresses ont une longueur de 128 bits.

La fonction NAT est bien con-nue, alors nous la rappellerons en quelques mots. Tout d'abord, il ne faut pas oublier que le réseau des connexions à Internet via la NAT doit embrasser au moins une adresse IP importante qui est affectée à un routeur ou à une machine connectée à Internet. Une application spéciale NAT (appelée NAT box) traduit les adresses dans les datagrammes entrants et sortants de façon à remplacer l'adresse source dans les datagrammes sortants par son adresse globale et l'adresse destina-tion dans les datagrammes entrants par l'adresse privée de la station ci-

Figure 4. La protection de l'association en deux modes

Figure 5. L'utilisation du mode transport

hakin9 Nº 4/2006 www.hakin9.org

Focus

34

ble donnée (d'après RFC 1918). Du point de vue d'un utilisateur externe, tous les datagrammes arrivent à la NAT et en réponse, sortent à partir de celui-ci. Du point de vue d'un utili-sateur interne, la NAT est un routeur connecté à Internet.

Inconvénients de la NATDans plusieurs applications, les règles de la NAT sont inaccepta-bles car celles-ci ne peuvent pas fonctionner correctement avec la translation des adresses. La NAT ne peut pas coopérer avec les protoco-les qui utilisent les informations sur les adresses à l'intérieur d'un simple datagramme. L'en-tête contient les adresses traduites à l'aide de la NAT, mais à l'intérieur des datagrammes, la NAT n'effectue pas l'opération de translation d'adresses. La nouvelle version de la NAT est capable de résoudre ce problème. En générale, la NAT n'est pas adaptée aux diffé-rentes tâches d'IP, il ne faut donc pas s'attendre à ce que les applications fonctionnent aussi efficacement en présence de la NAT dans leur con-ception initiale. Il serait peut-être juste que toutes les applications supportent la NAT, mais à vrai dire, cette solution n'est pas bonne vu la performance, l'extensibilité et l'implé-mentation des applications.

La NAT pose des problèmes même sous IPSec où la communi-cation se fait entre deux extrémités. Cette situation ne peut pas être com-parée à une adresse de substitution. IPSec, qui utilise l'en-tête authentifié, calcule la valeur d'authentification à partir du datagramme entier – y compris son adresse IP source et destination. Une modification quel-conque de l'adresse IP, par exemple au moyen de la translation, entraîne le calcul d'une autre valeur, et à cause de cela, l'authentification est refusée. La NAT doit être donc utili-sée avant le traitement avec IPSec. En cas d'ESP, l'authentification ne se fait pas à partir d'un en-tête extérieur, alors la translation NAT peut avoir lieu après l'application d'IPSec.

Si l'on combine la translation d'adresses et de ports (NAPT,

Network Address and Port Trans-lation), on utilise une adresse IP et plusieurs ports TCP et UDP (l'ob-jectif : économiser les adresses IP). La NAT établit les valeurs des ports juste après l'en-tête IP dans l'unité de données. Avec l'IPSec, le principe précédent ne peut pas être satisfait. De plus, l'ESP chiffre l'en-tête TCP ou UDP encore en mode tunnel, ce qui est inadmissible pour la NAT ; pour cette raison, la translation des adresses doit avoir lieu avant l'appli-cation d'IPSec. Plusieurs nouveaux produits IPSec supportent l'utilisa-tion de la NAT en implémentant l'en-capsulation UDP, mais ce n'est pas une solution universelle.

Protocole de nouvelle génération IP version 6 et sa protectionLa nouvelle version du protocole IP (IPng, IP next generation), portant le numéro 6 (IPv6; RFC 2460) a été élaborée il y a dix ans. La nécessité d'apporter les améliorations à IPv4 était liée au système d'adressage in-suffisant et à son utilisation ineffica-ce en allouant des blocs d'adresses trop grands. IPv6 résout tous ces problèmes grâce au format permet-tant d'utiliser 1038 d'adresses uni-ques, mais sa mise en point dans les réseaux modernes est motivée aussi par d'autres facteurs que seulement l'espace d'adressage plus large.

Grâce à l'adressage individuel, IPv6 permet une communication

sans intermédiaire entre les stations basée sur la règle peer-to-peer. Il supporte mieux que son prédéces-seur de nouvelles applications et services tels que VoIP, les jeux en li-gne menés par plusieurs utilisateurs, les vidéoconférences, les services de transfert des données avec la téléphonie mobile, ainsi que la con-nexion à distance des senseurs (par exemple RFID, Radio Frequency IDentification), les ménages infor-matisés, les bâtiments intelligents ou grid computing.

Mais il ne s'agit pas tout à fait d'une nouvelle architecture réseau car IPv6 a hérité beaucoup de ca-ractéristiques d'IPv4. Il y a le même service datagramme, les mêmes pro-tocoles de transport et pratiquement les mêmes applications. Pourtant, IPv6 offre aussi de nouveaux élé-ments, tels que l'espace d'adressage plus étendu, l'autoconfiguration, le support des technologies mobiles et la politique de sécurité intégrée.

Adressage dans le protocole IP version 6Pour satisfaire aux exigences liées à l'élargissement de l'espace d'adressage pour IP, IPv6 utilise 128 bits au lieu de 32 (RFC 4291). L'espace d'adressage devient alors quasi infini : 2128. L'adresse IPv6 type est divisée en deux parties : le préfixe et l'identificateur d'interface. Un identificateur d'interface peut avoir plusieurs adresses IPv6. Il existe différents types d'adresses

Figure 6. L'utilisation du mode tunnel

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 35

hakin9 Nº 4/2006 www.hakin9.org

Focus

36

Ipv6 : adresses mono-utilisateur (unicast; RFC 3587), multidestina-taires (multicast; RFC 3306, 3307 et 3956) et les adresses correspondant à un groupe d'interfaces (anycast) – seuls les deux premiers types sont utilisés dans IPv4. Le nouveau type d'adresse anycast est fort utile dans plusieurs applications modernes qui utilisent les serveurs dissminés dans le réseau. D'autre part, les adresses réservées peuvent être pour un intrus un but d'attaque intéressant – par conséquent, les adresses anycast disponibles globalement devraient être définies uniquement pour les routeurs. Pour une adresse anycast destination, il n'existe aucun méca-nisme d'autorisation ce qui rend plus faciles les attaques de type spoofing et masquerade.

Les adresses ont deux fonctions de base, coexistantes dans IPv4, mais séparées dans Ipv6 – la fonc-tion de localisation et la fonction d'identification. Les informations sur la localisation sont nécessaires au routeur parce qu'elles déterminent la façon de trouver le chemin vers le but. Elles offrent au moins trois niveaux d'agrégation : (TLA, Top-Level Aggregator; NLA, Next-Level Aggregator oraz SLA, Site-Level Aggregator, RFC 3587).

L'identification (identificateur) identifie un périphérique spécifique ou son interface. L'agrégation et l'allocation hiérarchique des adres-ses sont utilisées effectivement pour router globalement les données, vu que les décisions concernant le trajet du paquet dans le réseau sont prises à partir des bits initiaux de l'adresse suivant les préfixes de plus en plus longs et spécifiques.

Dans Ipv6, les 64 premiers bits déterminent en général l'information sur la localisation pour qu'il soit pos-sible d'atteindre un certain intervalle (site). Les 64 bits suivants identifient le périphérique dans le domaine défini. Le passage à un nouvel FAI nécessite le changement du locateur, mais pas de l'identificateur. Les adres-ses hiérarchiques IPv6 plus longues satisfont avant tout les exigences concernant la recherche effective

du chemin de paquet dans le réseau car elles permettent une agrégation plus facile des adresses suivant les niveaux hiérarchiques du réseau, le FAI (connexion), l'entreprise utilisant Internet et autres (RFC 3587).

La notation des adresses IPv6 diffère de celle d'IPv4. Les adresses sont écrites en notation hexadécima-le où les 8 groupes de 16 bits sont séparés par deux-points. L'adresse peut se présenter par exemple ainsi : FBCD:1234:5678:9001:2222:AB12:2345:6789. Il est permis de supprimer de la notation les zéros non significatifs, mais une seule fois dans une notation donnée, autre-ment cela pourrait porter à confu-sion. Par exemple, l'adresse FEDC: 0000:0000:0000:0000:0000:0000:0110 peut notée comme FEDC::110. IANA(Internet Assigned Numbers Authority) a affecté à RIPE NCC (Ré-seaux IP Européens Network Coor-dination Centre) la plage d'adresses (hex2001:600::/23). Quand nous récapitulons tous les types d'adres-sages IPv6, nous obtienons une liste assez longue. L'IPv6 permet d'affec-ter à une interface réseau plusieurs adresses individuelles qui peuvent être globalement uniques (global), seulement locales (site-local) ou cel-les dont la validité est restreinte à un lien (link-local). Dans le cadre d'IPv6, les adresses peuvent être divisées

suivant l'état de la configuration (RFC 2462) en préférées (prefer-red) et déconseillées (deprecated) ; éventuellement, conformément à RFC 304, en publiques (public ad-dresses) et temporaires (temporary addresses).

La connexion aux plusieurs FAI, c'est-à-dire multihoming, permet d'affecter plusieurs adresses à un nœud – aussi pour les interfaces virtuelles ou l'interface tunnel. De cela, pendant l'établissement d'un connexion, les implémentations d'IPv6, dans les nœuds extrêmes et les routeurs, doivent souvent choisir parmi plusieurs adresses sources et destination. Ces situations sont réso-lues par l'intermédiaire du mécanis-me de choix d'adresses (RFC 3484), commun à toutes les implémenta-tions, mais qui n'est pas prioritaire par rapport au choix des adresses définies par chaque application. En cas d'implémentations double (IPv4

Avantages d'IPv6 par rapport à IPv4• l'espace d'adressage plus étendu,• la simplification du format de l'en-

tête du datagramme,• le support obligatoire pour IPSec,• le support élargi pour les protoco-

les IP mobiles.

Figure 7. ESP en mode transport et tunnel

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 37

avec IPv6), il faut décider quel type d'adresses doit être utilisé.

Configuration automatiqueIPv4 n'offre pas directement une configuration automatique de la machine lors de sa connexion au réseau. L'alternative pour la configu-ration manuelle de chaque machine est le protocole DHCP. À partir de la requête de la machine, le serveur DHCP lui affectera une adresse IP et fournira les informations nécessaires pour le travail dans le réseau donné. Dans IPv6, il est possible d'utiliser le protocole DHCPv6 remanié, mais l'apport positif d'IPv6 est la confi-guration automatique (RFC 2462 et RFC 3041) qui n'exige aucun serveur.

L'autoconfiguration n'a pas été intégrée dans le projet IPv6 pas à cause du manque de confiance envers les utilisateurs finaux, mais pour faciliter les modifications d'ISP, supporter les technologies mobiles,

assurer l'unicité des adresses et sup-porter IP sur les équipements qui ne sont pas surveillés par un administra-teur réseau (il s'agit par exemple des dispositifs récepteurs domestiques). L'auto configuration sans état permet aussi aux nœuds une communica-tion dans les réseaux sans routeurs (réseaux ad hoc).

L'autoconfiguration utilise le protocole ICMPv6 (Internet Control Message Protocol) et est basée sur la découverte des voisins (NDP, Neighbor Discovery Protocol, RFC 2461 et RFC 3122). L'équipement connecté au réseau IPv6, en premier lieu crée son adresse locale (link-local) à partir du préfixe prédéfini hexFE80, et ensuite, ajoute à celui-ci son identificateur (EUI, End User Identifier). L'équipement vérifie dans le réseau si cette adresse n'est pas utilisée par quelqu'un d'autre. Tous les nœuds dans un segment répon-dront à une station donnée, et après l'échange des informations pourront

communiquer sans l'intermédiaire des serveurs ou routeurs.

Les équipements suivent les messages des routeurs qui envoient régulièrement l'information (router advertisement) annonçant aux équi-pements l'adresse du préfixe (prefix adress) d'un réseau donné et l'infor-mation sur la passerelle (default ga-teway) et sa durée de vie. En même temps, grâce à ces informations, l'équipement saura s'il faut utiliser la configuration avec état ou sans état. L'équipement nouvellement con-necté peut demander tout seul ces informations à partir des routeurs, alors il ne doit pas attendre leur annoncepériodique. Dans le cadre de la configuration sans état, à partir du préfixe annoncé, l'équipement construira sa propre adresse IPv6 unique en ajoutant à ce préfixe l'EUI de l'adresse locale. Si l'équipement effectue la configuration avec état, DHCPv6 est utilisé.

Pour des raison de sécurité, il faut vérifier si l'information diffusée dans le réseau provient d'un routeur autorisé et avec quelles exigences de sécurité en ce qui concerne la dé-couverte des voisins que nous avons déjà mentionné.

SEND (SEcure Neighbor Disco-very; RFC 3971) définit de nouvelles possibilités d'ICMPv6 dans le cadre du protocole NDP, sur la base des si-gnatures utilisant les clés publiques. La fonction de hachage de la clé publique est utilisée pour la géné-ration de l'adresse, les routeurs sont certifiés par l'intermédiaire de X.509, les données sont signées et les mar-queurs de temps confirment le mo-ment de la création du message.

Datagramme IP version 6IPv6 transmet efficacement aux extensions des en-têtes optionnels les informations qui ne sont pas nécessaires dans le datagramme. L'en-tête obligatoire ( Figure 9) a la longueur constante (40 octets) et ne contient que 8 champs. La Figure 8 présente le format du datagramme IPv4). Après l'en-tête obligatoire peuvent venir les en-têtes option-nels d'une longueur variable. Les

Format de l'en-tête obligatoire• version (version) – numéro de la version du protocole (6),• priorité (priority) – permet à la source d'identifier la priorité de chaque datagramme

par rapport au reste des datagrammes provenant d'une même source ; il s'agit de la priorité du point de vue de la transmission et de la livraison,

• étiquette de flux (flow label; RFC 3697) – permet d'identifier les datagrammes spécialement traités lors du routage ; les équipements et les routeurs qui ne sup-portent pas ce champ, ne peuvent pas le changer. Le flot de données est défini comme une suite de datagrammes envoyés d'une source à un destinataire ou à un groupe de destinataires. Le marquage du flux et le champ précédent priority permettent ensemble de définir la priorité de la transmission dans le cadre de QoS (Quality of Service) – le contrôle de la bande passante. Vu qu'il n'existe pas de mécanisme d'authentification, les attaques DoS (Denial of Service) ou les vols du service peuvent avoir lieu. C'est pourquoi, les mécanismes de type pare-feu ne doivent pas baser entièrement sur les marquages du flux pour prendre les déci-sions,

• longueur des données dans le datagramme (payload length) – la longueur de la partie restante du datagramme Ipv6, c'est-à-dire la longueur de tous les en-têtes complémentaires et la longueur du champ de données,

• en-tête suivant (next header) – identifie le type de l'en-tête directement après l'en-tête obligatoire du datagramme IPv6,

• nombre maximal de routeurs (hop limit) – le nombre de routeurs permis (une ana-logie au champ de durée de vie sous IPv4 – TTL, Time To Live) ; chaque routeur le réduit d'une unité. Si cette valeur est réduite à 0, le datagramme ne peut pas être transmis plus loin ni qu'un message ICMP soit généré,

• adresse source (source address) – l'adresse de la source d'une longueur de 128 bits,

• adresse destination (destination address) – l'adresse du destinataire voulu d'une longueur de 128 bits (dans certains cas, il ne s'agit pas d'un périphérique cible, à moins qu'une extension de l'en-tête pour diriger n'ait été utilisée).

hakin9 Nº 4/2006 www.hakin9.org

Focus

38

données qu'ils contiennent seront utilisées dans les nœuds extrêmes, mais très rarement dans les rou-teurs. Ainsi, les routeurs ne s'occu-pent que de l'en-tête d'une longueur constante, moins compliqué que dans IPv4, ce qui a permis d'accé-lérer son fonctionnement.

À la différence d'IPv4, l'en-tête obligatoire ne contient pas ici une information superflue sur la longueur de l'en-tête, et en même temps, il ne contient pas non plus la somme de contrôle en se référant aux autres couches. Dans IPv6, contrairement à IPv4, la fragmentation d'après la longueur admissible de l'unité de données (MTU, Maximum Trans-mission Unit) n’est réalisée que par les nœuds sources et les routeurs sur le trajet ne le peuvent pas. Cela veut dire que la MTU minimale d'un transfert donné doit être déduite par l'ordinateur source (RFC 1981) avant l'envoi du datagramme. Le fait de défendre la fragmentation des data-grammes aux routeurs réduit dans une certaine mesure les abus de la fragmentation qui ont pour but de violer la sécurité de la transmission.

Après l'en-tête obligatoire IPv6, peuvent venir certains en-têtes d'extension optionnels. Chaque en-tête identifie l'en-tête suivant – il contient le champ définissant le type de l'en-tête consécutif (l'exemple sur la Figure 10). Si il n'y aucun en-tête suivant, le protocole de transport est spécifié par l'intermédiaire du numé-ro du protocole, qui est le plus sou-

vent identique à celui d'IPv4 (6 pour TCP, 17 pour UDP ou 46 pour RSVP, mais 58 pour ICMPv6). La valeur 59 dans le champ En-tête suivant indi-que que rien ne suit cet en-tête – s'il y a quand même des données, elles seront négligées.

Sécurité d'IPv6IPv6 utilise obligatoirement le proto-cole de sécurité IPSec, ce qui signifie qu'il supporte nativement l'authenti-fication, le chiffrement, VPN. Avec le nouveau protocole, de nouveaux types d'attaques apparaissent, il ne faut donc pas attendre qu'IPv6 sera supersécurisé. En particulier, il faut se rendre compte du fait qu'IPSec veille à la sécurité de la couche réseau et pas des applications spécifiques, et qu'il ne préviendra les attaques contre cel-les-ci. IPv6 ne protégera pas non plus contre les attaques par inondation de datagrammes.

Les mécanismes d'authentifica-tion et de chiffrement sont ajoutés au datagramme IPv6 au moyen des en-têtes d'extension optionnels. Même si le support de ces en-têtes est obligatoire, IPv6 ne les détermine pas à l'aide des applications, c'est

pourquoi la présence de la protection au niveau de transport ne dépend que de l'utilisateur et des applications. On ne peut donc pas prétendre qu'IPv6 soit un protocole plus sécurisé que son prédécesseur, mais on peut dire qu'IPv6 est un pas en avant pour l'élargissement de l'authentification et de la protection au niveau des protocoles de transmission. L'AH assure l'intégrité des données (MAC) et l'authentification (vérification de l'identité de la source), mais ne garan-tit pas la confidentialité. Le calcul de MAC est réalisé par la source avant la fragmentation du datagramme, et le contrôle de l'intégrité se fait après la reconstitution du datagramme dans le nœud destination. Le MAC concerne toutes les parties du datagramme qui ne changent pas pendant le trajet dans le réseau (comme pour quel-ques types d'en-têtes). Pour le MAC, on utilise MD5 et SHA-1.

L'ESP a pour but de chiffrer les données. On peut chiffrer soit les don-nées de niveau transport, c'est-à-dire le segment TCP/UDP ou le message ICMP (transport-mode), soit le data-gramme IPv6 entier (tunnel-mode, voir la Figure 11). Dans le premier cas,

Ordre des en-têtes optionnelsUne revue des en-têtes et leurs identificateurs sont présentés dans le Tableau 2 :

• en-tête des options sauts après sauts (hop-by-hop options header) – définit les options qui doivent être examinées et traitées par chaque routeur le long du chemin emprunté par le datagramme, par exemple l'avertissement du routeur sur le contenu du datagramme intéressant (RFC 2711, le choix de l'identificateur 5) ou le support de l'emploi de ce qu'on appelle jumbogrammes (RFC 2675, le choix de l'identifica-teur 194), les datagrammes d'une taille supérieure à 65 Ko et inférieure à 4 Mo,

• en-tête des options de destination (destination options header) – contient les infor-mations optionnelles pour la destination (l'en-tête optionnel peut être placé après tous les autres en-têtes et définit l'action du dernier nœud destination).

• en-tête de routage (routing header) – donne une liste des routeurs qui doivent être visités le long du trajet vers la destination ; la destination doit ensuite utiliser cet en-tête pour déterminer le trajet dans le sens inverse,

• en-tête de fragmentation (fragment header) – contient les informations servant à fragmenter et rassembler les datagrammes. La fragmentation n'est réalisé que par un nœud source, c'est pourquoi le nœud source doit être capable de déterminer la MTU pour que le datagramme ne soit pas détruit lors de la transmission. La reconstitution du datagramme est effectué par la station destination,

• en-tête d'authentification (AH) – assure l'intégrité et la véracité du datagramme,• en-tête d'encapsulation de charge utile sécurisée (ESP) – assure la protection des

données transférées dans le datagramme, leur authenticité et leur intégrité ; si le chiffrement est nul (null), seuls les services d'authentification et d'intégrité sont assurés.

Tableau 2. Les en-têtes d'extension et leurs identificateurs

identifi-cateur

en-tête d'extension

0 hop-by-hop43 routing44 fragment50 encapsulating security

payload header, ESP51 authentication header,

AH59 no next header60 destination options62 mobility

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 39

SDJE

hakin9 Nº 4/2006 www.hakin9.org

Focus

40

le chiffrement est réalisé par le nœud source, et lors du trajet, les routeurs ne s'intéressent qu'aux en-têtes obli-gatoires non chiffrés du datagramme IPv6 et aux en-têtes d'extension non chiffrés. Quant au mode tunnel, tout le datagramme est chiffré (intérieur) et il est encapsulé dans un autre data-gramme avec l'en-tête non chiffré (da-tagramme extérieur). Cette méthode ne fonctionne qu'entre les routeurs qui collaborent et pas entre les nœuds extrêmes. Les routeurs identifient les datagrammes uniquement avec l'en-tête extérieur.

Les mécanismes de protection peuvent être combinés, ce qui veut dire qu'un datagramme IPv6 peut contenir les deux en-têtes : AH et ESP (Figure 12). Vu que le chiffrement est réalisé avant l'authentification, le da-tagramme entier est authentifié avec les parties chiffrées et non chiffrées ; vu que c'est l'authentification qui est effectuée en premier lieu, l'en-tête est insérée dans le datagramme inté-rieur qui est ensuite chiffré dans son entier. Cette solution n'est pas trop

heureuse car on ne profite pas de l'authentification.

Le protocole IPv6 n'assure pas la protection contre la non-repudiation, le rejeu (replay) et notamment contre les attaques de type denial-of-ser-vice (DoS).

Le mécanisme NAT élargi dans les protocoles IPv4 n'est pas néces-saire dans IPv6, bien qu'il existe une certaine analogie. Il s'agit du fait de supporter la translation des adresses IPv4 et IPv6 (RFC 2766). Ce méca-nisme comprend la façon de traduire le format de l'en-tête les deux proto-coles, c'est pourquoi il a dans son nom la notion de translations de pro-tocoles (PT, Protocol Translation).

Passage à IPv6 ?Vu que le fait de migrer vers un nou-veau protocole nécessitait une modi-fication complète des adresses IPv4 en adresses Ipv6) et un changement coûteux des équipement et des pro-grammes, parallèlement au dévelop-pement d'IPv6, on a tenté de mieux aménager l'espace adressable IPv4.

Ainsi, de nouvelles solutions (tempo-raires) ont pu voir le jour :

• translation des adresses réseau (NAT) – pour remédier à la pénu-rie d'adresses routables,

• masque de sous-réseau à lon-gueur variable (VLSM) – une adresse du réseau IPv4 peut être divisée en plusieurs sous-réseaux (subnetting) ; avant VLSM, ce type d'adressage était possible, mais il fallait opérer sur un nombre cons-tant de bits destinés à adresser un sous-réseau (longueur du masque ou, éventuellement, une machine. VLSM a éliminé cette limitation et a permis l'adressage efficace des sous-réseaux avec plusieurs machines terminales (Ethernet et autres réseaux utilisant les moyens de transmission) et des connexions entre deux point né-cessitant uniquement deux adres-ses de nœuds terminaux,

• routage inter domaine sans classe IPv4 (CIDR) – le routage des proto-coles modernes, notamment avec BGP (entre les domaines ou les systèmes autonomes), n'est pas effectué via les classes d'adres-ses, mais par une agrégation de plusieurs réseaux (supernetting). Ainsi, on obtient un masque uni-que pour représenter des réseaux multiples en une seule entrée de table de routage. Une pause dans le transfert vers les adresses destination d'un bloc d'adresses agrégées n'entraîne pas la néces-sité de recalculer toute la table de routage.

Ces solutions n'ont pas éliminé les problèmes liés à IPv4 : la NAT en-traîne les problèmes dus à l'instal-lation des mécanismes de protection réseau (IPSec) et ne permet pas la communication peer-to-peer. CIDR seul ne suffit pas pour limiter la taille des tables de routage.

Comparaison détaillée d'IPv6 avec IPv4Les différences concernant les ser-vices dans IPv4 et IPv6 sont présen-tées dans le Tableau 3.

Figure 8. Le format du datagramme IPv4

Figure 9. Le format de l'en-tête obligatoire du datagramme IPv6

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 41

Les différences dans le format des datagrammes IPv4 et IPv6 sont présentées dans le Tableau 4 (Fi-gure 8 et 9).

Passage d'IPv4 à IPv6 Si les implémentations complètes d'IPv6 supportent IPSec, la pro-tection d'IPv6 est aussi puissante qu'IPv4 avec IPSec. Mais grâce à l'élimination de la NAT, l'implé-mentation d'IPSec, surtout dans les réseaux importants est devenue plus simple.

Mécanismes d'intégration entre IPv4 et IPv6L'implémentation d'IPv6 dans les réseaux implique non seulement le changement du protocole du réseau principal et de l'adressage, mais aussi d'autres protocoles connexes : ICMP, les protocoles routeur et ap-plicatifs. L'ICMPv6 contient aussi les fonctions des protocoles ARP (Address Resolution Protocol) et IGMP (Internet Group Management Protocol) en version 4. Le protocole RARP a été exclu de l'architecture de la nouvelle génération. Les pro-tocoles de transport TCP et UDP fonctionnant dans IPv6 ne diffèrent pas trop des protocoles de transport existants dans Ipv4.

Parmi les protocoles applicatifs (administratifs), le support pour IPv6 est développé par l'extension des protocoles DNS et FTP. Les protoco-les applicatifs de l'utilisateur, tels que HTTP et SMTP, ne changent pas. La transition d'IPv4 à IPv6 est résolue à l'aide des mécanismes de base sui-vants (il existe d'autres méthodes qui en sont la combinaison) :

• tunnellisation (RFC 3056, voir la Figure 13.) – pour assurer la communication entre deux ma-chines , il est impératif de mettre en place des tunnels unidirec-

tionnels ou bidirectionnels ; pour ce faire les paquets IPv6 sont encapsulés dans des paquets IPv4 (RFC 2893),

• double implémentation d'Pv4 et IPv6 (dual-stack, voir Figure 14.) – les implémentations de deux protocoles au sein du même équipement,

• translation – la communication entre l'équipement IPv4 et IPv6 est possible.

Mais les mécanismes de transition ouvrent de nouvelles possibilités pour les attaques : surtout les tun-nels créés automatiquement sont vulnérables à la modification des paquets et aux attaques de type DoS, c'est pourquoi ils doivent être protégés par IPSec. Il s'agit du même type d'attaques qu'en cas de tunnels utilisés dans IPv4 – il ne diffèrent que par la méthode de réa-lisation. Les tunnels statiques sont plus sûrs, mais leur extensibilité n'est pas élevé. De plus, les tunnels sont capables de contourner les services pare-feux. Ils doivent être mis au point uniquement entre les systèmes autorisés. Dans le cas de la double implémentation (dual stack), il faut veiller à assurer la protection de deux protocoles. Les attaques contre IPv6

peuvent facilement endommager le réseau IPv4.

Importance d'IPv6 dans les réseaux modernesLe Japon et la Chine sont les pays où IPv6 règnent non seulement dans les réseaux nouvellement construits, mais aussi dans les réseaux de l'ad-ministration publique. En Asie, on craint souvent que l'espace adressa-ble ne soit pas suffisant, ce qui est un danger réel en prenant en considéra-tion la vitesse du développement des technologies et des réseaux dans cette région. Au Japon, IPv6 devien-dra bientôt le protocole de commu-nication dans les réseaux publiques et d'entreprise. L'année passée, en Chine, le plus grand réseau de recherche et d'éducation, appelé CERNET2 (http://www.edu.cn), qui relie actuellement environ deux cent université, a été entièrement basé sur le protocole IPv6.

En Europe, comme aux États Unis, l'utilisation d'IPv6 se limite seulement aux réseaux de recher-che et universitaires ou aux projets futurs. Pourtant, les organisations de l'état des États Unis ont l'intention de passer à IPv6 en 2008. Les FAI sont en train d'apprendre IPv6, mais même le support assez pauvre des réseaux basés uniquement sur Ipv6, les utilisateurs peuvent profiter des possibilités offertes par la tunneli-sation d'IPv6 pour les réseaux IPv4. Grâce aux tunnels, l'environnement IPv6 est accessible pratiquement pour tous.

Figure 10. L'exemple des en-têtes d'extension du datagramme IPv6 pour les données TCP

Figure 11. Le chiffrement des données dans le datagramme IPv6

hakin9 Nº 4/2006 www.hakin9.org

Focus

42

En Europe, le retard ne concerne pas les exigences envers les blocs d'adresses IPv6 provenant de RIPE NCC, mais il est dû au manque de support pour IPv6 dans chaque équi-pement réseau dans le domaine des services et des applications. Plu-sieurs applications utilisent actuelle-ment les adresses IPv4 au lieu des noms (hostname), alors le passage vers IPv6 nécessite le changement du côté clients et serveurs.

Le premier réseau mis en place pour tester IPv6 était 6Bone, créé dé-jà en 1995. En Europe, c'était le pro-jet Euro6IX (http://www.euro6ix.org) qui a permis de mettre en place une véritable infrastructure d'IPv6. Il était la base pour construire le premier réseau européen non commercial IPv6 – Internet Exchange et 6NET (http://www.6net.org). Cela a con-firmé la nécessité de passer à IPv6 pour permettre le développement d'Internet. Environ trente partenaires ont participé à la construction du réseau 6NET, y compris l'entreprise tchèque CESNET, qui déjà au début de 2003 a mis au point dans son pays – dans le cadre de 6NET – le premier réseau basé sur le protocole

IPv6 (mais pas avec la méthode de tunnellisation).

Le réseau CESNET2 basé sur le protocole IPv6 a été mis en place déjà en 1999, et depuis 2004, le pro-tocole IPv6 est offert comme service standard. Au lieu de la tunnellisation ordinaire IPv6 dans Ipv4, CESNET2 implémentait le mécanisme de la transmission des datagrammes IPv6 via MPLS (MultiProtocol Label Switching) basée sur la technologie 6PE (supporté par Cisco Systems et Juniper) qui consistait à la commuta-tion des paquets IPv4 en IPv6. Cer-

tains réseaux terminaux connectés à CESNET2 supportent aussi IPv6 outre IPv4 en mode dual stack, alors une connexion au réseau MPLS par un routeur du côté client est simple. Dans d'autres cas, il est nécessaire d'implémenter les routeurs spéciaux supportant Ipv6 ; il faut aussi utiliser le mécanisme d'après IEEE 802.1Q pour séparer l'exploitation d'IPv6 de celle d'IPv4.

Le réseau national pour les recherches et l'éducation (NREN) CESNET2 fait aussi partie d'un ré-seau européen IPv6 GÉANT dans

Tableau 3. Différences dans les services d'IPv4 et IPv6

Service solution IP version 4 solution IP version 6

adressage adressage sur 32-bits : monoutilisateur (unicast), multiutilsateur (multicast), global(broadcast)

adressage sur 128-bits : monoutilisateur (unicast), multiutilisateur (multicast), inter-face dans le groupe (anycast)

autoconfiguration DHCP possible pour les nœuds termi-naux

DHCPv6 (stateful, avec état) ; autoconfigu-ration (stateless, sans état), rénumérotation des routeurs (router renumbering)

qualité des services (QoS)

bits IP (dans le champ Type of Service), changement en bits pour DiffServ ; autre mécanisme IntServ

classes d'exploitation, identification des flux de données (priority a flow) directement dans le datagramme

extensibilité routage avec CIDR, agrégé d'adresses (bloc d'adresses)

routage hiérarchique à partir des structures hiérarchiques

émission adressage multiutilisateur (multicast) – à tous les utilisateurs d'un groupe (par exemple vidéoconférences, formations en ligne)

adressage multiutilisateur (multicast) adressage à une interface (la plus proche) d'un groupe (anycast)

protection IPSec – ajout possible support obligatoire ; une partie du data-gramme : l'en-tête d'extension (AH, ESP)

technologies mobiles Mobile IP – routage via home agent à travers un tiers agent auquel l'utilisa-teur est connecté (triangle routing)

élimination du tunneling via home agent, routage direct

Figure 12. Le chiffrement et l'authentification dans IPv6

Sécurité d'IPv6

hakin9 Nº 4/2006www.hakin9.org 43

lequel Ipv6 est disponible en stan-dard depuis 2003. Son successeur, GÉANT2 (http://www.geant2.net), un nouveau réseau européen cons-truit à des fins éducatives, supporte IPv6 et IPv4 en mode dual stack. GÉANT2, dont la première phase a été déjà terminée, servira pour tester les technologies réseaux et les appli-cations, y compris IPv6.

Il existe un organisme inter-national qui surveille et supporte l'application du protocole IPv6 dans différents types de réseaux. Il s'ap-pelle IPv6 Forum. En 2003, il a lancé un programme international de certi-fication des composants Ipv6 appelé IPv6 Ready Logo Program! (http://www.ipv6ready.org). Le forum a pu-blié aussi une analyse dans laquelle il avertit de l'épuisement potentiel des adresses IPv4 déjà en 2008 (pour plus d'informations : Internet Protocol Journal 9/2005).

Dans les réseaux scientifiques et universitaires, IPv6 est soumis aux tests permanents, mais dans les autres, il est utilisé plutôt par obliga-tion car les personnes intéressées par ce protocole ne sont pas nom-breuses. Il y a un véritable abîme entre les concepteurs et les implé-mentateurs, et la vulgarisation de ce protocole et son utilisation dans la pratique dépendent justement de ces derniers. Quand le premier groupe déclare la nécessité d'utiliser IPv6, le second le voit autrement : IPv4 est encore très bon et les adresses sont

pour l'instant en abondance. D'après les analyses effectuées par Juniper Networks sur un groupes de respon-sables IT et les cadres de l'adminis-tration du gouvernement des États Unis, seulement 7% sur 349 per-sonnes questionnées considèrent le protocole IPv6 comme important dans leur travail, bien que la gestion facile des réseaux et l'amélioration de la qualité de la communication soient dans leur intérêt. De plus, le protocole de la nouvelle génération peut réduire les coûts de la transmis-sion multiutilisateur (multicast), vidéo et simplifier le passage vers VoIP. Ce qui est très important – pour un tiers des personnes interrogées par Juni-per Networks, la raison pour rester sur IPv4 est... le manque de motiva-tion pour les changements. Un autre tiers serait pour le changement, mais – d'après eux – les coûts liés à ce changement sont importants (sur-tout ceux concernant l'échange du

matériel). Environ 17% craignent les problèmes techniques.

La plupart des applications IPv6 se heurtent au problèmes liés aux coûts que beaucoup d'utilisateurs ne peuvent pas franchir, d'autant plus s'ils ne sont pas capables de prévoir les bénéfices potentiels. On a toujours l'impression qu'il n'existe pas encore d'application (killer ap-plication) pour laquelle il vaudrait la peine de passer à IPv6. Mais une justification suffisante pour passer au nouveau protocole est le nombre im-portant d'utilisateurs des téléphones mobiles ou la popularité croissante des réseaux informatiques domesti-ques. Et on peut encore ajouter un électronique portative, les minisen-seurs et la technologie RFID...

Plages à problèmesIPv6 est un protocole réseau du fu-tur, mais sa sécurité n'est pas encore complète. La politique de sécurité,

Tableau 4. Les différences dans les en-têtes des datagrammes IPv4 et IPv6

Informations dans le datagramme IP version 4 IP version 6longueur du datagramme variable – spécification de la lon-

gueur nécessaireconstante – sans devoir spécifier la longueur dans le datagramme

Longueur du datagramme spécifiée dans le champ longueur totale

n'est pas donnée; seule longueur du paquet après en-tête est donnée – le champ payload length

type de service champ ToS – actuellement pour DSCP

champ de priorité et flow label

durée de vie Définie dans le champ TTL définie dans le champ hop limitfragmentation champ d'identification, fragmentation

par routeursfragmentation uniquement par la source – seule l'en-tête d'extension

protocole supérieur numéro du protocole l'en-têtesomme de contrôle de l'en-tête protection protocole supérieurpossibilités longeur du datagramme l'en-tête

Figure 13. La tunnellisation d'IPv6 à IPv4

hakin9 Nº 4/2006 www.hakin9.org

Focus

44

les processus et les moyens doi-vent être ajustés à IPv6. Il ne faut pas oublier d'installer un pare-feu avec un support approprié – cela est parfois problématique car les produits présents actuellement sur le marché ne prennent pas en compte les besoins typiques pour IPv6. Il en est de même s'il s'agit de la stabilité et du support complet de tous les éléments d'IPv6 dans les routeurs et les systèmes d'exploitation.

Le pare-feu dans les réseaux IPv6 change son caractère, ce qui est dû aux modifications dans le modèle réseau général. Sa position dans le réseau ou dans le système final (pare-feu personnel) change et de cela – change la gestion (administrateur ou utilisateur) car il n'existe pas de limite que l'on doive défendre. Les systèmes terminaux doivent être protégés avec plus de précaution : accès par mot de passe, protection anti-virus, cryptage des données et autres.

Si les réalisateurs des réseaux pouvaient déjà offrir IPv6, proba-blement ils n'entreprendraient pas des actions spéciales pour un petit groupe de clients. NTT America en est une exception notable, car en précurseur d'IPv6 aux États Unis, il offre depuis quelque temps la pro-tection d'IPv6 pour le même prix que le pare-feu pour IPv4.

Malheureusement, même dans le cas de Linux, il n'existe pas as-sez de scripts qui pourraient aider à créer des pare-feux appropriés. C'est pourquoi, les attaques sur les réseaux IPv6 ne sont pas rares.

IPSec est obligatoire pour IPv6, mais ne résout pas le problème de protection réseau. Les autres pro-priétés d'IPv6 supportent aussi la protection plus avancée par rapport à Ipv4 : de grands sous-réseaux rendent plus difficiles les attaques à l'aide des vers, et le scannage

automatique est aussi difficile. De l'autre côté, IPv6 signifie une com-plexité plus élevée de l'adressage et de la configuration. De nouveaux éléments IPv6, de même que ses applications immatures, sont plus vulnérables aux failles de sécurité.

Il faut consacrer assez de temps au passage d'IPv4 à Ipv6 car la mi-gration ne sera pas effectuée sur-le-champs – les deux environnements devront coexister encore longtemps. Ce sont justement les mécanismes transitoires – les tunnels, une double implémentation sur les équipements – qui peuvent poser des problèmes en ce qui concerne la sécurité. Outre ces obstacles, la protection des systèmes terminaux, la protection des applications et l'audit resteront toujours une question très impor-tante. l

Sur Internet• http://www.ins.com/downloads/surveys/sv_ipv6_1205.pdf – INS IT Industry Survey: Ipv6• http://hexateuch.6net.org/thebook/ – Ipv6Deployment Guide (sous le patronage

de CESNET dans le cadre du projet 6NET)• http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html

– A Pragmatic Report on IPv4 Address Space Consumption, Tony Hain, Internet Protocol Journal Vol. 8, No. 3

• http://www.SANS.org – SANS Institute• http://www.ietf.org/rfc.html – RFC• http://www.ripe.net/rs/ipv6/stats/ – RIPE• http://www.ipv6forum.org – IPv6 Forum• http://www.ipv6tf.org – IPv6 Task Force• http://www.ipv6style.com/en/ – IPv6 Style• http://www.ipv6.org / – IPv6 Information Page• http://www.ist-ipv6.org/index.php – IPv6 Cluster• http://www.6bone.net – 6Bone• http://www.6ren.net – 6REN (IPv6 Research and Education Networks)• http://www.6net.org/ – 6NET• http://www.euro6ix.org/ – Euro6IX• http://www.euro6ix.org / – 6IX (IPv6 Internet Exchanges)• http://www.6qm.org/ – 6QM (IPv6 QoS Measurement)• http://www.seinit.org – SEINIT (Security Expert Initiative)• http://www.geant2.net – GÉANT2• http://www.cesnet.cz – CESNET

Littérature• Protection de la communication distante, Computer Press, ISBN 8025107914• TCP/IP w skrócie, Kopp, ISBN 8072322362• Routing and Switching: Time of Convergence?, Addison Wesley Longman Limited

ISBN 0201398613

Figure 14. Dual stack

www.hakin9.orghakin9 Nº 4/200646

Fiche technique

P cap est une des libraires les plus utili-sées servant à chiffrer le trafic réseau. Elle offre un accès très détaillé aux

couches ISO/OSI spécifiques. De plus, elle est disponible sur plusieurs systèmes d'exploitation (pour plus d'informations, lisez l'article de Kon-rad Malewski Plein contrôle ou accès de bas niveau au réseau du numéro 5/2005 de hakin9) et dans plusieurs langages de programmation.

Marteau, tourne-vis, sniffeur ou outils pour l'analyseSi nous voulons envisager l'analyse réseau, il est impossible de nous débrouiller sans outils qui pourrait nous faciliter la tâche. Commen-çons par les sniffeurs.

EtherealEthereal est l'un des outils le plus connu servant à analyser les réseaux. Il possède beaucoup d'options très utiles pour l'analyse. Les deux caractéristiques dominantes de ce projets sont : l'enregistrement du trafic réseau sous différents formats et l'interface graphique. Bien que nous n'avions pas besoin directement de la seconde caractéristique pour l'analyse, elle est un complé-ment très agréable et facilite le travail.

TcpdumpTcpdump est encore un très bon sniffeur. Ce sont ses auteurs qui ont conçu la bibliothè-que Pcap. Le programme possède quelques front-end non officiels, mais il a été conçu spécialement pour être utilisé directement à partir de la ligne de commande (shell) du système.

Notre armementVoici la liste des programmes et scripts que nous allons utiliser pour l'analyse du trafic réseau :

Analyse du trafic réseau

Bartosz Przybylski

Degré de difficulté

Si vous administrez un réseau quelconque, vous pouvez être sûrs que, tôt ou tard, il deviendra un but d' une attaque. Mais vous êtes capables de l'empêcher. Plusieurs possibilités se présentent : en commençant par la désactivation des services, par les pare-feux jusqu'aux IDS. Mais il se peut que la question la plus importante soit le fait de savoir distinguer les bons paquets des mauvais.

Cet article explique...• Comment analyser le trafic réseau.• Comment détecter les tentatives d'attaque

grâce à l'analyse.• Comment bloquer ces tentatives.

Ce qu'il faut savoir...• Les notions de base du fonctionnent des ré-

seaux (ISO/OSI).• Utiliser le shell de Linux.

Analyse du trafic réseau

hakin9 Nº 4/2006www.hakin9.org 47

• capinfos (une partie du paquet ethereal),

• tcpdstat,• zonk.pl (un simple script pour

les administrateurs des réseaux – écrit par l'auteur du présent article),

• quelques propres scripts.

Garantie d'authenticitéSi les résultats de l'analyse effectuée doivent nous servir de pièce de con-viction contre l'intrus, il est important de prouver l'authenticité du fichier avec le trafic réseau enregistré et du fichier sur lequel basait notre analyse.

Il est important que le fichier originale servant de pièce de convic-tion principal ait la date de création la plus proche de l'intrusion. Pour l'assurer, il faut copier le fichier avec le trafic dans un répertoire à part et

affecter au fichier et au répertoire les droits en lecture seule (read-only). Pour ce faire, tapez :

mkdir ~/analyze

cp ./traffic.cap ~/analyze

chmod 444 ~/analyze/traffic.cap

~/analyze/

Si la copie est sûre, il faut encore prouver son authenticité. C'est le script du Listing 1 qui nous aidera à le faire.

Ce script peut s'avérer utile pour démontrer l'authenticité du trafic intercepté. Il est aussi conseillé de garder les sommes de contrôle pour le fichier original, ce qui sera encore plus convaincant.

Analyse réseauPassons maintenant à notre tâche principale, c'est-à-dire à l'analyse

du trafic intercepté. Pour pouvoir ef-fectuer l'analyse, il faut collecter des informations de base concernant le trafic intercepté. Pour cela, nous allons utiliser le programme capinfo qui est un composant du paquet ethereal.

Consultons le Listing 2 pour sa-voir quels types d'informations nous pouvons obtenir grâce à capinfo.

La première ligne (File name) n'est pas importante, elle contient le nom du fichier. La deuxième con-tient l'information sur le format du fichier. Dans ce cas, c'est un fichier au format pcap. Un autre système d'enregistrement du trafic réseau très populaire est Microsoft Network Monitor x.x, x.x étant la version de la bibliothèque. La version la plus utilisée est la version 2.x (bien sûr, ce ne sont pas seulement les formats d'enregistrement des fichiers de tra-fic réseau).

La ligne suivante (3) affiche le nombre de paquets qui ont passés à travers notre réseau lors du snif-fing. Ensuite vient (4) la taille du fichier et (5) la taille des données du trafic enregistré. Après, nous avons respectivement : (6) la durée exacte de l'interception, (7) la date du début et (8) de la fin du sniffing, (9) le flux de données moyen en octets/s et (10) en bits/s, par contre la dernière ligne (11) montre la taille moyenne du paquet.

À cette étape de l'analyse, nous pouvons déjà tirer certaines con-clusions concernant le trafic non autorisé éventuel (il s'agit avant tout de grandes entreprises). Si dans un petit lap de temps (la valeur Capture duration n'est pas élevée), nous ob-servons un nombre important de pa-quets ou la taille moyenne du paquet est grande, nous pouvons soupçon-ner que les programmes supportant le téléchargement via Internet sont utilisés dans notre réseau. Pourtant, ce n'est pas toujours vrai car un tel trafic peut être dû au téléchargement des mises à jour des programmes.

Le pas suivant consiste à la re-connaissance plus précise du trafic, cette fois-ci au niveau des paquets. Ce qui nous intéresse, ce sont le

Listing 1. La vérification d'authenticité de deux fichiers (aut.sh)

#!/bin/sh

if [ -z $2 ]; then

echo "Usage: $0 authentic_file file_for_check";

exit

if

md5sum $1 | cut -c1-32 > /tmp/f1.cksum

md5sum $2 | cut -c1-32 > /tmp/f2.cksum

sha1sum $1 | cut -c1-40 >> /tmp/f1.cksum

sha1sum $2 | cut -c1-40 >> /tmp/f2.cksum

res=`/usr/bin/cmp /tmp/f1.cksum /tmp/f2.cksum`

if [ -z "$res" ]; then

echo "File is authentic"

else

echo "File is not authentic"

fi

rm /tmp/f1.cksum /tmp/f2.cksum

Listing 2. La sortie du programme capinfo

$ capinfo traffic.cap

1 File name: traffic.cap

2 File type: libpcap (tcpdump, Ethereal, etc.)

3 Number of packets: 1194

4 File size: 93506 bytes

5 Data size: 213308 bytes

6 Capture duration: 342.141581 seconds

7 Start time: Thu Jun 23 14:55:18 2005

8 End time: Thu Jun 23 15:01:01 2005

9 Data rate: 623.45 bytes/s

10 Data rate: 4987.60 bits/s

11 Average packet size: 178.65 bytes

hakin9 Nº 4/2006 www.hakin9.org

Fiche technique

48

type de protocole et la taille du pa-quet. Nous prendrons également connaissance plus précisément de la caractéristique du chargement de la connexion. Pour cela, nous nous servirons du programme de Dave Dittrich tcpdstat, avec modifications. Le Listing 3 nous servira de base.

Nous pouvons lire les données de base identiques à celles obtenues auparavant au moyen du programme capinfos. Mais cette fois-ci, nous disposons du plus grand nombre d'informations. Il s'agit ici du nombre de paquets dans une plage de tailles donnée, et des informations plus pré-cises sur les protocoles du trafic (ces informations sont disponibles sous le titre Protocol Breakdown). Les lignes successives ont été enregistrées au format suivant :

[niveau du protocole] protocole

nombre_de_paquets (pourcentage_de_tous_

les_paquets) nombre_d'octets

pourcentage_de_tout) nombre_moyen_

d'octets_par_paquet

Grâce à ces informations, nous pouvons vérifier quels paquets des familles de protocoles données traversent notre réseau. Il faut faire attention à ce fait car à partir des protocoles présents, il est possible de déduire si notre réseau n'est pas le but d'une analyse distante ou d'une attaque.

Il faut faire attention au grand nombre de paquets TCP. À moins que les informations sur les pa-quets HTTP ne suscitent pas notre inquiétude (à condition que ce ne soit pas une exploitation abusive de nos applications PHP), nous devons réfléchir ce qui peut être la source d'un tel trafic des autres paquets TCP (other). C'est un trafic défini dans pcap à partir de la couche ré-seau, mais il n'est pas défini suivant les ports. Le plus souvent, c'est un trafic output, mais pas toujours. Cela peut être également une tentative de scannage de notre système.

Une autre information transmise par tcpdstat est, entre autres, dix chargements du réseaux les plus importants. Mais ces informations

sont indispensables seulement pour la création des données statistiques.

Maintenant, quand nous avons des informations sur les paquets et les protocoles, il faudrait savoir plus sur les expéditeurs et les destinataires des paquets. Pour cela, nous disposons d'un simple script du Listing 4.

Ce script affiche à la sortie les adresses IP des paquets traversant notre station (il faut se rendre compte que ce ne sont que les adresses sources). À partir de ces informa-tions, nous pouvons préparer les règles de refus ou d'acception d'une IP donnée pour le pare-feu. Il faut vé-

rifier si aucune adresse n'appartient à bogone space.

Si c'est le cas, cela veut dire qu'une attaque DDoS non réussie a eu lieu dans notre réseau. Dans ce cas, il faudrait utiliser (pour quelques jours) le script qui bloquera dans le pare-feu les adresses bogone (ce script est disponible sur le site http://completewhois.com/).

Une petite modification dans searchip peut nous fournir des in-formations sur les adresses MAC des interfaces à partir desquelles proviennent les paquets analysés. Mais cela n'est pas nécessaire car

Listing 3. La sortie du programme tcpdstat

DumpFile: traffic.cap

FileSize: 0.09MB

Id: 200506231455

StartTime: Thu Jun 23 14:55:18 2005

EndTime: Thu Jun 23 15:01:01 2005

TotalTime: 342.14 seconds

TotalCapSize: 0.07MB CapLen: 68 bytes

# of packets: 1194 (208.31KB)

AvgRate: 5.08Kbps stddev:30.22K

### IP flow (unique src/dst pair) Information ###

# of flows: 66 (avg. 18.09 pkts/flow)

Top 10 big flow size (bytes/total in %):

20.0% 16.3% 15.7% 12.9% 4.8% 4.0% 2.9% 1.3% 1.3% 1.2%

### IP address Information ###

# of IPv4 addresses: 68

Top 10 bandwidth usage (bytes/total in %):

69.9% 21.5% 18.5% 17.5% 16.9% 13.9% 5.4% 5.2% 4.5% 4.3%

# of IPv6 addresses: 4

Top 10 bandwidth usage (bytes/total in %):

81.5% 59.2% 40.8% 18.5%

### Packet Size Distribution (including MAC headers) ###

<<<<

[ 32- 63]: 857

[ 64- 127]: 104

[ 128- 255]: 79

[ 256- 511]: 61

[ 512- 1023]: 14

[ 1024- 2047]: 79

### Protocol Breakdown ###

<<<<

protocol packets bytes bytes/pkt

------------------------------------------------

[0] total 1194 (100.00%) 213308 (100.00%) 178.65

[1] ip 988 ( 82.75%) 198381 ( 93.00%) 200.79

[2] tcp 884 ( 74.04%) 180408 ( 84.58%) 204.08

[3] http(s) 219 ( 18.34%) 124825 ( 58.52%) 569.98

[3] other 665 ( 55.70%) 55583 ( 26.06%) 83.58

[2] udp 94 ( 7.87%) 17247 ( 8.09%) 183.48

[3] dns 9 ( 0.75%) 2752 ( 1.29%) 305.78

[3] other 85 ( 7.12%) 14495 ( 6.80%) 170.53

[2] icmp 7 ( 0.59%) 546 ( 0.26%) 78.00

[2] igmp 3 ( 0.25%) 180 ( 0.08%) 60.00

[1] ip6 5 ( 0.42%) 422 ( 0.20%) 84.40

[2] icmp6 5 ( 0.42%) 422 ( 0.20%) 84.40

Analyse du trafic réseau

hakin9 Nº 4/2006www.hakin9.org 49

nous analysons le trafic provenant d'Internet et pas celui provenant du réseau local.

S'il s'agit des attaques DoS et DDoS, c'est un sujet très vaste et ils exigent un article à part. Dans le numéro 5/2004 du hakin9, Andrzej Nowak et Tomasz Potęga présentent comment se protéger contre les atta-ques de ce type.

Il faut ajouter que le blocage des attaques DDoS qui ont déjà eues lieu n'a pas de sens car les intrus uti-liseront sans doute une autre plage d'adresses.

HTTP, FTP – analyse des informationsPosons-nous des questions sui-vantes : sommes-nous capables d'empêcher une analyse détaillée de notre serveur Web et de prévenir les conséquences de cette opération ? sommes-nous capables de prévenir l'utilisation de notre serveur ftp pour le scannage des ports ? La réponse est oui, mais ce n'est pas si simple que ça. Si nous le faisons manuel-lement, cela prend beaucoup de temps. Effectuons un fragment d'une telle analyse pour voir comment elle est fastidieuse.

Ouvrons le fichier avec le trafic réseau enregistré à l'aide du paquet ethereal (nous l'utilisons pour son interface graphique). Nous choisis-sons l'un des paquets commençant le téléchargement des documents à partir du Web (le paquet dans son contenu doit posséder la phrase GET ou HEAD).

L'exemple de ce paquet est présenté sur la Figure 1. On voit

que chaque bonne connexion pos-sède des informations transmises automatiquement par le navigateur. Ce sont, par exemple : le type et la

version du navigateur (User-agent), le type de fichiers accepté (Accept), le codage (Accept-Encoding), la langue préférée (Accept-Language).

Bogon spaceEn bref, bogon space est une zone d'adressage dans Internet à laquelle aucun possesseur n'a été affecté. Les paquets provenant de ces adresses doivent être considérés comme incor-rects et éliminés. La liste de bogon cou-rante est disponible à l'adresse http://completewhois.com/.

Vous trouverez les informations plus détaillées sur bogon space et bo-gon packets dans hakin9 n° 5/2005.

Listing 4. Le script servant à rechercher différentes ip du fichier pcap (searchip.pl)

#!/usr/bin/perl

use Switch;use Net::Pcap;

my $err;my $rep;my $curr_ip;my @ip_table = ();

sub connread;

if ($ARGV[0] eq "") {

print "Usage: ./search_ip <filename/filepath>";

exit;}

if($pcap = Net::Pcap::open_offline($ARGV[0], \$err)) # ouvrez le fichier{

Net::Pcap::loop($pcap, -1, \&connread, ''); # transférez chaque paquet dans

# la fonction connread

}

else {

print "Error\n";

exit;}

print "Founded different IP:\n";

foreach $ip_table(@ip_table) {

print $ip_table."\n";

}

sub connread # fonction principale

{

my($data, $header, $packet) = @_;my $packet = unpack('H*', $packet);$rep=0;

# recherchez dans le paquet ip

if ($packet =~ m/^\w{44}(..)(..)(\w{4}|\w{8})(..)(..)(..)(..)\ w{8}(....)(....)\w+(.*)/)

{

# enregistrez dans la variable et comparez aux ajoutés

$curr_ip = hex($4).".".hex($5).".".hex($6).".".hex($7);

foreach $ip_table(@ip_table) {

if($ip_table eq $curr_ip){

$rep = 1;

}

}

if ($rep == 0) { # si ce ip n'existe pas encore, ajoutez-le au tableaupush(@ip_table, $curr_ip);

}

}

}

hakin9 Nº 4/2006 www.hakin9.org

Fiche technique

50

De plus, nous pouvons obtenir les informations si la connexion doit être maintenue et pour quel temps et l'ID du témoin de connexion (cookie).

Pratiquement tous les intrus, pendant l'analyse des informations fournies par le serveur (ses pages d'ouverture) ne fournissent pas les données ajoutées par défaut par le navigateur (car le serveur élimine les connexions qui restent inactives pen-dant quelque temps). Nous pouvons exploiter ce fait.

Si, lors de la recherche du trafic, nous retrouvons les en-têtes incom-plètes, nous pouvons soupçonner que notre serveur a été l'objet d'une analyse déjà terminée et que nous devons nous attendre à une attaque. Malheureusement, ou heureuse-ment, ce n'est pas toujours vrai car les navigateurs texte (par exemple Lynx, links) ne laissent pas de car-tes de visite. Une erreur est donc bien possible. Mais ils laissent les informations sur cookies, ce qui les distingue des intrus examinant les pages d'accueil du serveur.

Occupons-nous maintenant du FTP. Si nous donnons accès à un serveur ftp anonyme, il peut être utilisé pour le scannage les ports sur un serveur quelconque. Cela est possible grâce à la commande PORT. Bien sûr, nous pouvons le désactiver, mais ainsi la réalisation des connexions actives avec notre serveur ne sera plus possible. Mais si, pour une raison ou une autre, nous avons besoin des connexions actives, il est conseillé d'effectuer de temps en temps une analyse du trafic ftp sur notre serveur. De même qu'en cas de http, nous pourrions rechercher le trafic pendant des heures et bloquer les adresses IP spécifiques sur le pare-feu, mais nous tenons beaucoup à l'efficacité. Le script fhelp.pl (voir le Listing 5) nous vient à l'aide.

Ce simple script recherche le fichier donné au format pcap, ou travaille directement en recherchant dans les paquets http les cas où il y n'a pas des informations sur le navi-gateur du client. Il analyse également le trafic ftp à la recherche de la com-

Listing 5. Script fhelp.pl

#!/usr/bin/perluse Switch;use Net::Pcap;

my $dev = "eth0"; # interface d'écoutemy $pcap;my $err;my $packet;

sub connread;

if ($ARGV[0] eq "-h") {print "Usage: ./fhelp.pl <filename>\n\r If no filename given will start live capture\n";exit;}# vérifiez s'il y a le nom du fichier, si oui, ouvrez-le,# dans le cas contraire, ouvrez “live capture”if ($ARGV[0] == "") {if($pcap = Net::Pcap::open_live($dev, 2000, 1, 1000, \$err)) {Net::Pcap::loop($pcap, -1, \&connread, '');}else {print "Error\n$err\n";exit;}}else {if($pcap = Net::Pcap::open_offline($ARGV[0], \$err)) {Net::Pcap::loop($pcap, -1, \&connread, '');}else {print "Error\n$err\n";exit;}}

sub connread {my ($data, $header, $packet) = @_; $get = "n";my $packet = unpack('H*', $packet); # chargez et décompactez le paquet# recherchez les connexions avec les ports 80 et 21if ($packet =~ m/^\w{44}(..)(06)(\w{4}|\w{8})(..)(..)(..)(..)\w{8}(....)(005 0|0015)(.*)/) {$curr_ip = sprintf("%d.%d.%d.%d", hex($4), hex($5), hex($6), hex($7)); $traffic = sprintf("%s",$10);

# recherchez les paquets http incompletsif ($traffic =~ /(474554|48454144)/) {if (!($traffic =~ m/^(.*)\w(20485454502f312e(31|30)0d0a)(.*)(557365722d416765 6e743a)(.*)/)) {print "incomplete http header from $curr_ip\n";print "do you want to block ip $curr_ip on iptables? [y/N]: ";$get = <>;if (($get eq "y")|($get eq "Y")) {system("iptables -A INPUT -p tcp -s $curr_ip -j DROP");}}}# recherchez les commandes port dans les paquets ftpif ($traffic =~ /(706f7274|504f5254)/) {print "PORT command used in ftp connection from $curr_ip\n";print "do you want to block ip $curr_ip on iptables? [y/N]: ";$get = <>;if (($get eq "y")|($get eq "Y")) {system("iptables -A INPUT -p tcp -s $curr_ip -j DROP");}}}}

Analyse du trafic réseau

hakin9 Nº 4/2006www.hakin9.org 51

mande PORT. S'il retrouve ce type de trafic, il demande à l'utilisateur s'il veut bloquer une adresse IP appro-priée dans le pare-feu (il ne coopère qu'avec iptables). Il est évident que le script doit être démarré en root.

SSL – le talon d'AchilleChaque personne qui effectue des analyses réseau, tôt ou tard, se heurte à un trafic chiffré. C'est le principal problème de la plupart des analyses.

Il est possible de déchiffrer ce trafic, mais la pratique montre que cela ne sert à rien. Premièrement, dans 999 cas sur 1000 c'est un trafic autorisé. Deuxièmement, le déchif-frage des paquets prend beaucoup de temps car il faut trouver la clé de séquence pour chaque transmission. Si nous réfléchissons un peu plus à la question de ce type de transmis-sion, nous pouvons constater que la seule solution raisonnable est de permettre les connexions chiffrées uniquement aux hôtes de confiance. Hélas, cette solution n'est pas bonne si notre serveur doit être accessible au public et offrir aux clients des ser-vices deconnexions chiffrées.

Employés paresseuxMaintenant, il est temps de parler du script écrit en Perl – zonk.pl (par l'auteur de cet article).

Cette simple application basée sur les expressions conditionnelles et la bibliothèque pcap recherche dans le trafic réseau courant de sim-ples abus de la connexion (le trafic p2p, im, irc). Pour cela, elle utilise les numéros des ports des serveurs exploités par les transmissions in-terdites. Ce script peut s'avérer fort utile pour les administrateurs des réseaux d'entreprises et leurs aider

à rechercher et à éliminer l'utilisa-tion abusive des ressources par les employés au sein d'une entreprise. Zonk, et d'autres scripts mentionnés dans l'article, sont disponibles sur la page de l'auteur (Encadré Sur Inter-net). Vous y trouverez aussi d'autres outils indispensables pour les admi-nistrateurs.

Pourquoi tout cela ?Tenant compte des limitations pré-sentées dans l'article, nous pouvons nous poser la question s'il vaut la peine d'effectuer l'analyse du trafic dans notre réseau ?

Certainement, elle n'est pas le remède à tous nos problèmes, mais les informations obtenues à la suite d'une bonne et due analyse sont très précieuses. Ainsi, nous sommes capables de détecter les attaques brute force, DoS et DDoS, le trafic p2p et im et l'utilisation abusive des connexions http.

Bien sûr, le plus difficile détermi-ner ce bon et dû temps quand il faut effectuer l'analyse. C'est pourquoi, il est recommandé de l'effectuer ré-gulièrement et utiliser les scripts qui seront capables de détecter automa-tiquement les anomalies importan-tes. N'oubliez pas que l'élément le plus important de l'analyse effectuée n'est pas la collecte des données, mais l'interprétation appropriée du trafic intercepté.

Il faut aussi être conscient qu'après l'exploitation de tous les scripts et outils, il faudrait consulter de nouveau tout le trafic pour dé-tecter les anomalies plus détaillées, mais chaque analyseur réseau de-vrait s'en rendre compte. l

Sur Internet• http://www.ethereal.com/ – le site du projet du sniffeur ethereal,• http://www.tcpdump.org/ – le site de libpcap et tcpdump,• http://www.netfilter.org/ – le site du projet iptables.• ftp://tracer.csl.sony.co.jp/pub/mawi/tools/ – à partir de ce site, vous pouvez télé-

charger tcpdstat• http://aqu.banda.pl/scripts/network_analyzing/ – à partir de ce site, vous pouvez

télécharger zonk.pl

www.hakin9.orghakin9 Nº 4/200652

Pratique

Pour atteindre ces buts, une analyse très détaillée du fonctionnement des logiciels malveillants est nécessaire ; c'est l'ingé-

nierie inverse qui entre ici en jeu.Les concepteurs des programmes malveillants (virus, troyens, rootkits) essaient de rendre cette analyse extrê-mement difficile, par exemple à l'aide des techni-ques empêchant le déboguage, des techniques polymorphiques, des techniques stealth ou des programmes pour la compression des fichiers ; ces derniers non seulement réduisent la taille des fichiers exécutables, mais aussi ajoute une cou-che protectrice plus ou moins complexe.

Dans ces situations, c'est le temps qui compte avant tout : grâce à une analyse longue et précise, tôt ou tard, nous atteindrons notre but et pourrons connaître tous les détails du danger. Hélas, il arrive que nous n'avons pas assez de temps et dans ce cas il faut optimiser les opérations liées aux procédures de l'ana-lyse. Imaginez un ver exploitant une erreur inconnue d'un programme qui lui permet de se répandre via Internet. Le temps investi dans l'analyse et la compréhension du fonctionne-ment de ce ver marque la limite entre la vrai catastrophe des utilisateurs et le danger réduit et neutralisé.

De cela, nous prendre des mesures suffi-santes pour résoudre chaque type de problè-mes auxquels nous pouvons nous heurter.

HookingComme on peut remarquer, il existe beaucoup d'astuces qui ont pour but de rendre difficile l'utilisation du débogueur (aussi bien au niveau Ring0 que Ring3) qui est un principal outil dans l'ingénierie inverse. De cela, il est nécessaire

Construction d'un désassembleur de taille orienté HookingRubén Santamarta

Degré de difficulté

Jour après jour, les chercheurs des programmes malveillants, les analystes juridiques ou les administrateurs doivent faire face aux dangers menaçant la sécurité des systèmes informatiques. Leur objectif est d'expliquer les intrusions non autorisées, de protéger les utilisateurs contre les virus ou de protéger les systèmes contre différents dangers.

Cet article explique...• Comment utiliser hooking pour l'analyse des

programmes malveillants (malware).• Comment exploiter Structure Exception Han-

dling pour la création d'un désassembleur de taille.

Ce qu'il faut savoir...• Connaître Assembleur x86 y C.• Connaître Win32 Api et Structure Exception

Handling.• Avoir les notions de base des techniques utili-

sées par les logiciels malveillants et les virus.

Reconnaître l'adversaire

hakin9 Nº 4/2006www.hakin9.org 53

d'élaborer une méthode qui, dans les conditions appropriées, permet-trait d'influencer le comportement du fichier exécutable analysé et le modifier.

L'une des techniques les plus utilisées servant à atteindre ce but est hooking.

On peut distinguer différentes techniques d'accrochage en fonction de l'endroit où il a lieu. Chaque type est destiné à d'autres applications. Ainsi, on obtient les types suivants :

• Inline Hooking, • Import Address Table hooking, • System Service Table hooking

(Ring0),• Interrupt Descriptor Table hoo-

king (Ring0),• IRP hooking (Ring0),• Filter drivers (NDIS,IFS...Ring0).

Dans notre cas, nous allons utiliser la méthode Inline Hooking. Nous l'employons parce qu'elle permet Nous utilisons cette technique parce qu'elle permet de retoucher la fonc-tion à intercepter quand elle est char-gée dans la mémoire. Ainsi, nous ne devons pas nous soucier de quel en-droit proviennent les appels ou com-bien de fois ils ont eu lieu, mais nous attaquons directement le noyau. Un appel quelconque de la fonction sera intercepté par notre crochet.

Interception et modification du flux de codeAdmettons que nous voulons inter-cepter tous les appels API Close-Handle qui se produisent lors du démarrage du programme. L'API se trouve dans kernel32.dll, donnons un coup d'œil sur ses premières instructions :

01 8BFF mov edi,edi

02 55 push ebp

03 8BEC mov ebp,esp

04 64A118000000 mov eax,fs:[00000018]

05 8B4830 mov ecx,[eax][30]

06 8B4508 mov eax,[ebp][08]

Ce bloc du code présente les pre-miers octets du point d'entrée Clo-seHandle, ce qui signifie que chaque

Techniques utilisées contre désassembleurs et débogueursPendant des années, les concepteurs des programmes malveillants, les auteurs des virus ou même les développeurs des programmes commerciaux, dotaient leur programmes des méthodes anti-debug et anti-disasm. La plupart d'elles sont destinées à détecter si un programme donné est suivi par un débogueur. Si c'est le cas, le programme peut entreprendre différentes actions, en commençant par l'arrêt immédiat du démarrage et en terminant par le redémarrage de l'ordinateur ou même par des opérations plus agressive, ce qui, heureusement, est peu po-pulaire.

• Une très vielle astuce utilisée pour détecter la présence de SoftIce, le débogueur Ring0 le plus connu, employé dans le monde entier dans l'ingénierie inverse, était une tentative d'accéder aux mécanismes créés par l'un de ses pilotes - NtIce.

• L'instruction RDTSC dans l'assembleur x86 : un mnémonique de Read Time−Stamp Counter. Cette instruction stocke dans EDX:EAX (64 bits) la valeur timestamp du processeur. Imaginons que RDTSC est lancée au début du bloc du code, et la valeur retournée est stockée. À la fin de ce bloc du code, nous lançons encore une fois RDTSC et soustrayons la valeur obtenue de la valeur stockée. Quand le programme est démarré de façon ordinaire, le résultat de cette opération aura les valeurs rationnelles, en tenant bien sûr compte de la vitesse et de l'utilisation du processeur. Mais si nous nettoyons ce bloc du code, l'incrément de timestamp entre deux lecture sera très élevé par rapport à celui trouvé dans le débogueur.

• La manipulation des interruptions pour modifier le flux du code. Une possibilité très puissante de l'architecture Win32 est la fonction Structure Exception Handling (SEH) qui permet de déterminer les schémas de la fonction callback pour contrôler les exceptions. Vu que les débogueurs s'occupent de toutes les exceptions ayant lieu lors du fonctionnement du programme, les procédures définies par le pro-grammeur pour la gestion des exceptions ne seront jamais utilisées. Admettons que nous avons basé le flux de notre programme sur la procédure de ce type. Si après une génération expresse de l'exception (par exemple, au moyen de xor eax,eax, et ensuite mov [eax],eax ), nous ne parvenons pas à l'espace du code admis, nous sommes probablement sous la surveillance d'un débogueur.

• Autres astuces, moins élaborées, basés sur les propriétés spécifiques de chaque débogueur : les tentatives de retrouver certains types ou titres de fenêtres enregis-trés par le programme ou bien des clés dans le registre de Windows qui pourraient le dévoiler.

Figure 1. Le schéma de base d'Inline Hooking

hakin9 Nº 4/2006 www.hakin9.org

Pratique

54

appel de la fonction démarrera sans doute le code précédent. En nous servant du schéma d'Inline Hooking, nous remplacerons ces premières instructions par notre propre crochet qui modifiera le flux normal de la fonction dans la direction du filtre.

Différentes possibilités pour le même objectifIl existe différentes méthodes de chan-gement du flux dans la direction du notre code. La plus simple consiste à changer les premiers octets de Close-Handle par un saut inconditionnel.

01 E9732FADDE jmp 0DEADBEEF

02 64A118000000 mov eax,fs:[00000018]

Nous avons remplacé 5 premiers octets par un saut vers l'adresse 0xDEADBEEF. Bien sûr, cette adresse n'est pas valide car nous travaillons en mode utilisateur. À cette adresse, il y aurait le code que nous avons introduit dans l'espa-ce adressable du fichier exécutable.

Vu que c'est la méthode la plus simple, elle est aussi la plus facile

à détecter parce qu'il est suspect si le point d'entrée d'une fonction système contient le saut inconditionnel vers une autre adresse dans la mémoire. Nous pouvons utiliser une autre option étant la combinaison de PUSH + RET .

01 68EFBEADDE push 0DEADBEEF

02 C3 retn

03 A118000000 mov eax,[00000018]

Dans ce cas, nous remplaçons les 6 premiers octets. Si nous regar-dons ce fragment avec attention, nous constatons que le code origi-nal CloseHandle est effectivement changé, mais non du point de vue des instructions ajoutées, mais aussi certaines d'entre elles sont perdues et d'autres ont changé. C'est une question à discuter. Bien que nous avions atteint notre objectif et inter-cepté tous les appels de la fonction, la modification étaient si importante qu'elle a entraîné les anomalies du comportement, ce qui en résultat pourrait provoquer la fin inattendue du programme pendant le premier appel CloseHandle.

C'est pourquoi, il faut développer une technique le moins agressive envers le code source qui permet-trait à la fonction accrochée de fonc-tionner normalement tout en restant constamment sous contrôle. Cette technique est appelée Detour (elle a été présenté par Galen Hunt et Doug Brubacher des laboratoires Microsoft)

DetourPar rapport à Inline hooking, la technique Detour implémente deux nouvelles conceptions : la fonction Detour et la fonction Trampoline.

• Fonction Detour doit se compo-ser d'une partie dans laquelle sont réalisées les premières opérations sur les données ob-tenues, ensuite vient l'appel à la fonction Trampoline et à la fin, se trouve la partie du code qui sera lancé après la terminaison de la fonction Trampoline.

• Fonction Trampoline contient aussi bien les instructions de la fonction cible, remplacées complètement par le saut inconditionnel, que celles qui ont été changées par-tiellement. Ensuite, il y a un saut à l'instruction suivante correspon-dant à la fonction cible.

Ainsi, nous pouvons résoudre le problème lié aux données perdues ou aux instructions modifiées qui se produisait dans Inline Hooking. Il s'agit de sauver ces instructions dans la fonction Trampoline pour qu'elles puissent être exécutées. En-suite, nous sautons à une instruction suivante où la fonction cible fonction-nera normalement. Une fois la fonc-tion cible terminée, nous reprenons le contrôle sur la fin de la fonction Detour. Elle est capable de récupérer le chemin de démarrage en restau-rant le contrôle de la fonction source ou la possibilité de réaliser un autre type d'opération.

Mais comment savoir combien d'instructions faut-il copier dans la fonction Trampoline à partir de la fonction cible ? Chaque fonction cible sera différente, et de cela il Figure 2. Le schéma de base de la technique Detour

Tableau 1. Les données disponibles pour la gestion des exceptions, si celle-ci est active

T DonnéesESP+4 Pointeur à la structure

EXCEPTION_RECORDESP+8 Pointeur à la structure ERRESP+C Pointeur à la structure

CONTEXT_RECORD

Reconnaître l'adversaire

hakin9 Nº 4/2006www.hakin9.org 55

sera impossible de copier le nombre d'octets déterminé car les instruc-tions pourraient être coupées. Ce problème est résolu à l'aide du dé-sassembleur de taille.

Désassembleurs de tailleLes désassembleurs de taille diffè-rent des désassembleurs ordinai-res par leur fonction qui consiste à obtenir la taille des instruction et pas leur présentation. Ce type de désassembleurs était utilisé par les virus cavités, polymorphiques, etc. C'est pourquoi, les deux des désas-sembleurs de taille (les vraie perles de l'optimisation) les plus utilisés ont été programmés par les concepteurs des virus connus : Zombie et RGB.

Ils sont basés sur un désassem-balge statique des instructions. Pour cela, ils utilisent les tableaux des co-des des opérations de l'architecture sur laquelle ils fonctionnent, dans ce cas x86.

Outre le fait qu'ils sont utilisés pour la création des virus comple-xes, on l'emploie aussi pour le hoo-king car ils permettent de résoudre

le problème dont nous avons parlé auparavant.

À partir du potentiel de Structure Exception Handling, nous explique-rons la technique innovatrice de la création des désassembleurs dyna-miques de taille. Au boulot.

Utilisation de Structure Exception Handling (SEH)Premièrement, nous devons nous concentrer sur les caractéristiques du problème auquel nous voulons trouver la solution.

• Les premières instructions des fonctions cibles ne diffèrent pas trop, mais les différences sont aussi importantes qu'il est né-cessaire d'envisager chaque cas séparément.

• Le saut inconditionnel (jmp) ou Push + ret n'occupent pas plus de 6 octets. Il faudra analyser de 4 à 5 instructions au maximum.

• Les premières instructions exécu-tent généralement les opérations liées à l'ajustement de la pile.

• L'idée consiste à pouvoir lancer ces premières instructions dans l'environnement contrôlé, ce qui nous permettra de calculer leur longueur.

Pour savoir comment construire cet environnement, il faut saisir les infor-mations apportées par SEH.

Pour chaque exception que a eu lieu dans le code protégé par la fonc-

tion SEH définie pour le thread, la gestion définie dispose des données suivantes.

Si une exception se produit, le système démarre la gestion des exceptions pour qu'elle décide des actions ultérieures. À ce moment esp pointe vers différentes structures.

Dans la structure EXCEPTION_RECORD, l'attention est attirée sur les champs ExceptionCode et Ex-ceptionAddress :

• ExceptionCode identifie le type de l'exception créée. Dans le système, différents codes sont définis pour chaque type ; de plus, il est possible de définir nos propres codes pour person-naliser les exceptions via API RaiseException.

• ExceptionAddress est une adresse de la mémoire appartenant à l'ins-truction créée par une exception ; elle correspondrait au registre eip au moment où une exception s'est produit.

Une autre structure de base qu'il faut connaître est CONTEXT. Cette structure contiendra toutes les va-leurs des registres au moment où l'exception se produit.

Il ne faut pas oublier que c'est la possibilité de contrôler chaque instruc-tion démarrée est la plus importante, comme cela se fait dans le débogueur. En fait, notre désassembleur aura tou-tes les fonctionnalités du débogueur.

Programmation du désassembleur de taillePremièrement, il faut définir l'en-vironnement dans lequel nous dé-marrerons les fonctions surveillées ; ainsi, nous appellerons les instruc-tions appartenant à la fonction cible dont la longueur nous voudrons connaître, pour pouvoir ensuite les copier entièrement dans la fonction Trampoline.

Pour cela, premièrement il faut déterminer l'étendue de SEH, SEH_SEHUK étant une routine gérant les exceptions qui se produisent.

Tableau 2. Champs de la structure EXCEPTION_RECORD

Offset Données

+ 0 ExceptionCode+ 4 ExceptionFlag+ 8 NestedExceptionRecord+ C ExceptionAddress+ 10 NumberParameters+ 14 AdditionalData

Codes des exceptionsUne exception due à un accès à la zone de la mémoire invalide et une exception pro-duite à la suite de l'opération de division par 0 ne peuvent pas être traitées de la même façon. Le système identifie chaque situation pour faciliter la tâche de la gestion des exceptions. Les codes des exceptions les plus répandues sont :

• C0000005h – Violation des droits d'accès aux opérations de lecture ou d'écriture.• C0000017h – Pas de mémoire libre.• C00000FDh – Stack Overflow.

Les codes suivants sont les plus importants pour notre projet :

• 80000003h – Breakpoint généré par l'instruction int 3.• 80000004h – Single step généré par l'activation de Trap Flag dans le registre

EFLAGS.

hakin9 Nº 4/2006 www.hakin9.org

Pratique

56

01 push dword SEH_SEHUK

02 push dword [fs:0]

03 mov [fs:0], esp

Dès ce moment, tout le code dé-marré après ces instructions sera protégé. L'étape suivante consiste à copier un nombre déterminé d'oc-tets qui contiendront les instructions surveillées, à partir de la fonction cible vers la zone réservée à l'inté-rieur de notre code. Sa taille peut changer. Dans notre cas, nous avons choisi 010h car elle est assez large pour contenir en entier les premières instructions.

04..mov esi,TargetFunction

05 mov..edi,Code

06..push 010h

07 pop ecx

08..rep movsb

Quand nous sommes arrivés à ce point, il ne nous reste qu'une seule étape avant de démarrer les instruc-tions surveillées. Voyons :

09 int 3

10 Code:

11 ModCode times 12h db (90h)

ModCode est la zone dans laquelle nous avons copié les instructions surveillées ; avant d'arriver à ce point, nous avons mis la constante int 3. Pourquoi ? Il y en plusieurs raisons :

• Comme nous l'avons déjà men-tionné, les premières instructions d'une fonction cible quelconque réalisent d'habitude les opérations de modification de la pile. De cela, il faut s'assurer que notre pile ne sera pas détruite par ces actions. Après l'appel d'int 3, une excep-tion qui nous permettra d'accéder à SEH_SEHUK (notre gestion), est générée. Ainsi, en accédant à la structure CONTEXT, nous sauvons les registres ESP et EBP pour restaurer l'état de notre pile aux valeurs précédentes après la terminaison de l'analyse.

• L'activation de Trap Flag dans le registre EFLAGS. Grâce à cette

interruption, après le démarrage de l'instruction suivante, l'excep-tion Single Step sera automatique-ment générée. Ainsi, le contrôle est restauré. Nous avons obtenu la même information qu'à la suite des opérations effectuées pas à pas.

Consultons ces points créés dans le code de l'assembleur :

12 SEH_SEHUK:

13 mov esi, [esp + 4]

; EXCEPTION_RECORD

14 mov eax, [esi]

; ExceptionCode

15 test al, 03h

; Int3 Exception Code

16 mov eax, [esi + 0Ch]

; Eip Exception

17 mov esi, [esp + 0Ch]

; CONTEXT record

18 mov edx, [esi + 0C4h]

; Esp Exception

19 jz Int1h

20 mov eax, [esi + 0B4h]

; Ebp Exception

21 mov [OrigEbp], eax

22 mov [OrigEsp], edx

2 inc dword [esi + 0B8h]

; Eip++ (Int3->Instruction suivante)

24 mov eax,Code

25 mov [PrevEip],eax

26 jmp RetSEH

On voit que dans la ligne 15, nous comparons al avec 03 pour savoir si l'exception a été produite par int 3

(code de l'exception 80000003h), ou au contraire, il s'agit d'une exception provoquée par Trap Flag ou un autre évènement. S'il s'agit de l'exception BreakPoint, nous effectuerons les opérations expliquées auparavant (lignes 20, 21, 22).

Il est nécessaire de modifier EIP du contexte pour qu'au moment de la restauration du contrôle dans le sys-tème, il pointe vers l'instruction qui vient après int 3, autrement, nous serions dans une situations sans is-sue. Pour éviter cela, comme on voit dans la ligne 23, nous incrémentons la valeur d'une unité. Cela est dû au fait que le code de l'opération pour int 3 a 1 octet.

Tableau 3. Le champ CONTEXT appartenant aux registres généraux et de contrôle

Offset Registre+ 9C EDI+ A0 ESI+ A4 EBX+ A8 EDX+ AC ECX+ B0 EAX+ B4 EBP+ B8 EIP+ BC CS+ C0 EFLAGS+ C4 ESP+ C8 SS

Figure 3. Le schéma du fonctionnement de notre désassembleur de taille

Merci de remplir ce bon de commande et de nous le retourner par fax : 0048 22 887 10 10 ou par courrier :Software-Wydawnictwo Sp. z o. o., Piaskowa 3, 01-067 Varsovie, Pologne ; E-mail : abonnement@software.com.pl

Commande

Prénom Nom ..................................................................................... Entreprise .........................................................................................

Adresse ...........................................................................................................................................................................................................

Code postal ...................................................................................... Ville ...................................................................................................

Téléphone ......................................................................................... Fax ....................................................................................................

E-mail ................................................................................................

Je règle par :

¨ Carte bancaire n° CB expire le date et signature obligatoires type de carte .......................................................................... code CVV/CVC¨ Virement bancaire : Nom banque : Société Générale Chasse/Rhônebanque guichet numéro de compte clé Rib30003 01353 00028010183 90

IBAN : FR76 30003 01353 00028010183 90Adresse Swift (Code BIC) : SOGEFRPP

OFFRES DE COUPLAGE

Abonnez – vous !!!

l par courrier en nous renvoyant le bon ci-dessousl par le web, sur notre site : http://buyitpress.com/frl par téléphone entre 10-17 au 00 48 22 887 13 44l par fax au 00 48 22 887 10 11

OUI, je m’abonne et désire profiter des offres spéciales de couplage

Référence de l’offre : Prix : Qté : À partir du numéro :

12 Nos Linux+ DVD + 6 Nos PHP 99 €

12 Nos Linux+ DVD + 6 Nos Hakin9 comment se défendre ? 99 €

12 Nos Linux+ DVD + 6 Nos SDJ Extra 99 €

12 Nos Linux+ DVD + 6 Nos Programmation sous Linux 99 €

99 € 147 €

+

+

+

+

12 Nos 6 Nos

12 Nos 6 Nos

12 Nos 6 Nos

12 Nos 6 Nos

hakin9 Nº 4/2006 www.hakin9.org

Pratique

58

Dans la ligne 25, nous enregis-trons l'adresse de la mémoire où commencent nos instructions sur-veillées, ce qui nous permettra au moment de l'émulation des appels et des sauts conditionnels et incon-ditionnels.

Analyse des instructions surveilléesJusqu'alors, tout ce que nous avons présenté, pourrait être contenu dans le bloc préparation de l'environne-ment. Nous allons commencer à exa-miner le code appartenant à l'analyse des instructions surveillées.

ObjectifLe but de cette partie du code est l'analyse de la longueur des instruc-tions surveillées jusqu'à trouver la valeur supérieure ou égale à celle qui occuperait notre crochet, indé-pendamment du fait, si ce serait un saut inconditionnel (jmp 5 octets) ou push+ ret (6 octets). Imaginons par exemple que le type de notre cro-chet est push+ret et nous essayons d'accrocher CloseHandle. Nous indiquons au désassembleur que notre crochet occupe 6 octets (Hoo-kLength = 6). Il commencera alors à compter la longueur de la première instruction

01 8BFF mov edi,edi

Taille 2 octets. Vu qu'il est inférieure à 6, il continue comme suit

02 55 push ebp

Taille 1 octet +2 octets de l'instruc-tion précédente = 3 octets. Toujours inférieur à 6.

03 8BEC mov ebp,esp

Taille 2 octets +3 octets des précé-dents = 5 octets. On continue

04 64A118000000 mov eax,fs:[00000018]

Taille 6 octets +5 octets des précé-dents = 11 octets. C'est déjà fait !

Notre désassembleur de taille retournera 11. Que cela signifie-t-il ? Cela veut dire que pour un crochet composé de six octets, pour ne pas perdre aucune instruction, il faut co-pier onze octets de la fonction cible dans la fonction Trampoline.

Analyse des donnéesNous avons ici un bloc initial de l'ana-lyse. Jusqu'à la ligne 46, nous avons l'algorithme permettant d'émuler les appels et les sauts. Cet algorithme consiste à vérifier le décalage entre EIP dans lequel l'exception s'est pro-duite et la valeur précédente du re-gistre. Si ce décalage est important, nous avons à faire avec un appel ou un saut, c'est pourquoi nous passe-rons à la récupération du contexte pour qu'il pointe vers une instruction surveillée suivante au lieu d'exécu-ter le processus jusqu'à l'adresse 4

Listing 1. Observation du code

27 Int1h:

28 mov ecx, eax

29 sub eax, [PrevEip]

30 cmp ax, 10h

31 jb NoCall

32 mov ebx, dword [edx]

33 mov edx,ebx

34 sub ebx, [PrevEip]

35 cmp bl, 7

36 jbe HabemusCall

37 mov edi,[PrevEip]

38 inc edi

39 inc edi

40 mov dword [esi + 0B8h], edi

41 mov ecx,edi

42 jmp NoCall

43 HabemusCall:

44 mov dword [esi + 0B8h], edx

45 mov ecx,edx

46 NoCall:

47 mov [PrevEip], ecx

48 sub ecx, Code

49 cmp ecx, [HookLength]

50 jge Success

51 RetSEH:

52 or word [esi + 0C0h], 0100h

; Activation de Trap Flag

53 xor eax,eax

54 ret

55 Success:

56 mov [LenDasm], ecx

;Nous restaurons la longueur

de l'instruction

57 mov esp, [OrigEsp]

;Nous récupérons Esp

58 mov ebp, [OrigEbp]

; Nous récupérons Ebp

59 pop dword [fs:0]

;Nous nettoyons l'étendue SEH

60 add esp, 4

;Nous ajustons la pile

Figure 4. Le registre EFLAGS

Reconnaître l'adversaire

hakin9 Nº 4/2006www.hakin9.org 59

laquelle pointait l'appel ou le saut. Nous compterons aussi avec notre compteur combien d'octets occupe notre instruction.

Dans les lignes 47, 48, 49, nous vérifions s'il y a suffisamment d'ins-tructions pour mettre notre crocher.

La partie la plus principale du dé-sassembleur sont les lignes 52, 53 et 54. Là, nous activons Trap Flag en configurant à 1 le bit approprié dans le registre EFLAGS. C'est la base pour le nettoyage pas à pas.

À partir de moins de 256 octets, nous avons construit un désassem-bleur de taille tout à fait opérationnel. Maintenant nous pouvons l'appliquer dans la pratique.

Application pratique pour l'analyse d'un programme malveillantOn utilise les techniques differentes :

• Pour nos besoins, nous allons créer un programme qui intro-duira et démarrera du code dans le fichier exécutable qui lui sera passé en paramètre. Les techni-ques d'insertion du code dans les processus sont bien connues. Il en existe différents types, mais toutes sont basées pratiquement sur les mêmes API.

• VirtualAllocEx sert à allouer de la mémoire dans le processus cible. Le code sera introduit dans cet espace mémoire. Pour cela, nous utiliserons WriteProcessMemory.

• Au moment du démarrage du code, nous pouvons choisir parmi CreateRemoteThread ou SetThreadContext.

Mais nous nous servirons d'une autre fonction : QueueUserAPC.

Domaines d'applicationCe programme introduit dans la calculette Windows un petit code qui entraîne l'affichage d'une boîte de message (Message Box). La calculette ne s'affichera pas après le démarrage de ce code. Imaginons qu'au lieu d'un code innocent, nous introduisons un code malicieux d'un

ver. Imaginons aussi que ce petit code était compacté avec le pro-gramme contenant plusieurs types de protections anti-déboguage et anti-désassemblage. Nous devons vite savoir comment il s'infiltre dans un autre fichier exécutable et quel code il introduit. Pour tout cela, il serait nécessaire d'effectuer sur-le-champ le désassemblage du fichier exécutable, mais comme nous l'avions dit, il contient un pro-gramme de compactage (packer) qui

empêche notre analyse et l'utilisation du débogueur. Il ne reste pas aussi longtemps dans la mémoire qu'il soit possible de le décompresser sur le disque dur à l'aide d'un outil de dé-compactage (ProcDump...). En fait, le fichier exécutable ne reste dans la mémoire que pendant des dizaines de secondes empêchant également de capturer son image. Que pou-vons-nous faire ?

Pour résoudre ce problème, on pourrait accrocher ExitProcess, la

Listing 2. ACPInject

#include <stdio.h>

#include <windows.h>

typedef BOOL (WINAPI *PQUEUEAPC)(FARPROC,HANDLE,LPDWORD);int main(int argc, char *argv[]){

PROCESS_INFORMATION strProces;

STARTUPINFOA strStartupProces;

PQUEUEAPC QueueUserApc;

DWORD MessageAddr,Ret1,Ret2,Longueur;

char *szExecutableName;unsigned char Snippet[]= "\x90" /* nop */

"\x6A\x00" /* push NULL */

"\x6A\x00" /* push NULL */

"\x6A\x00" /* push NULL */

"\x6A\x00" /* push NULL */

"\xB9\x00\x00\x00\x00" /* mov ecx,MessageBox*/

"\xFF\xD1" ; /* Call ecx */

Longeur = (DWORD) strlen(

"c:\\windows\\system32\\calc.exe") + 1;

ZeroMemory( &strStartupProces, sizeof( strStartupProces) );strStartupProces.cb = sizeof( strStartupProces );ZeroMemory( &strProces, sizeof( strProces) );szExecutableName = (char*) malloc( sizeof(char) * Długość);if( szExecutableName ) strncpy(szExecutableName,"c:\\windows\\system32\\calc.exe",Longueur);

else exit(0);_QueueUserApc = (PQUEUEAPC)GetProcAddress( GetModuleHandle (

"kernel32.dll" ), "QueueUserAPC");

MessageAddr = (DWORD) GetProcAddress ( LoadLibraryA(

"user32.dll") , "MessageBoxA" );

// U32!MessageBoxA

*( DWORD* )( Snippet + 10 ) = MessageAddr;

Ret1 = CreateProcessA( szExecutableName, NULL, NULL, NULL,

0, CREATE_SUSPENDED,

NULL,NULL,

&strStartupProces,&strProces);

Ret2 = (DWORD) VirtualAllocEx( strProces.hProcess,NULL,sizeof(Snippet), MEM_COMMIT,

PAGE_EXECUTE_READWRITE);

WriteProcessMemory(strProces.hProcess,(LPVOID)Ret2, Snippet,

sizeof(Snippet), NULL); _QueueUserApc((FARPROC)Ret2,strProces.hThread,NULL);

ResumeThread(strProces.hThread);

return 0;}

hakin9 Nº 4/2006 www.hakin9.org

Pratique

60

figer dans la mémoire du processus (à l'aide de Sleep) et le maintenir dans cet état aussi longtemps qu'il soit possible de la capturer et ensui-te reconstruire cette capture binaire pour le désassembler et restaurer à l'état initial. Pourquoi accrocher ExitProcess ? 90% de programme malveillant, après avoir arrivé à ExitProcess est décompressé dans la mémoire. Il peut arriver que seule une partie du fichier exécutable se décompacte, mais cela n'est pas trop fréquent parce que c'est trop difficile à concevoir. Quant à nous, nous nous concentrerons à construire un outil qui nous permettrait de s'accro-cher rapidement à une API d'une dll quelconque utilisée par un program-me malveillant. Pour ce faire, nous allons utiliser bien sûr nous nouveau désassembleur de taille.

En tant que technique de hoo-king, nous utiliserons Inline Hooking avec certains éléments de la techni-que Detour

HookCode contient les éléments étant le prologue de la fonction Detour. La tâche de ce prologue consiste à nous informer que le programme malveillant a atteint ExitProcess par un signal sonore en appelant API Beep. Ensuite, comme nous avions mentionné, nous appellerons Sleep au moyen du paramètre envoyé via la ligne de commande. Ce paramètre sera assez fort pour nous permettre les opérations de capture, ainsi que d'autres que nous voudrions exécu-ter. Une fois le prologue terminé, les premières instructions d'ExitProcess seront démarrées (les instructions contrôlés par le désassembleur

Figure 5. Le schéma d'accrochage d'ExitProcess

Listing 3. Outils API

unsigned char HookCode[]= "\x90"

/* nop */

"\x68\x38\x03\x00\x00"

/* push 3E8h */

"\x6A\x6E"

/* push 6Eh */

"\xB9\x00\x00\x00\x00"

/* mov ecx,00h */

"\xFF\xD1"

/* Call K32!Beep */

"\x68\x00\x00\x00\x00"

/* push dword 00h */

"\xB9\x00\x00\x00\x00"

/* mov ecx,00h */

"\xFF\xD1"

/* Call K32!Sleep */

"\x90\x90\x90\x90"

/* Espace pour les instructions

surveillées */

"\x90\x90\x90\x90"

"\x90\x90\x90\x90"

"\x90\x90\x90\x90"

"\x90\x90\x90\x90"

"\x68\x00\x00\x00\x00"

/* push dword 00h */

"\xC3"

/* ret */

"\x90";

/* nop */

unsigned char ExitHook[]="\x68\x00\x00\x00\x00"

/* push dword 00h */

"\xC3";

/* ret */

Listing 4. Nous construisons notre HookCode à l'aide des adresses obtenues

printf("[+]Rebuilding

HookCode...");

// K32!Beep

*( DWORD* )( HookCode + 9 ) =

BeepAddr;

// Sleep param

Parameter = atoi( argv[2] );

*( DWORD* )( HookCode + 16 ) =

Parameter;

// K32!Sleep

*( DWORD* )( HookCode + 21 ) =

SleepAddr;

*( DWORD* )( HookCode + 48) =

HookAddr + LenDasm;

printf("[OK]\n");

Sur Internet• http://www.reversemode.com/index.php?option=com_remository&Itemid=2&fun

c=select&id=8 – Le code source complet de toutes les applications mentionnées dans l'article. Le désassembleur de taille. L'exemple d'un programme malveillant et d'une application pour hooking,

• http://research.microsoft.com/~galenh/dfPublications/HuntUsenixNt99.pdf – Detours: Binary Interception of Win32 Functions,• http://msdn2.microsoft.com/en-us/library/ms253960(VS.80).aspx

– Structure Exception Handling in x86.

Reconnaître l'adversaire

hakin9 Nº 4/2006www.hakin9.org 61

de taille), et ensuite, le contrôle de l'instruction convenable suivante (ExitProcess+7) sera restauré.

Ensuite, il faut reconstruire Hoo-kCode et ExitHook au moyen des adresses de la mémoire API et des

valeurs obtenues à partir du désas-sembleur de taille.

Ensuite, nous créons un proces-sus en mode suspendu et nous al-louons de la mémoire dans l'espace adressable.

À la fin, nous restaurons Exi-tHook à l'aide de l'adresse obtenue via VirtuaAllocEx, nous retouchons Entry Point de la fonction cible (dans ce cas ExitProcess) au moyen d'Exit-Hook.

La façon d'appeler le programme était le suivant :

congrio c:\acpinject.exe 10000

Kernel32.dll ExitProcess

• en premier argument, nous avons path malware,

• en deuxième argument, l'interval-le en millisecondes du passage à Sleep,

• le troisième argument est DLL qui exporte la fonction cible,

• la fonction cible est ici ExitPro-cess.

ConclusionComme on a pu voir dans l'article, les différents domaines de l'ingénie-rie inverse se convergent dans un point. Nous avons couplé différentes techniques, comme par exemple les désassembleurs de taille, le et l'introduction des processus pour fa-ciliter notre analyse des programmes malveillants.

Paradoxalement, ces mêmes techniques sont exploitées par les programmes malicieux, ce qui aide aussi le développement de l'ingé-nierie inverse. Plus les rootkits, les virus, etc. sont complexes, plus l'ana-lyse des techniques utilisées et des façons dont elles sont appliquées est détaillée. Ainsi, nous avons une sor-te d'une course à laquelle participent les chercheurs, les programmeurs des programmes malveillants ou les auteurs des virus, mais les effets en seront ressentis par millions d'utilisa-teurs. Pourtant, on ne peut pas nier le fait que les recherches et les in-novations proviennent de deux côtés de la barricade. l

Listing 5. ProcessusA

Ret1 = CreateProcessA( szExecutableName, NULL, NULL, NULL,0,

CREATE_SUSPENDED,NULL,NULL,

&strStartupProceso,&strProceso);

if( !Ret1 ) ShowError(); printf("[OK]\n");

printf("[+]Allocating remote memory...");

Ret2 = (DWORD) VirtualAllocEx( strProceso.hProcess,NULL,sizeof(HookCode), MEM_COMMIT,

PAGE_EXECUTE_READWRITE);

Listing 6. Nous restaurons ExitHook

*( DWORD* )( ExitHook + 1 ) = Ret2;

printf("[OK]->Address : 0x%x",Ret2);

printf("\n[+]Hooking %s...",argv[4]);

printf("\n\t[-]Reading %d bytes from %s Entry Point ...", LenDasm, argv[4]);

Ret1 =(DWORD) memcpy( (LPVOID)( HookCode + 27 ),(LPVOID)HookAddr, LenDasm);

if( !Ret1 ) ShowError(); printf("[OK]\n");

printf( "\t[-]Hooking %s...", argv[4] );

Ret1=0;

while( !Ret1 ) {

ResumeThread(strProceso.hThread);

Sleep(1);

SuspendThread(strProceso.hThread);

Ret1 = WriteProcessMemory(strProceso.hProcess, (LPVOID)HookAddr,

/ * Nous retouchons la fonction cible */

ExitHook, HookLength, NULL);

/* dans la mémoire */

}

printf("[OK]\n");

printf("\t[-]Injecting Hook...");

Ret1 = WriteProcessMemory(strProceso.hProcess,(LPVOID)Ret2,

/* Nous copions le code dans l'espace adressable*/

HookCode, sizeof(HookCode), NULL);

/* du processus récemment créé */

/* Nous permettons au processus de se dérouler */

ResumeThread(strProceso.hThread);

À propos de l'auteurL'auteur s'intéressent depuis 16 ans de l'environnement de l'ingénierie inverse et en général de la sécurité informatique. À l'âge de 19 ans, en parfait autodidacte, il a com-mencé à travailler comme programmeur. Ensuite, il se développé dans les domaines liés au bas niveau, aux programmes anti-virus et à la vulnérabilité aux attaques. Ac-tuellement, il se concentre sur ce dernier domaine.

www.buyitpress.com

Abonnez-vous à vos magazines préférés et commandez des anciens numéros !

Vous pouvez en quelques minutes et en toute sécurité vous abonner à votre magazine préféré.

Nous vous garantissons :• des tarifs préférentiels, • un paiement en ligne sécurisé, • la prise en compte rapide de votre commande. Abonnement en ligne sécurisé à tous les magazines de la maison d’édition Software !

Vous recevrez vite de très beaux cadeaux !

Merci de remplir ce bon de commande et de nous le retourner par fax : 0048 22 887 10 11 ou par courrier : Software-Wydawnictwo Sp. z o.o., Piaskowa 3, 01-067 Varsovie, Pologne ; Tél. 0048 22 887 13 44 ;E-mail : abonnement@software.com.pl

Prénom Nom ............................................................................................... Entreprise ...................................................................................................

Adresse .................................................................................................................................................................................................................................

Code postal ................................................................................................ Ville ..............................................................................................................

Téléphone ................................................................................................... Fax ...............................................................................................................

Je souhaite recevoir l'abonnement à partir du numéro .....................................................................................................................................................

E-mail (indispensable pour envoyer la facture) .................................................................................................................................................................

o Prolongement automatique d’abonnement

bulletin d’abonnement

TitreNombre de numéros annuels

Nombre d’abonne-

ments

À partir du numéro Prix

Programmation sous Linux (1 CD ou DVD) Bimestriel pour les programmeurs professionnels 6 38 €

Software Developer’s Journal Extra ! (1 CD ou DVD) – anciennement Software 2.0 Extra Bimestriel sur la programmation

6 38 €

Linux+DVD (2 DVDs)Mensuel unique avec 2 DVDs consacré à Linux et à ses utilisateurs 12 86 €

Linux+ Extra Pack (4-7 CDs ou 1-3 DVDs)Distributions Linux les plus populaires 6 50 €

PHP Solutions (1 CD)Le plus grand magazine sur PHP au monde 6 38 €

Hakin9 – comment se défendre ? (1 CD)Bimestriel destiné aux personnes qui s’intéressent à la sécurité des systèmes informatiques

6 38 €

.PSD (2 CDs)Bimestriel pour les utilisateurs d’Adobe PhotoshopTutoriels dans chaque numéro

6 39 €

MSCoder (1 CD)Independent magazine for software developers 6 38 €

Je règle par :¨ Carte bancaire n° CB expire le date et signature obligatoires type de carte .......................................................................... code CVC/CVV ¨ Virement bancaire : Nom banque : Société Générale Chasse/Rhônebanque guichet numéro de compte clé Rib30003 01353 00028010183 90IBAN : FR76 30003 01353 00028010183 90Adresse Swift (Code BIC) : SOGEFRPP

Total

www.hakin9.orghakin9 Nº 4/200664

Pratique

Actuellement dans le réseau, des millions de transactions ont lieu et les données privées et confidentielles sont rendues

publiques. Dans le réseau, tout cela est possi-ble, mais pour des raisons de sécurité, il faut savoir qui a accès aux données vulnérables et qui peut exécuter des opérations privilégiées. Nous devons être sûrs que les utilisateurs non autorisés ne peuvent pas consulter les documents auxquels ils n'ont pas d'accès. Les serveurs essaient de savoir qui est l'utilisateur et à partir de ces informations décider quel type d'action ceux-ci peuvent exécuter. L'authentifi-cation est une technique d'identification qui consiste à vérifier l'identité d'une personne à partir de certaines preuves telles que mot de passe ou PIN. HTTP fournit une fonctionnalité naturelle permettant une authentification.

En fait, HTTP définit deux protocoles offi-ciels d'authentification : une authentification de base et une authentification digest. Dans cet article, je me concentrerai particulièrement sur la méthode d'authentification de base qui est largement utilisée par les clients et les serveurs réseau et est moins sûre.

Les domaines d'application de cette mé-thode d'authentification :

• Serveurs réseau sur Internet – c'est une situation la plus populaire. À partir de la maison ou d'un cyber-café, l'utilisateur se connecte sur un serveur sur lequel l'authen-tification HTTP est configurée pour accéder à certaines ressources. Si vous consultez les pages Web des entreprises, vous pou-vez observer que beaucoup de pages utili-sent ce type d'authentification pour donner accès aux parties protégées du site.

• Serveurs réseau dans un Intranet- dans ce cas, le domaine d'application est plus restreint

Problèmes d'authentification HTTP

Emilio Casbas

Degré de difficulté

Le protocole HTTP nous offre le mécanisme d'autorisation de type requête-réponse qui peut être exploité par un serveur en réseau ou un proxy pour accepter ou refuser l'accès aux ressources du réseau.

Cet article explique...• Différents niveaux d'autorisation HTTP.• Différences dans l'autorisation HTTP sur les

niveaux différents.• Exemples pratiques de communication HTTP.• Faiblesses de l'autorisation.• Solutions et alternatives.

Ce qu'il faut savoir...• Modèle OSI.• Connaissance du protocole HTTP.

Authentification HTTP

hakin9 Nº 4/2006www.hakin9.org 65

car il est limité à l'Intranet d'une en-treprise, mais les problèmes liés à ce type d'authentification sont identiques à ceux étudiés dans le cas précédent, et les ressources disponibles à l'intérieur du réseau sont tout aussi vulnérables.

• Serveurs proxy sur Internet – il se peut aussi que pour naviguer dans certaines ressources d'un réseau donné ou pour contrôler

l'accès, on puisse le faire unique-ment à travers le serveur proxy de cette institution. Pour cela, l'authentification HTTP peut être aussi implémentée dans le proxy pour que toutes les données pas-sent via Internet.

• Serveurs proxy dans un Intranet – il arrive aussi souvent qu'au sein d'un réseau d'entreprise, l'unique possibilité d'accéder

à Internet est réalisée via un ser-veur proxy, ce qui a pour but de contrôler pleinement l'utilisation d'Internet. C'est pourquoi la con-figuration du serveur proxy pour qu'il contrôle les utilisateurs est tout à fait normal dans ce cas. Normalement, ce type de vali-dation sera intégrée à d'autres mécanismes existant dans le réseau intranet, ce qui aggrave le problème de Single Sign On dont nous nous occuperons plus tard.

Exemple pratiqueDès que nous savons déjà ce que c'est l'authentification HTTP et quel-les sont les étapes de son fonction-nement, analysons ces étapes d'une façon plus détaillée, à l'aide de notre navigateur Web mozilla. Pour cela, nous aurons besoin d'une extension pour capturer les en-têtes HTTP que nous réalisons.

L'extension dont nous avons besoin s'appelle livehttpheaders et nous pouvons la télécharger à partir du site http://livehttpheaders.mozdev.org/. Nous l'installons suivant les pas décrits sur le site, et ensuite, dans mozilla, l'option Live HTTP Headers devient disponible (présen-tée sur la Figure 6).

Nous cliquons sur cette option et il s'affiche une fenêtre présentée sur la Figure 2.

Dès ce moment, nous obtien-drons toutes les informations sur les en-têtes HTTP de tous les sites que nous visitons en interceptant les en-têtes expliqués ci-dessous.

En-têtes et explicationsLe client envoie une requête HTTP standard demandant une ressource donnée.

GET /doc/ecasbas/ HTTP/1.1\rn

Host: www.prueba.es\rn

User-Agent: Mozilla/5.0

(Windows; U;

Windows NT 5.1; en-US; rv:1.7.12)

Accept: text/xml,text/html;q=0.9,

text/plain;q=0.8,

image/png,*/*;q=0.1\rn

Accept-Language: en-us,en;

Brève introduction à l'authentification digestLe but de l'authentification digest n'est jamais d'envoyer en clair le mot de passe à travers le réseau, mais de l'envoyer en tant que condensé crypté de manière irré-versible.

L'authentification digest a été développé de façon compatible comme une alternati-ve plus sûre par rapport à l'authentification de base, mais ce n'est pas un unique proto-cole appelé sûr comparable à ceux utilisant les mécanismes de clé publique (SSL) ou les mécanismes d'échange de tickets (kerberos). L'authentification digest n'est pas une authentification forte et n'offre pas la confidentialité des données outre la protection du mot de passe (l'autre partie de la requête et de la réponses passent en texte clair).

Authentification de base :

• L'authentification de base est l'un des protocoles d'authentification HTTP les plus utilisés. Elle est implémentée dans la plupart des clients et serveurs réseaux. Pour mieux comprendre ce qu'est c'est, regardez sa description graphique.

• Au-dessous, nous présenterons les étapes précédents l'authentification HTTP.• L'utilisateur veut accéder à une ressource réseau (par exemple une image)• Le serveur vérifie que cette ressource est protégée et envoie au client une de-

mande de mot de passe avec l'en-tête HTTP Authorization Required et le code 401.

• Le navigateur de l'utilisateur obtient le code et l'en-tête d'authentification et affiche la boîte de dialogue utilisateur/mot de passe. Quand l'utilisateur saisit les données, le navigateur effectue le chiffrement en base64 des données saisies et les envoie au serveur dans l'en-tête utilisateur Authorization.

• Le serveur déchiffre le nom de l'utilisateur et le mot de passe et vérifie s'il a accès à la ressource protégée.

Comme on voit, l'authentification de base envoie une paire utilisateur:mot de passe sous une forme non cryptée à partir du navigateur vers le serveur et en tant que telle ne devrait pas être employée pour les connexions sensibles, à moins qu'on ne travaille dans un environnement chiffré tel que SSL.

Figure 1. Les serveurs réseau sur Internet

hakin9 Nº 4/2006 www.hakin9.org

Pratique

66

q=0.7,es;q=0.3\rn

Accept-Encoding: gzip,deflate\rn

Accept-Charset: ISO-8859-1,

utf-8;q=0.7,*;q=0.7\rn

Keep-Alive: 300\rn

Connection: keep-alive\rn

Le serveur lit son archive de confi-guration et détermine si la ressource sollicitée est protégée par un mot de passe. Le serveur peut donner accès à celle-ci seulement aux utilisateurs connus. Alors le serveur répond au client par une demande d'autorisa-tion en l'indiquant par le code HTTP 401.

HTTP/1.0 401 Unauthorized\rn

Date:

Mon, 16 Jan 2006 11:17:51 GMT\rn

Server: Apache/2.0.55 (Unix)

mod_ssl/2.0.55 OpenSSL/0.9.7g

PHP/5.1.1\rn

WWW-Authenticate:

Basic realm="ByPassword"\rn

Accept-Ranges: bytes\rn

Content-Length: 3174\rn

Content-Type: text/html\rn

X-Cache:

MISS from www.prueba.es\rn

Connection: keep-alive\rn

Le navigateur interprète ce code HTTP 401 comme requête à authen-tifier et affiche alors l'invite utilisateur:mot de passe en montrant le nom de l'hôte et realm, ce qui est illustré sur la Figure 3.

Le client renvoie la requête avec les données sur l'utilisateur/le mot de passe saisies :

GET /doc/ecasbas/ HTTP/1.1\rn

Host: www.unav.es\rn

User-Agent: Mozilla/5.0

(Windows; U; Windows NT 5.1;

en-US; rv:1.7.12)

Accept: text/tml+xml,text/html,

image/jpeg,image/gif;

q=0.2,*/*;q=0.1\rn

Accept-Language:

en-us,en;q=0.7,es;q=0.3\rn

Accept-Encoding: gzip,deflate\rn

Accept-Charset:

ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn

Keep-Alive: 300\rn

Connection: keep-alive\rn

Authorization:

Basic ZWNhc2JhczpwcnVlYmE=\rn

Ensuite, le serveur compare l'infor-mation provenant du client avec sa liste des utilisateurs/mots de passe.

Si l'autorisation ne réussit pas, le serveur renvoie l'en-tête de l'auto-risation souhaitée HTTP 401. Si les données saisies sont correctes, le serveur affichera la ressource vou-lue. Ensuite, le serveur passe à la ressource sollicitée :

HTTP/1.0 200 OK\rn

Date: Mon, 16 Jan 2006 11:17:58 GMT\rn

Server: Apache/2.0.55 (Unix)

mod_ssl/2.0.55

OpenSSL/0.9.7g PHP/5.1.1\rn

Last-Modified:

Fri, 13 Jan 2006 10:31:02 GMT\rn

ETag: "125b019-5-f636a580"\rn

Accept-Ranges: bytes\rn

Content-Length: 5\rn

Content-Type: text/html\rn

X-Cache:

MISS from www.prueba.es\rn

Connection: keep-alive\rn

Dans les champs précédents, nous avons vu les champs spéciaux qui ont été ajoutés aux différentes en-têtes HTTP. Dans l'étape 3, quand le serveur envoie la réponse avec l'en-tête 401, il ajoute un champ spécial.

WWW-Authenticate:

Basic realm="ByPassword"\rn

La valeur Basic montre que nous demandons au navigateur d'utiliser l'authentification de base. La chaîne de caractères realm est une chaîne

Figure 2. Les serveurs réseaux dans un Intranet

Authentification HTTP

hakin9 Nº 4/2006www.hakin9.org 67

arbitraire envoyée pour afficher à l'utilisateur l'information sur le type d'authentification. La Figure 3 mon-tre comment la fenêtre de mozilla de-mande l'authentification en affichant le realm et l'hôte.

L'utilisateur remplit le formulaire et l'envoie. Le navigateur renvoie automatiquement sa demande. Comme on a pu voir auparavant, certains champs ont été ajoutés à une requête HTTP standard :

Authorization:

Basic ZWNhc2JhczpwcnVlYmE=\rn

À ce moment, le navigateur Web envoie une information sur l'autorisa-tion actuelle au serveur. On voit que le champ Authorization se compose de deux valeurs. Le mot Basic mon-tre que le nom de l'utilisateur a été envoyé conformément à la méthode d'authentification de base. Le bloc de données qui vient après celui-ci est le nom de l'utilisateur actuel envoyé par le navigateur. Nos données con-cernant le nom de l'utilisateur n'ap-paraissent pas directement, mais ce n'est pas le chiffrement, mais seule-ment le codage en 64. En résumé, le codage en base64 présente les séquences d'octets arbitraires de façon illisible pour un être humain. Les algorithmes de codage et de décodage sont simples, mais les données codées sont d'habitude de 33% que les données non codés. Pour en savoir plus, lisez l'encadré Sur le réseau.

Si l'on possède le code précé-dent, le nom de l'utilisateur en texte clair peut être facilement déchiffré au format utilisateur:mot de passe.

ZWNhc2JhczpwcnVlYmE=

--> base64Decode() --> "ecasbas:essai"

L'implémentation de l'authentifica-tion digest est exactement le même processus que l'authentification de base. L'unique différence est dans le nombre d'arguments soumis par le navigateur et dans le format du nom de l'utilisateur retourné.

Les deux types d'authentification, digest et basic sont utilisés par les clients et les serveurs Web, mais il ne faut pas les utiliser pour la protection des informations sensibles ou l'accès sécurisé. L'utilisation du même nom de l'utilisateur et mot de passe pour différents services est très fréquente,

mais il faut faire attention à ce que les ressources que l'on veut ainsi protéger ne soient pas trop vulnérables et que ces authentifications ne fonctionnent pas dans d'autres services tels que le courrier électronique et l'accès aux informations privées.

Authentification proxyLes séquences précédentes concer-nent le client demandant au serveur Web un accès à une ressource protégée. Mais cette procédure peut être aussi employée si le serveur proxy nécessite une authentification pour obtenir un accès à une ressour-ce. Nous analyserons aussi cette situation et verrons quels codes sont affichés dans le cas d'un proxy.

Avec un serveur proxy configuré dans le navigateur, nous exécutons une requête pour pouvoir naviguer.

GET

http://www.google.com/ HTTP/1.1\rn

Host: www.google.com\rn

User-Agent: Mozilla/5.0 (Windows; U;

Windows NT 5.1; en-US; rv:1.7.12)

Accept: application/x-shockwave-flash,

text/xml,application/xml,*/*;q=0.1\rn

Figure 4. Les serveurs proxy dans un Intranet

Figure 5. L'authentification de base

Listing 1. Le code perl pour décoder la chaîne en base64

#!/usr/bin/perl

use MIME::Base64;

while (<>) { print MIME::Base64::decode_

base64($_);

}

hakin9 Nº 4/2006 www.hakin9.org

Pratique

68

Accept-Language:

en-us,en;q=0.7,es;q=0.3\rn

Accept-Encoding: gzip,deflate\rn

Accept-Charset:

ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn

Keep-Alive: 300\rn

Proxy-Connection: keep-alive\rn

Le proxy nous répond en nous in-diquant que pour pouvoir naviguer, une autorisation est nécessaire.

HTTP/1.0 407

Proxy Authentication Required\rn

Server: squid/2.5.STABLE12\rn

Mime-Version: 1.0\rn

Date: Mon, 16 Jan 2006 13:01:19 GMT\rn

Content-Type: text/html\rn

Content-Length: 3283\rn

Expires:

Mon, 16 Jan 2006 13:01:19 GMT\rn

X-Squid-Error:

ERR_CACHE_ACCESS_DENIED 0\rn

Proxy-Authenticate: Basic realm=

""Proxy Authentication

(user/passwd)""\rn

X-Cache: MISS from proxy.es\rn

Proxy-Connection: keep-alive\rn

Alors notre navigateur interprète cela comme requête/réponse pour l'authentification de base et affiche l'in-

vite pour y saisir le données exigées, ce qui est illustré sur la Figure 9.

Certains navigateurs n'interprè-tent pas correctement realm, c'est pourquoi ils affiche dans la fenêtre présentée ci-dessous le message Proxy Authentication (user/passwd). Ce cas est un peu différent, mais il nous servira d'exemple.

Nous saisissons le nom de l'uti-lisateur et le mot de passe, et notre client envoie les données de retour suivantes au proxy.

GET

http://www.google.com/ HTTP/1.1\rn

Host: www.google.com\rn

User-Agent: Mozilla/5.0

(Windows;

U; Windows NT 5.1;

en-US; rv:1.7.12)

Accept:

application/x-shockwave-flash,

text/xml,

image/gif;q=0.2,*/*;q=0.1\rn

Accept-Language:

en-us,en;q=0.7,es;q=0.3\rn

Accept-Encoding:

gzip,deflate\rn

Accept-Charset:

ISO-8859-1,utf-8;q=0.7,*;q=0.7\rn

Keep-Alive: 300\rn

Proxy-Connection:

keep-alive\rn

Proxy-Authorization:

Basic

ZWNhc2Jhc0B1bmF2Lm

VzOnBydWViYTAx\rn

Le serveur proxy vérifie intérieurement si effectivement le nom de l'utilisateur et le mot de passe sont valides et nous donne accès à la ressource.

HTTP/1.0 200 OK\rn

Cache-Control: private\rn

Content-Type: text/html\rn

Content-Encoding: gzip\rn

Server: GWS/2.1\rn

Content-Length: 1408\rn

Date: Mon, 16 Jan 2006 13:05:40 GMT\rn

X-Cache: MISS from filter\rn

Proxy-Connection: keep-alive\rn

Au lieu du code 401 HTTP, le serveur proxy affiche le code 407 (authentifica-tion par proxy nécessaire), et l'en-tête ajouté dans le cas du serveur réseau WWW-authenticate, pour le serveur proxy est Proxy-Authenticate. Tout le processus est identique à celui de l'ac-cès restreint à une ressource réseau, excepté ces petites différences.

Vision générale de l'authentification HTTPLe schéma d'authentification de base n'est pas une méthode sûre

Figure 6. L'option Live HTTP Headers

Figure 7. La fenêtre Live HTTP Headers Figure 8. La fenêtre Live HTTP Headers

Authentification HTTP

hakin9 Nº 4/2006www.hakin9.org 69

d'authentification des utilisateurs. Elle ne protège pas l'identité de l'utili-sateur et celle-ci est transmise à tra-vers le réseau en texte clair. D'autre part, HTTP ne refuse pas l'utilisation des schémas d'authentification addi-tionnels et des mécanismes de cryp-tage qui augmentent et améliorent la sécurité d'authentification de base.

Malgré les faiblesses de ce type d'authentification, comme on a pu voir ci-dessus, cette méthode est utilisée dans différents environne-ments où le plus grand danger est lié à l'existence de Single Sign On, quand un seul mot de passe vous sert à vous identifier auprès de tou-tes les ressources. Ainsi, il n'est pas important si vous utilisez les méca-nismes d'accès sécurisé par le biais de SSL, les connexions chiffrées au

réseau (IPSEC), les programmes avec une connexion sécurisée, etc. Si l'une des ressources emploie ce type d'authentification, vous avez un accès immédiat à tous les services disponibles.

Un champ idéal pour implémen-ter ce type d'authentification serait, par exemple, l'accès aux statistiques d'utilisation d'un serveur donné ou l'accès à une autre ressource, si vous trouvez qu'un accès illégal à celle-ci n'est pas dangereux. De cela, les authentifications d'accès doivent être fournies par l'adminis-trateur du site ou par un programme générateur. Elles ne doivent jamais être choisies par l'utilisateur car ainsi on se retrouvera avec le même pro-blème qu'auparavant. Les gens n'ont pas l'habitude d'utiliser différentes

authentifications pour différents ser-vices, mais les réutilisent.

ConclusionL'authentification HTTP de base est simple et commode, mais ce n'est pas une méthode sûre. Il faut l'em-ployer dans les cas où l'accès aux informations doit avoir le caractère privé et son utilisation ne peut pas compromettre la sécurité des autres systèmes.

Les gens utilisent souvent le même nom d'utilisateur et le même mot de passe à des fins différentes. De cela, même si ceux-ci sont uti-lisés dans des environnements de confiance et dans les cas d'un accès aux informations non sensibles, il existe toujours un risque que les mêmes authentifications pourraient nous donner accès aux services plus importants tels que courrier électronique, documents privés ou bases de données.

Au moyen d'un sniffeur réseau et de quelques scripts permettant d'interpréter le trafic intercepté, en quelques minutes on peut obtenir des centaines de paires utilisateur/mot de passe par la méthode décrite ci-dessus. Dans l'authentification HTTP, les mots de passe traversent le réseau en texte clair, et lors de la connexion, les en-têtes avec les mots de passe le traversent plus d'une fois. Pendant la connexion, ils sont renvoyés pour chaque tran-saction réalisée. Cela est dû à la propriété du protocole HTTP qui ne conserve pas l'état et il est nécessai-re de rappeler les données qui sont fournies pendant chaque connexion au serveur ou au proxy. Pour amé-liorer cette manière d'authentification ou la remplacer par d'autres métho-des plus sûres, il faudrait :

• le combiner avec SSL pour ren-forcer la sécurité en chiffrant toutes les données de la trans-mission

• le remplacer par l'authentification digest

• utiliser Kerberos• le supprimer de tous les endroits

où il n'est pas nécessaire. l

Figure 9. La fenêtre Live HTTP Headers

Tableau 1. L'authentification de serveur réseau et l'authentification proxy

Serveur réseau Serveur Proxy.

Code d'état sans autorisation : 401 Code d'état sans autorisation : 407WWW-authenticate Proxy-AuthenticateAuthorization Proxy-authorizationAuthentication-Info Proxy-Authentication-Info.

Sur Internet• http://livehttpheaders.mozdev.org/ – le plug-in pour mozilla,• ftp://ftp.isi.edu/in-notes/rfc2617.txt – l'authentification HTTP : l'authentification

Basic et Digest,• http://www.faqs.org/rfcs/rfc2045.html – le chiffrage du transfert en Base64, • http://httpd.apache.org/docs/1.3/howto/auth.html – la configuration d'apache pour

qu'il demande l'authentification,• http://rfc.sunsite.dk/rfc/rfc2617.html – RFC 2617.

www.hakin9.orghakin9 Nº 4/200670

Alentours

Albert Einstein a dit une fois : Il n'existe que deux choses infinies, l'univers et la bêtise humaine... mais pour l'univers, je

n'ai pas de certitude absolue. Plusieurs person-nes associent cette citation à la sociotechni-que et au social engineering. À moins que dans le premier cas cela ait du sens, je suis plus sceptique en ce qui concerne le social engineering. Il s'agit plutôt d'inconscience que de bêtise. Le fait de ne pas se rendre compte de certaines règles est à la base de la plupart des attaques sociotechniciens contre les entre-prises. Par contre, on peut qualifier de bêtise le comportement des employés seulement quand ils acceptent consciemment les méthodes exploitées par un sociotechnicien s'attaquant à leur entreprise.

C'est dans cette inconscience que réside la puissance du social engineering. Si un cracker expérimenté casse la protection réseau d'une entreprise, il y aura toujours quelqu'un qui vou-drait expliquer la situation par l'inconscience et l'incompétence des administrateurs ou des utilisateurs du réseau. Par contre, si un socio-technicien s'attaque à une entreprise – les victimes de cette attaque non seulement ne se rendront pas compte qu'ils sont manipulés,

mais probablement longtemps après l'évè-nement, ne feront pas le lien entre certains faits. Bien que cela paraisse perfide – l'attaque sociotechnicien est une subtilité. Kevin Mitnick – le sociotechnicien le plus célèbre (et pas le cracker – comme il est injustement appelé par les média) du monde répétait toujours dans ses interviews qu'il avait obtenu les informations seulement parce qu'il les demandait. Évidem-ment, de la manière appropriée.

SociotechnicienLes principes théoriques du social engineering constituent la sociotechnicien qui est une scien-ce de la manipulation des êtres humains. Dans chaque attaque exploitant le social engineering, nous pouvons retrouver les traces des règles communes à la base de la sociotechnicien :

• Règle de réciprocité – chaque chose posi-tive (aide, support, cadeau) obtenue de la part d'une personne, génère la volonté de rendre la politesse

• Règle de preuve de justification sociale – 10 mille clients ne se trompent pas ! Con-formément à cette règle, il est plus facile de nous convaincre de quelque chose, si l'on

Social engineering

Tomasz Trejderowski

Degré de difficulté

Quelqu'un a appelé le social engineering intrusion dans l'esprit. C'est une moyenne arithmétique de la sociotechnicien (manipulation d'autrui) et du cracking (intrusion dans les systèmes informatiques). À partir de ces deux mécanismes, un outil très puissant est né. Beaucoup ne se rendent pas compte de sa force destructrice.

Social engineering

hakin9 Nº 4/2006www.hakin9.org 71

nous démontre que les autres pensent ou se comportent de la même manière.

• Règle de sympathie – si nous aimons quelqu'un ou il nous paraît sympathique, nous répondrons plus volontiers à ses demandes.

• Règle d'autorité – nous n'avons pas assez de courage pour nous opposer à quelqu'un de plus sage,plus expérimenté ou plus haut quenous dans la hiérarchie. Ce méca-nisme fonctionne même si nous sommes contraints que la décision ou que l'action prises par cette per-sonne sont erronées.

• Règle d'engagement et de con-séquence – si nous sommes en-gagés dans quelque chose, nous allons viser à réaliser le but.

• Règle d'indisponibilité – la valeur d'une chose donnée augmente, sicelle-ci est temporairement ou con-stamment indisponible. Il y a aussi une Règle inversée d'indisponibi-lité – les choses fréquentes, évi-dentes et facilement disponibles ne présentent pas une grande valeur à nos yeux.

• Règle de valeur et de profit – il vaut la peine de lutter pour les cho-ses de valeur (y compris spirituellestelles que l'honneur, la bonne re-nommée, la gloire). Si une so-ciotechnicien suscite en nous l’impression que ces aspects de notre vie sont menacés, il peut facilement nous contraindre aux actions que nous-mêmes n'avons jamais entreprises.

Ces règles sont très souvent exploi-tées dans la manipulation sociotechni-cien (dans le média, la politique, la vie professionnelle). Quand on parle du social engineering, différentes com-binaisons de ces règles sont utilisées.

Il ne faut pas oublier que le méca-nisme le plus populaire utilisé par les sociotechniciens dans les attaques sur les entreprises est tout simple-ment le mensonge.

Manque d'équivalence des notionsCertaines personnes sont d'avis qu'il faut séparer ces deux notions. L'in-

fluence totale sur les sociétés entiè-res (de grands groupes sociaux) est le social engineering. Une manipu-lation informative d'un individu (d'un petit groupe de gens) est un social engineering. Dans le deuxième cas, on utilise aussi les notions socioin-formatique et sociohacking.

Beaucoup de gens trouvent que l'informatique et le totalitarisme (et également le marketing, les médias, les affaires, etc.) sont des domaines très éloignés. Malgré tout, on peut considérer l'exercice de l'influence sur les êtres humains sur ces ni-veaux comme mécanismes équiva-lents et identiques. C'est pourquoi, on utilise dans tous les cas la même expression – social engineering.

La notion la plus populaire est le social engineering et elle a été utilisée dans ce texte, bien qu'elle ait autant de partisans que d'adver-saires.

Niveau d'insécuritéLa conscience du danger qui me-nace de la part de la sociotechnicien et du social engineering est négligée dans la plupart des entreprises.

D'où je prends ces données ré-vélatrices ? Je me baserai sur mon propre exemple qui, selon moi, mon-tre très bien l'étendue du problème. Outre les articles, je donne aussi des cours. Le centre des formations où je travaille est le seul dans la région à organiser des cours du domaine de la sociotechnicien et du social engineering. Au cours de l'année, nous organisons deux cours et nous avons des difficultés pour trouver dix clients. Et j'habite et je travaille dans une ville (Katowice, Pologne) qui a 300 mille d’habitants et 50-80 mille entreprises (comme dans plusieurs villes européennes). C'est la preuve suffisante d'une très basse cons-cience dans cette matière.

En attaquant, un sociotechnicien touche le point le plus faible de cha-que entreprise – homme. La socio-technicien et le social engineering s'attaquent au niveau subconscient de l'esprit humain – les régions dont les actions sont souvent nous ne hors de champ de la conscience ;

les mécanismes sont réflexifs et automatiques. Contre ces attaques, aucun pare-feu, ni programme anti-virus, ni des millerrs dépensées pour la sécurité informatique, ne sont pas capables de nous protéger. Seuls les cours de sociotechnicien perma-nents peuvent nous protéger contre ce danger car ils éliminent l'incons-cience dont j'ai parlé au début de l'article.

Dans la suite de l'article, je mon-trerai que c'est seulement en appa-rence que le danger ne nous con-cerne pas. En fait, il est présent dans chaque entreprise, chaque ville et à tout moment.

Qui et pourquoi ?Il n'est pas possible de déterminer quia utilisé la sociotechnicien pour la première fois. Il y a quelques milliers d’années que les prêtres égyptiens utilisaient les moments de l'éclipse du Soleil calculées mathématiquement pour manipuler leurs peuple et se faire obéir.

Quant au social engineering, alors l'exploitation de la sociotechnicien pour s'attaquer aux entreprises et aux sys-tèmes informatiques, la question de la première utilisation de ce mécanis-me n'est pas facile à déterminer. Plu-sieurs personnes croient que pour la première fois, cette méthode a été utilisée par le célèbre Kevin Mitnick. Moi, personnellement, je suis d'avis qu'il a seulement rendu plus po-pulaire cette technique de collecte des données. Le social engineering existe aussi longtemps qu'il existe de-puis probablement aussi lengtemps qu’il existe des ordinateurs. C’est à dire depuis les années soixante ou même cinquante du siècle passé.

La réponse à la question pour-quoi ce mécanisme est utilisé ? est banale et je l'ai donnée dans les pa-ragraphes précédents. C'est tout sim-plement fructueux. En Europe, c'est encore (heureusement) la phase ini-tiale qui domine, pendant laquelle la plupart des attaques sont exécutées par des sociotechniciens - amateurs. Ils le font surtout pour résoudre leurs petits problèmes privés qui ne peu-vent pas être réglés par voie tradi-

hakin9 Nº 4/2006 www.hakin9.org

Alentours

72

tionnelle. Très souvent, ils utilisent le social engineering uniquement pour démontrer à eux-mêmes comment ils sont doués (Sociotechniciens à White hat ?). Mais cette étape ne durera pas longtemps. Le temps quand les sociotechniciens seront embauchés par la concurrence pour voler les secrets commerciaux ou pour mener les entreprises à la fail-lite – modèle américain – n'est pas trop lointain. C'est la question de quelques années.

Question de réputationEn premier, il faut se poser la ques-tion si un employeur ou un proprié-taire d'une entreprise est capable de relier certains évènements (le plus souvent la perte des données confidentielles) à l'action d'un socio-technique ? Ce sont des attaques très subtiles (disons –difficiles à dé-tecter) et qui ne laissent pas tout de suite des désastres visibles (tels qu'un disque dur formaté, une page Web remplacée – le résultats de l'activité du cracker). C'est pour-quoi les chances pour les détecter (mêmes quelques semaines plus tard) par une équipe non formée et n'ayant pas connaissance du problème sont – selon mon avis – minimales.

Si, pourtant, l'entreprise détecte qu'elle a été l'objectif de la cible d'unsociotechnicien, reconitra-t-elle ce fait ? Non. Parce qu'elle ne gagne rien et peut beaucoup perdre – à commen-cer par la confiance des ses clients et sa réputation.

C'est pourquoi, bien que les don-nées statistiques n’existent pas pour ce sujet, leur véracité est redoutable. Comment alors, par qui et comment obtenir les informations véridiques

sur ce sujet quand ces données sont le plus grand secret de chaque en-treprise. L'attaque sociotechnicien, outre les pertes financières remar-quables, est aussi une confirmation de la faiblesse. Une chose inadmis-sible.

Tel est pris qui croyait prendreQuand on prend connaissance des techniques de social engineering et des façons de s'en défendre, très sou-vent on est tenté de l'utiliser pour ses propres buts. Je laisse au lecteur le jugement moral et les chances de découvrir cette activité. Je voudrais seulement signaler que le social en-gineering, comme toute autre formede manipulation des gens, contre leur gré et à leur insu, pour en tirer profit, est un acte punissable en France (les réglementations appro-priées existent dans chaque pays). L'article 226-15 du Code pénal dit :Le fait, commis de mauvaise foi, d'ouvrir, de supprimer, de retarderou de détourner des correspondan-ces arrivées ou non à destination et adressés à des tiers, en d'en pren-dre frauduleusement connaissance, est puni d'un an d'emprisonnement et de 300 000 F d'amende. Est puni des mêmes peine le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divul-guer des correspondances émises, transmisses ou reçues par la voie de télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles intercep-tions.

Pas de vérificationSi l'on comprend l'outil le plus simple et le plus populaire du sociotechni-

cien – le mensonge – la solution la plus simple vient automatiquement à l'idée. C'est la vérification. S'il est possible de se faire passer pour un autre, il faut vérifier, vérifier et encore une fois vérifier – à chaque pas. Pra-tiquement chaque entretient au sein d'une entreprise concernant ces aspects stratégiques (informations confidentielles, sécurité, argent) doit être suivi d'un rappel téléphonique. Si l'administrateur du réseau, Jean Martin, téléphone à l'employé Jean Dubois, alors ce dernier raccroche et rappelle lui-même Jean Martin (bien sûr, au numéro qu'il connaît et pas à celui donné), pour s'assurer que c'était vraiment Jean Martin et pas un sociotechnicien qui s'était fait passer pour lui.

C'est la théorie. Dans la pratique, les entreprises sont loin d'implémen-ter une telle solution. Le problème n'est pas financier. Vu que la com-munication téléphonique interne est gratuite, le coût de l'implémentation de cette solution ne devrait pas être élevé. Mais très souvent, les respon-sables considèrent que les moyens de sécurité si avancés ne sont pas nécessaires. Hélas, c'est une façon d'aborder le problème très dange-reuse.

Quand une information innocente est-elle nuisible ?Toujours ! Toute information est dan-gereuse. Même celle la plus simple – comme le prénom et le nom de la collègue qui est assise de l'autre côté du bureau. Si elle n'aide pas di-rectement au sociotechnicien, il peut l'exploiter pour vérifier son identité artificielle pendant la conversation avec une autre personne. Je le ré-pète encore une fois. Chaque infor-mation, même celle la plus banale – qui sort en dehors de l'entreprise, peut être dangereuse.

La conclusion en est simple. Il est impossible de se défendre contre la sociotechnicien et le social enginee-ring. La façon efficace de s'y défen-dre n'a jamais existé, n'existe pas et n'existera pas. On peut, à la limite,

Figure 1. Qui découvrira le mot de passe caché dans cette impression ?

Social engineering

hakin9 Nº 4/2006www.hakin9.org 73

tenter de réduire ses effets et limiter le risque au minimum. IL est impossi-ble de l'éliminer complètement.

Tisser la toileLe plus grand avantage du socio-technicien et en même temps le plus grand danger pour les entreprises est le fait que l'attaquant a du temps et beaucoup de patience. L'attaque sociotechnicien n'est pas effectuée n'importe comment, par un blanc-bec qui a lu une traduction (le plus souvent mauvaise) d'un ouvrage américain concernant ces problèmes et veut se lancer. C'est un jeu straté-gique très bien préparé, élaboré pour plusieurs éventualités, contenant les solutions alternatives et les scénarios pour les situations atypiques.

Le mécanisme de cette attaque est en général identique ou très simi-laire. Il ressemble au tissage d'une toile d'araignée. À partir des fils très fins qui en tant que tels ne constituent pasobstacle même pour une mouche du vinaigre, une toile raffinée est créée pouvant capturer non seulement un troupeau de mouches, mais aussi un grand moustique et plusieurs d'autres insectes.

Pour un sociotechnicien, aucune information n'est sans valeur. Chacune, même la moins importante, peut l’ai-der. Ces informations apparemmentanodines sont pour lui les plus pré-cieuses. C'est parce qu'elles sont les plus faciles à obtenir – personne ne les considère comme confidentielles et ne les protège pas – tandis qu'el-les peuvent servir à trier les faussesinformations, et ainsi, obtenir les don-nées d’une valeur inappréciables.

Par exemple, les actions pour-raient se passer ainsi :

• l'obtention du prénom et du nom d'un employé quelconque ;

• le prénom et le nom sont révélés spontanément par le département où la personne donnée est em-ployée ;

• pour obtenir l'adresse du courrier électronique d'un employé, il ne faut même pas connaître le département dans lequel celui-ci est embauché – ces données

sont souvent publiées sur la page Web de l'entreprise ;

• on peut téléphoner à cet employé, se faire passer pour l'administra-teur et par le biais d'une simple manipulation obtenir son nom d'utilisateur et le mot de passe au réseau d'entreprise. Mais ce n'est pas l'objectif en tant que tel ;

• si l'on possède l'adresse de la messagerie, il sera facile de se procurer le numéro interne de cet employé (p.ex. sur la liste des rémunérations, le numéro d'enre-gistrement, etc.).

Si l'on connaît le prénom, le nom, le département, l'adresse du courrier électronique, et souvent aussi le nom de l'utilisateur et le mot de passe, on dispose de la base pour voler l'iden-tité d'une personne. Un sociotechni-cien muni de ces informations peut avec succès se faire passer pour l’employé d'une entreprise et conti-nuer son attaque sociotechnicien dans la direction souhaitée.

Pourtant, l'attention est attirée non sur le contenu, mais sur l'idée de ce plan d'actions. En tout cas, le sociotech-nicien téléphone à une autre person-ne, se fait passer pour quelqu'un d'au-tre (administrateur, employé, client), présente une histoire inventée mais vraisemblable et demande d'une façon ingénieuse une information simple et apparemment insignifiante.

Chacun des employés atta-qués s'y prête de bonne grâce car il pense consciensciemment (à raison) qu'il n'avoue aucun secret commer-cial ou d'entreprise, et qu’il ne donne que des informations complètement insignifiantes.

Méthodes d'obtention des informationsVu la taille et le caractère de cette publication, je ne peux donner que quelques méthodes d'attaques les plus importantes.

• En se servant de la règle d'inac-cessibilité (curiosité), un sociotech-nicien peut contraindre l’employé d'une entreprise à exécuter une action atypique, par exemple en

envoyant un email ou en glissant une disquette contenant les don-nées apparemment confidentiel-les (le système de primes, les rémunérations de l'administration, les détails piquantes de la vie privée, etc.). Après l'ouverture du document joint (le démarrage du programme), un troyen est ins-tallé sur l'ordinateur de la victime. Ainsi, l'assaillant obtient l'accès au réseau de l'entreprise et aux données enregistrées sur le disque dur.

• À l'aide de la règle d'autorité, l'attaquant peut se faire passer pour un supérieur et contraindre le subordonné à révéler certai-nes informations. S'il connaît le prénom et le nom de l'assistante du président, il peut ensuite té-léphoner à une autre personne et lui dire qu'il se contacte à la demande de cette personne. Aux membres de la direction, personne ne refusera rien.

• La règle de sympathie peut être exploitée dans une situation imaginée quand une personne connue et aimée est menacée. Un sociotechnicien peut télépho-ner à l'entreprise, se faire passer pour un employé de la banque et dire qu'un collègue ou un collabo-rateur de la personne à laquelle il téléphone, à la suite de... (ici un mensonge vraisemblable) n'obtiendra pas sa rémunération à temps, mais que nous pouvons aider et donner... (une informa-tions peu importante, mais non disponible au public – par exem-ple l'identifiant de cet employé). Dans cette situation, tout en étant guidé par la sympathie (ici exploi-tée) et la volonté d'apporter de l'aide, nous révélerons facilement les informations qui ne devraient pas sortir de l'entreprise.

• Une solution alternative à la pré-cédente consiste à téléphoner à la personne intéressée et à lui faire croire (une manipulation de la peur, l'aspect de la règle de valeur) que sa rémunération est virée à une autre banque. L'em-ployé excité (émotions) est dis-

hakin9 Nº 4/2006 www.hakin9.org

Alentours

74

ponible aux manipulations. Danscette situation, on peut en tirer pratiquement toute information en jouant quelqu'un qui veut aider.

• La question d'aide est exploitée dans la sociotechnicien inverse. Un sociotechnicien peut met-tre en scène une situation (par exemple pas d'accès à Internet dans une période chaude pour l'employé), en se faisant passer avant pour l'administrateur et en lui donnant le numéro de la ligne d'urgence en cas de problèmes. Si la victime (à la suite d'une mystification rusée) téléphone elle-même au sociotechnicien, il est presque sûr qu'elle désactive tous les mécanismes défensifs possibles et sera ouvert à la ma-nipulation.

• Le mécanisme de demande d'aide ou de volonté de l'offrir est l'un des plus utilisé par les socio-techniciens. C'est pourquoi il faut rester vigilant et faire attention à qui nous offrons notre aide et de qui proviennent les informations. Le fait d'offrir de l'aide démarre le mécanisme de la règle de réciprocité, ce qui peut rendre efficace l'attaque du sociotechni-cien.

• Dans les cas extrêmes, le so-ciotechnicien ne doit rien faire car les employés inconscients et non formés donnent seuls accès aux informations. Par exemple, le protocole de fin du contrat avec un opérateur de la téléphonie cellulaire – le proto-cole dont la copie est parvenue au client – contient le numéro SFID de l'employé chargé de terminer l'opération de fin du contrat. C'est un numéro con-fidentiel identifiant l'employé. Sous aucun prétexte, ces types d'informations ne doivent être affichées sur les documents disponibles au public imprimés pour les clients. Dans un dis-pensaire de Katowice, une négli-gence encore pire a eu lieu. Sur le bureau de la réception, au vue et au su de tout le monde, on a laissé les cartes de nouveaux

patients. Les informations desti-nées à la Caisse nationale d'as-surance maladie, contenant les données complètes comme le pré-nom, le nom, l’adresse, le télé-phone, le NIF. Pour une person-ne habile, cela suffit pour voler l'identité d'un autre.

• Pour obtenir le numéro du cel-lulaire privé d'un employé en ne connaissant que son prénom et son nom, il suffit de se servir d'une simple astuce. Le socio-technicien peut téléphoner à la réception (centrale) de l'entre-prise, en s'assurant au préalable qu'une personne donnée n'est pas présente au travail (par exem-ple les vacances ou une absence temporaire). Il se fait passer pour l'administrateur, invente une his-toire (p.ex. un baratin technique incompréhensible) et demande de laisser sur le bureau de l'em-ployé une annotation suivante : Envoie un signal au numéro XXX. Très urgent ! Administrateur. Si l'employé retéléphone – le socio-technicien a son numéro (il n’a même pas à dérocher). Si le nu-méro est caché, il suffit de de-mander d'écrire l'annotation En-voie un SMS au numéro XXX, je ne peux pas accrocher. Dans les cas extrêmes, il ne faudra même pas attendre car la réceptionniste épouvantée et manipulée d'une façon appropriée donnera seule le numéro du cellulaire de l'em-ployé.

• Les déchets – les documents jetés à la poubelle dans une en-treprise comprennent une quan-tité de données (les adresses du courrier électronique, les identifi-cateurs, les téléphones internes, les noms des responsables, etc.).Et ils sont détruits très rarement.Un sociotechnicien ne se procu-rera pas directement des donnéesconfidentielles (mais ce n'est pas si sûr que ça) car ces données sont traitées dans le destructeur ou sont conservées et pas jetées. Mais ces informa-tions peu importantes provenant de ces déchets se prêtent par-

faitement au tissage de toile et à créer l’image d'une personne que l'on est pas. Kevin Mitnick a mentionné dans plusieurs entretiens que les visites dans les dépôts des déchets des entreprises ou même la cor-ruption du personnel des entre-prises s'occupant de l'évacuation des déchets pour qu'ils lui fournissent les déchets d'une société concrète, était l'une des meilleurs méthodes d'obtention des informations indispensa-bles.

• Les nouveaux employés sont trai-tés en général avec indulgence. Le modèle américain admet le mécanisme que la concurrence envoie un employé dans une au-tre entreprise pour y travaillerpendant quelque temps (quel-ques mois). Il commet tant d'er-reurs qu'il n'est possible qu’il se procure des informations. L'indul-gence et la compréhension – oui, mais en même temps une double vigilance.

• Un sociotechnicien peut télépho-ner à l'entreprise et arranger une situation quand l'employé doit s'éloigner du téléphone en comp-tant que celui-ci ne lui bloque pas le microphone. Et dans plusieurs cas, il ne se trompe pas. Une fois, j'ai profité des services de l'une des plus grandes entreprises d'expédition. J'ai téléphoné pour vérifier l'état de mon envoi. La vé-rification durait assez longtemps et pendant l'absence de mon interlocuteur, j'ai pu entendre tou-tes les conversations menées à proximité – entre les employés eux-mêmes et les d'employés et les clients. J'ai entendu beaucoup de détails (adresses, paramètres, identificateurs) concernant les autres clients et les envois. Une telle situation est inadmissible.

• Souvent, les administrateurs des réseaux d'entreprise facilitent latâche au sociotechnicien. Ils obli-gent (trop) souvent les employésà changer les mots de passe en(trop) compliqués. L'esprit humainmot de passe est limité et ils

Social engineering

hakin9 Nº 4/2006www.hakin9.org 75

hakin9 Nº 4/2006 www.hakin9.org

Alentours

76

exagèrent quand ils contraignent l'utilisateur à mémoriser cinq lon-gues chaînes de lettres et chif-fres. Il ne faut pas être étonné que ce dernier essaie de se fa-ciliter la tâche – p.ex. il emploie les combinaisons clavier sim-ples (qwe123, zaq12wsx) dont les listes sont disponibles dans Internet. Ou bien, il note les mots de passe sur les feuilles de papier. Mais si l'on doit ab-solument noter un mot de passe sur un bout de papier, il faut le faire d'une façon ingénieuse. Il est difficile de mémoriser vingt chiffres et lettres. Mais il n'est pas difficile de les entourer au début et à la fin par exemple de cinq caractères aléatoires, et en-suite, avant et après cette ligne ajouter (ou imprimer) encore dix autres, également aléatoires. Dans un bloc de lettres, signes et chiffres si dense, personne ne trouvera notre mot de passe. Et pour nous, un coup d'oeil suffit pour nous rappeler qu'il faut enlever dix ligne à partir du haut et du bas et cinq caractères de chaque côté et copier la chaîne de caractères qui reste.

• Un sociotechnicien peut aussi se faire passer pour un employé d'une entreprise plus grande (un gros consortium) collaborant avec la société attaquée. Il peut dire qu'il téléphone du départe-ment du service et qu’il fait une enquête ayant pour but d'amé-liorer la collaboration entre les deux entreprises. Grâce au mé-canisme non important-impor-tant, il peut introduire dans les questions banales et évidentes les contenues grâce auxquels il obtiendra des informations précieuses. En étant en posses-sionde ces informations, il peut ensuite téléphoner à l'entreprise dont il jouait l'employé

• Très souvent, l'attaque directe (sur le terrain de l'entreprise), pour se procurer un objet con-cret, est impossible à effectuer ou très difficile. Tout le monde se connaît et il existe des pro-

cédures que le sociotechnicien ne connaît pas, et il pourrait être démasqué. Dans ce cas, en disposant d'une quantité appro-priée d’informations, simuler un employé (par téléphone) et in-venter une histoire justifiant pour-quoi il ne vient pas reprendre per-sonnellement un envoi donné. L'attaquant peut demander de le laisser à la réception et informer que quelqu'un le fera pour lui. Ensuite, il se rend per-sonnellement à l'entreprise où il peut se comporter comme un homme ordinaire. Personne ne vérifiera son identité car le vrai employé a dit qu'il ne peut pas reprendre l'envoi personnelle-ment. Dans cette situation, il est facile d'obtenir les informations imprimées, difficiles à acquérir d'une autre manière. Il faut seu-lement prendre soin pour que la personne pour laquelle se fait passer le sociotechnicien soit absente et qu'il soit impossiblede la contacter. Pour un assaillant bien payé ce n'est pas un pro-blème.

• Si un sociotechnicien s'atta-que à une filiale d'une grande entreprise (corporation, il peut facilement se faire passer pour un employé d'une autre filiale, mentir qu'à la suite d'une panne, l'accès au réseau d'entreprise est impossible et obtenir ainsi les informations qui ne sont pas destinées pour quelqu'un de l'extérieur.

• Comme on avait mentionné au début, la règle d'inaccessibilité dit que plus une chose est inac-cessible, plus la valeur de cette chose augmente aux yeux de l'at-taqué. Un sociotechnicien peutsimuler la situation d'un accès li-mité à des données urgentes (par

exemple une panne apparente d'un serveur) et ainsi contraindre l'employé à révéler les données confidentielles (nom de l'utilisa-teur, mot de passe) pour accé-lérer la reprise de l'accès aux données.

• Le mécanisme très similaire qui a pour but de créer une impression de menace (Votre carte de crédit sera désactivée, veuillez donner son numéro et le code pour an-nuler le processus de la désacti-vation.) ou d'offrir une promotion (Donnez votre nom de l'utilisateur et le mot de passe eBay pour ob-tenir 10 euros sur votre compte utilisateur.) est très souvent utilisé par phising. Le mécanisme est très simple et consiste à contraindre la victime à révéler les informa-tions nécessaires pour la fraude. Il n’est pas nécessaitre d’être un cracker. Il suffit un peu de ruse et un peu de social engineering et de crédulité (et souvent – d'avi-dité) de la part de la victime.

Comment se défendre ?Ce ne sont que des exemples. Quel-ques exemples. Un sociotechnicien professionnel qui tire profits de l'ac-tivité illégale, en connaît quelques centaines. Et tout en observant la vie et les relations interpersonnelles, est capable d'en inventer au moins un chaque jour. Ses principaux atouts sont le mensonge, l'aplomb, la pa-tience et l'expérience.

Il n'existe pas une méthode sûre permettant de se défendre contre un sociotechnicien et probablement il n'en existera jamais. La détermi-nation de certaines règles peut effi-cacement rendre difficile la vie des sociotechniciens et leur empêcher d'effectuer plusieurs attaques. Ces règles sont, à savoir :

À propos l'auteurTomasz Trejderowski – par sa formation métallurgiste, par sa profession d’écrivain, chargé de cours, programmeur et webdesigner. Auteur des plusieurs ouvrages et articles. Candidat au doctorat à la Polytechnique de Silésie.http://www.tomasz.trejderowski.com/

Social engineering

hakin9 Nº 4/2006www.hakin9.org 77

• La vérification par tous les moyens possibles si la personne avec qui nous parlons est celle pour qui elle se fait passer. Un sociotechnicien, par méthode de tissage du toile peut acquérir plusieurs informations sur l'en-treprise et sur la victime, mais certainement pas toutes. Une at-titude très utile (pour l'entreprise) et en même temps très embêtante (pou lui) consiste à ne pas violer les règles de sécurité définies seulement parce que quelqu'un nous le demande. Si nous avons six codes à vérifier et nous choi-sissons d'une façon aléatoire C, demandons de la personne qui téléphone de donner le code C. Ne cédons pas à sa demande d'un autre code seulement parce que quelqu'un est, par exemple, devant son ordinateur. Cela peut être un mensonge et le sociotech-

nicien qui téléphone peut tout sim-plement connaître un seul code et tente de nous manipuler ainsi.

• Ne pas céder aux émotions, à la pression de l'autorité et à la peur.

• Ne pas ouvrir les pièces jointes aux messages et les fichiers sur les disquettes et CDs provenant des sources inconnues.

• Détruire régulièrement et pré-cisément les déchets et autres documents imprimés issus de l'entreprise. Ne pas révéler des données confidentielles sur les documents disponibles au grand public. Bloquer les conversations téléphoniques pour qu'une tierce personne ne puisse pas entendre ce qui se passe dans le bureau.

• Vérifier très minutieusement à qui nous offrons notre aide et qui essaie de nous aider.

• Formations régulières de tous les employés sur les méthodes

sociotechniciens et du social en-gineering.

ConclusionLa sociotechnicien est une manipu-lation du comportement des humains permettant d'en tirer des profits maté-riels ou des données confidentielles. La sociotechnicien existe depuis le début de l'humanité, mais l'exploita-tion de ses règles pour les attaques sur le entreprises et les systèmes informatiques n'est présente que de-puis quelques dernières années.

J'espère que j'ai réussi à vous présenter les arguments assez forts pour convaincre au moins quelques personnes que le problème non seulement existe, mais est quasi un danger réel, et avant tout – concerne pratiquement chaque entreprise, cha-que personne et chaque aspect de la vie, aussi bien professionnelle que privée. l

P U B L I C I T É

hakin9 Nº 4/2006 www.hakin9.org78

Bibliothèque

79hakin9 Nº 4/2006

Bibliothèque

Titre : 19 Deadly Sins of Software security: Programming flows and how to fix themAuteur : Michael Howard, David Leblanc, John ViegaÉditeur : Mc Grow Hill Langue : AnglaisNombre de pages : 304 pagesISBN : 0-07-226085-8Prix : 32,90 €

Bibliothèque

Tout le monde, y compris un programmeur débutant, sait ce que signifient les erreurs lors de la programmation. Il suffit de lire une description de n'importe quelle faille critique pour se rendre compte de ses conséquences sur la sécurité du système. La surcharge de la mémoire tampon, de la pile, etc. sont des éléments fréquents et n'impressionnent plus personne.

D'après les auteurs, les 19 péchés du titre de l'ouvrage, signifient les erreurs les plus fréquentes. Selon Amit Yoran (National Cyber Security Division), ces erreurs constituent 99 % de défauts dans la programma-tion.

Le livre, il est facile de le deviner, comprend 19 parties. Chacune d'entre elles est consacrée à l'un des péchés que l'on peut commettre lors de la programma-tion. À titre d'exemple, un chapitre décrit donc un péché, présente un fragment concernant les péchés similaires où vous pouvez trouver des similitudes entre les erreurs diverses. Il y a aussi un fragment où le programmeur

décide une amélioration (donc comment éviter ce type d'erreur) et un examen de conscience, donc une liste de points sur lesquels il faut réfléchir pour éviter ce type d'erreur dans l'avenir.

Cette manière de traiter l'analyse d'erreurs comme une confession peut, dans un premier temps, surprendre, voire énerver – personne n'aime en effet admettre une erreur. Après une réflexion, il est difficile de ne pas y voir un sens d'humour et une logique.

Les auteurs ont réussi en plus à réaliser un ouvrage complet, dépourvu d'éléments inutiles – ils ont donc eux-mêmes réussi à éviter un péché souvent fréquent chez les auteurs d'ouvrages informatiques, à savoir, le péché de bavardage. Ils tiennent aussi leur promesse de proposer un texte qui ne vous prendra pas votre temps inutilement.

Indépendamment donc de votre niveau, lisez l'ouvrage, frappez-vous la poitrine et améliorez-vous en améliorant votre code.

Titre : Network Security BibleAuteur : Eric Cole, Ronald L. Kurtz, James ConleyÉditeur : O’ReillyLangue : AnglaisNombre de pages : 660 pages ISBN : 0-7645-7397-7Prix : 38,90 €

La maison d'édition Helion essaie de choisir les ouvrages les plus complets sur un sujet donné. Jusqu'à présent, au moins, en ce qui concerne les ouvrages liés à la sécurité, elle n'avait pas toujours de bons résultats. Les lecteurs s'attendent donc à recevoir un ouvrage sur la sécurité pour les utilisateurs intermédiaires et avancés.

L'ouvrage Sécurité de réseaux ne s'écarte pas de ce niveau intermédiaire. Il discute largement la question du titre, permettant ainsi à l'utilisateur de réfléchir sur les points oubliés, en ce qui concerne la sécurité et la pro-tection de réseaux. Cet ouvrage décrit très bien les direc-tives pour réaliser des réseaux et parle des questions importantes aussi bien pour créer un nouveau réseau que pour mieux protéger le réseau existant.

Cependant, nous vous prévenons toute de suite : la sécurité de réseaux est un sujet tellement vaste qu'un ouvrage de 660 pages ne peut pas forcément

tout décrire. De plus, les exemples de solutions et de techniques, présentés dans le livre, ne sont que élé-mentaires ; ils ne servent qu'à illustrer les questions sélectionnées et de nombreux problèmes sont à peine mentionnés.

Si le sujet vous intéresse, il ne vous reste qu'à cher-cher éventuellement les descriptions des solutions dans un autre ouvrage.

La première partie du livre (cela constitue son avan-tage) comprend les procédures et les principes élémen-taires concernant la sécurité de réseaux. Il est vrai que le savoir lié à la sécurité évolue rapidement mais les procé-dures changent assez rarement. La sécurité de réseaux concerne aussi la protection d'informations, autrement dit, non seulement des éléments techniques mais aussi des procédures, des normes et des principes. C'est le point souvent oublié par les administrateurs.

hakin9 Nº 4/2006 www.hakin9.org78

Bibliothèque

79hakin9 Nº 4/2006

Bibliothèque

Les critiques sont proposées par Krystyna Wal et Łukasz Długosz de l'équipe InfoProf (http://www.infoprof.pl). La Librai-rie Informatique Cracovie (http://www.informatyczna.pl) a aima-blement prêté les livres aux critiques et les éditeurs Helion et WNT les ont aimablement prêtés à notre rédaction.

Titre : Linux Server SecurityAuteur : Michael D. BauerÉditeur : O’ReillyLangue : AnglaisNombre de pages : 456 pagesISBN : 059600705Prix : 45,90 €

Voici le livre qui a des chances de vous surprendre avant de le lire. Si vous ne faites pas attention, vous pourrez acheter l'ouvrage précédent de cet auteur, datant de 2003. Pourqoui ? Parce que la couverture et le titre, Linux Server Security, sont similaires à la publication la plus récente. Pourtant, si vous achetez le bon livre, vous serez également surpis.

Vous avez donc acquis un ouvrage dont la structure n'est pas unie et le niveau n'est pas toujours le même. D'après le titre, nous pouvons nous attendre à un ouvrage destiné plutôt aux utilisateurs avancés qui atten-dent non seulement un ensemble de bonnes pratiques dans la configuration de services fragiles mais aussi les conseils pour ne rien oublier et pour améliorer les solu-tions. Et l'ouvrage nous propose à la place les fragments des analyses théoriques (par exemple concept de fonc-tionnement de LDAP) et les descriptions détaillés pour

configurer des services concrets. Nous trouvons aussi une recette pour les configurations de programmes, comme Sendmail et Postfix. Entre temps, nous tombons sur des fragments très faibles où l'auteur dit tout simple-ment qu'un service en question existe et peut provoquer des problèmes, comme par exemple, la base MySQL. Il est donc difficile de nous prononcer clairement sur son niveau ou sur les utilisateurs qu'il concerne. Nous pou-vons affirmer toutefois que cet ouvrage sera décidément utile aux administrateurs débutants grâce aux conseils détaillés concernant la configuration FTP, du service DNS et SMTP. L'exemple de configuration Iptables et le chapitre sur les IDS les plus populaires, comme Snort ou Tripware, seront donc très utiles. Les utilisateurs avan-cés trouveront aussi des points intéressants, à condition d'être patients et de lire rapidement les descriptions de points évidents.

Titre : Introduction aux scripts shellAuteur : Arnold Robbins, Nelson H. F. BeebeÉditeur : O’ReillyLangue : FrançaisNombre de pages : 580 pagesISBN : 2-84177-375-2Prix : 35,90 €

Les scripts shell dont parle le titre concernent la pro-grammation sur la console texte, l'absence apparente de facilités et une technique très souple pour résoudre les problèmes classiques et atypiques.

Dans la plupart de cas, les scripts complexes consti-tuent des règles de démarrage, de fermeture et de con-trôle de déroulement. Pour pouvoir travailler avec eux, il faut savoir les manipuler.

Les commandes de shell offrent de grandes possi-bilités, en ce qui concerne la réalisaton de tâches spé-cifiques, pour lesquelles aucun outil prêt n'existe pour l'instant. L'ouvrage présenté sera donc utile non seule-ment aux administrateurs de systèmes Unix mais aussi

aux autres utilisateurs qui souhaitent réaliser facilement leurs propres solutions, sans forcément opter pour les langages de programmation typiques.

L'ouvrage est très clair et vous avez la possibilité de passer au fur et à mesure aux questions de plus en plus difficiles, liées à la programmation de scripts. Les chapi-tres expliquent aussi comment bien manipuler le shell et présentent ses commandes élémentaires.

Nous pouvons considérer cette publication comme un ensemble de cours où les auteurs analysent les outils, leurs défauts, le fonctionnement et enseignent comment réaliser et modifier les scripts prêts. Ce deuxième point suit le principe : « ne pas enfoncer une porte ouverte » ; quelqu'un a déjà fait quelque chose de semblable, il suffit donc peut-être de modifier une partie pour obtenir une nouvelle solution, simple et souple et garder les stan-dards. Le livre peut s'avérer un ouvrage précieux pour les programmeurs qui écrivent en langages compilés et pour les administrateurs qui souhaitent apprendre davantage sur la programmation de scripts.

hakin9 Nº 4/2006 www.hakin9.org80

Éditorial

S'il existait l'équivalent d'un Greenpeace pour défen-dre la sécurité informatique, et prendre soin des espèces rares dans le monde des technologies

informatiques, il ne laisserait probablement pas s'éteindre une certaine créature parmi les plus fascinantes, qui fêtera cet hiver son vingtième anniversaire d'existence.

Je veux bien sûr parler du premier virus sur PC, connu sous le nom de Brain. Bien qu'il ne s'agisse pas du tout premier virus informatique (le premier étant apparu plus tôt, en 1982 sur la plateforme Apple II), le virus Brain est aussi important dans le domaine des ordinateurs que ne l'est Brian Adams pour sa maison d'enregistrement. Avec l'invention du PC, les ordinateurs ont commencé à occuper une place importante dans la vie quotidienne de leurs uti-lisateurs, et pas seulement aux yeux de ces scientifiques rébarbatifs avec leurs lunettes toutes fines. En ce sens, les virus informatiques sont devenus un phénomène majeur.

Un autre logiciel destiné à la plateforme Intel, créée en 1985, soit un an avant le virus Brain, a survécu jusqu'à nos jours. Environnement graphique censé initialement fonctionner de manière autonome, ce logiciel n'inscrivait au début aucun code dans le secteur d'amorçage, et tour-nait à la place sous le système d'exploitation MS-DOS. Aujourd'hui, après 21 ans de développement continuel et plusieurs versions successives, Windows est devenu lui-même un système d'exploitation, dont la toute nouvelle version, Vista, est prévue pour cette année. Microsoft n'a pas l'intention de proposer de logiciel anti-virus avec cette version, les nouvelles fonctionnalités de la marque majeure Vista étant déjà sécurisées.

Permettez moi d'émettre des doutes quant à la raison avancée pour ne pas inclure d'anti-virus par défaut dans le package de distribution. S'ils le pouvaient, les développeurs de Microsoft intègreraient dans leur système d'exploitation un aspirateur dans l'unique but de vous convertir en utilisa-teur dépendant de la technologie Microsoft. Et ce ne serait pas une si mauvaise idée. Plus j'y pense, et plus l'idée me semble alléchante. Non, vraiment, pourquoi aller chercher un aspirateur auprès d'autres fournisseurs, alors que mon système d'exploitation préféré en possède déjà un ? Après tout, une version originale ne vous coûtera pas moins de 60 dollars, sans compter le prix de l'ordinateur.

Mais revenons à notre question initiale : où sont passés les anti-virus ? La réponse est simple lorsqu'on se souvient des batailles juridique menées par l'entre-prise de Bill Gates au sujet des applications Internet

Où sont passés les anti-virus ?

Explorer et Windows Media Player. Microsoft a été en effet accusé, dans ces deux cas, de proposer ces appli-cations avec son système d'exploitation. Déjà échaudé, il n'est guère difficile de comprendre que Microsoft ne sou-haite pas prendre le même risque avec un anti-virus.

Que penser des utilisateurs qui ont du fait payé pour les produits Microsoft. Il s'agit pour la plupart d'entrepri-ses ou de clients de fabricants de matériel informatique d'origine, ayant acheté Windows avec leur ordinateur. Je suppose qu'ils n'ont aucun problème à connecter leur ordinateur à Internet. En outre, ces utilisateurs sont pro-bablement connectés en permanence.

En gros, cette situation suffit à ajouter un bouton télécharger l'anti-virus dans le panneau de configura-tion pour intégrer virtuellement le logiciel dans le kit de distribution. Un seul clic, et voilà un anti-virus installé et prêt à l'emploi. Symantec et McAfee ont déjà déclaré qu'ils accepteraient Microsoft en tant que nouvel acteur sur le marché des anti-virus et ne feraient appel à aucun organisme de régulation. Sans souhaiter la présence de Microsoft sur ce marché, force est de constater que cette fois tout est légal, le logiciel n'étant pas inclus, aucune loi anti-trust ne peut être appliquée.

Si j'étais architecte de logiciels chez Microsoft, je con-cevrais un composant anti-virus sous Vista de la façon suivante : afin d'éviter un téléchargement trop long, je place-rais tous les codes des anti-virus dans les bibliothèques du système d'exploitation. Lorsque vous appuyez réellement sur le bouton, vous téléchargerez un programme EXE de 5 kilooctets, chargé d'appeler tout simplement la fonction de l'interface de développement StartAntivirus(). Il ne peut, avoir aucun problème avec l'interface de développement, celle-ci étant de toute façon fermée.

Et que peuvent y changer Symantec, McAfee ou d'autres petits distributeurs d'anti-virus ? De nombreuses options se présentent à eux : prospecter d'autres seg-ments du marché semble judicieux. Finalement, l'option des aspirateurs n'est pas la pire. l

Konstantin Klyagin

À propos de l'auteurKonstantin Klyagin, également connu sous le surnom de Konst, est ingénieur en solutions logicielles. Depuis sept ans, il travaille dans le domaine du développement de logiciels. Originaire de Kharkov, en Ukraine, il habite à l'heure actuelle à Berlin. Pour plus de renseignements contactez : http://thekonst.net.

PublicitéSafety-Lab

Les bases de données et les infrastructures qu'elles supportent constituent les points vitaux d'une organisation. Les bases de données con-tiennent, en effet, les données les plus précieu-ses d'une organisation (qu'elle soit financière, personnelle, pour tenir des inventaires, ou traiter des cartes de crédit, etc.). Il est donc nécessaire de prendre toutes les mesures nécessaires afin de rectifier les vulnérabilités présentes sur les bases de données. Shadow Database Scanner de Safety-Lab sera votre ARME de DÉFENSE.

Shadow Database Scanner de Safety-Lab vous permettra de gérer votre base de données et ses vulnérabilités, et d'analyser vos besoins en termes de sécurité sur les serveurs SQL. Les organisations reposant sur Internet ont besoin d'une solution de sécurité sur leur base de données flexible, facile à utiliser et capable de faire économiser des ressour-ces de valeur.

Le scanner de base de données de Safety-Lab répond à ces besoins, en proposant aux entrepri-ses de protéger leurs données et leurs informa-tions sensibles sur un serveur SQL sécurisé.

Shadow Database Scanner (Shadow Database Scanner – scanner de base de données) a été le fer de lance d'une nouvelle génération de logiciels extrêmement performants, à la pointe de la tech-nologie du 20ème siècle, et occupe toujours les pre-mières places du marché en ce début de nouveau millénaire !

Shadow Database Scanner a été développé dans le but de proposer la détection sécurisée, rapide et fiable d'un large choix de failles sécuritaires présen-tes sur les systèmes. Une fois le système scanné, Shadow Database Scanner analyse les données collectées, localise les vulnérabilités ainsi que les éventuelles erreurs de réglage du serveur, et suggère des résolutions envisageables des problèmes ren-contrées. Shadow Database Scanner fait appel à un algorithme d'analyse de sécurité du système unique fondé sur un concept intellectuel breveté.

En raison de son architecture unique, Sha-dow Database Scanner est le seul scanner de sé-curité au monde à pouvoir détecter des défauts sur MiniSql. Il s'agit également du seul scanner commercial capable de suivre plus de 300 audits par système.

Shadow Database Scanner supporte aujourd'hui les serveurs SQL suivants : MSSql, Oracle, IBMDB2, MiniSql, MySQL, Sybase, SAP DB et Lotus Domino. Grâce à son architecture entièrement ouverte (re-posant sur ActiveX), n'importe quel professionnel maîtrisant VC++, C++ Builder ou Delphi a la possi-bilité d'étendre très simplement les fonctionnalités du scanner.

La technologie ActiveX permet également aux administrateurs de système d'intégrer Shadow Da-tabase Scanner dans pratiquement n'importe quel produit supportant ActiveX.

Dans la mesure où Shadow Database Scan-ner propose un accès direct à son noyau, vous pouvez utiliser l'interface de programmation (pour de plus amples informations, veuillez consulter la documentation sur l'interface de programmation) afin d'obtenir tous les accès à Shadow Database Scanner ou modifier ses propriétés et ses fonctions. Si vous maîtrisez le fonctionnement de base des réseaux infor-matiques et si vous avez trouvé de nouvelles brèches dans la sécurité de votre système, et ce sans être programmeur professionnel, vous pouvez contacter directement Safety-Lab ou utiliser l'assistant BaseSDK : celui-ci saura vous guider dans tout le processus de création d'un nouvel audit. L'assistant BaseSDK vous permet-tra également d'ajouter plus de 95% de nouveaux types d'audits.

L'éditeur de règles et de paramètres est l'outil idéal des utilisateurs désireux de scanner uniquement les ports et les services souhaités sans perdre de temps, ni de ressource, à scanner d'autres services.

Grâce à sa flexibilité de réglage, les administra-teurs de système peuvent ainsi gérer la profondeur du scan à réaliser ainsi que d'autres options afin de profiter d'un scan de réseau extrêmement rapide sans aucune perte de qualité.

Notre scanner est également doté d'une fonc-tion unique permettant de sauvegarder l'enregis-

trement d'une session de scan détaillé non seule-ment au format traditionnel HTML (disponible chez 99% des autres scanners), mais aussi aux formats XML, PDF, RTF et CHM (HTML compilé).

La nouvelle interface du scanner est à la fois conviviale et simple à utiliser. Elle a été optimisée de manière à faciliter l'accès aux principales fonc-tions du programme.

La gestion des options de Shadow Database Scanner est également très simple : tous les élé-ments clé de l'interface du programme sont dotées de fenêtres d'aide sous forme de bulles compre-nant une description concise des fonctions.

L'assistant des mises à jour se charge de mettre à jour régulièrement les modules exécutifs du programme avec les informations de sécurité les plus récentes, afin d'assurer à votre système une solide protection et une bonne résistance aux attaques malveillantes.

Safety-Lab propose également avec son nou-veau produit un accès direct à son service Internet Security Expert ainsi qu'une zone de télécharge-ment mise à jour quotidiennement.

Si vous souhaitez poser des questions, con-naître les prix proposés aux acheteurs en gros et aux revendeurs de logiciels, ou bénéficier d'of-fres commerciales, veuillez contacter Edward Fitzgerald à l'adresse suivante : Edward@safety-lab.com. l

Safety-Labhttp://www.safety-lab.com/en

Contact :

Offre spéciale !Safety-Lab propose aux lecteurs du magazine ha-

kin9 la version complète de Shadow Database Scan-

ner valable sur 2 adresses IP pendant 30 jours.

Vous devez indiquer 2 adresses IP de serveur

de base de données par email à l'adresse suivante :

support@safety-lab.com.

La version complète sera valable pendant

30 jours dès réception des adresses IP. Pour re-

cevoir dès à présent votre version, veuillez écrire

à support@safety-lab.com en indiquant dans l'objet

de votre message hakin9-safety-lab-offer.

Offre valable jusqu'au 30 septembre 2006.

LOGICIEL PROFESSIONNEL DE SÉCURITÉ

Publicité

Pour voir les informations actuelles sur le prochain numéro, visitez la page http://www.hakin9.org/frCe numéro sera disponible en vente début septembre 2006.La rédaction se réserve le droit de modifier le contenu de la revue.

hakin9 5/2006 Dans le numéro suivant, vous trouverez, entre autres :

Dans le prochain numéro

Puissante cryptographieLorsqu'on évoque la cryptographie, l'exemple d'un message électronique aussi sécurisé que peut l'être une carte postale est souvent cité. La cryp-tographie permet de sécuriser et d'élever le niveau de confidentialité des communications échangées via Internet en cryptant et/ou en signant les messages. Selon Lars Packschies, la cryptographie garantie aux internautes l'équivalent d'une vie privée à l'ère de l'information totale, d'où son impor-tance accrue dans notre civilisation moderne.

Scan de ports et violation des droitsLa propriété (telle que définie par la loi) est associée au serveurs, aux rou-teurs et aux systèmes informatiques en général En tant que telle, la loi la considère comme un bien meuble (chattels, en anglais). Ainsi, les serveurs sont des biens meubles. Les données relèvent de la propriété intellectuelle. Craig S Wright expose de manière fort intéressante le scan de ports et la violation des droits dans son article.

Corrélation d'évènements avec Simple Event Correlator (SEC) pour une surveillance en temps réelLorsqu'il est question de sécurité des systèmes informatiques, les rapports d'activité jouent un rôle fondamental. Aujourd'hui, de nombreuses applica-tions, systèmes d'exploitation, dispositifs de réseau et autres composants d'un système sont capables de rédiger des messages d'évènements liés à la sécurité dans les fichiers journal. Risto Vaarandi présente dans son article toutes les fonctionnalités du protocole syslog des systèmes BSD, standard de rapports d'activité supporté par la majorité des systèmes d'exploitation et des fournisseurs en équipements réseau. Ce protocole permet, entre autres, de créer un serveur central de journal destiné à recevoir et à stocker les mes-sages d'évènements issus de tout le système informatique.

Analyse différentielle des pares feuComment détecter des violations de sécurité sur un pare feu activé à l'aide d'un système de détection d'intrusions sur le réseau, en comparant le trafic en temps réel interne et externe, et alerter l'administrateur en cas de con-tradiction avec les règles ? Arrigo Triulzi et Antonio Merola tenterons de répondre à cette question en évoquant la possible utilisation d'un système de détection d'intrusions sur le réseau (Network Intrusion Detection System, ou NIDS) en tant qu'outil de vérification dans le cas particulier d'un échec du pare feu.

Focus

Pratique

Fiche technique

Fiche technique