Slashdot Mirror
Kelihos Botnet Comes Back To Life
angry tapir writes "A botnet that was crippled by Microsoft and Kaspersky Lab last September is spamming once again and experts have no recourse to stop it. The Kelihos botnet only infected 45,000 or so computers but managed to send out nearly 4 billion spam messages a day, promoting, among other things, pornography, illegal pharmaceuticals and stock scams. But it was temporarily corralled last September after researchers used various technical means to get the 45,000 or so infected computers to communicate with a "sinkhole," or a computer they controlled."
Researchers knew that it would only be a matter of time before its controller used the botnet's complex infrastructure of proxy servers and communication nodes to regain control.
The linked story says they fully expected this, and that the method they used (sink-holing) was never expected to be a permanent solution. One has only to hope that stating they have no "recourse" is merely baffle-gab to embolden the controllers. It might also mean "lets make believe we haven't compromised some of the bots and planted a few or our own".
They also suggest that the suspected Russian controller couldn't be extradited, but conveniently neglect to mention that Kaspersky Lab is a Russian company that could influence internal Russian enforcement actions.
Kaspersky Lab Expert Maria Garnaeva Posts in her Blog some of the difference between the new and old control mechanisms: http://www.securelist.com/en/blog/655/Kelihos_Hlux_botnet_returns_with_new_techniques
She also mentions it is not as bleak as the original article, because:
It is still possible to neutralize the botnet with sinkholing but using slightly different techniques as was used before, and it is still possible to push an update tool on infected machines to neutralize the botnet. In this case the botmasters need to infect machines again to build another botnet.
Sig Battery depleted. Reverting to safe mode.
What I don't get in the whole spam saga - and I've been following it for 15 years now - is why it is possible for law enforcement to cooperate internationally and do joint raids in several countries when it comes to fake products, unauthorized DVD presses or computer games piracy groups - but not when it comes to spam.
Ask Spamhaus - we know most of the top offenders. We know who they are and in many cases we know where they live. And law enforcement is sitting on their hands.
Because it is a small damage on many people - an attack on the commons, not on one particular company or individual. We as humans assess damages instinctively, not mathematically. And that leads to crazy results. We consider someone stealing $50k from a bank a serious criminal, but someone stealing $0.01 from 50 mio. people is a nuissance - even though the actual damage is 10 times higher.
Sadly, that's a trend not only with spam. When Mommy Jane illegally downloads a Disney movie, she is fined ridiculous amounts of money. When Disney corrupts the law to steal from the public domain by retroactively taking content back under copyright, or extending it so it enters it later (if ever), it is hard to even explain to people why that's bad.
We have lost the concept of the commons, and that is the real tragedy of the commons, not the bullshit neo-liberal bedtime story by the same name.
Assorted stuff I do sometimes: Lemuria.org
"We could have issued an update to those machines to clean them up, but in several countries that would be illegal," said Ram Herkanaidu, security researcher and education manager for Kaspersky Lab.
Don't be a sissy! If you have the means to clean up machines infected with a botnet client without screwing it up, do it! If some pedantic rule-thumper complains about good-faith efforts to make clueless people's spamming machines stop doing that, rat them out by name to The Internet and sit back and watch a million people demand video evidence of their head being placed on a spike.
There are plenty of rules that could be set up to prevent rogue systems from sending spam, but the problem is with getting network operators and individual server administrators on board. Trying to get all network operators (or ISPs) around the world doing something is like herding cats. Trying to get all individual server administrators to do something is like herding millions of catnip-infused cats.
Your thought about MX records is not quite right. There is a difference between servers that recieve mail (which should be pointed to by MX records) and servers that send mail (which should have valid PTR records in reverse DNS for their IP). While a single server may perform both duties, that is not by any means guaranteed. One action that would block a large number of infected systems from delivering their spam would be receiving mail servers blocking all mail from senders that do not have a valid RDNS record. This is the correct version of your proposal, and some major providers already do this. An even greater benefit could be achieved if all ISPs were to block outbound traffic headed for TCP port 25 by default, requiring subscribers to "opt-in" to initiate port 25 traffic. Some ISPs already do this, but far too many do not. Yet another good measure would be for recipients to block mail from servers that fail to identify themselves with a valid fully-qualified domain name in their HELO message and require that domain to resolve by DNS. Like the RDNS solution, this would require all legitimate mail server operators to set their sending servers up properly. As more receiving operators start blocking non-compliant mail servers, we may slowly push more sending server operators to do things right, but it is a long, slow process when users demand that every legitimate message get through.
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP,
Because there is no rule that says any destination must have an MX record associated with it. RFC 5321 lists how to determine the host a server connects to, and "no MX" is an allowed case.
and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
What is a "human real-world number"? How do you deal with mailing lists that have hundreds of recipients? One email to the list results in hundreds of emails all at the same time.
That would prevent a non-MX mail server from being able to send mail since other mail servers would reject it based on DNS,
I'm sorry, but I don't think you understand the purpose of an MX record. The MX record isn't for the SENDING server, it is so the sending server can find a defined host to which email FOR a domain is sent. In fact, if an MUA uses SMTP to send mail, then it is highly unlikely that the sending host (the user's computer) will be the address pointed to by the MX record for any domain.
Yes, it would require some more programming in the SMTP daemon, but it shouldn't jack with the protocol.
As long as you don't consider "not being able to send email at all" a problem, no, your idea won't "jack with the protocol".
The more correct means of dealing with the problem is two-fold. SPF (sender permitted|policy framework) is how a recipient server looks up the authorized hosts that might be sending it email from a domain. Greylisting is how a server typically dispatches botnet senders, since the botnet is usually not going to try resending an email after getting a 500-level error.
Jeez where do I start? You must not be that familiar with email or how it is actually run today.
First off, email is an archaic platform that gets a bunch of glue and duct tape every so often.
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP, and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
You can already do this with most mail servers. You have two problems here:
1) Requirement.
2) ISP involvement.
You cannot legally compel any person operating a mail server to do anything as part of configuration. The only legal liability I am aware of is sending SPAM itself, and even then the claim that you are merely a victim usually works.
ISPs don't want to be involved on a general basis. On business connections they don't do a damn thing, because businesses would go ape shit. I would. On residential connections some have at some points in time restricted port 25 destination traffic and the TOS usually prevent operating services off the IP address anyways. That being said, it has been awhile since I have actually seen a US based ISP actually block port 25 traffic anymore.
What is done on a day-to-day basis now:
1) Inspection of the IP address communicating with the mail server. Policy based lists, which are contributed to by the ISPs, tell us if it is a residential connection (Dynamic IP address ranges). There are also other lists that allow us to see if that specific IP address is flagged for SPAM. Look at Spamhaus or Cisco's Senderbase products. If the IP address is on a list it the session can be terminated immediately or the SPAM score increased sufficiently.
2) Headers. Who is it being sent to? Who is it being sent from? You have to ignore who the email is claiming to be from in most cases since that is easily forged. Every part of the email address can be forged except the remote IP address. Sent to addresses can be on white list to get it into the Inbox regardless of SPAM heuristics. Part of what you seemed to be alluding to is the EHLO statement. You check the reverse DNS for the remote IP address and see if it matches, or even exists in the first place. You're right that most real mail servers run by professionals, and not on home networks, will have a proper reverse DNS. Shutting down the connection solely based on that is questionable though.
3) URI inspection. Parse out all the links in the email and compare them against lists of known malware host sites. Fairly effective, and I personally don't allow the email to even reach the junk mail folder when one is found. New URIs pop up very fast so this is only effective for older campaigns.
4) Certifications, DKIM, SPF. These are methods outside of the mail server communication that involve 3rd parties, certificates, and DNS records that can validate a mail server as authentic and provide policies on how to treat remote IP addresses.
5) Anti-virus and Anti-malware. Inspection of attachments.
6) Heuristics. Evaluating all of the above plus content inspection to arrive at an overall SPAM score. If it exceeds the threshold throw it in the junk mail folder.
Now that is just off the top of my head for the mail servers I run. You also alluded to gray listing which is temporarily denying an email and asking that it be resent later. This is controversial because a lot of people are waiting for an email ASAP and can't wait 15 minutes. Throttling is also not very useful because on an IP address basis the SPAM load is distributed.
There are already quite a number of tools to reduce SPAM. The biggest problem I face is backlash from executives. Requiring proper reverse DNS left out half the vendors we were communicating with right off the bat. I have had to tone down the security a number of times because the remote part has no clue what they are
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
(X) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(X) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
(X) Willingness of users to install OS patches received by email
(X) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
(X) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
(X) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Half the business world seems to believe that it is acceptable to mail my ISP, and have me disconnected from the internet if I download a couple of songs, movies, or whatever. Three strikes, and you're out.
So - why isn't anyone clamoring to have these machines disconnected by the ISP's? If they had all those machines communicating with a sinkhole for months, then surely they have identified real IP addresses for most, if not all of them.
We have the ability to unplug people and computers from the internet. Why do we only want to use that ability to punish small time downloaders?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br