Seven Security Blankets and I'm Still Short-Sheeted

Sunday, July 17, 2011

Kevin McAleavey

Note: This is the fifth in a multipart series on the history of the antivirus and security industry by a long time insider (Part One)(Part Two)(Part Three)(Part 4). We will explore how antivirus and antimalware technology works, and why a 1980's solution is no longer applicable to the current threat landscape. The series will conclude with solutions and recommendations on where we might all go next.

In our continuing drama so far, I've explained the failings of antivirus and operating systems in protecting the end user from various and sundry evils. A job that they all did pretty miserably, even in the early days when all they were up against were kids and pranksters. As the end user caught on to the fact that all of the shiny antivirus technology that supposedly kept them safe really wasn't up to it.

"Security experts" on websites assured them that adding more chotchkes to their computer would fortify their digital castle. Having fallen victim repeatedly to ever-increasing numbers of malware, users were assured that "defense in depth" or "layered security" would ride in on a white horse and save their small town.

End user "layered security" in practice turned out to be very different from what professionals knew that definition to be in server farms and corporate structures since professional equipment and software was beyond the price range of the consumer. And yet, consumers were lead to believe that inexpensive solutions could bring them the same safety and assurance that the "big boys" enjoyed.

The first thing that the average user was aware that they needed was a firewall to stop Windows File and printer sharing from being attacked on their personal networks. And so they bought Zone Labs' "ZoneAlarm" and similar products which were touted by sites like GRC which offered an online "Leaktest" (and don't forget to wear your "nanoprobe!") as a particularly effective way of selling ZoneAlarm in particular. I've known Steve since the "Spin-Rite" days and his shilling was embarrassing but necessary at the time.

Anything that moved popped up a big red-colored alert with loud noises and big red letters shouting, "ZOMG! You're under attack! PING detected!" instead of just dropping the packet quietly like a real firewall. And heaven help your screen if there was a routine inbound scan to see if you had NETBEUI lit. The invasion of Normandy was nothing compared to the fireworks that went off if that happened. And that just ramped up the paranoia level among those who didn't know what any of this really meant and had firewall software flying off the shelves faster than you can say "antivirus."

Consumer Firewalls were extremely "noisy", frequent and got annoying fast. On a network connection where there were gamers on the segment, firewalls would go off like a pinball machine filling your screen with so many alerts, you couldn't find your browser. They were like those early gag trojans that would fill your screen with Message boxes that you couldn't close fast enough. So many warnings in fact that users quickly got used to not even reading what they said before clicking them closed.

Soon other "firewalls" appeared, offering "outbound" protection as well as blocking incoming ports. These latter "outbound" based firewalls required the use of "kernel notification hooks" (I'll get back to this in a while) in order to intercept executables about to start running and delayed them in order to pop up an annoying message each time any program attempted to "connect to the internet" including system programs, browsers, and all those programs "phoning home" to check for an update, multiplying the number of "alerts" exponentially. "ZOMG! Port 80 is taking heavy fire!"

Of course when a rogue program triggered these alarms, the user ended up automatically clicking on "ALLOW" anyway because they believed that whatever they had just started, triggering the alert, was going to show them the porn that they wanted to see in the first place. Eventually it got so bad that many firewalls allowed the user to click a button to "save" the settings for programs they trusted and in doing so, opened up a security hole because early firewalls couldn't detect changed programs at first and trusted that the user made the correct guess as to what they should do. Ah yes ... "ask the user, TRUST the user."

As "firewall" technology matured and the noise got out of hand, most "firewalls" added to the problem by adding a "learning mode" which allowed pre-existing malware the ability to skate by detection because ... well ... it was already there. Besides ... if they said no to an unknown program, their system wouldn't boot anymore, so they learned to just accept everything they saw listed.

And so firewalls were the start of short-sheeting security in the hands of technically "unsavvy" computer users. Except of course for detecting pings and scans and setting off the klaxons and popups. That they still managed to do successfully. And they produced copious logs which users reveled in comparing the sizes of, taking great pride as they filled their hard drives.

An even earlier "gotta have" for "layered security" was a "cookie cleaner." I'm proud to have been the first to market with an overall privacy solution that cleaned everything a browser left behind in our "NSClean" product (and later "IEClean" when Internet Explorer first emerged) back in 1996. Many copycats followed over the years, and a "cookie cleaner" was considered an important part of "privacy protection."

And as antiviruses failed to deal with trojan horses, we created "BOClean" to deal with not only those, but BHO's and other "spies" of all kinds brought about by the intrusion of advertisers into prople's privacy including such annoyances as "toolbars," "Browser Helper Objects (BHO's)" as well as malware. Other "antitrojan" and "antimalware" products emerged as well in this space, with some attempting to define a new word, marketing themselves as "antispyware" which "stuck" in the minds of further panicked consumers. This layer too became part of the defacto "layered security" recommended by popular security forums and blogs.

Another popular "layer" included replacing the original Windows "HOSTS" file with widely distributed replacement HOSTS files which redirected known rogue sites to on Windows computers. Some were updated regularly, and some were issued by rogue sites in order to prevent antiviruses and other programs from updating themselves by redirecting the updates to as well. Content-filtering software performs similar goals, but is rarely updated quickly enough to catch all rogue sites. Still, better than nothing.

"Security" forums and columnists routinely advised their technically-challenged readers to try the flavor of the week, including some really squirrely niche products in a haphazard mix and match fashion. Most computers came with an antivirus and some additional "free trial" products preinstalled and often expired by the time they first turned on their shiny new machine. And even if the "free trial" products functioned for a while, they eventually expired and were ignored by the user who believed that since they came with their computer, they were somehow still working, the expiration notice dismissed like all the other popup noise they had become conditioned to just ignore.

Earlier, I mentioned "Kernel notification hooks." In order to detect when a new process or thread is created in Windows, the ONLY way that can be done is by writing a kernel driver for your security program. You then have to trap kernel calls named "PsSetCreateProcessNotifyRoutine" and "PsSetCreateThreadNotifyRoutine" for which a "callback" is required to notify your antimalware/antivirus/firewall/whatever.

But there's a problem. In Windows versions prior to XP, there were only four "teats" available in the kernel. In XP, this grew to eight maximum. I believe it was also limited to eight in Vista and beyond as well, but I got out of it by that time. And Microsoft ate at least one of them prior to their MSE and other add-ons since after all, it was their kernel. And owing to the random firing of kernel drivers at bootup, it was musical chairs as to who won a teat. But Microsoft always got theirs first though.

The Problem of course was that since you had to have a kernel driver installed to be notified, any previous kernel drivers from no longer used products also had to be removed or the chances were very good that there would be no room at the inn for the next security program that was installed to get a teat. And with old cruft still there and never uninstalled, and more junk wanting to add their own, often well-written security programs came up empty-handed for notification.

With our BOClean product, we had a fallback position of doing process, thread, library and memory scans every ten seconds anyway. Most others didn't bother and then sat silent, oblivious to any new rogues starting. This issue caused antiviruses, firewalls and spam stoppers to fail and it appears that many of their designers never saw this coming.

And of course there were the adventures of fights between firewalls and the one built into Windows over who stopped whom. Same between antivirus and antimalware software, which is why we designed BOClean to be "second string" after the AV failed and just waited our turn with a design philosophy of "second chance to win", letting the AV have credit for the takedown if it noticed. We waited for malware to try to execute in memory after file scanning was done.

Then the "wisdom" of the industry turned to bringing together all of these elements into "security suites" so that a common kernel driver could be used for all of the necessary additional "features" that users wanted. But the bigger problem was that some companies were OK with their antivirus but their firewall chewed, others did a firewall OK but had no clue of how to do an AV.

None of them made a decent "suite" and there were serious compatibility problems if you wanted to augment a really bad suite with another product that filled in the gap adequately. And having two or more AV's on the same machine brought about a real life game of "Battletoads" where nobody won.

With Vista, Microsoft then upped the ante of alerts and irritations with UAC. More alerts to irritate and be dismissed without even looking at in the first place, resulting in even more malware being installed by the end user exasperated with their "layered security" and trying to find any way possible to defeat it and just "use their computer."

Silence is golden, but nobody in the business was playing that. Silence is bad marketing: Means your stuff doesn't work. And it's bad security too because the end user is the "brains" behind the protection.

One of the brightest lights recently in the "Windows mess" is executable control and "whitelisting." Only the applications approved are able to be started on the client computer. Attempts to install or run anything not on the "known good" list will fail. Sounds pretty good indeed. Only problem is that the bad guys are already ahead of this one too. And in consumer whitelisting, vendors and software are frequently vetted poorly.

Attackers depend on your "trusted" apps to have an exploit that hasn't been patched. They crash through memory and then "inject" a module directly into memory which then executes anyway without any file that those "kernel driver hooks" are going to spot because the injection is not a process and therefore isn't stopped. This trick dates back years, and if they inject kernel shellcode and drop a small rootkit, it will bypass any such programs that run in userland to allow their rootkit to run a new process irrespective of your whitelist. Whitelisting is better than anything else of course, but not a panacea either. Remember, the enemy is well financed now.

Client-side "layered security" is a mess. It fails because people are so irritated by all the alerts that they don't understand and so they just click through them anyway. They no longer trust their security arrangements to begin with. And when they go and visit a site that offers them a rogue antivirus and no alert pops up, they're going to let it run for a "second opinion."

I've heard this way too many times from people whose machines I've had to clean up or try to save their data from before nuking it. "I wanted a second opinion because the XXXX I have on here sucks." Worse, users try to disable as much of it as they can because all this cruft noticeably slows down their machines.

Many institutional administrators go through a lot of effort setting permissions and policies when rolling out client computers as well. End users will go out of their way to hit up Google or forums and find a way to change those because they will install what they want to and information on how to do that takes only a few minutes and a few downloadable tools to get around your registry permissions and settings. I learned this years ago. Whatever you set, they will defeat it even if they can't remember their own password.

Once upon a time, security software was used after an infection was suspected. And its primary purpose was to thoroughly clean a mess and restore a system to "pristine condition." Over time, "cleaning" fell by the wayside in favor of "prevention" at a substantial loss of "cleaning" effectiveness. Our "BOClean" product had the word "clean" in it for a reason. When BOClean removed malware, it thoroughly cleaned up the affected machine to a "pristine" state. Silly us, we thought that was the entire objective.

"Prevention" has similarly failed because of the failure to add detection in a timely manner. Without "cleaning," the only way to deal with malware today is to exert vast amounts of time and effort attempting to preserve important data from infected machines before going through the labor-intensive process of reloading or reimaging infected computers. This in turn has far exceeded the cost and value of security software in the first place.

All because the security software industry has done the final farming out of end user security management: to the end user, who of course knows the correct decision at all times. Oh. And they didn't read that alert either. Had Microsoft and the antivirus industry done it right in the first place, we wouldn't be here in all likelihood. But here we are nonetheless.

In our final article, let's see how we can fix this ...

(to be continued)

About the author: Kevin McAleavey is the architect of the KNOS secure operating system ( ) and has been in antimalware research and security product development since 1996.
Possibly Related Articles:
Viruses & Malware
Information Security
Antivirus Trojans malware Rootkits Trust White Listing
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.