CERTA
Centre d'Expertise gouvernemental de
Réponse et de Traitement des Attaques informatiques
|
CERTA Centre d'Expertise gouvernemental de |
|
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
2010-19
Gestion du documentLe bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-019.pdf Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante : http://www.certa.ssi.gouv.fr/site/CERTA-2010-ACT-019/ 1 Vulnérabilité dans SafariCette semaine, une vulnérabilité relative au navigateur Safari de Apple a été publiée sur l'Internet. Cette faille non-corrigée a fait l'objet de l'alerte CERTA-2010-ALE-006. Elle est relative à un problème dans la gestion des fermetures de fenêtres intempestives (pop-ups) et permet à un utilisateur distant malintentionné de provoquer un déni de service ou d'exécuter du code arbitraire via un site web construit de façon particulière.Documentation
2 Actualité MicrosoftLes bulletins correctifs mensuels de Microsoft ont été publiés cette semaine. Les vulnérabilités découvertes sont les suivantes :
Le CERTA rappelle qu'il est recommandé d'appliquer ces correctifs dès que possible. Documentation
3 Month of PHP bugs, bilan à mi-parcoursLe mois de mai 2010 voit se dérouler un Month of PHP bugs, comme en mars 2007. Le principe consiste à publier chaque jour une vulnérabilité de PHP ou d'une application écrite avec ce langage. Des articles sur la sécurité de PHP sont également insérés.À ce jour, 26 vulnérabilités ont été publiées, dont la plupart ont été découvertes antérieurement. Globalement :
Six applications présentent des possibilités d'injections SQL. Deux seulement ont émis des correctifs en réponse aux informations publiées. Deux applications offrent des possibilités d'injection de fichiers. Les vulnérabilités liées à l'interface avec Zend appartiennent à une classe de vulnérabilités présentée à BlackHat USA en 2009. Le site du mois des bogues PHP donnant des preuves de faisabilité, il est à redouter que des individus malintentionnés utilisent ces informations à des fins malveillantes. Les administrateurs sont donc invités à :
4 Gestion des comptes de services sous Windows et les secrets LSAAujourd'hui nous allons nous intéresser à la gestion des mots de passe des comptes de services sous Windows. De nombreuses applications métiers sont implémentées sous forme d'un service, et souvent ces services sont paramétrés pour utiliser un compte spécifique (compte local ou du domaine). Le gestionnaire de services (CM) utilise les secrets LSA pour stocker les mots de passe des comptes de services. Nous parlons bien de mots de passe et non de condensés... Les secrets LSA sont stockés dans la clé : HKLM/Security/Policy/SecretCette clé n'est accessible qu'à l'utilisateur "Système" par défaut (bien entendu, un administrateur peut s'élever en tant qu'utilisateur "système" très facilement). De plus les mots de passe ne sont pas stockés en clair mais sont chiffrés. Le mot de passe (chiffré) pour un service donné se trouve dans : HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\_SC_<Nom du Service>\CurrVal Ensuite pour retrouver le compte associé à ce mot de passe il faut aller voir la valeur : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Nom du Service>\ObjectName Le problème est que ce chiffrement est facilement réversible et qu'il existe de nombreux outils disponibles sur internet pour afficher en clair la liste des mots de passe stockés dans les secrets LSA, et donc ceux des comptes de services... Maintenant prenons le scénario suivant, un service lié à une application X a été déployé sur tous les serveurs (voire toutes les machines), avec le même couple "compte de service" / "mot de passe". Ajoutons que généralement ce type de compte de service a des droits importants, souvent de type administrateur. Nous avons donc une situation où, si une des machines est compromise, toutes les autres machines le sont, car l'attaquant est maintenant en possession d'un compte utilisateur privilégié avec son mot de passe. Évidemment le scénario est encore pire si le compte de service utilisé n'est pas un compte local mais un compte du domaine, et pourquoi pas de type administrateur du domaine... Une des solutions à ce problème est de ne pas utiliser de comptes spécifiques mais plutôt d'utiliser les comptes de services par défaut (Local system , Network Service etc...). On peut aussi utiliser des comptes locaux, mais avec des mots de passe unique pour chaque machine. L'effort en terme d'administration est important mais nécessaire vu la nature du risque ... 5 Avertissement concernant le site de PHP-NukeLe site officiel de PHP-Nuke (http://phpnuke.org) a fait l'objet d'une compromission aux alentours du 7 mai 2010. Celle-ci s'est caractérisée par l'injection d'un iframe resté actif pendant plusieurs jours. Les internautes navigant sur ce site avec l'exécution de JavaScript activée étaient redirigés vers un site malveillant exploitant plusieurs vulnérabilités (notamment une concernant Acrobat Reader, voir avis CERTA-2010-AVI-012). Cette information a été diffusée par de nombreux sites d'antivirus, mais elle n'a pas été relayée sur le site officiel de PHP-Nuke. Il est donc assez difficile d'en évaluer la portée et de savoir si les sources du produit disponibles en téléchargement ont été modifiées. Le CERTA recommande aux administrateurs de vérifier les postes ayant navigué sur ce site en mai 2010 ainsi que l'intégrité des sources (voir avec l'éditeur) téléchargées au cours de cette période.
|
||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
)
