Archive for December, 2005

spamhuntress blogmysite - Blogs by Webstars2K

Saturday, December 31st, 2005

That’s exactly how Maryanne Myers is presenting a blog on one of her blog networks.

spamhuntress blogmysite - Blogs by Webstars2K

Which I take exception to, because I’m associated with the name Spamhuntress, and because I would NEVER EVER have a blog on any of her sites, nor use any of her software.

It’s retaliation on her part, because I wrote about her earlier.

Notice how there are about 350 comments on the first blog post there. The comments tart to fall off the page after about 14 days. That’s her program, blogmysite, in action. The punters get backlinks lasting about 14 days.

I wouldn’t pick on her, except she’s got a new technique out, which you can see on what apperas to be my blog on her network:

myblogbomb

What she doesn’t say, is that the blogs with those ads on them are easily identified, and it would be very possible and easy to just ban anything that appears on there.

And it turns the blogs into splogs, effectively…

Suss out spam networks

Saturday, December 31st, 2005

I was running down splogs that refer to one of my other sites (nativecelebs has good serps and content, so often included on junk sites).

And I found one blog that I suspected was part of a splog network, with blogs living in various folders. But the root didn’t work, so I turned to Google.

And found this:

a2b for 70.86.36.194

It’s a list of URL’s that point (or pointed at one point in time) to one particular IP number.

And it looks like it’s part of a blocklist that susses out splogs. Have a look!

And I was absolutely right. The domain is part of a scraper splog network.

About a2b: They’ve now added nofollow to the spam URL’s, so I lost the nofollow on the links!

Oh, and the spammer behind the splogs? He’s best known as peteinoz on forums and such. He owns wpburner, catbcreator, completeadsensetoolkit and probably a few others. All splog creation, posting and pinging tool. Matt, are you there with your red crayon? These need banning. The guy talks openly about splogging. I’m debating whether or not I’ll post the URL to his forum, so you can see for yourself. Hmmm…

Actually, most of the URL’s on that blocklist should be banned. Most are probably generated with wpburner or similar.

Proof of concept - iframes and Yahoo groups

Wednesday, December 28th, 2005

I’ve made a proof of concept page for Yahoo groups.

The hope is that Yahoo groups will see it, and realize how badly insecure the homepages for the groups are:

http://groups.yahoo.com/group/proofofconcept/

And no, it’s not dangerous. I’m not a bad guy. But had I been a bad guy, I could have basically done anything with that vulnerability. And because it’s a trusted site, people wouldn’t have thought they could be infected.

I added a pop-up, and a redirect (thanks for the suggestion, Joe).

What I found while setting up the group, was that if I only included the iframe in the description field, they substituted my tags for lookalike characters. But if I had other tags first, the tags were delivered as I wrote them.

Update:
Proof of concept that iframes work in message as well:
Joe’s proof of concept message (Joe got it to work too, and this one’s ready for scrutiny).
I had to remove the redirect here, because it crashed Thunderbird when I tried to send the message. But with a spam mailer, or software with other features, that wouldn’t be a problem. Incidentally, the iframe worked in Thunderbird as well, which I totally didn’t like! Update: Joe’s version of Thunderbird was different, and he had to work a bit more to get the iframe to work. His post about the issue here.

For contrast, eBay talks openly about iframes not being allowed. Looks like they have some kind of automated way of blocking it. As Joe pointed out, it’s a thorny story, because Google Adsense actually uses iframes to work. The point isn’t that iframes should not exist. The point is that trusted services should not allow strangers who open an account to use unsafe code. Iframes basically import foreign content into their sites. In other words, if you go into unsafe neighborhoods with an unsafe browser, it’s your neck. But if you go to a trusted service and get a trojan, it’s an embarassment for said service, and a shock for the infectee.

Update December 30, 2005:

I got two new responses from Yahoo. One for the specific use of ads via iframe on a specific Yahoo group (which is still up), and one for reporting the iframe vulnerability. I got the same stock response for both reports:

While we investigate all reported violations against the Yahoo! Terms of
Service (TOS), Yahoo! has no control over activities outside its
service, and therefore if messages are being sent directly to your
address outside of the Yahoo! Groups service, we cannot take action.

You may try contacting the sender’s email provider, by identifying the
sender’s domain and contacting the administrator of that domain.

This demonstrates a total inability to even understand the problem, on the part of the responding abuse person. And if I get this type of response, it’s very unlikely it will be sent up the pipe to someone who can do anything about it. Which means we need to make a public stink to get the attention of someone higher up.

What other services allow or disallow:
* Livejournal, xanga and myspace from July 2005
* Browsers - it’s possible to block iframes in your browser. If anyone knows how, please let me know.
* Ebay doesn’t allow iframes

Digg my story

Mediawiki anti-spam suggestion

Tuesday, December 27th, 2005

I’ve found that most wiki spammers go for the pages that all MediaWiki installations have by default. Some of those are reached by the menu on the left.

To cut down on the spam left on those pages, protect them while logged in as sysop. That way they can only be edited by someone with rank. But that should be a small price to pay for less wiki spam in general, right?

Here’s an overview of the pages I found necessary to protect on my own wiki.

If you have a different type of wiki, check if you can protect pages, just for your own peace of mind. And please still moderate heavily. I have spammers who go for other pages as well.

Block iframes

Tuesday, December 27th, 2005

Update: Proof of concept

Since discovering the iframe on Yahoo Groups, I’ve been thinking about the possible ill uses of that technique.

Basically, those that have interactive services: You need to disable iframes from working.

Iframes can be used to drop parasites, as well as ads, into services that never intended to become a vehicle for such.

So Yahoo Groups, now’s the time to act!

And any software - forums, guestbooks, wikis, classified - anything out there that allows contributions by people whose character you don’t know, make sure iframes can’t be used!

High spam scores with SpamAssassin

Tuesday, December 27th, 2005

I read Richi’s post where he asks for a service that lets him sort spam by spam score.

And then I checked a spambox I had with over 8000 spam mails, all with relatively high scores (all 25 or over). The highest score I could find was 69! From a cursory inspection, it looked like all spam mails that scored 57 and over were Spanish.

I’ve never seen a false positive with a score of 25 or over.

Tired of abuse asking for headers

Monday, December 26th, 2005

I told Yahoo Groups abuse department about a wiki spammer that used Yahoo Groups as throwaway sites.

And then I get a reply, saying to give them headers or they can’t do anything!

Aaaarrrrgggghhhhh!!!!!

How many times have I received that exact same e-mail from various abuse departments?

It’s getting REALLY old, REALLY fast!

Please educate your abuse personnell, Yahoo, and others!

Linkspam up considerably

Saturday, December 24th, 2005

Link spam on my guestbook and blog is up significantly.

The guestbook spam was manageable, but now it’s to the point of at least 10 per day. The guestbook spammers used to be easy to block, but they now use proxies.

Comment spamming on spamhuntress.com is also up significantly.

And as you guys know, I’ve been complaining bitterly about one particularly bothersome referrer spammer, who steals bandwidth. One blog has more than one gigabyte more traffic than normal this month, and chances are, this one spammer is behind it.

Mini dictionary attack

Friday, December 23rd, 2005

I do various grep searches on my log files in order to spot problems. And I found another type of dictionary attack.

And this one illustrates how short sighted many people are when they choose e-mail addresses. These are the addresses tried in one such attack:

accounting@domain.com
administrator@domain.com
admin@domain.com
advertising@domain.com
contact@domain.com
help@domain.com
home@domain.com
info@domain.com
mail@domain.com
majordomo@domain.com
postmaster@domain.com

And in a very similar dictionary attack, I found this in addition:

accounts@domain.com
billing@domain.com
root@domain.com
sales@domain.com
support@domain.com
webmaster@domain.com

These addresses should be avoided. In fact, try to make your addresses hard to guess, but still memorable.

The problem is of course that if you avoid the postmaster address, you open yourself to other problems. The postmaster address should at the very least be open on the root domain of the webserver, but I’m torn when it comes to small domains used by one to six people. I mean, most of them don’t read the postmaster account anyway.

Dictionary attack

Thursday, December 22nd, 2005

Update January 10, 2006:
I didn’t want to believe it, but that domain is still receiving thousands of e-mails, even after I disabled catch all and reject unknown addresses. Either it’s a dictionary attack still going strong, or the spammers think they found legitimate addresses. Looks like the latter, because I find the same addresses in just about every stats report going back to December 17!!!

—————

My current job involves taking care of three mailservers. I inherited some. I’m happy to say two of those are gone, and the third will be OK once I’ve made some modifications. My two new ones are running open source all the way. With that comes really good logs (the old ones had atrocious logs).

Anyway, one of the domains on our servers is currently under a dictionary attack. This has been going on before, during and after the migration. The oldest dated message I’ve seen is from December 15, and it’s still going on. This is for a domain that has 6 human users, a few forwarders and company accounts.

With the earlier servers, it was catch all on the two front machines, and then bounce for non-existent users on the mailbox servers. Now, since the new servers, I reject mail for non-existing users for most of the domains we serve. That means my server doesn’t waste resources on a message past giving the sending server a 550. No spam or virus checking on thousands of rejected messages, means my server runs much lighter.

I thought I’d give you the benefit of my curiosity, and give you my research on this particular spam run.

Basically, I hardly see the same IP number twice. And I have a hard time finding any of them on blocklists.

Allthough this is a dictionary attack, I doubt the spammers are using their own e-mail addresses to look for bounces. I think those belong to innocent third parties. Probably domains configured with catch all, and non-existing users.

Each and every mail i looked at (which was a small cross section) was different. Many looked very similar. But the links in each were different.

Each domain pinged the same IP number:
221.7.209.69
See Spamhaus records:
SBL35655 (same MO as my spammer, judging from the sample e-mail)
SBL35677

And had the same dns servers:
ns0.morreser.com (NMC102-BMN-HST)
ns0.orredecte.com (NOC40-BMN-HST)

And get this, the sites were all operational!

Whois info was different for virtually all domains. I have no doubt they’re fake. Registrars were different as well.

I have no idea what they plan to achieve by using a dictionary attack against a domain with that few users. It seems incredibly wasteful.

Read this account on Cotse, from a guy who’s been doing some thinking after having been subjected to dictionary attacks.