MBTA and responsible disclosure

What is responsible disclosure? That is a question that has not and will not be answered. It all depends on who you ask. One researcher will give one answer and another will give another answer. The same goes for those who work in other areas of information technology and information security. Networkers and developers, security pros and server admins. All will give different answers depending on their view of information security and the importance of discovering flaws and disclosing them.

The key word in this discussion is "responsible". Unfortunately even responsible doesn't mean the same thing to everyone. I guess in reality the word responsible can/does have a moving definition. If you find a vulnerability and it will take lots of skill, special tools and lots of money to exploit it on a wide scale then the risk of it being exploited is pretty low and disclosing it w/o going to the vendor is not as big a deal. On the other hand if you take the opposite of those things and you disclose without giving the vendor a chance to fix it is irresponsible. Those are the two extreme sides of the debate. It's all the stuff in the middle that causes the masses to argue over what is responsible and what isn't.

Here is my take on this with some comments on the MBTA debacle thrown in.

1. As Information Security Professionals it is our responsibility to act in a professional manner and to do all in our power to protect the company that we work for.
   
2. If you are doing research on your own or for a company then you have a responsibility to protect your client or the company/vendor that you are researching.
   
3. If you call yourself a White Hat researcher then you have a responsibility to act in responsible manner for all computer users.
4. Responsible disclosure means that you give the vendor/company time to fix the issue before going public with it.
5. The argument that vendors are not responsive a vulnerability is given to them is flawed because this is not the case most times.

In this instance the MIT students didn't act responsibly in several of these areas. #2, 3, 4 were all ignored for the most part. Giving a company 4 days advance notice is hardly responsible. Although there is some rumor floating around that the MBTA did have notice of some of the issues several months ago. Which if you think about it is true. They may not have known about this particular research from MIT but it has been public knowledge of the Mifare RFID chip being vulnerable since the Dutch researchers wrote their paper about a year ago. Not to mention the fact that the London Oyster Card also used the same chip and it was announced a few months back that it had been hacked.

If anyone would expect that the MBTA would be able to fix this in a short period of time then they are sadly mistaken. An issue such as this involves much more than just changing the encryption on the card. The software and firmware used in the readers and encoders have to be changed. The database has to has to be modified as well as the code in the vending machines that sell the tickets and much more. There has to be testing and QA before it can be rolled out into production. Not to mention that getting new cards is not something that you can just run down to Wal-Mart and pick up. Especially when you are dealing with something as big as this. There are specs that have to be figured out and agreed upon between the MBTA and their Fare collection vendor. Then they probably have to put out a bid on the new cards and give the card vendors time to submit proposals. Then they have to go through a selection process and then wait on a PO to be approved via their procurement process. Then they can place the order. Even at that point they are still not ready to go live. The vendor has to fill the order and once the new cards are in there is still the whole process of replacing the old cards. This means that the new specs will have to be backward compatable with the old ones because they can't just cut the old cards off and make everyone migrate to the new ones all in a day.

As things such as this and the DNS Metasploit exploit continue to happen it makes me less and less of a fan of disclosure until after vendors have released a patch and adequate time for the patch to be installed has passed. I'm not there yet. I still think that there is a place for researchers to find flaws and get the word to the vendor so they can be fixed. I'm even in favor of researchers releasing exploits prior to a patch if the vendor is ignoring the issue AND the issue is not of a nature that can cause serious widespread pwnage.

I have to admit that one thing that I recently read makes a lot of sense. I don't remember where I read it or who said it so if you know let me know so I can give them credit. Basically they said that instead of spending so much time looking for and focusing on vulnerabilities that have a very low risk to the public lets focus on fixing the ones we know about that do have the potential to cause serious problems. Let's also focus on writing better code and deploying more secure applications and infrastructures. This is where we can make a difference. Lets quit trying to make a name for ourselves by being the first to find something and make a name by being the ones who are willing to work together to make things better.