GreenValueHost forced password reset - Security breach?
- Thread starter MannDude
- Start date
- Status
Maybe my "Marine Corps Grunt Brain" still doesn't understand that GVH is saying it was whmcs cronjob that caused the reset? How are you so quick to say it was the automation cronjob in whmcs that reset the passwords? I looked at the cron.php and look encrypted to me with ioncube. Do you have a decrypted version? Did you go through the code to see where it if even makes a call to the database saying reset the passwords? Im just wondering!
Aldryic C'boas
The Pony
Good to hear there are secure alternatives now (and have possibly been around for awhile - I admittedly have not looked into automated payments, especially with cards, on WHMCS in quite some time. We don't offer this solely out of distrust of relying on third party software to handle such sensitive information) - though to be quite honest I doubt an amateur operation like GVH would use anything above 'host-in-a-box' panel defaults.
That's their official story? That the automated cron caused the reset?
texteditor
Premium Buffalo-based Hosting
@aldryic
"said: Just an update, as of now we have no evidence of a "hack" it looks more like a bug in WHMCS as the password resets were sent in line with the Cronjob, we will escalate to WHMCS to see if they have a better insight"
"It appears that WHMCS ran it and its in line with the timing of cronjob finishing another process."
From LET
"said: Just an update, as of now we have no evidence of a "hack" it looks more like a bug in WHMCS as the password resets were sent in line with the Cronjob, we will escalate to WHMCS to see if they have a better insight"
"It appears that WHMCS ran it and its in line with the timing of cronjob finishing another process."
From LET
DomainBop
Dormant VPSB Pathogen
Yep, and they're doing a Fabozzi and blaming it on the software maker.
Quote from their new "Vice President of Operations" :
http://lowendtalk.com/discussion/26078/gvh-password-reset/p2
Aldryic C'boas
The Pony
Blaming the Cron reeks of bullshit.
For starters, the cronfile is ioncube'd, unless they're pulling a Fabozzi and using cracked/unlicensed software. The cronjob also has a very strict list of items to run, and modifying user accounts is not among those. The only way the cronjob would've issued password resets, is if some dumbass placed an /includes/hooks/ file to do so.
The cron is also only intended to be run once per day. Which begs an explaination for why Sure, you could set the cron.php file to run multiple times in one day - but then *every* client will receive duplicate emails regarding due services, invoices, and so forth. And let's not forget that WHMCS logs all actions taken - if this were actually a bug in the cron, the logs would've given evidence of such immediately, and there wouldn't be any uncertainty at all.
For starters, the cronfile is ioncube'd, unless they're pulling a Fabozzi and using cracked/unlicensed software. The cronjob also has a very strict list of items to run, and modifying user accounts is not among those. The only way the cronjob would've issued password resets, is if some dumbass placed an /includes/hooks/ file to do so.
The cron is also only intended to be run once per day. Which begs an explaination for why Sure, you could set the cron.php file to run multiple times in one day - but then *every* client will receive duplicate emails regarding due services, invoices, and so forth. And let's not forget that WHMCS logs all actions taken - if this were actually a bug in the cron, the logs would've given evidence of such immediately, and there wouldn't be any uncertainty at all.
That's a pretty bold claim to make when you don't actually know what the problem is. Unless the prior deduction of 'testing on a production platform' turned out to be true, and now you're just needing a scapegoat to make you look less ridiculous.
The real truth is they either got hacked or they were fucking around and caused the email to go out. I would be very worried if I was a client and that they have turned off the md5 on all users passwords.
Thank god I never signed up with this horrid provider they have been a joke since day 1!
Thank god I never signed up with this horrid provider they have been a joke since day 1!
Does this actually send out password reset emails to all clients?What's this button do?!
I have no idea.
DomainBop
Dormant VPSB Pathogen
The WHMCS documentation doesn't say whether it sends out emails but if that option was enabled it poses a huge security risk (mainly because idiots tend to use the same password everywhere), and GVH clients should seriously consider closing their GVH account because there is no legitimate reason why an admin of an unmanaged service would need to see the passwords of all of their customers
From WHMCS:
I don't see "password resets"/"change in MD5 ", etc. on the list of cron jobs...
- affcommissions
- affreports - First day of the month only
- backups
- cancelrequests
- ccexpirynotices
- ccprocessing
- clientstatussync
- closetickets
- domainrenewalnotices
- emailmarketing
- fixedtermterminations
- invoicereminders
- invoices
- latefees
- overagesbilling - Runs on the last day of the month only.
- suspensions
- terminations
- updatepricing
- updaterates
- usagestats
- skip_report
- http://docs.whmcs.com/Crons
I don't know how Mandrill works, but does it add headers that show where (what IP) the email was sent from?
I am wondering whether it was their main WHMCS that sent out the emails, or another one (say their dev WHMCS, where other data from non-customers could have been imported).
I am wondering whether it was their main WHMCS that sent out the emails, or another one (say their dev WHMCS, where other data from non-customers could have been imported).
Aldryic C'boas
The Pony
Did a bit of testing on our WHMCS dev platform..
Original password, with md5 enabled:
mysql> SELECT password FROM tblclients WHERE id = 1;
+----------------------------------------+
| password |
+----------------------------------------+
| 2ae51bfc8fec24a86a8cbbffc345ccd2:%!Rd% |
+----------------------------------------+
1 row in set (0.00 sec)
Stored password after checking said box, and saving:
mysql> SELECT password FROM tblclients WHERE id = 1;
+------------------------------------------+
| password |
+------------------------------------------+
| I3noCCtmFPCtEFgyxrKVKyPcgctuttmdv4ooxFbV |
+------------------------------------------+
1 row in set (0.01 sec)
Stored password after re-enabling md5, and saving again:
mysql> SELECT password FROM tblclients WHERE id = 1;
+----------------------------------------+
| password |
+----------------------------------------+
| 56570acfefb64055b752e81fb588257f:E#WR# |
+----------------------------------------+
1 row in set (0.00 sec)
It appears WHMCS does randomize new passwords each time this option is toggled (I ran through this loop several times to verify) - however, clients do not get notified of the change.
Here's where things get fun. There is no documented API function that lets you reset a client's password (which would be necessary for this scenario, since manually updating SQL won't send emails). There *ARE* API functions for encrypting and decrypting non-md5 passwords, as well as an API function for resetting a service (not WHMCS login) password.
The only method of resetting a client's password that includes an automated, templated email is the `Reset & Send Password` button on the clientsummary.php page. This leaves the following options:
There are a plethora of other scenarios, but most rather unlikely and would be a waste of time to go into. It'll be pretty easy to see what actually happened as more excuses come forth, though - GVH has a known history of telling blatant exaggerations/bluffs, only to come back later with a different story.
This does reset passwords. It does not email clients.What's this button do?!
Original password, with md5 enabled:
mysql> SELECT password FROM tblclients WHERE id = 1;
+----------------------------------------+
| password |
+----------------------------------------+
| 2ae51bfc8fec24a86a8cbbffc345ccd2:%!Rd% |
+----------------------------------------+
1 row in set (0.00 sec)
Stored password after checking said box, and saving:
mysql> SELECT password FROM tblclients WHERE id = 1;
+------------------------------------------+
| password |
+------------------------------------------+
| I3noCCtmFPCtEFgyxrKVKyPcgctuttmdv4ooxFbV |
+------------------------------------------+
1 row in set (0.01 sec)
Stored password after re-enabling md5, and saving again:
mysql> SELECT password FROM tblclients WHERE id = 1;
+----------------------------------------+
| password |
+----------------------------------------+
| 56570acfefb64055b752e81fb588257f:E#WR# |
+----------------------------------------+
1 row in set (0.00 sec)
It appears WHMCS does randomize new passwords each time this option is toggled (I ran through this loop several times to verify) - however, clients do not get notified of the change.
Here's where things get fun. There is no documented API function that lets you reset a client's password (which would be necessary for this scenario, since manually updating SQL won't send emails). There *ARE* API functions for encrypting and decrypting non-md5 passwords, as well as an API function for resetting a service (not WHMCS login) password.
The only method of resetting a client's password that includes an automated, templated email is the `Reset & Send Password` button on the clientsummary.php page. This leaves the following options:
- An actual WHMCS Bug - I'm inclined to discredit this one. The actual function to reset the pass and email the client is embedded within the clientsummary.php page, as evidenced by the &resetpw=true&token= called on the URL. The WHMCS cron does *not* call the clientsummary.php page at all - and with no other hooks/functions that both reset the pass and issue an email, the chances of this being a cron bug are next to nil.
- Poorly Coded Module - This has some potential. To reset a client's password, you have to call the clientsummary.php page directly with the &resetpw=true&token=[REDACTED] flags included. So, assuming you were competent with bash/perl/etc, you could fairly easily write a script that would generate a list of URLs to hit with curl that would effectively mass-reset passwords. I've actually written a script to do just this some time back as a precaution when all of the exploits started surfacing last year. However - I did say assuming you were competent, so I think we can pretty much agree this option is ruled out.
- Security Breach - A frightening possibility - but worth considering. If someone had malicious thoughts of GVH, but didn't want the innocent clients to become casualties, gaining access and doing something minor like this would be enough to put a scare into folks.
There are a plethora of other scenarios, but most rather unlikely and would be a waste of time to go into. It'll be pretty easy to see what actually happened as more excuses come forth, though - GVH has a known history of telling blatant exaggerations/bluffs, only to come back later with a different story.
@Aldryic C'boas try running the daily cron after toggling the box, maybe it will send the password reset emails then?
Aldryic C'boas
The Pony
I tried, it did not. Sorry, forgot to mention that in the last post.
For what it's worth, I still have a dummy account setup with GVH with no VPS active and did NOT receive a password reset email. I did, however, get a mass email that stated they are investigating.
- Status