Computerworld

MBTA flaw disclosure: The students speak up

Zack Anderson, one of three MIT students who successfully exploited flaws in the Massachusetts transit authority's ticketing system, says they were right to disclose the problem, but that miscommunication was an issue.

Zack Anderson was one of three MIT students who caused a stir over the summer when they decided to disclose flaws they discovered in the Massachusetts transit authority's "Charlie Card" fare system.

Anderson, Russell "RJ" Ryan and Alessandro Chiesa planned to show off their findings (.pdf) at the Defcon hacker conference in August, prompting the Massachusetts Bay Transportation Authority (MBTA) to seek a temporary gag order until the problems could be fixed.

A US District court judge eventually dissolved the gag order, but the incident rekindled debate over whether flaws should be publically disclosed before the affected vendor has a chance to fix them.

In this Q&A, Anderson explains the surprise he and his peers felt over the MBTA's response, why he thinks the flaw exposure was necessary and what the lesson is for future researchers.

What was the main motivation for hacking into the MBTA's ticketing system?

It started as a class project. We wanted to do a security analysis of an important system which, if the security were compromised, could lead to a number of issues. We settled on subway fare collection systems and saw that the system integrator that makes Boston's fair collection system also makes collection systems around the world. We figured that if we were to find vulnerabilities in the Boston system they might well apply to others.

Were you surprised by how easily you were able to punch through the system?

Yeah. What was most surprising, though, was the fact that they already have a lot of infrastructure in place to build a much more secure system but they don't have the software to leverage that hardware.

Were you and your fellow students surprised by the resistance you ran into with the MBTA after you announced your discovery?

Absolutely. We did contact the MBTA and said we wanted to sit down with them, go over what we had found and recommend some ways to fix it so they could go back to the integrator and say'this is what we'd like done.' We thought that would go well, since we were out to help them. What happened instead was a lot of animosity from the start. The funny thing is that we eventually did sit down with them and everything was fine. The person we sat down with thanked us and was mad at the system integrator for making a flawed system that the MBTA had spent millions of dollars on.

Page Break

So the pushback came from someone above the person you met with?

Yeah, and I think there was also a lack of communication within the organization. We probably should have spoken directly with the person at the top rather than leaving it be with the person they ended up sending out. That might have helped us to avert some issues. Given our relationship with the person we spoke to from the MBTA and the lawsuit that followed a few days later, it's clear that something was lost in translation within the organization.

Typically in the lead-up to Black Hat and Defcon a vendor or someone else tries to block at least one presentation that's on the agenda, and the MBTA incident has re-opened the debate over responsible disclosure. What's your position?

Responsible disclosure implies you're not going to create havoc for the vendor who legitimately wants to fix the problem but doesn't necessarily have the time. You want to give the vendor some time. In our case we gave them a little time but probably not enough for the fixes they needed to do. But the key point for us was that in our presentation we were going to leave out a few major details so someone couldn't go defraud the MBTA. On that basis, we felt that what we were doing was responsible disclosure. The key is to maintain a level of trust from the beginning and I think that's where it went wrong for us.

Now that the gag order has been lifted, what's the status?

Are they trying to fix the problem? Anderson: I think they do want to fix it. Now that it's public I think they have to. That's one of the things disclosure does. It forces a vendor to acknowledge and fix problems they really should fix.

What's your advice to other researchers so that they might be able to avoid the situation you found yourself in?

One key point if that you need to maintain a trust relationship with the vendor from the beginning. Contacting the vendor before even a vague public mention is pretty important. You want to speak to someone at the top. The bottom-up approach is not good because you can speak to someone who is fine with what you're showing them and will sign off on it but that doesn't mean everyone's going to be fine with it. So you really need to speak with someone at the top.