Cupfighter.net

A few days ago while starting TortoiseSVN it prompted me to update to version 1.7

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. Read more…

Last night I attended the Microsoft Security Response Team webcast regarding the Out Of Band patch for the ASP.net padding Oracle vulnerability discovered by Juliana Rizzo and Thai Duong 11 days before.

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!

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?

Read more…

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.

Here are the slides of my presentation.

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.