Hello there!
It’s been a while since last time i’ve been on this forum.
I got notice of a problem with a website that got blocked by the hoster due to compromised files on the server.
A quick check of the files on the webspace didn’t indicate any added or changed files in the recent past. So i took a look at the logfiles and witnessed heavy usage of more than 600k times of the php-file in “assets/components/ajaxform/action.php” in about 3 days.
The site where this happened is running with MODX 2.8.3 on PHP 8.1.
Since i’m using Ajaxform on many projects, i am a bit anxious this is going to happen on the other sites as well.
Anyone else here who had this problem? What can i do to prevent this?
Thanks in advance,
Marc
So where were these “compormised files” if you say that no files were “added or changed in the recent past”?
Was this server used to send spam?
Theoretically this AJAX-endpoint should only run FormIt. The same as it would without AjaxForm.
I haven’t heard of any such problems with AjaxForm.
However, the development of this extra is no longer continued.
Maybe use FetchIt instead (which is the official replacement).
Hey halftrainedharry!
Thanks a lot for your reply.
So where were these “compormised files” if you say that no files were “added or changed in the recent past”?
No, i could not find any changes in the timestamps of files nor folders since the last update i did a year ago.
Was this server used to send spam?
Theoretically this AJAX-endpoint should only run FormIt. The same as it would without AjaxForm.
Yeah, after some further research i got a notice that spam got send via an insecure contact-form. Since there is only only AjaxForm-form on the site, and due to the heavy usage of the action.php, this must be the issue from my perspective.
Maybe use FetchIt instead (which is the official replacement).
Thanks for the hint. Once the site gets unblocked i’m gonna have a look into that. For now i deleted the whole ajaxform-folder and the transport package.
As AjaxForm only executes the FormIt snippet, the problem could also be FormIt (or the way you set it up).
Is the extra FormIt up-to-date?
Did you use any spam protection for this form?
Was there a way to choose the receiver of the email from the front-end?
Is the extra FormIt up-to-date?
Nope, it’s formit-4.2.6, that’s currently being used. So yeah, an update is needed for this for sure!
Did you use any spam protection for this form?
No further spam protection than the standard hidden-input field that needs to be blank, and a kind of honeypot-email input, which must also be blank or empty for the form to validate.
Was there a way to choose the receiver of the email from the front-end?
No, the receiver is only set in the Ajaxform-call, no option to choose the email from the front-end.
I fail to see how the AjaxForm endpoint (action.php) could have been used to alter the FormIt settings or execute any other code.
Is there anything else in the logfiles that helps to understand how this endpoint was used? Any request parameters that were sent?
Is there anything else in the logfiles that helps to understand how this endpoint was used? Any request parameters that were sent?
No, unfortunately not. This attack happened mid January 2024, and the logfiles only go back to two days after this incident. Since i can’t communicate with the hoster directly it’s a bit complicated. I’m hoping and waiting for some more information, since script-based sending of messages is still disabled on the site, though the site itself got unblocked.
Is your form sending reply emails to submitter email that contain email addresses and content? If so, it was likely used for the purposes of spam. Spammers load up submissions with a series of email addresses and often ilnks to nasty sites and fire away.
Other things to do includes rate limiting form submissions, Rampart, reCAPTCHA3 (which doesn’t use box puzzles), JavaScript testing, token checking to make sure the page was actually loaded in the browser or, if the site is of any importance to the org, subscribe to a WAF with rate limiting and bot blocking.
Is your form sending reply emails to submitter email that contain email addresses and content?
Yeah, there was an option in the form to send a copy of the sent message to the submitter. This copy then holds address-information and the website-email.
Other things to do includes rate limiting form submissions, Rampart, reCAPTCHA3 (which doesn’t use box puzzles), JavaScript testing, token checking to make sure the page was actually loaded in the browser or, if the site is of any importance to the org, subscribe to a WAF with rate limiting and bot blocking.
Thank you for all these hints, i gotta dive deeper into that for sure! So far the honeypot worked good, but this really hit me out of the blue.