WVHDF Was Warned and Now Your Info May Have Been Stolen
A little-advertised element of the program is how it helps anyone in the state make critical repairs through low-interest loans. For example, our improperly-installed leech field failed. Combine Dan Ryan Builders (seriously, if you’re considering having them build a home for you, RUN AWAY as fast as you can) and a county sanitarian who was found to have been accepting bribes at the time our home was built, and you have our predicament. We didn’t have $6,000 sitting around to fix it properly. The contractor told us about this program where we could get a 1-2% loan to cover the costs of the repair. It was a no-brainer.
That’s the good. And now for the entirely-preventable bad.
Last week, I received a letter from the WVHDF that stated:
We are writing to inform you of a recent security incident at the West Virginia Housing Development Fund. On January 30, 2015, we were notified of suspicious activities on one of our servers. The Fund took immediate action to investigate the issue, including retaining a computer forensic consulting firm and turning off the affected server. It appears that files including your name, address, and Social Security number may have been viewed. The files did not include bank account or credit card information.
My immediate reaction? “I told you guys! I warned you!”
Back on July 5, 2014, I sent them the following email:
Subject: 2 concerns
1. I received the letter with the password to log into the wvhdf site so I could start paying on my loan. An account number is required. I have not receive that yet. How may I receive that?
2. There is a security issue with your website. When I entered the account number with the letters in it (at the top of the paper mailed to me), and tried to log in, I received a JDBC error telling me it could not convert a varchar to a bigint. Please let your web people know that this goes against security best practices. What your web team should do is:
1. disable the verbose error messages in the production environment. They give potential attackers too much information. 2. Use CFTRY and CFCATCH along with some data validation so you can handle errors in the data that your users supply gracefully and before you get an error at the database itself.
In earlier years, I was a ColdFusion developer. When acwe suffered a hacking incident of one of our applications where I work almost eight years ago, in the ensuing independent validation and verification (IV&V), my ColdFusion app was the one that withstood the scrutiny. It was built with security in mind from the very start.
Developing web applications that are secure isn’t hard. It’s a mindset. The fix to the issue I reported to them is insanely simple. As simple as checking a checkbox in the ColdFusion administrator.
I’m not privy to the forensic information, so I can’t say whether the weakness I found and alerted them to was how the attackers got in. However, given that I warned them of an issue six months prior to them discovering an attack and yet the attack still happened suggests that there’s either a cavalier attitude about information security at WVHDF or they have developers that just aren’t up to the task.
This breach, in my opinion, was entirely preventable. If anyone’s identity was stolen, then they have every right to be pissed and to seek justice. I have no proof, but based on my experience that I just shared with you, I believe WVHDF was negligent.