Face à une certaine inertie ambiante et persistante au sein des organisations, et en dépit d’un cortège désormais pléthorique de référentiels, trouver les bons leviers pour faire appliquer systématiquement et uniformément les exigences de sécurité relève encore et toujours de la gageure pour le RSSI. Pour tenter de comprendre, certaines insuffisances récurrentes au niveau opérationnel, il parait nécessaire de prendre un peu de hauteur, en s’intéressant tout d’abord aux freins identifiés, mais également aux systèmes de gouvernance des entreprises, pour se risquer ensuite à faire un parallèle entre la sécurité et d’autres domaines au moins aussi transverses que sont le Développement Durable ou la Qualité. Par cette approche interdisciplinaire, nous allons pourtant voir comment deux disciplines aussi disjointes que la Sécurité du Système d’Information et la Responsabilité Sociétale (ou « RSE »), peuvent en définitive s’avérer positivement interdépendantes lorsqu’associées dans une démarche de progrès visant « excellence et performance durables » !

Lire la suite de l’article dans le magazine Global Security Mag – numéro 23 (Trimestriel Avril-Juin 2013)

Cette pratique n’est pas sans effets puisque les entreprises se retrouvent face à de nouvelles contraintes relatives à la gestion de flotte mobile (smartphones, tablettes, terminaux hybrides, etc.) et la sécurisation des données de l’organisme.

Le BYOD implique des risques à maîtriser

Une étude de Cisco a montré que la France est le pays où le taux d’utilisation des terminaux personnels en entreprise est le plus faible avec un taux de 52%, contre 70% aux Etats-Unis et en Chine. La tendance est à la hausse et ce taux risque d’exploser dans un avenir proche. Les entreprises doivent se préparer à encadrer ce phénomène, analyser de très près les risques induits et étudier les solutions à mettre en place pour réduire les effets de bord et autres dérives.

Les entreprises doivent en premier lieu déterminer si le BYOD apporte une réelle réduction des coûts dans le contexte considéré. Une estimation des frais liés à la mise en place des solutions d’organisation et de sécurité peut influencer de façon significative la décision d’autoriser ou non le recours au BYOD, sachant que des coûts cachés peuvent exister, comme l’adaptation de l’architecture sécurité de l’organisme, l’acquisition de solutions de sécurité appropriées, l’ajustement des politiques de sécurité, la sensibilisation et la formation des utilisateurs et des services informatiques.

Les organisations qui estiment que la pratique du BYOD est incontournable doivent gérer les risques encourus, qui selon le CLUSIF⁽²⁾, se répartissent en trois catégories principales :

• Les risques concernant les données professionnelles ou personnelles :
  • Fuite de données sensibles, notamment en cas de perte ou de vol du terminal ;
  • Perte de données personnelles, typiquement suite à un effacement à distance du terminal par erreur.
• Les risques concernant le système d’information de l’entreprise :
  • Fuite d’information et ses impacts en termes d’image ;
  • Accès à distance non autorisé au SI suite à une compromission des identifiants par la présence de keylogger installé sur le terminal à l’insu de son propriétaire.
• Les risques relevant des obligations légales et de la responsabilité pénale, civile et sociétale :
  • Problème de responsabilité en cas de vol d’un terminal contenant des données professionnelles ;
  • Discrimination sociale entre collaborateurs équipés et non équipés.

La plupart des risques identifiés ci-avant ne sont pas nouveaux mais le fait que les terminaux appartiennent aux employés peut modifier les natures d’impacts. De plus, aucune jurisprudence portant sur un litige relatif au Code du Travail et lié au BYOD n’est à ce jour recensé en France.

Aussi, un ensemble de scénarios doit être construit et de multiples questions doivent être posées pour mettre en évidence les risques à couvrir, parmi lesquels :

• Comment officialiser le BYOD, faut-il modifier le contrat du travail, la charte informatique ou le règlement intérieur ?
• Comment garantir la sécurité des informations auxquelles les employés accèdent sur leurs terminaux personnels ?
• Comment protéger les données de l’entreprise sans compromettre la vie privée des utilisateurs ?
• Les assurances en cas de sinistre ou d’incident de sécurité sont-elles à la charge de l’employé ou l’employeur ?
• Comment définir les limites entre vie privée et vie professionnelle ?
• Comment contrôler les usages abusifs, voire illicites (installation et utilisation des applications sans licence, etc.) ?

Des mesures de sécurité visant à réduire les risques peuvent être mises en place mais elles sont le plus souvent délicates à implémenter au vu de l’hétérogénéité des équipements disponibles sur le marché et le rejet de ces mesures par les employés ou les organisations syndicales.

Bien que des solutions existent pour pallier aux risques de certains aspects du BYOD, elles sont encore peu déployées et le plus souvent mal maîtrisées.

Quelques solutions de base sont néanmoins préconisées :

• Endpoint Protection (EP) for Mobile Devices, permettant le renforcement de la protection des terminaux mobiles et pour la protection des applications, de la connectivité réseau et des données ;
• Mobile Device Management (MDM), permettant de superviser et administrer les terminaux mobiles ;
• Security Information & Event Management (SIEM), permettant aux administrateurs sécurité de superviser notamment l’activité réseau émise par chaque terminal et les éventuels incidents de sécurité ;
• Next-Generation Firewalls (NG-FW), permettant d’appliquer une politique de sécurité BYOD en périmétrie, notamment en détectant automatiquement et en catégorisant les différents OS de terminaux (iOS, Android, Windows Phone, etc.).

Mise en situation (simulation) :
« La réunion annuelle se déroule comme chaque année au siège de la société BOMOD à Paris. Mr Pépin, le responsable financier se trouvait la veille à l’aéroport de Moscou (SVO) ; son vol était prévu à 20h35 mais son avion a eu un retard.
Mr Pépin en  a profité pour envoyer un email professionnel au comptable, en lui communiquant des chiffres sur les résultats des dernières opérations via son smartphone personnel.
Il s’est connecté avec sa tablette tactile au réseau public de l’aéroport pour finaliser la réponse à un appel d’offre sur un dossier particulièrement stratégique.
A son arrivée à la réunion il s’aperçoit qu’il n’a plus sa sacoche, qui contenait smartphone et tablette, perdue ou volée lors de son trajet en transport en commun.
Par ailleurs, le comptable déclare qu’il n’a pas reçu d’email, Mr Pépin a dû se tromper de destinataire…»

• Quelle est la responsabilité de l’entreprise face à cette situation ?
• En supposant que le destinataire est l’un des concurrents, comment l’entreprise doit réagir face à ce problème ? qui est responsable ?

De manière générale, la question à se poser est la suivante : quels sont les risques entraînés par le BYOD et comment les maîtriser dans le cadre d’un SMSI⁽³⁾ ?

Répondre à cette interrogation, c’est inclure les problématiques spécifiquement liées au BYOD dans le périmètre du SMSI, en intégrant les terminaux personnels en tant qu’actifs en support, porteurs de vulnérabilités et exposés à un certain nombre de menaces, en identifiant les actifs primordiaux dont les critères de sécurité sont susceptibles d’être impactés, et en évaluant les risques potentiels pour l’entreprise, en vue de les traiter de façon acceptable.

⁽¹⁾ BYOD : Bring Your Own Device
⁽²⁾ CLUSIF : Club de la Sécurité des Systèmes d’Information Français
⁽³⁾ SMSI : Système de Management de la Sécurité de l’Information

Références :
www.clusif.fr/fr/production/ouvrages/pdf/CLUSIF-2012-Byod-Synthese.pdf
www.zdnet.fr
www.journaldunet.com
www.bcp-expert.com
www.channelnews.fr/expertises/etudes/14434-byod–la-france-encore-tres-frileuse.html

Le Spear-phishing, bien que directement dérivé du phishing traditionnel, utilise quant à lui un mode opératoire sensiblement plus subtil et sournois, en harponnant (verbe « to spear » en anglais) une ou quelques cibles au plus, méticuleusement choisies, avec pour dessein d’obtenir des informations très précises sur les organisations auxquelles elles sont rattachées. Cette méthode cible donc des profils très particuliers qui officient pour des organisations aux activités généralement sensibles sur un secteur particulier (défense, industrie, finance, etc.). L’objectif ici est donc bien évidemment d’arriver à exfiltrer des données sensibles de l’intérieur, avec la complicité passive d’une victime ou plus. Pour parvenir à leurs fins, les attaquants utilisent ainsi des emails relativement personnalisés et écrits dans la langue du pays, sans tournure de phrase maladroite ou de mise en forme suspecte quelconque, afin d’abuser leurs victimes. Pour rendre ces messages crédibles aux yeux des destinataires, une étape de collecte d’informations est effectuée au préalable, sachant que celles-ci se trouvent souvent accessibles très simplement sur Internet en utilisant les outils traditionnels comme les moteurs de recherche ou les réseaux sociaux notamment.

Une fois que la ou les cibles ont été identifiées, et que suffisamment d’informations personnelles à leur sujet ont été consolidées, les cyber-pirates envoient alors un faux email qui exploite au mieux les informations sur le ou les destinataires amenés à être dupés. L’email frauduleux contient la plupart du temps soit une pièce jointe (avec une extension trompeuse pour l’utilisateur final, du genre <nom_de_fichier.pdf>.zip incluant par exemple un fichier exécutable ou contenant du code malicieux dont l’extension sera masqué à l’affichage), soit un lien qui lancera à l’ouverture (exécution) de celui-ci l’installation d’un malware (type cheval de Troie,bot), qui permettra par la suite de transmettre des informations sensibles aux fraudeurs en connexion sortante vers Internet via des « techniques d’évasion », voire même de leur donner un accès distant au poste infecté par canal de communication dit « C&C » (« Command and Control » en anglais).

Ci-dessous un schéma décrivant le processus d’attaque par spear-phishing :

Le Spear-Phishing est donc une tendance qui semble se développer et qui, certainement encore cette année, fera de nouvelles victimes aussi bien au sein des organisations que parmi les particuliers. Dorénavant, les organisations, mais plus particulièrement encore chacun de leurs employés, notamment exerçant des responsabilités importantes, devront être encore plus vigilantes, notamment dans le cadre de la prévention contre les APT.

Comme vous l’aurez compris, il est encore temps de prendre les 5 bonnes résolutions de l’année 2013 pour ne pas vous faire piéger :

• S’assurer de la fiabilité de l’expéditeur : analyser scrupuleusement (au caractère près !) l’adresse email de l’expéditeur, et notamment le nom de domaine indiqué après le « @ ».
• Ne pas cliquer sur des pièces jointes ou des liens avant d’être convaincu de l’authenticité de l’expéditeur.
• S’assurer de la pertinence de la destination des hyperliens : lorsqu’un mail contient un ou plusieurs liens, prendre connaissance de l’adresse Internet vers laquelle ils pointent avant de cliquer dessus, par exemple en survolant (sans cliquer) avec le curseur.
• Vérifier l’intitulé parfois trompeur des liens affichés : les URL raccourcies (notamment dans les tweets) cachent souvent des liens distincts malveillants. Après avoir cliqué sur un lien, au niveau du navigateur, contrôler la réputation du site indiqué par les éventuels plugins de protection anti-phishing.
• Ne jamais communiquer de données sensibles sur des sites non-sécurisés : s’assurer de la connexion en https tout en contrôlant les informations du certificat du site.

Références :
http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf
http://idtheft.about.com/od/theftmethods/a/Spear_Phishing.htm

Nous sommes en 2013, et le Cloud Computing est toujours là. Ni la fin du monde, ni ses nombreux détracteurs n’auront eu sa peau. Ses premières années ont été accompagnés de débats houleux et acharnés autour de son concept, certains parlant de révolution, d’autre de simple évolution de l’hébergement externalisé, remettant en cause l’utilité d’une telle prise de risque dans la perte de gouvernance.

Les clients eux, n’ont pas l’air de se poser autant de questions, les PME comme les grands groupes s’arrachant les services de quelques géants (Amazon, Microsoft, IBM) pour des besoins allant de la VM d’appoint pour la sauvegarde, à l’infrastructure complète externalisée en Cloud Privé.

Les revenus générés par les différents acteurs du Cloud le montrent : De 4 milliards de dollars en 2010, les sociétés européennes devraient dépenser le double en 2013, et presque 14 à l’horizon 2016. Et nous, petits français, ne sommes pas en reste ; en 2012 nous représentions 1/4 du marché européens dans ce secteur en termes de dépense (sources PAC).

Réduction des coûts, simplification de gestion, flexibilité et rapidité de mise en œuvre sont autant d’arguments commerciaux précipitant les décideurs à opter pour l’Infonuagique (promis, ce mot existe). Décisions, malheureusement le plus souvent dépourvues de réflexions orientées sécurités.

Parlons-en ; à mon sens , le Cloud Computing n’apporte pas pléthores de problématiques sécurités du point de vue technique par rapport à un hébergement externalisé classique. La nouveauté viendra de la notion de cloisonnements inter-clients dans un Cloud Public. Cela pourrait faire l’objet, pourquoi pas, d’un prochain article. Pour le moment, penchons-nous sur l’aspect juridique, et plus particulièrement contractuel qui par la perte de contrôle due au concept du Cloud, prend une dimension toute particulière.

Contractus Nimbostratus…

Le premier véritable danger du Cloud Computing c’est le contrat qui est associé à son service. On le divisera en deux grandes catégories : le contrat d’adhésion et par opposition le contrat négocié (ou contrat gré à gré).

Comme son nom l’indique, le contrat d’adhésion, on l’aime ou on la quitte. Plus sérieusement, ce contrat, type « case à cocher », ne laisse au client aucune possibilité d’ajustement, d’ajout ou de suppressions de clauses incluses au contrat. Contrat qui se résume à une page classique de CGU suivie d’une case à cocher. Et au final, qui lit vraiment ces fameuses CGU ?

L'exemple le plus connu : Amazon

Ce type de contrat laisse donc aucune marge de négociation aux clients et conviendra mieux, si cela est possible, aux services d’appoints peu sensibles.

A contrario, le contrat négocié, laissera le loisir aux clients et fournisseurs de s’affronter dans des joutes interminables, mais néanmoins nécessaires à la formation d’un contrat remplissant des garanties de sécurités suffisantes en adéquation avec le besoin client.

Notre expérience nous mène à souligner un certain nombre de clauses à inclure dans ce type de contrat :

• Clause limitative de responsabilité : Cette clause, primordiale, permettra tout simplement de fixer la répartition des responsabilités quant aux services externalisés dans le Cloud. Cette clause est extrêmement à l’avantage du fournisseur dans les contrats d’adhésions, le client étant alors responsable de tout ou presque.

• Clause d’auditabilité : Ici, il s’agira de définir sous quelles conditions le client pourra ordonner un audit de la plateforme qui héberge son service. Sans cette clause incluse au contrat, l’audit pourrait n’avoir comme périmètre que le contrat lui-même.

• Clause de confidentialité et non divulgation : Plus classique, cette clause engage le fournisseur sur ses actions par rapport aux données, mais se porte également garante de ses employés et sous-traitants. Il ne doit donc pas vendre les données, ni les réutiliser dans le cadre d’une autre activité, publicitaire par exemple.

• Clause de réversibilité : Autre clause importante, elle précise le plan de réversibilité, son déroulement, mais également ses éléments déclencheurs. C’est dans cette clause qu’est précisée la suppression des données en cas de réversibilité, élément impossible à vérifier dans les faits.

D’autres éléments seront à voir :

• La convention de niveau de service : Cette convention permet au client d’obtenir du prestataire une qualité de service convenue contractuellement. Il y a aura également des indicateurs sous forme de malus ou de pénalités en cas de non-respect des engagements. Ces niveaux de services peuvent être exprimés en heures et en pourcentages. La plupart du temps, ils concernent la disponibilité et la performance d’accès aux services.

• La localisation des données : (Objet de la partie 2 de cet article) La restriction de la répartition des données à un territoire défini, dans un cadre légal spécifique, est vivement recommandée, quand cela est possible.

• Le chiffrage de la valeur des données : Les avocats spécialisés conseillent grandement cette étape, qui permettra en cas de préjudice, de connaitre exactement la somme que le client peut réclamer en dédommagement.

Tous ces éléments indispensables à tout contrat portant sur une offre Cloud Computing tendent à compenser la très importante perte de contrôle du SI. Pourtant cela pourrait bien être peine perdue vu l’opacité totale dont font preuve les fournisseurs, dans leur traitement des données, sous couvert de préserver la confidentialité de ses clients.

Cet atelier pose les bases d’une réflexion sur le caractère multi-domaine de la notion des risques, et d’identifier la place de la sécurité de l’information dans cet ensemble.

Alors, pensez-vous qu’un management unifié des risque est possible ?

Construisez votre propre réponse en parcourant le support de présentation de notre atelier.

CONIX – Assises de la Sécurité 2012 – Management Unifié des Risques

Cette année, Sylvain CONCHON animera un atelier intitulé « le management unifié des risques est-il possible ? », le 4 octobre 2012 de 16h00 à 16h45. Cet atelier vise à poser les bases d’une réflexion sur le caractère multi-domaine de la gestion des risques, et d’identifier la place de la sécurité de l’information dans cet ensemble.

Venez nombreux nous retrouver à cette occasion.

Vous savez, nous savons, qu’aucun système d’information n’est absolument sécurisé. Ce qu’il faut retenir de cette rengaine estivale, c’est que même chez les grands, la sécurité peut être très loin de l’état de l’art. Donc reprenons tous en chœur : je ne stockerai pas mes mots de passe en clair. Je ne les chiffrerai pas non plus de façon réversible. Je n’utiliserai pas de fonction de hachage sans y ajouter un sel, unique, par utilisateur. Ce sel sera robuste cryptographiquement, et je le trouverai soit dans une des sources de hasard de mon serveur, soit en combinant plusieurs données aléatoires ou difficiles à deviner et en les faisant passer par la fonction de hachage que j’utilise.

Je vous entends, chers lecteurs, vous plaindre depuis vos transats : « Cette chanson n’a rien d’un tube de l’été! C’est abscons! Terrible à retenir! Et puis, surtout, tu ne nous a donné aucun conseil utile depuis le début de cet article! ». Je vous entends et vous réponds. Vous avez à votre disposition plusieurs fonctions de hachage reconnues par la communauté: SHA-256 ou SHA-512, Whirlpool, Blowfish… Prenez une fonction, de votre choix. Ou plusieurs, en combinaison. Cela ne fera que ralentir les attaques sur les mots de passe de vos utilisateurs, en demandant aux attaquants plus de force de calcul, et en rendant plus coûteuses les attaques utilisant un hardware dédié. Nous appellerons cette fonction HASH().

Maintenant, décidez d’un secret, et stockez ce secret dans le code source de votre application. Nous le noterons S_A, pour Secret Applicatif. Ce secret vous garantit que, même si votre base de mots de passe est compromise, l’attaquant n’aura pas toutes les cartes en main. Ensuite, à la création d’un mot de passe, stockez dans votre base de mots de passe S_U, le Secret Utilisateur, qui sera par exemple HASH(IP + timestamp + random() ) où random() est l’aléa de votre serveur. Vous pouvez, si vous le souhaitez, ajouter un autre secret, ou le User Agent, ou ce que vous voulez pour assurer une bonne entropie à ce secret.

Enfin, stockez à côté du S_U le mot de passe de l’utilisateur, chiffré de façon non réversible sous la forme HASH(S_A + S_U + Mot de passe). Vous pouvez à présent dormir sur vos deux oreilles, vous êtes à l’état de l’art, les mots de passe de vos utilisateurs sont bien protégés. Hein? Mais non, ne vous levez pas de vos transats, je n’ai pas fini! Ne pensez-vous pas qu’il y a un problème? Oui, vous, monsieur, dans le fond, je vous vois grimacer depuis tout à l’heure. Oui, vous. Vous me dites que? Que vous ne voyez pas pourquoi vous mettriez tant d’énergie à protéger les mots de passe de vos utilisateurs quand toutes leurs autres données ne sont pas protégées?

Vous avez bien raison. Il est évident que voir les mots de passe de tous ses utilisateurs publiés sur le Grand Internet est vexant. Cela vous rappelle l’époque où, à cause d’un billet moquant la petite Lucie Durand, avec ses dents en avant et son léger strabisme, billet passé à votre camarade de classe et intercepté par l’instituteur, vous avez passé un quart d’heure au coin coiffé d’un bonnet d’âne à souffrir les moqueries des autres élèves. Mais tout cela fait partie du passé, et ne vous a visiblement pas fait tant de mal que ça vue la fière allure que vous arborez aujourd’hui.

Les mots de passe de vos utilisateurs ne sont sûrement pas la donnée la plus importante que vous avez à protéger. Et si cela était le cas, permettez-moi de vous le dire, vous devriez reconsidérer le fait de les stocker, des alternatives existent. Et si un attaquant a accès aux mots de passe de vos utilisateurs, il a aussi accès à tout le reste! Protéger efficacement les mots de passe vous permettra peut-être de ne pas faire la une des journaux et d’éviter ainsi d’être la risée de vos petits camarades, mais empêcher l’accès à vos données et à celles de vos utilisateurs, quelles qu’elles soient, devrait être une priorité. N’oubliez pas que la perte ou divulgation de données personnelles est un délit puni de 5 ans de prison et 300 000 euros d’amende.

Bon, j’ai assez occupé votre temps précieux, nous avons tous bien mieux à faire que de m’écouter radoter ; vous avez du sable partout dans vos chaussures et ça ne serait pas sérieux d’en couvrir la moquette de vos bureaux, et moi j’ai piscine. A bientôt!

En premier lieu, il faut savoir que l’Internet est depuis son origine régi par un certain nombre de règles administratives dont l’IANA ⁽¹⁾ se pose en principal gestionnaire, en attribuant notamment, selon un découpage géographique, un numéro d’AS (Autonomous System), ainsi que des blocs d’adresses IP (IPv4 – pour un temps encore, pénuerie oblige – au profit d’IPv6 à terme) aux différents FAI ⁽²⁾ par l’intermédiaire de l’organisme RIR⁽³⁾ faisant autorité pour chacun des continents (ex : RIPE NCC ⁽⁴⁾ pour l’Europe). Charge ensuite à chacun des FAI, d’une part de gérer ses interconnexions au travers de nœuds d’échanges, dits « GIX » (Global Internet eXchange) ou « IX[P] » (Internet eXchange [Point]), avec les autres FAI moyennant accords d’appairage (peering) ou de transit (selon le statut du FAI, à savoir Tier-1 international, Tier-2 national ou Tier-3 régional/local), et d’autre part de gérer ses propres ressources vis-à-vis de ses clients finaux respectifs, à savoir professionnels et/ou grand public, pour les raccorder à Internet.

Par ailleurs, il n’est peut-être pas non plus inutile de rappeler ici que la structure du stack IP ne prévoit en standard aucun mécanisme permettant d’authentifier l’émetteur des paquets IP. En effet, seul une somme de contrôle (checksum), recalculée par chaque équipement de routage, se limitera basiquement à prouver l’intégrité de l’entête IP au prochain saut (next hop), le paquet étant rejeté par ce dernier dans le cas contraire. Quand aux couches supérieures (cad. transport, session, présentation, application), celles-ci ne sont, pour l’heure, pas traitées par les routeurs de l’Internet (excepté peut-être dans certains pays au régime politique plus ou moins permissif sur le contenu des communications …), et ce, principalement pour des raisons de performance, mais aussi de domaine de responsabilité des FAI, ce que l’on comprendra aisément.

Qui plus est, la pile IP n’interdit pas pour autant de modifier (ou « forger ») n’importe quel champ, et a fortiori celui de l’IP source. Ainsi, l’usurpation d’adresse IP (IP spoofing ou IP hijacking) en amont, à savoir au niveau de la machine hôte émettrice des paquets alors falsifiés, relève d’une opération on ne peut plus triviale.

Fort de ces constats, dans l’hypothèse (en risque « brut ») où aucune mesure de contrôle de cohérence de l’entête IP ne serait appliquée par les FAI, rien ne s’opposerait à ce que des paquets à l’IP source falsifiée circulent sur l’Internet pour atteindre la destination visée, ne serait-ce que pour exercer une ou plusieurs attaques par dénis de service [distribué] ([D]DoS) sans dévoiler l’origine de l’attaque, ou encore en usurpant une adresse IP, voire un bloc d’adresses, dont le titulaire (alors victime indirecte) passerait à tord pour l’agresseur. Autre cas de figure, si une intrusion était réussie sur un routeur de FAI mal sécurisé, rien n’empêcherait non plus de faire annoncer et propager par celui-ci des subnets IP illégitimes sur le backbone Internet, et ce, dans le but de détourner tout ou partie du trafic destiné au titulaire officiel d’une ou plusieurs adresses IP appartenant à ces mêmes subnets. Tels seraient ainsi les vulnérabilités brutes (parmi d’autres) du World Wide Web portant indubitablement atteinte à la fiabilité que l’on voudra bien lui prêter.

Dans la réalité, l’hypothèse avancée ci-dessus est loin d’être théorique puisqu’il est avéré que des adresses, des blocs (routes) et même des numéros d’AS sensés être réservés à un usage privé ou spécifique – on les désignera alors par les termes « martians » ou « bogons » (à savoir non conforme aux RFC 1918 – Address Allocation for Private Internet et RFC 5735 – Special Use IPv4 Addresses, non attribués par l’IANA, ou encore au format invalide) – se retrouvent effectivement bel et bien sur l’Internet, et ce, de façon récurrente (cf. RIS debogon project du RIPE, ANA spoofer project du MIT, ou site Team Cymru).

Extrait d’un Summary Report de l’ANA spoofer project (MIT)

Ceci étant, des conventions de bonne gestion des accès à Internet par les FAI sont établies et visent à mettre en place des garde-fous notamment basés sur l’application de bonnes pratiques en matière d’anti-spoofing. Ainsi, un certain nombre de guides relatifs aux mesures préventives sont aujourd’hui publiés et tenus à jour au travers des séries RFC/BCP ⁽⁵⁾ de l’IETF ⁽⁶⁾, des livres blancs du SANS Institute ou d’autres acteurs officiant dans le secteur des télécoms comme le forum NSP-SEC.

On pourra notamment citer les textes de références suivants en termes de bonnes pratiques traitant des techniques d’anti-spoofing, adressés en premier lieu aux FAI :

• RFC 3013 (BCP46) - Recommended ISP security services and procedures
• RFC 2827 (BCP38) - Network Ingress Filtering: Defeating DoS Attacks which employ IP source address spoofing
• RFC 3704 (BCP84) en révision du RFC 2827 - Ingress filtering for multihomed Networks

A titre d’exemple, intéressons-nous aux mesures de sécurité suivantes citées en recommandations :

• Sécurisation des routeurs (filtrage ACL, cloisonnement Management plane / Control plane / Data plane, désactivation de services superflus, authentification radius/AAA, management par protocole sécurisés SSHv2/SNMPv3, etc…) : consiste à restreindre l’accessibilité du routeur au maximum en rejetant tout trafic utilisateur destiné aux interfaces locales ou loopback du routeur et susceptible de prendre le contrôle sur ce dernier par intrusion ou bien de perturber son fonctionnement par dénis de service.
• Authentification mutuelle par hash MD5 (RFC 2385 – Protection of BGP Sessions via the TCP MD5 Signature Option) : configurée sur les protocole de routage dynamique (en l’occurrence BGP) pour les annonces de routes.
• BGP TTL (Time to Live) Security Check (RFC 3682 – Generalized TTL Security Mechanism) : consiste à rejeter tout paquet (potentiellement forgé) transportant des annonces BGP dont le TTL (ou Hop Limit en IPv6) n’est pas de 254 (le compteur TTL initialement fixé à 255 par le routeur adjacent est en effet sensé être décrémenté d’un saut).
• Filtrage max-prefix et longueur d’AS-Path (chemin d’AS) des annonces par BGP : consiste au niveau du peering, à prévenir contre la propagation de routes erronées vers les autres FAI en fixant un seuil correspondant à un nombre maximum de blocs échangés par session eBGP.
• Filtrage des paquets IP avec option source routing (routage par la source) : consiste à bloquer les paquets portant notamment l’option LSRR (Loose Source and Record Route) spécifiant au routeur le chemin à appliquer pour router le paquet.
• Filtrage statique par ACL (Access Control List) en entrée/sortie (ingress/egress) au niveau des Edge routers : consiste à bloquer les paquets sortant (vers Internet) si l’adresse appartient à un réseau qui n’est pas alloué au client, voire à bloquer les paquets entrant (depuis Internet) si l’adresse appartient à un réseau alloué au client.
• Filtrage statique des annonces BGP en entrée/sortie (ingress/egress) par ACL de prefix-list (liste de blocs) et AS-Path : consiste à appliquer un filtrage sur l’apprentissage et les annonces de routes à partir de black-list (ex : subnets RFC 1918, RFC 5735, bogons) ou white-list (blocs attribué au FAI adjacent), éventuellement combinable au récent mécanisme de contrôle par signature ROA (Route Origin Authorization) conformément au RFC 6483 - Validation of Route Origination using the Resource Certificate PKI and ROA.
• Filtrage uRPF (unicast Reverse Path Forwarding ou « contrôle du routage inverse ») et black list (liste noire) : consiste à vérifier la présence d’une entrée (route et interface associée) correspondant à l’IP source des paquets entrants dans la table de routage de la FIB (Forwarding Information Base) et à le détruire dans le cas contraire. Ce mécanisme préventif couplé au routage BGP est autonome lorsque implémenté, en mode strict, au niveau des Edge routers pour les clients à raccordement unique (single-homed connection). En cas de routage asymétrique (cas des Border routers au niveau du peering notamment, ou des multi-homed connections sur Edge routeurs), le mode Loose permet de ne pas contrôler l’interface d’entrée.
• Filtrage RTBH avec uRPF (RFC  5635 - RTBH filtering with uRPF) : le mécanisme précédent combiné au filtrage RTBH (Remote Triggered Black Hole, défini dans le RFC 3882 - Configuring BGP to Block DoS Attacks) consiste à déclencher manuellement (donc en mode réactif) mais de façon centralisée (à partir d’un Trigger router prévu à cet effet, alors à l’origine de la propagation par annonces de routes BGP au sein de l’AS du FAI), une redirection de l’ensemble du trafic estimé illicite à destination d’un subnet IP cible de l’attaque vers un « trou noir » (black hole) concrétisé par une interface null. Cela revient au final à détruire lesdits paquets par le routage (moins consommateur en ressources systèmes que le filtrage) et ainsi à neutraliser l’attaque identifiée. A noter que ce type de mécanisme semi-automatisé est à « double tranchant », et lorsque implémenté ou exploité sans certaines précautions d’usage, celui-ci comporte de nouveaux risques induits pouvant typiquement conduire à un déni de service impactant du trafic légitime, induisant ainsi des « faux positifs » sur un subnet client à l’IP usurpée ou un subnet cible donné. On imagine alors aisément les dommages collatéraux pour ces derniers …

Filtrage RTBH basé sur la source (livre blanc Cisco Systems – RTBH filtering)

En complément de ces quelques mesures non exhaustives, plus ou moins efficaces et exploitables, il est à préciser ici que l’adoption progressive du protocole IPv6 sur l’Internet ne constitue pas spécialement une avancée significative en termes de sécurité de l’infrastructure de transport. En effet, si IPv6 permet potentiellement de conserver une même adresse IPv6 pour une machine se connectant via des point d’accès différents, les problématiques et contre-mesures exposées précédemment restent tout autant d’actualité. A noter à ce titre l’existence du RFC 4832 : Security Threats to Network-Based Localized Mobility Management (NETLMM), qui adresse spécifiquement les menaces liées à la mobilité s’appuyant sur le protocole PMIPv6 (Proxy Mobile IPv6 – RFC 5213).

Le but de la présente démonstration était de rappeler que l’Internet, bien que délivrant des services de plus en plus critiques (paradoxe de l’ère du Cloud, notamment public), reste à ce jour un réseau de transport, étendu à l’échelle de la planète, manifestement encore loin d’être infaillible, auquel une confiance relativement limitée doit être accordée dans la mesure où la sécurité de l’infrastructure réseaux et télécoms, ainsi que des services d’infrastructure (comme la résolution de noms DNS avec un BIND qui n’est pas en reste en matière de vulnérabilités récurrentes) est confiée à la charge d’une constellation de FAI disposant d’une couverture et de structures nivelées, auxquels il appartient de mettre en œuvre (ou pas) les bonnes pratiques d’usage selon le niveau de maturité de leur processus. C’est donc bien à juste titre que les solutions de cloisonnement réseau (type pare-feu, UTM, …) associent à l’accès Internet le terme « untrust », désignant par là-même une zone ou interface réputée de « non confiance » !

⁽¹⁾ Internet Assigned Numbers Authority

⁽²⁾ Fournisseur d’Accès Internet

⁽³⁾ Registre Internet Régional

⁽⁴⁾ Réseaux IP Européens – Network Coordination Centre

⁽⁵⁾ Request For Comments / Best Current Practices

⁽⁶⁾ Internet Engineering Task Force

Nous avons vu dans un précédent article les hooks possibles au sein d’un processus sous Windows. Nous allons voir maintenant les principales techniques de hooks possibles dans le kernel Windows x86 (sous x64, les techniques diffèrent radicalement à cause de Patch Guard). Nous ne détaillerons pas chaque technique, pour des exemples, voir la partie « Références & Exemples » en bas de page.

Hooks kernel-land (ring 0)

L’intérêt de placer des hooks dans le kernel est multiple, et dépend du contexte de leur emploi :

• C’est le niveau le plus « bas » possible où placer un hook. Il est donc possible d’intercepter tous les appels de l’userland à une fonction, sans possibilité de contournement, ainsi qu’une très large majorité des appels du kernel.
• Au niveau kernel, tout (ou presque) est possible.
• Leur détection ne peut être effectuée que par un code lui-même chargé dans le kernel, donc dans le même espace mémoire, et pouvant potentiellement être corrompu / trompé.

Les hooks kernel-land peuvent être situés à différents endroits, souvent dans une des (nombreuses) tables du kernel :

• Le hook System Service Descriptor Table¹ ou SSDT, consiste à modifier les entrées de la table ServiceTableBase de la structure KeServiceDescriptorTable, qui référence les fonctions Nt* du kernel (généralement les plus critiques, comme NtTerminateProcess, par exemple). Il suffit alors, à l’instar des hooks IAT de modifier l’adresse d’une de ces fonctions pour la faire pointer sur d’autres instructions. La détection passe en vérifiant l’intégrité de cette table (les fonctions doivent pointer pour la plupart dans le module du kernel Windows ntoskrnl).
• Le hook Interrupt Descriptor Table² ou IDT, consiste à modifier les entrées des tables (une par coeur de processeur) InterruptDescriptorTable qui référencent les handlers d’interruptions reçues par le processeur (comme par exemple l’interruption 1 qui correspond à un breakpoint hardware). La détection passe aussi en vérifiant l’intégrité de cette table, les 256 entrées étant normalement gérées par le kernel Windows.
• Le hook Interrupt Request Packet³ ou IRP, consiste lui à modifier la table des fonctions I/O Request Packet d’un module kernel. Cette table référence les adresses des handlers des I/O request packet, utilisés pour gérer des requêtes diverses et variées, que ce soit depuis l’espace utilisateur (ring 3) ou depuis le kernel (ring 0). La détection passe toujours par la vérification de l’intégrité de cette table, en vérifiant que ces handlers sont soit les handlers par défaut (kernel Windows ntoskrnl, ou dans certains cas, d’autres modules comme NDIS.sys), soit dans le module courant.
• Le hook sysenter⁴ consiste à modifier le champ SYSENTER_EIP_MSR du Model Specific Register (MSR), définissant le handler des instructions SYSENTER / SYSCALL depuis l’userland, indiquant un appel au kernel (anciennement l’interruption 0x2E). Il est donc possible d’intercepter tous les appels à des fonctions depuis l’espace utilisateur (sauf utilisation d’interruptions 0x2E). Il suffit de vérifier que sa valeur pointe bien dans l’espace mémoire du kernel Windows pour détecter une éventuelle modification.
• Le hook inline consiste, comme son pendant userland, à poser une indirection sur une fonction en mémoire. Sa détection est identique à celle en ring 3 : il est possible de ne vérifier que les premiers octets de chaque fonction à la recherche d’une indirection (peu fiable), ou de vérifier l’intégrité de la section de code du module en comparant celle du module et celle de son binaire sur le disque (plus fiable).
• Le hook DKOM⁵ (pour Direct Kernel Object Manipulation), très spécifique aux rootkits, consiste à modifier des objets du kernel (liste des processus, des threads, des drivers, etc.) en mémoire de façon à cacher des informations. La détection de tels hooks ne peut être effectuée qu’avec une bonne connaissance de la structure de Windows, puisqu’il faut retrouver ces informations dans d’autres structures, ou au sein de certaines fonctions.

Nous avons vu ici les hooks kernel-land que les plus communs, ainsi que quelques idées pour détecter ces derniers de façon automatisée. Leurs avantages et inconvénients par rapport aux hooks userland dépendent du contexte de leur emploi, et chaque type de hook est spécifique à une utilisation donnée.

Par exemple, certains antivirus utilisent des hooks SSDT pour protéger leurs processus de malwares qui chercheraient à les terminer. Des anti-debogueurs effectueront plutôt un hook IDT pour bloquer l’utilisation des breakpoints (interruptions 1 & 3). Certains malwares utiliseront, eux, des hooks inline ou IAT au sein de processus pour tenter d’intercepter des informations sensibles comme des mots de passe, des cookies, etc. On notera que sur les systèmes Windows 64 bits, les drivers doivent être signés numériquement et PatchGuard interdit la modification du kernel (ce qui laisse toutefois quelques techniques réalisables).

Références & exemples :

1- Hook SSDT : http://www.ivanlef0u.tuxfamily.org/?p=63 , http://www.shp-box.fr/blog/en/227

2- Hook IDT : http://www.shp-box.fr/blog/266 , http://uninformed.org/index.cgi?v=8&a=2&p=8

3- Hook IRP : http://www.ivanlef0u.tuxfamily.org/?p=45

4- Hook de l’instruction SYSENTER via la modification du registre MSR :

http://read.pudn.com/downloads151/sourcecode/windows/freedic/655298/SysEnterHook/sysenter.c__.htm

5- Hook DKOM : http://0vercl0k.blogspot.com/2008/02/first-steps-into-ring0.html

Un très bon livre pour s’initier aux hooks kernel-land : http://books.google.fr/books/about/Rootkits.html?id=XKsl5SZyfS4C

Plusieurs types de hooks présentés : http://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Aiko/bh-jp-08-Aiko-EN.pdf

Une fois n’est pas coutume, nous allons illustrer les travaux que nous effectuons en Recherche et développement à travers quelques articles techniques. Les deux premiers de ces articles porteront sur l’API hooking sur des systèmes Windows, une technique assez utilisée dans le domaine de la sécurité informatique, que ce soit au sein de logiciels anti-intrusions (HIPS / HIDS), de malwares, ou lors de patchs de binaires.

L’API hooking consiste à détourner des appels de procédures sous Windows, pour diverses raisons :

• Modifier l’appel ou le retour de la procédure : cela peut être utilisé par des programmes afin de cacher des données (processus, fichiers…), voler des informations (mots de passe, cookies…), se protéger (empêcher un kill d’un processus…), protéger l’intégrité du système en détectant des activités suspectes (ouverture de connexion…). Par exemple, un rootkit cherchera à intercepter les appels aux fonctions permettant de lister un répertoire pour cacher ses fichiers en altérant leur retour.
• Tracer l’appel de certaines procédures : utilisé pour faire de la couverture de code dans plusieurs contextes (analyse de malwares, fuzzing, etc.).

Nous allons voir dans cet article plusieurs techniques de « hooking » en espace utilisateur (ring 3) couramment employées sous Windows, ainsi que la façon de les détecter de façon automatisée. Nous n’aborderons pas ces techniques dans le détail (je vous laisserai vous reporter en bas de page aux références et aux exemples donnés), et nous nous contenterons seulement de les décrire.

Les hooks « userland » (ring 3) sous Windows

Nous allons d’abord analyser les hooks “userland” sous Windows, c’est-à-dire au sein d’un même processus dans l’espace utilisateur.

• Le hook inline¹ consiste à remplacer les premiers octets d’une fonction par une indirection vers une fonction de détournement. Les octets écrasés seront sauvegardés (principe du trampoline), puis restaurés lors du retour. Il existe plusieurs types d’indirections, dont le hot patch qui a pour intérêt de ne pas écraser d’instructions importantes, simplifiant la mise en place. Ce type de hook peut être détecté en analysant les premiers octets de la fonction (peu fiable), ou en comparant les sections de code du module en mémoire et de son binaire sur le disque (plus fiable mais plus complexe si le code est relogé en mémoire).

Principe du Hook inline. Il est possible d’altérer le retour (ou l’appel) à la fonction.

• Le hook Import Address Table² ou IAT, consiste à patcher la table d’importation d’un module, qui contient les adresses des fonctions importées par le module. En effet,  les adresses des fonctions pouvant changer (ASLR, code relogé…), le loader de Windows remplit cette table de correspondances lors du chargement du module en mémoire. Il suffit ici de modifier l’adresse d’une fonction dans cette table pour détourner les appels utilisant cette fonctionnalité (une large majorité). Pour détecter ce type de hook, il suffit de vérifier que l’adresse de chaque entrée pointe bien dans la bonne plage mémoire (celle du module exportant la fonction). Il est également possible de modifier la table d’exportation (hook Export Address Table) du module exportant la fonction, pour tromper certaines fonctions Windows (GetProcAddress) / compliquer la détection du hook.

Principe du Hook IAT.

• Il est possible de modifier le comportement d’un processus en utilisant un débogueur³. Ce dernier va placer des points d’arrêts (software ou hardware) sur les instructions intéressantes, catcher les exceptions, puis modifier des données dans le processus cible en manipulant les registres et/ou la mémoire du processus. La plupart des détections anti débogueur fonctionnent ici (IsDebuggerPresent, vérification de la présence d’interruptions, analyse des registres de débug, calcul de temps d’exécution, etc.).
• Enfin, le PEB hijacking⁴ consiste à modifier des membres de la structure Process Environment Block (qui liste les modules en mémoire entre autres), de façon à faire passer un module lambda pour un module légitime, qui contiendra les mêmes exportations, et qui appellera les fonctions du module remplacé de façon transparente. Il est couplé à des hooks IAT, et permet de compliquer leur détection. On peut détecter cette pratique en comparant le module et son binaire sur le disque (une comparaison des entêtes suffit généralement).

A titre de remarque, il est toujours préférable de se placer le plus proche possible du kernel. Par exemple, un appel à CreateProcessA conduira à un appel à CreateProcessW, puis à ZwCreateProcess, qui appellera le NtCreateProcess dans le kernel. Plutôt que de poser 3 hooks, il vaut mieux en poser un unique sur ZwCreateProcess, puisque cette fonction sera toujours appelée.

Nous avons donc vu les hooks les plus courants (et les plus simples) au sein d’un même processus. Ces techniques peuvent être détectées généralement assez simplement. D’autres techniques sont possibles mais sont généralement moins utilisées (par exemple, patch de la Junk Thunk Table⁵). Il est également possible de complexifier ces techniques pour rendre leur détection plus ardue.

La limite principale de ces hooks est qu’il est toujours possible de les détecter au sein d’un processus, et d’appeler directement les fonctions du kernel sans passer par les APIs Microsoft. Nous verrons donc dans un prochain article les hooks pouvant être effectués dans le kernel Windows.

Références & exemples :

1- Hooks inline : http://www.ivanlef0u.tuxfamily.org/?p=24

2- Hooks IAT : http://0vercl0k.blogspot.com/2007/11/api-hooking-iat-patching.html

3- Malicious debugger : http://esec-lab.sogeti.com/post/2007/10/03/13-malicious-debugger-1-3

4- PEB hook : http://arsouyes.org/index.php?id=314

5- Junk Thunk Table : http://blog.zenk-security.com/index.php/2011/07/02/iathooking/

L’API MsDetours de Microsoft : http://research.microsoft.com/en-us/projects/detours/

Quelques techniques utilisées par des malwares : http://www.tdeig.ch/windows/wenger_M.pdf

Un très bon livre sur les rootkits : http://books.google.fr/books/about/Rootkits.html?id=XKsl5SZyfS4C