Trust is the New Attack Vector

OK it may not be the "new" attack vector but it has become a popular one to exploit.

So what does one mean when they say "trust is an attack vector". Lets go back to the simplest ways that have been used to garner information about people or companies - the phone call. Your office phone rings and when you answer it the person on the other end immediately starts talking in terminology that you are comfortable with and dropping names of people in your organization. At this point a majority of people will drop their guard, at least to some level. If the questions start to get more and more deep into information that you think this person, who you have begun to trust, should know then the guard begins to go back up. This is the simplest form of the "trust attack vector" and we commonly refer to it as social engineering.

In the electronic world it is a bit different as there is no person to interact with and secure protocols exist so we know the entity we are dealing with ... or do we. Over the last couple of years there have been a number of attacks that utilize this assumed trust to deliver malicious payload by doing much the same as the "social engineer", that is they provide enough information that allow the process that they are dealing with to trust the transaction. In the online world that first trust transaction will usually involve you getting in the door of the system or application.

So how does this really work? Trust in the online realm is based around a shared secret or a cryptographic operation - either I have a password to use or; there is a common shared cryptographic key or a public/private key pair that is used to establish the transaction. More and more systems are utilizing the cryptographic option since passwords can be directly attacked and are hard to share when that is needed (of course symmetric key distribution can also be a challenge but that is a side conversation). So today many servers and applications use private/public key pairs to establish trust. These key pairs are used to establish secure channels such as SSL/TLS or IPSEC tunnels. Symmetric keys are commonly used to establish SSH connections. If these systems are properly configured and use strong algorithmic choices and key sizes the cryptographic aspect is very difficult to attack. In reality the cost of the attack is not worth the value so attacking the cryptography is rarely seen (exceptions are in cases of weak crypto such as seen in the Flame attack). So instead an attacker will go after a system to gain access to the keys themselves. This can be done by going after the Registration Authority that is the interface to key issuance (Comodo attack) or hack into the system using other attack vectors to gain access to the keys to the process that uses the keys to sign data (Adobe attack). Once they have this access then they can generate attacks against other systems.

A recent example of this is the Bit9 attack. Recent data suggests that the attack was initiated with a SQL injection attack against an internet facing web server which had been turned up with an old certificate. This attack planted a root kit that was signed by a stolen certificate. Once inside Bit9 the attackers used Bit9's signing keys to sign their own malware. Bit9 customers that were targeted would believe that the code they were executing was trusted as it was signed by the Bit9 keys. of course this is just one example of keys and certificates being used to obfuscate the trust chain.

So trust is being used as an attack vector- what can be done about it? There are a number of things:

1. Know what is in your network when it comes to the trust infrastructure. This means:
1. Know what certificates and keys are being used and why
2. Ensure that cryptographic assets that are used in your environment meet your policy for strength, lifetime and algorithmic uses
3. Ensure every cryptographic asset has an owner assigned to it and that you can keep that data up to date
2. Clean your Root stores. In any organization you will have a variety of Root stores. These Root stores are used by applications and the operating system to help build the trust chain. The reality of the situation is that off-the-shelf Root stores delivered in applications and operating systems has many more Roots installed than you will ever encounter. It is important for an organization to trim down those Root stores and maintain oversight of them to ensure that Roots that should not be in the stores are not introduced or re-introduced.
3. Maintain a central view of the trust environment. The two pieces above can, in themselves, be challenging so it is important that you have central oversight of the environment, be able to recognize changes and then react accordingly.

As I have always said, there is no silver bullet for security other than disconnecting all external communications and interaction from a box. Outside of that the best actions are those that mitigate risk and two important steps to mitigating risks are knowing what is in your network now and knowing what gets introduced into your network. This is especially true when it comes to trust.