Update: READ the last paragraph of this message!

I did a search to see if anyone has already mentioned this and don't see it so here goes:

This morning while checking my mail server's filtered spam directory I noticed 11 messages that appeared to come from my MT blog. More research showed the spammer used mt-send-entry.cgi to attempt to send spam. They would have succeeded also if not for the fact that I have spamassassin installed on my mail server and it snagged the outgoing email before it could be delivered to any of the 500 recipients in the email. The disturbing part is they would have gotten away with it if not for spamassasin (which I suspect most blog email systems do not have).

For the moment, I took the send entry form off my web pages and removed the mt-send-entry.cgi script. Does anyone have a better solution? Is there a modified mt-send-entry.cgi that would limit this problem? (using MT 2.64)

grrrrrrr.....

Woody

Update: I can now simulate what the spammer did. I've removed details I posted earlier to make it a little more difficult for others to duplicate. I HIGHLY RECOMMEND EVERYONE PROTECT OR RENAME THEIR mt-send-entry.cgi SCRIPT EVEN IF YOU DO NOT USE IT UNTIL THIS IS FIXED. Failure to do so will allow a spammer to send email on behalf of your mail server. It was actually very trivial to get this to happen, but I will only release the details to MT developers/moderators.

Content removed.

see post above.

I tried to track down the ISP but it originates from a dsl line in Mexico - doubt I'll have much luck getting them disconnected. Folks may want to look for 200.78.106.65 in their server logs...

Content removed.

see post above

Woody

It looks to me like mt-send-entry.cgi is a big whopping security risk. It allows anyone to send email to anyone they want. It's a fairly simple process to locally load up the variables then "submit" to the remote system. This is the same type of security hole found in formmail over a year ago.

I'm disabling this script on my server.

Three 4 5 6 more attempts to send SPAM through mt-send-entry.cgi this morning - all from different IP addresses. Of course all they did was send their hack into a modified mt-send-entry.cgi so I could trap what they were doing.

I again, STRONGLY recommend everyone disable this script before your ISP flags you as a spammer.

Woody

How do I disable mt-send-entry.cgi? Simply change permissions?

What ramifications does this have? What does it affect?

Dan

just rename it to something else.

As far as I know, it is only used for readers to send a email with a link to one of your individual entries in your blog to other people.

Is renaming it really enough? Can't it still be used?

Yes, it could still be used - but as with the spam issue involving mt-comments.cgi, if everyone renames their file to something different, it makes the spammers' work a bit more difficult (i.e., they have to hunt for the specific file name on each MT user's site).

Well, I'm assuming that you don't allow viewing the contents of your cgi-bin directory from the web, and I'm assuming you aren't using the mt-send-entry.cgi in your blog. If those are true, then renaming it to something obscure will make it very difficult to use. If you still have a link to the new name from your blog, it is very trivial to find it again.

The only truly safe thing is to remove it.

Woody

Woody,

Do you have a link to your honeypot script for this? I've disabled this, but I'd like to capture the spam myself.

To safely disable the script and not have to worry about someone guessing the filename, add these three lines immediately after the "use strict;" line in the file:

print "Content-Type: text/html\n\n";
print "Disabled for security reasons";
exit;

Alternately, just delete the file.

setting up a trap

All,

This is a bug in the MT code that sends mail using sendmail. If you're using SMTP, you are not, I don't think, susceptible to this. The problem is that the code is not doing enough input validation on the From and To fields that are used in the mail message.

The fix will be in the next version of MT, but in the meantime, here's a fix.

1) Open mt-send-entry.cgi in a text editor.

2) Before line 40, add these lines:



3) Save mt-send-entry.cgi.

I recommend completely removing the ability to inject a custom message into the script. This will remove the incentive to use it to spam people. That way, even after you have a fix, there will be less reason to look for other security holes.

Btrott,

Is this before line 40 for serveral versions back, or just 2.64?

I am still running 2.51, for instance.

Thanks,

Disable the script entirely.

It can (still) be used to, completely anonymously, send arbitrarily large amounts of email to arbitrary recipients with arbitrary message body content.

That's paradise to a spammer.

The only thing the spammer can't get rid of easily is the Subject line, which serves only to sully the reputation of you and your blog.

Disable the script entirely.

Do it now.

You can disable the script completely without needing to delete it.

In the same directory as the script, create the simple text file .htaccess (note leading period) containing this:


The rest may not be necessary:

Go into your apache configuration file (e.g. /etc/apache/httpd.conf) and find the "Directory" section referring to your mt directory, e.g.


Find the line that begins AllowOverride. If it is "all" or has "limit" on the line, then nothing more needs to be done. If it is "none", change it to "limit". If it is something else, append "limit" to the line (seperated by a space).

Restart apache for the change to kick in.

If you do not have access to the apache configuration file then it is probably already configured to allow you to override the settings.

you could also

or

to prevent the webserver from accessing the file.

This is good advice - the send-entry script functionaility (to send a link or page to someone else) is actually built in to most web browsers today, which negates the need for this script at all.

I'm really concerned about the thousands of MT implementations out there - bloggers that rarely (if ever) would come by this support forum - being a spammer's dream. Five more accesses to my spam trap hit my site again today...

Woody

Changing the permission on the file will suffice.

Change them to "600" (read/write by owner only) from "755" (read/write/execute by owner, read/execute by others) -- or whatever you previously had.

That should suffice.

Getting MT banned by thousands of irate ISP's is certainly one way to get their attention.

Running an unsecured formmail script is enough to get your ISP's mail server blackholed by several RBL services. This script is just as bad. ISP's don't like having their mail servers blacklisted ...

Anyone else had spammers show up in their apache logs using mt-send-entry? My honeypot has snagged spam attempts from 44 51 different IP addresses since saturday. AOL users are getting a few less spam emails...

Has anyone tested this? I spent about 15 minutes on it tonight and I'm still able to send mail through SMTP (I didn't try sendmail again)

Woody

Disregard: I just tried it again and it worked - I must have had a typo in the first one..

I'm not sure what the point is.

It's true that the previous version did not validate the "from" and "to" parameters (and hence a spammer could stuff the entire payload of their email into one of these parameters. That way, they could avoid any semblance of the formatting of the email message sent by the script.

But, if they don't mind the subject header and first line of the message-body being dictated by the script, they can send any bloody email message they wish, even with the "patched" version.

As I spell out elsewhere, there's nothing in this "patched" version to discourage spammers from sending arbitrarily large amounts of spam through this script.

As you've pointed out, the basic functionality is already present in any modern browser. The only added-value that this script provides is the ability to act as an anonymous emailer for any miscreant on the internet.

Not that this really changes anything, but it's interesting to note that Yahoo has this exact same problem with the e-mail this story links on news pages off of Yahoo news. I suspect anyone who has any kind of e-mail link has this same problem. On Yahoo's site, I was able to paste an entire 2 page word doc into the "personal message" field and it got delivered.

Aside from banning this completely, I think there are a couple of things that can be done.

First, as Ben suggested, disallow input that has line breaks in, and don't allow a personal message to be appended. Then, modify the scripts to only pass entry and blog ID values through form submission, not the entry titles. Lastly, remove the sender's name from the subject and "From". This does two things:

• increases the "verifyability" of requests
  
• reduces the number of places that a spammer can put the spam content

For example, if you use Yahoo's service, the message is from the Yahoo news service and the subject is the title of the original news story. Only in the body do you have the value that was entered in the form for Sender and sender e-mail.

If the spammer cannot control the subject, and only has a one line in the message body in which to put their content, the value of doing this drops dramatically. Might they still do it? Who knows.

I imagine Yahoo implements some sort of throttling to ensure that their script is not abused by spammers. Throttling won't be of much use here. If you want to send out 10,000 messages, you can find 10,000 MovableType blogs and hit each of them once.

Removing the personal message field (from the CGI script, not from your templates -- which is useless) or limiting it to a certain number of character (not lines!) would be a reasonable solution.

But, once you've reduced the functionality to emailing a URL, anyone can do that directly in their browser, without the "benefit" of a CGI script to anonymize their email.

Actually, Safari can't do that yet. Also, at my day job, most people use Lotus Notes, and their PC's are not configured to correctly receive or SEND mail using Outlook Express. We are strongly cautioned against using mailto links on webpages we create on our intranet.

Then again, how many people actually know that IE will let me send a link to a web page? I've worked with engineers from Microsoft many times over the years and they've often proudly told us all of the simple things that their typical user does not know how to do (like copy a file to a floppy; circa 1996).

Actually, any Cocoa Application (including Safari) can do something better. There's a Service (Safari->Services->Mail->Send Selection) which will create a new email message containing anything from just the URL of the page to the entire HTML content of the page.



That is, indeed, a problem. Solution, anyone?

If you really think that your readers would be interested in sharing your pages with others in that way, why not put up a llittle page called "How to Share" or something, and give details on how to go about it?

Is the content of your site aimed at people who don't even know to use their browser?

I wish that was not the case, but anyone who is making a site for the average person should not assume that they know how to do anything. I would say the average person on the internet "barely" knows how to use their browser. Yes, they know how to find and click on links, but I wouldn't go much farther than that.

The only absolute truth about computer users that I have found is that whenever I have made an assumption about what the typical user can do, I have been wrong. It drives me absolutely batty, but that's the truth.

Obviously no good for webmail users, but how about just something like this:

As has been pointed out earlier in this thread, Yahoo's News site has this same problem, as do (I would assume) most other sites that allow you to email a story to a friend. There are many of them--it's not just Yahoo. So a spammer could just as easily use any of the most common news web sites to send spam, and there are enough of them that they could do so without throttling being a problem.

In fact, I think that this is a problem with any send this story/article to a friend functionality--all of them allow you to specify a message, and all of them allow you to specify a To: address.

The patch that I sent prevents a spammer from inserting rogue headers into the message, including multiple To: headers. It should prevent that for both sendmail and SMTP, no matter whether SMTP was even vulnerable to the multiple header problem in the first place.

Do these other sites allow one to inject arbitrary content (the message parameter of your CGI script) into the email message that gets sent?

I guess I haven't examined enough of them.

But this is very similar to the "online greeting card spam" problem that was so prevalent a few years back.

Except -- again -- rather than a few, "professionally-managed", sites which could potentially be used as conduits, we have tens of thousands of individual blogs, run by people who may or may not be savvy enough to notice when their site is being abused by a spammer.

Yes, the majority of the other sites I've looked at do allow you to add a personalized message.

We've added a post to the main MT page explaining the situation, including an updated mt-send-entry.cgi script which: does not allow the header injection; does not allow multiple recipients; allows a maximum of 250 characters in the personalized message.

Geez...Thanks for the info. I didn't even realize. It seems ripe for abuse. I removed it, as its not an integral part of my use.

BTW...I found that virtually every site with a 'email this article' allowed me to append multi-paged spam using a false email address.

OUCH. This seems an Internet wide problem, again, thanks for the heads up.

OK, I'm going through this thread and there are a couple of things I would like to know:

1. As I go to my stats page, I see that I have almost 1000 hits on both my mt-comment.cgi and mt-tb.cgi. Could this mean that someone is trying to use it for spam?

2. In other words, how can I tell if my site is being used by spammers. What kind of info should I be looking for on my stats?

YES! I FOUND IT!

I had no idea that in SAFARI if you HIGHLIGHT content on a web page, the services section will open up and you will be able to send it as an email.

EVEN BETTER! I have KUNG-LOG and DEVONTHINK. They both are enabled once you do this along with SIMPLETEXT and STICKIES.

HURRAH!

Not to let this drift too far off topic, but -- as I said -- Services work in any Cocoa application. In most applications, the Service in question will just prepare an email message with the selected snippet of text.

What's cool about Safari's implementation is that what appears in the email message is the actual HTML (complete with images!), rather than the rendered "text" of the page.

Yea, but I've never been able to make it work.

The whole point of my post is that while you said "All cocoa apps have services", I actually explained how the services are enabled.

I used to be a tech writer. You know Alice from Dilbert? i know her pain. Techies may be gods but tech writers are the ones that make sense of them

Sorry, I missed that.

Most services act on a "selection", whether that be a selected block of text, a file selected in the Finder, ... whatever.

Those services which don't apply to the type of data (a block of text, say) you have selected are grayed-out in the Services menu.

If you haven't selected anything, then all the services are grayed-out, because there's nothing for them to act on.

It is a source of some entertainment to wander through the User Interface(s) of your Applications, selecting stuff and seeing what services are available to act on that type of data.

You need to get out more

One last note from me to illustrate how important it is for folks to remove or fix this script.

My spamtrap (honeypot) allows the spammer one attempt to send spam. It logs the email they try to send, then exits, making the spammer believe the email was sent. It then blacklists the IP address they use, so it is a one shot deal for them *per* IP address.

With that in mind, to date there have been 125 IP addresses attempt to send email through my server. In my conversations with ISPs, the ip addresses in many cases appear to be servers that have been compromised, unbeknown to their system administrators. The 125 emails that were trapped consisted of 62338 AOL addresses (not a typo) and would have resulted in my mail server trying to email those messages out. Who knows how many there would have been if I hadn't blacklisted each ip address as they occurred.

I'm off to search for a tar pit for iptables...

Woody

im with you man. People that send that stuff are like babies. I mean some of us have business's on the web and they take the clothes off our back. god help us

Which version of MT had this bug?

Versions below 2.65 - some versions of 2.64 do not have the bug, if they were downloaded after 11/26/03.

How can I fix it? I remember seeing a quick easy way somewhere, but I can't find it (Google yields iffy results).

EDIT: nm, I was thinking of some replies in this very thread