Analytics
7/27/2007
02:20 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Open Source Bots

With most botnets based on open source, it may be time to rethink just what gets open-sourced

I just got my first major update on the bot problem and it scared the crap out of me. I hadn’t really thought through just how bad this was getting. I use Postini, and this month I've noticed a scary rise in emails that appeared to be generated from bots and were chewing up a lot of my time. (Either that, or I suddenly have thousands of friends I didn’t know about sending me executable attachment eCards. If that is the case, I need to have a long chat with those friends.)

Part of the briefing, which was provided by Symantec, was a discussion of just how advanced the hubs are that manage these massively increasing numbers of zombie computers. Evidently, the hubs are made up of state-of-the-art servers, often clusters, which showcase some of the most advanced systems management tools and skills in the industry.

Some of the botnet hubs that have been discovered and taken out of service would incite major IT envy – not many IT shops can afford what some of these botmasters can afford and deploy.

Much, if not almost all, of the technology being used appears to be coming from open source resources, and probably the secondary market for hardware (though I understand some are just buying the software on the open market). I don’t think there's anything that can be done about the hardware, but I’m beginning to wonder if certain types of tools shouldn’t be in the open source arena.

One of my problems with open source, Apple, or anything backed by huge advocacy groups is the all-or-nothing mentality in the face of substantial evidence that moderation is really best. Take nuclear technology – if we made it readily available so that all could gain access to it and use it, we likely would have more cheap power. But we would also likely become extinct as a race, either from the resulting pollution or from a group of folks wanting to make a big-bang statement.

Restricting Open Source
It's obviously too late for a lot of platforms, but I wonder if it wouldn’t be wise, going forward, to refrain from open-sourcing products and tools that allow for the management and control of large numbers of servers or workstations. The tools needed to manage these large numbers are needed by a relatively small number of people. And given the potential for corrupt use of these tools, this should remain a small group of people.

It's time to think about categories of products that, for the safety of all of us, should remain relatively secret and protected – if only to give the security industry and platform vendors more time to create and distribute more secure products. That would mean any technology that enables the mass remote control of any platform or critical application: These are the master keys, and need a higher level of protection and restriction. There are likely other software offerings where open source is either ill-advised or unsafe, but many do not represent the national, and worldwide, security threat that botnets represent. (And Honeynets, of course, need this code.)

Security 2.0
Symantec, as part of its Security 2.0 initiative, is the only company aggressively looking to the future of botnets and figuring out a way to anticipate and mitigate future attacks. Symantec's new AntiBot appears to lead the segment. (See Symantec Unveils Anti-Botware.) We’ll discuss this offering more in the future, and Symantec’s efforts go beyond this product – into tracking and reporting botmasters and botnets to law enforcement for the sole purpose of shutting them down and bringing the folks responsible to justice.

The war against botnets would undoubtedly be more successful if there were fewer of them in the first place. Limiting access to the open-source technology they are using could go a long way in helping get ahead of this threat.

Another option would be for the open source community to go to war with the people who misuse the code to do harm to others. If that were to happen, folks like me would be less worried about open source and much more supportive of it. But it often seems that open-source advocates don't want to be bothered with this kind of community support activity. There are, however, some efforts, such as the Honeynet Project.

I think that messing up and messing with the botmasters would be a fun pastime for aging hackers who used to have fun doing a little mischief. Given the proliferation of honeypot projects, this may already be happening.

But the best way to beat the botnets is probably a combination of determining what should and should not be open, as well as a community response to the threat of the misuse of open tools. My hope is that we get there before my Postini inbox explodes from overcapacity.

— Rob Enderle is President and Founder of Enderle Group . Special to Dark Reading

  • Symantec Corp. (Nasdaq: SYMC)
  • Honeynet Project
  • Postini Inc.

    Comment  | 
    Print  | 
    More Insights
  • Register for Dark Reading Newsletters
    White Papers
    Flash Poll
    Current Issue
    Video
    Slideshows
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2011-0460
    Published: 2014-04-16
    The init script in kbd, possibly 1.14.1 and earlier, allows local users to overwrite arbitrary files via a symlink attack on /dev/shm/defkeymap.map.

    CVE-2011-0993
    Published: 2014-04-16
    SUSE Lifecycle Management Server before 1.1 uses world readable postgres credentials, which allows local users to obtain sensitive information via unspecified vectors.

    CVE-2011-3180
    Published: 2014-04-16
    kiwi before 4.98.08, as used in SUSE Studio Onsite 1.2 before 1.2.1 and SUSE Studio Extension for System z 1.2 before 1.2.1, allows attackers to execute arbitrary commands via shell metacharacters in the path of an overlay file, related to chown.

    CVE-2011-4089
    Published: 2014-04-16
    The bzexe command in bzip2 1.0.5 and earlier generates compressed executables that do not properly handle temporary files during extraction, which allows local users to execute arbitrary code by precreating a temporary directory.

    CVE-2011-4192
    Published: 2014-04-16
    kiwi before 4.85.1, as used in SUSE Studio Onsite 1.2 before 1.2.1 and SUSE Studio Extension for System z 1.2 before 1.2.1, allows attackers to execute arbitrary commands as demonstrated by "double quotes in kiwi_oemtitle of .profile."

    Best of the Web