Demise of BlueSecurity

According the Register, Blue Security has decided to close up shop.

The problem with Blue Security’s model is that a single attacker with sufficient resources can bring it down. Blue Security had it nearly right – if enough people took the spammers up on their offer to de-list users from spam registries, then the spam issue starts to become managable until such time it becomes law the spammers are jailed and refused access to the Internet forever and ever all over the world.

We need to set up a (de-)centralized place for spammers to check the “do not intrude” list without blowing their cover or exposing e-mail addresses, and a totally anonymous decentralized categorization effort without causing any harm to innocent bystanders (such as Tucows or Typepad).

The primary spammer who took out Blue Security can be considered to be essentially an organized criminal, and has committed criminal acts in taking out Blue Security. In general, fighting organized crime takes a lot of guts as it can be quite dangerous as they have nothing to lose and live in generally lawless societies. These thugs are like extremly stupid gruff dogs – they must be shown exactly who the boss is, and it’s not them. If they require a good slap on the snout or worse for shitting all over the Internet, well, it’s not for us to do so – it’s for the local police and SWAT teams to do. And in my personal opinion, I’d love to see that on COPS instead of their usual fare of poor drugged out wackos, who need social workers not arresting.

As I do not want any innocent bystanders, developers, moderators, ISPs (who are somewhat guilty), or key infrastructure targeted, I have thought about ways to protect as many stages of the life cycle as possible. I propose the following:

Server Infrastructure

Use newsgroups.

The infrastructure already exists at nearly every ISP, and is available read only at many other places to allow both the spammers and newsless ISP customers to participate, is sufficiently de-centralized, replicates relatively well, and the attacks are already well known (post flooding, etc)


  • Spammer would upload a batch file of e-mail hashes to a particular newsgroup (say alt.evil.spammers.must.die) with a response address to which the user’s clients will respond with a lightweight message. This prevents emails from being exposed to other spammers.
  • Individuals run a plugin on their mail application, which parses each message posted to this newsgroup
  • If the plugin’s protected e-mail address(es) are found, the plugin will ping the response address in the batch file
  • The ping would traverse a peer to peer network set up via the plug-ins. All of the plug-ins communicate via a de-centralized model to prevent the sort of attacks which might take it out (flooding, rubbish pings, etc). After a random number of hops, the last random peer will perform the takedown notice to the properly categorized spammer page.
  • The Spammer receives the do not intrude ping request from the individual and they take them out of their lists.
  • Problem solved for “less evil” spammers.

What to do about more evil spammers

Escalate. Spammers who refuse will get 2x … 4x … 8x the number of “unsubscribe me” from various anonymized addresses spread over a few days. In time, they’ll learn. Take the e-mails out, hits go down.

Categorizing spam

The plugins will need to know how to deal with spam, and to do that, it must be categorized, URL form found, and regulatory reports performed (ie, BSA for pirate software, FDA and other drug regulators for meds, etc).

However, as Blue Security demonstrated, being the centralized categorization source of truth does not work. That’s soooo Web 1.0. Let’s move on to a decentralized, people power version for several reasons:

  • If it’s a small group, they would be in severe danger. I don’t believe we could protect this model
  • If it’s a moderate sized group, taking out even one or two could cow the rest. This is how organized crime works today
  • If it’s the entire group, the risks are spread out over a large population, and taking out even a small number of users will not affect (and indeed will drive) membership.

Being in a large anonymous group makes it harder for attackers to find or attack anyone. If no one is a permanent moderator / categorizer and can always decline the task, taking out any number of individuals simply wont work – the service continues and the spammers continue to get hit with unsubscribe requests. This makes it impossible for the most mobile and ruthless of spammers to take effective action against the network and is a first hand demonstration of people power.

Each node is randomly chosen to be a categorizer for a few hours as per slashdot. If a user decides to participate, the nearby network will hear about it, and new uncategorized spams will be sent to current categorizers.

The hash of the spam is noted to remove dupes and this is spread everywhere. This will help prevent the same spam being categorized more than once.
If the categorizer can’t read the spam (say it’s in another language), it can be categorized to be a particular language, and then re-forwarded to peers who accept that language.
Let’s make it reliable via voting. Completed categorizations are offered to three other plugin users for peer approval. If all two peers agree with the categorization, it’s accepted and spread throughout the network.
If the spam is not categorized, for safety’s sake it is not acted upon, but instead spread to another node when the node’s time is up. This stops big spams from being lost in the system. However, there should be a maximum age for spams to prevent overload. Spammers usually send out more in a few days time.
At install time, node owners can say they are “advanced” nodes when their turn comes to be a categorizer. Each approved categorization will be looked at by one advanced node to see if it has enough information to detail the source. Let’s get those zombies closed down – find and report each and every zombie to the ISP abuse queue. Do this politely and in batches so they can deal with a bot fleet in a managable way. ISPs are not our enemies – they need to be helped to clean up the net from being abused. Hopefully the ISPs will get the idea and close down outbound SMTP from the zombies, or even better take the customers offline until they’re cleaned up.

An alternative I had thought of – a network of resilient web apps, which allows anonymous volunteers to contribute to categorization with voting to ensure that only good categorizations are let through, wouldn’t work. Spammers would just DDoS it out of existance. This particular model wouldn’t work.

Another alternative is to use another newsgroup to distribute categorizations. I like this as Plan B in case the attacker manages to kill the P2P network. However, as more headers are available, the attackers may be able to identify key nodes, particularly categorizers, so I don’t really think this is a safe idea.

Attack models

PharmaSpammer basically threatened to take the Internet out. As it’s essentially protected infrastrucuture these days (with no real SLA though), doing so will create a real law enforcement retaliation, as well as get ISPs to finally take responsibility for their zombie customers and get them the hell off our Internet. So let’s discard this attack – the spammers want to spam, and to do so, they need the Internet to be more or less working.

Let’s look at more realistic attacks:

a) Attacking news servers. DDoSing each and every news server in the world is just not likely, especially if ISPs make sure their news servers can only be reached by their own customers (which is typical today).

b) Attacking news groups. Post flooding can be dealt with via automated moderation of articles. This is a very old attack, and there are some methods to deal with it. Automatic cancellation is the wrong approach as this creates 2x replication traffic. Lastly, adding huge quantities of fake hashes to slow down client plugin processing of the newsgroup or to force the news server to archive legitimate and reasonably fresh articles to conserve disk space.

c) Attacking the peer to peer network. The RIAA has yet to make huge inroads into their little P2P problem, so I think with a bit of research, we can come up with a manageable P2P model for our purposes. Things to worry about are: rogue clients injecting rubbish. Flooding. Rogue clients looking for identifying information, rogue or real clients injecting “unsubscribe” URLs to attack competitors. These issues would need to be looked at.

d) Attacking the categorization volunteers / moderators. This is definitely a problem, but one which if there are enough moderators (say 100 or 150 volunteers) makes it that much less likely that attacking one or two of them will make any difference to the spam meisters – they will still be receiving one cancel message for each spam they pump out.

e) Attacking the plug in development. I propose that like the spread of DeCSS or Linux, this could be done in a relatively de-centralized fashion – let’s propose a standard for the p2p protocol, and then allow as many implementations as possible. Individual implementations could be distributed via P2P networks with known good hashes found on the more trusted sites to prevent malware being issued. Obviously we need open source implementations, as well as allowing vendors to integrate this feature into their fat apps.

I’d be really interested in peoples’ thoughts on this one. We can’t let organized crime win this one.

One Reply to “Demise of BlueSecurity”

Leave a Reply

Your email address will not be published. Required fields are marked *