ASP.net Applications and the Conficker (Downadup) virus
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.
Scenarios:
We have seen the following scenarios:
you start your browser to connect to the ASP.net application but all you receive once you navigate to its address is a 'Service Unavailable' message in your browser. Upon investigation of you Event Viewer Application log, you notice that there are lots of errors logged by ASP.net 2.0 telling you that the Application Domain could not be created.
you start your browser and when you open the page of your ASP.net application you have a message that informs you that the application could not connect to the 'Out Of Process State Server' in ASP.net. Upon investigation you note that the aspnet_state.exe process that hosts the 'Out Of Process State Server' is running and nothing has changed in the configuration of your IIS 6 server.
In both these cases the Windows 2003 Server on which IIS 6 is installed has become infected with the Downadup or Conflicker virus.
Further Investigation:
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:
https://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
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:
- Group: 'Users' with read rights
- Group: 'Power Users' with change rights (read / execute / write)
- User: 'SYSTEM' with full control – this is the user that the .Net Framework will use to read these files so that it can evaluate the permissions needed to create the Application Domain.
- User: 'Administrator' with full control – the rights for this user should not have changed.
Solution:
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:
- Group: 'Users' should have read and execute rights
- Group: 'Power Users' should have read, execute and write rights
- User: SYSTEM should have all rights on this file.
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:
- cacls.exe c:\windows\assembly\pubpol1.dat /E /G SYSTEM:F
- cacls.exe c:\windows\assembly\pubpol1.dat /E /G "Power Users":C
- cacls.exe c:\windows\assembly\pubpol1.dat /E /G USERS:R
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
Comments
Anonymous
January 31, 2009
PingBack from http://www.clickandsolve.com/?p=2582Anonymous
February 11, 2009
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%AssemblyPubPol1.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 - HKLMSOFTWAREMicrosoftASP.NETUseWorkStation We get no ACCESS DENIED errors. This is our WSUS server. Any thoughts?Anonymous
February 18, 2009
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:WindowsAssembly). Hope this helps, Paul