Responsible Disclosure and PASS’s Security Vulnerability

I’ve only been at the DBA thing for the last six months. I’m as close to an Accidental DBA as it gets; and I’m the first to admit that. I’m learning fast, I’m learning on the Job, and (full disclosure), the Brent Ozar Unlimited team has helped with that, tremendously.

I’ve been following Brent Ozar‘s blog for a long time now, and more recently started paying attention to the PASS debacle(s). Before, it was idle curiousity, now it’s because I’m working day in and day out in that sphere. I can’t afford to be ignorant.

Today, Brent blogged about PASS’s lack of security surrounding their voting system. In essence, it worked like this:

PASS sends you to a third party site to vote, you input your PASS credentials on this third party site, and voila, you’ve voted.

See the problem? No?

How about now?

PASS sends you a postcard with an address to go to. You go to that address, give them identity information (Social, birthdate, whatever they need to act as you), and they mail it back to PASS with your vote.

Would you do that in real life? No. Then why would you do that online?

At first, it was fun and games. Everyone have a laugh at terrible security. Then, I took an action on the PASS site, and noticed that rather sensitive information was leaking out. I even dug into the developer tools to be sure I wasn’t making it up — but even after that, I still thought there was something I was missing. I had to be. I posted an offhand comment on Brent’s blog because quite frankly, I thought I was wrong.

I was so sure I was wrong that I didn’t even think about the ethics of disclosure. It didn’t cross my mind. I was hoping someone would reply with, “Hey, you’re not seeing X, or Y — they’re actually doing it correctly.”

So I posted a comment.

I shouldn’t have done that, because in this case: I was right. Oops.

I’m sorry.

Brent and others are already in contact with the PASS people to get this vulnerability fixed. For my part: lesson learned.

Note: If you’re trying to raise me on twitter, I’m taking a break from social media for the next 9 weeks. Catch me through a comment on this site or through email.

Additional note: If you have a link to a template for Responsible Disclosure that isn’t vendor specific, link to it in the comments. An internet search turns up a lot of separate “responsible disclosure policies“, but I haven’t seen an authoritative template on the subject that should govern our actions, or ethical actions in the case a company doesn’t have a policy on their site. Troy Hunt’s take on the subject is relevant.

Update 1: The vulnerability on the PASS site affects your user credentials (login/password). The site has been vulnerable for an unknown amount of time — but it’s not one of those things that work and you accidentally break one day. My supposition is that it’s been broken for a very long time. If you use the same username/email + password combination anywhere else, change it on that site immediately. ( I include email because that’s part of the sensitive information that leaks out, and some sites use your email address as your login instead of a unique username).

Do not change your PASS credentials until they fix the vulnerability on their side. Doing so will only cause you pain, without actually fixing the issue.

Update 2: You may wonder why this is a problem. After all, it’s not like it’s your bank, right? I mean, it’s just an association website! The problem is, that association represents professionals that have the keys to the kingdom in their own little world. Depending on what email address is used, a potential attacker not only has a company to target with user credentials, but potentially active directory passwords as well.

Good security practices are to use different passwords for each site; but how many people actually do that? I know I don’t always do that (though I do segment ‘non-critical’ sites from critical sites, and I use a different password for each critical site).

If this were a fantasy football site, I wouldn’t be as worried. However, this is a site where DBAs congregate — and in any revenue generating organization, the DBA sits right next to the goods.

Update 3: It looks like SQL Pass has purchased an SSL certificate and set it up. The affected pages are now being served over SSL; potentially negating the vulnerability.

Here’s how their SSL Setup rates:

If you use an SSL certificate (and you should, but that’s another story), it’s always a good idea to have a tool that can tell you where you’re vulnerable. The SSL Labs tools do just that.