strange submissions coming through concrete5 form:
Permalink
My clients site is getting spammed with form submissions. The form only has one input, one for submitting your email.
The code is ${@print(md5(acunetix_wvs_security_test))}
But if I try to submit that exact thing through the web form, the form won't let it, because it's not an email address.
So how is this code even being submitted through the form?? And what vulnerability is it trying to expose?
The code is ${@print(md5(acunetix_wvs_security_test))}
But if I try to submit that exact thing through the web form, the form won't let it, because it's not an email address.
So how is this code even being submitted through the form?? And what vulnerability is it trying to expose?
Apparently it has something to do with this tool:
https://www.acunetix.com/vulnerability-scanner/...
The fact it was able to create submissions and get passed the email filter could mean the c5 form has vunerabilities it is getting through.
https://www.acunetix.com/vulnerability-scanner/...
The fact it was able to create submissions and get passed the email filter could mean the c5 form has vunerabilities it is getting through.
Attached is an image of the c5 backend, showing that they were able to make malicious entries:
I have just had a similar thing on one of my client sites - I have a form which can't get submitted without logging in, but the error log is full of database errors from submitting the form.
How's this possible?
How's this possible?
@ob7dev That code is used to check for a PEAR vulnerability that was fixed back in 2011 so unless your host is not serious about security you're probably ok.
When you say that submitting it through the form doesn't work because it is not a valid email, do you mean that you get the browser's message telling you it's not an email?
My guess is, the input has a type of "email" so the browser checks for validity but because it is a custom form, the email is probably not checked in PHP. So to bypass the browser check is easy, you just need to send the post directly to the URL used in the form's action attribute so it goes straight to PHP.
You can always implements verification on the server as well.
@linuxoid do you mean the form is not even visible when not logged in or it is visible but you can't submit?
I saw this before though and the answer was that somebody was login in to the website with an infected computer and the virus on the computer was just trying every form on visited pages so any time the person would log in that form was available to the virus.
When you say that submitting it through the form doesn't work because it is not a valid email, do you mean that you get the browser's message telling you it's not an email?
My guess is, the input has a type of "email" so the browser checks for validity but because it is a custom form, the email is probably not checked in PHP. So to bypass the browser check is easy, you just need to send the post directly to the URL used in the form's action attribute so it goes straight to PHP.
You can always implements verification on the server as well.
@linuxoid do you mean the form is not even visible when not logged in or it is visible but you can't submit?
I saw this before though and the answer was that somebody was login in to the website with an infected computer and the virus on the computer was just trying every form on visited pages so any time the person would log in that form was available to the virus.
Hey @makalay:
I used the built in legacy form maker. Yes it's the brwoser checking if its not a valid email. How should I build the form so that submissions like these don't get through? I could try using the new form builder instead of the legacy one? My client called me and my only answer was "someone is trying to hack the site"....
Since I don't have 5K to use the sql injection tester that caused these entries, how do I check whether or not it was successful in finding vunerabilities?
I read somewhere that seeing those entries get through means a vunerability may have be found, but since it's a bot doing the scan, it won't actually try to break the site. Instead, the person doing the scan gets around to looking at the results and then tries to attack the site. So I had to take the form down incase the attacker comes back to make an actual attack.
I used the built in legacy form maker. Yes it's the brwoser checking if its not a valid email. How should I build the form so that submissions like these don't get through? I could try using the new form builder instead of the legacy one? My client called me and my only answer was "someone is trying to hack the site"....
Since I don't have 5K to use the sql injection tester that caused these entries, how do I check whether or not it was successful in finding vunerabilities?
I read somewhere that seeing those entries get through means a vunerability may have be found, but since it's a bot doing the scan, it won't actually try to break the site. Instead, the person doing the scan gets around to looking at the results and then tries to attack the site. So I had to take the form down incase the attacker comes back to make an actual attack.
@ob7dev, if you want to run some checks you have to override the legacy form controller and, in the function that submits the data, check for every field of type email.
Or you could use an Express Form instead. Email fields are checked for validity automatically.
If you're stuck with legacy forms, you can use the same email validator used by express forms:
If you want, using that email() function you can also check the email DNS to make sure it is an existing email and make validation strict to make sure the email must exist AND not raise any flags with weird characters
the first "true" is for DNS checking and the second one is for "stict" mode
Or you could use an Express Form instead. Email fields are checked for validity automatically.
If you're stuck with legacy forms, you can use the same email validator used by express forms:
$fh = \Core::make('helper/validation/strings'); if (!$fh->email($email_to_check)) { // return some error }
If you want, using that email() function you can also check the email DNS to make sure it is an existing email and make validation strict to make sure the email must exist AND not raise any flags with weird characters
$fh = \Core::make('helper/validation/strings'); if (!$fh->email($email_to_check, true, true)) { // return some error }
the first "true" is for DNS checking and the second one is for "stict" mode
I went ahead and remade the form using the new form builder instead of legacy.
It's the Free Simple Comments add-on (https://www.concrete5.org/marketplace/addons/free-simple-comments/). The add-on has a button to open a lightbox form. The form html is hidden, and the button will not pop up the form unless the user is logged in:
Does it mean the attacker somehow gets the form code and tries to submit it without logging in? That's why it results in a DB error because the user can't be identified.
Should I also disable the submission process altogether if the user is not logged in?
<?php if (!$u->isRegistered()) { ?> <div class="ab-simple-comments-btn"> <a href="<?php echo \URL::to('/login','forward', $c->getCollectionID())?>" class="btn btn-primary"><?php echo $login_btn; ?></a> </div> <?php } else { ?> <div class="ab-simple-comments-btn"> <a href="#ab-simple-comments-form" class="btn btn-primary ab-simple-comments-for-a"><i class='fa fa-comment'></i> <?php echo $post_btn; ?></a> </div> <?php } ?> <div class="row ab-simple-comments-form mfp-hide" id="ab-simple-comments-form"> <div class="col-xs-12"> <div id="comments_spinner_img" class="spinner-img hidden"><img src="<?php echo $img_url; ?>spinner.gif" /></div> <div id="comments_errors" class="alert alert-danger hidden" role="alert"></div> <div id="comments_success" class="alert alert-success hidden" role="alert"><?php echo t('Your comment has been sent for moderation'); ?></div> <form id="simple_comments_form" method="post" action="<?php echo $form_action?>" accept-charset="utf-8">
Viewing 15 lines of 38 lines. View entire code block.
Does it mean the attacker somehow gets the form code and tries to submit it without logging in? That's why it results in a DB error because the user can't be identified.
Should I also disable the submission process altogether if the user is not logged in?
I am sorry to say but that code makes no sense. Why hide the button but still leaves the form in the page? CSS hidden is nto going to stop bots from using it. The form is right there logged in or not so all they need to do is fill the inputs and trigger the form submit. The form should not be on the page at all when not logged in.
There is really no mistery here.
Just move that "if" closing bracket to the end of the form so it's included
There is really no mistery here.
Just move that "if" closing bracket to the end of the form so it's included
I've moved the submit button inside the login if. Now it's fine. I've updated the package.
I can't move form inputs into the if because it throws jquery errors trying to read the hidden field data which is not there while not logged in.
I can't move form inputs into the if because it throws jquery errors trying to read the hidden field data which is not there while not logged in.
That's not good enough. Bots don't need a button to submit a form. What's most important is that you hide the URL in the form action attribute so they can't submit to the DB. You might as well hide all the inputs jQuery doesn't neef
Ok, that's what I've done - now the whole form is hidden if not logged in. I'll update the package.
You might still want to use the code I posted above to validate the email on submission, as an added security step.
https://stokito.wordpress.com/2017/02/23/acunetix-web-vulnerability-...
But why it gets through the form input... I don't know.