Collaboration - Walk into any partnership with open eyes

The title of this blog may seem to have little to do with security at first glance but the thought came to me as I continue to follow the developments in the Flame arena.

As always the discussion here is based on information that we know. There is always a chance that what we know has been planted so always consider this when planning actions - and I guess that ties into the whole point of this post.

I was reading an item on Flame that seemed to confirm some of the original thinking, that the recently found incarnation is directly related to the development of Stuxnet as well as Duqu (and likely others). This should not be earth shattering to anyone as the pointers to that linkage are many including shared code, common targets and when looking at the bigger picture the fact that Flame was a data gatherer while Stuxnet included action elements. This follows the "know your enemy before acting" mentality.

The interesting thing for both Stuxnet and Flame is that discovery came only after one of the collaborators in developing the platform decided to take action with the platform outside the original scope. Stuxnet was discovered when it went beyond its target platforms and into the Internet after a poorly implemented code change. It now appears Flame was discovered after it was directed to another environment. Both these actions were unilateral actions taken by one of the parties involved in the development.

These types of actions should not surprise anyone either. When you have a vehicle such as this that has been successful for a period of time the temptation to manipulate it for your benefit is significant. What we need to think about though is the impact it had on the overall program. Did these actions raise the risk of other similar platforms being discovered or other actions being taken to reduce risk? Does this now impact how successful the original program is going to be in halting or delaying the original intent? We need to remember the goal here is to halt or delay nuclear weapons development so the stakes are high.

But in the general business environment the same thing can happen. I am not suggesting you cannot have good partnerships between companies that are "frenemies" but you do need to make sure your eyes are open. Of course it is more than just redirecting the partnership - when companies collaborate you also need to make sure that the shared environment is protected to the highest common denominator of security. It is no longer just our data at risk - it is also your collaborator's data and that loss could pose bigger problems in the long run.

It appears that the Stuxnet-Duqu-Flame attacks has brought to light more issues than just the security issues. Yes those security issues are many including very important ones like managing your trust environment and evaluating what certificates and algorithms are in use and/or trusted in your environment, but we now also need to consider that this effort really became known only because of mistakes made by one partner in the trust relationship. That may be the bigger lesson - security is not just about what you do but also what those that you deal with do as well.

That is something to spend some time thinking about.


- Posted using BlogPress from my iPad

Flame Extinguished?

I will give Microsoft credit in reacting quickly to Flame and its use of faked Microsoft CA certificates. Microsoft quickly came out and moved the two MD5 certificates that were faked and the SHA1 certificate that was abused to its untrusted store. The fact that they did this through the Microsoft update, which was one of the transaction sets that was hijacked by these certs, is kind of funny but that is an aside.

So did Microsoft solve the problem. The simple answer is NO!

Microsoft solved the problem that was created by their certificates. The problem that was created by generating a CA certificate and having the signature applied using an algorithm that was known to have weaknesses and was demonstrated to be attacked in a very similar way the year BEFORE the certificate was generated. In putting their certs in the untrusted store they closed this door - but this is not the only door that exists.

What Flame did was highlight that this attack is not only feasible but something that is executable. Did this take a high degree of knowledge and expertise - of course. The MD5 attack was a bit different then that demonstrated in the past - but this was something that was going to happen. The original demonstration of an MD5 collision attack was done on a cluster of high-end IBM UNIX servers. A few short years later the attack was performed on a network of 200 Playstation 3s. Now this says a lot about technological advancement in processing power for sure but also says a lot about the threat and how rapidly it grows. In 2005 when this was an active topic Ron Rivest (the R of RSA) said ""md5 and sha1 are both clearly broken", when speaking in terms of collision resistance. 


So what do we take away from this? Organizations, including groups like the CA Browser Forum, need to get very diligent about what CA certificates are in browsers, applications, and hardware devices. These need to be assessed for requirement, strength and validity periods and a clear strategy needs to be put in place to understand what is there and how to replace what should not be there. If you look in your out-of-the-box browser today you will not only find MD5 based signatures but also MD2 based signatures. Yes these have been around for some time but we must think that if they have been replaced with a new infrastructure why are we keeping the old ones around? We must also start to question the lifetime of the SHA1 based signatures. There are some CA certificates that are out there that are SHA1 with very long lifetimes - and some with weak key algorithms (RSA-1024 keys for example).


So it is time to get diligent and start to manage your environments - or the next flame may be one licking at your feet.

It did not take long ... FLAME on

OK - I promise no further Marvel references.


I do know it has been a while since I have updated this blog but there have been a few changes going on so I sat back and took it all in first. That being said I could not sit back and not comment on the latest discoveries that have come out of the FLAME discussions given how it touches so much of what I have been doing and now what I am doing.


So if you are reading this you likely know what FLAME is - or at least you know what has been published. I suspect that there is still a lot to discover but I wanted to highlight some very important things that come out of what we know so far.

The FLAME malware has been dissected over the last few days and one of the most disturbing finds that has come out, in my view, is the discovery of 3 certificates that appear to be rooted in the Microsoft Root CA.

The certificates in question are:

Microsoft Enforced Licensing Intermediate PCA (2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70) - Issued by Microsoft Root Authority 

Microsoft Enforced Licensing Intermediate PCA (3a 85 00 44 d8 a1 95 cd 40 1a 68 0c 01 2c b0 a3 b5 f8 dc 08) - Issued by Microsoft Root Authority

Microsoft Enforced Licensing Registration Authority CA (fa 66 60 a9 4a b4 5f 6a 88 c0 d7 87 4d 89 a8 63 d7 4d ee 97) – Issued by Microsoft Root Certificate Authority 

The disturbing part of this is that the PCA certs were generated using MD5 as a hashing algorithm. This created an ideal environment against which to attack since MD5 is known to have weaknesses.

Now, of course, we are not yet certain that it was MD5 that was the vector of attack but there certainly is suspicion based on the purported parties behind FLAME (Nation State suspected), along with the fact that the delivery of code was done using these certificates. These facts combined with the fact that the MD5 attacks have been published since 2005 raises the suspicion level even greater.

The fact that the creators/designers took advantage of this attack to go after the MSUpdate service and the MS license registration process is powerful. This style of attack creates a number of vulnerabilities:

• Raises the risks when performing the required MS registration of any product that may have been officially registered. Today it appears it was only against the Terminal Services environment but the complete story may be different than this.
• The attack creates a Man-in-the-middle (MITM) risk for any machine where these certs were injected.
• The PCA certs have a broad use base defined within their extended key usage including code signing and possibly more worrisome CRL signing. The extended uses for these certificates were critical in allowing the attack to happen (code signing usage) and potentially for preventing discovery with the fact that they also have CRL signing capabilities.

The CRL signing risk is significant since as long as a system has these certs in the trusted store the CRLs are inherently untrusted. The timeframe for these certs to have been in place and the certificates that may have been trusted through the path defined by these certs also raises the potential of further down stream risk.

This of course was a directed attack against the system using known vulnerabilities but it also raises questions/concerns with processes within Microsoft. These concerns include:

-       Use of MD5 for signature hashing

-       Broad definition of key usage for given certificates

-       Lifetime of intermediate CAs given the ever changing technology environment

So outside of the obvious issues for anyone that was impacted directly by FLAME this does highlight a number of weaknesses in managing environments. Ones own environment may be greatly influenced by those you deal with. In this case an injection occurred, likely, through a software registration process. It was achievable due to poor management of signature algorithms and certificate usage settings. This attack demonstrates that these types of attacks are achievable and likely have been for at least 5 years.

So if you were not paying attention to what certificates were in your stores before I hope you will now. You need to:

• Look for known bad ones;
• Evaluate what roots you trust, and why;
• Look at what signing, hashing and key lengths are used and;
• Look at what certificate lifetimes are indicated

This area of Certificate and Key management is becoming more critical as it no longer just touches how I secure my running shoe purchase on Zappos but now it affects how I get software and how I trust that and in todays cloud-based world that is a potentially disconcerting issue.