After I updated to version 1.7. I could not connect to our internal repository anymore. The connection failed with the following error: SSL error: sslv3 alert certificate unkown.

SSL error: sslv3 alert certificate unknown

Our internal respoitory is secured with a certificated issued by our internal CA infrastructure.

Root CA

|
v

Intermediate Certificate

|
v

Repository certificate

Surfing to the svn repository does not produce an error, so the certificate chain is fine. At first I figured that Tortoise was using its own certificate store, but it turns out that Tortoise does use the Windows Root CA store, so there is no need to add the Root CA.

After some more investigation we found out that Tortoise does use the Windows Root CA store to validate the certificate chain, but does not use the Intermediate CA store to complete the certificate chain, like windows does. Since all our client machines have the intermediate certificate in the Intermediate CA store we never noticed that the certificates offered by apache were not chained. After chaining the repository certificate with the intermediate certificate Tortoise was able to talk to the repository again.

The MSS: settings used to be here...

I recently got involved in a project where I defined the Baseline Security settings for windows and Linux. I used the settings provided by the Center for Internet Security (CIS).

We decided on the following approach:

• Based on the CIS templates we created a baseline document specific to our company
• I, in my security role, created a Nessus .audit file, so we could audit compliance to our own baseline with Seccubus
• The windows administrator created GPOs to apply the settings.

When creating in the GPOs we did a strange discovery. In a windows the settings that are normally marked as MSS: in the category Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options do not appear in a domain if its functional level is Windows 2008.

This made us wonder, have these setting become irrelevant ? If this is not the case, how can we still set them, preferably via group policy?

The settings are not irrelevant, as e.g. Peter van Eeckhoutte’s blog points out. Windows 2008 does not forward IPv4 packets that have source routing on them,  but it does accept them if the machine is the final destination. However for IPv6 Windows 2008 will forward these packets by default.

So if the settings are not irrelevant, how can we apply them if they are not in the Group Policy Editor? For this purpose we created an .adm file, which can be loaded into the Group Policy editor as a Classic Administrative template.

All the MSS settings can be controlled with this Administrative template. When we applied these settings we reached our desired compliancy with our own baselines.

Mission Accomplished!

So what are these MSS setting and what do they do?

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.

The new Seccubus logo

Last month our coworker Frank Breedijk rechristened his vulnerability management tool Seccubus. Today he has launched his new website Seccubus.com

With the new website author Frank also unveiled the new logo for Seccubus drawn bij Schuberg Philis collegue Robert Heuvel.

Slide deck “Seccubus Confidence 2009.02 v0.1″

This afternoon/evening, Security Justice will hold their 1st Annual International Podcast BBQ to celebrate US labor day.

The BBQ will feature our Schuberg Philis colleague Frank Breedijk as blogger for cupfighter.net and author of AutoNessus

At 15:00 EST (20:00 GMT) they will kick off by firing up the grill and opening the (probably not first) beers. After this there will be a series of interviews:

16:00 EST (21:00 GMT)  – Our own Frank Breedijk (@autonessus)
17:00 EST (22:00 GMT) – Chris John Riley (@ChrisJohnRiley) and Robin Wood (@digininja)
18:00 EST (23:00 GMT) – James Arlen (@myrcurial)
19:00 EST (00:00 GMT) – Nick Owen (@wikidsystems)
20:00 EST (01:00 GMT) – Clean-up and the usual banter…

The podcast will be streamed live via hak5radio.com and IRC: irc.freenode.net #securityjustice will be used for audience participation.