1 Incidents de la semaine

CKEditor, FCKEditor : une porte d’entrée pour les intrus

CKEditor, comme son prédécesseur FCKEditor, est un éditeur texte et HTML WYSIWYG distribué sous plusieurs licences de logiciels libres.

Il permet d’enrichir le site Web sur lequel il est présent, par la création en ligne de pages, de commentaires ou de billets. Il est intégré ou utilisable sous forme de module dans des gestionnaires de contenu (CMS) ou dans des développements spécifiques.

1.1 Incidents récents

Deux incidents très récents ayant affecté la communauté des utilisateurs du CERTA ont un point commun : FCKEditor a servi de porte d’entrée aux intrus.

Dans un cas, le chargement d’un fichier a permis à l’attaquant l’escalade de permissions jusqu’à devenir super utilisateur. Il a alors compromis tous les sites Web présents sur le serveur physique.

Dans un autre cas, la compromission du site Web a permis des rebonds sur d’autres serveurs du réseau.

1.2 Recommandations

Des précautions élémentaires ont déjà été recommandées par le CERTA pour limiter l’accès de cet éditeur aux utilisateurs légitimes et pour limiter l’impact d’un détournement de son utilisation (voir la sous-section Documentation).

Il est donc indispensable de rappeler quelques règles :

  • faire l’inventaire des moyens de modifier le contenu du serveur Web et du serveur sous-jacent (FCKEditor, WebDAV, FTP, SSH…). Ces moyens peuvent être peu visibles car intégrés à des logiciels applicatifs (CMS, par exemple) ;
  • mettre, comme toujours, ses systèmes et ses logiciels à jour ;
  • n’autoriser l’accès aux moyens de modifier le contenu qu’aux utilisateurs et aux adresses nécessaires. Ceci implique un filtrage réseau et une authentification adaptée des utilisateurs ;
  • utiliser des mots de passe forts pour ces moyens de modification et, si le contexte l’exige, une authentification forte du client ;
  • (faire) vérifier régulièrement l’intégrité des postes de travail à partir desquels les modifications sont faites. Un mot de passe fort est en effet inutile si un cheval de Troie sur un tel poste copie et diffuse à volonté ce mot de passe ;
  • n’allouer que les droits indispensables aux processus liés à ces outils de modification ;
  • désactiver ces moyens dès lors qu’ils ne sont plus indispensables ;
  • mettre en place un système de vérification de l’intégrité du serveur ;
  • journaliser les modifications et analyser régulièrement les journaux.

La vigilance doit être encore plus grande lorsque le site Web est sur un serveur mutualisé.

1.3 Documentation

2 Élévation de privilèges d’administrateur local à administrateur de domaine

Lors des investigations menées par le CERTA, nous sommes amenés à constater des compromissions profondes d’environnements de production. Fréquemment ces situations sont dues à la méconnaissance des mécanismes permettant à un attaquant d’élever des privilèges d’administrateur local d’un poste ou serveur compromis vers des privilèges d’administration de la globalité du système d’information.

Ces attaques, de la plus simple à la plus sophistiquée, de la plus rapide à la plus lente sont régulièrement constatées dans les environnements sur lesquels le CERTA est intervenu.

Notre bulletin d’actualité se propose de détailler certaines de ces attaques ainsi que les mesures permettant de limiter l’exposition aux risques et aux impacts dans vos environnements. Pour commencer, le bulletin d’actualité se concentrera sur les environnements Microsoft Windows. L’administrateur d’une machine Windows (légitime ou illégitime) dispose des privilèges nécessaires pour inspecter, modifier ou « trahir » le système d’exploitation et les applications de cette machine. Tout ce que le système recèle de mots de passe, de clés, de condensés ou plus généralement de « secret » est accessible à un code disposant des privilèges d’administration locaux.

Force est de constater que l’attaquant dispose aussi d’un autre levier dans son attaque : le temps. Nous remarquons qu’un attaquant peut patienter des semaines voire des mois afin qu’un évènement rare ou improbable se produise et lui apporte les clés du système d’information. Pour illustrer ce propos, nous allons aborder les premières techniques simples (et redoutables) fréquemment exploitées.

Très Simple : l’implantation de clés de registre

Attaque :

Sous Microsoft Windows, un attaquant ayant les privilèges d’administration sur un poste dispose des droits d’écriture dans la ruche HKEY_LOCAL_MACHINE. Il peut alors y inscrire le lancement automatique d’une commande de son choix à chaque ouverture de session, que le logiciel soit ou non malveillant. L’attaquant n’a alors plus qu’à attendre l’ouverture d’une session avec un compte « puissant » pour disposer de ses droits et privilèges. Par exemple, le ver Conficker a compromis un nombre bien plus grand de systèmes en utilisant cette technique qu’en exploitant la vulnérabilité adressée par le correctif MS08-067.

Prévention :

Il n’existe pas de défense absolue contre cette attaque. Néanmoins les mesures habituelles de défense en profondeur pourront très largement en diminuer la probabilité et l’impact :

  • ne pas ouvrir de session interactive avec un compte d’administration « puissant » sur des postes d’utilisateurs. Au contraire, utiliser RunAs ou « exécuter en tant que » pour élever les privilèges des seuls processus nécessaires.
  • ne pas utiliser de compte d’administration du domaine pour intervenir sur des postes utilisateur potentiellement compromis (recommandation typiquement destinée aux équipes de support).

Simple et rapide : l’énumération des sessions de la machine compromise

Attaque :

Lors de la compromission d’une machine, l’attaquant disposant des droits locaux d’administration locale peut énumérer les processus présents sur un poste et « emprunter » les droits associés à ces processus. Si un processus s’exécute sur un poste compromis en utilisant un compte puissant du domaine, alors l’attaquant peut s’associer à sa session et usurper ses privilèges.

Prévention :

Il convient de s’assurer que des processus ne s’exécutent pas avec des comptes puissants du domaine. Ainsi les scripts, les services, les tâches planifiées ne sont exécutés qu’au moyen de comptes restreints aux seuls privilèges requis par cette tâche.

À suivre…

Rappel des avis émis

Dans la période du 12 au 18 septembre 2011, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :