On the Internet, Trust is Fleeting

As further analysis of Flame come to light, one of the most interesting aspects of it comes from the way that it establishes trust. Or, perhaps more accurately, how it appropriated it. Flame was able to make its software packages appear that they came from Microsoft. In recent days, Microsoft has been working to correct the problem by getting patches pushed out as well as taking steps to harden Windows Update from the techniques that Flame used for a Man in the Middle attack.

The process of establishing trust on the Internet relies on a system of certificate authorities that are already trusted by your operating system and web browser. Certificates issued by said certificate authorities are also trusted by virtue of having a chain back to a trusted root. In other words, I’ll trust you as long as both of us trust the same 3^rd party. Microsoft is just one company that maintains a certificate authority. There are hundreds of others around the world.

While public key infrastructure (PKI) has a number of uses, one of the most used applications of PKI has been for server-side SSL certificates and code signing certificates. These are particularly useful because it’s dealing with a one-to-many trust relationship.  An ecommerce site needs to be able to prove that it’s legitimate to all of its users. A company that distributes patches over the Internet can sign the code so all of the recipients know that it’s for real.

While trust is easily given in this method, it’s also very hard to take away. With PKI, you can generate a Certificate Revocation List (CRL) which is a static list of certificates that you shouldn’t trust anymore. It’s a system that’s hard to scale and it’s also not very practical for endpoints because it depends on the host to perform the checks against a list of every potentially bad certificate in existence. If any of you are old enough to remember this, it’s like the books of invalid credit card numbers that merchants used to use before the electronic point of sale became mainstream.

There’s an online method of checking a certificate through Online Certificate Status Protocol, which has a mixed level of adoption by both the endpoint and by certificate authorities. The third method is through software updates, which is used to add a trusted root certificate and can also be used to remove one. All three scenarios could work in a perfect world, but in the real world, it can be actually quite difficult to make a community of users stop trusting a certificate as soon as a risk emerges.

In recent years, there have been numerous cases of dangerous conditions where certificates needed to be revoked immediately. There were issues such the creation of an subordinate certificate authority linked to a trusted root, there’s been trusted certificates issued to an unauthorized party, and there’s been the use of stolen private keys used to sign code, just to name a few. Research into Flame reveals that the attackers took an entirely different approach by using a hash collision to build a code signing certificate chained to Microsoft.

Some people see this as a supply problem, in that owners of certificates need to be proactive about cleaning up the use of weak cryptographic algorithms and keys. Yet as pointed out earlier, on the consumption side, it’s hard to remove trust in a certificate. For the enterprise looking to protect their users, it can be very challenging making sure every endpoint stops trusting a certificate in order to prevent unwarranted trust in a website or code.

Microsoft has issued an update that revokes the certificates that were exploited in this trust relationship, so the right process to remove trust has been initiated on the supply side. Enterprises, however, typically cannot get patches issued to thousands of endpoints on the turn of a dime, and there is a window of exposure between a patch’s availability and the patch being fully deployed. As a result, code tied to the attacker’s certificate could still be trusted, thus posing continued risk of exposure.

This is just one example why enterprise network security plays such a critical role to protecting endpoints. It also highlights a reason why network security should be in place even for mobile users through an always-on remote access connection, as it would be otherwise impossible to patch or protect an unconnected endpoint.

In terms of vulnerability protection, Palo Alto Networks has issued a number of signature updates that detect the presence of Flame, such as the ability to identify Flame’s Command and Control Traffic. More importantly, there are also new signature updates that detect files signed by the invalid certificates, thus providing enterprises with the ability to spot untrusted code even in advance of the installation of the patch or confirmation of the certificate’s revocation.

There’s a lot of talk that’s going on about what needs to be done to prevent the abuses of trust found in the Certificate Authority system. There is discussion about whether changes need to be done to remove trust more quickly. Ultimately, however, enterprises can’t wait for changes in the system to occur, and that’s why it’s critical to have vulnerability protection and network security delivering the means for enterprises to protect themselves.