DreamHost Database Event
In April of this year, a data warehouse for logs and performance metrics that we had used in the past to help us explore the impact of potential new DreamPress feature enhancements was inadvertently made publicly viewable due to an automated misconfiguration of a firewall rule.
In total, 21 websites were affected.
This database was accessible outside of our network for approximately 12 hours during an active maintenance window. During this time it was accessed by a single internet user — a white hat security researcher — who had been scanning our IP space. He alerted us to his finding as we were in the process of taking it down, and we’re thankful for the work that he and other researchers do every day.
Mistakes We Made
A logging database had been used for storing test data related to feature development
This database was not properly configured for authentication
A firewall configuration issue temporarily made this database accessible outside of our network
Corrected the configuration issues resulting in outside accessibility
Removed stale testing data
21 impacted website owners were contacted
Continuing audit of all internal access control systems
Assess and refine all deployment and configuration processes and documentation
Despite the sensational headlines this event has generated, metadata pertaining to 21 current and former DreamHost customers’ DreamPress websites were briefly accessed by the security researcher. Each of these customers has been contacted.
While it’s true that the 85GB database itself consisted of over 800 million records, none of those records contain data that would have allowed access to DreamHost accounts. They consist entirely of entries that include object update records, error reports, and log entries.
This database did not contain Personally Identifiable Information (PII) of DreamHost customers as defined by a variety of statutes in jurisdictions in which we operate, nor did it contain any user passwords (encrypted or otherwise). It did contain email addresses and display names of registered WordPress users across these 21 websites. As this database was used as a means of measuring DreamPress performance, it also included lists of installed WordPress plugins and themes.
Also contained within the database was an overwhelming number of spam accounts ostensibly created with automated tools. Approximately 4,855 email addresses appeared in this database, of which 4,339 were tied to spam accounts from a single site with an open registration policy. Most do not appear to be legitimate.
Is My Data Safe?
Again, while it was publicly available, our logs show that this database was accessed by a single internet user — a lone security researcher who disclosed his findings to us responsibly. The evidence shows that there was no additional unauthorized access to this database.
The administrative system that misconfigured this database’s access controls was modified immediately after we secured it in April. All stale data pertaining to the aforementioned 21 sites was removed at that time as well.
We do not expect the unique set of technical circumstances that caused this event to occur again, and the changes we’ve made ensure that they will not. In addition to our ongoing breach and configuration monitoring, we are continuing a full audit of all internal systems, including our processes and documentation surrounding these systems.
We place a high level of importance on protecting our customers’ data. Our customers trust us to respect their data and their rights to share it online as they choose, and we will always place the highest priority on ensuring that those rights are respected.
Timeline of Events
- Access control rule is modified by software, the database becomes externally accessible
- Security researcher contacts us
- Database access issue is identified and resolved
- Log review confirms the singular access was to the researcher
- Legal department begins review to determine the scope of the event
- Legal department concludes internal review/investigation
- Security team responds to the researcher to thank him for his report
- Researcher confirms he did not “download or extract any data from the logs” and took only screenshots.
- Researcher writes back to the security team, offering to help if needed
- Security team writes back to confirm the firewall rule was resolved on the day of its report
- Researcher goes public