On Jan 11, 2008 8:01 AM, Tyler Durden <camera_lumina@hotmail.com> wrote:

Someone want to explain this? ... Why encrypt the traffic?

authentication of replies to special searches used in the decentralized command and control. the botnet is basically being partitioned up into distinct sets for resale or other purpose. the previous design did not allow for such segmentation of C&C.

On Sat, Jan 12, 2008 at 11:38:06PM +1300, Peter Gutmann wrote:

Enterprise DRM for the botnet.

(Alternatively, "because they can". They're not paying for the overhead, it doesn't really make much sense not to encrypt everything).

Anyone seen a private Tor bot network in the wild yet? -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

On Sat, 12 Jan 2008, Peter Gutmann wrote:

(Alternatively, "because they can". They're not paying for the overhead, it doesn't really make much sense not to encrypt everything).

I don't agree -- they *are* paying for the overhead. Not in dollars, but in CPU cycles (and a minor programming overhead.) If you increase the performance degradation on the hosts in the botnet, you're going to lose some of those hosts due to the owners cleaning up the system so that they can use it -- botnets survive because they steal CPU and bandwidth that is "acceptable" to the users, or unnoticed by them. Adding in additional computational overhead to the operation of the botnet diminishes its overall capacity, either in the number of nodes, or in the amount of work you can steal from the nodes without losing hosts, or both. Your "DRM" answer, and coderman's comments, seem to be more on the mark. --Len.

Makes me wonder whether there's some way to make peace with our new Spam overlords. Maybe get in on the action somehow. Seems to me the battle's very nearly lost if the botnet is functioning in a way that we can live with and that is very hard to tamper with. -TD

Date: Sat, 12 Jan 2008 15:01:54 -0800 To: rabbi@abditum.com From: bill.stewart@pobox.com Subject: RE: Storm, Nugache lead dangerous new botnet barrage CC: pgut001@cs.auckland.ac.nz; camera_lumina@hotmail.com; cypherpunks@al-qaeda.net; eugen@leitl.org; info@postbiota.org

At 10:37 AM 1/12/2008, Len Sassaman wrote:

...

...

(Alternatively, "because they can". They're not paying for the overhead, it doesn't really make much sense not to encrypt everything). I don't agree -- they *are* paying for the overhead. Not in dollars, but in CPU cycles (and a minor programming overhead.) If you increase the

On Sat, 12 Jan 2008, Peter Gutmann wrote: performance degradation on the hosts in the botnet, you're going to lose

Encrypting the control channel isn't going to burn a lot of CPU; hopefully the botnet doesn't need more than a few KB/hour of control, and almost certainly it wouldn't need more than a few KB/sec of data (such as spam-target email addresses), so encrypting it's low-horsepower.

The heavy-resource job of a bot is sending out lots of packets to targets, whether it's spam email sessions or DDOS UDP packets, and the limiting factor on that is upstream bandwidth, typically 128-768kbps. On a modern CPU you could even encrypt that traffic if you wanted, without the CPU breaking a sweat, though the only application I can see for that is encrypted SMTP sessions if you're spamming somebody high-tech.

Most computers have enough spare CPU that they can burn it looking for space aliens or folding proteins at home without noticing a performance hit; the real trick on keeping resource consumption low enough to not be noticed is managing upstream bandwidth so that you don't stifle http queries and TCP acks.

_________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail.-get your "fix". http://www.msnmobilefix.com/Default.aspx

Len Sassaman <rabbi@abditum.com> writes:

On Sat, 12 Jan 2008, Peter Gutmann wrote:

...

(Alternatively, "because they can". They're not paying for the overhead, it doesn't really make much sense not to encrypt everything).

I don't agree -- they *are* paying for the overhead. Not in dollars, but in CPU cycles (and a minor programming overhead.) If you increase the performance degradation on the hosts in the botnet, you're going to lose some of those hosts due to the owners cleaning up the system so that they can use it

If you ever find users who do this, could you send them my way? :-). There may be some reference user somewhere in a display case who does this, but in practice unless the computer explodes in front of them no-one ever reacts to infection. I've seen users whose laptop fans are running continuously because the CPU is pegged at 100% by malware not have any idea that this isn't a normal state of affairs. I've seen users who patiently wait something like 30 seconds for an Explorer window to open because that's just how long Windows takes. I've seen users whose PCs page themselves to death every time they start an app, and that's quite normal. I've seen attack ships on fire off the shoulder of Orion... More importantly, the sort of people who are likely to have machines riddled with malware are the same ones who aren't likely to have any idea that anything's wrong. Bill Cheswick has a neat talk "Windows OK" in which he describes his dad patiently using his malware-infested PC that nicely illustrates this.

Adding in additional computational overhead to the operation of the botnet diminishes its overall capacity, either in the number of nodes, or in the amount of work you can steal from the nodes without losing hosts, or both.

So you reduce it from 1M nodes to 900,000 nodes, that's not much of a loss. The benefit you get from making it hard(er) to intercept and disrupt more than covers it. Peter.

Len Sassaman <rabbi@abditum.com> writes:

I'm not sure that this *does* make it harder to disrupt the botnet, though, does it? Does anyone have example traffic dumps of these encrypted payloads? It should be possible to identify and block this traffic; it's going to follow some unique pattern.

It doesn't have much effect on passive blocking, but what it stops (or at least makes lot harder) is two things: Active attacks (penetration of botnet servers by security people is a serious problem for the botherders, and I assume competing botherders find this an easy target as well), and leeching of botnet-collected data by others. It's mostly back to enterprise DRM again. Peter.