password protection [sic] bypassed;-(
-
Have already suffered an actual ’email injection’ breach because I was unaware that WP-ContactForm v1.1 needed to be updated to v1.4.3 (for WP2.0.1). Bad Behavior v1.2.4 is now also active, it’s currently 412’ing the continuing email injection attempts. MySQL is filling up.
Hoping to quash the current takeover activities have implemented the password protection [sic] feature on the contact form’s static page. Another static page called ‘password’ shows a simple cryptic clue to the password – ie it’ll stop robots/scripts but not people.
The logs show nice people going through the password area and on to the contact form.
The logs show nasty scripts completely ignoring ie bypassing the password area and implementing the POST directly.
How is this allowed!? More importantly what may I do to defend my WordPress sites?
-
“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?”
That shouldnt happen, IF the plugin exists on the same domain.
As for the rest of your questions, Ive no idea how ip-masquerading might affect any of this, but Im guessing your not coveting the only Linux box on the net using it and a veritable cacaphony of mod_rewrite rules ??
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, Robertwhooami—
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, Robertwell, I dont know. You get a 404 when? When its called correctly? Or do you mean a 403 when its called incorrectly, ie through a spam attempt?
Ive never tried to access a page outside of www_root except when using includes (That CAN be done, and is a very good way of handling .config files, but thats another story).
——
The link to the script I provided you will be up until you tell me youve given up or figured it out. The best I can suggest at this point is to play with your settings. Make sure Apache isnt mucking something up, etc..mess with NAT ?? God knows what it might be, but the last rule I provided in this thread does work, if everything else is behaving.
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
Emm… I’ve been trying to follow this thread but it’s way beyond any miniscule PHP skills I’ve got.
Simple question – is there a contact form / plugin out there now (as a result of all the above) which has been modified to sort this problem? If so – linky linky please? ??
Thanks in advance
c0y0te
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
ahh well yes, that would explain it. Thats another problem all together as files and dirs are identical animals to *NIX (in fact, a dir IS a file to *NIX)
You ought to drop an email to the plugin author illuminating him to that ..
Im glad to know that its working as expected now, and yes that should keep a good deal of the crap at bay.
Im happy to help!
PS: For anyone else, renaming the directory and adjusting the paths inside those files, IF there are any will fix the “.htaccess now working” problem.
———I reccomend, of course, doing this for wp-comments.php as well. Any log watcher can notice immediate patterns — they hit the permalink page with “some” referer, and the next hit is wp-comments with NO referer.
I see it all the time, only mine always get 403s ??
Churchtown: a little bit touchy don’t you think? ?? It’s just an expression.
As for PSXMail.. I’ve tried to use this in the past but for some reason it sends 8 emails instead of one when anyone uses the contact form. I did some work with the author but he was unable to pinpoint what was causing it. I suspect it may be something to do with my IIS/Windows hosting versus a linux/apache setup, but the end result was that I had to go back to WP-Contactform instead.
Thanks ‘anyway’ ??
c0y0te
“Thanks in advance” is certainly in common use on web forum first-posts, by way of politeness, I believe.
But getting back to the matter in hand, whilst I’m sure those contact form plugins are workable, there is sometimes a case to do something manually – in this case to make a standalone contact page that merges in with the rest of the WordPress site.
I can see that this is not for everyone, as it means building the page with PHP scripts included, but it might be a rewarding alternative, and there are plenty of resources online on how to do this. It just requires a bit of research.
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
Robert,
Absolutely!
Send him/her here:
https://www.faqs.org/docs/linux_intro/sect_03_01.html
point out …
“A Linux system, just like UNIX, makes no difference between a file and a directory, since a directory is just a file containing names of other files. Programs, services, texts, images, and so forth, are all files. Input and output devices, and generally all devices, are considered to be files, according to the system.”
or here:
https://www.linux-tutorial.info/modules.php?name=Tutorial&pageid=4
The entire page might be a good read for him or her. ??
or send him here, if thats enough:
https://www.cyberciti.biz/faqs/2006/02/linuxunix-rules-for-naming-file-and.php
Point out this:
“A filename must be unique inside its directory. For example, inside /home/vivek directory you cannot create demo.txt file and demo.txt directory name.”
The above statement is true because having both a directory and a file named demo.txt is the same to *NIX.
At the very least, it’s very poor form. ??
Any regular and “educated” *NIX user knows this to be the case. Had I known the plugin extracted to a directory with the same name as the file name, we could have saved 3 pages of posts ??
————–
All that aside, I was looking through your emails to me and I didnt find one where you actually pasted an example where you specified the COMPLETE path to the file.
Had you done that, the mod_rewrite rule should have worked.
No matter, but its a learning opportunity for everyone, myself included.
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, RobertThey’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, RobertSomebody 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
- The topic ‘password protection [sic] bypassed;-(’ is closed to new replies.