Comments on: MBTA Hack: Is It Really This Easy? http://www.veracode.com/blog/2008/08/mbta-hack-is-it-really-this-easy/ Application security testing, analysis, and metrics Thu, 09 Feb 2012 11:59:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Anton Aylward http://www.veracode.com/blog/2008/08/mbta-hack-is-it-really-this-easy/comment-page-1/#comment-2026 Anton Aylward Thu, 21 Aug 2008 22:23:46 +0000 http://www.veracode.com/blog/?p=238#comment-2026 Compare this with the system used by the Toronto Transit Corporation. The 'pass' is for a given period and allows unlimited travel in that period. As such the gates only have to check to see if the pass is used within its valid timeframe. The economics of this are obviously different. See http://www3.ttc.ca/ A commuter will make 2 trips a day at $2.75, minimum, so there is a small saving. But the TTC benefits from a plan that gives a predictable cash flow. The consumer also benefits from the convenience of the pass for extra 'incidental' trips. No doubt the overall economic analysis also takes into account that this is an incentive to use the transit system compared to driving. Regardless: what I find interesting is how different cities seem to come to different conclusions and use different economic models given much the same data about commuters. Compare this with the system used by the Toronto Transit Corporation.
The ‘pass’ is for a given period and allows unlimited travel in that period. As such the gates only have to check to see if the pass is used within its valid timeframe.

The economics of this are obviously different. See http://www3.ttc.ca/

A commuter will make 2 trips a day at $2.75, minimum, so there is a small saving. But the TTC benefits from a plan that gives a predictable cash flow. The consumer also benefits from the convenience of the pass for extra ‘incidental’ trips. No doubt the overall economic analysis also takes into account that this is an incentive to use the transit system compared to driving.

Regardless: what I find interesting is how different cities seem to come to different conclusions and use different economic models given much the same data about commuters.

]]> By: Brandon Creighton http://www.veracode.com/blog/2008/08/mbta-hack-is-it-really-this-easy/comment-page-1/#comment-2012 Brandon Creighton Fri, 15 Aug 2008 17:57:17 +0000 http://www.veracode.com/blog/?p=238#comment-2012 If the value isn't stored on the card, then the system isn't able to collect fares when the network isn't available (say, a bus is in a tunnel, or the network is down). That doesn't mean that the system shouldn't or couldn't check a centralized card database, encrypt the data, or even use a checksum with an effective possible entropy greater than 6 bits (even SYSV sum(1) gives you 16 bits). In short: as they implied in their recommendations, the problem isn't with a) or b), it's with c) and d). Even with crypto, there are still plenty of points of attack -- if you think IKE is complicated, try working out the logistics of key distribution for fare readers and buses from Providence to Newburyport. One question I'm curious about that isn't explicitly mentioned in either the presentation or the recommendations is: do the CharlieTickets have machine-readable unique IDs that are tracked by the fare readers? If this isn't the case, the resulting attack doesn't even require a magstripe reader: Buy a card; slice the important tracks into two (or more if you're lucky) identical pieces; re-assemble each onto a new card; and go to town. There's a breakdown of the fields in the slides, but I'm not sure whether or not it's a complete description of the card. By the way, since apparently no journalist has bothered to dig this far (even though it's mentioned in the presentation slides), the contractors responsible for the MBTA's system are <a href="http://www.oti.co.il/content.aspx?id=263" rel="nofollow">Scheidt & Bachmann/OTI</a>. S&B is also responsible for the awesome LIRR/Metro-North card system that <a href="http://www.nytimes.com/2008/08/13/nyregion/13scam.html?em" rel="nofollow">lets users buy cards even if their debit cards don't have enough money to cover the cost</a>. If the value isn’t stored on the card, then the system isn’t able to collect fares when the network isn’t available (say, a bus is in a tunnel, or the network is down). That doesn’t mean that the system shouldn’t or couldn’t check a centralized card database, encrypt the data, or even use a checksum with an effective possible entropy greater than 6 bits (even SYSV sum(1) gives you 16 bits).

In short: as they implied in their recommendations, the problem isn’t with a) or b), it’s with c) and d).

Even with crypto, there are still plenty of points of attack — if you think IKE is complicated, try working out the logistics of key distribution for fare readers and buses from Providence to Newburyport.

One question I’m curious about that isn’t explicitly mentioned in either the presentation or the recommendations is: do the CharlieTickets have machine-readable unique IDs that are tracked by the fare readers? If this isn’t the case, the resulting attack doesn’t even require a magstripe reader: Buy a card; slice the important tracks into two (or more if you’re lucky) identical pieces; re-assemble each onto a new card; and go to town. There’s a breakdown of the fields in the slides, but I’m not sure whether or not it’s a complete description of the card.

By the way, since apparently no journalist has bothered to dig this far (even though it’s mentioned in the presentation slides), the contractors responsible for the MBTA’s system are Scheidt & Bachmann/OTI. S&B is also responsible for the awesome LIRR/Metro-North card system that lets users buy cards even if their debit cards don’t have enough money to cover the cost.

]]>