CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2010-10
Gestion du documentLe bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-010.pdf Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-010/ 1 Actualités Microsoft1.1 Bulletins du mois de marsCette semaine, Microsoft a émis deux bulletins de sécurité :
Le CERTA recommande l'application des correctifs dès que possible. 1.2 Vulnérabilité non corrigée dans Internet ExplorerCette semaine, le CERTA a également émis une alerte concernant les navigateurs Internet Explorer 6 et Internet Explorer 7. La faille est actuellement exploitée sur l'Internet et il est donc impératif d'appliquer les mesures détaillées dans la section « contournement provisoire » de l'alerte pour se protéger. Le CERTA rappelle que la vulnérabilité est exploitable au moyen de plusieurs vecteurs d'attaque, notamment des sites Web spécialement conçus mais également des documents Microsoft Office. Dans ce sens, l'utilisation d'un navigateur alternatif n'est pas suffisante pour se protéger contre tous les vecteurs. En effet, cela protège un utilisateur lors de la navigation Internet mais pas lors de l'ouverture d'un document spécialement construit, par exemple. La restriction d'accès sur la bibliothèque vulnérable ou la mise à jour vers Internet Explorer 8 sont donc nécessaires pour se protéger totalement contre cette faille. 1.3 Documentation
2 Durcissement de la configuration des systèmes Windows : restriction des accès anonymes (3/8)Les sessions nulles, c'est-à-dire des accès non authentifiés (le client n'a pas besoin de fournir un identifiant et un mot de passe), ont toujours été source d'accès illégitimes aux systèmes Windows. Elles doivent donc être restreintes ou désactivées, afin de se protéger contre la fuite d'information (comptes utilisateurs, partages réseau, etc.). En effet, parmi les fonctions natives d'un système Windows, les fonctions d'énumération accessibles via des interfaces RPC étaient historiquement appelables sans authentification. Ces interfaces RPC sont généralement accessibles par le mécanisme des canaux nommés (named pipes) et transportées sur le réseau au moyen du protocole SMB.
Cette recommandation s'applique tant pour les postes de travail que pour les serveurs. Il existe plusieurs dispositifs de sécurisation suivant les différentes versions de Windows. 2.1 Windows 2000La valeur RestrictAnonymous de la clef de registre HKLM\SYSTEM\CurrentControlSet\Control\Lsa permet de définir des restrictions d'accès pour les connexions anonymes. Elle peut prendre une valeur allant de 0 à 2 :
Ce paramètre peut être configuré au travers des Options de sécurité. Sous Windows 2000, le paramètre s'appelle « Restrictions supplémentaires pour les connexions anonymes » et doit être positionné à la valeur « Ne pas permettre l'énumération des comptes et partages SAM », ce qui correspond au niveau 1 du tableau ci-dessus. 2.2 À partir de Windows XP et Windows 2003La valeur RestrictAnonymous est toujours
présente, mais seules les valeurs 0 et 1 sont possibles.
En revanche, deux nouveaux paramètres font leur
apparition, toujours sous la clef
Ces paramètres peuvent être configurés au travers des Options de sécurité. La liste suivante indique les correspondances entre le nom des valeurs de la base de registre et le nom de l'option dans l'éditeur de stratégie :
Par ailleurs, toujours dans les Options de sécurité, le paramètre Accès réseau : Permet la traduction de noms/SID anonymes autorise ou interdit la conversion anonyme des identifiants de sécurité (SID) vers le nom de l'entité associée. Ce paramètre doit être désactivé.
Enfin, au niveau des contrôleurs de domaine Windows 2003, il convient de vérifier que le groupe spécial ANONYMOUS LOGON ainsi que EVERYONE ne figurent pas dans le groupe Pre Windows 2000 Compatible Access. 2.3 À partir de Windows XP Service Pack 2 et de Windows 2003 Service Pack 1Les paramètres décrits ci-dessous, bien que déjà présents dans les versions antérieures de Windows ou de Service Pack, ne permettaient pas de contrôler certaines valeurs implicitement positionnées par le système, réduisant ainsi leur utilité.
Ce problème est désormais corrigé,
l'ensemble des valeurs étant paramétrable sous la
clef
Ces paramètres peuvent être configurés au travers des Options de sécurité. La liste suivante indique les correspondances entre le nom des valeurs de la base de registre et le nom de l'option dans l'éditeur de sécurité :
3 La technologie DEP (Data Execution Prevention) : Administration, compatibilité et limites (3/3)La semaine dernière nous avons détaillé la configuration de DEP, notamment avec l'ACT. Nous allons maintenant nous intéresser aux moyens disponibles pour détecter si DEP est activé. Pour finir, nous aborderons les potentiels problèmes liés à DEP ainsi que les limites de la technologie. 3.1 Recenser la configuration de DEPNous avons vu que le fichier boot.ini (ou l'utilisation de bcdedit) permet de définir la configuration de DEP au niveau du système. Donc un administrateur voulant connaitre la configuration de DEP pourrait créer un script pour lire ce fichier. Cependant cela pose plusieurs problèmes :
Une méthode plus simple à gérer lorsque l'on administre un parc de machines, est d'utiliser un script WMI (Windows Management Instrumentation). Outre un script on peut aussi appeler WMI via l'outil WMIC.EXE en ligne de commande. Dans notre cas, pour savoir quel est le réglage de DEP : wmic OS Get DataExecutionPrevention_SupportPolicy Cette ligne de commande renvoie une valeur de 0 à 3 qui correspond au réglage de DEP au niveau système. La fiche technique http://support.microsoft.com/kb/912923/fr vous donnera plus de détails. Outre WMI, on peut aussi appeler directement l'API GetSystemDEPPolicy depuis un programme. 3.2 Problème de compatibilitéSi vous activez DEP, il faudra vous assurer que cela ne pose pas de problèmes aux applications installées sur la machine. Normalement toutes les applications récentes ont été développées pour être compatibles avec DEP. Cependant, si vous avez des applications relativement anciennes installées, il se peut que certaines soient instables si vous activez DEP (notamment avec les options AlwaysOn ou OptOut). Dans ce cas, il faudra vérifier si une nouvelle version de l'application supportant DEP n'est pas disponible auprès de l'éditeur. Dans le cas contraire vous pouvez désactiver DEP pour cette application, comme nous l'avons vu la semaine dernière. Dans tous les cas, ces problèmes d'incompatibilité peuvent être réglés, et donc, ne sauraient justifier la décision de ne pas activer DEP. 3.3 Limites de DEPComme tout mécanisme de protection, DEP a ses limites et ne vous protège pas de toutes les formes d'attaques. Plusieurs méthodes ont été développées pour contourner DEP, la plupart utilisent une variante d'une technique appelée «Return-to-libc». Le but de cette technique est d'essayer de désactiver DEP en réussissant à appeler l'une des ces API (liste non exhaustive) :
Cependant, si DEP est couplé à la technologie ASLR (Address Space Layout Randomization), introduite dans Vista, ces techniques de contournement sont rendues plus difficiles à appliquer. Mais ASLR a aussi ses faiblesses, comme l'ont montré les techniques utilisant le «JIT Spraying» ... 3.4 ConclusionMalgré ses limites, la technologie DEP (surtout couplée à ASLR) rend l'exploitation de vulnérabilités significativement plus difficile. C'est une protection supplémentaire et efficace qui participe à la politique de défense en profondeur. Le CERTA recommande donc son utilisation, bien que son activation doive être faite avec prudence sur des systèmes opérationnels. 4 Vulnérabilité dans Spamassassin MilterCette semaine, une vulnérabilité relative à l'extension Spamassassin Milter a été publiée. Spamassassin Milter permet d'interfacer le logiciel Spamassassin avec des serveurs de messagerie comme Sendmail ou Postfix. Historiquement cette extension fonctionnait nativement uniquement avec Sendmail en utilisant certaines macro-commandes de ce Sendmail pour communiquer. Postfix utilise d'ailleurs une couche d'émulation de ces macros afin de dialoguer avec Spamassassin Milter. La vulnérabilité concerne l'option '-x' qui permet à spamassassin-milter de prendre en compte les éventuels alias ou utilisateurs virtuels lors du passage de message à Spamassassin. Cette option n'est normalement pas activée par défaut et doit faire l'objet d'une configuration spécifique de Spamassassin Milter. Il est à noter que si toutefois cette option est activée, l'exploitation de la vulnérabilité devient triviale et permet l'exécution de code arbitraire à distance. Recommandation :En temps normal, un système de filtrage s'appuyant sur Spamassassin Milter n'est pas vulnérable car la commande spamass-milter ne sera pas appelée avec l'option '-x'. Cependant, il convient de bien s'en assurer car si tel n'était pas le cas, une attaque serait facile à réaliser.
|
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
