Downadup (Conficker) Virus and ASP.net on IIS 6.
It's been another busy week here on the IIS team, but an interesting one as well since we had the occasion to see several IIS 6 (Windows 2003) Servers infected with the Downadup or Conflicker worm. As you already know, Microsoft has rolled out a security patch for the virus which is recommended you install right away. But it has also become apparent that there is another side effect to the virus: if you have errors with your ASP.net applications that were running before and that are refusing to run after infection, you might wish to continue reading.
We have seen the following scenarios:
In both these cases the Windows 2003 Server on which IIS 6 is installed has become infected with the Downadup or Conflicker virus.
If you find yourself in one of the two scenarios mentioned above, download and install Process Monitor from the Microsoft website and install it on the infected computer.
Proccess Monitor can be downloaded from:
Once installed, run the Process Monitor and attempt to recycle the Application Pool that is hosting your failing web-application if you find yourself in scenario number one, or attempt to restart the 'ASP Net Session State Server' and then connect to the ASP.net application. Then stop the trace that was running.
Filter the trace, by first eliminating all events that do not come from the file system, then based on the process name: setup a filter on 'Process Name' is either 'w3wp.exe' or 'aspnet_state.exe'. To finish the filter, add another condition: 'Result' is 'ACCESS DENIED'. You should obtain a list that looks like the one shown below:
If you note that you have 'ACCESS DENIED' results on %WinDir%\WindowsShell.Manifest and on %WinDir%\Assembly\PubPol1.dat (may also be other numbers after PubPol) than you have encountered the side effect that seems to be caused by the virus.
Why is this happening?
The 'ACCESS DENIED' results you are seeing is because the Access Control Lists (ACLs) on the above files have been changed. By default the following Windows users and groups have permissions on the two files:
You need to manually re-establish the ACLs on these files. For the WindowsShell.manifest, this can be done via the Windows Explorer interface, by selecting the file and editing its properties. In the 'Security; tab grant the following rights:
For the pubpol1.dat, which is found in the .Net Framework GAC (Global Assembly Cache), we cannot change the ACLs via Windows Explorer since the shell of Windows Explorer has been changed to display the contents of this special folder. We have to revert to the command line utility called cacls.exe. Execute the following commands:
The /E parameter specifies that we are only wanting to modify (edit) the current ACLs and not replace them with the ones we are setting via the command line. The /G parameter specifies that we are granting the new rights to a specified user.
Once the modifications in place, you should be able to restart w3wp.exe with no errors being logged from ASP.net or you should be able to restart the 'ASP Net Session State Service' and then connect to the ASP.net application that uses ASP.net application that uses out of process sessions.
Should the errors persist, take another Process Monitor trace and see if you encounter any other 'ACCESS DENIED' results, most likely on assemblies (dlls) that are located in the GAC (%WinDir%\Assembly\).
Paul Cociuba - IIS and ASP.net Support Team
PingBack from http://www.clickandsolve.com/?p=2582
We have a couple of ASP.NET applications that have ceased to function since Conflicker hit our site. We are seeing the same pattern in the event logs and the same ACL changes on the %WinDir%\WindowsShell.Manifest, but we have no %WinDir%\Assembly\PubPol1.dat.
What we see in process monitor when we filter for w3wp.exe and aspnet_state.exe are a lot of queries for a registry key that does not exist - HKLM\SOFTWARE\Microsoft\ASP.NET\UseWorkStation
We get no ACCESS DENIED errors. This is our WSUS server.
Hello Ben Hall,
The idea is that as I have specified in the original article, PubPol1.dat is one of the files that the .Net Framework uses to store its policies in. You should look for access denied on PubPolN.dat where N is any number. If you are seeing appDomain creation errors you should have access denieds on some PubPol file in the GAC (C:\Windows\Assembly).
Hope this helps,