Neil's News

Security Separation

18 June 2005

[I'm starting to get a fair amount of feedback from OU staff and students. It seems that my pages discussing OU courses all currently outperform the Open University's own pages in Google. Oops. I didn't intend to speak this loudly. Mmm, Google-juice...]

The chair of the OU M886 security course found my earlier comments and asked for suggestions for improvements. My suggestion is to re-examine the concept of separation.

Many disciplines suffer from "Physics envy". In the physical sciences one quickly learns that breaking a problem down to its simplest levels makes things consistent and predictable. When analysing how a car crashes, one first studies how metal deforms, now glass breaks, and how tires skid. Add all the pieces together, and one gets the whole picture.

This security course attempts the same thing. In order to deal with an organisation's security, each threat is identified, assessed, and (optionally) treated. Since one can never treat every possible threat (are you prepared for exploding pigeons?), the threat assessment step is key to evaluating what must be treated and what is too trivial or unlikely.

Individually assessing each threat works -- as long as the threats are individual. Separation of all systems is assumed. But in the real world this separation is often an illusion. It is common for white-hatters to claim that if the public web site and the internal systems are on separate servers, then an attack on one would not compromise the other. As any competent black-hatter knows, that kind of thinking works in their favour.

Let's assume that one has just compromised a server. Let us count some of the ways by which one could leverage that exploit in order to obtain access to a related server.

• Locate an email account on the cracked server and use it to request a password change for a related account on the other server.
• Write a Trojan horse which monitors passwords. Ideally the passwords for one server won't work on another server, but in reality they often do. Even if they don't, watch for failed password attempts (how many times have you typed a valid password into the wrong server?).
• Switch the network to promiscuous mode. Start sniffing traffic on the local network. The next unencrypted login is your ticket to another computer.
• Use (what should be) inside information gleaned from the cracked server as a basis for impersonating a valid user (or administrator) and obtaining access elsewhere.
• Does the cracked server host any DNS records? If so, those machines are now at your mercy.
• Is there a "special relationship" between the two servers? An obvious one would be a password-less login from one to the other. A less obvious one would be some form of data-transfer which could be hijacked. If the servers talk to each other at all, then there's always going to be an opportunity here.
• If all else fails, the cracked computer is probably an ideal location from which to launch a DoS attack. First, it's probably nearby the target computer. Second, it would cripple two computers in the organisation (plus their internal network) at once. If the cracker is clever, it could even be made to look like an accident or an inside-job.

This is the fundamental fact which the course misses: Crackers work by using each exploit as leverage for the next. The first exploit may be minor and of no significant consequence. As might the second exploit. Combined, they may allow the cracker to open a third exploit, one which was determined to be too improbable to be worth treating. Next, the cracker moves on to exploits which aren't even listed in the security management plan.

A few years ago a co-worker and I noticed an utterly trivial error in a guestbook. Not too long after we had root access (penetration testing is part of the job^[?]). All done one very small step at a time. That incident taught me that separation of systems and inside defences aren't worth much. It is all about getting that first toehold, that first nearly worthless exploit. The rest is just a matter of time and patience.

Dr. Hall replies:

If the course 'M101: How to defeat the gifted hacker' missed this, it would be a real problem. But M886: Information Security Management doesn't miss this at all, it intentionally omits it. The course is about normal design for security and most attacks do not come from gifted, original hackers, i.e., they do not need to be handled by radical design practices. Most attacks come from those sitting on the shoulders of these hacking giants: they do not have the gifts the giants have, nor the ability to reason in the way giants do. For every giant there are a million script-kiddies. Against script kiddies, Information Security Management provides fit-for-purpose solutions.
Perhaps I will write "M101: How to defeat the gifted hacker" with your help someday.

I guess I was expecting that a post-graduate security course would be able to handle more than just script-kiddies.

< Previous | Next >