amuck-landowner

GreenValueHost forced password reset - Security breach?

Status
Not open for further replies.

SkylarM

Well-Known Member
Verified Provider
2VG.png
What's this button do?!
 

Tactical

Where is the beer!
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
Many providers use a gateway with a vault system (for instance, we use Quantum Vault, but there are others) so the credit card number never touches WHMCS.  It uses a token to automatically charge the card in the future if the user chooses to leave it on file for automated charging.
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.

GVH is saying it was whmcs cronjob that caused the reset?
That's their official story?  That the automated cron caused the reset?
 

Tactical

Where is the beer!
@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 
 

DomainBop

Dormant VPSB Pathogen
That's their official story?  That the automated cron caused the reset?
Yep, and they're doing a Fabozzi and blaming it on the software maker.

Quote from their new "Vice President of Operations" :

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
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.
 

No it was not a security breach. Client data is completely safe and has not been leaked.
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.
 

toadyus

Article Submitter
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!
 

ChrisM

Cocktail Enthusiast
Verified Provider
Soooo. GVH found another way to give themselves free advertising through pass resets? That's unique. 
 

DomainBop

Dormant VPSB Pathogen
Does this actually send out password reset emails to all clients? 
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:

For security client area passwords are irreversibly encrypted and cannot be viewed by admins, enabling this option will switch to reversible encryption allowing admins to view the password. When switching from irreversible to reversible clients will all be assigned a new password and will need to use password recovery.
http://docs.whmcs.com/Security_Tab#Disable_MD5_Clients_Password
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
 

rds100

New Member
Verified Provider
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).
 

Aldryic C'boas

The Pony
Did a bit of testing on our WHMCS dev platform..

2VG.png
What's this button do?!
This does reset passwords.  It does not email clients.

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.
 

SkylarM

Well-Known Member
Verified Provider
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
Not open for further replies.
Top
amuck-landowner