June and July gave lots of opportunity for people to talk about Flame and I will bet all of you are tired of hearing about it - and I would say rightfully so. The reality is that Flame is not likely to affect you. I know a few people who will hate that line but it is the truth.
The TRUE reality is that the attacks vectors and malware elements are not used once and then discarded - and that is why we have a problem in the world of cybersecurity. People see the headlines about Sykipot and Flame and then see days later mitigation mechanisms and that they feel is the end of the story - it truly is not.
Sykipot had a number of variants that have done damage in the wild and they have been seen over many many months. Some would say that the similarities between Stuxnet, Duqu and Flame are indicative of malware reuse with some additions in the attack vectors.
Now we have another variant that leverages elements of Flame and attacks the financial sector and could also contain elements to attack other critical infrastructure elements. Read about Gauss here.
The Flame may be out, according to the pundits, but the embers are still causing havoc and you need to be aware that the attack vector used is a dangerous one and that you need to understand your infrastructure to protect against attack. The malware side of these attacks will eventually be signatured but until they are you need to stop allowing strangers in your networks. In previous posts I have given some basic guidance on what you need to do but it truly does start with understanding your infrastructure: managing the trust domains you use through the Root Certificate Authorities you trust; ensuring you have a strong policy for user authentication; and when using certificates as part of that have a good policy for key length, algorithms used and lifetimes and then manage them properly.
Those embers will burn as long as there is money to be made attacking other people so you need to protect yourself from getting burnt.
- Posted using BlogPress from my iPad
Friday, August 10, 2012
Friday, July 20, 2012
Is Power Grid security being given up for convenience?
I live in an interesting area just outside of Washington DC. We have the suburbs that are old and established with the big beautiful oaks and then we have the growing suburbs that are sprouting out of old farm fields. The last few weeks have seen a rash of storms that have delivered devastating blows to the power supply at people's homes. Those in the newer suburbs have been less affected due to buried cable than those in the beautiful old neighborhoods where wire is still strung amongst those beautiful old oaks that tend to fall and take out the overhead infrastructure. Of course these storms are either summer thunderstorms, in this case, which happen during the hottest part of summer - so no power means no air conditioning in the DC heat. The other end of the spectrum is a nor'easter in February which takes out power when it is well below freezing. Welcome to living in the DC area.
Of course all of this has people talking about the power companies in terms of reliability and response. Things like "How can a company not be prepared for this type of situation - people without power for a week" have been heard frequently over the last two weeks. Well I am not one to beat up a power company for nature unleashing its fury. Nature is unpredictable and when a storm does happen, as in this case, it can be a very large undertaking to get things coordinated to remove trees and then restring wires etc.
Where I do have an issue is when it comes to the things that they are doing which can be planned for over a long period of time. We have all seen recent articles on the hacking of the power grid in various magazines over the last few years. In c|net, Scientific American, and you can even go to YouTube to see a video on how to do it. Congress, the National Security Agency and others have highlighted the fact that we have this vulnerability. The National Institute of Standards and Technology (NIST) has been working with industry to develop a stronger set of security standards for the SmartGrid to try and build a better grid.
BUT .....
We still have people in the industry that appear to think that the problem is not that bad. The North American Energy Standards Board (NAESB) authorizes two organizations to issue certificates for the Grid today - Open Access Technology International (OATI) and GlobalSign (Yes the same folks who had their website hacked earlier this year). Both OATI and GlobalSign feel it is OK to have long life certificates within the infrastructure protecting the power grid. In fact both have stated that 30 year certificate lifetimes are ok from a security perspective.
I myself find that amazing as the criticality of this infrastructure and its impact on Defense, Homeland Security and the economy is well recognized. This is an infrastructure you want to protect. Part of the argument is the difficulty in updating but then the OATI webCares CPS indicates an 8 year lifetime for Root certificates. Globalsign does allow 30 and 40 year Root certificates in its Certificate Policy and goes as far as 5 year for end devices. They also allow SHA1 hashed certificates, with a 2048 RSA key. There does seem to be some contradiction in the Globalsign CP in that it indicates following of NIST guidance but is not all that specific on which guidance. Certainly today NIST does not recommend use of SHA1 for any certificate use and long life certificates for Root CA's or any issuing CA is also not recommended due to the rapidly evolving attack vectors.
So what we are left with is two companies that seem to think that they can mitigate the risk of technology obsolescence. If we look at history we learn some very hard lessons. MD5 went from a suspected problem (1997) to a demonstrated attack in 8 years. Within 7 years of this first demonstrated attack (2005) there was a usable attack vector that allowed an attacker to introduce malware without the victim knowing and apparently not knowing for a couple of years. So yes one can replace their certificates if someone sees an attack against the CA or the technology that was being used but will that be too late? Will the logic bombs already be in place? If they are can we find them in time? If we do not what will happen? And what is being attacked, industrial control systems, have been targeted very recently due to existing vulnerabilities.
The risks are high here so rather than playing with convenience should NAESB not make it simple for all involved and strengthen these standards to reduce the risk? I would hope that if I asked the folks that went without air conditioning for a week in 100 degree heat if they would risk losing power again, and maybe for much longer, that they would react strongly. I wonder how people in hospitals and Wall Street would see things?
Of course all of this has people talking about the power companies in terms of reliability and response. Things like "How can a company not be prepared for this type of situation - people without power for a week" have been heard frequently over the last two weeks. Well I am not one to beat up a power company for nature unleashing its fury. Nature is unpredictable and when a storm does happen, as in this case, it can be a very large undertaking to get things coordinated to remove trees and then restring wires etc.
Where I do have an issue is when it comes to the things that they are doing which can be planned for over a long period of time. We have all seen recent articles on the hacking of the power grid in various magazines over the last few years. In c|net, Scientific American, and you can even go to YouTube to see a video on how to do it. Congress, the National Security Agency and others have highlighted the fact that we have this vulnerability. The National Institute of Standards and Technology (NIST) has been working with industry to develop a stronger set of security standards for the SmartGrid to try and build a better grid.
BUT .....
We still have people in the industry that appear to think that the problem is not that bad. The North American Energy Standards Board (NAESB) authorizes two organizations to issue certificates for the Grid today - Open Access Technology International (OATI) and GlobalSign (Yes the same folks who had their website hacked earlier this year). Both OATI and GlobalSign feel it is OK to have long life certificates within the infrastructure protecting the power grid. In fact both have stated that 30 year certificate lifetimes are ok from a security perspective.
I myself find that amazing as the criticality of this infrastructure and its impact on Defense, Homeland Security and the economy is well recognized. This is an infrastructure you want to protect. Part of the argument is the difficulty in updating but then the OATI webCares CPS indicates an 8 year lifetime for Root certificates. Globalsign does allow 30 and 40 year Root certificates in its Certificate Policy and goes as far as 5 year for end devices. They also allow SHA1 hashed certificates, with a 2048 RSA key. There does seem to be some contradiction in the Globalsign CP in that it indicates following of NIST guidance but is not all that specific on which guidance. Certainly today NIST does not recommend use of SHA1 for any certificate use and long life certificates for Root CA's or any issuing CA is also not recommended due to the rapidly evolving attack vectors.
So what we are left with is two companies that seem to think that they can mitigate the risk of technology obsolescence. If we look at history we learn some very hard lessons. MD5 went from a suspected problem (1997) to a demonstrated attack in 8 years. Within 7 years of this first demonstrated attack (2005) there was a usable attack vector that allowed an attacker to introduce malware without the victim knowing and apparently not knowing for a couple of years. So yes one can replace their certificates if someone sees an attack against the CA or the technology that was being used but will that be too late? Will the logic bombs already be in place? If they are can we find them in time? If we do not what will happen? And what is being attacked, industrial control systems, have been targeted very recently due to existing vulnerabilities.
The risks are high here so rather than playing with convenience should NAESB not make it simple for all involved and strengthen these standards to reduce the risk? I would hope that if I asked the folks that went without air conditioning for a week in 100 degree heat if they would risk losing power again, and maybe for much longer, that they would react strongly. I wonder how people in hospitals and Wall Street would see things?
Friday, July 13, 2012
Flame is STILL burning
In this case Flame continues to burn Microsoft. Microsoft have announced the termination of trust of 28 additional certificates within their infrastructure in addition to the 3 that were immediately untrusted when Flame was first brought to light. This new announcement is significant as it highlights the importance of certificates within an enterprise as large as Microsoft but also highlights the interconnectedness of systems. Microsoft's announcement was based on their believe that the newly untrusted CA's are "… outside our recommended secure storage practices". What exactly that means is certainly up for discussion but Microsoft itself states that this effort is being undertaken after their continued review of what happened with Flame. This likely means that they these certificates were protected only as well as those known to be compromised and based on the form of attack there is some level of certainty that these could be exploited as well.
This interconnectivity of systems is becoming a key element of security management. When I speak of interconnectivity I do not just mean network connectivity but I also mean trust connectivity. With todays growing base of interconnected devices, whether that is the traditional server/desktop/laptop, the simple extension to mobile devices such as smartphones/tablets, or whether we take it the next level to control systems such as those interconnected through networks such as the SmartGrid or ones run by companies such as Tridium, we need to consider what happens when a security gap in one element of that infrastructure exists.
This, of course, is also not the end of the conversation. Even if we can find all those certificates and systems that Microsoft "untrusted" on all the platforms that we own and manage, this is one example of how the use of a vulnerable algorithm can create a significant and broadly impacting issue. We knew MD5, the hashing algorithm that was exploited in the original attack, was vulnerable in 2005. In fact some would rightfully argue that we knew about it almost a decade before that when flaws in the algorithm were first identified. At the time these flaws were not considered catastrophic but between 2005 and 2008 attacks against MD5 were demonstrated multiple times. It was so well understood at the time that Microsoft published a recommendation not to use MD5. In 2009 though Microsoft issued a new CA certificate using MD5. A mistake on their part but one that got through and created a significant problem.
MD5 is not the only vulnerable algorithm. Other elements of the system are also vulnerable, thankfully just not exploited yet. These other areas include one of the most commonly used hashing algorithm, SHA1, which has been theoretically shown to have a vulnerability (recognized by NIST in early 2005) but no known attacks have been shown. However the National Institute of Standards and Technology (NIST), which provides guidance for the US Government on computer security requirements, published in 2004 that SHA-1 be phased out of use in the US Government beginning in 2010. The phase out is intended to be completed by the end of 2012.
Hashing algorithms are not the only weakness. Based on the strength and availability of computing systems, 80-bit cryptography is considered vulnerable. Of course everyone will say that they do not use 80 bit keys but what NIST is saying is that algorithms with certain key sizes only provide effective security strength of 80 bits. This includes RSA-1024, DSA-1024 (with specific characteristics) and Elliptic Curve where keys are less than 224. The specific sizes of these three algorithms are again being phased out of use within the US Government as they are considered vulnerable for their common purpose. They will be completely phased out by 2013.
So yes Flame did turn up the heat on Microsoft but it also raises the overall issue of technical obsolescence of cryptographic algorithms and key sizes. This is not the first time this has happened but the major difference is that today the problem is bigger due to the interconnectedness of the systems. We now need to consider how to mitigate the threat posed here and this is where we can learn something from Flame. Flame was created as a data gatherer – the old adage of "know your enemy". We need to do the same thing and in this case the enemy is the use of vulnerable cryptographic algorithms and key sizes. Assess your environment to determine what is used and why and plan to replace those algorithms and those certificates built around vulnerable algorithms as quickly as possible.
And for those of you that think Flame is not an issue - take a look at some of my recent posts and as you read them think about Sykipot and how that has evolved over the last year. Workable exploits do not die - they evolve as our defenses do.
- Posted using BlogPress from my iPad
This interconnectivity of systems is becoming a key element of security management. When I speak of interconnectivity I do not just mean network connectivity but I also mean trust connectivity. With todays growing base of interconnected devices, whether that is the traditional server/desktop/laptop, the simple extension to mobile devices such as smartphones/tablets, or whether we take it the next level to control systems such as those interconnected through networks such as the SmartGrid or ones run by companies such as Tridium, we need to consider what happens when a security gap in one element of that infrastructure exists.
This, of course, is also not the end of the conversation. Even if we can find all those certificates and systems that Microsoft "untrusted" on all the platforms that we own and manage, this is one example of how the use of a vulnerable algorithm can create a significant and broadly impacting issue. We knew MD5, the hashing algorithm that was exploited in the original attack, was vulnerable in 2005. In fact some would rightfully argue that we knew about it almost a decade before that when flaws in the algorithm were first identified. At the time these flaws were not considered catastrophic but between 2005 and 2008 attacks against MD5 were demonstrated multiple times. It was so well understood at the time that Microsoft published a recommendation not to use MD5. In 2009 though Microsoft issued a new CA certificate using MD5. A mistake on their part but one that got through and created a significant problem.
MD5 is not the only vulnerable algorithm. Other elements of the system are also vulnerable, thankfully just not exploited yet. These other areas include one of the most commonly used hashing algorithm, SHA1, which has been theoretically shown to have a vulnerability (recognized by NIST in early 2005) but no known attacks have been shown. However the National Institute of Standards and Technology (NIST), which provides guidance for the US Government on computer security requirements, published in 2004 that SHA-1 be phased out of use in the US Government beginning in 2010. The phase out is intended to be completed by the end of 2012.
Hashing algorithms are not the only weakness. Based on the strength and availability of computing systems, 80-bit cryptography is considered vulnerable. Of course everyone will say that they do not use 80 bit keys but what NIST is saying is that algorithms with certain key sizes only provide effective security strength of 80 bits. This includes RSA-1024, DSA-1024 (with specific characteristics) and Elliptic Curve where keys are less than 224. The specific sizes of these three algorithms are again being phased out of use within the US Government as they are considered vulnerable for their common purpose. They will be completely phased out by 2013.
So yes Flame did turn up the heat on Microsoft but it also raises the overall issue of technical obsolescence of cryptographic algorithms and key sizes. This is not the first time this has happened but the major difference is that today the problem is bigger due to the interconnectedness of the systems. We now need to consider how to mitigate the threat posed here and this is where we can learn something from Flame. Flame was created as a data gatherer – the old adage of "know your enemy". We need to do the same thing and in this case the enemy is the use of vulnerable cryptographic algorithms and key sizes. Assess your environment to determine what is used and why and plan to replace those algorithms and those certificates built around vulnerable algorithms as quickly as possible.
And for those of you that think Flame is not an issue - take a look at some of my recent posts and as you read them think about Sykipot and how that has evolved over the last year. Workable exploits do not die - they evolve as our defenses do.
- Posted using BlogPress from my iPad
Tuesday, July 3, 2012
Do you want to be scared?
In 25 plus years of working in the data comm industry and the majority of that working in the cybersecurity/data security realm I have diligently stayed away from fear-mongering. My basic approach was that there are plenty of business reasons to take cybersecurity seriously, whether it was to maintain your control of your investment, stay ahead of your competition, perform tasks more efficiently, reduce costs of shipping, paper, manpower, and many other benefits. There never has been a reason, from my perspective, to dangle the scythe of death over anyone's head.
Now there have been times when I have looked at cybersecurity from the scythe of death perspective. A number of years ago I worked with the US Government on Critical Infrastructure Protection and there you need to look at cybersecurity from that perspective because if you get it wrong very bad things can happen. So over the last few weeks with all of the discussion on Flame and its relation to Stuxnet and other attacks I started to look at what does this mean from the bigger cybersecurity perspective.
Lots of people hear about these malware variants and when you talk to them their first response is "That won't affect me - it was targeted at Iran" or other Middle Eastern countries. The latter part of that statement is certainly true ... but .... let me pull out the scythe here. What Flame and Stuxnet ended up doing was writing a new chapter in the cyber-attackers handbook. Certainly the creators did not intend for this but through some carelessness the Pandora's box of cyber-warfare has been opened and in it is a very powerful toolkit. Note I did not say weapon. What Flame and Stuxnet has provided is an approach to attacks that is unique and inherently difficult to recognize. Certainly there are tools out there today that can recognize malware that is known about but what Flame and Stuxnet introduce is a way to use the inherent trust of the Internet architecture to allow the introduction of malware to your environment that may not be discovered through those normal processes and checks.
Think of it this way - today people get upset when they discover that you can go on the web and find the "How to make a pipe bomb" instructions. What if you could find the same instructions for a nuclear weapon that was undetectable? A weapon that could be delivered to any city without anyone knowing about it because you inherently trusted the way it was being delivered and there were no tests to check against it? A scary proposition - but potentially not as catastrophic as what can be done with a Stuxnet like attack using the Flame approach to delivery. Think of what could happen if operators could not control the power grid, the water supply chemical composition, the natural gas pipelines or potentially the mechanisms used to transfer funds between banks and brokerage houses. Now imagine that all of those things went wrong on the same day. That is cyber warfare and that is the handbook that can be written with the existing toolkits that are out there today.
But, that is the worst case scenario and things can be done to mitigate the risk. The National Institute of Standards and Technology (NIST) publishes documents which describe the appropriate ways to protect data including what algorithms to use and what policies to have in place. These include things like using appropriate crypto and avoiding algorithms with known weaknesses. Flame took advantage of the fact that not everyone is following these guidelines and for that attack they were able to spoof a Microsoft certificate that used an MD5 hashing algorithm.
So if you want to mitigate some risk look at what NIST has published (start at csrc.nist.gov) to see if there are things you can do better. And remember what one of my colleagues said after Flame was better studied ...
If you want an interesting look at a piece CBS 60 Minutes did on this topic then check out this video.
Now there have been times when I have looked at cybersecurity from the scythe of death perspective. A number of years ago I worked with the US Government on Critical Infrastructure Protection and there you need to look at cybersecurity from that perspective because if you get it wrong very bad things can happen. So over the last few weeks with all of the discussion on Flame and its relation to Stuxnet and other attacks I started to look at what does this mean from the bigger cybersecurity perspective.
Lots of people hear about these malware variants and when you talk to them their first response is "That won't affect me - it was targeted at Iran" or other Middle Eastern countries. The latter part of that statement is certainly true ... but .... let me pull out the scythe here. What Flame and Stuxnet ended up doing was writing a new chapter in the cyber-attackers handbook. Certainly the creators did not intend for this but through some carelessness the Pandora's box of cyber-warfare has been opened and in it is a very powerful toolkit. Note I did not say weapon. What Flame and Stuxnet has provided is an approach to attacks that is unique and inherently difficult to recognize. Certainly there are tools out there today that can recognize malware that is known about but what Flame and Stuxnet introduce is a way to use the inherent trust of the Internet architecture to allow the introduction of malware to your environment that may not be discovered through those normal processes and checks.Think of it this way - today people get upset when they discover that you can go on the web and find the "How to make a pipe bomb" instructions. What if you could find the same instructions for a nuclear weapon that was undetectable? A weapon that could be delivered to any city without anyone knowing about it because you inherently trusted the way it was being delivered and there were no tests to check against it? A scary proposition - but potentially not as catastrophic as what can be done with a Stuxnet like attack using the Flame approach to delivery. Think of what could happen if operators could not control the power grid, the water supply chemical composition, the natural gas pipelines or potentially the mechanisms used to transfer funds between banks and brokerage houses. Now imagine that all of those things went wrong on the same day. That is cyber warfare and that is the handbook that can be written with the existing toolkits that are out there today.
But, that is the worst case scenario and things can be done to mitigate the risk. The National Institute of Standards and Technology (NIST) publishes documents which describe the appropriate ways to protect data including what algorithms to use and what policies to have in place. These include things like using appropriate crypto and avoiding algorithms with known weaknesses. Flame took advantage of the fact that not everyone is following these guidelines and for that attack they were able to spoof a Microsoft certificate that used an MD5 hashing algorithm.
So if you want to mitigate some risk look at what NIST has published (start at csrc.nist.gov) to see if there are things you can do better. And remember what one of my colleagues said after Flame was better studied ...
"Friends don't let friends sign with MD5"
... Tim Sawyer
If you want an interesting look at a piece CBS 60 Minutes did on this topic then check out this video.
Wednesday, June 20, 2012
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
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
Friday, June 8, 2012
Flame Extinguished?
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.
Monday, June 4, 2012
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.
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.
Subscribe to:
Posts (Atom)