GoDaddy Breached – Plaintext Passwords – 1.2M Affected
There is an update available here: GoDaddy Breach Widens to tsoHost, Media Temple, 123Reg, Domain Factory, Heart Internet, and Host Europe
This morning, GoDaddy disclosed that an unknown attacker had gained unauthorized access to the system used to provision the company’s Managed WordPress sites, impacting up to 1.2 million of their WordPress customers. Note that this number does not include the number of customers of those websites that are affected by this breach, and some GoDaddy customers have multiple Managed WordPress sites in their accounts.
According to the report filed by GoDaddy with the SEC [1], the attacker initially gained access via a compromised password on September 6, 2021, and was discovered on November 17, 2021 at which point their access was revoked. While the company took immediate action to mitigate the damage, the attacker had more than two months to establish persistence, so anyone currently using GoDaddy’s Managed WordPress product should assume compromise until they can confirm that is not the case.
It appears that GoDaddy was storing sFTP credentials either as plaintext, or in a format that could be reversed into plaintext. They did this rather than using a salted hash, or a public key, both of which are considered industry best practices for sFTP. This allowed an attacker direct access to password credentials without the need to crack them.
According to their SEC filing: “For active customers, sFTP and database usernames and passwords were exposed.”
We attempted to contact GoDaddy for comment and to confirm our findings, but they did not immediately respond to our requests for comment.
What did the attacker have access to?
The SEC filing indicates that the attacker had access to user email addresses and customer numbers, the original WordPress Admin password that was set at the time of provisioning, and SSL private keys. All of these could be of use to an attacker, but one item, in particular, stands out:
During the period from September 6, 2021, to November 17, 2021, the sFTP and database usernames and passwords of active customers were accessible to the attacker.
GoDaddy stored sFTP passwords in such a way that the plaintext versions of the passwords could be retrieved, rather than storing salted hashes of these passwords, or providing public key authentication, which are both industry best practices.
We confirmed this by accessing the user interface for GoDaddy Managed Hosting and were able to view our own password, shown in the screenshot below. When using public-key authentication or salted hashes, it is not possible to view your own password like this because the hosting provider simply does not have it.
You’ll also note that the system is using port 22, which is Secure File Transfer Protocol. There are several kinds of sFTP, and this confirms that they’re using sFTP via SSH, which is encrypted, and designed to be one of the most secure ways to transfer files. Storing plaintext passwords, or passwords in a reversible format for what is essentially an SSH connection is not a best practice.
GoDaddy appears to acknowledge that they stored database passwords as plaintext or in a reversible format. These are also retrievable via their user interface. Unfortunately storing database passwords as plaintext is quite normal in a WordPress setting, where the database password is stored in the wp-config.php file as text. What is more surprising, in this breach, is that the password that provides read/write access to the entire filesystem via sFTP is stored as plaintext.
What could an attacker do with this information?
While the SEC filing emphasizes the potential phishing risk posed by exposed email addresses and customer numbers, the risk posed by this is minimal compared to the potential impact of exposed sFTP and database passwords.
Although GoDaddy immediately reset the sFTP and Database passwords of all the impacted sites, the attacker had nearly a month and a half of access during which they could have taken over these sites by uploading malware or adding a malicious administrative user. Doing so would allow the attacker to maintain persistence and retain control of the sites even after the passwords were changed.
Additionally, with database access, the attacker would have had access to sensitive information, including website customer PII (personally identifiable information) stored on the databases of the impacted sites, and may have been able to extract the contents of all impacted databases in full. This includes information such as the password hashes stored in the WordPress user accounts databases of affected sites, and customer information from e-Commerce sites.
An attacker could similarly gain control on sites that had not changed their default admin password, but it would be simpler for them to simply use their sFTP and database access to do so.
On sites where the SSL private key was exposed, it could be possible for an attacker to decrypt traffic using the stolen SSL private key, provided they could successfully perform a man-in-the-middle (MITM) attack that intercepts encrypted traffic between a site visitor and an affected site.
What should I do if I have a GoDaddy Managed WordPress site?
GoDaddy will be reaching out to impacted customers over the next few days. In the meantime, given the severity of the issue and the data the attacker had access to, we recommend that all Managed WordPress users assume that they have been breached and perform the following actions:
- If you’re running an e-commerce site, or store PII (personally identifiable information), and GoDaddy verifies that you have been breached, you may be required to notify your customers of the breach. Please research what the regulatory requirements are in your jurisdiction, and make sure you comply with those requirements.
- Change all of your WordPress passwords, and if possible force a password reset for your WordPress users or customers. As the attacker had access to the password hashes in every impacted WordPress database, they could potentially crack and use those passwords on the impacted sites.
- Change any reused passwords and advise your users or customers to do so as well. The attacker could potentially use credentials extracted from impacted sites to access any other services where the same password was used. For example, if one of your customers uses the same email and password on your site as they use for their Gmail account, that customer’s Gmail could be breached by the attacker once they crack that customer’s password.
- Enable 2-factor authentication wherever possible. The Wordfence plugin provides this as a free feature for WordPress sites, and most other services provide an option for 2-factor authentication.
- Check your site for unauthorized administrator accounts.
- Scan your site for malware using a security scanner.
- Check your site’s filesystem, including
wp-content/pluginsandwp-content/mu-plugins, for any unexpected plugins, or plugins that do not appear in the plugins menu, as it is possible to use legitimate plugins to maintain unauthorized access. - Be on the lookout for suspicious emails – phishing is still a risk, and an attacker could still use extracted emails and customer numbers to obtain further sensitive information from victims of this compromise.
Conclusion
The GoDaddy Managed WordPress data breach is likely to have far-reaching consequences. GoDaddy’s Managed WordPress offering makes up a significant portion of the WordPress ecosystem, and this affects not only site owners, but their customers. The SEC filing says that “Up to 1.2 million active and inactive Managed WordPress customers” were affected. Customers of those sites are most likely also affected, which makes the number of affected people much larger.
For the time being, anyone using GoDaddy’s Managed WordPress offering should assume their sites have been compromised until further information becomes available, and follow the steps we have provided in this article. We will update the article if more information becomes available.
References:
- GoDaddy SEC Report: https://www.sec.gov/Archives/edgar/data/1609711/000160971121000122/gddyblogpostnov222021.htm
Note: All product names, logos, and brands are property of their respective owners in the United States and/or other countries. All company, product, and service names used on this page are for identification purposes only. Use of these names, logos, and brands does not imply endorsement.
Comments
12:19 pm
Does this also affect ManageWP - which was acquired by GoDaddy?
Thanks!!
6:41 am
See my other replies on this issue. In short, probably not, but keep an eye out for announcements as their investigation proceeds.
12:25 pm
Hi—Just to be sure I'm understanding correctly, the breach ONLY applies to GoDaddy Managed Wordpress hosting accounts, and NOT to the rest of GoDaddy accounts? I use them as the domain name registrar for a number of sites, but none are hosted with GoDaddy.
Thank you.
6:41 am
That does seem to be the case, however their own investigation is still underway, so keep an eye out for announcements from them.
12:42 pm
Would site's on Pagely (acquired by GoDaddy on 11/11/2021) be impacted by this breach? I'm guessing no but I'm curious if you have any insight into this.
Thanks!
6:40 am
No indication at this time that that is the case. Having been acquired myself years ago, I would say that the chances are very low because it takes months - sometimes years - to integrate the new business's operations into the acquirer. So they're probably still two completely separate operations at this point.
12:48 pm
Does this in any way affect the domain registration side of their operation? Should those who have their domains registered at GoDaddy.com also change their passwords and take other precautions?
Thank you.
6:39 am
There are no indications at this time that their domain registrar biz was compromised, but keep an eye out for announcements as their investigation proceeds.
12:53 pm
GoDaddy holds my domains but my websites are hosted elsewhere. Am I compromised?
6:38 am
No indication of that at this time, but keep an eye out for announcements as their investigation proceeds.
1:21 pm
I no longer use GoDaddy directly but do use ManageWP.com and wonder if that is a concern and if those logins saved by ManageWP are at risk?
6:38 am
See my reply to another poster here. Short version: Nothing to indicate that at this time, but keep an eye on announcements from them as their investigation proceeds.
1:25 pm
Does this breach also affect accounts that only have domains registered with GoDaddy? None of my clients are hosted with them, but there are some who have legacy domains that are still registered there. Thanks!
6:37 am
Nothing to indicate that at this point. But keep an eye on announcements from them as their investigation proceeds.
2:22 pm
I BELIEVE Panthur is owned by Go Daddy - is this Panthur also affected?
6:37 am
I don't think they are owned by GoDaddy.
2:28 pm
Not surprised at all by this - it’s what happens when large companies get into an area they know nothing about, even though they market themselves as leaders in the field.
2:44 pm
Yikes. Readable plain text passwords... beyond comprehension that such a large organization would use such poor standards.
3:00 pm
I hope this doesn't affect domains registered at GoDaddy, but not hosted there.
4:11 pm
I don't host websites with GoDaddy however. I do use their ManageWP application to manage customer websites and my own. Does this hack include customers using their ManageWP app?
6:35 am
GoDaddy acquired ManageWP a while back (managedwp dot com) and we have no definitive data at this one on whether or not users of that app are affected. Their announcement does not include manageWP, so indications are that they are not affected. However some applications store data on the provider's servers, and so I'd suggest waiting to see what their own investigation says.
6:58 pm
Data Breaches are common now-a-days. About a week before, one of my website (unfortunately this specific website was not using wordfence 2FA, as others was using Wordfence 2FA) was hacked and the attacker installed the "WP File Manager" plugin in my website and I didn't notice it to be critical for about a week. After a week, my wordpress files of the other websites were trembled. The WordFence notified me that it has found about 150 malicious files on my websites. I check them and they all were pointing towards an exploit "UeExploit" (same case of alphabets). The harmful files were then pushed inside the file manager, surprisingly, frontend of all websites was running normally.
Since, I am a Security Analyst, I mitigated the issue and found that the access was granted due to a data breach and the attacker used "WP File Manager" (legit plugin) to gain access into the files of the affected website.
Gaining access to that website grants them access to other websites hosted on the same server. This way, it took me a long time restoring them to previous state.
Now, I am using WordFence 2FA in that website also, which granted the attacker access to website.
Some of those harmful files identified by WordFence premium are
File appears to be malicious or unsafe: wp-includes/Requests/class-wp.php
* File appears to be malicious or unsafe: wp-includes/index.php
* File appears to be malicious or unsafe: wp-content/1index.php
* File appears to be malicious or unsafe: wp-options.php
* File appears to be malicious or unsafe: wp-admin/class-loadering.Php
* File appears to be malicious or unsafe: wp-content/wp-options.php
* File appears to be malicious or unsafe: wp-admin/indeeex.php
* File appears to be malicious or unsafe: wp-includes/indeeex.php
* File appears to be malicious or unsafe: wp-content/radio.php
* File appears to be malicious or unsafe: wp-includes/radio.php
* File appears to be malicious or unsafe: wp-admin/1index.php
* File appears to be malicious or unsafe: wp-includes/images/wlw/javascripts/js/wp-logs.php
* File appears to be malicious or unsafe: wp-includes/wp-options.php
* File appears to be malicious or unsafe: smtphec.php
* File appears to be malicious or unsafe: lyda.php
* File appears to be malicious or unsafe: wp-includes/class-query.Php
* File appears to be malicious or unsafe: wp-admin/css/colors/blue/wp-logs.php
* File appears to be malicious or unsafe: wp-includes/smtphec.php
* File appears to be malicious or unsafe: wp-content/smtphec.php
* File appears to be malicious or unsafe: wp-supports.php
* File appears to be malicious or unsafe: wp-admin/smtphec.php
* File appears to be malicious or unsafe: index.php
* File appears to be malicious or unsafe: wp-includes/class-loadering.Php
* File appears to be malicious or unsafe: wp-includes/indeex.php
* File appears to be malicious or unsafe: wp-commentin.php
* File appears to be malicious or unsafe: wp-includes/1index.php
* File appears to be malicious or unsafe: wp-content/class-loadering.Php
* File appears to be malicious or unsafe: wp-admin/wp-options.php
* File appears to be malicious or unsafe: wp-admin/radio.php
* File appears to be malicious or unsafe: wp-includes/images/wlw/javascripts/js/wp-lo.Php
* File appears to be malicious or unsafe: indeeex.php
* File appears to be malicious or unsafe: wp-content/indeeex.php
* File appears to be malicious or unsafe: wp-god.Php
* File appears to be malicious or unsafe: wp-activate.php
* File appears to be malicious or unsafe: wp-includes/SimplePie/wp-logs.php
* File appears to be malicious or unsafe: wp-content/index.php
High Severity Problems:
* Unknown file in WordPress core: wp-admin/1index.php
* Unknown file in WordPress core: wp-admin/class-loadering.Php
* Unknown file in WordPress core: wp-admin/css/colors/blue/wp-logs.php
* Unknown file in WordPress core: wp-admin/css/colors/coffee/image.php
* Unknown file in WordPress core: wp-admin/indeeex.php
* Unknown file in WordPress core: wp-admin/indeex.php
* Unknown file in WordPress core: wp-admin/radio.php
* Unknown file in WordPress core: wp-admin/smtphec.php
* Unknown file in WordPress core: wp-admin/wp-options.php
* Unknown file in WordPress core: wp-includes/1index.php
* Unknown file in WordPress core: wp
Thanks WordFence team for such endpoint protection, otherwise, I would not has identified the issue on frontend of websites (although wordpress dashboard was showing me some unusual behaviour like ".htaccess file not found", etc.
6:32 am
Glad to hear Wordfence helped you!
8:46 pm
Thank you so much for this article. I've been fretting about what to do. At 2AM (today) I received an email from Godaddy confirming this, I happened to wake up when I heard it come in on my phone. Fortunately the one website affected, of mine, is young and with few customers or subscribers but now I have the fun task of letting them know of the breach. Fortunately the site is registered with the ICO, and fortunately I use Wordfence and subscribe to you. This helps a great deal. I don't envy the more established websites. Just how much of a spring clean should you do? I'm assuming that by now the perpetrator would have taken what they wanted anyway, but I'll close the barn door just in case. Not very amused with Godaddy though. I'm off to write a customer email.
2:27 am
This also affects TSOhost - I've just had an email from them to inform me of the security issue as you've described - although it doesn't affect me as I closed that account over a year ago!
5:32 am
Thank you for reporting on this!
Do you know if ManageWP Orion users are affected as well?
6:31 am
I have no data on that. I'd suggest contacting GoDaddy immediately if that's one of their products and ask them.
8:34 am
Thank you!
6:00 am
Thank you once again WordFence for all of this valuable information! So am I understanding this correctly that this breech was only for GoDaddy MANAGED Wordpress hosting and not their regular hosting packages then?
Thank you!
6:30 am
Yes it does appear so. But we can't definitively say that other systems weren't breached. Their own investigation is still underway. I'd change passwords now, and wait and see before notifying your own customers if you are with GD but are not managed hosting.
6:31 am
I'd also suggest contacting them.
8:36 am
Just went into an affected managed wordpress account and changed the sFTP password as directed. Unsurpisingly. it's still storing passwords in plaintext.....
8:44 am
Thanks for this very valuable information. I'm curious about two things:
1. GoDaddy says they immediately cancelled SSL private keys. Does that mean that it removes the possibility of any future site impersonation? (Obviously I'll get a new one)
2. You mentioned above that there may be plugins installed that (a) don't appear in the plugin menu and (b) allow continued access even after passwords have been changed. Any particular way to identify these?
Clearly Wordfence is a useful plugin that I'll have to get moving forward.
Thank you.
3:00 pm
Hi,
Browsers keep a list of revoked certificates, called a CRL (certificate revocation list) so future site impersonation should not be practical. As far as identifying problem plugins, you should be able to check the list of installed plugins under /wp-admin/plugins.php and Must-Use plugins under wp-admin/plugins.php?plugin_status=mustuse. If plugins appear under wp-content/plugins or wp-content/mu-plugins that don't correspond to what you see in the admin interface then you might have a plugin that's hiding.
12:04 pm
do you think Sucuri (Parent-GDDY) is part of the breach?
2:23 pm
Hi,
We've received new information on what else was impacted - so far Sucuri doesn't seem to have been affected but a number of other brands that resell GoDaddy's Managed WordPress offering have been impacted.
2:57 pm
Thank you for your expedient coverage and analysis of the security breach. I appreciate you going beneath the surface to explain the nuances. Plus, thank you Mark for answering questions in the comments! :-)
10:04 pm
Thanks for the best analysis of this breach so far. IMO the lack of information or list of affected websites (~1.2 million or more) that were hosted on managed WordPress environment poses an unknown degree of risk when accessed through a company's corporate network. For example: if abc.com was part of this breach and the hackers/perpetrators took over the site in the 2 month period when they had access by adding plugins/malware etc. Then accessing this website itself can cause another incident/breach when accessed via a corporate machine?