churchtown

Have re-thought the gist of the .htaccess and will see what happens overnight.
Also left the Bad Behaviour plugin on-line to derive some further intelligence. Looks initially like the same old same old… It’s late so g’night.
—-best wishes, Robert

Somebody wake up the US military and ask them if they might have left the door open in Texas:

[server access log]

https://www.foo.co.uk 192.138.77.36 – – [02/Mar/2006:23:43:09 +0000] “POST /wordpress/contact-email/ HTTP/1.1” 200 16158 “https://foo.co.uk/” “-“
United States – Texas – San Antonio – hcssa
machinet.jackson.amedd.army.mil

They’re back;~| It’s almost as though I needn’t have bothered to (try to) do anything about it. Just why is it that locks tend to keep out the innocent and merely inconvenience (or less) the not-so-innocent? No breach (yet) but they’re still POSTing (going nowhere) with 200 responses. At least in the Groundhog Day film that chap got ‘things’ done each 24hrs!
—-best wishes, Robert

whooami—-
Agreed. In apologetic explanation, with a multi-site topology here I habitually go for the generic equation so as to be able to re-use it across sites with the minimum of editing for the absolutes. It’s been very much quieter… My next task is to effect HTML stripping from any/all submissions. Have already asked the author of the PXS Mail Form plugin if he will consider including that functionality as a RFE.
—-best wishes, Robert

coyote—-
I don’t consider it touchy to detest the pointlessness and arrant nonsense epitomised by the term ‘Thanks in advance (aka TIA)’ and to articulate my viewpoint *politely* to the utterer (mainly in the fond hope he will desist). That the term is broadcast to the whole world in general, whether they like it or not, rather defeats the implied value of what is said or typed personally to some one in recognition of a kindness, deed or gift. It was not a judgement, complaint or anything awful – just a polite request not to thank me for something I haven’t yet done. We both felt a need to add something to the end of our messages. I thought your’s pointless and you thought mine touchy. Fine. No need for a flame war. I am heartened by the spark of originality imbued at the end of the last message;~)

pcmt—-
Common, widespread or otherwise ubiquitous use of the term on web forum thread starters (aka first-posts) doesn’t necessarily make the term any more meaningful or polite.

—-Getting back to the main thrust of the thread (dealing with the vulnerabilities of contact forms generally)… One of my respondents uses a WP site with a FormMail contact package ie not a specific WP plugin. However, as I’m sure you are aware, FormMail does have its own ‘history’ of vulnerabilities;~/

coyote—-
None of the three flavours of forms mentioned here have done what you’ve observed, perhaps this is because my server is a Linux box. I’m not sure what I can advise, possibly trying the Custom Contact Me/Us (CCM/U) plugin. Its own unique selling point could be considered as being the Me/Us part in that multiple email addresses/accounts are properly configured. Perhaps that specific configuring exercise may cure your site of its 8x emails?

whooami—-
Have advised CCM/U plugin author of the apparent weakness (subdirectory/filenaming w.r.t regex). He seems to be of the opinion that the issue *MAY* also be involved in the specific use of (Mozilla) Firefox and an associated absence of referrer! Do you use FF? I universally use FF but as I am already here then the regex ‘works’ when I ‘test’ it on my own site. Any comments?

—-best wishes, Robert

coyote—-

<…linky linky…>
PXS Mail Form plugin
https://phrixus.co.uk/pxsmail

[/wordpress/wp-content/plugins/.htaccess]
# redirects remote attempts for the PXS Mail Form
RewriteCond %{HTTP_REFERER} !^https://([^.]+)?foo.bah/.*$ [NC]
RewriteCond %{REQUEST_URI} .*pxsmail.php$ [NC]
RewriteRule .* – [F,L]

whooami: the modified .htaccess did not work with the Custom Contact Me/You plugin. I think the regex has a problem with the fact that the plugin installs itself in a subdirectory of an identical name to itself. Hence the lookup/match fails and so does the .htaccess file. I moved over to using PXS Mail Form which uses a single file in the plugins directory. It was at this point that the .htaccess was able to operate correctly (ie with the new flavour of contact form);~) Keeping things under close observation…

The monitoring confirms that the .htaccess is (now) slowing down the criminally-minded activists. They have now had to access the contact form in a more direct fashion – possibly manually. This procedure started earlier this morning. Looks like an intelligence gathering run with non-standard characters. I have unloaded the Bad Behavior plugin so do not have a copy of the contents of what they attempted. So… Yes they’re back. No, they haven’t got anywhere (yet).

On a hunch, yesterday I asked the author of PXS about the possibility of including HTML character removal with the plugin ie bring all submissions down to PLAIN OLD TEXT (my favourite)… Looks like I was somewhat pre-sentient;~/

coyote: I would prefer it if you did not thank me in advance for 1) I may not do anything to help you and 2) it belittles whatever I do do for you.

—-best wishes, Robert

whooami—-

The site’s own contact page gets a 404 now because I’ve moved the custom-contact-email.php file into a non-www-accessible zone (though the file now has www permissions). I put the absolute reference into what I thought was the settings file but the site’s own contact page still gets a 404.

Your own b2 thingummy is referencing the old location of the custom-contact-email.php file and so it gets a 404 obviously.

I think the Custom Contact Me/Us’s author complications with his RANE directory calls may be confusing me. Admittedly this is not exactly hard to do.

Will deactivate Custom Contact Me/Us and go back to using the PXS Mail Form plugin. It uses only one file and ‘appears’ to be slightly more ‘hardened’ than Ryan’s original WP-ContactForm plugin.

—-best wishes, Robert

whooami—
IDEA. Have moved the custom-contact-email.php file into the non-www-accessible area for that ibay. Tried amending that plugin’s pointer (line 63 in custom-contact.php) to the absolute reference on the server and now get a 404. Maybe the author’s RANE stuff elsewhere is interfering. Is this a good way to go?
—-best wishes, Robert

whooami—-
I thought the subdirectory with the custom-contact-email.php file would be the simpliest and least complicated place to put the .htaccess file clause. To check that it IS that file doing the operating I swapped the [F] for a [G] and duly got GONE messages. The file is blocking direct access – fine – but it’s also blocking the site’s own contact form doing its proper job!? Any idea how to sleuth why?
—-best wishes, Robert

whooami—-

Good afternoon… it’s been a bit stressful lately and for somewhat too long. I slept over for 14hrs straight.

I don’t think you could’ve duplicated my scenario, there’s at least one factor you wouldn’t have known but I deal with that later.

Cleaned out the myriad iterations of this stuff dotted everywhere in the names of desperation and experimentation. Yes, I see now that those POST attempts do ‘access’ that file! Because it doesn’t show on my logs I wasn’t aware of that, I’m self-educated and work by myself effectively and pretty much in a vacuum except for the web.

a) Have put your localised clause into a new .htaccess in the same directory holding the errant PHP file to which the POSTing attempts aim. In that location the plugin gets a 403 and so does b2. Not good?

b) Have appended your localised clause to the existing .htaccess file in the (virtual) web site’s base area. The plugin is allowed but so is b2 (though it is held by the plugin’s own checking for required fields). Not good?

c) Have appended your localised clause to the existing .htaccess file in the server’s ‘true’ base area ie for the IP. Situation is the same as in b). Not good?

I’ve a myriad of rewrite stuff that works but never had or wanted to get to selective grips with any REFERER trapping. Is there a well-known minimal version of the mod_rewrite file required? Probably a silly question.

The server (SME Server 6.0.1-10) is a RH7.3-derivative and I expect to have a go at moving to the SME7 (CentOS4-derivative) soon as it’s in a fairly stable pre-RC status at the moment. PHP is at 4.3.8

And finally… a thought occurred to me during my 14hrs of freedom, I have a double firewall here. The pictures are triple firewalled but that’s irrelevant in this case as these thieves are not after my photographs but my server and its broadband connx. Would the REFERER stuff still exist by the time the request had gone through two masqueraded sections? My experiments show that it is the REFERER detection line that is the source of this issue, the URI line stuff seems OK.

—-best wishes, Robert

pcmt—-
Yes, very helpful. I now KNOW that I’m out of my depth. I really shouldn’t be messing with PHP alterations over and above what the original author should’ve been doing… I think it’s going to lead to further problems and/or breaches for which some I may be responsible;~| I’m really not getting very far ahead at all with this issue. Also whooami seems to think there’s something amiss with (my server’s) mod_rewrite functionality which is driving me somewhat nuts as mod_rewrite is desperately important to an Apache server. I may just switch this contact stuff off for all the trouble it’s causing. Thanks for your willingly offered help anyway pcmt.
—-best wishes, Robert

pcmt—-
AFAIK all three flavours of contact forms now prevent header injections per se. I don’t know how to “try a header injection” myself. I’ve some guesses in hand by looking at the data that Bad Behaviour stockpiles but I’ve no real idea how to re-use the information myself either directly on my server or via a remote test facility. I would like to be able to test more intelligently than by a method uncomfortably like pointing a loaded weapon at oneself and saying: “Well… am I feeling lucky?”
—-best wishes, Robert

pcmt—-
You don’t say;~) Anyway that stuff looked self-standing enough to me. So I saved the entire example (between <?php and ?>) as a file named validation.php and called it from the earliest point I could determine in the Custom Contact Me/You plugin. Chose its custom-contact-email.php file and inserted a new line…
?WAS
require_once(‘../../../wp-blog-header.php’);
?NOW
require_once(‘validation.php’);
require_once(‘../../../wp-blog-header.php’);
…which appeared to do the job adequately enough.
—-best wishes, Robert

Not appropriate (site was virtually unreadable with my eyesight).

pcmt—-
I’m not a programmer but I think you meant…
Content-Type (with a colon added at the end)
…but the rest of it was just trouble. My site really does not like whatever logbadrequest() is or should do. Had to delete all the iterations of it out of the test php file. From the loops it looks like the test php file just can’t properly cope with the fact that my site has a non www prefix despite the code looking like it could handle or otherwise test for it. Then it kept giving 403 for perfectly ordinary good attempts actually made from the contact form (let alone anything trickly from a command line POST)… so I’ve dumped it.
—-best wishes, Robert