Habitat for Humanity Breach
Habitat for Humanity is a large, international charity that builds and provides low-income housing. Ex-president Jimmy Carter is a vocal supporter of the organization. They do good things and help a lot of people. That is why is pains me to report on the poor data breach incident response of their Michigan branch.
The silence on Habitat’s side may be somewhat related to the fact that their Colorado branch recently announced an actual hack, rather than a simple exposure of data, that has been crippling operations. Having to announce a second, separate, breach within a month is probably not on the top of Habitat’s wish list. But it’s the right thing to do.
Here are the technical details—Habitat for Humanity of Michigan is a client of a web hosting provider named Providence, which in turn gets service from an ISP named ACD. All of these companies are based in Michigan. During the course of my research, I discovered a publicly exposed remote synchronization (rsync) service that was operating on an ACD IP address.
Most of the files available from this rsync service were encrypted with ShadowProtect backup software. However, there was a notable exception: The Habitat for Humanity of Michigan files. It appears that either someone simply forgot to encrypt them, or whoever does IT for Humanity chose not to take advantage of the encryption, or perhaps the files were scheduled for encryption but it had not yet taken place.
Whatever the case, I soon had over 400 gigabytes of virtual hard drive data stemming from Habitat for Humanity of Michigan.
Looking through 400 gigs in order to see if personal information had been exposed can be a little challenging. I soon found a directory with over 700 folders containing PDF background and credit check reports. You can imagine how sensitive these reports are. They contain everything a malicious actor would need for identity theft. I also quickly found a SQL database backup file with a bevy of information, including over 4,600 peoples’ social security numbers, names, addresses, phone numbers, etc.
It was after normal business hours on October 9th when I confirmed that sensitive information was indeed exposed by this hosting breach. Fortunately ACD (the ISP involved) has a 24-hour hotline for technical issues. I called and spoke with a young man who said he would look into the situation. When I checked on it the following day, the rsync service was no longer accepting public connections.
A few days later I followed up with Habitat to make sure that ACD had notified them of the issue. Later investigation, conducted by Dell Cameron of The Daily Dot (https://www.dailydot.com/debug/habitat-for-humanity-applicants-michigan-data-breach/) revealed that ACD had in fact contacted Providence, who appear to be the main hosting provider for Habitat’s Michigan branch.
As far as I can tell, Providence did not inform Habitat. Although it would be nice if Habitat could confirm that for me.
Whatever the case, Providence provided Dell Cameron with a little background: “I will tell you that the way that it was presented to us made it sound like [Vickery] may have been a hacker and that it may have been a phishing scam.”
That is interesting because, even if I was some sort of malicious hacker, they still should have informed Habitat that there had been a data breach. I’m not sure how phishing could have fit into the mix. At this point I already had the data. There’s no point in phishing for credentials or other information if the data is already publicly exposed and has been handed out.
Overall, the incident seems to have been handled very badly by three separate parties. If the information I have gathered is correct, then ACD should not have represented to Providence that some sort of “hacking” occurred, Providence should have at least requested my information from ACD (which I had provided) in order to look into the issue, and Habitat for Humanity of Michigan should have at least responded to my data breach notifications.
This all goes to show that the current state of data breach response is not good. Very few companies will own up to making mistakes, very few will accurately communicate information surrounding the event, and even fewer will follow through with a well-planned incident response plan. Most will do everything possible to avoid notifying the affected clients or “victims”.
I will continue working to improve this sad state of affairs.
Attention - Portions of this article may be used for publication if properly referenced and credit is given to MacKeeper Security Researcher, Chris Vickery.