YACSW (Yet Another Client Side Weakness)
The recent Microsoft advisory MS05-053 is yet another client-side weakness. This is a trend that has been happening for quite some time - remember Sept 2004's MS04-028 jpeg image vulnerability? Why does your adversary want to enter via the client and not the server? Will we see more of less of this in the future? Is it specific to Windows or will other clients be scrutinized for weaknesses? These are valid questions asked by a reasonable person and deserve an adequate answer. Don't you just love using the words 'reasonable' and 'adequate'? Makes you feel so.....so legal. :-)
In my humble opinion, I think that the trend will continue and in fact, I think it will be the main focus of organized crime.
TARGET RICH:
Lets just go with the numbers. On any given network, do you think there are more active clients or active servers. Ding ding ding, clients is the right answer. If your objective is to comprise as many computing resources as you can in the next 24 to 48 hours, the dominant strategy is to focus on clients.
Old: PUSH EXPLOIT New: PULL EXPLOIT
SP2 Firewalls, Stack-based firewalls, network based firewalls are very effective at mitigating an active attack to your servers active TCP or UDP socket. They have a near zero chance of adding any value when the client on a network is sucking down the exploit. Firewalls do well with PUSH exploits and fail with a PULL exploit strategy. As long as the content is able to carry a method to exploit a weakness in the client, sounds like a dominant strategy to me.
BANK ROBBER WISDOM: Willie S.
When bank robber Willie Sutton was said to be asked the question "Why do you rob banks?" His answer was "Because that's where the money is". Sutton denied ever saying it. Regardless, we can humor ourselves with this updated version:
When organized crime was asked "Why do you hack client-side applications?" Their answer would surely be "Because that's is where the intel is". "Intel"? I am not talking chips. Why go after the big servers that are guarded really well when you can just go after the thousands of clients out there and steal their identity. This identity intel yield a high price (depending on its quality) on the black market. If you don't know how real Identity Theft is, you have been in suspended animation too long. Think about it: it is more important for them to gain access and control to the client infrastructure than the servers at this point in the game. At a strategic level, this is the same logic behind the value proposition of GRID computing across desktops where the leaves when connected together in a sufficient manner far exceed any resources the trunk could have offered.
So, are we going to have to deal with more client-side vulnerabilities? Yes.
Will Desktop Operating Systems have to change to confront this trend? I think so.
Do you have to run Microsoft? Maybe.
If we take that last phrase and redefine the word 'run', I think we can address what I consider to be a logical error in the client-side design. A paradox.
A PROBLEM CANNOT BE PROPERLY RESOLVED AT THE SAME LOGICAL LEVEL IT WAS CREATED.
Kurt Godel, Albert Einstein, John Boyd, Gregory Bateson, and many other great thinkers have said in one way or another that certain problems cannot be resolved at the same level they originate. If you apply this to our client-side problem, you will also see that there is a similar paradox. Once the client has been compromised and the adversary now has complete control over that computing base, ALL security related detection, auditing, and any type of safeguard must be also not trusted since the underlaying computing base is not to be trusted. I call it the Paradox Host-Based Security Measures: How can the computer detect it has been compromised when as soon as it has been compromised the ability to detect it has been compromised can no longer be trusted?
I can't leave you without an answer. Although a brief one, the answer is vitualization. The security controls for the OS must live at a higher logical level. Security measures must exist outside of the world in which it is providing services. We have to return to the roots of "The Theory of Logical Types" which says that no class can be a member of itself; that a class of classes cannot be one of the classes which are its members. I can go on and on about this but you get the idea.
I hope this offers from food for thought in a field that is just obsessed with bits and bytes.
--tk
Comments (4)
Great post and food for thought.
But, doesn't this just move the problem from the OS to the security layer--which would then become the new target of attack? How would you mitigate threats against the securty layer itself?
Posted by Aneel | November 10, 2005 6:24 PM
Posted on November 10, 2005 18:24
Aneel,
I think what tk is driving at is the fact that decoupling service security from the services themselves is the best ... no, *only* means by which you have any hope to successfully manage security in an enterprise environment. It's the same old "if administrator is comprimised and the administrator account can clear security logs, then there will be no evidence of actions in the logs except for the last 'clear security log' action."
The theory of logical types is all about the need to recognize certain classes or types as necessarily distinct from one another. Without class or type distinction, a paradox arises ...
"To consider the set of all sets which are not members of themselves. Such a set, if it exists, will be a member of itself if and only if it is not a member of itself." Sounds like Philosophy hocus-pocus, but it highlights the need to recognize distinct classes of things to avoid vicious cycles in logic.
To apply this to the security log example above, this vicious cycle would be addressed by treating security log access management as a distinct type from other administrator permissions, and to further enforce by policy that a single user account could not have both roles assigned to it. There is more detail required to fully explain, but I'm sure you get the point.
By decoupling service security from the services themselves, we can *greatly* complicate the process of exploiting both components. Moreover, with service security treated as a distinct type or class (and with a narrow focus of what it does and how much human interaction it requires) we can apply *much* more strict controls on the security component without facing the usability impact of tighter controls.
I suspect that this is similar to what MS had in mind, for example, when they introduced the Schema Admin role with AD instead of extending those privileges to Domain Admins. Even if they had only granted these permissions to Domain Admins for the root domain, there was no need for a single user account to perform the tasks of Domain Admin and Schema Admin. They were probably after the same kind of thing when they created Account Operators and Server Operators. Problem is, everyone just made themselves Domain Admins.
Until our friends in the OS and Enterprise App space realize that the current standard security model is subject to this paradox, they're kidding themselves and their customers that their services constitute "trustworthy computing".
It's also a fact that today's Identity Management solutions are powerless to address Identity Theft in any meaningful way. As tk points out, the problem cannot be solved (or even addressed) within the same class that is the target of attack.
Posted by sheldon_malm | November 18, 2005 9:49 AM
Posted on November 18, 2005 09:49
Aneel,
I think what tk is driving at is the fact that decoupling service security from the services themselves is the best ... no, *only* means by which you have any hope to successfully manage security in an enterprise environment. It's the same old "if administrator is comprimised and the administrator account can clear security logs, then there will be no evidence of actions in the logs except for the last 'clear security log' action."
The theory of logical types is all about the need to recognize certain classes or types as necessarily distinct from one another. Without class or type distinction, a paradox arises ...
"To consider the set of all sets which are not members of themselves. Such a set, if it exists, will be a member of itself if and only if it is not a member of itself." Sounds like Philosophy hocus-pocus, but it highlights the need to recognize distinct classes of things to avoid vicious cycles in logic.
To apply this to the security log example above, this vicious cycle would be addressed by treating security log access management as a distinct type from other administrator permissions, and to further enforce by policy that a single user account could not have both roles assigned to it. There is more detail required to fully explain, but I'm sure you get the point.
By decoupling service security from the services themselves, we can *greatly* complicate the process of exploiting both components. Moreover, with service security treated as a distinct type or class (and with a narrow focus of what it does and how much human interaction it requires) we can apply *much* more strict controls on the security component without facing the usability impact of tighter controls.
I suspect that this is similar to what MS had in mind, for example, when they introduced the Schema Admin role with AD instead of extending those privileges to Domain Admins. Even if they had only granted these permissions to Domain Admins for the root domain, there was no need for a single user account to perform the tasks of Domain Admin and Schema Admin. They were probably after the same kind of thing when they created Account Operators and Server Operators. Problem is, everyone just made themselves Domain Admins.
Until our friends in the OS and Enterprise App space realize that the current standard security model is subject to this paradox, they're kidding themselves and their customers that their services constitute "trustworthy computing".
It's also a fact that today's Identity Management solutions are powerless to address Identity Theft in any meaningful way. As tk points out, the problem cannot be solved (or even addressed) within the same class that is the target of attack.
Posted by sheldon_malm | November 18, 2005 9:57 AM
Posted on November 18, 2005 09:57
Sheldon, thanks for the explanation and examples! I see the value, now. :)
Posted by Aneel | November 22, 2005 8:48 PM
Posted on November 22, 2005 20:48