Les vingt vulnérabilités de sécurité les plus critiques d ...

flippantmewlingΑσφάλεια

19 Ιουν 2012 (πριν από 5 χρόνια και 1 μήνα)

1.530 εμφανίσεις


Les vingt vulnérabilités de sécurité les plus critiques
d'Internet (Liste mise à jour) ~ L’avis des experts

Version 4.0, 8 Octobre 2003 Copyright (C) 2001-2003, SANS Institute
Les questions/commentaires peuvent être envoyés à
top20@sans.org
.


----- Accès à l'index du Top 20 des Menaces -----

Introduction
La liste du SANS des 20 Vulnérabilités de Sécurité les plus critiques d'Internet
La plus grande majorité des vers et autres cyber-attaques réussies sont rendues possibles par
des vulnérabilités inhérentes à un petit nombre de services communs dans les divers systèmes
d'exploitation. Les attaquants sont opportunistes. Ils prennent le chemin le plus facile et le plus
commode et exploitent les failles les mieux connues avec les outils d'attaque les plus efficaces et
largement disponibles. Ils comptent sur les entreprises ne remédiant pas aux problèmes et ils
attaquent souvent au hasard, parcourant l'Internet à la recherche de n'importe quels systèmes
vulnérables. La diffusion facile et destructive de vers comme Blaster, Slammer et Code Red, peut
être directement imputée à l'exploitation de vulnérabilités non patchées (mises à jour).
Il y a trois ans, l’institut du SANS et le National Infrastructure Protection Center (Centre de
Protection d'Infrastructure National) au FBI ont réalisé un document récapitulant les dix
vulnérabilités de sécurité les plus critiques de l'internet. Des milliers d'organisations ont utilisé
cette liste, et les listes étendues à un Top20 qui ont suivi un et deux ans plus tard, afin de
s’efforcer de résoudre en priorité les problèmes les plus dangereux. Les services vulnérables
ayant conduit aux exemples précités - Blaster, Slammer, et Code Red, aussi bien que les vers
NIMDA – figurent dans cette liste.
Cette mise à jour de la liste Top20 du SANS est en fait constituée de 2 listes Top10: les dix
services vulnérables les plus communément exploités dans Windows et les dix services
vulnérables les plus communément exploités dans UNIX et Linux. Bien qu'il y ait des milliers
d'incidents de sécurité affectant tous les ans ces systèmes d'exploitation, une majorité
accablante des attaques réussies visent un ou plusieurs de ces vingt services vulnérables.
La liste du Top20 est un consensus des vulnérabilités qui exigent une remédiation immédiate.
C'est le résultat d'un processus qui a rassemblé des douzaines d’experts reconnus en matière de
sécurité. Ils viennent des agences fédérales les plus consciencieuses en matière de sécurité aux
Etats-Unis, au Royaume-Uni et Singapour, des principaux fournisseurs de logiciels de sécurité et
sociétés de consulting, des principaux programmes universitaires de sécurité, de nombreuses
organisations d'utilisateurs, et de l'Institut du SANS. Une liste des participants peut être trouvée
à la fin de ce document.
La liste Top20 du SANS est un documents en constante évolution. Il inclut des instructions étape
par étape et des indicateurs sur l'information utile complémentaire permettant de corriger les
failles de sécurité. Nous mettrons à jour la liste et les instructions au fur et à mesure de
l’identification de la criticité des menaces et des pratiques méthodologiques, vos commentaires
étant les bienvenus. Ce document est basé sur un consensus communautaire -– votre ex
p
érience
à contrer les attaquants et à l'élimination des vulnérabilités peut aider ceux qui viennent après
vous. Veuillez soumettre vos suggestions par e-mail à
top20@sans.org
.

Notes à l’attention des lecteurs

Numéros CVE
Vous trouverez des références aux numéros CVE (Common Vulnerabilities and Exposures)
accompagnant chaque vulnérabilité. Vous pouvez également voir des numéros CAN. Les numéros

CAN sont des candidats aux entrées CVE qui n'ont pas encore été entièrement vérifiées. Pour
plus d'information sur le projet CVE récompensé par des distinctions, Cf.
http://cve.mitre.org
.
Les numéros CVE et CAN reflètent les vulnérabilités les plus critiques en terme de priorité
nécessitant d’être vérifiées pour chaque item. Chaque référence de vulnérabilité CVE est liée à
l'entrée de vulnérabilité associée dans le service d'indexation de vulnérabilité ICAT de l'Institut
National de Standards et de Technologie (
http://icat.nist.gov
). ICAT fournit une brève description
et une liste des caractéristiques de chaque vulnérabilité (e.g. portée de l'attaque associée et
dommage potentiel), une liste de noms de logiciels et des numéros de versions vulnérables, ainsi
que les liens vers l'avis de vulnérabilité et l'information de mise à jour.
Ports à bloquer sur le pare-feu
---- Accès à l'index des ports à bloquer sur le Pare-feu ou la Passerelle ----
À
la fin du document, vous trouverez une section supplémentaire offrant une liste des ports
communément sondés et attaqués. En bloquant le trafic à destination de ces ports sur le pare-
feu ou sur d'autres dispositifs de protection réseau, vous ajoutez une couche supplémentaire de
défense qui aide à vous protéger des erreurs de configuration par inadvertance. Notez
cependant, que l'utilisation d'un pare-feu ou d'un routeur pour bloquer le trafic réseau dirigé vers
un port ne protège pas le port des éventuels intrus malveillants qui sont déjà à l'intérieur de
votre périmètre ou des pirates qui peuvent avoir pénétré votre périmètre en utilisant d'autres
moyens. Il est aussi beaucoup plus sûr d'implémenter une règle de filtrage (refus ou blocage) de
tout ce qui n'est pas explicitement permis sur les configurations pare-feu et routeur plutôt que de
bloquer des ports spécifiques individuellement.
retour au début ^

Principales Vulnérabilités des Systèmes Windows

W1 Internet Information Services (IIS)


W2 Serveur SQL Microsoft (MSSQL)


W3 Authentification Windows


W4 Internet Explorer (IE)


W5 Services d'Accès distants Windows


W6 Composants Microsoft Data Access (MDAC)


W7 Windows Scripting Host (WSH)


W8 Microsoft Outlook et Outlook Express


W9 Partage de fichiers Windows entre Pairs (P2P)

W10 Protocole SNMP (Simple Network Management Protocol)

Principales Vulnérabilités des Systèmes UNIX

U1 Système de Noms de Domaines BIND

U2 Appels de Procédure à Distance (RPC)


U3 Serveur Web Apache


U4 Comptes d'identification généraux UNIX sans mots de passe ou mots de passe faibles


U5 Services en Clair

U6 Sendmail


U7 Protocole SNMP (Simple Network Management Protocol)


U8 Shell Sécurisé (SSH)


U9 Mauvaise configuration des Services d'entreprise NIS/NFS


U10 Secure Sockets Layer libre (SSL)


retour au début ^
Principales Vulnérabilités des Systèmes Windows (W)
W1 Internet Information Services (IIS)
W1.1 Description
Les installations par défaut de IIS ont prouvé avec le temps leur vulnérabilité à un certain
nombre d'attaques sérieuses. L'impact de ces vulnérabilités peut inclure :
• Le déni de Service
• L’exposition ou compromission de fichiers sensibles ou de données
• L’exécution de commandes arbitraires
• La compromission complète du serveur
IIS utilise un module de programmation connu sous le nom d'ISAPI pour associer les fichiers
ayant certaines extensions à des DLLs (connues sous le nom de filtre ISAPI). Les pré-processeurs
tels que ColdFusion et PHP utilisent ISAPI, IIS incluant beaucoup de filtres ISAPI pour manipuler
des fonctions telles que les pages actives (dynamiques) de serveur (ASP), y compris côté
serveur, et partage d'impression web. Beaucoup de filtres ISAPI installés par défaut avec IIS ne
sont pas requis dans la plupart des installations, et beaucoup de ces filtres sont exploitables. Des
vers bien connus comme Code Red et Code Red 2 sont deux exemples de programmes
malveillants qui emploient ce type de mécanisme de propagation.
Comme beaucoup de serveurs sur l’internet, IIS inclut des exemples applicatifs qui ont été
conçus pour démontrer la fonctionnalité du serveur web. Ces applications n'ont pas été conçues
pour fonctionner en toute sécurité dans un environnement de production. Quelques exemples
applicatifs de IIS ont permis la visualisation ou la réécriture arbitraire de fichiers aussi bien que
l'accès à distance à d'autre information sensible du serveur, y compris le mot de passe de
l'administrateur.
Une installation d'IIS sans maintenance effective est également sujette à des vulnérabilités
découvertes à posteriori de la date de révision du logiciel. Les exemples incluent les
vulnérabilités
WebDAV
"ntdll.dll" dans IIS 5.0, qui pouvait permettre des attaques par déni de
service, à n'importe quel visiteur du site internet de créer et d’exécuter des scripts sur le
serveur, et l'exploitation de la vulnérabilité Unicode, qui permettait à n'importe quel visiteur du
site internet d'exécuter des commandes arbitraires sur le serveur en effectuant simplement des
requêtes URLs soigneusement forgées.
Des add-ons tiers tels que ColdFusion et PHP peuvent introduire d'autres vulnérabilités dans une
installation d'IIS, soit par une mauvaise configuration ou au travers de vulnérabilités inhérentes
au produit.
De
p
lus am
p
les information sur les dernières vulnérabilités s
p
écifi
q
ues à WebDAV
(
CAN-2003-
0109

CA-2003-09
) peuvent être trouvées sur les sites suivants :
http://www.cert.org/advisories/CA-2003-09.html

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0109

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q241520

W1.2 Systèmes d'Exploitation Affectés
Windows NT 4 (toutes versions) fonctionnant avec IIS 4
Windows 2000 Serveur fonctionnant avec IIS 5
Windows XP Professionnel fonctionnant avec IIS 5.1
Au moment de la présente édition, aucune vulnérabilité n'a été reportée dans Windows 2003
fonctionnant avec IIS 6 ; Il est cependant raisonnable d'anticiper la découverte et le rapport de
vulnérabilités ultérieures, le nombre d’environnements de production adoptant la nouvelle plate-
forme augmentant significativement.
W1.3 Les identifiants CVE/CAN
CVE-1999-0264
,
CVE-1999-0278
,
CVE-1999-0874
,
CVE-1999-0237
,
CVE-1999-0191
,
CVE-2000-0770
,
CVE-2000-0778
,
CVE-2000-0884
,
CVE-2000-0886
,
CVE-2000-0226
,
CVE-2001-0151
,
CVE-2001-0241
,
CVE-2001-0333
,
CVE-2001-0500
,
CVE-2001-0507

CAN-1999-0509
,
CAN-1999-0736
,
CAN-1999-1376
,
CAN-2002-0071
,
CAN-2002-0073
,
CAN-2002-0079
,
CAN-2002-0147
,
CAN-2002-0149
,
CAN-2002-0150
,
CAN-2002-0364
,
CAN-2002-0419
,
CAN-2002-0421
,
CAN-2002-0422
,
CAN-2002-0869
,
CAN-2002-1180
,
CAN-2002-1181
,
CAN-2002-1182
,
CAN-2002-1309
,
CAN-2002-1310
,
CAN-2003-0109
,
CAN-2003-0223
,
CAN-2003-0224
,
CAN-2003-0225
,
CAN-2003-0226
,
CAN-2003-0227
,
CAN-2003-0349

W1.4 Comment déterminer si vous êtes vulnérable
Les installations par défaut ou non mises à jours de IIS peuvent (doivent) être présumées
comme vulnérables.
Les administrateurs de système et réseau en charge des déploiements de IIS devraient se
familiariser avec la vaste collection d’utilitaires de Microsoft ainsi qu’avec les documents de
sécurité se rapportant à l’administration correcte d’Internet Information Server.
La principale référence concernant la documentation inhérente à la sécurité de IIS est le
Centre
de Sécurité Internet Information Server (IIS)
Il vous est conseillé de télécharger et d’utiliser
Microsoft Baseline Security Analyzer
qui contient
des procédures de détection spécifiquement adaptées à IIS.
Les administrateurs devraient comparer leurs systèmes avec les nombreuses
listes de
vérification
,
guides de configuration renforcée
, et documentations de
remédiation aux
vulnérabilités
que Microsoft met à disposition afin de donner un sens au statut de vulnérabilité.
W1.5 Comment s’en protéger
Patchez le système et tenez-le à jour.
La mise à jour d’un serveur à l'installation est nécessaire, mais pas suffisant. En fonction des
découvertes de nouvelles failles inhérentes à IIS
,
vous devrez effectuer les mises à
j
our en
conséquence. Windows Update et AutoUpdate sont des options pour des installations serveurs en
mode autonome.
HFNetChk
, le Network Security Hotfix Checker (Contrôleur de Patchs Sécurité
Réseau), aide l’administrateur système à scanner les systèmes locaux ou distants pour des
patchs d’actualité. L’outil fonctionne sur Windows NT 4, Windows 2000, et Windows XP. La
version actuelle peut être téléchargée chez Microsoft sur
http://www.microsoft.com/technet/security/tools/hfnetchk.asp
.
Si vous utilisez des add-ons tiers tels que ColdFusion, PerlIIS, ou PHP, rappelez-vous de vérifier
la présence de patchs aussi bien que d’aides à la configuration sur les sites Web des vendeurs.
Pour des raisons évidentes, Microsoft n'inclut pas de patchs tiers (pour des produits autres que
Windows) dans Windows Update ni dans les services de mise à jour associés.
Utilisez le Gestionnaire IIS Lockdown afin de renforcer l’installation
Microsoft a réalisé un utilitaire simple connu sous le nom de gestionnaire IIS Lockdown pour
faciliter la sécurisation des installations de IIS. La version actuelle peut être téléchargée chez
Microsoft sur
http://www.microsoft.com/technet/security/tools/locktool.asp
.
L’activation du Gestionnaire IIS Lockdown en mode "custom" ou "expert" vous permettra de faire
les changements recommandés suivants sur une installation IIS:
• Désactivez WebDAV (à moins que votre environnement ne le requiert absolument pour la
publication de contenu web).
• Démappez toutes les extensions ISAPI inutiles (y compris .htr, .idq, .ism, et .printer en
particulier).
• Eliminez les exemples applicatifs fournis.
• Interdisez au serveur web l’accès aux commandes système courantes généralement
utilisées dans un compromis (e.g., cmd.exe et tftp.exe).
Utilisez URLScan pour filtrer les requêtes HTTP
Beaucoup de codes d’exploitation des vulnérabilités d’IIS, y compris Code Blue et la famille Code
Red, utilisent des requêtes HTTP malicieusement forgées dans les attaques dites « Directory
Traversal » ou « Débordement de Buffer ». Le filtre URLScan peut être configuré pour rejeter de
telles demandes avant que le serveur essaye de les traiter. La version actuelle a été intégrée au
gestionnaire IIS Lockdown, mais peut toutefois être téléchargée séparément chez Microsoft sur
http://www.microsoft.com/technet/security/tools/urlscan.asp
.

retour au début ^
W2 Serveur SQL Microsoft (MSSQL)
W2.1 Description
Le serveur SQL Microsoft contient plusieurs sérieuses vulnérabilités qui permettent aux
attaquants distants d'obtenir des informations sensibles, d'altérer le contenu de la base de
données, de compromettre les serveurs SQL, et, dans certaines configurations, de compromettre
les serveurs hôtes.
Les vulnérabilités MSSQL sont bien connues du public et perpétuellement sous attaques. Deux
récents vers MSSQL en Mai 2002 et Janvier 2003 ont exploité plusieurs vulnérabilités connues de
MSSQL. Les hôtes compromis par ces vers génèrent un niveau de trafic réseau dommageable
quand ils recherchent d'autres hôtes vulnérables. Vous pouvez trouver une information
complémentaire sur ces vers à
Vers SQLSnake/Spida (Mai 2002)

http://isc.incidents.org/analysis.html?id=157


http://www.eeye.com/html/Research/Advisories/AL20020522.html


http://www.cert.org/incident_notes/IN-2002-04.html

Vers SQL-Slammer/SQL-Hell/Sapphire (Janvier 2003)

http://isc.incidents.org/analysis.html?id=180


http://www.nextgenss.com/advisories/mssql-udp.txt


http://www.eeye.com/html/Research/Flash/AL20030125.html


http://www.cert.org/advisories/CA-2003-04.html

Les ports 1433 et 1434 (ports par défaut Serveur MSSQL et Contrôle) ont aussi été
régulièrement référencés comme deux des ports les plus fréquemment scannés par l’
Internet
Storm Center
.
L'exploitation de la vulnérabilité SQLSnake dépend du compte administratif par défaut, ou
compte « sa » (Administrateur Système), ne disposant pas de mot de passe. Pour toute
configuration appropriée et défense d'un quelconque système, il est essentiel de s'assurer que
l'ensemble des comptes système sont protégés par mot de passe, ou complètement désactivés
s'ils ne sont pas utilisés. Vous pouvez trouver plus d'information concernant le paramétrage et la
gestion des mots de passe du compte « sa » dans la documentation MSDN (Microsoft Developer
Network) sous , aussi bien
Changer le login de l'Administrateur SQL Serveur
Vérifier et Changer le
Mot de passe de l'Administrateur Système en utilisant MSDE
. Le compte “sa” doit disposer d’un
mot de passe complexe et difficile à deviner, même s’il n’est pas utilisé pour votre
implémentation de SQL/MSDE.
Le code d'exploitation de la vulnérabilité SQL Slammer est basé sur un débordement de buffer
(tampon) dans le Service de Résolution de SQL Serveur. Quand le vers envoie des paquets
d'attaque forgés vers le port UDP 1434 des systèmes cibles vulnérables, ce débordement de
buffer est amené à s'exercer et la sécurité de l'hôte est ainsi compromise. Si une machine
fonctionne avec des services SQL qui sont sujets à ce débordement de buffer dans la pile et qu'il
reçoit des paquets de cette nature, il en résultera d'ordinaire une compromission totale du
serveur et de la sécurité du système. Le plus efficace des moyens de défense contre ces vers
consiste en une mise à jour assidue, des exercices de configuration système proactifs, et une
vérification du filtrage du port UDP 1434 sur les passerelles réseau.
Le "Desktop Engine" Microsoft 2000 Serveur (MSDE 2000) peut être considéré comme une
version "lite" de Serveur SQL. Beaucoup de propriétaires de système ne réalisent même pas que
MSDE fonctionne sur leurs systèmes et qu'ils disposent d'une version SQL Serveur installée.
MSDE 2000 est installé en tant que composant des produits Microsoft suivants:
1. SQL/MSDE Serveur 2000 (Editions Développement, Standard et Entreprise)
2. Visual Studio .NET (Editions Architect, Développement et Professionnel)
3. ASP.NET Web Matrix Tool
4. Office XP
5. Access 2002
6. Visual Fox Pro 7.0/8.0
Il y a de plus beaucoup d'autres packages logiciels nécessitant l'utilisation du logiciel MSDE 2000.
Veuillez vous connecter sur
http://www.SQLsecurity.com/forum/applicationslistgridall.aspx
pour
vérifier la mise à jour de la liste. Ce logiciel utilisant MSDE en tant que moteur de base de
données principal, est sujet aux même vulnérabilités que SQL/MSDE Serveur. MSDE 2000 peut
être configuré de façons multiples et différentes pour être à l'écoute des clients. Il peut être
configuré de façon à ce que les clients utilisent les "canaux nommés" (named pipes) sur une
session NETBIOS (port TCP 139/445), les sockets avec les clients qui se connectent au port TCP
1433, ou les deux. Quelle que soit la méthode utilisée, SQL Serveur et MSDE écouteront toujours
sur le port UDP 1434. Ce port est désigné comme port de contrôle. Les clients enverront un
message à ce port pour découvrir dynamiquement comment le client pourrait se connecter au
serveur.

Chaque fois que le simple paquet 0x02 lui est présenté, le moteur MSDE 2000 fournit des
informations le concernant. D'autres paquets causent un débordement de buffer sans jamais
devoir s'authentifier au serveur lui-même. Ce qui aggrave plus encore ces problèmes est que
l'attaque est canalisée sur UDP. Si les processus MSDE 2000 fonctionne dans le contexte de
sécurité d'un utilisateur de domaine ou du compte local SYST
È
ME, l'exploitation avérée de ces
failles de sécurité peut signifier la compromission totale du système cible.
Puisque SQL Slammer exploite un débordement de buffer sur le système cible, le suivi de "best
pratices" de mises à jours opportunes et une consciencieuse configuration système aide à
atténuer cette menace. En téléchargeant et en utilisant des outils défensifs tels que le
Kit de Mise
à jour Critique SQL de Microsoft
, on peut vérifier la vulnérabilité des systèmes locaux à cette
faille, parcourir des domaines ou des réseaux entiers à la recherche de l'existence de systèmes
vulnérables, et automatiquement mettre à jour les fichiers affectés avec le Kit de Mise à jour
Critique SQL.
Vous trouverez le rapport et l'analyse sur
incidents.org
pour plus de détails sur le ver SQL/MSDE
Slammer. Cette attaque particulière a affecté le Backbone Internet pendant quelques heures
dans la matinée du 25 janvier 2003.
W2.2 Systèmes d'Exploitation Affectés
Tout système Microsoft Windows avec le serveur Microsoft SQL/MSDE 7.0, le serveur Microsoft
SQL/MSDE 2000 ou le Microsoft SQL/MSDE Desktop Engine installé, aussi bien que tout système
qui utilise le moteur de MSDE séparément.
W2.3 Les identifiants CVE/CAN
CVE-1999-0999
,
CVE-2000-0202
,
CVE-2000-0402
,
CVE-2000-0485
,
CVE-2000-0603
,
CVE-2001-0344
,
CVE-2001-0879

CAN-2000-0199
,
CAN-2000-1081
,
CAN-2000-1082
,
CAN-2000-1083
,
CAN-2000-1084
,
CAN-2000-1085
,
CAN-2000-1086
,
CAN-2000-1087
,
CAN-2000-1088
,
CAN-2000-1209
,
CAN-2001-0509
,
CAN-2001-0542
,
CAN-2002-0056
,
CAN-2002-0154
,
CAN-2002-0186
,
CAN-2002-0187
,
CAN-2002-0224
,
CAN-2002-0624
,
CAN-2002-0641
,
CAN-2002-0642
,
CAN-2002-0643
,
CAN-2002-0644
,
CAN-2002-0645
,
CAN-2002-0649
,
CAN-2002-0650
,
CAN-2002-0695
,
CAN-2002-0721
,
CAN-2002-0729
,
CAN-2002-0859
,
CAN-2002-0982
,
CAN-2002-1123
,
CAN-2002-1137
,
CAN-2002-1138
,
CAN-2002-1145
,
CAN-2003-0118

W2.4 Comment déterminer si vous êtes vulnérable
Microsoft a publié un ensemble d'outils de sécurité à
http://www.microsoft.com/sql/downloads/securitytools.asp
. Le Toolkit, appelé Kit de mise à jour
criti
q
ue S
Q
L
,
contient de
p
récieux outils tels
q
ue S
Q
L Scan
,
S
Q
L Check
,
et la mise à
j
our criti
q
ue
de SQL.
Chip Andrews de
sqlsecurity.com
a réalisé un utilitaire appelé SQLPingv2.2. Cet outil envoie un
simple paquet UDP (d'une valeur octale de 0x02) à destination du port 1434 soit d'un hôte
unique ou d'un sous-réseau entier. Les serveurs SQL écoutant sur le port UDP 1434 répondront
en divulguant des détails système comme le numéro de version, des exemples, etc...
SQLPingv2.2 est considéré comme un outil de scanning et de découverte plus que SQL Scan de
Microsoft, et ne compromettra pas plus la sécurité de votre système et de votre réseau. Des
outils de sécurité SQL complémentaires peuvent être trouvés sur le
Site internet sécurité
SQL/MSDE
de Chip Andrews.
W2.5 Comment s’en protéger
Sommaire:
1. Désactiver le Service de Contrôle SQL/MSDE sur le port UDP 1434.
2. Appliquer le dernier service pack pour Microsoft SQL/MSDE serveur et/ou MSDE 2000.
3. Appliquer le dernier patch cumulatif qui est sorti après le dernier service pack.
4. Appliquer tous les patchs individuels sortis après le dernier patch cumulatif.
5. Activer l’enregistrement (la journalisation) d'identification SQL Serveur.
6. Sécuriser le serveur au niveau système et réseau.
7. Restreindre les privilèges du Service MSSQL/MSDE Serveur et de l’Agent SQL/MSDE
Serveur.
Détail:
1. Désactiver le service de contrôle SQL/MSDE sur le port UDP 1434.

Ceci peut facilement être accomplit en installant et en utilisant la fonctionalité fournie par
SQL Server 2000 Service Pack 3a
. Le moteur de base de données de Microsoft MSDE
2000 s'expose à deux vulnérabilités de débordements de buffer pouvant être exploitées
par un attaquant à distance sans qu’il ne doive jamais devoir s'authentifier auprès du
serveur. Ce qui aggrave plus encore ces problèmes est que l'attaque est canalisée sur
UDP. Si les processus MSDE 2000 fonctionne dans le contexte de sécurité d'un utilisateur
de domaine ou du compte local SYSTÈME, l'exploitation avérée de ces failles de sécurité
peut signifier la compromission totale du système cible. MS-SQL/MSDE Slammer envoie à
très haute fréquence un paquet UDP d'une longueur de 376 octets au port 1434 en
utilisant des cibles aléatoires. Une fois qu'ils sont infectés, les systèmes compromis
commenceront immédiatement à envoyer les paquets identiques de 376 octets. Le ver
envoie du trafic à des adresses IP aléatoires, y compris des adresses IP multicast, causant

un déni de service sur le réseau cible. Les machines autonomes infectées ont reportées un
taux de trafic de plus de 50 Mb/sec après avoir été infectées.

2. Appliquer le dernier service pack pour Microsoft SQL/MSDE serveur et MSDE 2000.

La version actuelle du service pack Microsoft SQL/MSDE Serveur est:
o SQL/MSDE Serveur 7.0 Service Pack 4
o MSDE/SQL Serveur 2000 Service Pack 3a
Afin de s’assurer de la version de vos mises à jour avec les futures upgrades, contrôler le
bulletin
Rendez vos serveurs SQL/MSDE moins vulnérables
de Microsoft TechNet.

3. Appliquez le dernier patch cumulatif qui est sorti après le dernier service pack.

Le patch cumulatif actuel pour toutes les versions de SQL/MSDE/MSDE Serveur est
disponible sur
MS02-061 Escalade de Privilège dans les tâches internet de SQL/MSDE
Serveur (Q316333/Q327068).
Afin de s’assurer de la version de vos mises à jour avec les futures upgrades, vous pouvez
vérifier le dernier patch cumulatif pour Microsoft SQL/MSDE Serveur sur:
o
Microsoft SQL/MSDE Server 7.0

o
Microsoft SQL Server 2000

o
MSDE Server Desktop Engine 2000 (MSDE 2000)

4. Appliquez tous les patchs individuels sortis après le dernier patch cumulatif.

Actuellement, il n’y a pas de patch individuel après le release
MS02-061 Escalade de
Privilège dans les tâches internet de SQL/MSDE Serveur (Q316333/Q327068)
. Mais pour
s’assurer de la version de vos mises à jour avec les futures upgrades, vous pouvez vérifier
la disponibilité de mise à jour de patchs individuels sur:
o
Microsoft SQL/MSDE Server 7.0

o
Microsoft SQL Server 2000

o
MSDE Server Desktop Engine 2000 (MSDE 2000)

5. Activez l’enregistrement (la journalisation) d'identification SQL Serveur.

La journalisation d'identification SQL Serveur est communément non activée. Ceci peut
être effectué par « Enterprise Manager » (Propriétés du Serveur; onglet Sécurité).

6. Sécuriser le serveur au niveau système et réseau.

Une des expositions la plus généralement attaquée de MSSQL/MSDE est que le compte
administratif est installé par défaut (connu sous le nom de « SA ») avec un mot de passe
à blanc. Si votre compte SQL/MSDE « SA » n'est pas protégé par un mot de passe, vous
ne disposez d'aucune sécurité efficace et pouvez être affecté par des vers et autre code
d'exploitation. Par conséquent, vous devriez suivre la recommendation issue du thème
« Identification du System Administrator (SA) »
Livres en ligne SQL/MSDE Serveur
pour
s'assurer que le compte intégré « sa » dispose d’un mot de passe fort, même si votre
serveur SQL/MSDE n’utilise pas ce compte. Une documentation sur
Changer
l'Identification de l'Administrateur SQL Serveur
et comment
Vérifier et Changer le mot de
p
asse S
y
stem Administrator en utilisant MSDE
est dis
p
onible sur Microsoft MSDN.

7. Restreindre les privilèges du Service MSSQL/MSDE Serveur et de l’Agent SQL/MSDE
Serveur.
Faites fonctionner le service MSSQL/MSDE Serveur et l’Agent SQL/MSDE Serveur sous un
compte de domaine valide disposant d’un minimum de privilèges, et non en tant que
compte Administrateur de Domaine, compte SYSTEM (sur NT) ou LocalSystem (sur 2000
ou XP). Un service compromis qui fonctionne avec des privilèges locaux ou sur un
domaine pourrait fournir à un attaquant le contrôle complet de votre machine et/ou de
votre réseau.
a. Activer l’authentification Windows NT, activer l’audit des logins réussis et refusés,
et arrêter et redémarrer alors le service MSSQL/MSDE Serveur. Si possible,
configurer vos clients afin qu’ils utilisent l’Authentification NT.
b. Le filtrage de paquet doit être accomplit aux frontières du réseau afin de prohiber
spécifiquement les connexions entrantes ou sortantes non autorisées à des
services MSSQL spécifiques. Le filtrage en entrée-sortie des ports TCP/UDP 1433 et
1434 pourrait empêcher des attaquants internes ou externes de scanner et
d’infecter des serveurs Microsoft SQL/MSDE vulnérables sur votre réseau ou des
réseaux externes non explicitement autorisés à fournir des services SQL/MSDE
publics.
c. Si les ports TCP/UDP 1433 et 1434 nécessitent d’être disponibles sur vos
passerelles, activez et personnalisez un filtrage en entrée-sortie afin d’empêcher
toute mauvaise utilisation de ce port.
Des informations additionnelles sur la sécurisation de Microsoft SQL/MSDE Serveur sont
disponibles sur

Microsoft SQL/MSDE Server 7.0 Security


Microsoft SQL/MSDE Server 2000 Security

retour au début ^
W3 Authentification Windows
W3.1 Description
Les mots de passe, passphrases et codes de sécurité sont virtuellement utilisés dans toute
interaction entre utilisateurs et systèmes d’information. La plupart des types d’authentification
utilisateur, aussi bien que la protection de fichier et de donnée, dépendent des mots de passe
utilisateur. Un accès correctement authentifié étant bien souvent non enregistré, ou même s'il
l’est n'éveillera probablement pas de soupçon, un mot de passe compromis est une occasion
d'explorer virtuellement sans détection un système de l'intérieur. Un attaquant aurait ainsi un
accès complet à n'importe quelles ressources disponibles pour cet utilisateur, et serait
significativement tout près d'avoir accès à d'autres comptes, à des machines proches, et peut-
être même à des privilèges administratifs. Malgré cette menace, les comptes avec de mauvais ou

sans mots de passe restent extrêmement communs et les entreprises avec une bonne politique
de mot de passe sont beaucoup trop rares.
Les vulnérabilités de mot de passe les plus communes sont:
• Comptes utilisateurs avec mots de passe faibles ou inexistants.
• Indé
p
endamment de la robustesse de leur mot de
p
asse
,
les utilisateurs ne le
p
rotè
g
e
p
as

correctement.
• Le système d’exploitation ou le logiciel additionnel créé des comptes administratifs avec
des mots de passe faibles ou inexistants.
• Les algorithmes de hachage de mot de passe sont connus et les hashs sont souvent
stockés de manière telle qu’ils sont visibles par n’importe qui. La meilleure et la plus
appropriée des défense contre cela est d'avoir une politique de mot de passe forte qui
inclut des instructions minutieuses pour de bonnes habitudes et la vérification proactive
de l'intégrité du mot de passe.
Microsoft Windows ne stocke ni ne transmet les mots de passe en clair - il utilise un « hash » du
mot de passe pour l'authentification. Un « hash » est un résultat de taille fixe obtenu par
l’application d'une fonction mathématique (l'algorithme de hachage) à une quantité arbitraire de
données (connu aussi comme le challenge de message). (Bibliothèque MSDN) Il y a trois
algorithmes d'authentification Windows: LM (le moins sûr, le plus compatible); NTLM et NTLMv2
(le plus sûr et le moins compatible). Bien que la plupart des environnements Windows actuels
n'aient aucun besoin du support de LAN Manager (LM), Microsoft Windows stocke localement le
résultat des hachages de mots de passe LM (connus aussi sous le nom de hachages LANMAN)
par défaut sur les systèmes Windows NT, 2000 et XP (mais pas sur Windows 2003). LM utilisant
un schéma de chiffrement beaucoup plus faible que les approches actuelles de Microsoft (NTLM
et NTLMv2), les mots de passe LM peuvent être craqués en très peu de temps. Même les mots de
passe autrement considérés comme "forts" peuvent être craqués par force brute sous une
semaine avec le matériel actuel.
http://www.msdn.miscrosoft.com/library/default.asp?url=/library/en-us/security/

Security/h_gly.asp

Les faiblesses des hachages LM dérivent de ce qui suit:
• Les mots de passe sont tronqués à 14 caractères.
• Les mots de passe sont complétés avec des espaces pour atteindre les 14 caractères.
• Les mots de passe sont convertis en caractères majuscules.
• Les mots de passe sont divisés en deux parties de sept caractères chacune.
Ce processus de hachage signifie qu'un attaquant doit seulement accomplir la tâche triviale de
forcer deux mots de passe à sept caractères en majuscules afin de disposer d'un accès
authentifié à votre système. Puisque la complexité de craquage des hachages augmente
géométriquement avec la longueur du hash, chaque séquence de sept caractères est d'un ordre
de grandeur au moins plus simple à attaquer par force brute qu'une séquence combinée de
quatorze caractères ne peut l'être. Puisque toutes les séquences font exactement sept caractères
(espaces y compris) entièrement en majuscules, une attaque par dictionnaire est également
simplifiée. La méthode de hachage LM sape donc complètement les bonnes politiques de mot de
passe.
En plus du risque posé par le fait d'avoir le hasch LM stockés dans la SAM, le processus
d'authentification LAN Manager est souvent activé sur les clients et accepté par les serveurs. En
conséquence, les machines Windows capables d'utiliser des algorithmes de hachage plus forts
envoient au lieu de cela des hashs LM faibles à travers le réseau, rendant l'authentification
Windows vulnérable à l'écoute par « sniffing » de paquet, et facilitent donc les efforts d'un
attaquant à obtenir et forcer les mots de passe de l’utilisateur.
W3.2 S
y
stèmes d'Ex
p
loitation Affectés
Tous les systèmes d’exploitation Microsoft Windows.
W3.3 Les identifiants CVE/CAN
CVE-2000-0222

CAN-1999-0504
,
CAN-1999-0505
,
CAN-1999-0506

W3.4 Comment déterminer si vous êtes vulnérable
Bien qu'il y ait des symptômes observables de faiblesse générale de mot de passe, comme par
exemple l'existence de comptes utilisateurs actifs alors que ceux-ci ont quittés l'entreprise ou des
services non utilisés, la seule façon de connaître à coup sûr la robustesse de chaque mot de
passe individuel est de les tester tous avec le même programme de cassage de mots de passe
utilisé par des attaquants.

A noter: N'utilisez jamais un scanner de mot de passe même sur des systèmes
pour lesquels vous disposez d'un accès administratif, sans permission explicite et
de préférence écrite de votre employeur. Des administrateurs avec la plus
bienveillante des intentions ont été renvoyés pour avoir utilisé des programme de
cassage de mots de passe sans autorisation.

Quelques-uns des meilleurs outils de craquage disponibles sont:
LC4 (l0phtcrack version 4)
et
John the Ripper

Quant à la question d'un hash LAN Manager stocké localement:
• Si vous utilisez une installation de NT, 2000 ou XP, vous êtes vulnérables puisque par
défaut les hashs LAN Manager sont stockés localement.
• Si vous avez des systèmes d'exploitation dans votre environnement qui exigent
l'authentification LM pour communiquer avec les serveurs, vous êtes donc vulnérables
parce que ces machines envoient les hashs LM qui peuvent être « sniffés » du réseau.
W3.5 Comment s’en protéger
La meilleure et la plus appropriée des défenses contre les mots de passe faibles est une politique
forte qui inclut des instructions minutieuses afin d'initier de bonnes habitudes de mot de passe et

la vérification proactive de l'intégrité de ceux-ci.
1. Assurez-vous de la robustesse suffisante des mots de passe. Avec assez de
matériel et assez de temps, n'importe quel mot de passe peut être craqué par force brute.
Mais il y a des façons plus simples et avérées de connaître les mots de passe sans une
telle dépense. Les programmes de craquage de mots de passe emploient une typologie
d'attaque connue sous le nom d'attaque par dictionnaire. Les méthodes de chiffrement
étant connues, les utilitaires de craquage comparent simplement la forme chiffrée d'un
mot de passe par rapport à des états chiffrés d'un dictionnaire de mots (dans beaucoup
de langues), des noms propres et des permutations des deux. Par conséquent, un mot de
passe dont l’origine a une quelconque ressemblance à un mot connu est fortement
prédisposé à une attaque par dictionnaire. Beaucoup d'entreprises demandent à leurs
utilisateurs de générer des mots de passe en utilisant des combinaisons de caractères
alphanumériques et spéciaux, les utilisateurs y adhérant le plus souvent en prenant un
mot
(
«
p
assword »
)
et en convertissant les lettres en nombres ou caractères s
p
éciaux
(« pa$$w0rd »). De telles permutations ne peuvent pas protéger contre une attaque par
dictionnaire: « pa$$w0rd » est aussi susceptible d'être craqué que « password ».

Un bon mot de passe ne peut pas donc avoir un mot ou un nom propre comme origine.
Une politique de mot de passe forte devrait inciter les utilisateurs à générer des mots de
passe plus aléatoires, par exemple comme une expression ou le titre d'un livre ou d'une
chanson. En concaténant une chaîne de caractères plus longue (en prenant la première
lettre de chaque mot, ou en substituant un caractère spécial pour un mot, en enlevant
toutes les voyelles, etc...), les utilisateurs peuvent générer des chaînes suffisamment
longues qui combinent des caractères alphanumériques et spéciaux afin de rendre les
attaques par dictionnaire beaucoup plus difficiles. Et si la chaîne de caractères est facile à
se rappeler, le mot de passe devrait donc l'être aussi.
Une fois que l'on donne les instructions appropriées aux utilisateurs pour générer de bons
mots de passe, les procédures devraient être mises en place pour s'assurer que ces
instructions sont suivies. La meilleure façon de le faire est de valider le mot de passe
chaque fois que l'utilisateur le change, en employant Passfilt (NT4).
Windows 2000, XP et 2003 disposent de puissants outils pour mettre en application la
politique de mot de passe. Pour voir votre politique de mot de passe actuelle sur la
plupart des systèmes Windows, suivez ces étapes (Démarrer - Programmes - Outils
Administratifs - Politique de Sécurité Locale - choisir Politique de Comptes - Politique de
Mot de passe). Les paramètres de La Politique de Sécurité Locale sont les suivants:

o Le mot de passe doit répondre aux exigences de complexité. Déterminer si
les mots de passe doivent être tributaires des exigences de complexité. Les
exigences de complexité sont mises en application quand les mots de passe sont
changés ou créés. Si on permet cette politique, les mots de passe doivent
satisfaire aux exigences minimales suivantes:
1. Ne pas contenir tout ou partie du nom de compte de l'utilisateur
2. Etre d’une longueur d’au moins six caractères
3. Contenir des caractères de trois des quatre catégories suivantes:
4. Caractères anglais majuscules (A à Z)
5. Caractères anglais minuscules (a à z)
6. Chiffres en Base 10 (0 à 9)
7. Caractères non alphanumériques (e.g., !, $, #, %)
o Imposez un historique des mots de passe (de 0 à 24): Déterminez le nombre
de nouveaux mots de passe uniques qui doivent être associés à un compte
utilisateur avant qu'un ancien mot de passe ne puisse être réutilisé. La valeur doit
être entre 0 et 24 mots de passe. La configuration de ce paramètre d'unicité à 0
permet le recyclage de mot de passe; Un paramétrage d'unicité à 24 mots de
passe exige 24 changements de mot de passe avant que le mot de passe initial ne
puisse être réutilisé. Cette politique permet aux administrateurs d'améliorer la
sécurité en s'assurant que d'anciens mots de passe ne soient pas réutilisés
continuellement. Pour maintenir l'efficacité de l'historique des mots de passe, ne
permettez pas le changement immédiat des mots de passe quand vous configurez
la durée de validité minimale du mot de passe.
o Durée de validité maximale du mot de passe (0 à 999 jours): Déterminez la
période de validité (en jours) de l'utilisation d'un mot de passe avant que le
s
y
stème n'exi
g
e son chan
g
ement
p
ar l'utilisateur. Vous
p
ouvez faire ex
p
irer les
mots de passe après un certain nombre de jours (entre 1 et 999), ou vous pouvez
spécifier que les mots de passe n'expirent jamais en mettant le nombre de jours à
0.
o Durée de validité minimale du mot de passe (0 à 999 jours): Déterminez la
période de validité (en jours) de l'utilisation d'un mot de passe avant que
l'utilisateur ne puisse le changer. Vous pouvez mettre une valeur entre 1 et 999
jours, ou vous pouvez autoriser la prise en compte des changements
immédiatement en mettant le nombre de jours à 0. L'âge minimal du mot de passe
doit être inférieur à l'âge maximal du mot de passe. Configurez l'âge minimal du
mot de passe afin qu'il soit supérieur à 0 si vous voulez mettre en application
l'historique des mots de passe pour être efficace. Sans un âge minimal de mot de
passe, les utilisateurs peuvent ressaisir des mots de passe en boucle à plusieurs
reprises jusqu'à ce qu'ils arrivent à un ancien favori. La configuration par défaut ne

suit pas cette recommandation, de telle sorte qu'un administrateur puisse spécifier
un mot de passe pour un utilisateur et exiger ensuite que l'utilisateur change le
mot de passe défini par l'administrateur quand l'utilisateur se connecte. Si
l'historique des mots de passe est mis à 0, l'utilisateur n'a pas à choisir de
nouveau mot de passe. C'est pour cette raison que l'historique des mots de passe
est mis à 1 par défaut.
o Longueur minimale du mot de passe (de 0 à 14 caractères): Déterminez le
nombre de caractères minimum qu'un mot de passe peut contenir pour un compte
d'utilisateur. Vous pouvez mettre une valeur entre 1 et 14 caractères, ou vous
pouvez établir qu'aucun mot de passe n'est exigé en mettant le nombre de
caractères à 0. La longueur minimale d'un mot de passe devrait se conformer à la
politique de sécurité d'entreprise (il est toutefois recommandé qu'il soit mis à 8
caractères ou plus.
l'Agence Nationale de Sécurité (la NSA)
recommande 12
caractères).
o Stockez le mot de passe en utilisant un chiffrement réversible pour
l'ensemble des utilisateurs dans le domaine: Déterminez si Windows 2000,
2003 et XP Professionnel stockent les mots de passe en utilisant le chiffrement
réversible. Cette politique fournit un support pour les applications utilisant des
protocoles qui exigent la connaissance du mot de passe de l'utilisateur pour
identification. Stocker des mots de passe en utilisant le chiffrement réversible est
strictement la même chose que stocker des mots de passe en clair. Pour cette
raison, on ne devrait jamais permettre cette politique à moins que des prérequis
applicatifs ne priment sur le besoin de protéger l'information du mot de passe.
Une approche qui peut être utilisée pour générer automatiquement et assigner des mots
de passe complexes aux comptes utilisateurs est la suivante - saisissez la commande
suivante (en ligne de commande Windows NT4, 2000, XP, 2003):
Net user username /random
L'exécution de cette commande assignera des mots de passe complexes aléatoires (mais
toujours à 8 caractères de long) à un compte et affichera ce mot de passe sur la console
écran. Cette méthode est d'habitude plus appropriée pour assigner des mots de passe à
des comptes de service plutôt que pour des utilisateurs réels.
La meilleure façon de vérifier la qualité des mots de passe est d'utiliser un utilitaire de
craquage de mots de passe, en tant que partie intégrante de la routine de scan, en mode
autonome.
Rappel: N'utilisez jamais un scanner de mot de passe même sur des
systèmes pour lesquels vous disposez d'un accès administratif, sans
permission explicite et de préférence écrite de votre employeur. Des
administrateurs avec la plus bienveillante des intentions ont été renvoyés
pour avoir utilisé des programmes de cassage de mots de passe sans
autorisation.
Une fois que vous avez l'autorisation d'utilisez des utilitaires de craquage sur votre
système, faites-le régulièrement sur une machine protégée. Les utilisateurs dont les mots
de passe sont craqués devraient être notifiés confidentiellement et des instructions
données sur la façon de choisir un bon mot de passe. Administrateurs et Management
(i.e. Direction) devraient établir et développer ces procédures ensemble afin que le
Management puisse fournir une assistance quand les utilisateurs ne répondent pas à ces
notifications.
Une autre façon de se protéger contre les mots de passe inexistants ou faibles est
d'utiliser une forme alternative d'authentification comme les « Tokens » générant des
mots de passe aléatoires ou la biométrie.

2. Protégez les mots de passe robustes. Même si les mots de passe eux-mêmes sont
robustes, les comptes peuvent être compromis si les utilisateurs ne protègent pas leurs
mots de passe. Une bonne politique devrait stipuler qu'un utilisateur ne fournisse jamais
son mot de passe à quelqu'un d'autre, qu'il ne le note jamais là où il pourrait être lu par
d'autres, et garantir la sécurisation de tous les fichiers dans lesquels un mot de passe
pourrait être stocké afin d'automatiser l'authentification (les mots de passe sont plus
faciles à protéger quand cette procédure n’est utilisée qu’en cas d'absolue nécessité). La
durée de vie d'un mot de passe devrait être imposée afin que tous mots de passe qui
échappent à ces règles ne soient seulement vulnérables que pendant une courte période,
et les anciens mots de passe ne soient pas réutilisés. Assurez-vous que les utilisateurs en
soient avertis et qu'ils puissent changer leur mot de passe avant qu'il n'expire. Quand ils
sont confrontés au message « Votre mot de passe a expiré et doit être changé », les
utilisateurs auront tendance à choisir un mauvais mot de passe.

3. Contrôlez efficacement les comptes.
o Tous les comptes de service ou administratifs non utilisés devraient être désactivés
ou supprimés. Tous les comptes de service ou administratifs utilisés devraient
disposer de nouveaux mots de passe robustes.
o Auditez les comptes sur vos systèmes et créez une liste principale. N'oubliez pas
de vérifier les mots de passe sur des systèmes comme les routeurs et les
imprimantes connectées à l’Internet, les copieurs et les contrôleurs d'impression.
o Créez des procédures afin d'ajouter des comptes autorisés à la liste, et pour
supprimer des comptes quand ils ne sont plus utilisés.
o Vérifiez régulièrement la liste afin de vous assurer qu'aucun nouveau compte n'ait
été ajouté et que les comptes inutilisés ont été supprimés.
o Disposez de procédures strictes permettant de supprimer des comptes quand les
employés ou dirigeants quittent l'entreprise ou quand les comptes ne sont plus
exigés.
4. Maintenez une politique de mot de passe stricte pour l'entreprise. En plus des
contrôles de niveau de service s
y
stème d'ex
p
loitation ou réseau
,
il existe
q
uantité
d'utilitaires complets disponibles permettant d'aider à gérer une bonne politique de mots
de passe. De nombreux exemples de modèles de politique, procédures de développement
de politique, principes de base de sécurisation de mots de passe, et liens vers de
nombreux sites Web de politique sécurité (y compris une information de politique de mots
de passe) sont disponibles sur le site du
Projet de Politique Sécurité du SANS
.

5. Désactivez l'authentification LM sur l'ensemble du réseau. Le meilleur
remplacement de l'authentification Windows LAN Manager est NT LAN Manager version 2
(NTLMv2). Les méthodes de « challenge/response » NTLMv2 surmontent beaucoup de
faiblesses inhérentes à LM en utilisant un chiffrement plus robuste et ont amélioré
l'authentification et les mécanismes de sécurité de session. La clé de registre qui contrôle
cette capacité tant dans Windows NT que dans 2000 est:

Ruche: HKEY_LOCAL_MACHINE
Clé: System\CurrentControlSet\Control\LSA
Valeur: LMCompatibilityLevel
Valeur Type: REG_DWORD - Number
Range Valide: 0-5
Défaut: 0
Description: Ce paramètre spécifie le type d'authentification à utiliser.
0 - Envoyer la réponse LM et la réponse NTLM; ne jamais utiliser la sécurité de session
NTLMV2
1 - Utiliser la sécurité de session NTLMV2 si elle est négociée
2 - Envoyer seulement l’authentification NTLM
3 - Envoyer seulement l'authentification NTLMV2
4 - Le Contrôleur de Domaine (DC) refuse l’authentification LM
5 - Le Contrôleur de Domaine (DC) refuse l'authentification LM et NTLM (n'accepte que
NTLMv2)
Sur Windows 2000, 2003 et XP la même fonctionnalité peut être mise en oeuvre en
configurant le niveau d'authentification LAN Manager (Windows 2000) ou la Sécurité
Réseau: niveau d'authentification LAN Manager (Windows XP, 2003) (Démarrer-
Programmes - Outils Administratifs - Politique de Sécurité Locale - Politiques Locales -
Options de Sécurité).
Si l'ensemble de vos systèmes correspond à un niveau d’OS Windows NT SP4 ou plus
récents, vous pouvez paramétrer la valeur de cette clé à 3 sur tous les clients et à 5 sur
tous les Contrôleurs de Domaine afin d'empêcher toute transmission de hash LM sur le
réseau. Cependant, les anciens systèmes (comme Windows 95/98) n'utiliseront pas
NTLMV2 avec le Client de base de Réseau de Microsoft. Pour disposer de la fonctionnalité
NTLMV2, installez le Directory Services Client. Une fois installé, le nom de la valeur dans
le registre est « LMCOMPATIBILITY » et les valeurs permises sont 0 ou 3.
Si vous ne pouvez pas forcer vos anciens clients à utiliser NTLMV2, vous pouvez bénéficier
d'une amélioration sensible sur le hachage LM en forçant NTLM (NT LAN Manager version
1) au niveau du Contrôleur de Domaine (mettez LMCOMPATIBILITYLEVEL à 4, ou si vous
utilisez l'outil Politique de Sécurité Local configurez le niveau d'authentification LAN
Manager à la valeur : Envoyer seulement la Réponse NTLMV2 \Refuser LM). Mais l'option
la
p
lus sûre en ce
q
ui concerne les anciens s
y
stèmes est de les mi
g
rer vers une nouvelle
plate-forme opérationnelle, puisque les anciens systèmes d'exploitation ne permettent pas
le support de ce niveau de sécurité minimal.

6. Empêchez le stockage du hash LM. Un des problèmes principaux avec le fait de
simplement retirer les hashs LM de passer sur le réseau est que les hashs sont toujours
créés et stockés dans la SAM ou dans Active Directory. Microsoft met à disposition un
mécanisme permettant de désactiver entièrement la création des hashs LM, mais
seulement pour Windows 2000, 2003 et XP. Sur les systèmes Windows 2000 (SP2 ou plus
récent), la clé de registre suivante contrôle cette fonction:

Ruche: HKEY_LOCAL_MACHINE
Clé: System\CurrentControlSet\Control\LSA\NoLMHash
Si cette clé est créée sur un Contrôleur de Domaine Windows 2000, les hashs LanMan ne
seront plus créés et stockés dans Active Directory.
Sur Windows XP et 2003, la même fonctionnalité peut être mise en oeuvre en activant la
configuration de la Sécurité Réseau : ne stockez pas la valeur de hachage LAN Manager
lors du prochain changement de mot de passe (Démarrer - Programmes - Outils
Administratifs - Politique de Sécurité Locale - Politiques Locales - Options de Sécurité).
Après avoir effectué ces modifications le système doit être redémarré afin que le
changement puisse prendre effet.

Note importante: Cela évite seulement la génération de nouveaux hashs
LM. Les hashs LM existants sont enlevés individuellement au prochain
changement de mot de passe de chaque utilisateur.
7. Empêchez la copie des hashs de mots de passe et de la base SAM. Les utilitaires de

craquage de mots de passe, mentionnés dans cette section, obtiennent les hashs des
mots de passe par:
o Reniflage (Sniffing) des mots de passe sur le réseau. Contre-mesures : 1.
Utilisation de réseaux commutés; 2. Détection et suppression des cartes réseau
en mode promiscious (elles peuvent être détectées par la plupart des outils
d'évaluation de sécurité commerciaux, tels les outils gratuits comme PromiScan ou
ethereal
).
o En copiant le fichier de la base SAM (situé dans le sous-répertoire
%SystemRoot%\System32\Config\ habituellement C:\Winnt\System32\Config\ -
sur Windows NT4 et 2000 ou C:\Windows\System32\Config\ - sur Windows XP et
2003). Ce fichier est normalement verrouillé par l'OS Windows et peut être copié
seulement quand le système est démarré sur un autre OS. Le fichier SAM peut
aussi être obtenu en restaurant la sauvegarde du fichier SAM ou l'État Système
(Windows 2000, 2003, XP). Le fichier SAM est aussi placé sur le Disquette de
Réparation d’Urgence de NT4 (Emergency Repair Disk).
Countre-mesures: Limitez et contrôlez l'accès physique aux systèmes informatiques
(p
articulièrement aux Contrôleurs de Domaine
),
médias de sauve
g
arde et dis
q
uettes de
réparation.
Les articles suivants de Microsoft fournissent des références utiles:
o
Comment désactiver l'Authentification LM sur Windows NT [Q147706]
détaille les
changements requis dans la Base de Registres pour Windows 9x et Windows
NT/2000.
o MS03-034 : Un défaut dans NetBIOS pourrait conduire à une fuite d'information
(824105)
o
Le niveau de compatibilité LM et ses Effets [Q175641]
explique les possibilités
d'interopérabilité avec ce paramètre.
o
Comment activer l'Authentification NTLMv2 pour Windows 95/98/2000/NT
[Q239869]
explique comment utiliser le Client Windows 2000 Directory Services
pour Windows 95/98 afin de surmonter la limitation de compatibilité pour NTLMV2.
o
Nouvelle clé de registre pour supprimer les hashs LM d'Active Directory et Gérer la
Sécurité de Compte

retour au début ^
W4 Internet Explorer (IE)
W4.1 Description
Microsoft Internet Explorer (IE) est le navigateur internet par défaut sur les plate-formes
Microsoft Windows. Toutes les versions existantes d'Internet Explorer ont des vulnérabilités
critiques s'ils ne sont pas mis à jour avec patchs d'actualité. Un administrateur malveillant de site
internet peut concevoir des pages web pour exploiter ces vulnérabilités dans le contexte d'un
utilisateur d'Internet Explorer pendant qu'il navigue sur ces pages.
Les vulnérabilités peuvent être classées dans de multiples catégories incluant le « spoofing »
(l'imitation) de pages web ou de l'interface Windows, des vulnérabilités de contrôle ActiveX, des
vulnérabilités de script actifs, l'interprétation erronée de type MIME et de contenu, ainsi que des
débordements de buffers. Les conséquences peuvent inclure la divulgation de cookies, de fichiers
locaux ou de données, l'exécution de programmes locaux, le téléchargement et l'exécution de
code arbitraire, ou la totale prise de contrôle du système vulnérable.
W4.2 Systèmes d'Exploitation Affectés
Ces vulnérabilités existent sur les systèmes Microsoft Windows fonctionnant avec n'importe
quelle version de Microsoft Internet Explorer. Il est important de noter que IE est installé avec
toute une variété de logiciel Microsoft et est donc typiquement présent sur tous les systèmes
Windows, même sur des serveurs où la navigation internet est rarement nécessaire.
W4.3 Les identifiants CVE/CAN
CVE-2001-0002
,
CVE-2001-0154
,
CVE-2001-0339
,
CVE-2001-0727
,
CVE-2001-0875
,
CVE-2002-0022
,
CVE-2002-0027
,
CVE-2003-0344

CAN-2002-0190
,
CAN-2002-0193
,
CAN-2002-1258
,
CAN-2003-0111
,
CAN-2003-0113
,
CAN-2003-0114
,
CAN-2003-0233
,
CAN-2003-0309
,
CAN-2003-1328

W4.4 Comment déterminer si vous êtes vulnérable
Si vous utilisez Internet Explorer sur votre système et n'avez pas installé le
patch de sécurité
cumulatif
, vous êtes probablement plus que vulnérable. Si la fonction de mise à jour « Windows
Update » est activée sur votre machine, vous pouvez vérifier si IE est installé et quels patchs
d'Internet Ex
p
lorer sont installées sur votre s
y
stème en visitant
http://windowsupdate.microsoft.com. Si la mise à jour de Windows n'est pas disponible pour
votre système, vous pouvez utiliser HFNETCHK, le Contrôleur de Hotfix Sécurité Réseau, ou
Microsoft Baseline Security Analyzer (MBSA) pour faire de même.
Vous pouvez aussi trouver des outils d'analyse d'Internet Explorer en ligne, comme le
Vérificateur de Navigateur Qualys
, afin de faire une très bonne évaluation de l'état de sécurité de
IE sur vos systèmes.
W4.5 Comment s’en protéger
Les patchs pour ces vulnérabilités sont disponibles pour la version 6.0 d'Internet Explorer. Les
versions précédentes d'Internet Explorer sont aussi vulnérables; cependant les patchs ne
peuvent pas être disponibles pour des versions précédentes. Si vous utilisez IE 5.5 ou antérieur,
la mise à niveau vers IE 6.0 est fortement recommandée, les service packs pour les versions
précédentes d'Internet Explorer n'étant plus disponibles. Si vous utilisez IE 6.0, commencez par
une mise à jour vers le service pack le plus récent pour Internet Explorer qui peut être trouvé sur
ce lien
Internet Explorer 6 SP1
.
Vous devriez aussi ajouter le dernier patch de sécurité cumulatif (
828750
) qui répare les
vulnérabilités complémentaires. Pour plus d'information sur les vulnérabilités, ce patch et les
changements appropriés pouvant atténuer les risques pour votre configuration, veuillez consulter
le bulletin de sécurité précité et l'article de la Base de Connaissance.
Pour maintenir la protection de votre système, soyez attentif à la progression de toute nouvelle
mise à jour de IE avec Windows Update, HFNetChk, ou Microsoft Baseline Security Analyzer
(MBSA). Vous pouvez aussi disposer d'information sur la mise à jour générale de IE sur le site
central de Microsoft Internet Explorer.
W4.6 Comment sécuriser Internet Explorer
Pour configurer les paramètres de Sécurité pour Internet Explorer:
1. Sélectionnez Options Internet sous le menu d'Outils.
2. Sélectionnez l'onglet de Sécurité et cliquez ensuite sur Personnaliser le Niveau pour la
zone Internet.

La plupart des défauts dans IE sont exploités par Scripting Actif (Active Scripting) ou des
Contrôles ActiveX.
3. Sous Script, Sélectionnez « Demander » pour Permettre aux opérations de copies via
script d'empêcher le contenu d'être exposé de votre presse-papiers.

Note: « Active Scripting » ne devrait pas être désactivé puisqu'il est utilisé par beaucoup
de sites internet.
Les contrôles ActiveX ne sont pas aussi populaires mais sont potentiellement plus
dangereux, en cela qu'ils permettent un accès plus important au système.
4. Sélectionnez Demander pour le Téléchargement des contrôles ActiveX signés.
5. Sélectionnez Désactiver pour le Téléchargement des contrôles ActiveX non signés.
6. Sélectionnez aussi Désactiver
p
our contrôles d’Initialisation et de scri
p
t ActiveX non
marqués comme sécurisés.

Les applets Java ont typiquement plus de capacités que les scripts.
7. Sous Microsoft VM, Sélectionnez Haute Sécurité pour les permissions Java afin de faire
fonctionner correctement l'applet Java dans un « bac à sable » (Sandbox) et empêcher un

accès privilégié à votre système.
8. Sous Divers sélectionnez Désactiver pour Accès aux sources de données sur plusieurs
domaines afin d'éviter les attaques de type « Cross-site scripting ».
Assurez-vous aussi qu'aucun site non approuvé ne se trouve dans les sites de confiance ou les
zones d'intranet locales, ces zones disposant de paramètres de sécurité plus faibles que les
autres zones.

retour au début ^
W5 Services d’accès distants Windows
W5.1 Description
La famille des plate-formes opérationnelles Windows supporte une multitude de méthodes et de
technologies réseau différentes, du support natif de la plupart des protocoles réseau standard
aux fonctionnalités incorporées nécessaires aux nombreuses méthodes et techniques spécifiques
à Microsoft. Parmi ces technologies réseau spécifiques Microsoft figurent notoirement des failles
inhérentes à la mauvaise configuration des partages réseau NETBIOS, les sessions nulles par
connexions anonymes, l'accès distant à la Base de Registre et les appels de procédure distants.
Ces items constituent une grande part des exploits (i.e. exploitation des vulnérabilités) au niveau

réseau sur Windows et sont décrit dans le texte suivant.

NETBIOS -- Partages réseau Microsoft non protégés Microsoft Windows fournit à
une machine hôte la capacité de partager des fichiers ou des dossiers à travers un
réseau avec d'autres hôtes par les partages réseau Windows. Le mécanisme sous-
jacent de cette fonction est le protocole Server Message Block (SMB), ou le
Système de Fichiers Commun d'Internet (CIFS - Common Internet File System).
Ces protocoles permettent à un hôte de manipuler des fichiers distants comme s’ils
se trouvaient en local.

Bien que ce soit une puissante et utile fonctionnalité de Windows, la configuration
incorrecte de partages réseau peut exposer des fichiers critiques ou peut fournir un
mécanisme à un utilisateur ou un programme malveillant permettant la prise de
contrôle totale de l'hôte. Un des moyens par lequel le ver I-Worm.Klez.a-h (
Famille
Klez
), le virus Sircam (
Cf. l'avis 2001-22 du CERT
) et le ver Nimda (
Cf. l'avis 2001-
26 du CERT
) se sont si rapidement diffusés en 2001 fut par la découverte de
partages réseau non protégés dans lesquels ils plaçaient des copies d’eux-même.
Beaucoup de possesseurs d’ordinateurs ouvrent inconsciemment leurs systèmes
aux pirates informatiques en rendant leurs disques accessibles en lecture et en
écriture aux utilisateurs réseau. A l’inverse, une configuration de partages réseau
effectuée avec attention permet d’atténuer les risques de compromission.
Connexion Anonyme
Une session nulle est une session établie sans autorisation (c'est-à-dire Nom
d’Utilisateur et Mot de
p
asse à blanc
)
. Des sessions nulles
p
euvent être utilisées
pour afficher des informations sur des utilisateurs, des groupes, des partages et
les politiques de mots de passe. Les services Microsoft Windows NT fonctionnant
comme compte Système Local sur l'ordinateur local communique avec d'autres
services sur le réseau en établissant des sessions nulles. Windows 2000 et les
services ultérieurs fonctionnant comme compte Système Local sur l'ordinateur
local utilisent le compte machine local pour s’authentifier aux autres serveurs.
Active Directory fonctionnant en mode natif n'accepte pas les requêtes de session
nulles. En mode mixte, Active Directory autorise un accès compatible pré-Windows
2000 en acceptant les requêtes de session nulles qui, en retour, héritent des
vulnérabilités inhérentes aux sessions nulles de Windows NT.
Accès distant à la Base de Registres
Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000, Windows ME et
Windows XP emploient une base de données hiérarchique centrale, connue sous le
nom de Base de Registres, pour gérer les configurations de logiciels, de systèmes
et de paramètres utilisateurs. Des permissions ou paramètres de sécurité
incorrects peuvent permettre un accès distant au Registre. Les attaquants peuvent
exploiter cette possibilité pour compromettre le système ou établir une base pour
ajuster l'association de fichier et les permissions pour activer un code malveillant.
Appels de Procédure à distance
Beaucoup de versions de systèmes d'exploitation Microsoft (Windows NT 4.0,
2000, XP et 2003) fournissent un mécanisme d'inter-processus de communication
qui permet aux programmes fonctionnant sur un hôte d'exécuter du code sur des
hôtes distants. Trois vulnérabilités ont été publiées qui permettraient à un
attaquant de faire fonctionner du code arbitraire sur des hôtes vulnérables avec
des privilèges Système Locaux. Une de ces vulnérabilités a été exploitée par les
vers Blaster/MSblast/LovSAN et Nachi/Welchia. Il y a aussi d'autres vulnérabilités
qui permettraient aux attaquants de monter des attaques de déni de service contre
des composants RPC.

W5.2 Systèmes d'Exploitation Affectés
Windows 95, Windows 98, Windows NT Workstation et Server, Windows Me, Windows 2000
Workstation et Server, Windows XP Home et Professionel, et Windows 2003 sont tous
vulnérables.
W5.3 Les identifiants CVE/CAN
NETBIOS
CVE-2000-0979

CAN-1999-0518
,
CAN-1999-0519
,
CAN-1999-0621
,
CAN-2000-1079

Connexion Anonyme
CVE-2000-1200

Accès distant à la Base de Registres
CVE-2000-0377,
CVE-2002-0049

CAN-1999-0562
,

CAN-2001-0045
,

CAN-2001-0046
,

CAN-2001-0047
,

CAN-2002-0642
,

CAN-2002-0649
,
CAN-2002-1117

Appels de Procédure à distance
CAN-2002-1561
,
CAN-2003-0003
,
CAN-2003-0352
,
CAN-2003-0528
,
CAN-2003-0605
,
CAN-2003-0715

W5.4 Comment déterminer si vous êtes vulnérable
Comment déterminer si vous êtes vulnérable aux problèmes NETBIOS
précités ?
Nombre d'outils disponibles peuvent vous aider à déterminer la présence des
vulnérabilités NETBIOS précitées sur vos systèmes.
NAT' (NetBIOS Auditing Tool – Outil d’Audit NetBIOS) est disponible sur Afentis
Security. NAT explore les services de partages de fichiers NETBIOS disponibles sur
des systèmes cibles et met en oeuvre une approche pas à pas pour recueillir une
information avant de tenter d'obtenir accès au fichier au niveau système. NAT est
disponible sous Licence Grand public GNU :
http://www.afentis.com/resources/win32/nat/
.
Les utilisateurs Windows 95/98/me peuvent utiliser Légion v2.11, la dernière
version du scanner de fichiers Légion par Rhino9, pour rechercher des partages
réseau Windows.
Les administrateurs Windows 2000 peuvent utiliser le Contrôleur de Mot de passe
de Partage de Security Fridays (SPC) pour scanner leurs clients Windows 95/98/me
pour voir s'ils sont vulnérables à la vulnérabilité de Mot de passe de Partage qui
révélera les mots de passe des partages à un attaquant.
Pour Windows NT (SP4), Windows 2000, Windows XP et Windows 2003, le
Microsoft Baseline Security Advisor recensera les hôtes qui sont vulnérables aux
exploits SMB et peut être utilisé pour résoudre le problème. Les tests peuvent être
effectués localement ou sur des hôtes distants.
Les utilisateurs Windows NT, Windows 2000, Windows XP et Windows 2003
peuvent taper simplement « net share » à partir de la ligne de commande pour
voir les ressources partagées. Pour plus d'information sur la commande « net
share », tapez « net share / ? ».

Note IMPORTANTE : Cet article contient des informations sur la
modification de ressources partagées. Avant que vous ne modifiiez
une ressource partagée, assurez-vous de comprendre comment
restaurer la ressource si un problème survient. Il est recommandé
que vous testiez très sérieusement l’impact de toute(s)
modification(s) avant sa mise en oeuvre dans un environnement de
production. Pour une information sur les ressources partagées,
cliquez sur les numéros d'articles suivants pour voir l'article dans la
Base de Connaissance de Microsoft

:

125996 - Sauvegarde et Restauration des partages Windows existants
,
Partages
Spéciaux
308419 - Comment Configurer, Changer ou Supprimer les Permissions Spéciales
pour les fichiers ou dossiers dans Windows XP

307874 - Comment Désactiver le partage simplifié et protéger un dossier partagé
par mot de passe dans Windows XP

174273 - Comment copier des fichiers et maintenir les permissions de partages
NTFS


Les permissions par défaut sur les nouveaux partages:
Windows NT, Windows 2000, et Windows XP (Pre Service Pack 1)
• Tout le Monde – Contrôle Total
Windows XP SP1

• Tout le Monde - Lecture
Windows XP par défaut a un répertoire partagé appelé « SharedDocs ». La
localisation de ce partage est:
"C:\Documents and Settings\All Users\Documents"

• Tout le Monde – Contrôle Total
La plupart des scanners de réseau commerciaux disponibles détecteront les
partages ouverts. Un test rapide, gratuit et sûr sur la présence de partage de
fichiers SMB et ses vulnérabilités intrinsèques, efficaces pour toute machines
fonctionnant avec n'importe quel système d'exploitation Windows, est disponible
sur le site Internet de
Gibson Research Corporation
. Suivez les liens vers
« ShieldsUP » pour recevoir une évaluation en temps réel de l'exposition SMB de
n'importe quel système. Des instructions détaillées sont disponibles pour aider les
utilisateurs de Microsoft Windows à remédier aux vulnérabilités SMB. A noter que
si vous êtes connectés sur un réseau où certains dispositifs intermédiaires bloquent
SMB, l'outil ShieldsUP annoncera que vous n'êtes pas vulnérables quand, en fait,
vous l’êtes. C'est le cas, par exemple, pour les utilisateurs de modem câble où le
fournisseur bloque SMB dans le réseau du modem câble. ShieldsUP annoncera que
vous n'êtes pas vulnérables. Cependant, les 4000 – ou à peu près - autres
personnes sur votre liaison modem câble peuvent toujours exploiter cette
vulnérabilité.
Outils de scans automatisés pour détecter les vulnérabilités de partages:

Nessus
-- Un scanner de sécurité gratuit, puissant, à jour et facile à utiliser

Winfingerprint
par vacuum -- Scanner Win32 d'énumération d’hôte/réseau

Comment déterminer si vous êtes vulnérables aux Connexions
Anonymes ?
Essayer d’établir une session nulle vers votre ordinateur en lançant la commande
suivante de la ligne de commande (Démarrer --> Exécuter --> tapez cmd):
C:\>net use
\\adresse
IP\ipc$ "" /user:""
La syntaxe précédente connecte aux communications cachées d'inter-processus :
partager (IPC$) à l’adresse IP en tant qu’utilisateur anonyme incorporé (/user:"")
avec mot de passe nul ().
Si vous recevez une erreur système « 5 » (accès rejeté), alors votre système n'est
pas vulnérable.
Si vous recevez le message de retour « la commande s’est achevée avec succès »,
cela signifie alors que votre système est vulnérable.
La liste des outils ci-dessus Nessus et Winfingerprint peut aussi être utilisée pour
détecter les vulnérabilités de sessions nulles.
Comment déterminer si vous êtes vulnérables aux accès distants à la
Base de Registres ?
Le Kit de Ressources Techniques NT (NTRK) disponible chez Microsoft contient un
fichier exécutable intitulé "regdump.exe" qui évaluera passivement les permissions
d'accès à la Base de Registres à partir d'un hôte Windows NT contre d'autre
machines Windows NT / Windows 2000 ou Windows XP sur l'Internet ou le réseau
interne.
En outre, une collection de scripts shell en ligne de commande qui testera les
permissions d'accès à la Base de Registres et une gamme d'autres items sécurité
est disponible pour le téléchargement à
http://www.afentis.com/top20
.
Comment déterminer si vous êtes vulnérables aux appels de procédures à
distance ?
Microsoft a fait un outil de vérification des mises à jour et des hotfix librement disponible
en téléchargement; c'est probablement la meilleure façon de déterminer si des hôtes
Windows sont sensibles à une quelconque de ces vulnérabilités. Il est appelé « Microsoft
Baseline Security Analyzer » (MBSA) et est disponible sur
http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp
. Il recherchera
les erreurs de configuration et les mises à jour de sécurité manquantes; vous devriez
vérifier que les hotfixes appropriés ont été appliqué. Il y a aussi un outil de recherche
autonome qui vérifiera les patchs de sécurité manquants seulement pour CAN-2003-0352,

CAN-2003-0528, CAN-2003-0605 et CAN-2003-0715; Disponible sur
http://support.microsoft.com/?Kbid=827363
. Vous êtes cependant encouragés à utiliser
MBSA, qui couvre un périmètre plus large. Les utilisateurs à domicile ou à petite échelle
en charge de quelques ordinateurs seulement trouveront probablement plus facile de
visiter le site de Mise à jour de Windows à
http://windowsupdate.microsoft.com/
et
vérifieront l’horodatage logiciel des machines individuelles.
W5.5 Comment s’en protéger

Comment se protéger contre les attaques NETBIOS précitées ?
Diverses précautions peuvent être prises afin d’atténuer le risque de l'exploitation
d'une vulnérabilité par les Partages Réseau Windows :
• Désactivez le partage partout où cela n’est pas requis. Si l'hôte n’a pas
besoin de partager de fichiers, désactivez alors les partages réseau
Windows dans le panneau de configuration Réseau de Windows. Si un
partage ouvert doit être fermé, vous pouvez le désactiver par le menu des
propriétés de l'Explorateur pour ce répertoire, dans le Manager de Serveur
pour les Domaines ou dans l’Editeur de Politique de Groupe.
• Il est recommandé que les clients Windows 95/98/me fonctionnant dans un
domaine Windows NT soient configurés avec un contrôle d’accès au niveau
utilisateur pour les partages.
• N’autorisez pas le partage avec des hôtes sur Internet. Assurez-vous que la
fonction de partage réseau est désactivée pour tous les hôtes en frontal
d’Internet dans le panneau de configuration Réseau de Windows. Le
partage de fichiers avec des hôtes Internet devrait être réalisé en utilisant
FTP ou HTTP.
• N’autorisez pas les partages non authentifiés. Si le partage de fichier est
requis, alors ne permettez pas d'accès non authentifié à un partage.
Configurez le partage afin qu’un mot de passe soit requis pour la
connexion.
• Limitez les permissions sur les dossiers partagés au minimum requis. Soyez
particulièrement vigilant à ne permettre l'accès en écriture qu’en cas
d’absolue nécessité.
• Pour une sécurité supplémentaire, n’autorisez uniquement le partage
qu’avec des adresses IP spécifiques parce que les noms DNS peuvent être
imités.
Comment se protéger contre les problèmes de Connexion Anonyme sur
vos systèmes ?
Note IMPORTANTE: Cet article contient des informations sur la modification de la
Registry (Base de Registres). Avant que vous ne modifiiez le Registre, assurez-
vous de sa sauvegarde préalable et assurez-vous d’avoir compris comment le
restaurer si un problème survient. Il est recommandé que vous testiez très
sérieusement l’impact de toute(s) modification(s) avant sa mise en oeuvre dans un
environnement de production. Pour plus ample information sur la sauvegarde, la
restauration et l’édition de la Base de Registres, cliquez sur les numéros d'articles
suivants pour voir l'article dans la Base de Connaissance de Microsoft:
256986 - Description de la Base de Registres Microsoft Windows

323170 - Comment Sauvegarder, Editer, Restaurer la Base de Registres dans
Windows NT 4.0

322755 - Comment Sauvegarder, Editer, Restaurer la Base de Registres dans
Windows 2000

322756 - Comment Sauvegarder, Editer, Restaurer la Base de Registres dans
Windows XP Windows Server 2003

Les contrôleurs de Domaine Windows NT requièrent les sessions nulles pour
communiquer. Par conséquent, si vous travaillez dans un domaine Windows NT ou
Windows 2000/2003 Active Directory fonctionnant en mode mixte, qui autorise
l'accès compatible pré Windows 2000, vous pouvez réduire au minimum
l'information que les attaquants peuvent obtenir, mais vous ne pouvez pas arrêter
toute fuite d’information en mettant la valeur du registre « RestrictAnonymous » à
1. Par exemple; GetAcct de Security Friday évite RestrictAnonymous=1 et
énumérera le SID et UserID. La solution idéale si vous disposez d’Active Directory
Windows 2000/2003 en mode natif est de mettre la valeur d'enregistrement
RestrictAnonymous à 2.
Pour limiter l'information disponible via les sessions nulles, cliquez sur les numéros
d'articles suivants pour voir les articles dans la Base de Connaissance de
Microsoft :
143474 - Restreindre l'information disponible aux utilisateurs de Connexion
Anonyme dans Windows NT

246261 - Comment utiliser la valeur de Registre RestrictAnonymous dans Windows
2000


Pour remédier à un problème avec la valeur d'enregistrement RestrictAnonymous,
cliquez sur le numéro d'article suivant pour voir l'article dans la Base de
Connaissance de Microsoft :
296405 - La valeur du registre RestrictAnonymous peut interrompre une Relation
d'Approbation avec un Domaine Windows 2000

Comment se protéger contre l'accès distant à la Base de Registres sur vos
systèmes ?
Pour éviter cette menace, l'accès à la Base de Registres du système doit être limité
et les permissions relatives aux clés de registres critiques passées en revue. Les
utilisateurs de Microsoft Windows NT 4.0 devraient aussi assurer que le Service
Pack 3 (SP3) a été installé avant le réglage de la Base de Registres.

Note Importante: Cet article contient des informations sur la
modification de la Base de Registres. Avant que vous ne modifiiez
celle-ci, assurez-vous de sa sauvegarde préalable et assurez-vous
d’avoir compris comment la restaurer si un problème survient. Il est
recommandé que vous testiez très sérieusement l’impact de toute(s)
modification(s) avant sa mise en oeuvre dans un environnement de
production. Pour plus ample information sur la sauvegarde, la
restauration et l’édition de la Base de Registres, cliquez sur les
numéros d'articles suivants pour voir l'article dans la Base de
Connaissance de Microsoft:

256986 - Description de la Base de Registres Microsoft Windows

323170 - Comment Sauvegarder, Editer, Restaurer la Base de Registres dans
Windows NT 4.0

322755 - Comment Sauve
g
arder
,
Editer
,
Restaurer la Base de Re
g
istres dans
Windows 2000

322756 - Comment Sauvegarder, Editer, Restaurer la Base de Registres dans
Windows XP Windows Server 2003

Limitez l’accès réseau. Pour limiter l'accès réseau à la Base de Registres, suivez
les étapes listées ci-dessous pour créer la clé de registre suivante:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\

Control\
SecurePipeServers\winreg
• Description: REG_SZ
• Valeur: Registry Server
Les permissions de sécurité sur cette clé définissent les Utilisateurs ou les Groupes
autorisés à accéder à distance au Registre. Les installations Windows par défaut
définissent cette clé et configurent la Liste de Contrôle d’Accès afin de fournir les
privilèges complets à l'Administrateur système et au Groupe d'Administrateurs (et
aux Opérateurs de Sauvegarde dans Windows 2000).
Les modifications de la Base de Registres nécessiteront un redémarrage afin d’être
prises en compte. Pour créer la clé de registre afin de limiter l'accès à la Base de
Registres:
1. Démarrer l’Editeur de Registre (“regedt32.exe" ou "regedit.exe") et aller à la sous-
clé suivante: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
2. Dans le menu “Edition”, cliquer sur "Ajouter une clé".
3. Entrez les valeurs suivantes:
o Nom de la clé: SecurePipeServers
o Classe: REG_SZ
4. Aller à la sous-clé suivante:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers
5. Dans le menu “Edition”, cliquez sur "Ajouter une clé".
6. Entrez les valeurs suivantes:
o Nom de la clé: winreg
o Classe: REG_SZ
7. Aller à la sous-clé suivante:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\winreg
8. Dans le menu “Edition”, cliquez sur "Ajouter une clé".
9. Entrez les valeurs suivantes:
o Nom de la Valeur: Description
o Type de Donnée: REG_SZ
o Chaîne: Registry Server
10. Aller à la sous-clé suivante:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\winreg
11. Selectionner "winreg." Cliquer sur "Sécurité" et cliquer alors sur "Permissions."
Ajouter les Utilisateurs ou les Groupes auxquels vous voulez autoriser l’accès.
12. Quitter l’Editeur de Registre et redémarrer Microsoft Windows.
13. Si ultérieurement vous voulez changer la liste des utilisateurs qui peuvent avoir accès à la
Base de Registres, répéter les étapes 10 à 12.

Limitez les Accès Distants Autorisés. La mise en application de restrictions
strictes sur la Base de Registres peut avoir des effets secondaires néfastes sur des
services dépendants, comme le Duplicateur de Directory et le service d’impression
réseau.
Il est par conséquent possible d'ajouter un degré de granularité aux permissions
en ajoutant soit le nom du compte sous lequel le service fonctionne à la liste
d'accès de la clé « winreg », soit en configurant Windows pour contourner la
restriction d'accès à certaines clés en les inscrivant dans la valeur Machine ou
Utilisateurs sous la clé AllowedPaths:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
SecurePipeServers\winreg\AllowedPaths
Valeur: Machine
Valeur Type: REG_MULTI_SZ - Multi string
Donnée par défaut: System\CurrentControlSet\Control\ProductOptionsSystem\
CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\

Services\EventlogSoftware\Microsoft\WindowsNT\CurrentVersionSystem\
CurrentControlSet\Services\Replicator
Etendue valide: (Un chemin valide vers un emplacement dans la Base de
Registres)
Description: Autorise l'accès machines aux emplacements inscrits dans la Base de
Registres à condition qu'aucune restriction d'accès explicite n'existe pour cet
emplacement.
Valeur: Utilisateurs
Valeur Type: REG_MULTI_SZ - Multi string
Donnée par défaut: (none)
Etendue valide: (Un chemin valide vers un emplacement dans la Base de
Registres)
Description: Autorise l’accès utilisateurs aux emplacements inscrits dans la Base
de Registres à condition qu'aucune restriction d'accès explicite n'existe pour cet
emplacement.
Dans la Base de Registres Microsoft Windows 2000 et Windows XP:
Valeur: Machine
Valeur Type: REG_MULTI_SZ - Multi string
Donnée par défaut: System\CurrentControlSet\Control\ProductOptionsSystem\
CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\
control\Server ApplicationSystem\CurrentControlSet\Services\Eventlog\
Software\Microsoft\Windows NT\CurrentVersion
Valeur: Utilisateurs (n’existe pas par défaut)
Il est communément acquis qu’il y a un laps de temps de retard entre le moment
où une vulnérabilité devient publique et le moment où un patch est mis à
disposition. Ou pour d'autres raisons politiques, la vulnérabilité doit être permise.
Pour en atténuer le risque une entreprise peut limiter l'accès par des coupe-feux
(p
are-feus
)
ou des routeurs. Une mesure com
p
lémentaire devrait être d’écrire de
nouvelles règles pour un IDS (Système de Détection d'Intrusion) comme
Snort
qui
alerterait ou déclencherait une réponse de l’entreprise. Des exemples de règles
documentées pour Snort figurent ici.
Comment protéger vos systèmes des procédures d’appels à distance
précitées ?
La meilleure façon et de loin est d'appliquer les patchs appropriés identifiés par
MBSA ou Windows Update: voir « Comment déterminer si vous êtes vulnérables à
la fonction d'Appel de Procédure à Distance précitée » ci-dessus. A défaut il y a un
certain nombre de façons de désactiver ou limiter quelques fonctionnalités d'Appel
de Procédure à Distance, certaines pouvant être trouvées dans l’excellent résumé
sur
http://www.ntbugtraq.com/dcomrpc.asp
. AVERTISSEMENT : la désactivation
ou la limitation de la fonctionnalité d'Appel de Procédure à Distance peuvent
interférer avec des services Windows sur lesquels vous comptez, vous devriez donc
en premier lieu toujours tester les modifications dans un environnement de non-
production.
Si vous ne pouvez pas mettre à jour vos systèmes, vous devriez certainement
bloquer les ports associés aux appels de procédure à distance de Windows (ports
TCP 135, 139, 445 et 593; ports UDP 135, 137, 138 et 445) sur vos périmètres
réseau. Bien entendu, le meilleur moyen est de bloquer par défaut tous les
services inutiles sur votre périmètre réseau.
Pour plus d’information:
Article de la Base de Connaissances Microsoft Q153183. Comment Limiter l'Accès à
la Base de Registres NT d'un Ordinateur Distant.
Une autre source est
Le Service Bulletin de Sécurité & Hotfix de Microsoft
.
Bienvenu sur la bibliothèque MSDN
(Cherchez Sécurisation de la Base de
Registres)
Article de la Base de Connaissances Microsoft 310426 : COMMENT: Utiliser
l'Editeur de Registre Windows XP et Windows Server 2003
Accès Réseau: Paths et sous-paths de la Base de Registres accessibles à distance
Guide de Sécurité Windows Server 2003
retour au début ^
W6 Composants Microsoft Data Access (MDAC)
W6.1 Description
Les Composants d'Accès aux Données Microsoft correspondent à une série de technologies de
base de données qui sont présentes dans beaucoup de versions récentes de Windows. Il y a un
certain nombre de cas différents où un attaquant peut exploiter des vulnérabilités dans MDAC
pour faire exécuter du code et des commandes malveillantes. Il y a les deux publications
d’anciennes failles RDS décrites ci-dessous aussi bien que des problèmes plus récents où un
attaquant se faisant passer pour un serveur SQL peut causer un débordement de buffer ainsi
qu’une potentielle compromission complète du système avec un paquet UDP soigneusement