At 1:02 PM -0700 4/15/02, Andrew Daviel wrote: >True, security through obscurity is not real security. But we're not >trying to block a determined person from sending one piece of mail, we're >trying to make it not worthwhile for automated abuse. Currently, many >formmail scripts are found by scanning for them, just by requesting >/cgi-bin/formmail.pl. As another correspondent pointed out, renaming >the thing to cgi-bin/formmailtoo.pl would thwart this. >While the script is known, and in a known place, the form is not, and >can have arbitrary structure, and be in an arbitrary place. To find these >in an automated fashion would require a search engine able to search >on HTML elements (rather than visible text). Then the hidden field >would have to be found (different for each site). This is somewhat >more complex than just trolling for cgi-bin and would I think >deter most spammers. I think you are massively underestimating the determination of spam software writers. First of all, they certainly read these lists--so they'll know about such approaches before you've even deployed your solution. Secondly, you are talking about people who think nothing of stealing credit card numbers and using them to set up one-shot accounts. Last month a spammer who got shut down sent mail threatening to rape my wife. We aren't dealing with script kiddies. We are more and more dealing with out and out criminals engaged in theft of services and money. Some of the people for whom they are sending email may not be in that class, or realize what they are supporting--but at the core are people who are dead serious about this. Making their job just a little bit harder is not going to be sufficient. What bothers me about your solution is something it has in common with most anti-spam legislation. You're looking at solving the current problem. What you need to *also* do is consider what the spammer's reaction to your solution will be. Let's assume that everyone running formmail switches to a new version as you describe *and* renames it. (Not likely, you'd be amazed how many people don't even rename the "webmasterat_private" email link in their FrontPage template.) You've just created a problem for the spammer--you've closed a nice untraceable (or at least hard to trace) spam venue. Have you stopped them? Of course not, they just have to work a little harder. The question is--where will they move next? In detail. 1. Rename the form As you say, there are programs out there that just hit a site to find out if it has formmail. They do this because it's the fastest way to find it. However spammers also run spiders to find email addresses. Those spiders *definitely* know how to read HTML (not to mention hacks like "nazgul at somewhere.com"). How long would it take to modify those spiders to find formmail scripts? An hour maybe? 2. Use a custom-per-site hidden field Is this custom per-isp, or custom per site? If the former then you might as well go back to hard coded config files--they are more secure and no harder to administer. If the latter, you've just made life easier for the spammer. But in any case, this is no harder than the first problem. Now when the spammer scans for formmail scripts he also scans for the code. In his database of formmail scripts he now has to also store the code for each one. I'll give that one four hours of coding. 3. Throttle the script Spammer then customizes software to play round robin with formmail scripts instead of just using one at a time. They already have learned to randomize the recipient lists (some spam filters check for alphabetically sorted addresses as an indicator that this may be spam, and some mail servers block incoming messages if there are too many bounces), so now they have to randomize the formmail usage. I'll be generous and give that 8 hours of programming. 4. Set a cookie with a webbug Ignoring the fact that this may block many modern browsers which block webbugs from setting cookies, it just means that the spammer needs to fetch an image (well, the headers of one) before calling the script. The info needs to go in the database (four hours) and the code needs to be added to the spam software (four hours). So, for three days of coding a spammer now has a system that can bypass your fix. A month after ISPs have started installing it, it starts to get broken. Does the spam go as fast? Nope. But given that my spam load appears to be doubling every year, I don't think we've done much to slow that exponential curve. I'm sorry this comes across so bitter, but I'm currently bouncing 5-6 million pieces of spam every year--to accounts that do not, and have never, existed. I'm *very* worried about the unintended consequences of half-way solutions. >The only other solution I can think of at the moment, would be to >give the HTML authors a private directory that they can write to - either >outside the Web directory, or password-protected. >The form script could then read the recipient list from a file >(directly, or over the net with a suitable client). >It would have to figure out the >filename from the referer, or from a hidden field. 1. The ISP provides a password-protected form where the web administrator can login and specify the valid recipients. It updates the config file for that site's version of formmail. To break it, the spammer needs to break the password. You can further limit damage by restricting the number of recipients, and the number of changes that can be made within a certain amount of time. Such a script should of course ship with formmail, configured for multi-site use. 2. Have formmail look in a text file on the site for the list of recipients, one per line. Tell the web admin how to create the file. (In some ways not as safe as #1). But let's back up a minute. Fundamentally you're trying to fix a tool that wasn't a good solution in the first place. Forget form mail, it's a lousy way to get data from a form to a client. If it's a "hello, how are you" message then an email link would have worked better. If it's data, then having the web admin cut and paste from email to his database is painful and doesn't scale. 3. Do what I do with my web clients. When someone submits a form it's stored in a comma-separated file and notification mail is sent to a single email address (also configured via the admin interface). The web admin can then come to the site and download the file into their favorite database/spreadsheet whenever they want. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ nazgulat_private I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Apr 15 2002 - 17:13:17 PDT