New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Thanks for the notice. Set to maintenance mode.
How do you disable access to WHMCS completely while insuring things like cron jobs and trouble tickets (via email) continue to work? Maintenance mode is the only way I know to do that.
Both should work fine. Just shut down your web server, or restart your web server to serve pages from a different location. Anyway maintenance mode is probably fine, I was mostly saying you can also add some mod_security rules to block the exploit; but it may not block it completely (same exploit with different variables/query).
Simple, change folder permissions to 700
Huh? Try htaccess... Search some of the other threads regarding WHMCS exploits to see examples.
Cron jobs don't go through the web server. Why bother using .htaccess when you can just cut off access to the web server completely? If you need to do maintenance operations you can always interact via good ol' SQL.
Oh also...the script cannot access admin area if you use secondary (.htaccess password protection) authentication as per WHMCS recommendations. So they have to know your custom admin directory and get past apache authentication if you are using one or both of those. If not maybe this is a wake up call.
They can read tbladmins and tblclients but passwords are hashed. Anyone know if this exploit let's them change the hash...without access to admin area?
IPN does. It's also nice to be able to use the bulk mail function to inform customers the billing system has been taken offline. As well as continue using the ticket system. Just because WHMCS is out doesn't mean I can take the day off :P
Yep, I don't profess to be an expert in the specifics of sql injection and the like however why are people still:
Serious question, why?
Regardless of those simple steps I still take down my WHMCS when ever a new exploit is released but honestly I don't worry to much I am just annoyed by the inconvenience for me and my clients.
I dont know, perhaps time for a change, probably not but perhaps.
In the mean time please could everyone at the VERY LEAST who has WHMCS open a ticket with something like:
"I am very disappointed to learn that a completely avoidable hole was found in your commercial software, once again you have put my business and the business of many others at risk without good reason.
Please accept this as a formal complaint, I request 3 months worth of credit as compensation and insist that a proactive audit is carried out at your expense by a qualified third party."
Insist it gets escalated to management.
They really need at least 1000 tickets like this as it is very obvious they are content to fix on fail as no one is really challenging them to do better, we just wait with out hands out stretched for a patch in relative silence in terms of action and consequence.
Nothing is wrong with Apache. Just because it's the easiest thing for kids to install doesn't mean, in any way, that it's not a capable and secure web server. Like any other web server, it's only as good as it's administrator.
Well ok I take your point on that, I stand by the rest of it though
Blog update posted - http://blog.whmcs.com/?t=80206
the anti-Apache snobs are annoying I gotta say.
Sorry in hind sight I really don't know why I said that.
Amazing how they're just going to let people continuously exploit each new update.
They should really do what Solus did and get a code audit.
I know if I was Matt I wouldn't be able to sleep easy at night until I did get an external audit.
I agree there!
Any update on a fix?
http://blog.whmcs.com/?t=80206
No but they have acknowledged it..... 21 hours later.
Ya sadly that blog post is all they have said so far.
I just read that moments ago. That blog shows so poorly with all the security related announcements. They need to do something to secure their product better.
A mod_security filter to protect against this vulnerability has been posted:
http://www.webhostingtalk.com/showthread.php?p=8880491&posted=1#post8880491
It's a pretty basic rule set, but we've tested it and it appears to work well.
It should protect against most future WHMCS vulnerabilities as well.
Best of luck to all of you on this one!
Time to jump on the mod_security bandwagon I guess.
I have mod_security and mod_security_crs installed from epel. First time using it so be gentle. I would put these rules in a file and call it something like
modsecurity_crs61_whmcs.confand save it in/etc/httpd/modsecurity.d/activiated_rulesIs that right? I have verified that
SecRuleEngine Onin/etc/httpd/conf.d/mod_security.confIs this going to make anything stop working in WHMCS that I should be aware of?
great!
There are ways around your mod_security rules.
Honestly the best way to to secure your site is to completely disable WHCMS. You would be ignorant not to....
I was able to exploit our whmcs installation but after I put it in maintenance mode not anymore. Need anymore prove? Ofcourse moving it will always be better but it is 'safe'
Why? Because the .py file uses the viewtickets.php page, and you can't use the page anymore when it is in maintenance mode.
HOWEVER i do not know what pages you can use.
if that script use viewtickets.php page how about if we sent 000 permission to viewtickets.php ? our whmcs would still work
Yes, but it can be that same vulnerability is in other pages too. Better let the whmcs people look at it, they are supposed to know their code better. The fact that the patch is not out yet might mean they have many places to look into.
Patch is out
http://blog.whmcs.com/?t=80223
After playing around with mod_security for the first time all I can say is not impressed. It's a real PiTA. Adds a whole new layer of BS to deal with. Just not what I consider a good solution but of course they mean well.
Simply doesn't play well with one particular application I use a lot so kind of a deal breaker for sites that use it. So far up to 12 ID exclusions for this application and still getting 403 forbidden...sigh.
Got it working with WHMCS so that I can do stuff in admin area but only after I removed about 10 secrule ID's. That is just so far. The more I do things in the admin area the more I get that 403 forbidden which means another trip to the logs to find the ID number each time it happens.
Just adds a whole lot more work and I have better things to do.