My main objective in watching the webcast (which is not my usual habit) was to find out if systems that have the described workaround applied still need to apply the patch. The webcast did not give a definitive answer but this YouTube video and the Netifera website and the twitter accounts Thai Duong provide the answer: Yes you should apply the patch a.s.a.p!

Click here to view the embedded video.

However the Q&A section of the talk did give me, as a security operations guy, quite some food for thought. I made some notes in my own Twitter feed, which I have summarized here.

Q: Why did Microsoft release and OOB update for a vulnerability rated “only” as important?
A: The vulnerability itself is rated as Important because it is not a vulnerability that directly leads to remote code execution on the vulnerable system, however exploitation of the vulnerability will lead to disclosure of all information in the webroot including web.config. This information can be used for session hijacking, compromising backend databases and to attack associations between websites, e.g. the association of a website with PayPal. Hence an out of band patch was warranted.

Q: Why only release to the download center and not to WSUS etc?
A: We felt we needed to get this update out quickly, the people that need to apply this patch quickly are mainly enterprises who are capable of applying patches without the aid of WSUS. Developing the WSUS capabilities would add another few days of delay to the deployment of this patch.

Q: Is the attack actively used?

A: We have seen limited attacks against this vulnerability as well as continuous efforts to to bypass installed workarounds.

Q: Can the patch be uninstalled, does it require a reboot?
A: The patch can be uninstalled and does require a reboot.

Q: If you have multiple versions of .Net installed on the system, do you need to install all patches for each version of .Net?
A: Yes.

Q: If you have 64bit and 32bit version of Asp.Net installed, do you need to apply both 64bit and 32bit patches?
A: No, the 64bit patch will patch the 32bit versions as well.

Q: Should we regard the ASP.NET MachineKey as compromised?
A: Yes, if you have set a static MachineKey it is recommended to replace this key with a new key. (Information on AutoGenerated MachineKeys was not provided)

Q: Will the patch have an effect on end-users?
A: Yes, information stored on the client that is protected by the MachineKey can no longer be validated. This can e.g. mean that users whoo used a ‘remember me’ function will have to login in again.

Q: Does the patch need to be applied to all nodes of a cluster?
A: Yes, because the patch changes the way data in transit (such as e.g. viewstate) is encrypted, this patch needs to be applied to all nodes in a cluster as the same time or users may experience unexpected results.

Q: Does the patch change IIS?
A: No, the patch only changes ASP.NET, not IIS.

Q: Does the patch change the way encrypted data is stored on the server?
A: No, the patch changes the way data in transit is cryptographically protected, both encryption and signing is now applied. It does not effect any encrypted data stored on the server.

Q: Are the patches in the download center “smart” enough to know if they are applicable for the machine you apply them to?
A: No, detection capabilities will be built into the patches once they are deployed to WSUS.

Q: Should the update be applied to all .net installation, not just web servers?
A: The vulnerability only manifests itself via web servers. For now it is recommended to only install patches there, and way for the patches to appear in WSUS before patching other .net installs. But remember a system with an unpatched .net installation will become vulnerable as soon as a webserver is installed.

Q: Should the workaround be removed prior to patching?
A: No, you can apply the patch with the workaround in place. If you need to do so you can then remove the workaround after the patch has been applied. CustomErrors generally does not hurt and neither does UrlScan all though UrlScan is known to break SharePoint and may break other web applicaitons as well

Q: Do customer applications need to be recompiled?
A: No.

Scott Guthrie’s blog has an excellent overview of which patch is applicable to which platform.

On the 9th of September, together with the regular MS updates an update for WSUS 3.0 came in: Service pack 2. The first issue we encountered was the fact it was announced as an upgrade. It performs a re-install though. This means you have to reconfigure the basic setup of WSUS. The computer list and grouping definitions are safe in the database. Things like which updates and which language to download will have to be configured again though. Being prepared here by making a note of current settings will help.

We ran into a new issue the next morning. The upgrade of WSUS also upgrades all clients with the Windows Update Agent. This runs flawless on 32 bit windows clients. It causes an issue on 64 bit windows however: two files, NT5IIS.CAT and IASNT4.CAT are replaced, probably by 32 bit versions. When you connect to the console of the server it will tell you about this in the form of a Windows File Protection Error. The choice is yours to cancel this warning and ignore like we did, because it concerns a database server and the files will never be used (NT5IIS for web server, IASNT4 for internet authentication). You could also cancel and replace the files manually from CD or service pack. Fact is that the files copied with this update are dated 25-05-2005, so very old and will most like cause problems when you ever need them.

I thought I’d share this information as I’m sure other people will run into this problem as well. Would be a shame if they had to go through the same cycle!