taint.org: Justin Mason’s Weblog

Renesys Blog: The Bluesecurity Fiasco – in which Todd Underwood, CSO for Renesys Corporation, applies some real-world knowledge of how the internet works to the “timeline of events” press release, issued by BlueSecurity as part of their ongoing PR about the DDoS.

Judging by the comments at Slashdot, this really needs to be more widely read.

Here’s some highlights:

The timeline from BlueSecurity [...] is frustratingly vague. It uses phrases like ‘tampering with the Internet backbone using a technique called “Blackhole Filtering”.’ As Thomas Pogge, a philosophy professor of mine, used to say: that’s not even wrong yet. There is no “Internet backbone”, there is no technique known as “Blackhole Filtering”, and blackhole routing is not normally described as tampering. So the whole explanation is nonsense. [...] Let’s clear one thing up for the press and everyone else: this event just wasn’t that interesting. The attack against bluesecurity was a run-of-the-mill denial of service attack.

His conclusion:

I believe that the PR engine from BS is in overdrive spinning this event as fast as they can. But the concrete facts being put out by them simply to not add up. In the process they seem to be doing two things: 1) trying to imply or state that someone at UUnet was bribed by a spammer. This is simply ridiculous. I know many of the people who work for UUnet and they are honest, hardworking and extraordinarily clever people. They would not be crooked, or stupid, enough to do such a thing and if they were, they would have been trivially caught by change-management procedures. Moreover, such a change at UUnet (or BTN) wouldn’t have caused the event BS claims to have witnessed anyway. Additionally, 2) BS is trying to deflect attention from the damage that they caused at Six Apart. It would be much better if they could just claim ignorance of the DOS, apologize and move on. I recognize that that isn’t going to happen, but it sure would make this whole thing easier to handle.

Well said.

Of course, this is pretty much immaterial — the people who are using Blue Frog, and vocally supporting Blue Security, don’t really care what happened. All they care about is that someone is taking some kind of direct action against spammers, in some way or another, and if there’s a little “friendly fire” and some bending of the truth, why, this is a war! What, do you support the spammers?

It’s disappointing — the amount of disinformation being successfully pumped out (and accepted!) on this story is massive.

Tags: anti-spam, blue-frog, bluesecurity, ddos, internet, routing, security

Blue Frog is a company who operates a “Do Not Email” list, on the (optimistic) basis that spammers will vet their lists against it.

Reportedly, it’s been compromised. If this is true, I’m not surprised — as Dr. Aviel Rubin’s report to the FTC of May 2004 regarding a Do-Not-Email list notes:

The scrubbing approach [to running a D-N-E list] requires that a list of live email addresses exist. While the party owning that list may be well intentioned, it is unlikely that such a valuable list would not leak out. History is replete with insider attacks, as well as external break-ins to highly sensitive sites, such as the Pentagon computers. The Do Not Email Registry represents the kind of prize that attracts hackers. In this case, the prize has monetary value as well. Once the list is exposed, there is no way to undo it.

Also, it’s almost inevitable:

If this service were running for some time, it is more likely than not that the plaintext addresses would leak at some point, given the history of computer security incidents.

Update: it appears, according to this white paper, that the Blue Frog “Do Not Intrude” list is hashed, rather than plain-text. Rubin’s advice still applies:

Without hashing, a compromise of the registry database results in exposure of all of the registered email addresses. This is a total disaster. However, even exposure of a hashed list is a catastrophe. A spammer with a copy of a hashed list of email addresses is able to find out, for any email address, if the address is in the registry. The attacker simply hashes a candidate email address and sees if the hashed value is in the list. This is very powerful. [....]

Hashing provides absolutely no security against a marketer who obtains a scrubbed list and uses that to sell the addresses that were scrubbed by the registry. Whether or not the list is hashed has no impact on a malicious marketer in the scrubbing approach.

Tags: anti-spam, blue-frog, blue-security, do-not-email