Two Worm "Families" Make Up Most Botnets

JMoon writes "HNS has an article about the Sdbot and Gaobot families which are responsible for most botnets worldwide. These two families were responsible for 80 percent of detections related to bots during the first quarter of 2007. Other culprits, although on a much lesser scale, included Oscarbot, IRCbot or RXbot."

Comments

Reduced diversity.

[Red Flayer]

Q1 2007: 80% from two families.

2006: 74% from these families.

Hmm. Too bad bots reproduce asexually, otherwise we could hope for inbreeding to take them out.

Seriously, though, is the decreased diversity in bot "heritage" a good thing -- does it mean that bot infections are easier to detect and treat?

Or does it not make any bit of difference until the typical user learns to protect their PC?

Non Windows Bots

[pembo13]

Any information on non-Windows bots? I know bots are forever trying to get into SSH, so that must means non Windows machines are being targeted, but I am curious as to the success-rate.

Re:Non Windows Bots

[Anon-Admin]

I don't think those are bots.

I noticed my servers SSH port being hit a few years ago. I moved it to another port, locked the port down, then set up an SSH honey pot on the standard port. The honey pot attempts to ID people from programs using a verity of methods such as space between key strokes and use of the backspace or delete key.

I found that once the attacking software appeared to have access to the server, A person would login and check it out. Most of them attempted to use wget to dump a root kit onto the server. I have grabbed copies of the software they attempt to down load and checked it out.

It normally consists of a root kit, network scanner, packet sniffer, and the scanning software to scan and hack SSH.

I think these are wannabe hacker kids trying to get in.

Liability...

[msimm]

If you write a piece of code that's going to spread through unpatched computer networks you're creating a worm. Not only that, but if you make a mistake and this piece of code somehow (unforeseeably) damages any thing you will be in a world of hurt.

Either way, the law doesn't look to kindly on computer trespass even if (you *claim*) your intentions are good.

Re:Liability...

[cdrguru]

Yes, you are going to be in the same position as the folks that create botnets. We see every day how these people are treated.

Are they arrested in thrown in jail? No, they are living very well in Russia from their ill-gotten gains.

There is no liability unless you are a complete idiot.

A valid botnet ..

[Anonymous Coward]

Thought this would be an interesting point to add about botnets and security.

2 years ago I almost gave our security people a heart attack when I suggested an internal botnet.

We have most of our servers plugged into a tightly controlled IRC server.
All servers run a custom bot with limited access that pipe all critical files into specific IRC channels.

Response bots monitor the channels and take appropriate action, signaling the bots to run specific commands, paging, emailing, etc.

It allows NOC to run things like 'uptime' and have dozens of servers reply at once.

Security it tightly controlled at the bot and server level, using a custom hacked and very locked down UnlreaIRCd.

For our security at least, it was the first example of a useful IRC setup that allowed easy monitoring and limited control of servers.

As bad as botnets are, they are very good at what they do.
Good example of allowing totally unrelated applications to communicate with each other, as basically all programming languages have IRC support.

And a funny side note, my slashdot "verification image" is "misuse" ....

Re:A valid botnet ..

[Anonymous Coward]

Our setup is fairly simple.
The bots are all stored in our Subversion repository.
To install the bot they run a simple script along the lines of -
wget http://repos/installer | perl

The IRC server is the next pert, UnrealIRCd running modules such as NSAuth (among others).

Can't login without a user/pass, can't create a channel that isn't defined, can't /msg anyone.
Can only msg in channels, and all non-bot chatter is logged.
Can't talk in log channels, but if you have permissions you can enter and watch the logs.

The bots are the only ones with permission to /msg a channel. They don't join the channels, only
message them so they don't see peer logs.

Its also custom hacked to do the opposite of most IRC servers, flooding gets priority.
If your client can't keep up, you get kicked, not the bots. This ensures the log files continue at full pace.

For monitoring we have applications running on monitoring servers that watch the log channels, when things happen they take action.
Usually actions are to page someone, or join a "command channel" and issue a command to the bots.
They also monitor IRC chatter.

The bots only listen for commands from specific nicks, in specific channels, from specific IPs.
They follow cron-like permissions, so NOC teams and programmers can only run commands during their shifts.
Additionally, production rollouts are handled by the bots.
We say "release", they run svn up in production, do cleanup scripts, etc.
With sudo access to specific accounts and commands given to the bots.
And rollback is just as simple, developers don't need production access for releases, to check logs, etc.
It also ensures they can't break anything on non-rollout days, permissions are usually only Tue - Thu.

Bot permissions are controlled via subversion.
To give someone else permissions, you need commit access to the bots repository, then access in IRC to tell the bots to update their permissions or source files.
This also is locked down to specific timezones when they can update themselves, so a developer with access can't touch the bots source on a weekend.

Currently working on GPG security as well for more specific commands.
Bots store your public key, and /msg you a request, and since we all run IRC clients with perl support, we can script the challenge/response.

Security in IRC, in the bots, in subversion. With Subversion and IRC servers being tightly locked down.

Our security team has no complaints, but its fun to see each new person they hire go through the whole process all over again.
"We do what with IRC?"

Re:And that won't change soon

[Junior J. Junior III]

It's an idea, but I'd recommend against it. So many legitimate license keys have been disabled by Microsoft that it would affect a huge number of innocent users who've had their key disabled because MS felt like it.

I have seen firsthand and heard countless confirmations of people re-installing XP on their OEM system using the license key from the sticker that was glued to their system case, and being rejected by Microsoft's Product Activation. I'm not sure the reason behind this, but I'd guess that most likely some keygen hacker program ended up randomly generating the same key and was used enough times that MS decided to distrust that key anymore.

In my case, I was helping out a friend of the family with getting their laptop back in service after it had been hopelessly compromised by malware. I entered the key from the sticker on the bottom of their laptop, and Product Activation failed. I called the 1-800 number that Microsoft said to call, and went through all their steps to generate a new number, but it just told me that I was rejected and that my number was in fact really no good. I had no recourse, no appeal, no live body to talk to on the phone. So I did the only thing I could do to return the system to service, and used a Corporate license key that didn't need to be run through Product Activation and would not trip of on WGA.

Now, you might say that pissing off all these legitimate users would actually be a good thing, because it will ultimately help Microsoft to shoot its foot clean off by enraging masses of legitimately licensed end users who've been disconnected from the net because they couldn't maintain their systems properly because MS couldn't validate their license even though it wasn't pirated. But I don't think it's quite fair to say that every license key that fails to pass WGA is ipso facto a pirate user. If you block everyone on suspicion of running an unpatched, compromised, pirated OS, you're going to affect a lot of screwed paying customers. As long as they rightfully blame Microsoft for being the cause of their woes, you should be in the clear. If the collateral damage is worth it, then I guess it's not a bad plan.