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.
WHMCS vulnerability: Google Checkout module
From http://www.webhostingtalk.com/showthread.php?t=1214407
tl;dr:
Confirmed this is indeed an issue. We had someone add funds via Google Checkout / Wallet and then apply the funds to their purchased service. The payment posts to WHMCS and all is green except that the transaction is fake and doesn't show in Wallet. Luckily we verify all orders/transactions.
This happened to us yesterday too. Posting it here for more coverage.
Comments
Thanks !
another reason to use hostbill?
Thanks.
Another reason not to use Ioncube-encoded software.
Not really. cleanout of gateways, and other modules and a few other things to secure our whmcs further and that's all really.
WHMCS has had years of testing, and it's only occasionally that a bug, or vunl pops up.
Thanks
Thank you for the heads up. I have disabled it.
Luckily we disabled Google Checkout today and added PP Pro.
@winston
Hostbill has some slick ui features, but the company and support seriously suck based on my experience. Just try contacting their sales.
Being backed by cPanel now, you can at least be assured of some kind of response from WHMCS related to security issues of which there will likely be many.
I got an order from my private testing billing system (which has all working automation module), he ordered and pay $0 for the product I set at $50, I asked him how did he do that and he said he used a Firefox add on...
Is a fake invoice number associated with this issue?
Not a fake invoice number, but instead, the transaction ID isn't a bunch of random characters like a normal Google Checkout transaction ID, the transaction ID is the invoice number.
I saw it as well, it's been disabled on my end.
Thanks for the warning. Been kicking around the idea of enabling it, I'll hold off a bit.
I disabled the callback file so clients can still place orders and make payments but we have to manually verify the payments.
great, each month we get new vulnerability in WHMCS, wtf
Though I'm wondering when will the WHMCS team officially acknowledge it, to me it's not smart to wait until there's a fix before notifying customers, rather should put customers on alert to maybe disable automatic processing of funds to that module until a patch has been released.
I've had nothing but rapid responses and good support lately.
Thanks for the heads up!
Advice to those who had it on, go review all your emails showing customers changing payment options, I found 4 where they changed it to paypal after paying via google.
Google Checkout was too much of a CF anyways, I at least, had to go click the merchant link to get a login that would take me to the right place.
Thanks, now I can take advantage of this.
Useless if you actually use the vulnerable module.
Only occasionally? I don't know when it became acceptable for software to be full of vulnerabilities (but I suppose that has become sort of a standard here with the crap software available in the hosting industry). There is absolutely no reason why there should even be a single vulnerability in WHMCS whatsoever, even moreso because it's billing software. That it has had "years of testing" (which doesn't mean much for constantly changing software, by the way) only makes it more worrying.
Additionally, I don't think you even understood the comment you were replying to - the software being Ioncube-encoded means that you cannot 1. review the code in a security audit to ensure it's safe 2. patch the code when a vulnerability is found and WHMCS has not released a patch yet.
There will always be vulnerabilities especially when those modules connect to 3rd party systems. But that being said, I remember the last time WHMCS was exploited and most of their server exposed to the world, some of the coding seemed very low-quality for PHP.
When Microsoft started writing software? ;-)
Complete bullshit. High-level languages like PHP are extremely easy to write secure code in, if you put some effort into it. It's not like C, where it's fairly easy to overlook a security mechanism.
EDIT: Additionally, what do "third party systems" even have to do with it? It really doesn't matter whether something is a third party system or running locally. Just don't implement things you don't understand.
You must be a freaking millionaire to have written a PHP-based payment API that's truly unexploitable.
And yes I agree that PHP, Python, Perl, Ruby, etc can be written quite securely with the inputs/etc sanitized and so forth if the developer actually spends the time for it.
Far as 3rd party goes, most of the time it's not normally an issue since things like google checkout/paypal requires a callback to the master site for verification of the transaction. I haven't seen the details of what the plugin is doing incorrectly for google checkout so I cannot comment on that exactly. I mainly say, the more factors involved, the more likely it can be exploited/made-vulnerable. Perhaps what I said is that there will always be the possibility of vulnerabilities in the future, you cannot simply write a billing system and expect it to be secure forever, and not all exploits/vulnerabilities are at the due of how it was coded.
That being said, if the google checkout vulnerability in WHMCS was attributed to sloppy php coding on their part for not sanitizing or correctly verifying/validating with the payment gateway... then jesus f. christ...
We're talking about WHMCS here. WHMCS is the API client, not the API server. Not exactly comparable to writing a "payment API".
Additionally, I fail to see what any amount of money ("millionaire") has to do with code security. I have not had a single security breach in my history of developing software (and it has definitely been attempted), and I live off a few hundred bucks a month.
There are only really two options:
I'd say that the second option is almost certainly what's going on, in which case WHMCS is fully responsible for the issue, and all this could have easily been avoided. A payment processor API isn't really any different from any other kind of API, and APIs are typically ridiculously easy to implement.
Then again, we will probably never know, because WHMCS Ioncube-encodes their source code, and as such we can't determine for ourselves whether the software we rely on to handle invoices and payment processing is secure or not. Yay for Ioncube.
What I mean to say, is if you advertise your code as un-exploitable, no vulnerabilities, impossible to exploit, yada yada, you could be charging more.
Also just because it hasn't happened, doesn't mean it won't happen. Your code is only one factor in possible exploits.
I thought some of the code was exposed during the last server compromise they had earlier in the year. But far as being responsible... gota love their terms of service saying they're not. (For that matter, does HostBill claim responsibility for exploits either? such as reimbursing you for any credits/monies lost due to it?)
Off Topic note: it's kind of odd that a company backed by Cpanel seems to be less secure than a smaller staffed competitor.
No, not really. Why not? Because of people that believe "a few vulnerabilities" is normal and a fact of life. For example:
Result: it's much easier to just not care about "those few vulnerabilities", people will pay for your shit anyway. Welcome to capitalism.
Oh, of course. But if I can run a site that hits the Alexa 10k at some point, and is home to quite a few controversial press releases that make it a constant target of DDoS and other nastiness (such as literally constant attempts to breach security), and it stays entirely without compromise... I'd say that it's very well possible to write secure code.
@Joepie91 in a nutshell, given the reasources behind WHMCS, there's no excuse for the level of failure they've exhibit, and I agree. I think most people either 1) try to make their own workarounds for known exploits (or possibilities of it by manually verify orders/payments) or 2) Live with it because they've grown too dependent on it and just call it cost of business (mainly cuz they can't code..., not everyone can hire their own personal developer).