**HIGH PRIORITY** Security patch released. Please Read!!

[Patrick]

Priority:
Critical

Risk:
Your entire hostbill database is at risk.  A user can command hostbill to dump the hostbill database to a 'txt' and download the dump revealing all customer info, tickets, private information.

Versions Affected
All versions up to 4.6.0

Download:
https://hostbillapp.com/clientarea/patches/hostbill_patch4.6.0_4324.zip

How to apply the patch:
Simply copy the includes/ directory to your existing hostbill install.  Overwrite the existing files. **You can ignore the templates directory as it's empty in the patch**

Files Modified:
/home/user/hostbill_install/includes/cpuupdate.php
/home/user/hostbill_install/includes/components/mailimport/class.mailimport.php

Other security measures:
Please read Additional security steps

[nibb]

I don´t get it. The templates folder in that patch is empty. What for?

Also, do you think its ok to actually not have the cpupdate.php at all in my installation? I will never use the auto update future, and I prefer all features related to it to be turned off or gone.

[Patrick]

The cpuupdate.php file i believe can be renamed or back it up and delete it.  It's a special module that based on user cpu load, hostbill would email the customers that they are using excessive resource usage.  That's what i believe it to be.  I'm 99% sure it is.  Something KBKP Software released about 7 months ago.  I've never used it, never plan to.  I doubt many even do.

Edit: I didn't even look in the templates folder, you're right it is empty.  So no need to upload that.  It's what is in the other folder.

[Patrick]

I can't find where it was implemented as a new feature but i know it was.  I believe a bug fix was done for it here on the screenshot.
I don't even know if that bug was related to it but i know that's what cpuupdate.php is for, at least pretty sure

[nibb]

I assumed it had to do something with the auto update feature in hostbill.

Otherwise it makes no sense why its in the exploit, which seems to be execute exactly that, the backup function without authentication dumping the whole database.

I did deleted it and nothing was affected. I will keep it gone in the future as well as I see no need to it.

I stand on my point that we should investigate an encryption software for databases like Gazzang or Vormetric.

This will surely not be the last security problem, with anything database and PHP im sure there are potential SQL injections vectors not discovered yet, not to mention any new update can introduce them.

We should try to test compatibility of hostbill without of this products that encrypted database. Im just glad I never had setup some VPS/Virtualization features in Hostbill. I do not feel comfortable putting server root passwords into the software at all.

When I started using XenServer, there where no control panels for it. I waited over 2 years and nothing happen, so back then I created my own control panel for end customers, its very nice and I took extreme measures for password to the point they are saved in a locked 256 AES database, which is always closed, only when certains operations are done, like rebooting a machine, it unlocks it from a specific system with a remote key for a few seconds. So even if that server is ever penetrated the databases is safe.

Now, why in the world would I stop using my own custom solution and start saving root node logins (which it seems to require for XenServer) into a PHP/MYSQL database which also happens to be open to the public is just out of my mind.

Sometimes I think I should just try to turn my solution into a commercial software and sell it because im amazed on how little to no security companies take in this regards, I understand automation systems needs passwords, but keep them like WHM at least with a key limited to API features, saving server passwords in MYSQL is just insane if you ask me. Even until recently hostbill did not even hashes this safely at all.

Is there any other work around in hostbill for this? Maybe even separate databases, one of for users, one for automation, so we can keep this apart in different servers, one locked down.

I just can´t believe how sloppy everything is. I could come up 10 ideas better for this. Sure, it would make the product more complicated, not as easy as now, just install it on any host, but it would be way more complex in terms of security.

Also, since I assume Hostbill will never do this, I expect at least one of its customer to do a vulnerability scan on his install on each new release, its the only way we can trust someone reports a problem. The more people target their install, the more chances are one or another finds something to be reported.

I did so on some McAffe scan and hostbill fixed them before. So its a question of trying to penetrate your installation and see if its working. Every new update can introduce or reintroduce previous problems so its a mouse and cat game.

[iso99]

Hey guys,  I'm confused with the patch. I thought it was also applicable for versions below 4.6 but the versions file says otherwise. I am not ready to upgrade to 4.6 yet seeing that it has many ticket bugs at the moment. Can I still apply this patch?

[Lawrence]

@Iso99 - It's safe to just delete the /includes/cpupdate.php file in your case. If you don't automatically suspend users for going over their bandwidth, then you're fine. Also, cPanel does this naively, so the module is unnecessary.

[Patrick]

Hey guys,  I'm confused with the patch. I thought it was also applicable for versions below 4.6 but the versions file says otherwise. I am not ready to upgrade to 4.6 yet seeing that it has many ticket bugs at the moment. Can I still apply this patch?

That was my bad, poorly worded.  I fixed that.

[iso99]

Oh okay thanks, I don't even use that feature.

[Patrick]

I don't know why but it's important to know they also included "class.mailimport.php" in the patch, so i'd still recommend updating that file.   I've updated the original post with the file structure and files modified. 

Edit:

I completely revamped the original post.  Many spelling issues, i can tell i rushed it.  It's more detailed and should help everyone some.

[nldaniel]

Hi All,

Does anyone know whether this is in the wild and/or any signatures we can search for to determine whether we have been exploited?

After all the big changes we stayed back on 4.5.x and kept an eye on the changelog (which specified no security fixes!).

Another thing is we nearly thought their email out was a hoax because the URL link actually went to a click-through traffic service, why would you do that?

[Lawrence]

Does anyone know whether this is in the wild and/or any signatures we can search for to determine whether we have been exploited?

There's no way to tell you've been exploited OTHER than the fact that there may be a database dump in your /templates_c folder. I'm not sure if this is true, but I can't see any other way.

Another thing is we nearly thought their email out was a hoax because the URL link actually went to a click-through traffic service, why would you do that?

To track clicks, other than that I don't know.

[dediserve]

The default install is vulnerable, we tested extensively on our dev install.

[dediserve]

You can also search for the access / expoit string in your logs - we saw a few dozen attempts from various IPs!

[Lawrence]

You can also search for the access / expoit string in your logs - we saw a few dozen attempts from various IPs!

I've seen a few of those as well, definitely not a fun thought.