Contact Forms 444 errors

[GatorShashank]

Hello Folks,

We have been having quite a few AOL spam attempts via the contact forms on many sites. The command files names used in these attempts are like
1. contact.php
2. contact_us.php
3. thanks.php
and others
We have temporarily disabled those on our servers using phpsecurex that we use. All those who see the 444 error might want to examine their code and make sure it does not allow bcc mails to be sent from it. It is highly recommended to use formmail from http://hostgator.com/formmail.shtml instead of badly coded php scripts which are leading this spam.

Any questions can be directed to support@hostgator.com.

[marlies63]

I thought I'd ask a question in here for others to read who might wonder the same thing...

I got the error on one contact.php page, but I have no email form on it. I have some email addresses listed, encoded (probably too simply) with codes replacing each letter (like: news@). Is that also a problem? I have renamed the file, so it's up again.

On another domain/website on my account the contact.php is not blocked, no form their either, the email addresses there are protected (as far as they are really protected) with a javascript that kinda cuts the addy in pieces in the code.

If this causes problems for me/the server/hostgator, I'd like to hear it of course.

[wsuccess]

The error message displayed to the end user is terse, technically formatted, has a misspelling (deteremined), and says that the page is unsafe and was disabled to prevent abuse. It has a single hyperlink and that is broken.

To a non-technical end user trying to contact my business, the error sounds alarmist and indicates that there is something untrustworthy about the company or that we might include (gasp) viruses or other little-understood but much feared topics of public notoriety. Actually, you just didn't like the name of the php page because other hackers can spam off it. Okay, you need to do something to combat the potential problem. But I would really appreciate it as a business owner if you didn't make me sound like an evil-doer (and one that can't spell).

Do you have any control over the message, or is this all hidden in the mysterious SecurePHPx software? If you have some control over the display, could you please clean up the message? I will be happy to offer wording suggestions if desired.

Thank you,
--Ken

PS: I am entering a related suggestion in the suggestions folder about creating an opt-in email list for SysAdmins so you can push information informing us that something has changed in a way that could break a tested, properly functioning, production-status website. It would be kinder and more efficient for your customers than posting a notice in a forum and hoping we happen to look for it that day.

re marlies63:

Scripts commonly have the ability to hardcode the TO: address, but something that is often missed is hardcoding or disabling the inclusion of extra 'headers'. The CC: and BCC: [(blind) carbon copy] fields are part of an email headers and often not blocked or protected. Thus, the spam does go to the intended TO: address as coded in the script, but also to the hundreds of CC'ed addresses as indicated in the additional headers specified during the script attack.

As noted in our original post, there are secure formmail scripts available server-wide that can serve the same purpose.

-David

[mawheatley]

While logging on to move all my sites to a new host I noticed that the pages that this morning were not working have miraculously come back to life!

If this is an admission of a heavy handed 'punish the masses for the errors of the few' action then kudos to you! (It would have been nice to announce it somewhere, rather than just let it happen, but whatever.)

I would like to know: Is this a permanent switch, or do I just have a little more breathing space to implement the move?

Your comments would be appreciated, both by myself all of your other customers who doubtless have experienced the same 'black Monday' as I.

This is not an attempt to punish the masses for the actions of the few. Note that 'the few' as apparently defined by you is not 'the few' as used in the next paragraph.

The Few, being authors of mail sending scripts that are so easily exploited, should not have their software put to use. There's nothing but trouble waiting behind such universally exploitable software. Scripts that check the 'referer' for verification can be tricked with a simple commandline switch to the http POST program in the perl LWP tools. Those that, as previously mentioned, hardcode the to: address do not protect from CC: and BCC: header additions.

It is a bit severe indeed, but I personally believe its better to disable this script globally than forever have our systems listed on spam-support websites. This would make 'The Few', being those who choose to use such insecure scripts against our advice cause punishment against 'the many', being everyone on the server as well as HostGator and the companies hosted on them, by way of email blacklists placed against the server. Since the attacks on these scripts, the support load relating to incoming spam complaints and blacklist complaints from clients has more than tripled. Since the global blockage of the poorly written and insecure script, the support load has, almost overnight, returned to normal.

This is important across the board; time spent on the abuse queue is time not spent on the support queue by a few of our technicians. We have enough staff to handle a normal load without problems, but when a single piece of third-party software causes enough issues to cause delays in support, it simply has to go. It's a hard decision to make when banning specific software, and its not one taken lightly or done at a whim. This decision was made after attacks and exploits on the software had proceeded for 3 days fairly constantly. This isnt just about server security. It's about HostGator and their clients being able to send email to their respective clients. If we continue to allow this broken script to operate, blacklists will not disappear. Instead, they'll grow in number and we'll potentially lose our upstream services. That, of course, would be a Bad Thing for all parties involved.

I see no reason to ever lift the ban on the software at this point. The author did a half-hearted job on creating the script, and needs to come to the realization that 'security by obscurity' doesnt work, especially when the exploitable variables are simply named, and the script's code is open for public review. As I think about it, the script actually has no security in mind, at all.

Cpanel's formmail script has gone through revision after revision to keep ahead of common exploits, and still stands secure to my knowledge. It should be used, as it's tested by time and by fire rather than being tossed together apparently overnight by a random individual that wrote something to provide a solution with no mentality for security and decided to share it with the public in the name that It Works.

We're looking out for the little guy more than it seems at times. Sadly, sometimes this looking-out-for process has to involve stepping on a commonly used script. In the end, we'll all be able to mail our clients and do business with them. This leads to the clients' businness success, and success for everones' businesses is very important at HostGator.

Okay, enough blathering. :-)

-David

[DigitalBids]

Kudos David for looking out for us. However, can you please tell us which scripts caused these problems? Or, a name that we can avoid so that we don't unwittingly try to install and use?

This 'little guy' says thanks.

[jeff_s]

GatorDave, I wonder if you could clarify just how you target a contact form script for disabling. Does it need to have been compromized to qualify, or are you just disabling scripts named "contact.php"?! This is what your first post in this thread seems to imply.

My contact forms are indeed named "contact.php", but I wrote them myself and they are secure. They have been routinely repelling "header insertion" probes from spammers for months now. They also log every attempt to disk, so I can see what's happening.

I do agree that if a bad script is found it must be disabled. And people who are not programmers should either study and learn it, or hire a programmer, or not use php.

- jeff_s

The scripts are disabled by name following the incredible number of copies of these scripts. As I noted previously, an administrator manually disabled more than 100 scripts on sunday evening in an attempt to stop the flood of spam attacks.

I also remember disabling a large number of them on Friday, and more again on Monday. Researching the source of a spam report and locating its script takes a significant amount of time away from support, so the decision was made (broken record mode) to disable the script to increase response times in support.

The following strings are currently blocked in PHPSecureX:

addarticle.php
formmail.php
modules.php?name=WebMail
shell.php
form2mail.php
contactform.php
feedback.php

The modules.php?name=WebMail has been there for a while, and blocks access to PHPBB's webmail module. shell.php is fairly obvious; a common script used to get backdoor access to exploited websites.

The rest are related to the flood of email script attacks over the last few days.

Do not attempt to get around the filters by renaming the script. It doesnt matter how much you try to hide the script, an attacker will find it. Security by obscurity doesnt work. This is clearly evidenced by the boom in security issues related to windows 2000 and some PHP scripts last year.

-David

[pli]

Can I safely assume that these scripts are not being blocked on dedicated servers? I use similar named scripts on my server, but have have seen absolutely no evidence of spaming from them

The scripts are created by "Forms2Go" http://www.bebosoft.com/products/formstogo/ and I have set them up so they can only be sent from the approved url

P

[GatorShashank]

They are not blocked on dedicated servers but still they remain vulnerable or atleast prone to attacks on dedicated servers as well.

[Serra]

They are not blocked on dedicated servers but still they remain vulnerable or atleast prone to attacks on dedicated servers as well.

Another benefit of having a dedicated server! We can police ourselves! The real question is PHPSecureX installed on the Dedicated Servers at all? If so, I'd love to know how to access it.

Originally Posted by pli

The scripts are created by "Forms2Go" http://www.bebosoft.com/products/formstogo/ and I have set them up so they can only be sent from the approved url

I saw that in one of your scripts, I even put a comment next to it that I thought that was really cool.

However, that isn't a protection against Injection. The hacker will use your form that feeds for the FTG script, so the FTG script will not see anything wrong. I've been sticking this into my FTG scripts just above the error_reporting(7);

PHP Code:

// Test for annoyance
foreach($_POST as $field => $input) {

//pulls out any slashes like \n\r in the input.
$input = stripslashes($input);
//checks for embedded mixed format message.
if(preg_match('/Content-Type:/i', $input)) $attack++;
//looks for bcc: in the inputs, if it finds it, likely it is being injected.
if(preg_match('/bcc:/i', $input)) $attack++;
}
//  $email is the to email from the form, I had trouble with a hacker
//  injecting forms with the email address in the domain, this stops that.
if(strstr($email,'mydomainname.com')){
$attack++;
}


if($attack) {
print "You've been detected trying to do stream injection and blocked from further access to this mail form.";
exit;
}
//this is from the FTG script.
error_reporting(7); 


I got this from another thread on the board and modified it a little for my usage. That script automatically set the .htaccess file to block the IP address, but I was unable to get that part to work because of the .htaccess file's permissions. It only worked if I set the .htaccess to 777, which didn't seem very smart.

Try mode 644 on the .htaccess file. It seems to need 777 cause php scripts dont run in your user account's security context. They inherit apache's, which on cpanel systems like ours, is the user "nobody".

The first two digits control user and group access, which normally for htaccess's is your user account. The last digit is for 'others'.

6 is read/write, handy for the owner of the file ;-)
4 is read-only, normal for group permissions.

FYI, to build a permissions digit, use this formula:
add 1 to make it executable
add 2 to make it readable
add 4 to make it writable

thus:
7 is all 3 (rwx: read, write, execute).
6 is 2 + 4 (rw-: read, write, no execute).

Interestingly, you can make write-only files if you like. This is handy for log files you dont want php scripst to read back, or directories a php script writes to (think galleries) but doesnt need to list. It's a bit tricky to get gallery software to control the permissions it sets on new dirs/files though, so its generally not done.

mode 777 on a file is hideously insecure. May as well tell everyone they can modify the file while youre at it ;-)

File permissions are difficult to understand as I know from when I learned to use linux 10 years go. Once you get used to the concept of permissions, its pretty straightforward.

-David

[Serra]

Originally Posted by GatorDave

Try mode 644 on the .htaccess file. It seems to need 777 cause php scripts dont run in your user account's security context. They inherit apache's, which on cpanel systems like ours, is the user "nobody".

I did try 644, but it was unable to open the file for writing. I set it to 777 to see if it was a permission problem or a writing problem, some times it is hard to be sure, and 777 worked fine, so I assumed that PHP couldn't write to the .htaccess file.

Here is the code that I was using:

PHP Code:

if($attack) {  
  $deny = '# ' . date("D M j G:i:s T Y") . "\n";
  $deny .= 'Deny from ' . $_SERVER['REMOTE_ADDR'] . "\n";
  fwrite(fopen('.htaccess', 'a'),$deny);  
  print "You've been detected trying to do stream injection and blocked from further access to this mail form.";  
  exit;
} 


Oddly, this would not work on my shared account, but it seems to work fine on my dedicated account.

Hi,

There's two potentials ways to resolve that on a shared server. A couple are solutions I don't recommend ever doing, so I'd go with this; you can run the PHP script in question as a CGI script (rather than using the .php file extension to have it run as the Apache API), so it will run as your own user instead of the global web server user. After all, the mail script should not get so many accesses that it allows the overhead of CGI to pose an issue (compared to the mod_php module saving that overhead).

You shouldn't need to change the php code for that, other than to add a shebang line at the top of the script (if you don't force a CGI type on another specific file name or file extension to call PHP as CGI, that is). Of course, the script would then be set to the permissions chmod 700, or 750, or 755 to be executable as CGI. Your dedicated server allowing you to write to the file with the default permissions on the .htaccess file probably means it's set up to run PHP in the CGI API.

[bryansmith]

Y'know, I'm almost tempted to keep my mouth shut, but I can't.

When the PHP upgrade was done on the 4th, more than half of my Cpanel accounts suddenly went down. By the time all was restored some of my most active sites had lost a good 4 hours to downtime. (and please don't tell me it wasn't that long because I have documentation to back that)

Once back up we started to slowly but surely notice errors - PHPbannerAds dead, Simple Machine Forums... responses from HG support have blithely told me it's my problem and to go fix it. No warnings of possible errors or required uprgades beforehand, just an arbitrary decision by the Great Hand of HG sweeping over the paltry masses...

Now I've found that the feedback form (NOT a webmail form!) for my auction sites isn't working.

HG's response: It is highly recommended to use formmail from http://hostgator.com/formmail.shtml instead of badly coded php scripts which are leading this spam

Firstly, this isn't formmail and secondly, it isn't badly coded php script, but now it's become my problem, my time, my costs, my customers hassling ME because of this. No warning, no notices anywhere, it's just plopped on my lap for me and my customers to discover for ourselves as time goes by. It's amazing that even Fantastico scripts that HG offers to their customers for them to use are affected.

Now, I suppose I could rewrite dozens of PHP scripts to fix the auction script issue by renaming the offending named file to skirt a highly questionable syntax decision on the part of HG, or I could move to a dedicated server. Given the latter option, the costs, the time to migrate scripts, files and databases, not to mention the DNS changes for 80-some domains, one thing is clear: If I choose that option, HG won't be getting my $$

I've been quite happy with most things up to this point, but this is going too far.

Sorry, but excuses simply don't help.

Had it up to here in Server Hicksville

[ltaylor]

I am running the latest Vbulletin board (not officially open to public as of yet) and as you are aware, there are tons of modifications that can be made on these boards, which I am carefully looking at. One specific MOD is the iTrader. (You guys probablly know about this MOD). Anways, of the functions for this script, holds the ability to give "feedback" in the form of "ratings" which is all done/displayed on the forum. It's not an Email/webmail based script. The file name is called:itrader_feedback.php . I see why I am getting a 444 Error now.

If your not familiar with this script, it is located at vbulletin.org. Then see iTrader


To use this modification properly (and knowing it's not email based) would it as simple as changing the file name/s?

[Serra]

Originally Posted by ltaylor

The file name is called:itrader_feedback.php . I see why I am getting a 444 Error now.

To use this modification properly (and knowing it's not email based) would it as simple as changing the file name/s?

Yes. As I understand it, HG set mod_security to block specific forms names because hackers were scanning sites looking for those names and then expoiting them. I'm not sure I agree with the concept, but it was effective and an increase in security helps everyone on the server.

Keep in mind that mod_security as scans the php code in the files and blocks them using that too. The error log some times gives clues as to what is wrong.

Given the latter option, the costs, the time to migrate scripts, files and databases, not to mention the DNS changes for 80-some domains, one thing is clear: If I choose that option, HG won't be getting my $$

You make it sound a lot harder than it really is. If it was that much work, I would never have done it.

[ltaylor]

Serra,

LOL but.....
Given the latter option, the costs, the time to migrate scripts, files and databases, not to mention the DNS changes for 80-some domains, one thing is clear: If I choose that option, HG won't be getting my $$

You make it sound a lot harder than it really is. If it was that much work, I would never have done it.

The above post and your reply had no relation to me...LOL. Just so you know "I" didn't say the above.

=-------

Okay, well, I'll see how I can re-write the function extention that contains the wording "feedback". I understand why the security function is there with GH, it's a good thing we'll all benefit from and now I know for future with various scripts what to watch out for.

Thanks Serra

[Dano1]

OK, I'm new here and I have a question...

If this problem is occuring in php form scripts, what about addon or installable scripts like SMF forum, PHPBB, Joomla, etc. Is this going to be a security issue with these other php powered tools?

OMG, This is a PHP board!!!

Sorry, I am just curious why these are under attack and if this is going to be a problem esewhere also or is there a reason why these other programs are not vulnerable.

Dano

[slapshotw]

Dano,

This thread is from 2005. If you're having problems open a new thread. Otherwise, don't worry about it.

-Matt

[GvilleRick]

This thread has not been opened in nearly two years. I doubt that this problem is still around. There have been numerous security patches since this thread was begun.