A CBL false positive reveals a significant issue with the CBL

March 11, 2012

We were notified today that one of our IPs, 128.100.1.90, had been listed on the CBL (and thus had been pulled in by Spamhaus in their XBL and Zen DNSBLs). There's only one problem with this: there's no machine at that IP address and never has been, and even if there was such a machine it would not have been allowed to do any external traffic by our firewall.

(This subnet is only present on a couple of switches in our machine room and is not exposed outside of it; it's not even carried on our general inside-department backbone.)

However, there is a long standing issue where some people out there in the world are using addresses in 128.100.0.* and 128.100.1.* on their internal networks. These addresses leak into Received: headers and provoke spam complaints when these companies are exploited to send spam. Now they apparently also cause CBL listings.

(Back when I first saw this it was primarily from machines in Europe, but this time it appears to be a bad machine and organization in Brazil.)

Unfortunately, this is very bad. The only way for the CBL to pick up these IP addresses is for CBL feeders to parse the Received: headers in the mail they receive. Let me repeat that: the CBL is listing IP addresses based on parsing Received: headers from untrusted third party machines. And demonstrably this parsing can and has been fooled into false positives, listing machines that are not spam sources.

What we are seeing here is only one demonstration of what can go horribly wrong when you do this. As far as I am concerned, this significantly lowers the trustworthiness of CBL results. It used to be that I could trust that everything in the CBL was listed because CBL honeypots had direct experience with bad behavior from that IP. Now it is clear that for some or perhaps many listed IPs, the CBL has at best indirect 'evidence', evidence that can easily be wrong. Probably the CBL is still mostly correct and this sort of thing is rare, but I had previously thought that this sort of false positive was actively impossible in the CBL.


Comments on this page:

From 63.166.216.16 at 2012-03-12 14:40:36:

So all the bad guys have to do to knock gmail.com off the net is to gin up some fake Received: headers mentioning the gmail.com IP addresses within spam messages.

Then CBL will white list the gmail.com IP addresses, and maybe hotmail.com and yahoo.com if they think of it.

Then the bad guys go into business blackmailing any smaller site with the temerity to host their own e-mail.

Sheesh.

By cks at 2012-03-13 19:36:22:

I don't think it's quite that easy for the bad guys, in that they also need to figure out one (or enough) CBL spamtrap addresses that can be exploited this way. On the other hand I suppose that's not much of a defense if they're already blasting spam out broadly and want to implicate GMail somehow.

I wouldn't be surprised if the CBL already has protections against what they consider 'obvious' fakes such as for GMail's sending machines and so on. The people behind the CBL aren't stupid so they are undoubtedly aware that parsing Received headers does risk false positives.

Written on 11 March 2012.
« Why you do not want to patch your source code in place
Why ZFS log devices aren't likely to help us »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 11 00:41:23 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.