Two Worm "Families" Make Up Most Botnets 176
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."
Reduced diversity. (Score:5, Interesting)
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?
Re:And that won't change soon (Score:3, Interesting)
Non Windows Bots (Score:5, Interesting)
Does this make it easier for ISPs to spot them? (Score:2, Interesting)
If they do, then getting ISPs to proactively monitor their customers for botnet-specific activities and phone them when they see suspicious activity will go a long way toward eliminating these particular threats.
Imagine if your mother getting this answering-machine message from her DSL provider:
"Hello Ms. Jones. You've heard of computer viruses? Our engineers are seeing signs of a virus on one of your computers. Please visit our security web site at http://www.momsisp.com./ [www.momsisp.com] This same web site is printed on your billing statement. In the meantime, we are taking steps to keep the virus from spreading. This may affect your connection. We will remove these blocks automatically when we see your system is clean. If you have any questions, call us at 1-800-MOM-SISP. Thank you."
Her next call will probably be to you. Problem solved.
Re:Non Windows Bots (Score:5, Interesting)
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... (Score:5, Interesting)
Either way, the law doesn't look to kindly on computer trespass even if (you *claim*) your intentions are good.
Re:Liability... (Score:4, Interesting)
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 .. (Score:3, Interesting)
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:And that won't change soon (Score:5, Interesting)
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.
Re:Does this make it easier for ISPs to spot them? (Score:2, Interesting)
My roommate set up a box and I guess he didn't finish patching it or something, because in less than a week, we got e-mail and snail mail from our ISP informing us of our PC that was scanning ports and more than likely had a virus. We took it off the network, but still haven't taken the time to wipe it and clean install it.
Re:ISP's half the problem (Score:3, Interesting)
Not on today's OSes and architectures, but those aren't the only possibilities.
Moving away from the assumption that software is trustable would be a great start. Why does my web browser have authority to overwrite my hosts file, just because I do and I'm the one logged in while it's running? Why does my email client have authority to launch executables?
Operating systems that enforce per-program restrictions do have a terrible record of being hard to use, and eventually someone will tell downloaders "remove jumper J4 to disable mandatory access control so you can install our dancing cursors.
Re:White hat "mal'-ware? (Score:2, Interesting)
There is a classic case of this that happened IIRC at MIT on one of the early networks. Some bright person wrote a small worm that went around and performed regular updates to the systems. All went well for a few months or so, but then a previously unknown bug in the worm caused it to go nuts and brought the network down HARD. In a similar vein, as an example of how things can go wrong, there's a famous story of someone (seem to remember him being connected with NSA or CIA or one of them... son of the director?) who wrote a worm that didn't have a payload in it to see if he could do it. It was supposed to send a couple copies of itself out, propogate for a bit, then erase itself. A bug in the logic however made it bombard the network attempting to propogate which resulted in one of the first DDOS attacks, even if un-intentional.
The reason in short of why you don't see any white hat mal-ware is because the risk is just too great that something can go wrong. It's better to come up with a more robust solution to the problem, rather than introducing another element into the mix that is already on shaky ground to begin with.
Re:Detection Question (Score:3, Interesting)
Unusual activity on non-standard ports. Atleast thats how I discovered it at my last job. Open up a packet sniffer, let it pull in traffic for a little while, then investigate.
Smarter worms use standard ports, but then you tell but unusual traffic patterns. (ie, why does "Bob the idiots" computer keep sending 2k of data to pron-iz-gud.com 50 times a minute??)
Re:A valid botnet .. (Score:3, Interesting)
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 [repos] | 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
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
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
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?"