Archive for August, 2006

Guestbook spammer litigation

Monday, August 14th, 2006

IrishVette proposes litigation against some guestbook spammers who’ve made trouble for her business.

Guestbook litigation 

This seems related to the post she’s commented on, so revisit the post and see if you want to compare notes or join in. Comment on the old post, not here.

Invision Power Boards and redirects

Monday, August 14th, 2006

I came across a free forum provider that had both phpBB and IPB (Invision Power Board) free forums.

And the IPB forum I saw had redirect code between the head and the body.

There’s an additional problem with IPB boards: They cost money. They used to be free, but in order to update them, you need to pay. And for a free forum host, that’s not a good deal. And because it’s not open source, the owners of the free forum host are hesitating to change the software.

So I propose a solution: Stop accepting new signups for IPB boards, but keep the old ones. But scan or look through the old ones, and remove ALL spammy forums.

Something to think about…

Trustrank by Yahoo

Saturday, August 12th, 2006

Yahoo has announced something they hope will counter webspam:

Yahoo!’s Trustrank Approach To The Spam Problem

How about some of you smart guys poke some holes in it?

I’ve got one: Expired domains. There’s already a rush on them, and with this, it might get even worse.

Bounce verification has achilles heel

Saturday, August 12th, 2006

I found this post via Email spam/Topix:

IronPort Wants To Give Bounce Spam The Boot

In short, IronPort wants to outfit their mailserver appliances with technology to sign outgoing mail, so that when a bounce is sent to it, they’ll know if it originated from their server.

The problem with that, is when an IronPort appliance is used for an environment where some customers are on other ISP’s. It’s customary for an “outside” customer to use the outgoing mail server belonging to his ISP, even though incoming mail is going through a business mail server where his business domain is residing.

In order for IronPort’s technology to work, all outgoing mail needs to go through that server, no matter where the sender is. Otherwise, guess what? No bounces, if you sent through an outside mailserver!

The solution is trivial, but enforcing it may not be:

Use an authenticating outgoing mail server, often used on other ports than SMTP. Just a question: How does that affect e-mail clients on cell phones?

phpBB redirect code

Monday, August 7th, 2006

And the litany of vulnerable apps continues:

I got spammed with a link to a free forum site. A link to the front page of said user created forum. I got curious, and found that the user somehow got a redirect into the code.

Turns out the code was in the sub heading of the post. The only post on that forum.

phpbb code

Anyone with a free service handing out phpBB forums to those who sign up, better make sure that hole is plugged. I haven’t had time to check regular phpBB forums. Hopefully it is plugged :-(

Update: It was interesting to see how that particular free provider had solved the problem. They substituted < " and > with the HTML equivalents that display the characters correctly, but the META refresh no longer works. With this substitution, HTML code or javascript wouldn’t work either, but BB code would. The META refresh code the spammer had inserted, is now clearly visible in the subtitle, but no redirection.

The upload spammer

Sunday, August 6th, 2006

Webspam is constantly evolving. A while ago a spammer told us spammers had long since moved on from what us anti-spammers were writing about. That webspam had moved on from comment spamming blogs. And I was sure he was right. What I’m seeing now, is the newbies spamming my blog. The spammers who don’t yet know what they’re doing, for the most part, with a few comment spammers who rely on inventive wording thrown in.

Today I’ve been on the trail of a spammer who’s constantly trying new things. He’s been at this for a long time. Eugene Blagodarny (some of you are no doubt tired of my talking about him). Lately he’s been using upload scripts to place spammy pages on otherwise clean sites. Not links to spammy pages, but regular throwaways that redirect to his money sites or his affiliate links. There might be other spammers doing the same thing, I just haven’t found their trails yet.

And this guy is using any upload script he can find. He’s not just searching for specific types of scripts. In one case I confirmed that he misused a custom written script that was used on ONE website.

In addition to any upload script he can get to accept his HTML pages (usually with .htm extension), he’ll leave comments or user profiles anywhere his javascript redirects will work. Some of his favorites are HyperNews (comments), Twiki (user profiles) and SnipSnap (userprofiles with uploads). He’s also (I assume) signed up for user accounts at compuserve in Germany.

He then comment spams other websites with links to his upload pages and redirect enabled comments, in order to get them into search engines. They’re often hidden on the websites he’s uploaded them to, so he needs to get them linked by other means.

What does all this mean?

If you’ve got a website that has an upload script that accepts HTML files, you need to be alert. Either recode to not accept HTML files, have a good admin interface and check it for uploads every day. Or remove the script altogether. Another possible option, if you haven’t been targeted yet, is to add a robots.txt file that bans search engine indexing of the directories your uploaded files are deposited in.

If you’ve got an interactive script on your website, make sure they don’t allow javascript redirects. That includes old scripts for guestbooks, forums etc.

If you’ve got a free website service, such as free homepages, free blogs, free groups, free forums, you need to recode those services so javascript redirects won’t work. Disabling iframes and frames pointing to somewhere else would also be proactive. I know of at least one free webhost who runs scripts every night, looking for certain keywords that spammers tend to use, and then disabling pages en masse. Identifying obfuscated redirects would also help you remove other sites with those redirects on them.

Twiki userpages spammed

Sunday, August 6th, 2006

Twiki is wiki software. And in the past it wasn’t much plagued with spam, according to the Chongqed writeup.

That has recently changed. I don’t know who figured it out, but noticed Eugene Blagodarny started posting his MarkusMerk users July 7, 2006. The spam started July 13, 2006. I’ve also seen other user accounts lately that look like spammer probing. There are several spammers using holes in twiki to spam, so it’s hard to figure out exactly who did what.
The spam works as follows:

The spammer registers as a user, with a spammy name, such as Viagra. He then populates the user page with his e-mail adress and name, and then adds a comment on this form:
twikiuserspam

Example: twiki.gridprovenance.org/bin/view/Main/GrowthHormone

The end result is a redirecting page on a wiki. And yes, it is indexed by search engines. The twiki developers need to close that hole! One way of making twiki less interesting, would be to make sure any user page is off limits to search engine spiders. But the redirect holes will also need to be plugged.

Here’s an example of a spammed wiki:
uai.cs.ubc.ca/cgi-bin/twiki/changes/Main

The spammy users were registered July 13. 29 users, if my count is correct.

I’ve also seen regular comment spam techniques used for adding spam to user pages this way. Here’s one example:
gnuenterprise.org/cgi-bin/twiki/view/Main/AustraliaRealEstate

Update: The twiki guys have identified yet another spam technique, and offered solutions: HTML Attachment Spam

Nuke redirect code

Saturday, August 5th, 2006

While looking at HyperNews misuse, I started thinking. How would an owner of a HyperNews site nuke all the comments with redirects?

A script that looks for common redirect code would get a lot of those comments, providing the template doesn’t contain that type of code. On the other hand, HyperNews is dead. It’s too hard to keep up these days. Spammers will just pump out the comments without checking for admins who clean their installations. So the only logical step is to remove the software altogether.

But, owners of free blogs and free websites, should definitely scan for redirect code. And remember that the moment you remove sites containing one type of code, the spammers will try and outwit you. So it’s an arms race, all the way.

And if you’ve got a website with any kind of interaction: The spammers will find a way to use your scripts against you. So you need to stay vigilant and monitor everything. Don’t want to monitor anything? Remove all the interactive stuff, and stick to clean HTML. OK, CSS might work, but php and cgi is out. While you’re at it, you should move to a dedicated box… ;-)

Seriously, the most cutting edge is way beyond guestbook spam by now. It’s high time we rethink our old methods for combating webspam. It just doesn’t work.

Update: Check out Google Groups spamvertizing of HyperNews spam. Don’t know what the point is, unless Googlebot spiders links in their groups. But there it is anyway.

Uploading scripts need to be removed

Saturday, August 5th, 2006

Eugene Blagodarny has started using uploading scripts as means of turning regular clean websites into spammy websites.

Here’s an example (that will hopefully be removed soon) of his handiwork:

m4l.berlios.de/pub/Main/MarkusMerk/

He likes using the username MarkusMerk.

But the problem goes deeper. Any file upload facility needs to be turned off unless you’re able to monitor daily (wikis that aren’t too busy might be able to keep it a little longer. Mediawiki also seems immune - doesn’t like html files). Upload facilities are often part of wikis, forums and content management systems that support communities. The SnipSnap blog software is especially vulnerable.

And HyperNews needs to be removed altogether.It’s a forum like script, with articles that can be commented on. It allows javascript redirects, and Eugene has been turning any installations into spam heaven for a while now. I notified the creator of the script of the problem a few weeks ago. So far no response.

Hideawhois

Saturday, August 5th, 2006

Whois data is supposed to be the glue that holds the web together. You’re supposed to be able to figure out who owns a website by checking the whois.

Here’s a good site for that: domaintools.

Problem is, lately spammers have turned whois into hideawhois. They use info that’s false, and the registrars let them get away with it.

Figuring out who a spammer really is, has been made almost impossible today, since the spammers know we track them. You’d have to track them back through time in order to pin something on them. Some of us have historical records that make it possible in some cases. And my wiki have enabled others to figure out who their spammers are.

But we need to do something about hideawhois!

Any ideas?