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
    Cartoon
    Current Issue
    Video
    Slideshows
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2012-3946
    Published: 2014-04-24
    Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

    CVE-2012-5723
    Published: 2014-04-24
    Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

    CVE-2013-6738
    Published: 2014-04-24
    Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

    CVE-2014-0188
    Published: 2014-04-24
    The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

    CVE-2014-2391
    Published: 2014-04-24
    The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

    Best of the Web