looks like the {php}evaL(base64_decode are returning

[easyhosting]

Looks like they are starting again with the {php}evaL(base64_decode attacks on support tickets.

 

I have had 2 today both from Pakistan (well thats where the IPs are from)

[inmn]

Couldnt you filter those via Exim?

[easyhosting]

Couldnt you filter those via Exim?

 

Exim is the mail server, these are being send in pre-sales tickets, so has nothing to do with exim or mail server

[imaticon]

You could use the awesome hook system from whmcs:

 

http://docs.whmcs.com/Hooks:Support_Tickets => TicketOpen, validate the content with "message" variable and manipulate.

 

Regards,

Marco

[wsa]

Yes it look like they start again I got 1 from Malaysia

[And then there was one les]

If you are hosted on a cpanel server install mod security and you can filter them at the firewall, the request will be rejected.

[Si]

If you are hosted on a cpanel server install mod security and you can filter them at the firewall, the request will be rejected.

 

Can you elaborate on how you would do that exactly please?

I only allow site visitors to raise tickets via the browser (not email).

[easyhosting]

If you are hosted on a cpanel server install mod security and you can filter them at the firewall, the request will be rejected.

 

will not work as the strings are different on each one

[LDHosting]

You could use modsec to filter {php} or base64decode, though that may raise some false positives.

 

Could you not use a hook to block them?

 

http://www.webhostingtalk.com/showpost.php?p=7882265&postcount=67

 

EDIT: Updated code to prevent issues with email template saving

 

    $file = pathinfo($_SERVER['SCRIPT_NAME']);
   $callingScript = $file['basename'];

   $checkvars = array(‘subject’, ‘message’);
   foreach ($checkvars AS $checkvar) if ($callingScript != ‘configemailtemplates.php’ && strpos($_REQUEST[$checkvar], ‘{php}’) !== false) die(“We’re sorry, but you cannot use \”{php}\” in a ticket submission. If you do have a legitimate issue, please press the back button in your browser and then change any instances of \”{php}\” to \”(php)\” so that your ticket may be submitted. Keep in mind that neither {php} nor (php) will function.”);

Edited August 16, 2013 by LDHosting
add modified code

[wsa]

I have create a small module also that you dont need to do nothing buy install it

[And then there was one les]

Install the mod_sec plugin to allow you to manage the rule sets, Download the latest mod_sec ruleset it should already have the rule in place that blocks the request. you just copy and paste the rule set into your mod_sec plugin.

 

If you are using any firewall you should always keep its definitions fresh and mod_sec is no different.

 

- - - Updated - - -

 

will not work as the strings are different on each one

 

It doesnt filter the string, it filters a required part of the string, base64_decode, if that is present in the request it is rejected. Doing this via exim or mod_sec has an added bonus, you can ban an ip at the server rather than at application level.

[And then there was one les]

I believe the patch released in 2012 resolved these issues though, and its included in all new updates. it doesnt prevent a submission but i believe it does prevent the php executing.

 

That said, i see no reason for not using mod_sec, if these are being submitted there is just cause to block the user, they could try other methods of attack that you can mitigate.

Edited August 20, 2013 by CDJ Hosting

[liz926]

You can also try this free module http://www.hostthebest.com/ticketfilter.php no licence check need