Applications ASP.net et le ver Conficker (Downadup)

  • Article

English Version

La semaine a encore été chargée pour l'équipe support IIS, mais elle s'est révélée des plus intéressantes puisque nous avons eu l'occasion de voir quelques serveurs IIS 6 (Windows 2003) infectés par le ver Conficker aussi dénommé Downadup. Comme vous le savez, Microsoft a sorti un patch de sécurité et il est fortement recommandé de l'installer le plus rapidement possible. En l'absence de ce patch, une infection par Conficker peut provoquer des erreurs sur vos applications ASP.Net. Nous évoquerons ici quelques scenarios rencontrés récemment.

Scénarios :

  • Vous démarrez votre browser pour vous connecter à votre application ASP.Net, mais tout ce que vous obtenez est un message du type "Service Unavailable". En regardant les journaux d'évènements applicatifs, on remarque qu'il y a de nombreuses erreurs enregistrées par ASP.NET 2.0 indiquant que l'Application Domain n'a pas pu être créé

  • Vous démarrez votre browser et quand vous ouvrez la page de votre application ASP.Net, vous avez un message vous informant que l'application ne peut pas se connecter à "Out Of Process State Server" dans ASP.Net. Si vous investiguez un peu, le processus "aspnet_state.exe" qui héberge l'"Out Of Process State" est démarré, et rien n'a changé dans la configuration du serveur IIS 6

    

Après investigations, il s'avère que le serveur IIS incriminé avait été infecté par le ver Conficker.

Plus d'investigations :

Si vous êtes tombé dans un des scénarios mentionnés ci-dessus, téléchargez et installez "Process Monitor" (Procmon) sur le serveur infecté.

Si vous êtes dans le scénario 1, lancez l'utilitaire Procmon en démarrant une trace et essayez de recycler l'Application Pool qui héberge l'application ayant le problème, sinon essayez de redémarrez le "ASP.Net Session State Server" et ensuite connectez vous à l'application ASP.Net. Ensuite Stoppez la trace.

Filtrez la trace en n'affichant que les opérations effectuées par le processus "W3WP.exe" pour le cas 1, et "aspnet_state.exe" dans le cas 2. Et enfin ajoutez le filtre "Result |is |Access Denied|then|Include". Vous devriez obtenir la même chose que dans l'image ci-dessous :

        

Si vous voyez de nombreux "Access Denied" sur "%WinDir%\WindowsShell.Manifest" et sur "%WinDir%\Assembly\PubPol3.dat" c'est que votre serveur est (ou a été) infecté par Conficker :

    

Les "Access Denied" que vous voyez sont dû à un changement d'ACLs sur ces fichiers. Par défaut, les Utilisateurs et Groupes Windows suivant ont des permissions sur les deux fichiers :

  • Group : "Users" avec droit de lecture
  • Group : "Power Users" avec droit de lecture, exécution et écriture
  • User : "System" avec tous les droits

Solution :

Vous devez manuellement rétablir les ACLs sur ces fichiers. Pour le WindowsShell.Manifest, ceci peut être fait via l'interface Windows Explorer en sélectionnant le fichier et en éditant ses propriétés. Dans l'onglet sécurité accordez les droits suivants :

  • Group : "Users" avec droit de lecture et d'exécution
  • Group : "Power Users" avec droit de lecture, exécution et écriture
  • User : "System" avec tous les droits

Pour le pubpol3.dat, qui est localisé dans la GAC (Global Assembly Cache), nous ne pouvons pas changer les ACLs via Windows Explorer puisque le shell de Windows Explorer a été changé pour afficher le contenu de ce dossier spécial. Nous devons utiliser la ligne de commande cacls.exe. Exécutez les commandes suivantes :

  • cacls.exe c:\windows\assembly\pobpul1.dat /E /G SYSTEM:F
  • cacls.exe c:\windows\assembly\pobpul1.dat /E /G "Power Users":C
  • cacls.exe c:\windows\assembly\pobpul1.dat /E /G USERS:R

Le paramètre /E spécifie que nous voulons modifier les ACLs et non les remplacer. Le paramètre /G spécifie que nous allons autoriser les nouveaux droits pour l'utilisateur spécifié.

Une fois la modification effectuée, vous devriez être capable de redémarrer IIS (processus W3WP.EXE) sans erreurs, ou être capable de redémarrer l'"ASP.Net Session State Service" et ensuite de vous connecter à votre application ASP.Net qui utilise les sessions out of process.

Si l'erreur persiste, prenez une nouvelle trace avec Procmon et voyez si vous avez de nouveaux "Access Denied", principalement sur les assemblies (DLLs) qui sont situées dans la GAC (%WinDir%\Assembly\).

Article écrit par Paul Cociuba / traduction par Sylvain Lecerf (équipe support IIS)