 |
|
S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information
Le directeur |
 |
|
Paris, le 14 août
2009
No CERTA-2009-ACT-033 |
Affaire suivie par :
CERTA
N O T E
Objet : Bulletin d'actualité
2009-33
Le bulletin d'actualité est disponible dans son
intégralité et au format PDF à l'adresse
suivante :
http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-033.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-2009-ACT-033/
Une vulnérabilité a été
récemment rendue publique. Elle concerne un
déréférencement de pointeur NULL à
la création de sockets pour
quelques protocoles (PF_BLUETOOTH, PF_ISDN, PF_APPLETALK,
PF_IRDA, PF_INET6 avec IPPROTO_SCTP, PF_PPOX, PF_IUCV, ...).
Les opérations non disponibles ne sont pas correctement
gérées, en particulier par la fonction
sock_sendpage.
La plupart des noyaux Linux actuels sont concernés
par cette vulnérabilité (branche 2.4 y compris
2.4.37.4 et branche 2.6 y compris 2.6.30.4).
Le CERTA a publié à ce sujet l'avis
CERTA-2009-AVI-337. Des correctifs pour chaque distribution
devraient apparaître dans les prochains jours.
Cette semaine, Microsoft a publié ses
bulletins mensuels de sécurité. Le CERTA revient
sur ces différents bulletins :
- MS09-036 : ce bulletin fait
état d'une vulnérabilité dans
l'environnement d'exécution Microsoft .NET
Framework dans leurs versions 2.0 avec sans le service
pack 1 ou 2 et 3.5 avec sans le service pack 1. Une gestion
incorrecte des files de requêtes, lorsque Internet Information Services (IIS) 7.0 est installé, permet
d'effectuer un déni de service lorsque ASP.NET est configuré pour utiliser le
mode « intégré » et non le mode
« classique » ;
- MS09-037 : plusieurs
vulnérabilités dans la bibliothèque
ATL (Active
Template Library), de Microsoft Windows
permettent d'exécuter du code arbitraire à
distance ;
- MS09-038 : deux
vulnérabilités dans le traitement de fichiers
Windows Media permettent à une personne
malintentionnée via un fichier AVI spécialement conçu
d'exécuter du code arbitraire à distance ;
- MS09-039 : deux erreurs dans
Microsoft Windows Internet Name Service permettent
à une personne malintentionnée
d'exécuter du code arbitraire à distance via un
paquet de réplication spécialement conçu
envoyé au service WINS vulnérable ;
- MS09-040 : un problème
a été identifié dans le service, non
activé par défaut, de mise en file d'attente
MSMQ de Microsoft
Windows. Le service vérifie de façon
incorrecte les données en entrée avant de les
transmettre au tampon et permet à un utilisateur
d'élever ses privilèges ;
- MS09-041 : une
vulnérabilité a été
identifiée dans le Service
Station de Travail de Microsoft Windows.
Celui-ci alloue et libère la mémoire de
manière incorrecte lors de la réception de
messages RPC spécialement conçus.
L'exploitation de cette vulnérabilité permet
d'exécuter du code arbitraire avec des
privilèges élevés ;
- MS09-042 : le service Telnet ne souscrit pas correctement aux
protections contre la réflexion des informations
d'identification NTLM. Une
exécution de code arbitraire est possible via cette
vulnérabilité ;
- MS09-043 : un ensemble de
contrôles COM (Component Object Model) utilisés pour
la publication de feuilles de calcul, de graphiques et de
bases de données sur le Web ainsi que pour l'affichage
de composants publiés sur le Web sont
vulnérables et permettent une exécution de code
arbitraire à distance. Ce correctif clôt
l'alerte CERTA-2009-ALE-011 ;
- MS09-044 : deux
vulnérabilités ont été
identifiées dans la Connexion
Bureau à distance de Microsoft
Windows. La première est due aux
paramètres renvoyés par le serveur RDP qui ne sont pas correctement
traités. La seconde concerne le contrôle ActiveX du client. Dans les deux cas,
seuls les clients RDP sont donc
affectés et une exécution de code arbitraire
à distance est possible.
Le CERTA rappelle l'impérative
nécessité d'appliquer au plus vite ces correctifs
afin de protéger son système d'information.
Le CERTA a publié dans le courant du mois de juillet
l'alerte CERTA-2009-ALE-013 concernant Adobe Shockwave Flash.
D'autres vulnérabilités avaient fait l'objet en
mars 2009 de l'avis CERTA-2009-AVI-076.
Le CERTA a traité cette semaine un incident relatif
à une compromission associée à
l'exploitation de l'une de ces vulnérabilités.
Des codes circulent actuellement, insérés dans
des pages Web de sites Internet ou dans des documents au format
PDF.
Le CERTA revient donc dans les sections suivantes sur
quelques pratiques associées avec cette application.
Adobe Flash Player se présente sous la forme d'un
module (ou plugin) pour navigateur
Internet. Il permet d'interpréter des contenus de type
vidéo ou animation aux formats SWF (Shockwave
Flash) ou FLV (Flash
Video).
L'installation n'est cependant pas unique sur chaque
machine. Elle peut être effectuée sous une forme
ActiveX par exemple pour Internet Explorer et comme module
additionnel dans un autre navigateur (Mozilla Firefox, Safari,
etc.). Une machine peut donc avoir plusieurs installations
distinctes d'Adobe Flash, avec des configurations et des
niveaux de mises à jour propres.
Pour connaître les versions actuellement
utilisées, il existe deux méthodes :
Pour conclure cette section, le CERTA tient également
à rappeler que les lecteurs Adobe Flash installés
sur une machine ne sont pas configurables de manière
simple. La seule méthode proposée par Adobe se
fait en mode connecté, en se rendant avec un navigateur
sur une page donnée du site Internet d'Adobe. C'est
à partir de celle-ci qu'une interface de configuration
est possible.
La page d'accueil se trouve à l'adresse :
http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager.html
Le CERTA avait longuement abordé la
problématique des fichiers de session propres à
Adobe, aussi appelés Local Shared
Objects ou LSO dans le bulletin
d'actualité CERTA-2008-ACT-034. Les paramètres de
configuration se trouvent dans un fichier au même format,
settings.sol et peuvent être modifiés
localement avec un éditeur adapté.
Enfin, toutes les mesures citées ci-dessous
s'appliquent au lecteur Adobe Flash mais restent valables pour
le lecteur Adobe Shockwave.
Il faut utiliser l'une des pages de l'interface de
configuration en ligne Adobe :
http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager05.html
Il est possible de préciser dans cette
interface :
- un avertissement doit être émis si une
nouvelle mise à jour est disponible ;
- la fréquence de vérification des mises
à jour. La valeur par défaut, de 14 ou 30
jours, est excessive. La valeur la plus petite
proposée est de 7 jours. L'interface permet de
l'augmenter au maximum à 7 jours. Cela reste trop
important dans les faits, étant donné que des
codes d'exploitation apparaissent très rapidement
après des mises à jour, voire avant dans les
cas les plus récents.
Le CERTA recommande vivement de ne pas se reposer sur le
fonctionnement de mise à jour automatique du lecteur
Adobe Flash Player. En cas de vulnérabilité
critique, une mise à jour manuelle s'impose.
Il faut pour cela télécharger
préalablement la nouvelle version du lecteur Adobe Flash
sur le site officiel. L'installation peut se faire sur un poste
déconnecté. La nouvelle version se charge de
désinstaller l'ancienne. Il est néanmoins
conseillé de vérifier après cette
opération par les procédures
précédentes que le changement est effectif.
Les accès hors-ligne présentés dans la
section précédente pour déterminer la
version du module Adobe Flash installé permettent, au
mieux, selon les navigateurs, de désactiver le module.
Il n'est pas possible, via la configuration du navigateur, de
désinstaller complètement l'application.
Pour le système d'exploitation Microsoft Windows, il
est possible :
- de désinstaller l'application via l'option «
Ajout/Suppression de programmes » du système
d'exploitation ;
-
de lancer manuellement les programmes de
désinstallation fournis par Adobe qui se trouvent
sous une des formes suivantes :
-
%WINDIR%\
Les mesures citées dans cette section ne sont
pas absolues mais permettent de limiter certains
risques liés aux contenus de format Flash sur
les postes. Il ne s'agit donc ici que de quelques
pistes envisageables.
Une mesure consiste à utiliser des
navigateurs avec des configurations distinctes : l'une
d'elles restrictive, n'interprète par
défaut aucun code particulier dynamique suite
à la visite d'une page. La seconde, plus
laxiste, permet d'activer cette interprétation,
de manière ponctuelle, pour des sites de
confiance. Cette procédure peut être aussi
appliquée en créant pour un même
utilisateur plusieurs profils (Mozilla Firefox).
Une autre mesure consiste à utiliser des
lecteurs Flash alternatifs en fonction du
système d'exploitation et des
navigateurs :
- Projet Gnash (http://www.gnashdev.org)
- Swfdec (http://swdec.freedesktop.org/)
- Gameswf Library
(http://tulrich.com/textweb.pl?path=geekstuff/gameswf.txt)
- Flirt (non mis à jour depuis 2006 -
http://flirt.sourceforge.net/)
Ils n'interprètent cependant pas toutes les
particularités du format Flash, mal
documenté à l'heure actuelle.
Des modules pour certains navigateurs (ex : Firefox
- flashblock, noscript, prefbar, etc.), permettent
enfin de bloquer par défaut des contenus Flash
sauf autorisation explicite de l'utilisateur. Cette
approche repose sur ce nouveau module qui devient de
fait une nouvelle surface d'attaque. Il faut donc avoir
confiance dans ce dernier (mises à jour
fréquentes, code audité, etc.) avant de
le déployer.
Enfin, les développeurs de sites Web
comprendront ici qu'il n'est pas conseillé de
développer un site Web intégralement en
Flash sous peine de pénaliser nombre de
visiteurs qui ne souhaitent pas installer ou activer un
tel module. Un site Web doit être par
défaut lisible et accessible par tout
navigateur, sans forcer l'utilisateur à
installer contre son gré des modules tiers.
L'objectif de cet article est d'aborder la
problématique des serveurs mandataires pour les
connexions en HTTPS. En effet, s'agissant d'un
protocole cryptographique de bout en bout, la
présence d'intermédiaires non de
confiance ne devrait pas poser de problème.
Voyons ici comment ces Pretty-Bad-Proxy (PBP) peuvent être utilisés
pour mener des attaques.
Il s'agit d'un serveur mandataire web (proxy) utilisé pour mener des
attaques de type « man in
the middle ». Il a accès au trafic
brut, mais ne pouvant décrypter le flux
HTTPS, il utilise le canal clair
associé (HTTP) pour injecter du contenu
malveillant et tenter d'accéder à des
données sensibles.
Il s'agit d'une sécurité consistant
à cloisonner les contenus (pages, scripts, ...)
afin d'éviter les interactions. Par exemple, la
page d'un site A n'a pas à accéder aux
identifiants saisis sur la page d'un site B. L'origine est
déterminée par trois critères, le
protocole, le nom du serveur et le port. Ainsi, http://unserveur.tld n'a pas la
même origine que
https://unserveur.tld. Il
est intéressant de remarquer que les scripts
n'ont pas d'origine propre,
mais celle du cadre ou de la page qui les contient.
HTTPS est un protocole bout-en-bout, ce qui
est contraire au principe du serveur mandataire qui
s'intercale dans le flux. Pour réussir à
établir une connexion sécurisée au
travers d'un proxy il faut utiliser le mécanisme
de tunnel. Pour cela, le
client envoie une première requête
HTTP au proxy annonçant le serveur
final, et le port, avec lequel il désire
établir la session. Le proxy va alors ouvrir et
maintenir deux connexions, l'une vers le client,
l'autre vers le serveur et servira de relais passif
pour le trafic HTTPS.
Lorsque l'utilisateur demande la page (https://unepage.tld), le navigateur
émet de façon transparente une
requête HTTP à destination du
proxy. Si ce dernier ne trouve pas la page en question,
il retourne une erreur HTTP (ex: 404) qui est interprétée
dans le contexte de https://unepage.tld. Un proxy
malveillant peut donc volontairement répondre
une page d'erreur contenant un script malveillant qui
aura accès aux données du site
sécurisé initialement demandé.
Les pages importent souvent des scripts depuis
plusieurs sources. Chacun des scripts externes
nécessite une requête à destination
du proxy suivant le même schéma, à
savoir, une première requête en
HTTP afin de définir le tunnel
désiré, puis l'établissement de la
connexion sécurisée. À la
première requête, le proxy peut
répondre que le site a été
déplacé (message 3xx), et faire
établir le tunnel avec un autre serveur. Comme
les scripts n'ont pas d'origine propre, ils seront
exécutés dans le contexte du cadre qui a
fait l'import et qui est bien celui du site
sécurisé.
Alors que le HTTPS est utilisé pour des
transactions sécurisées et le
HTTP pour tout le reste, il arrive souvent que
les pages non sensibles soient aussi accessibles via
HTTPS, elles portent le nom de "HPIHSL" (HTTP-intended-but-HTTPS-loadable).
Donc, lorsqu'une page en clair est demandée (ex:
http://unsite.tld), le
PBP peut insérer une
IFRAME qui a comme source
une page non sensible du même site (iframe
src=https://unsite.tld/pagenonsensible.html).
Mais demandée via HTTPS et
elle-même important un script en HTTP,
ce dernier est demandé en clair. Le proxy peut
alors le remplacer par un autre, et n'ayant pas d'origine propre, il aura celle de
l'IFRAME. Comme le cadre
principal a comme origine
HTTP, le fait d'accéder à du
HTTP dans une IFRAME, elle-même en
HTTPS, n'engendre pas d'alerte.
Afin d'optimiser les performances, les navigateurs
mettent en cache les certificats. Un PBP peut utiliser ce fonctionnement
pour servir ses propres pages et apparaître comme
sûr (affichage du cadenas). Lorsqu'une page
sécurisée est demandée (via
HTTP dans un premier temps), le PBP répond par une page d'erreur
(4xx ou 5xx) qui contient un élément
pointant vers le site sécurisé (par
exemple une image) et un méta
élément qui forcera le rechargement de la
page quelques instants plus tard.
L'élément pointant vers le site
sécurisé va provoquer
l'établissement de la connexion
sécurisée, et donc la mise en cache du
certificat. Lorsque la page se recharge, le PBP répond par une page
imitant le site sécurisé demandé
(toujours au moyen d'une erreur). Le contexte
étant celui du site visé et le certificat
étant en cache, la page apparait comme
certifiée. Cela ne fonctionne cependant pas avec
tous les navigateurs mais cette technique a l'avantage
de ne pas utiliser de script.
Les cookies sont des
chaînes de caractères utilisés,
entre autres, pour maintenir des sessions ouvertes. Le
problème est que l'origine des cookies ne tient pas compte du
protocole. Une page de http://unsite.tld pourra accéder
aux cookies de https://unsite.tld. Pour empêcher
cela le serveur doit utiliser l'attribut
SECURE du cookie.
Dans les faits, une grande proportion de sites dit
« sécurisés » ne le font pas.
Lorsqu'un utilisateur est connecté à un
site « sécurisé » de la
sorte, le PBP n'a
qu'à attendre que la victime demande n'importe
quelle page en HTTP de n'importe quel serveur
pour y injecter une IFRAME
malveillante. Cette dernière ayant comme source
l'adresse du site sécurisé en
HTTP, les cookies
d'authentification circuleront en clair et seront
interceptables par le PBP.
Le CERTA recommande de désactiver
l'utilisation automatique des serveurs mandataires non
maîtrisés. En particulier, il convient de
rester prudent lors de la navigation depuis un lieu
public (réseau d'hôtel, accès WiFi
public, cybercafé, ...).
5 Rappel des avis
émis
Dans la période du 07 au 13 août 2009,
le CERTA a émis les avis suivants :
- CERTA-2009-AVI-314 : Vulnérabilité
dans IBM AIX
- CERTA-2009-AVI-315 : Multiples
vulnérabilités dans WordPress
- CERTA-2009-AVI-316 : Vulnérabilité
dans Fetchmail
- CERTA-2009-AVI-317 : Vulnérabilité
dans CA Data Transport Services
- CERTA-2009-AVI-318 : Vulnérabilité
dans CA Unicenter
- CERTA-2009-AVI-319 : Vulnérabilités
dans Zope
- CERTA-2009-AVI-320 : Multiples
vulnérabilités dans Subversion
- CERTA-2009-AVI-321 : Vulnérabilité
dans libvorbis
- CERTA-2009-AVI-322 : Multiples
vulnérabilités dans Asterisk
- CERTA-2009-AVI-323 : Vulnérabilités
dans Apache APR-Utility
- CERTA-2009-AVI-324 : Vulnérabilité
dans ASPNET de Microsoft Windows
- CERTA-2009-AVI-324 : Vulnérabilités
de la bibliothéque ATL de Microsoft
Windows
- CERTA-2009-AVI-326 : Vulnérabilités
dans le traitement de fichiers Windows Media
- CERTA-2009-AVI-327 : Vulnérabilités
dans Microsoft WINS
- CERTA-2009-AVI-328 : Vulnérabilité
dans le service MSMQ Microsoft Windows
- CERTA-2009-AVI-329 : Vulnérabilité
dans le Service Station de Travail Microsoft
Windows
- CERTA-2009-AVI-330 : Vulnérabilité
dans Microsoft Telnet
- CERTA-2009-AVI-331 : Multiples
vulnérabilités dans Microsoft Office
Web Components
- CERTA-2009-AVI-332 : Multiples
vulnérabilités dans la Connexion Bureau
é distance Microsoft
- CERTA-2009-AVI-333 : Vulnérabilités
de Safari
- CERTA-2009-AVI-334 : Vulnérabilité
dans WordPress
- CERTA-2009-AVI-335 : Multiples
vulnérabilités dans libxml2
Pour cette même période, le CERTA a mis
à jour les avis suivants :
- CERTA-2009-AVI-302-002 :
Vulnérabilité dans ISC BIND (ajout du
bulletin de sécurité IBM AIX)
- 14 août 2009
- version initiale.
CERTA
2010-01-20
|
|
