Friday, September 08, 2006

Security through Obscurity

This is a follow up to my 'The trouble with NAT' post. I thought I should explain the other aspect to the thread that surfaced as it progressed as it touch on some other very interesting (and apparently controversial) points of view. As I previously explained the original poster of the thread had hit a brick wall in attempting to access a website. If you want to know the full details of why and how you really should read my previous blog entry. If not then read on.

After a while a possible solution emerged to the IP ban. Use an anonymous proxy. There is however a catch with that. Most educational institutions use web filtering software to block certain categories of websites. There's the usual obvious stuff like porn, warez, gambling etc. But most also attempt to block sites that have Trojans/viruses and most relevant for our situation sites that allow users to bypass the filtering. The vast majority of these only filter based on the sites domain or the URL.

This is hopelessly inflexible. Your fighting a losing battle trying to keep up with all the new sites going up on a daily basis. No, a much more sensible and proven method is to filter based on the content of the actual web pages. This how your virus scanner and spam filter works after all! To that end I use a web filter called DansGuardian. It does domain, URL and content filtering plus it can scan for viruses.

However it seems quite a few schools are using inferior systems (and paying for them to boot!). This got me into a little trouble and a few flames. When I pointed out that the original poster could setup a simple PHPProxy based system that would solve his problem my post was moderated. Now as far I'm concerned there really isn't any point.

Not withstanding the fact PHPProxy had been mentioned previously to illustrate exactly the problems I've outlined. I feel that the tools themselves are not to blame. There always will be someone out there who wishes to take freely available information and do something harmful or illicit on their work/school/college network. You just have to prepare your systems as secure as possible and have monitoring systems in place to catch them. Assuming you do then hope your AUP is sufficient to deal with them when you catch them.

7 comments:

Anonymous said...

don't you think though Geoff that it's one thing discussing the inherrant weaknesses of filters vs PHPProxy hosts and yet another pointing out the link between student and solution.

In one thread we're discussing how to deal with handguns, in another we're pointing an angry young man with a target to the gun.

The 'kid' in question wasn't 'all that bad' I suspect, but the question and answer were linked which fuels the fire.

I'm quite happy with our filtering solution - it's open source like yours, and has passed all tests thrown at it in the past.

I believe you've stated that you don't have a solution to the PHPProxy problem, so it looks like here you're pointing to an actual flaw in your own filtering??

Yes of course kids will find this stuff out. They'd have to be very savvy IMO. The vast majority of hacking info out there is hugely inadequate, especially at the knowledge level of your all but very advanced kid.

You think that by publishing security holes more widely that that will help make the situation better. Sorry - I just can't see how that works.

Like in my crappy analogy before, I recon we have a responsibility not to put people at risk - the hacker or the victim. You have a responsibility.

EvilGrin said...

don't you think though Geoff that it's one thing discussing the inherrant weaknesses of filters vs PHPProxy hosts and yet another pointing out the link between student and solution.

In one thread we're discussing how to deal with handguns, in another we're pointing an angry young man with a target to the gun.


PHPProxy is a tool. As with any tool (a gun in your analogy) it can be used or misused. That is not the tools fault but the choice of it's user. Should we ban such tools or should we punish users who misuse them? I prefer the latter.

I believe you've stated that you don't have a solution to the PHPProxy problem, so it looks like here you're pointing to an actual flaw in your own filtering??

Yes I remember the discussion, I think it was this thread wasn't it? Well basically that information is out of date. While it's true the stable version of DansGuardian in most distros does not handle PHPProxy but I have recently been using the Beta version. This does handle PHPProxy correctly.

Yes of course kids will find this stuff out. They'd have to be very savvy IMO. The vast majority of hacking info out there is hugely inadequate, especially at the knowledge level of your all but very advanced kid.

I was one of those kids (poacher turned game keeper if you will). When I was at high school we regularly comprimised the Novell Netware 3.11 system in use. Mostly by social engineering though.

OTOH at Univeristy the same system was in use, but because we were all slogging through a Software Engineering degree we could actually code working exploits for bugs we found. Go look on the net for Netware exploits. A sizeable percentage were written at UCLAN.

No, rather than relying on the ignorance of your users I think relying on the strength of your security systems is key.

You think that by publishing security holes more widely that that will help make the situation better. Sorry - I just can't see how that works.

Simply disclosing a problem does not magically fix it. What does fix it is the admins or manfacturer of systems suffering from the problem reading about it and plugging the hole.

In the situation your advocating the admins or manufacturer of such systems would never know there's a gaping hole in their security. Where as there is always the risk that some unsavory user will discover the hole and exploit it. Resulting in a fools paradise. Where one is blissfully ignorant to the fact that ones entire system security has been comprimised. I for one do not wish to live there.

Like in my crappy analogy before, I recon we have a responsibility not to put people at risk - the hacker or the victim. You have a responsibility.

They are already at risk. There's always another bug, and other configuration error around the corner that blows system security out of the window. We have a responisbility to keep the data safe. If we don't have sufficent information to adaquately do that, we've already lost.

Anonymous said...

I don't think security holes should go unmentioned.

The 'gun' I think is the statement "here's the weakness > here's the method".

Fair enough to state that a compromise is possible. Wrong to point out a method to someone who 'wouldn't otherwise know'.

Ppl who work out flaws as you've mentioned will always have considerable knowledge that underpins thier motives. Kids just looking to break stuff to look good to thier mates have different influences.

- mark
[publishing anonymously because my usual login doesn't work]

EvilGrin said...

Fair enough to state that a compromise is possible. Wrong to point out a method to someone who 'wouldn't otherwise know'.

Could it be proven they didn't know or couldn't find out on their own eventually?

Ppl who work out flaws as you've mentioned will always have considerable knowledge that underpins thier motives. Kids just looking to break stuff to look good to thier mates have different influences.

Your willing to bet your data on your users ignorance then? All it'd take is one of them to get a bit creative and by your own arguement they'd all know about it. Worse still it's unlikely you'd know anything bad had happened.

Anonymous said...

Your willing to bet your data on your users ignorance then? All it'd take is one of them to get a bit creative and by your own arguement they'd all know about it. Worse still it's unlikely you'd know anything bad had happened.

That's all a bit hypothetical isn't it - you bet your data on your ignorance of vulnerabilities you have no knowledge of yet too.

No one, I would imagine, would leave their data unprotected just because they thought - "ah well, people aren't likely to find that out". Well I certainly don't.

Take the Coke machine hack around. Do you agree that it's morally wrong to publish the hacking information? Yes it's there to be found, and it's also the responsibility of the viewer to have responsibility not to do it. But the main point is - it's immoral to make that information public.

If you were on a coke machine tech forum tho' - you'd want to know possible exploits. Maybe you'd do that by scouring the web for postings of vulnerabilities, which would be seen as doing your job [of securing coke machines] well.

The last thing you'd want to be tho' is a repository for coke machine hacks.

Trouble is when talking of IT systems it isn't so clear cut. Some systems are certainly vulnerable and you know that.

It seems to me that what you did was irresponsible. You know that the PHPProxy vulnerability is the one most likely to work/ most likely to be unsecured just yet by most filtering systems. Yet you have no hesitation pointing that out.

EvilGrin said...

That's all a bit hypothetical isn't it - you bet your data on your ignorance of vulnerabilities you have no knowledge of yet too.

You misunderstood what I said. What I was trying to explain is that one is risking ones data's security if one assumes that ones users are unaware of security weaknesses in ones systems. If one is unaware of the current IT security climate, one is simply being negligent to ones duties.

No one, I would imagine, would leave their data unprotected just because they thought - "ah well, people aren't likely to find that out". Well I certainly don't.

That was the point I was making in the original the blog article! But good for you.

Take the Coke machine hack around. Do you agree that it's morally wrong to publish the hacking information?

No, because if you prohibit such things from the public eye they go underground. Then only the bad guys can know about it. This is exactly the situation you don't want.

Yes it's there to be found, and it's also the responsibility of the viewer to have responsibility not to do it. But the main point is - it's immoral to make that information public.

This is down to an indiviual. Do I use this information for my own profit and break the law? I would argue it's the individual being immoral by misusing the information.

If you were on a coke machine tech forum tho' - you'd want to know possible exploits. Maybe you'd do that by scouring the web for postings of vulnerabilities, which would be seen as doing your job [of securing coke machines] well.

I'd also want to know when the coke machine maker is planning on fixing their broken machines.

The last thing you'd want to be tho' is a repository for coke machine hacks.

This is the Internet. Such things always exist. Regardless of it being physical or technological.

Trouble is when talking of IT systems it isn't so clear cut. Some systems are certainly vulnerable and you know that.

All systems are vunerable. The only way to be 100% sure a system is secure is to turn it off, unplug it and encase it in concrete. Such a system isn't terribly useful so we have to compromise. This exposes them to a certain amount of risk. Such risks are hard to quantify but there's several ways of reducing the odds in our favour.

It seems to me that what you did was irresponsible. You know that the PHPProxy vulnerability is the one most likely to work/ most likely to be unsecured just yet by most filtering systems. Yet you have no hesitation pointing that out.

Ad hominem. But I'll bite anyway. PHP Proxy (and other software similar to it) exists now today for anyone to use for the price of a little space on a web server. If I can find out about it and use it effectively what's to stop anyone else? Given the fact it's been mentioned specifcally no less than 58 times (according to Google) on Digg I think i'm probably on to something.

Anonymous said...

Sorry I thought I went a little OTT on that last comment.

Still I think you waffle to avoid the truth! ;)

I'll continue on your new post.