The Evils of Default Security (tutorial)

[catch]

After a seven week leave from this site I figured I ought to try and come back with something useful and interesting to remind you all of how much you missed me.

A large percentage of this site and really all computer security forums focus on a single topic: "Which is better (more secure)?" where various people will throw out random biased opinions, unlisted options to show how smart they is, or perhaps even *gasp* relevant facts. Facts are good right? Well, to quote Homer Simpson, "Facts are meaningless. You can use facts to prove anything that's even remotely true. Facts shmacts." As a rule, Homer tends to be not too bright, but his words frequently carry a deeper truth thus he is so lovable. In this case it seems that just because something is a fact, doesn't mean it is a fact in a given situation...

Confused yet?

I speak of default configurations. I can't recall how many times I've come across "X is already hardened, so it is more secure." Operating system like OpenBSD and Windows 2003 both fine examples of tribute to this fallacy. The subject of this tutorial is to demonstrate to the reader that “more secure by default” actually results in a less secure real world system. (How is that for facts shmacts?)

----------------------------------------------------------------------------------------
Part 1: The inadequacies of “hardening”.

Hardening either before or after shipment typically includes but is not limited to the following actions:

• Removing unnecessary packages/applications.
• Removing unnecessary services.
• Stronger default file permissions (removing suid/guid, adding sticky bits, etc)
• Locking down administrative accounts. (Using wheel to limit su, preventing telnet access, etc.)
• Utilizing an intrusion detection system. (Tripwire et al to monitor the system.)

Following this checklist you will have a very secure system right?

Nearly all computer attacks stem from the following six issues stack overflows, access to services, privilege and privileged accounts, networking resources, shared environments, and other bugs in applications and services. Considering this, it should be painfully clear how little hardening does for actually securing systems. Clearly different architectures and mechanisms are needed to deal with these issues as hardening alone is simply not viable.

The next broken BIND, thieving admin, or perhaps that one web application input that was accidentally not validated, just to name a few examples will suffer little resistance from your best hardening efforts.

I am sure many of you were already aware how this type of security falls short, but are probably still thinking that even the paltry security offered by hardening is better than nothing and for the vendor to offer such security by default not only makes your job easier but makes the system overall secure as few attacks happen against it.

----------------------------------------------------------------------------------------
Part 2: The benefits of homogenization. (Important points but a non-definitive argument.)

Nearly all exploits all into one of two categories:
[list=1][*]Configuration error.[*]Otherwise correct configuration but inadequate to provide protection against flawed source code.[/list=1]
The Apache.org root via FTP/Apache/MySQL configuration errors is a fine example of the former while the IIS Unicode attacks of the latter. While it is true that two additional types of exploit exist (source error indefensible by a different configuration and design flaws that have no source issues and cannot be fixed via admin configuration) these have not be included as they make up a very small percentage of real world attacks and because they have nothing to do with the subject of this tutorial.

Let us compare two systems now, one shipped in a soft state (systemA) and one shipped in a hardened state (systemB).
[list=1][*]Any two instances of systemB are likely to exist in the same state, as implementation/administrative intervention is less likely since a “secure” system was purchased.[*]Any two instances of systemA are likely to exist in different states, as post-purchase configuration is needed to bring the system into a secure state.[*]Any single instance of systemA is more likely to exist in an insecure state than any single instance of systemB.[/list=1]
This means, that since systemA is more likely to be insecure, valid exploits are more likely to exist. It also means that an instance of systemA, which has been configured to an equal state of security to systemB, is actually less likely to be effected by exploits than systemB is. Consequently the likelihood of systemB being vulnerable to random threats is greater than systemA existing in the same state. SystemA is also likely to be less vulnerable against specific threats since the exact configuration is less likely to be known by the attacker. Your odds of being the victim of packaged attacks are reduced without patches and the odds of you not seeing a 0-day attack coming are also reduced as a greater likelihood of an attacker error exists.

It is true that a systemB implementer/administrator could alter systemB’s configuration making it less predictable, but this would not only remove any advantages of having a secure by default system it would also play into bigger issues identified in section three.

----------------------------------------------------------------------------------------
Part 3: The costs and consequences of knowledge.

Consider two sand castles, the first already built the second a kit containing your bag of sand, various molds, and a detailed instruction manual. Using the kit you are able to make a sand castle (castleA) exactly like the one already built (castleB), and you do so. Now there are two identical sand castles on the table in front of you.

Depending on how exact you were in the construction of castleA, it is possible to know essentially everything about it. How many grains of sand in the left tower, the exact volume of the moat, if any additional measures are needed so that a base width of X can support a height of Y, etc, etc. If you add an extra doorway into the wall of castleA and you track what exactly you remove, you will know exactly what remains and have a better understanding of exactly how the remains are structured. Less chance for error exists and less requirement for auditing.

This example of sand castles may seem silly, but when compared to information system security it becomes highly valid. If for some reason you need to change the security of systemA, this will be very easy, especially from the default state. An error become obvious as you add security, if something no longer functions that was needed to function, undo the last step. When starting with a system secure by default and functionality needs to be added, errors will not present themselves without an additional security review. Additionally the implementer needs to know far more about the system to make changes. This can be easy with an old system, but to completely learn the number of grains in a system or patch just released… it gets impractical. (I’m not talking source I’m talking roles.) Critical elements may be (and in practice frequently are) inadvertently removed while trying to increase functionality.

In any controlled system it is a simpler task to calculate the effects of the addition of an element rather than a subtraction of one.

----------------------------------------------------------------------------------------
Part 4: What it all means.

Systems secure by default are little more than a marketing ploy, that prey upon users lack of understanding about the actual mechanisms and architectures that go into secure computing. These vendors feel that they will make more sales by selling a product that seems more secure than one that actually is more secure. (Unless you are like OpenBSD and scare all your clients away with your pompousness.) Odds are they are probably right, but that doesn’t mean it is a valid point to consider when comparing two systems.

If you start with something insecure but highly functional, so long as it comes with the tools to lock it down you’ll be ahead in security assurances, costs, time, and the skill level needed by your implementer.

catch

[gore]

Bout time you got back. I thought this was great information. I'm making a request:

Write a paper on OpenBSD and the false sence of security it delivers.

If you have time anyway.

I just thought you made very valid points the last time we argued. It was a damned good arguement too. Both of us presented our proposols, neither flamed, and we both talked about it for a long period of time and made very valid points on both sides. We need a thread like that on here.

And, yes, I am admitting that I learned alot from catch in that arguement, and actually changed my views around on OpenBSD.

[rapier57]

Thanks, catch. That was good. Nice topping to my lunch break today.

You make a number of excellent points that deserve further discussion and expansion.

If you start with something insecure but highly functional, so long as it comes with the tools to lock it down you’ll be ahead in security assurances, costs, time, and the skill level needed by your implementer.

A question at this point may be: "How do we keep the insecure but highly functional systems out of the hands of the incompetent?"



Looking forward to more exchanges with you.

[catch]

Much thanks gore. People who are secure in their knowledge tend to not feel the need to flame so much. (unless they are tired of banging their head against the wall with someone that just doesn't get it.)
I do like to pick on OpenBSD... I might take you up on that... oh the flames I'll receive.

Thank you rapier, I am glad you enjoyed the post. Your question:

How do we keep the insecure but highly functional systems out of the hands of the incompetent?

is a great one.

Actually it is to the benefit of systemA users if the majority of systemA users tend to be lazy and or uneducated. Primarily that it keeps the level of attack sophistocation down. (People won't seek a complicated attack if a simple one likely exists.)
These insecure by default systems that are always getting compromised are unimportant, they are systems that are not used to protect anything worthwhile or the level of attack that occurred didn't effect anything worthwhile. (I wrote about this a while back regarding .gov website defacements.) The end result is an artificially high number of recorded compromised systems.

From my experience, systemB type setups have way way way more compromises of the types that nobody reports. That should be the true measure of a system, sadly companies keep that data to themselves.

catch

[KissCool]

Excellent. I was precisely debating with a friend two days ago about the OpenBSD case and about its default policy. I thought nearly what you exposed here, even if my position was less hardened than yours.

Rapier57> We can't! Light speed, gravity, Plank constant and stupidity are the four major physics constants.

[thehorse13]

This is an excellent post. In fact, it is one of the most well written that I have seen here in quite some time.

Nice to have you back.

[Maestr0]

Good to see you around again Catch. I think you bring up some good points especially about homogenization. While a 'secure by default' operating-system is not an "end-all" solution I think a more accurate description would be 'somewhat more secure by default' (we all know the mantra that security is a process anyway ) I do think these systems do have merits which can give some advantage to the savy admin. And while many attacks will succeed against them many more will be thwarted. Some of the major 6 issuses are addressed in some fashion or another in the afore mentioned OSes. For instance overflows can be somewhat mitigated by Stack protection (present in both the new OpenBSD and Win2k3) and hand auditted code and some appplication code auditing (OpenBSD) and while it is known these can be defeated I think they represent a leg-up on OSes in which this is not present. I think you point out correctly that many people interpret 'secure by default' to mean 'no administration neccessary' which simply is not and will not ever(that I can see) be the case. I think your comparsion to a sand castle is an excellent one but I think core OS that attempts to be more secure at a kernel level is a good foundation for building a secure system but the 'secure by default' system cant be blamed the first time some idiot configures his web server wrong on his box and gets rooted.

-Maestr0

"It is the flawed assumption that security mechanisms can be adequately
provided in layers above the operating system. A perfect security application
cannot make up for flawed or absent security features within the OS kernel.
It is the classic example of building a castle on a swamp. You can build
a strong fortress, but it makes no difference if it slowly sinks into the
ground. "
- Mike Schiffman "The Belt and Suspenders Approach"

[catch]

Maestr0, I think part 3 of my original text is important and not to be overlooked.
Systems that ship in a secure state require far, far more effort to make calcuable changes to the security policy for things such as adding additional services. hence a real world system that shipped "securely" is going to be less secure (lower assurances) that a system that shipped in an insecure state with the same effort (resources).

Also, there is a difference between a system that has a security kernel and one that ships in a hardened state. OpenBSD for example offers no additional security functionality over Mandrake Linux, but people think it is more secure because it ships with a more secure configuration. My arguemnt is that after setting up a real world system, the Mandrake one will have greater implementation assurances and consequently will be more secure for the same efforts than the OpenBSD one.

"the 'secure by default' system cant be blamed the first time some idiot configures his web server wrong on his box and gets rooted."

There is an internet full of documents on locking systems down, there are virtually none on how to open up a hardened system in a secure manner. Are they an idiot, or are they doing the best they can (at a more difficult task) in absence of good/any information?

Very high security systems ship in a least secure configuration and come with a guide on how to lock down each aspect of the system if it is used or not used. this type of compartmentalization is very good and offers a great deal of assurances, but when you start removing security.... god knows what unthought of thing that change may unlock...

catch

[gore]

Originally posted here by catch
Much thanks gore. People who are secure in their knowledge tend to not feel the need to flame so much. (unless they are tired of banging their head against the wall with someone that just doesn't get it.)
I do like to pick on OpenBSD... I might take you up on that... oh the flames I'll receive.

Thank you rapier, I am glad you enjoyed the post. Your question:

is a great one.

Actually it is to the benefit of systemA users if the majority of systemA users tend to be lazy and or uneducated. Primarily that it keeps the level of attack sophistocation down. (People won't seek a complicated attack if a simple one likely exists.)
These insecure by default systems that are always getting compromised are unimportant, they are systems that are not used to protect anything worthwhile or the level of attack that occurred didn't effect anything worthwhile. (I wrote about this a while back regarding .gov website defacements.) The end result is an artificially high number of recorded compromised systems.

From my experience, systemB type setups have way way way more compromises of the types that nobody reports. That should be the true measure of a system, sadly companies keep that data to themselves.

catch

HEHE, as soon as you want to, go ahead on the OpenBSD thing. I think it'll be great fun to make it public this time. That can let ALOT more veiws get added in, and we can FINALLY have something worth replying to about a "touchy subject".

Most OpenBSD users are the one's saying "So, Linux users, how is your system doing? I have updated in 3 months, and it's hard as a rock!"

As for the flames, well, I do flame alot, but I try to do it for humor. I like making people laugh, and basically getting any reaction out of them I can. Most arguements I'v had publicly here were pretty much a waste of time as either I would loose my cool to fast and be at fault for being an ******* and flaming, or the other side would lay down a line that satisfied them, sounded good, and solved nothing.

You on the other hand, never went into flaming with me, we had our arguement over a long period of time, and we both made our points and talked about them, and I think we should do it publicly when you have the time to start your post on Open BSD.

Only recent time I'v argued a good well thought out arguement, was the other day on IRC with Pwaring, and Syini666.

We argued about drug laws, and we all plan on doing it again. Why you may ask? Because it was damned good fun, and both of them probably have a respect for me now they may not have had because none of us flamed, none of us used name calling, and we showed RESPECT for others feelings and ideas.

We argued for a while untill I had to leave but we agreed on doing it again. Heh, funny huh? We argued and WANT to do it again. Most people argue, and never want to speak to the other person again, while we are looking forward to it.

Catch, you need to stay back now, I havnt had any good argueing besides on IRC, in a long time, and you're one of the few willing to give me the chance to say what I feel and respond to it. Besides, you're one of the only members to ever change my mind about OpenBSD

SuSE Linux you have hardly a chance in cold bloody hell at changing my mind about, but I'd listen to you first at least....Hmm, want to have a discussion about SuSE Linux too? I'm looking forward too a damned good arguement with you man.

[chsh]

I was curious as to what your other positions on operating system security were, so I looked at some of your posts, and this is pretty well the best one it seems...

Originally posted here by catch
I speak of default configurations. I can't recall how many times I've come across "X is already hardened, so it is more secure." Operating system like OpenBSD and Windows 2003 both fine examples of tribute to this fallacy. The subject of this tutorial is to demonstrate to the reader that “more secure by default” actually results in a less secure real world system. (How is that for facts shmacts?)

Without facts to back you up? I find that somewhat amusing. Yes, let's not let little facts get in the way of our making our point shall we?

Nearly all computer attacks stem from the following six issues stack overflows, access to services, privilege and privileged accounts, networking resources, shared environments, and other bugs in applications and services. Considering this, it should be painfully clear how little hardening does for actually securing systems.

Oh, so what you mean to say is that the process of removing unneeded accounts, trimming down your user's access capabilities, jailing processes so that if they happen to be exploited system-wide access isn't guaranteed, and removing setuid binaries does nothing for actually securing a system? I want to make sure I get that right, since that's what you wrote and all. Wouldn't want to be confused about something like that.

The next broken BIND, thieving admin, or perhaps that one web application input that was accidentally not validated, just to name a few examples will suffer little resistance from your best hardening efforts.

You have evidently misunderstood the entire purpose of hardening your system. If you have some childish preconceived notion that hardening a system is done to prevent software vulnerabilities from happening, you possibly need to read a FAQ on the subject.

I am sure many of you were already aware how this type of security falls short, but are probably still thinking that even the paltry security offered by hardening is better than nothing and for the vendor to offer such security by default not only makes your job easier but makes the system overall secure as few attacks happen against it.

It does not fall short. It does exactly as advertised. That you are delusional and believe the hardening process is advertised as the be all and end all of security is not the responsibility of those who point out their OS is secure. You should seek some kind of understanding about the situation, rather than assuming you know what you're talking about when you actually evidently don't.

Nearly all exploits all into one of two categories:
[list=1][*]Configuration error.[*]Otherwise correct configuration but inadequate to provide protection against flawed source code.[/list=1]
The Apache.org root via FTP/Apache/MySQL configuration errors is a fine example of the former while the IIS Unicode attacks of the latter. While it is true that two additional types of exploit exist (source error indefensible by a different configuration and design flaws that have no source issues and cannot be fixed via admin configuration) these have not be included as they make up a very small percentage of real world attacks and because they have nothing to do with the subject of this tutorial.

Yes, actually, I find it funny that you categorize the other two as being unimportant when they are indeed the actual flaws responsible for the Windows XP exploits/flaws as well as basically ALL of the IIS vulnerabilities. Since you are evidently also not a programmer (which leads me to wonder, who are you to speak of any authority on such matters), you also don't seem to get that the second option you list above, is indeed the same as the third and fourth you mention. Basic design flaws are still 'flawed source code'. I like how you're vague enough to fool people but can't be precise enough to show you know something.

Let us compare two systems now, one shipped in a soft state (systemA) and one shipped in a hardened state (systemB).
[list=1][*]Any two instances of systemB are likely to exist in the same state, as implementation/administrative intervention is less likely since a “secure” system was purchased.[*]Any two instances of systemA are likely to exist in different states, as post-purchase configuration is needed to bring the system into a secure state.[*]Any single instance of systemA is more likely to exist in an insecure state than any single instance of systemB.[/list=1]

And where is the proof of this? How can we not know that two instances of System B are more insecure because of something they are both doing (under the guise of homogenization) where the two instances of A are more secure because of their differing roles. If you look at it logically, it favours A actually:
Examplis Gratis:
System A1 runs a buggy webserver while System A2 runs only mail services.
System B1 and B2 run a buggy webservers.
Exploit comes out affecting said buggy webserver. 100% of System B machines will be affected, while only 50% of system A machines will be, due to diversity of services. So where is your logic that A (non-homogenous) will be worse?

It is true that a systemB implementer/administrator could alter systemB’s configuration making it less predictable, but this would not only remove any advantages of having a secure by default system it would also play into bigger issues identified in section three.

Having played quite a bit of the intrusion game myself, I can unequivocally state you are wrong in your assumptions about attacker methodologies.

[..snippage of inane and utterly useless example..]

Part 4: What it all means.

Systems secure by default are little more than a marketing ploy, that prey upon users lack of understanding about the actual mechanisms and architectures that go into secure computing.[/b]

Indeed, that would be why those facts state otherwise (damn, knew those pesky things were going to come up once in a while). The truth is, 'secured by default', while definitely a marketing tool, is also a truth. Slackware and OpenBSD both have excellent security track records, since they don't enable anything by default. Secure by default and 'hardened' are not the same thing, which is yet another concept you seem to have failed to grasp. Secure by default is simply a way of securing the system from remote intrusion attempts by not having services starting up by default. Until OpenSSH, I believe both OpenBSD and Slackware had a perfect security record in terms of remote security.
I suppose given your opinion, everyone is MOST secure if they run out and install WinXP Pre-SP1, since any default security seems to be a waste.

These vendors feel that they will make more sales by selling a product that seems more secure than one that actually is more secure. (Unless you are like OpenBSD and scare all your clients away with your pompousness.) Odds are they are probably right, but that doesn’t mean it is a valid point to consider when comparing two systems.

Yes, it is a valid point to consider when comparing two systems. It sounds mostly to me like you just don't like being told you don't have a secure system by people who do. Indeed, that is your perogative to be cheesed off about it, but honestly, this diatribe of half-truths and outright falsehoods needed to be pointed out. The only reason you got any greenies for this is because evidently nobody was around to point out the utter flaws in this. Not only that, but why this is a tutorial I don't even know. It's an opinion essay, a very poorly researched one at that. Of course, there are those damn facts again eh? Why should you actually have to research something to believe you're right?

It saddens me to see that the level of technical expertise has fallen off so drastically that catch here is regarded as an 'expert' by some. He has a LOT of learning to do, and perhaps some decent discussion can be had after he lands a job (if) and gets bit by his idiotic practices.