The Vancouver metro system was/is affected by a bug that can be exploited to grant free rides to anyone with an NFC smartphone. We as a security community have know about this since 2012 when Corey and I discovered, disclosed, and presented the bug. There was a lot of press surrounding our disclosure:

Back in 2012, only a couple devices on the market supported NFC. Corey was able to cobble together “UltraReset”, an Android app that would do the deed, which we used for demos but never released. Now, however, there are a ton of free apps in the Google Play store that could be (mis)-used to exploit this issue.

We disclosed this bug to the transit agencies that we knew were affected ~6 months before we publicly revealed the bug. In order to privately disclose the bugs, we had to go through personal contacts to reach appropriate parties at SF Muni and NJ PATH (the two systems that we knew were affected at time of disclosure). While we couldn’t talk with them or test directly, we suspected that other systems around the world were vulnerable, and we styled our presentation to that effect. After the presentation, we got tons of requests for UltraReset or help exploiting a local transit system (we, obviously, declined). The next year, there was some cool follow up research by Matteo Beccaro and Matteo Collura that provided additional ways to circumvent the controls and guidance for transit agencies implementing a fix.

Fast forward to 2016, and this bug pops up in a major system with very similar features to SF Muni and NJ PATH. Why is this bug so hard to kill? I have a couple of theories:

  • Threat modeling: Temporary cards are an edge case. Common thought may be: temporary cards carry very limited value (only a ride or two or ten) and they’re temporary. So, we’re not worried about someone adding $100 to the cards and handing them out. However, a real threat model will point out the exact opposite. Temporary cards do the exact same thing as permanent cards, just with fewer security features: they let you access the system.
  • Hardware: If the city has bought a large quantity of “temporary” NFC cards (and that is where the vulnerability exists: in exploitation of the temporary transit cards only) and programmed their turnstyles to read/write from the unprotected memory pages and not the OTP bits, they’re locked in. The cards we identified already had some values written to the OTP bits, which means it would take a clever (but likely very possible) hack to allow the transit agencies to write to/check the OTP bits instead. As Matteo/Matteo point out, they also need to make sure the OTP memory page isn’t locked for writing as well.
  • Vendors selling the systems to cities are doing just that: selling. They’re not interested in going back to the table and integrating security features.
  • Obscurity: if you can’t “see” the NFC communication, it is very difficult to impersonate it. Now that everyone has an NFC reader/writer in their pocket, we need to reconsider the obscurity of the system. Security by obscurity is never a good strategy, and this situation illustrates exactly why.

As a result, the reaction we see from transit agencies is: “we’ll monitor and punish”. I’m not entirely confident that the system can be monitored effectively, and by definition it’s difficult to link up temporary cards with riders. In terms of enforcement, we’re back to the NYC standard: cops standing behind a pillar waiting for someone to digitally jump the turnstyle (except way less obvious, since there’s no physical difference between a new card and a reloaded card).

So, New York City MTA and others: if you’re thinking of implementing NFC turnstyles, please don’t make the same mistake. Ask your vendor if they’ve accounted for this vulnerability in their system design. It’s been 4 years. We shouldn’t see any new transit systems with this flaw.