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.

Sometimes things slip up on you

I was perusing my RSS feeds this morning and ran across this post by my friend Martin McKeay where he talks about missing his 5th year blog anniversary. That reminded me that I missed my 2nd year blog anniversary. I posted my first blog entry on Aug 9, 2006. It was an experiment to see how I would like it and it stuck. As Martin says in his post blogging has been a very good thing for me. It has opened many doors that more than likely would have remained closed if I had not started blogging. Ironically Martin is one of the key reasons that my blog has succeeded. I'm not sure how but he found my blog on Aug 11, 2006 and made a comment encouraging me to keep it up and he later linked to me and mentioned me on his podcast.

I've become a big fan of blogging and reading blogs. I consider reading blogs as a part of my job now because I learn from those I read and gain information and knowledge that I would not have. As I talk with other security and IT professionals who don't read blogs I'm amazed at how much more informed I am then they are about what is going on in the world of information security. I think the biggest benefit that I have gained from blogging is the friendships that I've developed w/ other bloggers and security professionals. Most of them I've never met, yet I know that I can call on them at any time if I need something. The next best thing has been the opportunity to interact with several of those of you who read my ramblings and then comment on them or send me emails. It's always good to know that what I have to say is enjoyed by others and occasionally adds value to them. Of course there are those who have disagreed with me from time to time and that's OK as well. Good healthy debate is good for the industry and helps to keep us sharp.

So, thanks to all of you who give me a few minutes of your time each day (that is when I don't go on a 2 week no blog spree). I hope that you stick around for the next several years.

I'm not an expert in all things security, but I am a thinker

My apologies to Glenn Beck for borrowing his line, but I think that it fits well. Not trying to toot my own horn just proud of the fact that I don't blindly follow the crowd. As you may know I haven't posted anything in over 2 weeks which is a first for me. Life continues to keep me busy and the last week or so have seen some personal events that have taken up lots of my time. During this time I've done a good bit of thinking and watching.

I'm not going to go into many details except to say that we had to buy a new vehicle recently due to my wife being the victim of another driver who wasn't paying attention while driving. At least not paying attention to driving, who was on the road near him, etc.. He may have been paying attention to something else but not these things. We also had to rent a car, talk to insurance adjusters and reps, make doctor visits, etc.... All the fun things that go along with something such as this. While I was doing these things I took advantage of the opportunity to practice my Johnny Long "No Tech Hacking" techniques. I noticed lots and lots of opportunities to gain access to personal information of other people and even to gain access into the computer systems of some of these companies.

I was left in offices alone w/ a logged on PC several times for various amounts of time. Several times there were also applications open that could spill their guts on other customers and clients. Many times I was left alone with documents loaded w/ PII right on the desk I was sitting at. I overheard lots of phone calls that involved names, addresses, credit scores, credit limits, etc...

Of course I was also asked to give sensitive information to many of these companies. Some needed it to fill out claim forms, reports, credit apps, etc... As usual many of the auto dealers wanted a copy of my drivers license before allowing me to test drive a car. When asked what they do with the copy I was told different things. Some said they were shredded, filed, thrown away and "I really don't know". Needless to say the answer given had a lot to do with whether or not I took a test drive and then I ensured that before I left the copy was truly destroyed.

In one office I was left alone w/ PII on the desk, several computers logged on w/ apps open, heard PII given out over the phone and then heard one girl tell the customer that the copy of the document was shredded to protect them. At least they have the right idea. They are just missing several pieces.

That's where the "I'm a thinker" part comes into play. What these companies need is to take a few minutes and think about what they are doing, why they are doing it and what they are not doing that needs to be done. The office above was taking a great step in shredding documents but they obviously either didn't have policies, processes and training in place to prevent lots of other errors. It's great that they shred a copy of a document that has my PII on it but what good does it do if all of the info on the document is freely available to others who are left alone in the office? This is why we can't just do "best practices" and move on. You have to take a look at the bigger picture of what is happening in your environment and work from there.

As the CSO or top security professional in a company it is difficult to know what all goes on out in user land unless you spend some time there. You need to talk to people who do the front line work and find out what they do that may need to be addressed. You need to either visit or at least have someone else visit different locations and departments to find out what is going on that the users would never be aware of. I'm talking about things such as giving out names, addreses and other information over the phone in front of other customers, leaving documents on a desk instead of filing them or at least putting them in a lockable drawer until you can get to them later. I realize that this is not the type of things that a busy security professional (especially if you are in the top spot) so this is where you can utilize your desktop support team and others who are in the field.

Another area that we need to pay attention to was made apparent recently by the legal department of the MBTA. In their efforts to stop a DefCon talk about how to hack the MBTA Charlie Card and other sloppy security issues, they released more info than would have been released by the talk. Not to mention that they brought lots more media attention to the fact than if they had just let the talk go on as scheduled. If they had bothered to consult with their security team they might have made better decisions in how to handle this.

As security professionals it's our job to protect the organization that we work for. We have to look out for their best interest even if it's in areas that we are not responsible for. What I mean by that is looking for things that aren't right and making them known to those who are responsible, doing our part to let others know that security is here to be an enabeler and not to hinder business. Letting them know that we can add value to all areas of the business if they will solicit our input (such as legal, HR, etc). Often these departments don't even think about how security can add value to what they do. Many times we think differently about problems because most of us think about how to make things do what they aren't supposed to do (or at least we are aware that the bad guys are doing this) and we see things from a point of view that the business units and even regular IT doesn't.

One more post on DNS

OK, here is my reply to LonerVamps comments on HD Moore releasing Metasploit exploits for the DNS vulnerability that Dan Kaminsky discovered.
Loner broke his comments up into two different comments. I've posted both of them below and my response will be in red.

First Comment
With or without Druid's exploit, our users were at risk. And rather than sit in the dark and not want exploit code, I certainly don't mind having it around to learn from it. I'd even contend that we're better off researching exploit code; write more, learn more, write better ones, learn yet more, and so on. I agree that having exploit code can be beneficial as we learn more about the vulnerabilities and how to protect ourselves from them.

So, you would probably come back and say that HD Moore shouldn't have released it "at this time." But, what basis is there for when a time is appropriate to release exploit code? One year after the disclosure/patches? One month? After a committee of CISSPs gets together an votes on it? After 75% of servers are patched? Ever? I think that the answer to this question depends on what the vulnerability is and how easy the exploit is to deploy. In this case the vulnerability was big and had the potential to affect a large portion of the Internet. Potentially sending people to sites that could do all sorts of things from something as harmless to the user as auto clicking on ads to as harmful as dropping Trojans and other malware on systems as well as stealing account info for financial sites. If this had been just a browser vuln or an ActiveX issue then I wouldn't have been as concerned about HD releasing his exploit this early. Not because the end result is less but because even those who did do their due diligence were vulnerable to potential big problems.

And how does exploit code differ from vulnerability details? Should we not disclose details that could lead to exploit code for 1 month, 1 year, or ever? As for when to release vuln details that is a whole different question that has been debated for a long, long time. I'm too tired to deal with that now. :)

This set of questions simply cannot be answered, and never will. And since they can't be answered, I'd have to err on the side of reality: Exploit code is exploit code, and when it is released it is released. And then move on. :)

2nd Comment:
said my comment was too long :(

Andy, I fear you are arguing the side that is actually indefensible. :) Acting "responsibly" is far too relative to ever apply to such a set of people as security-aware geeks. Even though I agree with you in reality I disagree that we shouldn't expect "security-aware geeks" to act responsibly. Unfortunately we, as security professionals, often do not act responsibility I feel that we have a responsibility to our users and companies to be responsible. That doesn't mean that we blindly apply a patch just because the vuln is a big on or even because exploit code has been released. It also means that we don't release exploit code when other parties (researcher, vendors, most users) are acting responsibility and doing their job. It would be different if the vendors were ignoring this but they weren't. They acted responsibly and HD should have let things be.

Here's another way to tackle it. Should we manage our security posture based on whether exploit code is known or not? Yes, a vulnerability/patch does have a different value based on whether code is known or not, but when no known exploit code is in the wild, is it OK to put off the patching of your servers?

It might be argued that distributing details and exploit code will actually stimulate a more secure digital world. If your time frame for patching DNS was a month after the patches because the vuln wasn't known or the exploit created, but is now immediately because an exploit has been released...is that not a desirable state? Obviously the presence of code prompts action, and as such, this might be a benefit to us all... In today's world of the bad guys being ahead of us on almost every front and since as soon as a patch is released it is reverse engineered and an exploit is in the wild within hours then any security guy worth his salt knows this. So if he chooses to put off patching just because there is no known exploit then he is just asking for trouble. We all measure risk and then make a decision based on our level of comfort with each issue. Personally when you have an issue of this magnitude I think you are foolish to wait for known exploits.

Result from DNS Poll

This has been one of the most popular polls that I've had. My post about this garnered a good deal of comments and emails. Most of which disagree with me. Not surprising since usually people who do agree don't comment nearly as much as those who disagree. I'm not through with this either. LonerVamp has come good comments that I want to respond to when I have more time.

There were 106 votes on the poll almost 70% of you said that HD should have released the exploit for one of the 3 yes reasons. The totals were 70 yes and 26 no. For a while I thought I would be the only one to vote "No, It was irresponsible of him". I still stand by that statement and when I respond to Loners comment I'll explain why in more detail. But for now I will say that I'm not against him releasing an exploit at a later date, just not at the time he did.

Here is the breakdown by answer.

Yes, we deserve to have it	18 (16%)
Yes, if he didn't someone else would	24 (22%)
Yes, the bad guys already have their own	28 (26%)
No, it was irresponsible of him to do so	9 (8%)
No, it's too early and several people haven't patched their servers yet.	23 (21%)
No, we don't need WhiteHat exploits.	4 (3%)

I was a little surprised that 4 of you voted "No, we don't need WhiteHat exploits." I'd love to hear from you with your reasoning why you feel that way.

Hopefully by now everyone has patched their servers, including AT&T (that is another irresponsible matter in my opinion) and that this is behind us.