[Newsletter HSC] N°57 - Mai 2009
Newsletter d'information de HSC
newsletter at hsc-news.com
Lun 4 Mai 16:11:45 CEST 2009
========================================================================
HSC Newsletter -- N°057 -- mai 2009
========================================================================
"La grippe, ça dure huit jours si on la soigne
et une semaine si on ne fait rien."
[Raymond Devos]
--[ Sommaire ]----------------------------------------------------------
1. Editorial
2. Le saviez vous ? La question
3. Compte-rendu de BlackHat Amsterdam
4. Prix de l'Innovation des Assises de la Sécurité
5. Nouveautés du web HSC
6. Agenda des interventions publiques
7. Veille en vulnérabilités HSC
8. Prochaines formations HSC
9. Offres d'emploi, 6 postes à pourvoir !
10. Actualité des associations : Club 27001, OSSIR et Club PCA
11. Le saviez vous ? La réponse
--[ 1. Editorial - Hervé Schauer ]--------------------------------------
Il y a quelques années, je n'hésitais pas à citer la virtualisation
comme une des technologies pouvant apporter une partie des solutions
techniques lors d'un plan de secours informatique.
Depuis, HSC a eu l'opportunité d'auditer des architectures virtualisées,
notamment à plusieurs reprises sur des architectures VMware, d'auditer
la sécurité de firewalls dans des architectures virtualisées, d'auditer des
réseaux virtualisés, d'auditer également la sécurité de SAN, interconnectés
avec des architectures virtualisées, ainsi que de réaliser des études en
sécurité nous ayant permis de rechercher des failles dans les logiciels
de virtualisation, et enfin de faire des tests d'intrusion externes,
ayant permis par exemple, d'accéder à la console de gestion de VMware
depuis internet.
Comme le domaine de la virtualisation a changé, mon avis est désormais
que la virtualisation peut apporter plus de problèmes de sécurité qu'elle
n'en résolve.
Les processeurs récents ont intégré des fonctionnalités spécifiques au
support de la virtualisation, Loïc Duflot (DCSSI) a montré qu'il était
possible d'exécuter du code en dessous de l'hyperviseur de virtualisation.
Les Pentium d'Intel sont devenus tellement complexes qu'ils ne peuvent
être exempts de bogues de sécurité, mais qui met à jour le microcode
de ses processeurs Intel avec les correctifs de sécurité ?
Certes l'attaque n'est pas triviale, le code n'est pas public, mais dans
le passé d'autres attaques non triviales se sont popularisées quelques
années plus tard. Nous sommes donc certains de ne jamais avoir de
virtualisation fiable à 100%, car nous ne pourrons jamais assurer que le
processeur n'a pas de bogues permettant de faire changer d'état un
hyperviseur de virtualisation.
Dans les hyperviseurs eux-mêmes, des failles ont permis de lire la
mémoire virtuelle dans une autre instance des machines virtuelles que la
sienne, ou bien ont permis de faire exécuter du code arbitraire par
l'hyperviseur, par exemple via des pilotes de périphériques avec des
débordements de tampon.
Les architectures virtualisées nous apportent en terme de réseau un
plat de spaghettis invraisemblable, que généralement seuls les auditeurs
de sécurité modélisent à chaque niveau de réseau, pour découvrir que
le filtrage n'est plus là où le client le croyait. L'intégration de la
virtualisation n'est pas neutre au niveau IP vue la complexité des flux
indispensables pour que les logiciels de virtualisation fonctionnent :
pour la licence, pour l'administration, etc.
Les systèmes d'administration des systèmes de virtualisation sont
aussi victimes des vulnérabilités habituelles comme les mots de passe
par défaut triviaux et jamais changés pour que la maintenance fonctionne.
L'application des correctifs de sécurité sur les serveurs est déjà
une tâche complexe, mais alors que dire de l'application des correctifs
de sécurité de VMware sur un système de dizaines de machines virtuelles ?
L'organisation des rôles et des responsabilités est elle aussi plus
complexe, faire qu'une équipe de développement qui réalise des recettes
d'applications n'ait accès qu'à une machine virtuelle de recette et non pas à
une machine virtuelle de production est plus facile à dire qu'à garantir
dans une architecture virtualisée.
Le stockage est aussi moins sécurisé avec les machines virtuelles.
Les SAN se partitionnaient afin par exemple que les serveurs de l'ERP ne
voient que les disques de l'ERP, que les serveurs Windows ne voient que
les disques Windows, etc. Avec les infrastructures virtualisées, le SAN
ne voit plus qu'une seule machine au niveau fiber channel, le pilote du
SAN est virtualisé lui aussi pour avoir les statistiques de transfert,
et le partitionnement du SAN ne sert plus, un hyperviseur comme VMware
voit tous les disques et c'est un commutateur virtuel qui segmente. Même
si une extension sur fiber channel destinée à virtualiser les adresses existe
elle n'est généralement pas encore supportée.
Il faut maintenant ajouter les firewalls virtuels, avec plusieurs
machines virtuelles de filtrage dans le même équipement avec des politiques
de filtrage distinctes. Là, le plat de spaghettis atteint son apogée, il
faut vraiment redessiner la réalité à chaque niveau réseau pour y voir clair
et ne pas faire d'erreur. Plus personne ne sait où est fait le traitement
des flux, qui a accès à quoi, comment ça marche.
Le manque de maîtrise est le maître mot de la virtualisation et aussi
du "Cloud" ou du "SaaS" que l'on place au dessus. Nous remplaçons des
opérateurs qui rackaient des serveurs et branchaient des câbles par
des ingénieurs (?) qui doivent créer des architectures complexes à gérer.
Les gains économiques et écologiques ne sont pas aussi évidents que le
marketing veut le faire croire : l'administration n'est pas virtualisable,
et les audits de sécurité ne sont pas virtualisables non plus.
Il m'apparaît trop dangereux d'intégrer dans un même hyperviseur
des machines virtuelles de niveaux de sécurité différents comme du
back-office, du front-office, des machines en DMZ et des serveurs sur
Internet. Il faut garder un minimum de segmentation maîtrisée, et
utiliser la virtualisation dans son bastion applicatif interne, bien
cloisonné du reste des réseaux internes et d'Internet.
Pour en savoir plus, les présentations HSC sur le sujet :
http://www.hsc.fr/ressources/presentations/ossir_vmware_2008/
http://www.hsc.fr/ressources/presentations/clusif-virtualisation/
http://www.hsc.fr/ressources/presentations/cio-virtualisation/
La présentation de Loïc Duflot :
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/pacsec2007-duflot-papier.pdf
--[ 2. Le saviez vous ? La question ]-----------------------------------
Comment, lors de votre première connexion à un serveur SSH, vous assurez-vous
de la validité de sa clé ?
--[ 3. Compte-rendu de BlackHat Amsterdam ]-----------------------------
par Jean-Baptiste Aviat
L'édition 2009 de Black Hat Europe s'est déroulée à Amsterdam, sans doute
pour la dernière fois, puisqu'il semblerait qu'en 2010, ce rassemblement aura
lieu à Barcelone.
.NET Framework Rootkits: Backdoors inside your Framework, Erez Metula
=====================================================================
Cette présentation porte sur une technique post exploitation, consistant à
usurper certaines bibliothèques du framework .NET. Les droits administrateurs
sont nécessaires pour effectuer ces modifications.
Un rappel de la structure d'une architecture .NET a été effectué avant de
présenter la technique de remplacement de librairies.
La signature de la DLL du chargeur .NET est utilisée comme nom de répertoire :
c:\windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c56765d795\
Le 'loader' prend la DLL dans ce répertoire, mais ne vérifie pas sa signature.
Celle-ci est vérifiée pour les bibliothèques utilisateur, et en cas d'invalidité,
le programme n'est pas exécuté.
La modification du framework suit le schéma suivant :
- localiser la DLL ;
- la décompiler :
ILDASM mscorlib.dll /OUT=mscorlib.dll.il /NOBAR /LINENUM /SOURCE
- la reprogrammer selon nos souhaits, puis la recompiler :
ILASM /DEBUG /DLL /QUIET /OUTPUT=mscorlib.dll mscorlib.dll.il
- forcer le framework à l'utiliser en effaçant le cache NGEN ;
ngen uninstall mscorlib
- supprimer nos traces.
La phase de reprogrammation, après le désassemblage, se fait en utilisant
MSIL :
Microsoft Intermediate Language.
IL_0000: call class System.IO.TextWriter System.Console::get_Out()
IL_0005: ldarg.0
IL_0006: callvirt instance void System.IO.TextWriter::WriteLine(string)
IL_000b: ret
L'auteur a écrit les méthodes suivantes :
- SendToUrl(string url, string data) : on envoie les données à une URL
spécifique ;
- ReverseShell(string ip, int32 port) : la machine initie un connect sur l'IP
et le port passés en argument pour donner un shell à l'attaquant.
Le logiciel ".NET sploit", création de l'orateur, automatise la création et le
déploiement des DLL, en permettant de :
- créer une nouvelle méthode ;
- référencer des fonctions extérieures ;
- exécuter des fonctions.
Il est possible d'écrire ses méthodes en tout langage .NET (C#...) : il
suffit de compiler son code source, puis de le décompiler selon la méthode
présentée ci-dessus, pour obtenir le MSIL.
Plus d'informations peuvent être obtenues sur le site de l'auteur,
http://www.applicationsecurity.co.il/english/NETFrameworkRootkits/tabid/161/Default.aspx
[NGEN] http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.71).aspx
"Stripping SSL To Defeat HTTPS In Practice", Moxie Marlinspike
==============================================================
Dans cette présentation, Moxie Marlinspike a présenté sa méthode permettant
de déjouer l'utilisation de SSL dans la plupart des sites Web grand public,
sans que l'utilisateur ne puisse le remarquer, à la condition de pouvoir
effectuer une attaque de l'intercepteur ('man in the middle').
Aujourd'hui, les navigateurs présentent des messages d'erreurs déroutant les
utilisateurs si le certificat SSL utilisé par le site est invalide. Marlin a
alors amélioré le logiciel sslsnif pour modifier le HTML intercepté de la
façon suivante :
- <a href="https:// => <a href="http://
- <form action="https:// => <form action="http://
Les requêtes du navigateur demandant l'icone du site web (favicon.ico) sont
interceptées, et une icone en forme de cadenas est renvoyée. L'utilisateur
voit alors un cadenas, et aucune alerte de sécurité : la plupart des
utilisateurs ne remarquent pas que la barre d'adresse contient une adresse
HTTP, et non HTTPS.
Le problème des Secure Cookie est réglé en enlevant simplement l'attribut
Secure sur les headers Set-Cookie envoyés par le serveur.
Pour forcer l'utilisateur à envoyer son mot de passe alors qu'il utilise un
cookie, sslsnif renvoie une réponse 302 pour la même URL avec Set-Cookie
expirant tous les cookies envoyés par le client, ainsi la requête s'effectue
à nouveau et l'utilisateur devra s'authentifier.
La façon la plus simple de se prémunir contre ce genre d'attaques est de
taper soi-même l'adresse HTTPS, et de ne pas faire confiance au site web
pour nous rediriger vers une page sécurisée par une connexion HTTPS.
Cette méthode a été appliquée sur un noeud Tor, où Marvin a pu obtenir de
nombreux couples login / mot de passe... et même à Black Hat, où il a
présenté une diapositive contenant de nombreux mots de passe.
sslstrip : www.thoughtcrime.org
"Alice in User-Land: Hijacking the Linux Kernel via /dev/mem"
Anthony Linberry
=============================================================
Anthony Linberry présente ici sa méthode d'injection de code en espace
noyau via l'utilisation du fichier /dev/mem. Cette méthode est beaucoup
plus discrète que l'utilisation d'un LKM.
Méthodes usuelles de protection :
- vérifier les tables systèmes : sys_call_table, IDT, etc ;
- 'hasher' les sections de code critiques ;
- obliger à signer les modules ;
- interdire l'utilisation de modules.
Ces méthodes de protection peuvent être déjouées en utilisant une méthode
d'injection en mémoire, décrite ci-après.
Le périphérique /dev/mem est une interface pour addresser la mémoire
physique. La première difficulté consiste à réaliser la correspondance entre
les adresses physiques et les adresses virtuelles. Il faut ensuite localiser
les structures importantes telles que IDT, sys_call_table, kmalloc(), etc.
L'IDTR est une structure avec l'adresse de l'IDT, on peut trouver son adresse
avec l'instruction assembleur SIDT, qui peut être appelée en espace
utilisateur (ne fonctionne pas dans une VM) :
struct idtr {
uint16_t limit ;
unsigned long base ;
} attribute (( packed )) ;
__asm__("sidt %0" : "=m"(idtr));
idtr.base + (0x80 * 8) => system_call
Le code à injecter peut être placé :
- dans l'espace mémoire noyau, sans garantie que l'espace libre utilisé ne
sera pas récupéré ultérieurement par le noyau ;
- dans des "guard pages" (pages non allouées) ;
- dans de l'espace alloué à l'aide de __kmalloc() : il faut alors trouver
l'adresse de kmalloc, à l'aide d'heuristiques ou utilisant kstrtab, la
table des symboles intégrée.
L'auteur a écrit la bilbiothèque libmemrk, qui possède les fonctions
suivantes : ukmalloc, kmalloc, kmemcpy, mais également des fonctions propres
aux appels systèmes : get_syscall, set_syscall, create_new_syscall.
Un processus utilisateur ne devrait pas pouvoir lire au delà de 16k dans la
mémoire physique, ce qui a été corrigé par le noyau 2.6.26 (option
STRICT_DEVMEM), mais n'est pas activé par défaut.
"SAP Penetration Testing", Mariano Nunez Di Croce
=================================================
Mariano Nunez Di Croce, pentester expert SAP, a résumé les principales
techniques d'exploitation de cet ERP, et a présenté Sapyto, sa création pour
faciliter la recherche d'informations et la découverte de faille dans ces
environnements.
La fonction sapinfo, qui retourne des informations sur le système, peut être
appelée de façon distante et anonyme par défaut, à la manière des RPC sous
Windows.
Il existe un grand nombre d'utilisateurs par défaut, dont les mots de passe
par défaut sont souvent inchangés.
Le rapport SAP RSUSR003 peut être utilisé pour afficher, à l'aide d'un client
lourd, toutes les options relatives à la connexion des utilisateurs. Il
indique également quels utilisateurs possèdent un mot de passe par défaut.
Stack Smashing as of Today: A State-of-the-art Overview on Buffer Overflow
Protections on linux_x86_64, Hagen Fritsch
==========================================================================
Durant cette conférence, Hagen Fritsch a décrit plusieurs méthodes servant à
outrepasser les protections de type ASLR ou NX sur les architectures 64 bits.
Bit NX
------
On peut se passer de code étranger pour exécuter des commandes, puisque tout
système a des bibliothèques : appeler system("/bin/sh") peut être légal.
Les instructions permettant de passer des arguments à une fonction (mov %rdi,
arg1 et call foo en x86-64) se trouvent dans des bibliothèques systèmes, par
exemple à @__gconv+347. Le bit NX n'est donc pas une protection suffisante.
ASLR (Adress Space Layout Randomization)
----------------------------------------
Le tas, la pile et les bibliothèques sont mappées à des adresses aléatoires.
La taille de l'aléa dépend de l'implémentation de l'ASLR.
Sur une architecture 32 bits, il est possible d'énumérer (par "brute forcce")
les 8 bits d'aléa. Sur architecture 64 bits, l'aléa est sur 20 bits, ce qui
rend cette attaque beaucoup plus difficile.
Trois autres techniques de détournement existent cependant :
1. Heap spray (qui fonctionne en cas d'absence du bit NX) ;
2. Contrôle de l'environnement : l'aléa du noyau dépend du temps (paramètre
du noyau jiffies) et du PID du processus. La variable jiffies reste constante
pendant 4ms, comme execve ne change pas le PID de notre programme, on peut
l'exécuter plusieurs fois avec le même aléa.
3. Emplacement mémoire statique : les noyaux antérieurs à 2.6.20 ne rendent
pas aléatoires les espaces mémoire de linux-gate.so, permettant aux
attaquants d'utiliser des techniques de type "return into libc" pour passer
outre l'ASLR.
Stack Smashing Protection (SSP)
-------------------------------
Cette protection rend les failles basées sur des stacks overflows
inexploitables par l'ajout d'une variable (cookie) placée avant EIP vérifiée
par le noyau avant le retour de la fonction. Il est toujours possible
d'écraser des variables, ce qui peut être exploité si l'attaquant peut
trouver des pointeurs de fonctions, tels qu'il en existe dans le code objet.
Il est également possible d'essayer de deviner le cookie, ce qui est
difficile par énumération, mais reste possible si l'attaque est combinée
avec un bug de type "format string".
La directive ENABLE_STACKGUARD_RND est désactivée sur la plupart des
architectures pour des raisons de performances et la répartition aléatoire
utilisée est en pratique beaucoup moins efficace.
WiShMaster - WIndows SHellcode MASTERy, Benjamin Caillat
========================================================
Benjamin Caillat a présenté son programme WiShMaster (Windows Shellcode
Master) permettant de transformer du code C standard en shellcode.
Plusieurs difficultés se présentent pour une telle opération : les sections
doivent être 'mappées' à la bonne adresse, les fonctions importées doivent
être résolues, le code ne doit pas contenir de référence mémoire absolue...
L'outil présenté effectue toutes ces opérations, et extrait le shellcode de
l'exécutable généré par la compilation. Ceci s'effectue en 6 étapes :
- identification des éléments du code ;
- obtention de la taille des variables globales ;
- création de la structure GLOBAL_DATA :
elle va contenir les pointeurs vers toutes les fonctions utilisées dans le
programme, les appels vers les fonctions doivent alors être effectués en
utilisant cette structure ;
- compilation et extraction des données binaires ;
- personnalisation en fonction des demandes (chiffrement de la charge utile,
intégration de constantes) ;
- et intègration ('dump' dans un fichier C...).
Le code source est très peu modifié, grâce à l'utilisation de directives
#define adaptées.
WiShMaster propose de nombreuses options de personnalisation et est
utilisable dans un shell, à la Scapy, pour voir et modifier dynamiquement
des parties des binaires générés.
Les démonstrations présentées de WiShMaster ont été effectuées en prenant
pour base le scénario d'attaque d'un virus.
Autres présentations
====================
D'autres conférences revenant sur des points moins novateurs ont également
été présentées :
- Tactical Fingerprinting Using Metadata, Hidden Info and Lost Data par
Chema Alonso et Enrique Rando, qui revenait sur les fuites d'information
via les métadonnées des documents bureautiques ;
- OpenOffice Security Design Weaknesses - Eric Filiol, Jean-Paul Fizaine,
présentant certaines failles de la suite bureautique ;
- Advanced SQL Injection exploitation to Operating System Full Control",
Bernardo Damele Assumpcao Guimaraes, auteur de SQLMap, a fait un résumé
des techniques d'exploitation en ASP(.NET) / PHP et MSSQL, MySQL,
PostgreSQL ;
- Cutting Through the Hype: An Analysis of Application Testing
Methodologies", Jon Miller, Neel Mehta, Alex Wheeler, David Bonvillian
ont fait un tour d'horizon des techniques de test disponibles dans
l'industrie et de leurs utilisations ;
- Fun and Games with Mac OS X and iPhone Payloads", Charlie Miller, Vincenzo
Iozzo ont présenté les techniques d'injection de code sous OS X, et les
protections de l'iPhone.
--[ 4. Prix de l'Innovation des Assises de la Sécurité ]----------------
Il ne vous reste plus qu'un mois pour candidater au Prix de
l'Innovation des Assises de la Sécurité ! Vous avez créé votre société,
vous avez un projet innovant en sécurité, profitez de cette opportunité
unique de vous faire connaître auprès de toute la profession !
Le Prix de l'Innovation des Assises de la Sécurité sera décerné pour
la 4ème année consécutive à Monaco du 7 au 10 octobre 2009.
Le comité de sélection du Prix 2009 est composé de :
Hervé Schauer, HSC, animateur du comité de sélection
Didier Gras, RSSI Groupe BNP Paribas, co-animateur
Jean Capron, RSSI France, Philips
David Crochemore, FSSI, Ministère de la Justice
Yvon Klein, ancien RSSI du CNES
Thierry Olivier, Responsable Sécurité du SI, SFR
Benoît Perrot, Directeur d'investissement, ACE Management
Sylvain Thiry, RSSI Groupe SNCF
Alexandre Zapolski, CEO Linagora
Réda Zitouni, CEO Mobiquant (société lauréate en 2008)
Ce prix permet à une entreprise innovante dans le domaine de la
sécurité des systèmes d'information de bénéficier d'un accès gratuit aux
Assises de la Sécurité. Elle bénéficiera d'un espace d'exposition et d'un
atelier afin de démontrer son produit ou son service. Elle recevra son prix
en séance plénière le vendredi 9 octobre 2009, en présence de la presse
et des médias.
Les critères utilisés par le comité de sélection sont notamment :
- le caractère innovant et nouveau de la solution présentée ;
- les innovations technologiques de la solution ;
- l'intérêt pour les RSSI et métiers associés ;
- l'état d'avancement du projet.
Le règlement complet et le dossier de candidature sont disponibles
en téléchargement sur le site des Assises, rubrique Prix de l'Innovation :
http://www.lesassisesdelasecurite.com/accueil/prix.aspx
ou le site du Cercle de la Securite : http://www.lecercle.biz/home/prix.aspx
Le dossier complet doit être envoyé sous format électronique avant le
30 mai 2009 à l'adresse prixinnovation at lesassisesdelasecurite.com.
N'hésitez pas à renvoyer cette annonce et à faire part de votre intérêt
à candidater auprès d'Hervé Schauer ou de Didier Gras.
--[ 5. Nouveautés du web HSC ]------------------------------------------
- Présentation "De la SSI aux risques et vice-versa" par Hervé Schauer
le 29 avril 2009 aux 4èmes journées sécurité organisées par 01.
http://www.hsc.fr/ressources/presentations/01info09/index.html.fr
- Brève sur WMI (Windows Management Instrumentation) par Stéphane Milani
le 7 avril 2009
http://www.hsc.fr/ressources/breves/WMI.html
--[ 6. Agenda des interventions publiques ]-----------------------------
- 12 mai 2009 : Conférence Netfocus organisée par Baptie - Bruxelles
"La gestion des risques selon la méthode ISO 27005" - Hervé Schauer
https://www.baptie.com/events/show.asp?e=206
- 4 juin 2009 : SSTIC 2009 - Rennes
Conférence invitée : "La norme ISO 27001" - Alexandre Fernandez-Toro
http://www.sstic.org/SSTIC09/programme.do
- 9 juin 2009 : Conference du CERT-IST - Paris
Participation à la table-ronde "Dépérimétrisation et cloud computing" -
Hervé Schauer
- 11 juin 2009 : Séminaire Aristote "Sécurité Distribuée" - Paris (Palaiseau)
"SSI du secteur privé : retour d'expérience et confrontation des
habitudes avec le monde de l'enseignement-recherche" - Raphael Marichez
http://www.aristote.asso.fr/doku.php/public/seminaires/accueil
- 12 juin 2009 : Panorama de la cybercriminalité du Clusif - Bordeaux
"Surmédiatisation des failles de sécurité" - Hervé Schauer
Clusir Aquitaine, http://www.clusir-aquitaine.fr/
- 12 juin 2009 : Clusir Aquitaine - Bordeaux
"La norme de gestion de risques en sécurité de l'information ISO 27005" -
Hervé Schauer
http://www.clusir-aquitaine.fr/
- 23 juin 2009 : "La sécurité pour accélérer le business" - Paris
"Enjeux de la SSI pour les entreprises"
Hervé Schauer représentant le Clusif
Organisé par les rédactions de CIO, de Réseaux et télécoms, et de CSO
- 25 juin 2009 : Panorama de la cybercriminalité du Clusif - Beziers
"Surmédiatisation des failles de sécurité" - Hervé Schauer
Clusir Languedoc-Roussillon, http://clusirlr.free.fr/
Retrouvez l'agenda de nos interventions publiques sur
http://www.hsc.fr/conferences/agenda.html.fr
--[ 7. Veille en vulnérabilités HSC ]-----------------------------------
1416 08-04-2009 Vulnérabilités critiques dans les produits VMware
1417 17-04-2009 Multiples vulnérabilités dans les produits Oracle
1418 17-04-2009 Multiples vulnérabilités dans Microsoft Windows
1419 30-04-2009 Vulnérabilités dans Adobe Acrobat et Adobe Reader
1420 30-04-2009 Vulnérabilités critiques dans les produits Symantec
--[ 8. Prochaines formations HSC ]-------------------------------------
Nos prochaines formations sont les suivantes :
- Paris
L'essentiel de PCI-DSS .............. : 25 mai
ISO 27005 Risk Manager .............. : 2 au 4 juin
ISO 27001 Lead Implementer .......... : 8 au 12 juin
ISO 27001 Lead Auditor .............. : 15 au 19 juin
Réalisation pratique des Tests d'Intrusion : 22 au 26 juin (*)
ISO 27005 Risk Manager .............. : 1 au 3 juillet
ISO 27001 Lead Auditor .............. : 6 au 10 juillet
Essentiels de l'ISO 27001 ............ : 3 et 4 septembre
ISO 20000-1 Lead Auditor ............. : 7 au 11 septembre
Fondamentaux techniques de la SSI ... : 14 et 15 septembre
Gestion des identités et des accès .. : 16 au 18 septembre
ISO 27005 Risk Manager .............. : 28 au 30 septembre
Mesures de sécurité ISO 27002 ........ : 1 et 2 octobre
Formation RSSI ....................... : 5 au 9 octobre
Réalisation pratique des Tests d'Intrusion : 12 au 16 octobre (*)
ISO 27001 Lead Implementer .......... : 19 au 23 octobre
DNS par la pratique .................. : 26 octobre (*)
Postfix par la pratique ............. : 27 octobre (*)
Lutte contre le spam par la pratique . : 28 octobre (*)
Fonctionnement des PKI ............... : 29 octobre
Sécurité de la VoIP .................. : 30 octobre
Sécurité des serveurs et applications web : 5 et 6 novembre
Sécurité du WiFi et des réseaux sans-fil : 18 novembre
(*) : formations pratiques avec un ordinateur par stagiaire
- Genève (Suisse)
ISO 27001 Lead Auditor .............. : 9 au 13 novembre
- Luxembourg
ISO 27001 Lead Auditor .............. : 25 au 29 mai
ISO 27005 Risk Manager .............. : 24 au 26 juin
ISO 27001 Lead Implementer .......... : 12 au 16 octobre
- Lyon
ISO 27001 Lead Implementer ........... : 22 au 26 juin
- Nice
ISO 27001 Lead Implementer .......... : 29 juin au 3 juillet
- Strasbourg
ISO 27001 Lead Implementer .......... : février 2010
- Toulouse
ISO 27005 Information Security Risk Manager : 13 au 15 mai
ISO 27001 Lead Auditor .............. : mars 2010
Pour tout renseignement, et pour vous inscrire pour toutes les villes
sauf Luxembourg, contactez Lynda Benchikh :
formations at hsc.fr -- +33 141 409 704
Pour les formations à Luxembourg contactez Sylvie Favaut :
Sylvie.Favaut at eu.didata.com
Tél : +352 25 48 25 321 -- GSM : +352 621 31 20 88 -- Fax : +352 25 48 30
Rappel : pour 4 jours de formation consécutifs commandés
simultanément par la même personne, le 5ème jour est offert (sauf
formations d'une semaine et certifiantes).
Vous souhaitez des formations dans votre ville ? Contactez Hervé Schauer.
Retrouvez le détail de nos formations (plan pédagogique, agenda) ainsi que
notre catalogue sur http://www.hsc.fr/services/formations/index.html.fr
--[ 9. Offres d'emplois ]-----------------------------------------------
HSC recherche :
- Un à deux consultants débutants intéressés par la sécurité autour des
normes ISO 27001 (SMSI) et ISO 27005 (Gestion de risques SSI)
- Un administrateur système et réseau, webmestre et logisticien
Au delà de ces recherches actives, tous les autres profils sont
invités à faire des candidatures spontanées. HSC recrute réellement.
Les postes sont basés à Levallois-Perret, à 5 minutes de la gare de
Paris Saint-Lazare, dans 400m2 de bureaux climatisés.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Les consultants ISO 27001 réaliseront des prestations de conseil,
d'expertise, d'audit, d'accompagnement et de formation en sécurité,
typiquement dans la mise en oeuvre et l'audit de SMSI, la gestion de
risque en sécurité de l'information, et de manière plus générale tout
ce qui touche à l'organisation de la SSI.
HSC propose un programme de 3 à 8 semaines de formations accessible à
tous les nouveaux embauchés, permettant un apprentissage sans équivalent
par des experts de chaque domaine.
L'équipe est jeune et dynamique mais aussi expérimentée, et se caractérise
également par son éthique et son indépendance qui lui donne une richesse
unique depuis 20 ans.
HSC propose des salaires très motivants, et permet des augmentations de
salaire rapides, fréquentes, et conséquentes. Diverses primes sont
également en usage. Chaque consultant qui fait ses preuves est réellement
reconnu rapidement.
Lorsqu'ils quittent HSC, en moyenne après 6 ans, les consultants évoluent
dans leur carrière, principalement au sein d'éditeurs en sécurité, de
multinationales en informatique et d'opérateurs de télécommunication,
partent au service de l'état (SGDN, Défense, etc), ou deviennent RSSI dans
un grand compte. Les carrières des anciens consultants passés chez
HSC depuis 20 ans vous le démontrent.
Les candidats devront avoir un bon contact humain, une bonne qualité de
rédaction en français, et une maîtrise de l'informatique et des technologies.
Si vous souhaitez proposer votre candidature, nous vous remercions d'envoyer
votre CV en format texte ascii par courrier électronique à cv at hsc.fr.
Pour plus d'informations : http://www.hsc.fr/societe/recrutement.html.fr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HSC recherche un administrateur système et réseau, de formation BTS
ou IUT, qui soit autonome, capable de prendre des décisions rapidement en
fonction des besoins, qui sache analyser les journaux système et réseau,
ayant de très bonnes compétences système Windows, et la connaissance de
Linux ou un autre Unix (Solaris, AIX, etc), et la maîtrise des routeurs
CISCO. Une compétence dans les produits VMware et Asterisk (VoIP) sera un
plus.
Les tâches attribuées à ce poste seront de veiller au bon fonctionnement de
toute l'infrastructure (réseau, serveurs, sécurité périmétrique), de gérer
les sauvegardes, de veiller à la sécurité des équipements internes et
périmétriques, de gérer le web interne et le web externe. Cette dernière
tâche sera importante et une connaissance du langage WML (Website Meta
Language) sera un plus (http://www.thewml.org/).
Il sera responsable de la logistique et des moyens généraux, et préparera
les salles de travaux pratiques (postes clients et infrastructure).
Si vous souhaitez proposer votre candidature, nous vous remercions d'envoyer
votre CV en format texte ascii par courrier électronique à cv-admin at hsc.fr.
--[ 10. Actualité des associations : Club 27001, OSSIR et Club PCA ]----
o Club 27001 (http://www.club-27001.fr/)
. Attention, suite à des conflits de dates, la prochaine réunion à
Paris a changé de date : elle sera le jeudi 11 juin 2009
. Programme de la réunion du 11 juin 2009 chez Altran à Levallois-Perret
- "Le framework RiskIT de l'ISACA" par Jean-Luc Strauss, Altran
- "Présentation du RGS" par Emeric Laroche, HSC
. Les réunions suivantes à Paris seront les 17 septembre et
19 novembre 2009
Les animateurs sont en attentes de propositions de présentations.
. Prochaine réunion à Toulouse le vendredi 26 juin 2009
o OSSIR (http://www.ossir.org/)
. Prochaine réunion à Paris le mardi 12 mai à 14h00
- "Le passeport Internet" par Martine Reindle (Axsionics)
- "La plate-forme Netifera" par Philippe Mathieu-Daudé et Claudio
Castiglia (Netifera)
. Prochaines réunions à Lyon, Rennes et Toulouse annoncées bientôt
o CCA (http://www.clubpca.eu/)
. Assemblée générale le 26 mai à l'OCDE
--[ 11. Le saviez vous ? La réponse ]------------------------------------
par Julien Raeis et Jean-Baptiste Aviat
Comment, lors de votre première connexion à un serveur SSH, vous assurez-vous
de la validité de sa clé ?
Un serveur SSH peut être reconnu par un client par la valeur de l'empreinte
de sa clé publique. Si cette valeur a changé, c'est que la clé publique a
changé, et il est probable que quelqu'un ait usurpé l'identité du serveur :
client$ ssh server
The authenticity of host 'server' can't be established.
RSA key fingerprint is d5:39:29:27:2e:fc:42:5c:2b:48:c0:db:85:e7:d8:14.
Are you sure you want to continue connecting (yes/no)?
A ce stade, il convient d'être sûr de la valeur "RSA key fingerprint", qui
valide l'identité du serveur. En tapant "yes", cette valeur ainsi que le nom
d'hôte du serveur seront enregistrés dans le fichier ~/.ssh/known_host :
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (RSA) to the list of known hosts.
Password:
Lors des prochaines connexions à ce serveur, la valeur enregistrée sera
systématiquement comparée à l'empreinte de la clé calculée par le client. Si
elles diffèrent, une alerte sera affichée et la tentative de connexion sera
terminée.
La phase de vérification initiale est donc cruciale. Il est cependant très
difficile de retenir par coeur la valeur de 128 bits du hash...
Les techniques présentées ci-dessous ont pour but de fournir une méthode plus
simple de vérification des clés qu'une comparaison exhaustive "manuelle" de
l'empreinte.
Validation visuelle
===================
Dans l'article "Hash Visualization: a New Technique to improve Real-World
Security" [1], les américains Perrig et Song ont présenté une technique (Hash
Visualization Algorithm, HVA) permettant de représenter une valeur quelconque de
façon graphique. Le HVA reprend les exigences d'une fonction de hachage telles
que la résistance au calcul de préimage, de seconde préimage et la résistance
aux collisions, après avoir adapté ces définitions aux contraintes de la
reconnaissance d'image par un être humain.
Cette idée a été également présentée par Dan Kaminsky au CCC en 2006 [2].
Disponible à partir de la version 5.1 de OpenSSH, il suffit d'activer l'option
VisualHostKey, sur la ligne de commande ou via le fichier ~/.ssh/ssh_config :
$ ssh -o 'VisualHostKey yes' server1
RSA key fingerprint is af:10:64:37:c2:01:aa:0f:8b:48:c6:b3:fa:30:a2:89
+--[ RSA 1024]----+
| .. |
| . .oo |
| +.+...|
| oo+ *.o|
| S o o =+|
| . oo o.+|
| . . Eo|
| o .. . |
| o .. |
+-----------------+
Voici un aperçu du HVA pour une clé différente :
$ ssh -o 'VisualHostKey yes' server2
RSA key fingerprint is 38:92:a0:b1:6b:5f:41:b0:3d:66:41:19:85:42:fe:09
+--[ RSA 8192]----+
| .o.+=. |
| ..+o. |
|. .E.* |
| + .*.o. |
|o o+o S |
| . ... |
|.. . |
|. . . |
| . |
+-----------------+
Sur deux clés relativement semblables (les premiers et derniers bits, seuls
généralement vérifiés par l'être humain), générées en utilisant l'outil ffp
[3], on peut voir que l'algorithme HVA produit toujours deux sorties très
différentes :
$ ssh -o 'VisualHostKey yes' localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 0a:b1:35:f5:6d:4d:5f:c1:4c:13:33:be:7c:a0:16:f3.
+--[ RSA 2048]----+
| . =B+|
| . . . o.+=|
| . o . = o..|
| + . . =...|
| o S o Eo.|
| . . . .|
| . |
| |
| |
+-----------------+
Are you sure you want to continue connecting (yes/no)?
$ ssh -o 'VisualHostKey yes' localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 0a:b1:3e:e2:62:9d:6b:6b:35:08:b0:27:f9:e2:b9:f3.
+--[ RSA 2048]----+
| |
|. |
|.o . |
|+.. o |
| +. + S |
|. .o + . |
|..+ = o |
|.* * . |
|.oBEo |
+-----------------+
Cette méthode ne permet cependant pas de s'assurer de la validité d'une clé,
mais permet de détecter simplement qu'un problème a pu se produire. Comme
rappelé dans le code source d'OpenSSH :
* If you see the picture is different, the key is different.
* If the picture looks the same, you still know nothing.
Validation par DNS
==================
Une autre méthode pour vérifier l'empreinte des clés du serveur est d'utiliser
l'enregistrement DNS SSHFP, défini dans la RFC 4255 [4]. Ce dernier a été conçu
spécifiquement pour stocker les empreintes des clés SSH et est construit de la
manière suivante :
<nom d'hôte> IN SSHFP <numéro d'algorithme> <type d'empreinte> <empreinte>
L'algorithme de la clé publique est 1 pour RSA ou 2 pour DSS et le type
d'empreinte est nécessairement 1 (pour SHA-1).
L'outil ssh-keygen, inclus dans OpenSSH, génère automatiquement les
enregistrements SSHFP pour l'hôte courant, avec l'option "-r" :
server$ ssh-keygen -r server
server IN SSHFP 1 1 d8a749c02521faa8a76402e45aaf3d4b4b8b21ea
server IN SSHFP 2 1 d00aebb3324cc3fb87d3531635d58b1ae6b3598c
Il est également possible de lui passer un fichier de clé en paramètre :
server$ ssh-keygen -r server -f /etc/ssh/ssh_host_rsa_key
server IN SSHFP 1 1 d8a749c02521faa8a76402e45aaf3d4b4b8b21ea
Pour les serveurs DNS ne gérant pas l'enregistrement SSHFP (Bind < 9.3.0 par
exemple), l'option "-g" de ssh-keygen va générer un enregistrement générique
du type 44, numéro assigné à SSHFP.
server$ ssh-keygen -r server -f /etc/ssh/ssh_host_rsa_key -g
server IN TYPE44 \# 22 01 01 d8a749c02521faa8a76402e45aaf3d4b4b8b21ea
Du côté du client SSH (et notamment d'OpenSSH), la vérification des clés
est activée par l'option "VerifyHostKeyDNS", présente depuis la version 3.4
d'OpenSSH. Lors de la connexion, une requête DNS supplémentaire va être
effectuée, demandant l'enregistrement SSHFP (44) :
Domain Name System (query)
Transaction ID: 0x4f27
Flags: 0x0100 (Standard query)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
server: type Unknown (44), class IN
Name: server
Type: Unknown (44)
Class: IN (0x0001)
La réponse va alors contenir les empreintes :
Answers
server: type Unknown (44), class IN
Name: server
Type: Unknown (44)
Class: IN (0x0001)
Time to live: 6 days, 23 hours, 52 minutes, 54 seconds
Data length: 22
Data 0101d8a749c02521faa8a76402e45aaf3d4b4b8b21ea server: type Unknown (44), class IN
Name: server
Type: Unknown (44)
Class: IN (0x0001)
Time to live: 6 days, 23 hours, 52 minutes, 54 seconds
Data length: 22
Data 0201d00aebb3324cc3fb87d3531635d58b1ae6b3598c
Le comportement lors de la connexion du client SSH sera le suivant :
client $ ssh -o 'VerifyHostKeyDNS=yes' server
The authenticity of host 'serveur (192.168.1.2)' can't be established.
RSA key fingerprint is 28:b4:cb:1b:ca:52:e5:3b:ec:e7:aa:af:dd:a7:d1:a9.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Ici le client va bien notifier l'utilisateur de la présence de l'empreinte de
la clé dans le DNS. Cependant, bien que celle-ci provienne d'un canal séparé,
elle ne peut pas être autentifiée avec certitude et sera marqué comme
non-sécurisée ("insecure") :
client$ ssh -v -o 'VerifyHostKeyDNS=yes' server
[...]
debug1: found 2 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'serveur (192.168.1.2)' can't be established.
[...]
Le client OpenSSH va en effet utiliser DNSSEC pour valider l'empreinte de la
clé de façon sécurisée. Ainsi, sur un système utilisant DNSSEC pour
authentifier les réponses DNS, la connexion au serveur SSH devient entièrement
transparente :
client$ ssh -v -o 'VerifyHostKeyDNS=yes' server
[...]
debug1: found 2 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
server$
[1] http://sparrow.ece.cmu.edu/~adrian/projects/validation/validation.pdf
[2] http://events.ccc.de/congress/2006/Fahrplan/events/1713.en.html
[3] http://freeworld.thc.org/thc-ffp/
[4] http://tools.ietf.org/html/rfc4255
Plus d'informations sur la liste de diffusion newsletter