September 01, 2008
PEER REVIEW OF THE MIT/MBTA "HACK" - PART 3
I followed up my pulpit-pounder below with these afterthoughts:
And The Goose replies:
Comments are disabled.
Post is locked.
I just read the vulnerability assessment that some are touting as being more damaging to MBTA than what was going to be presented at DefCon, and the mean old lawsuit liberated it unintentionally, oh the irony.
I must say, I expected more. It's a lot of "could have", "might be", "if they", and "with the right equipment and software."
It reads mostly like a basic review of the well-understood features and cost trade-offs of the system, which leads me to believe that OF COURSE MBTA knows what the vulnerabilities are, and that they decided to live with them.
The solution these guys propose is ludicrous - they have no idea how tough it would be to maintain a centralized account database with real-time access. The system would fall to its knees any time they had any kind of telecom problem. Talk about your angry customers - imagine a whole station shutting down at rush hour if the data line or server goes down. MBTA made the right choices.
And their comments about the crummy "physical security" makes my point. For the cost of zero dollars and no software or hardware or other high tech stuff, any mook can walk in and steal cards out of an unlocked room. You can bet some employees are dealing them out the back door as well. But identifying personnel-caused problems is easy, and I'm sure the MBTA is well aware of those. Fixing them, in a union town like Boston, is a real challenge.
And even at the $600 maximum per cloned card, the risk of fencing them to the losers who would buy them makes it almost certain that you'd get caught.
This is a righteous beef the MBTA has.
You want irony? This paper is marked "CONFIDENTIAL". Why all the 'free speech' attitude then? What's yours is mine, right?
And I see from his DefCon bio that one of the kids has patents pending. Good for him. Hope nobody hacks his inventions, but if they do, I bet he sues. Or else why get a patent?
I must say, I expected more. It's a lot of "could have", "might be", "if they", and "with the right equipment and software."
It reads mostly like a basic review of the well-understood features and cost trade-offs of the system, which leads me to believe that OF COURSE MBTA knows what the vulnerabilities are, and that they decided to live with them.
The solution these guys propose is ludicrous - they have no idea how tough it would be to maintain a centralized account database with real-time access. The system would fall to its knees any time they had any kind of telecom problem. Talk about your angry customers - imagine a whole station shutting down at rush hour if the data line or server goes down. MBTA made the right choices.
And their comments about the crummy "physical security" makes my point. For the cost of zero dollars and no software or hardware or other high tech stuff, any mook can walk in and steal cards out of an unlocked room. You can bet some employees are dealing them out the back door as well. But identifying personnel-caused problems is easy, and I'm sure the MBTA is well aware of those. Fixing them, in a union town like Boston, is a real challenge.
And even at the $600 maximum per cloned card, the risk of fencing them to the losers who would buy them makes it almost certain that you'd get caught.
This is a righteous beef the MBTA has.
You want irony? This paper is marked "CONFIDENTIAL". Why all the 'free speech' attitude then? What's yours is mine, right?
And I see from his DefCon bio that one of the kids has patents pending. Good for him. Hope nobody hacks his inventions, but if they do, I bet he sues. Or else why get a patent?
And The Goose replies:
I will answer your questions as best I can.
"Is what they did actually technically difficult?"
The work the students did was rather difficult, but they did have help from two sources. The first is from this story. The OysterCards use the same chip as the CharlieCards. A Dutch group already found exploits for the OysterCard. The students probably started their project because of the Dutch research. The CharlieCards also use a layer of security above the OysterCards. It is an encryption algorithm called Crypto-1. A group at the University of Virginia had already found weaknesses in the algorithm. The students state in their report they used these flaws to crack the encryption faster.
Even with these two sources, the students still had to figure out how the MBTA implemented these and other security measures. For instance, the turnstiles issue challenge/response pairs to verify the cards. The challenges are supposed to be random, but instead they are based on the number of clock cycles since the machine powered on. Thus, you can narrow down your guesses. Once you know the correct value and as long as the turnstile does not go through a power cycle, then you know what the next challenge value will be. Another example is the 6 Bit checksum. A hacker would only have to try a maximum of 64 cards before they got it right (2^6 = 64). The student's suggestion to increase the checksum to to 16 Bits is not unreasonable. So the student's work was not easy, but the hardest part was already done for them (finding weaknesses in the encryption algorithm).
"Can this process be easily duplicated?"
Replicating this hack would actually be quite easy. The students had planned to release open source software to do most of the dirty work. A person would only need to buy a RFID encoder. The software would take care of the encryption, checksum, challenge/response pairs, and any other tasks. The user would need zero knowledge of how the hack works (kind of like using a blue box).
"How could this profitably be exploited?"
I don't think the students planned to make a profit from this. Same with phreaking or using slugs, this probably was not intended to make a profit. After all hacking is said and done, I would equate this to getting free stuff from a vending machine. The information is out there. It isn't hard to do. But most people still get their stuff legitimately. Some one could do the trick repeatedly and sell the snacks for profit. Like wise, some one could make a bunch of phony CharlieCards and sell them for a profit. I think it is highly unlikely. Even Transport for London isn't worried (from the Guardian article), "We run daily tests for cloned or fraudulent cards and any found would be stopped within 24 hours of being discovered,' it said in a statement. 'The most anyone could gain from a rogue card is one day's travel."
"What are the possible losses to the MBTA from others actually trying to exploit the flaws vs. the cost of fixing the flaws?"
The loss in revenue would be trivial, probably similar to people just jumping over the turnstiles. I will admit that most of the "fixes" the students suggested were absolutely hilarious. A giant central database designed to track cards worth, on average, eight to ten dollars is just absurd. However, using a better encryption algorithm or a longer checksum is not unreasonable. I am assuming the changes would be in software. That is probably a terrible assumption. If the changes had to be in hardware, then any change would be prohibitively expensive.
It would not be worthwhile for the MBTA to update their system. It is more cost effective for them to sue the crap out of anybody who tries to break it. This is the old Security through Obscurity philosophy. If nobody knows how it works, then it can not be hacked.
I am really glad you found one of the students has patents pending. I find that hilarious. Most computer science types and especially hackers are disgusted with patents. And the big "CONFIDENTIAL" splayed across their report is rather contradictory to their Free Speech defense. I had originally heard about the OysterCard incident from Bruce Schneier. He is regarded by many as the Security Guru.
And with that, we'll consider this subject throughly analyzed, until such time, if and when, more comes from the source."Is what they did actually technically difficult?"
The work the students did was rather difficult, but they did have help from two sources. The first is from this story. The OysterCards use the same chip as the CharlieCards. A Dutch group already found exploits for the OysterCard. The students probably started their project because of the Dutch research. The CharlieCards also use a layer of security above the OysterCards. It is an encryption algorithm called Crypto-1. A group at the University of Virginia had already found weaknesses in the algorithm. The students state in their report they used these flaws to crack the encryption faster.
Even with these two sources, the students still had to figure out how the MBTA implemented these and other security measures. For instance, the turnstiles issue challenge/response pairs to verify the cards. The challenges are supposed to be random, but instead they are based on the number of clock cycles since the machine powered on. Thus, you can narrow down your guesses. Once you know the correct value and as long as the turnstile does not go through a power cycle, then you know what the next challenge value will be. Another example is the 6 Bit checksum. A hacker would only have to try a maximum of 64 cards before they got it right (2^6 = 64). The student's suggestion to increase the checksum to to 16 Bits is not unreasonable. So the student's work was not easy, but the hardest part was already done for them (finding weaknesses in the encryption algorithm).
"Can this process be easily duplicated?"
Replicating this hack would actually be quite easy. The students had planned to release open source software to do most of the dirty work. A person would only need to buy a RFID encoder. The software would take care of the encryption, checksum, challenge/response pairs, and any other tasks. The user would need zero knowledge of how the hack works (kind of like using a blue box).
"How could this profitably be exploited?"
I don't think the students planned to make a profit from this. Same with phreaking or using slugs, this probably was not intended to make a profit. After all hacking is said and done, I would equate this to getting free stuff from a vending machine. The information is out there. It isn't hard to do. But most people still get their stuff legitimately. Some one could do the trick repeatedly and sell the snacks for profit. Like wise, some one could make a bunch of phony CharlieCards and sell them for a profit. I think it is highly unlikely. Even Transport for London isn't worried (from the Guardian article), "We run daily tests for cloned or fraudulent cards and any found would be stopped within 24 hours of being discovered,' it said in a statement. 'The most anyone could gain from a rogue card is one day's travel."
"What are the possible losses to the MBTA from others actually trying to exploit the flaws vs. the cost of fixing the flaws?"
The loss in revenue would be trivial, probably similar to people just jumping over the turnstiles. I will admit that most of the "fixes" the students suggested were absolutely hilarious. A giant central database designed to track cards worth, on average, eight to ten dollars is just absurd. However, using a better encryption algorithm or a longer checksum is not unreasonable. I am assuming the changes would be in software. That is probably a terrible assumption. If the changes had to be in hardware, then any change would be prohibitively expensive.
It would not be worthwhile for the MBTA to update their system. It is more cost effective for them to sue the crap out of anybody who tries to break it. This is the old Security through Obscurity philosophy. If nobody knows how it works, then it can not be hacked.
I am really glad you found one of the students has patents pending. I find that hilarious. Most computer science types and especially hackers are disgusted with patents. And the big "CONFIDENTIAL" splayed across their report is rather contradictory to their Free Speech defense. I had originally heard about the OysterCard incident from Bruce Schneier. He is regarded by many as the Security Guru.
Posted by: JBD at
02:05 PM
| No Comments
| Add Comment
Post contains 1094 words, total size 10 kb.
14kb generated in CPU 0.007, elapsed 0.0333 seconds.
23 queries taking 0.0283 seconds, 28 records returned.
Powered by Minx 1.1.6c-pink.
23 queries taking 0.0283 seconds, 28 records returned.
Powered by Minx 1.1.6c-pink.