Security blankets...

I've been busily trying to catch up on a year's worth of the Security Now! podcast. If you haven't heard of it you should really (REALLY!!) check it out. Twit Networks - Security Now! I've been a fan of Steve Gibson for some time, so I've really been enjoying listening to extended conversations with him talking about how, for instance, the network stack works, or buffer overruns happen, and, consequently, how malicious code manages to take advantage of the cracks in the system. It's also sobering to learn that the pieces we take for granted really are very insecure.

As an example, despite Steve's constant mantra that we should turn ALL scripting off for ALL sites other than those we specifically white-list, I've been refusing to see the light on this one. That may be at least partially because I've moved almost exclusively to Firefox, where, natively, Javascript is either on or off, there is no trusted vs. untrusted site distinction, (although that is fixed by Giorgio Maone's extension called NoScript). But it is also just because it wasn't clear to me that scripting really posed that much of a danger. My machine is patched, I run a good anti-virus, and two good anti-spy/malware programs, all of which I keep updated and scan with regularly. What dangers could scripting really pose?

Well, check out this article from SPIDYNAMICS on Detecting, Analyzing, and Exploiting Intranet Applications using JavaScript. If the proposal that client-side scripting can "turn on wireless networking and turn off all encryption" doesn't send chills down your spine, then perhaps the idea that malicious javascript can essentially port-scan your local network and often fingerprint the services available on it discriminating, for instance, between an Apache and an IIS web server! This can all be done dynamically, and even if exploits can't be instigated at that time the data collected can be sent back to a repository where it could easily be analyzed for later exploit.

So today I'm working on education to go along with the implementation of a whitelisting policy for allowing scripting. I'm sure the troops will all grumble...

For more on how to implement browser security check out Security Now! Episode #38. Also check out Episode #45 on the HOSTS file and why you want to use a pre-populated HOSTS file (like Spybot S&D's) to help avoid malware.

If you're using XP with SP2, according to Wikipedia's article on the HOSTS file you have to disable the DNS Client service in order for the system to use the HOSTS file. According to an MVPS.org article on blocking parasites using the HOSTS file the problem only occurs when the HOSTS file is in excess of 135Kb (theirs is 493Kb!!).

If you haven't been listening to Security Now!, you're only about a year behind so go listen to them all, preferably in order, you'll learn a lot.